From skitrip-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jul 01 08:33:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwefW-0002mi-V5 for capwap-archive@lists.ietf.org; Sat, 01 Jul 2006 08:33:50 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwefU-000436-Ly for capwap-archive@lists.ietf.org; Sat, 01 Jul 2006 08:33:50 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 64F4E430141 for ; Sat, 1 Jul 2006 05:33:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: frascone.com mailing list memberships reminder From: skitrip-owner@frascone.com X-No-Archive: yes Message-ID: Date: Sat, 01 Jul 2006 05:31:14 -0700 Precedence: bulk X-BeenThere: skitrip@frascone.com X-Mailman-Version: 2.1.8 List-Id: X-List-Administrivia: yes To: capwap-archive@lists.ietf.org Errors-To: skitrip-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 This is a monthly reminder about your frascone.com mailing list memberships. It shows the lists you are subscribed to, your passwords, and a Web page URL you can use to manage your subscriptions. Visit the Web page URL shown below to unsubscribe, change your e-mail address, temporarily disable your subscription for a vacation, set digest-style delivery, and so on. You can also use e-mail to make changes. For more info, send a message to the '-request' address of the list (for example, skitrip-request@frascone.com) containing just the word 'help' in the message body. An e-mail message will be sent to you with instructions. Here is the subscription information for capwap-archive@lists.ietf.org: List Password // URL ---- -------- capwap@frascone.com ugimni http://lists.frascone.com/mailman/options/capwap/capwap-archive%40lists.ietf.org From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jul 01 13:41:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwjTC-0001Bi-6X for capwap-archive@lists.ietf.org; Sat, 01 Jul 2006 13:41:26 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwjT9-0000pr-Ma for capwap-archive@lists.ietf.org; Sat, 01 Jul 2006 13:41:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9E1F5430162 for ; Sat, 1 Jul 2006 10:41:22 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id C0B0943004F for ; Sat, 1 Jul 2006 10:40:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id AEB0D398029 for ; Sat, 1 Jul 2006 10:40:56 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id AD10A39801E for ; Sat, 1 Jul 2006 10:40:54 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k61HerPv020781; Sat, 1 Jul 2006 10:40:53 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k61HerBH020778; Sat, 1 Jul 2006 10:40:53 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Sat, 1 Jul 2006 10:40:53 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2021DFA6B@xmb-sjc-235.amer.cisco.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Update proposal for Packet formats X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 HI, Well, I think there are differences between a "retry bit", and a "retry number field" that is an integer and has range of 0 to 16. Small misunderstandings can be the source for non interoperation. Interoperation is the number one priority of the IETF, and one of the most important reasons why IETF technology has exploded in usage from the late 80s. I hope we can work out the tradeoffs of this field. I thought that I had explained it in the document. I must have been a little skimpy. I hope we can work this out, and develop interoperable implementations showing basic operation of the CAPWAP protocol. Otherwise, I suggest the WG be disbanded. If there is not enough commitment to achieve demonstration of basic interoperability then why would we expect demonstration of interoperability of all features, which is required for advancement on the standards track of the specification. Development of a specification that does not have interoperability is no benefit to the IETF community. Regards, /david t. perkins On Fri, 30 Jun 2006, Pat Calhoun (pacalhou) wrote: > Now I'm confused... > > > And on your specific question of a "retry bit", I quess I was > > not clear, because there is NO retry bit in my packet format > > proposal. > > > Retry#: The retry number field starts at zero and is incremented > > for each message with the same value of message ID. > > After the maximum value is reached, the value wraps back > > to zero. The paired response (or acknowledgement) returns > > the value from the request (or report). Note the size > > is 4-bits, and thus a maximum of 16 retries can be > > be currently outstanding. > > This field is used to match a request (or report) > > with its paired response (or acknowledgement) so that > > accurate round trip operation time can be determined. > > (DISCUSS: maybe put back here the text about how this > > works. The examples of operation retries should help.) > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > Sent: Friday, June 30, 2006 4:17 PM > > To: Pat Calhoun (pacalhou) > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Update proposal for Packet formats > > > > HI, > > > > Pat, while I appreciate and share your concerns about > > changes, I believe that there are serious problems in the > > fragmentation and retry scheme in CAPWAP-01. (I haven't had > > the time to check to see if this has changed in CAPWAP-02.) > > I've asked repeatedly for some one to show a timing diagram > > of this and other issues, but have not seen this. I've only > > seen responses to the affect "I understand how it works and I > > don't need a diagram." This type of comment does not verify > > that all that have read the document have reached a common > > understanding. Of course, you are well aware of IETF > > requiring interoperable implementations to demonstrate common > > understanding for a standards track document to advance. > > > > Basic issues, such as this should have been addressed and > > resolved starting at the November IETF, and if needed an > > interim meeting that the WG didn't have. I'm disappointed. > > The problems still remain. Let's put a spotlight on the > > issues and see if they are real, imaginary, or somewhere inbetween. > > > > > > > On Fri, 30 Jun 2006, Pat Calhoun (pacalhou) wrote: > > > David, > > > > > > I'm not sure that I understand the justification for making all of > > > these rather dramatic changes to the protocol, so I'm not sure what > > > implementation and demonstration would buy us at the IETF. I think > > > what would be useful instead is to create issues that describe the > > > actual problem. We can change the protocol until the cows > > come home, > > > but in order to maintain some level of sanity, we need to start > > > getting a little more aggressive about rejecting feature requests. > > > > > > One comment on the retry number, though. Both sides have to > > maintain > > > state anyways, so it's not clear to me that there is any > > use in this > > > bit. For instance what do you do if you receive a message with the > > > "Retry" bit set, but had never received the first one? The > > bit really > > > doesn't provide much use in this case. So in any case you need to > > > maintain a running counter of what's been received & > > processed, and we > > > do this through the sequence number field. The reliability > > part of the > > > CAPWAP protocol also ensures that packets are retransmitted if not > > > acknowledged (where your proposal would require that the packet be > > > re-encrypted because the Retry bit was changed). > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > Regards, > > /david t. perkins > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 03 02:04:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxHY6-0003hM-Jp for capwap-archive@lists.ietf.org; Mon, 03 Jul 2006 02:04:46 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxHNW-0007zC-9O for capwap-archive@lists.ietf.org; Mon, 03 Jul 2006 01:53:53 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 89CB04300CB for ; Sun, 2 Jul 2006 22:53:49 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7B8C9430018 for ; Sun, 2 Jul 2006 22:53:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 649C1398011 for ; Sun, 2 Jul 2006 22:53:15 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0085039800B for ; Sun, 2 Jul 2006 22:53:11 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k635r6JX012239; Mon, 3 Jul 2006 14:53:06 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k635r5t20834; Mon, 3 Jul 2006 14:53:05 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with SMTP id k635r5m05728; Mon, 3 Jul 2006 14:53:05 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Jul 2006 13:54:04 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDFF3A1F@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Thread-Index: AcaUcaGlibyXBya9RoaEC3MSIEfWHQJ8Cv/A From: "Saravanan Govindan" To: "Michael Montemurro" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.425 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0058271332==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 4ec58ef3f343ebf5ac40a04538f9a6fc This is a multi-part message in MIME format. --===============0058271332== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69E64.8CEA7E9B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69E64.8CEA7E9B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike, =20 I had a chance to review the new draft.=20 =20 With regard to Issue 43, my understanding is that updates were made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN message element now allows the AC to send sequence counter values to the WTP. So now, CAPWAP can support designs where the KeyRSC is maintained by the AC.=20 =20 My initial concern was with supporting designs where the KeyRSC is maintained by the WTP. This is particularly important to manage the 4-Way and Group-key handshakes.=20 =20 With this in mind, I think the protocol still requires support for designs where the KeyRSC is maintained by the WTP. Based on the current draft, this support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames would have unassigned fields for KeyRSC (since the value is maintained by the WTP).=20 =20 I am also open to any alternatives to support this.=20 =20 Cheers, Saravanan =20 =20 =20 =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Tuesday, June 20, 2006 10:01 PM To: Saravanan Govindan Cc: Bob O'Hara (boohara); capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 I've updated section 11.3 to deal with the GTK exchange and the handling of the KeyRSC in draft -02 to address your comments. I also provided a mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message element as part of the Group Key exchange.=20 =20 We're finalizing the -02 draft this week and you should be able to look at it when we post it later this week. =20 Cheers, =20 Mike ------_=_NextPart_001_01C69E64.8CEA7E9B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mike,

 

I had a chance to review the new draft. =

 

With regard to Issue 43, my understanding is that = updates were made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the = IEEE 802.11 Add WLAN message element now allows the AC to send sequence = counter values to the WTP. So now, CAPWAP can support designs where the KeyRSC = is maintained by the AC.

 

My initial concern was with supporting designs where = the KeyRSC is maintained by the WTP. This is particularly important to = manage the 4-Way and Group-key handshakes.

 

With this in mind, I think the protocol still = requires support for designs where the KeyRSC is maintained by the WTP. Based on = the current draft, this support can be included by adding another field to = the IEEE 802.11 Add WLAN message element. This field would contain Message-3 = EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key = handshake). These EAPoL frames would have unassigned fields for KeyRSC (since the value is maintained by the WTP).

 

I am also open to any alternatives to support this. =

 

Cheers,


Saravanan

 

 

 

 

From: = Michael Montemurro [mailto:montemurro.michael@gmail.com]
Sent: Tuesday, June 20, = 2006 10:01 PM
To: Saravanan Govindan
Cc: Bob O'Hara (boohara); = capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

 

Saravanan,

 

I've updated section 11.3 to deal with the GTK exchange and the handling of the KeyRSC in draft -02 to address your comments. I also = provided a mechanism for the AC to transmit the keyRSC to the WTP using the = updateWLAN message element as part of the Group Key exchange. =

 

We're finalizing the -02 draft this week and you should be able = to look at it when we post it later this week.

 

Cheers,

 

Mike

------_=_NextPart_001_01C69E64.8CEA7E9B-- --===============0058271332== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0058271332==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 03 03:01:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxIR6-00062y-T4 for capwap-archive@lists.ietf.org; Mon, 03 Jul 2006 03:01:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxIR5-0005VZ-Az for capwap-archive@lists.ietf.org; Mon, 03 Jul 2006 03:01:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 714E24300B0 for ; Mon, 3 Jul 2006 00:01:33 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4416C430018 for ; Mon, 3 Jul 2006 00:01:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EC3C043103C for ; Mon, 3 Jul 2006 00:01:01 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id CDDE6430646 for ; Mon, 3 Jul 2006 00:00:58 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id k6370ucJ027817 for ; Mon, 3 Jul 2006 16:00:56 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k6370uR29030 for ; Mon, 3 Jul 2006 16:00:56 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with SMTP id k6370vv05169 for ; Mon, 3 Jul 2006 16:00:57 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Jul 2006 15:02:10 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDFF3A40@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Editorial - WTP Event Request Thread-Index: AcaebpdAsrlTCjfpTu+amRRXjGnhFw== From: "Saravanan Govindan" To: "capwap" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE X-Spam-Level: Subject: [Capwap] Editorial - WTP Event Request X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0597958288==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 This is a multi-part message in MIME format. --===============0597958288== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69E6E.10C25BAE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69E6E.10C25BAE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 I would like to suggest an editorial update to Section 9.5 (WTP Event Request).=20 =20 This is based on earlier discussions of how WTP Event Request serves as an implicit keep alive mechanism for the WTP. I believe this observation can be made explicit in this section. =20 I suggest the following after the 1st paragraph of Section 9.5; =20 "The exchange of WTP Event Request serves as an implicit keep alive mechanism for the WTP. The arrival of a WTP Event Request message at the AC indicates the WTP is operational. In cases where WTP Event Request is not exchanged, explicit keep alive is used (see Section 7)." =20 The current text in Section 7 refers to maintaining the control communication channel, whereas the suggestion above refers to the WTP as a whole.=20 =20 Comments? =20 Saravanan ------_=_NextPart_001_01C69E6E.10C25BAE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

I would like to suggest an editorial update to = Section 9.5 (WTP Event Request).

 

This is based on earlier discussions of how WTP Event = Request serves as an implicit keep alive mechanism for the WTP. I believe this observation can be made explicit in this = section.

 

I suggest the following after the 1st = paragraph of Section 9.5;

 

“The exchange of WTP Event Request serves as an implicit keep alive mechanism for the WTP. The arrival of a WTP Event = Request message at the AC indicates the WTP is operational. In cases where WTP = Event Request is not exchanged, explicit keep alive is used (see Section = 7).”

 

The current text in Section 7 refers to maintaining = the control communication channel, whereas the suggestion above refers to = the WTP as a whole.

 

Comments?

 

Saravanan

------_=_NextPart_001_01C69E6E.10C25BAE-- --===============0597958288== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0597958288==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 03 09:22:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxONf-0007rU-Ik for capwap-archive@lists.ietf.org; Mon, 03 Jul 2006 09:22:27 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxONe-0002GT-57 for capwap-archive@lists.ietf.org; Mon, 03 Jul 2006 09:22:27 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1D43E43022F for ; Mon, 3 Jul 2006 06:22:25 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id C93704301B4 for ; Mon, 3 Jul 2006 06:20:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B8E8839801C for ; Mon, 3 Jul 2006 06:20:21 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.192.81]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8A26839801A for ; Mon, 3 Jul 2006 06:20:17 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc11) with ESMTP id <20060703132017m1100at5aee>; Mon, 3 Jul 2006 13:20:17 +0000 Message-ID: <44A91990.3080105@hyperthought.com> Date: Mon, 03 Jul 2006 06:20:16 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Saravanan Govindan References: <5F09D220B62F79418461A978CA0921BDFF3A40@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BDFF3A40@pslexc01.psl.local> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Editorial - WTP Event Request X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Hi Saravanan, I thought there was general agreement that if *any* authenticated = control traffic (not just an event request) is observed during the echo = interval, this is implicit proof of liveness, and no echo request is = required for that interval. Having text like what's suggested below = (that only references the event request) might lead people to = incorrectly conclude that only an event request can obviate the need for = an echo exchange. Why should we have text which confers this special status only on the = event request, rather than on all/any authenticated control channel traffic? Scott Saravanan Govindan wrote: > All, > = > = > = > I would like to suggest an editorial update to Section 9.5 (WTP Event = > Request). > = > = > = > This is based on earlier discussions of how WTP Event Request serves as = > an implicit keep alive mechanism for the WTP. I believe this observation = > can be made explicit in this section. > = > = > = > I suggest the following after the 1^st paragraph of Section 9.5; > = > = > = > =93The exchange of WTP Event Request serves as an implicit keep alive = > mechanism for the WTP. The arrival of a WTP Event Request message at the = > AC indicates the WTP is operational. In cases where WTP Event Request is = > not exchanged, explicit keep alive is used (see Section 7).=94 > = > = > = > The current text in Section 7 refers to maintaining the control = > communication channel, whereas the suggestion above refers to the WTP as = > a whole. > = > = > = > Comments? > = > = > = > Saravanan > = > = > ------------------------------------------------------------------------ > = > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > = > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 03 23:03:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxbBo-0000C3-MP for capwap-archive@lists.ietf.org; Mon, 03 Jul 2006 23:03:04 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxbBn-0005Sr-2W for capwap-archive@lists.ietf.org; Mon, 03 Jul 2006 23:03:04 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B818B430126 for ; Mon, 3 Jul 2006 20:03:01 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 256B9430018 for ; Mon, 3 Jul 2006 20:02:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 15F8A1448016 for ; Mon, 3 Jul 2006 20:02:38 -0700 (PDT) X-Greylist-Status: Sender first seen 00:30:54 ago Received: from cmccmta (webmail.chinamobile.com [211.136.27.4]) by hermes.tigertech.net (Postfix) with ESMTP id 0BC7B144800F for ; Mon, 3 Jul 2006 20:02:34 -0700 (PDT) Received: from ZHOUWENHUI ([10.1.5.54]) by mail.chinamobile.com (Lotus Domino Release 5.0.12HF438) with SMTP id 2006070410275027:1124 ; Tue, 4 Jul 2006 10:27:50 +0900 Message-ID: <00ad01c69f0f$8092fbc0$3605010a@ZHOUWENHUI> From: "Wenhui Zhou" To: References: Date: Tue, 4 Jul 2006 10:13:55 +0800 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 5.0.12HF438 | October 15, 2003) at 2006-07-04 10:27:50 AM, Serialize by Router on cmccmta/servers/cmcc(Release 5.0.6a |January 17, 2001) at 2006-07-04 10:54:15 AM, Serialize complete at 2006-07-04 10:54:15 AM X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=2.7 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MIME_BASE64_BLANKS, MIME_BASE64_TEXT X-Spam-Level: ** Subject: Re: [Capwap] Some question on CAPWAP protocol implementation X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Dear CAPWAP guys, i am sorry i missed much previous related topics, so i have some questions about CAPWAP protocol implementation. 1. Whether it has been decided that LWAPP will be the protocol implementing CAPWAP? 2. Whether all of the traffic of the control plane, management plane, as well as data plane will be encapsulated in the tunnel between WTP and the AC by the CAPWAP protocol imple? 3. Due to the hot and diverse discussions on CAPWAP protocol implementation here, can some kind of summary of agreement of CAPWAP protocol implementation be presented periodically? thanks. Wenhui Zhou ----- Original Message ----- From: To: Sent: Monday, July 03, 2006 6:16 PM Subject: Capwap Digest, Vol 9, Issue 3 > Send Capwap mailing list submissions to > capwap@frascone.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.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-owner@frascone.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Capwap digest..." > > > Today's Topics: > > 1. Re: Clarification of Issue 43: IEEE 802.11i Considerations > (Saravanan Govindan) > 2. Editorial - WTP Event Request (Saravanan Govindan) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 3 Jul 2006 13:54:04 +0800 > From: "Saravanan Govindan" > Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i > Considerations > To: "Michael Montemurro" > Cc: capwap > Message-ID: > <5F09D220B62F79418461A978CA0921BDFF3A1F@pslexc01.psl.local> > Content-Type: text/plain; charset="us-ascii" > > Hi Mike, > > > > I had a chance to review the new draft. > > > > With regard to Issue 43, my understanding is that updates were made in > Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 > Add WLAN message element now allows the AC to send sequence counter > values to the WTP. So now, CAPWAP can support designs where the KeyRSC > is maintained by the AC. > > > > My initial concern was with supporting designs where the KeyRSC is > maintained by the WTP. This is particularly important to manage the > 4-Way and Group-key handshakes. > > > > With this in mind, I think the protocol still requires support for > designs where the KeyRSC is maintained by the WTP. Based on the current > draft, this support can be included by adding another field to the IEEE > 802.11 Add WLAN message element. This field would contain Message-3 > EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for > Group-key handshake). These EAPoL frames would have unassigned fields > for KeyRSC (since the value is maintained by the WTP). > > > > I am also open to any alternatives to support this. > > > > Cheers, > > > Saravanan > > > > > > > > > > ________________________________ > > From: Michael Montemurro [mailto:montemurro.michael@gmail.com] > Sent: Tuesday, June 20, 2006 10:01 PM > To: Saravanan Govindan > Cc: Bob O'Hara (boohara); capwap > Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i > Considerations > > > > Saravanan, > > > > I've updated section 11.3 to deal with the GTK exchange and the handling > of the KeyRSC in draft -02 to address your comments. I also provided a > mechanism for the AC to transmit the keyRSC to the WTP using the > updateWLAN message element as part of the Group Key exchange. > > > > We're finalizing the -02 draft this week and you should be able to look > at it when we post it later this week. > > > > Cheers, > > > > Mike > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://lists.frascone.com/pipermail/capwap/attachments/20060703/7806c36e/attachment.htm > > ------------------------------ > > Message: 2 > Date: Mon, 3 Jul 2006 15:02:10 +0800 > From: "Saravanan Govindan" > Subject: [Capwap] Editorial - WTP Event Request > To: "capwap" > Message-ID: > <5F09D220B62F79418461A978CA0921BDFF3A40@pslexc01.psl.local> > Content-Type: text/plain; charset="us-ascii" > > All, > > > > I would like to suggest an editorial update to Section 9.5 (WTP Event > Request). > > > > This is based on earlier discussions of how WTP Event Request serves as > an implicit keep alive mechanism for the WTP. I believe this observation > can be made explicit in this section. > > > > I suggest the following after the 1st paragraph of Section 9.5; > > > > "The exchange of WTP Event Request serves as an implicit keep alive > mechanism for the WTP. The arrival of a WTP Event Request message at the > AC indicates the WTP is operational. In cases where WTP Event Request is > not exchanged, explicit keep alive is used (see Section 7)." > > > > The current text in Section 7 refers to maintaining the control > communication channel, whereas the suggestion above refers to the WTP as > a whole. > > > > Comments? > > > > Saravanan > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://lists.frascone.com/pipermail/capwap/attachments/20060703/b987e7b1/attachment.htm > > ------------------------------ > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > End of Capwap Digest, Vol 9, Issue 3 > ************************************ > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 04 02:55:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxeky-0001mj-42 for capwap-archive@lists.ietf.org; Tue, 04 Jul 2006 02:51:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxeXf-00081y-00 for capwap-archive@lists.ietf.org; Tue, 04 Jul 2006 02:37:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E2DAA43010F for ; Mon, 3 Jul 2006 23:37:49 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EF80E43006D for ; Mon, 3 Jul 2006 23:37:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D6F071448016 for ; Mon, 3 Jul 2006 23:37:21 -0700 (PDT) X-Greylist-Status: Sender first seen 27 days 22:30:39 ago Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by hermes.tigertech.net (Postfix) with ESMTP id B0E7C1448009 for ; Mon, 3 Jul 2006 23:37:17 -0700 (PDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k646XdZa018147 for ; Tue, 4 Jul 2006 02:33:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Received: from 300216erh2.post.avaya.com ([198.152.7.49]) by IS0004AVEXU1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Jun 2006 17:59:35 +0300 MIME-Version: 1.0 Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by 300216erh2.post.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5SExYgP001272 for ; Wed, 28 Jun 2006 08:59:34 -0600 Received: from leela-mail.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5SEtDhu000510 for ; Wed, 28 Jun 2006 10:55:13 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C2D9843016F for ; Wed, 28 Jun 2006 07:59:32 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 239C4430063 for ; Wed, 28 Jun 2006 07:59:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D7C5739805C for ; Wed, 28 Jun 2006 07:59:01 -0700 (PDT) Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by zoidberg.tigertech.net (Postfix) with ESMTP id 92EBF398040 for ; Wed, 28 Jun 2006 07:58:29 -0700 (PDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5SEs7nT030654 for ; Wed, 28 Jun 2006 10:54:07 -0400 content-class: urn:content-classes:message Date: Tue, 4 Jul 2006 09:37:11 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reminder - Call for candidates for additional WG co-chair for CAPWAP Thread-Index: Acaaw07oohHHM1g6R8ugIv6M/vCQ/Q== From: "Romascanu, Dan (Dan)" To: "capwap" X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: "Ops-Nm (E-mail)" , ietf@ietf.org Subject: [Capwap] Reminder - Call for candidates for additional WG co-chair for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da This is a reminder that the following call for candidates was issued a few days ago and will expire on July 7, 2006. ------------------------- In order to increase the efficiency of the work in the CAPWAP Working Group (http://www.ietf.org/html.charters/capwap-charter.html), and in order to accelerate the consensus process in the Working Group, the Area Directors decided to create a third co-chair position for the CAPWAP WG. The ADs have decided to write down a brief profile for the WG chair(s). We would like you to consider this profile and either nominate yourself or other people that you think that would fit well in this role by sending mail to the OPS ADs. ( and ). We do not intend to disclose the names of the nominees in public, but we will probably solicit for feedback with various other people. If you have a problem with your name being mentioned in this context, pls let us know. Note that this profile is written for a somewhat ideal candidate. We fully realize that such people are probably non-existent, so don't hesitate to nominate somebody who in your opinion would fit this role quite well but doesn't fit this profile 100%. And the intend is to end with a team of co-chairs that can complement each other and work together. As for the profile: - Good management and process skills, including but not limited to choosing and supervising editors, commitment and follow-through on the charter, active management of the working group discussions, and handling IETF process steps in prompt fashion. - Good basic knowledge of the wireless LAN and IP mobility protocols - Good understanding of requirements, candidate proposals and work-in-progress in CAPWAP - Operational background/experience is very desirable. - Enough available time. For example, preferable not more than one other working chair role in IETF. - There is no requirement that the candidate has been an IETF working group chair before, but it helps if there is some evidence that the candidate can fulfill such a role (e.g.. other management role in other places than IETF etc.) We would like to receive your comments & nominations by July 7th, 2006 and we plan to make a decision as soon as possible thereafter. It will be helpful if you indicate in your nomination mail how you or the nominated candidate fits this profile as best as possible. Dan Romascanu and David Kessens _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 04 09:40:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxl8u-0006TE-65 for capwap-archive@lists.ietf.org; Tue, 04 Jul 2006 09:40:44 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxl8p-0003DE-PM for capwap-archive@lists.ietf.org; Tue, 04 Jul 2006 09:40:44 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B36ED430130 for ; Tue, 4 Jul 2006 06:40:38 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 05346430018 for ; Tue, 4 Jul 2006 06:40:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E41AF39801D for ; Tue, 4 Jul 2006 06:40:19 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.192.81]) by zoidberg.tigertech.net (Postfix) with ESMTP id 048D339801A for ; Tue, 4 Jul 2006 06:40:15 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc11) with ESMTP id <20060704134015m1100at0ple>; Tue, 4 Jul 2006 13:40:15 +0000 Message-ID: <44AA6FBE.7030502@hyperthought.com> Date: Tue, 04 Jul 2006 06:40:14 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: capwap X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [Capwap] opencapwap.org X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hi Everyone, The purpose of this email is to announce a new site: http://opencapwap.org On that site is an open source package which demonstrates one way of integrating openssl into capwap (both wtp and ac), and currently provides a patched version of openssl which supports preshared keys (only provided until the next release of openssl, when this functionality will be generally available). The site explains the project and its goals, so I won't repeat all of that here. The code is in its infancy, so don't expect too much. However, it will continue to grow. Enjoy, Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 04 09:47:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxlFY-0003to-Of for capwap-archive@lists.ietf.org; Tue, 04 Jul 2006 09:47:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxlFY-0004Xi-0E for capwap-archive@lists.ietf.org; Tue, 04 Jul 2006 09:47:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 99AAE4300B7 for ; Tue, 4 Jul 2006 06:47:35 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4EE6443006D for ; Tue, 4 Jul 2006 06:47:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 38125144800F for ; Tue, 4 Jul 2006 06:47:00 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by hermes.tigertech.net (Postfix) with ESMTP id 4FFD3144800A for ; Tue, 4 Jul 2006 06:46:58 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id m51so1673259pye for ; Tue, 04 Jul 2006 06:46:57 -0700 (PDT) Received: by 10.35.45.14 with SMTP id x14mr2193236pyj; Tue, 04 Jul 2006 06:46:57 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Tue, 4 Jul 2006 06:46:56 -0700 (PDT) Message-ID: <26140d940607040646u6fdbdceak14dcc2b4e2952f33@mail.gmail.com> Date: Tue, 4 Jul 2006 09:46:56 -0400 From: "Michael Montemurro" To: "Saravanan Govindan" In-Reply-To: <5F09D220B62F79418461A978CA0921BDFF3A1F@pslexc01.psl.local> MIME-Version: 1.0 References: <5F09D220B62F79418461A978CA0921BDFF3A1F@pslexc01.psl.local> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1859377925==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 --===============1859377925== Content-Type: multipart/alternative; boundary="----=_Part_25566_11175461.1152020816990" ------=_Part_25566_11175461.1152020816990 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Saravanan, So, you would like to request that the WTP generate EAPoL-Key frames for the 4-way handshake and the GTK update? The current draft assumes that all EAPoL-Key frames are generated at the AC. Based on the following assumptions: 1) This feature would be for local-MAC only. 2) The 4-way handshake and the GTK handshake would originate from the same location. This would then require: 1) Negotiation between the WTP and the AC on where the 4-way handshake and GTK updates are generated. 2) A modification to the updateWLAN message element to include the PMK when a STA successfully associates. I've captured this as issue 199. On 7/3/06, Saravanan Govindan wrote: > > Hi Mike, > > > > I had a chance to review the new draft. > > > > With regard to Issue 43, my understanding is that updates were made in > Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add > WLAN message element now allows the AC to send sequence counter values to > the WTP. So now, CAPWAP can support designs where the KeyRSC is maintained > by the AC. > > > > My initial concern was with supporting designs where the KeyRSC is > maintained by the WTP. This is particularly important to manage the 4-Way > and Group-key handshakes. > > > > With this in mind, I think the protocol still requires support for designs > where the KeyRSC is maintained by the WTP. Based on the current draft, this > support can be included by adding another field to the IEEE 802.11 Add > WLAN message element. This field would contain Message-3 EAPoL frame (for > 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). These > EAPoL frames would have unassigned fields for KeyRSC (since the value is > maintained by the WTP). > > > > I am also open to any alternatives to support this. > > > > Cheers, > > > Saravanan > > > > > > > > > ------------------------------ > > *From:* Michael Montemurro [mailto:montemurro.michael@gmail.com] > *Sent:* Tuesday, June 20, 2006 10:01 PM > *To:* Saravanan Govindan > *Cc:* Bob O'Hara (boohara); capwap > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderations > > > > Saravanan, > > > > I've updated section 11.3 to deal with the GTK exchange and the handling > of the KeyRSC in draft -02 to address your comments. I also provided a > mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN > message element as part of the Group Key exchange. > > > > We're finalizing the -02 draft this week and you should be able to look at > it when we post it later this week. > > > > Cheers, > > > > Mike > ------=_Part_25566_11175461.1152020816990 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Saravanan,
 
So, you would like to request that the WTP generate EAPoL-Key frames for the 4-way handshake and the GTK update?
 
The current draft assumes that all EAPoL-Key frames are generated at the AC.
 
Based on the following assumptions:
1) This feature would be for local-MAC only.
2) The 4-way handshake and the GTK handshake would originate from the same location.
 
This would then require:
1) Negotiation between the WTP and the AC on where the 4-way handshake and GTK updates are generated.
2) A modification to the updateWLAN message element to include the PMK when a STA successfully associates.
 
I've captured this as issue 199.

 
On 7/3/06, Saravanan Govindan <Saravanan.Govindan@sg.panasonic.com> wrote:

Hi Mike,

 

I had a chance to review the new draft.

 

With regard to Issue 43, my understanding is that updates were made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN message element now allows the AC to send sequence counter values to the WTP. So now, CAPWAP can support designs where the KeyRSC is maintained by the AC.

 

My initial concern was with supporting designs where the KeyRSC is maintained by the WTP. This is particularly important to manage the 4-Way and Group-key handshakes.

 

With this in mind, I think the protocol still requires support for designs where the KeyRSC is maintained by the WTP. Based on the current draft, this support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames would have unassigned fields for KeyRSC (since the value is maintained by the WTP).

 

I am also open to any alternatives to support this.

 

Cheers,


Saravanan

 

 

 

 

From: Michael Montemurro [mailto: montemurro.michael@gmail.com]
Sent: Tuesday, June 20, 2006 10:01 PM
To: Saravanan Govindan
Cc: Bob O'Hara (boohara); capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations

 

Saravanan,

 

I've updated section 11.3 to deal with the GTK exchange and the handling of the KeyRSC in draft -02 to address your comments. I also provided a mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message element as part of the Group Key exchange.

 

We're finalizing the -02 draft this week and you should be able to look at it when we post it later this week.

 

Cheers,

 

Mike


------=_Part_25566_11175461.1152020816990-- --===============1859377925== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1859377925==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 05 00:26:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxyy9-0000Aj-JK for capwap-archive@lists.ietf.org; Wed, 05 Jul 2006 00:26:33 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxyy8-00028J-6R for capwap-archive@lists.ietf.org; Wed, 05 Jul 2006 00:26:33 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 14B294300CF for ; Tue, 4 Jul 2006 21:26:31 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3EC2143005F for ; Tue, 4 Jul 2006 21:26:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 295341448017 for ; Tue, 4 Jul 2006 21:26:08 -0700 (PDT) X-Greylist-Status: Sender first seen 1 mon 3 days 13:10:24 ago Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by hermes.tigertech.net (Postfix) with ESMTP id 858A21448001 for ; Tue, 4 Jul 2006 21:26:03 -0700 (PDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k654MOZS004906 for ; Wed, 5 Jul 2006 00:22:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 4 Jul 2006 22:25:59 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tentative agenda. Thread-Index: Acaf6x6YLcktHK66TJCWTu/vzGyAxg== X-Priority: 1 Priority: Urgent Importance: high From: "Mani, Mahalingam (Mani)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=X_PRIORITY_HIGH X-Spam-Level: Subject: [Capwap] Tentative agenda. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hi, A tentative (but almost final) agenda has been posted for IETF66: http://www3.ietf.org/proceedings/06jul/agenda/capwap.htm Any other agenda suggestions welcome as well and we will try to accommodate. So far Dorothy Stanley's (IEEE802.11 liaison) presentation has been received and posted. We hope to receive the others' before the sessions. -Chairs _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 05 02:19:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy0jl-0006PT-6V for capwap-archive@lists.ietf.org; Wed, 05 Jul 2006 02:19:49 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy0ji-0005cm-Gg for capwap-archive@lists.ietf.org; Wed, 05 Jul 2006 02:19:49 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 55981430120 for ; Tue, 4 Jul 2006 23:19:45 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E8E0743005F for ; Tue, 4 Jul 2006 23:19:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 994CE1448024 for ; Tue, 4 Jul 2006 23:19:15 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2AB711448023 for ; Tue, 4 Jul 2006 23:19:10 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k656J7PX012901; Tue, 4 Jul 2006 23:19:07 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k656J79W012893; Tue, 4 Jul 2006 23:19:07 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 4 Jul 2006 23:19:06 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Wenhui Zhou In-Reply-To: <00ad01c69f0f$8092fbc0$3605010a@ZHOUWENHUI> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Some question on CAPWAP protocol implementation X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 HI, See answers inline below... On Tue, 4 Jul 2006, Wenhui Zhou wrote: > Dear CAPWAP guys, > > i am sorry i missed much previous related topics, so i have > some questions about CAPWAP protocol implementation. This wasn't a question, but an untrue statement. CAPWAP is a protocol that is in development. There have been development of prototypes of early drafts of the CAPWAP protocol specification, but no compleat developments nor deployments of the latest draft of the protocol specification (that is CAPWAP-02) have been reported. > > 1. Whether it has been decided that LWAPP will be the protocol > implementing CAPWAP? The starting specification for the CAPWAP protocol specification was LWAPP. However, the current CAPWAP specification is "on the wire" different from LWAPP, and the final CAPWAP specification will, I'm guessing be radically different from LWAPP. This is because there are many other good ideas and requirements that are not part of LWAPP, plus the learning that has occured from deployment of LWAPP. I recently saw some cisco literature that said something to the effect that CAPWAP was LWAPP. This is just not the case. CAPWAP is a new protocol that uses a lot of ideas from LWAPP, but is not LWAPP. > 2. Whether all of the traffic of the control plane, management > plane, as well as data plane will be encapsulated in the tunnel > between WTP and the AC by the CAPWAP protocol imple? CAPWAP is in development, and so far all of the control traffic (including mangement - configuration, status, statistics, and event reporting) are via operations usings a protected session that provides data integrety and encryption. The data traffic to and from devices with a wireless interface between a WTP and AC over a protected tunnel. However, CAPWAP supported a local-MAC operation of a WTP where data traffic is not tunneled tbetween a WTP and AC. > 3. Due to the hot and diverse discussions on CAPWAP > protocol implementation here, can some kind of summary > of agreement of CAPWAP protocol implementation > be presented periodically? Wellm just folllow the WG minutes and look for new versions of the CAPWAP protocol specification. NOTE: the ther "implementation" has several meaning. Please be more specific. DO you mean completion of a version of A draft of the CAPWAP protocol specification? Or do you mean writing the code and creating and executabler for a WTP or AC? Or do you mean deployment of a wireless network that uses the CAPWAP protocol? > > thanks. > > Wenhui Zhou > > Regards, /david t. perkins > > ----- Original Message ----- > From: > To: > Sent: Monday, July 03, 2006 6:16 PM > Subject: Capwap Digest, Vol 9, Issue 3 > > > > Send Capwap mailing list submissions to > > capwap@frascone.com > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://lists.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-owner@frascone.com > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Capwap digest..." > > > > > > Today's Topics: > > > > 1. Re: Clarification of Issue 43: IEEE 802.11i Considerations > > (Saravanan Govindan) > > 2. Editorial - WTP Event Request (Saravanan Govindan) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Mon, 3 Jul 2006 13:54:04 +0800 > > From: "Saravanan Govindan" > > Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i > > Considerations > > To: "Michael Montemurro" > > Cc: capwap > > Message-ID: > > <5F09D220B62F79418461A978CA0921BDFF3A1F@pslexc01.psl.local> > > Content-Type: text/plain; charset="us-ascii" > > > > Hi Mike, > > > > > > > > I had a chance to review the new draft. > > > > > > > > With regard to Issue 43, my understanding is that updates were made in > > Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 > > Add WLAN message element now allows the AC to send sequence counter > > values to the WTP. So now, CAPWAP can support designs where the KeyRSC > > is maintained by the AC. > > > > > > > > My initial concern was with supporting designs where the KeyRSC is > > maintained by the WTP. This is particularly important to manage the > > 4-Way and Group-key handshakes. > > > > > > > > With this in mind, I think the protocol still requires support for > > designs where the KeyRSC is maintained by the WTP. Based on the current > > draft, this support can be included by adding another field to the IEEE > > 802.11 Add WLAN message element. This field would contain Message-3 > > EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for > > Group-key handshake). These EAPoL frames would have unassigned fields > > for KeyRSC (since the value is maintained by the WTP). > > > > > > > > I am also open to any alternatives to support this. > > > > > > > > Cheers, > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > From: Michael Montemurro [mailto:montemurro.michael@gmail.com] > > Sent: Tuesday, June 20, 2006 10:01 PM > > To: Saravanan Govindan > > Cc: Bob O'Hara (boohara); capwap > > Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i > > Considerations > > > > > > > > Saravanan, > > > > > > > > I've updated section 11.3 to deal with the GTK exchange and the handling > > of the KeyRSC in draft -02 to address your comments. I also provided a > > mechanism for the AC to transmit the keyRSC to the WTP using the > > updateWLAN message element as part of the Group Key exchange. > > > > > > > > We're finalizing the -02 draft this week and you should be able to look > > at it when we post it later this week. > > > > > > > > Cheers, > > > > > > > > Mike > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: http://lists.frascone.com/pipermail/capwap/attachments/20060703/7806c36e/attachment.htm > > > > ------------------------------ > > > > Message: 2 > > Date: Mon, 3 Jul 2006 15:02:10 +0800 > > From: "Saravanan Govindan" > > Subject: [Capwap] Editorial - WTP Event Request > > To: "capwap" > > Message-ID: > > <5F09D220B62F79418461A978CA0921BDFF3A40@pslexc01.psl.local> > > Content-Type: text/plain; charset="us-ascii" > > > > All, > > > > > > > > I would like to suggest an editorial update to Section 9.5 (WTP Event > > Request). > > > > > > > > This is based on earlier discussions of how WTP Event Request serves as > > an implicit keep alive mechanism for the WTP. I believe this observation > > can be made explicit in this section. > > > > > > > > I suggest the following after the 1st paragraph of Section 9.5; > > > > > > > > "The exchange of WTP Event Request serves as an implicit keep alive > > mechanism for the WTP. The arrival of a WTP Event Request message at the > > AC indicates the WTP is operational. In cases where WTP Event Request is > > not exchanged, explicit keep alive is used (see Section 7)." > > > > > > > > The current text in Section 7 refers to maintaining the control > > communication channel, whereas the suggestion above refers to the WTP as > > a whole. > > > > > > > > Comments? > > > > > > > > Saravanan > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: http://lists.frascone.com/pipermail/capwap/attachments/20060703/b987e7b1/attachment.htm > > > > ------------------------------ > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > End of Capwap Digest, Vol 9, Issue 3 > > ************************************ > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 05 02:41:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy14c-0006eK-9U for capwap-archive@lists.ietf.org; Wed, 05 Jul 2006 02:41:22 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy14Z-0006YB-Qv for capwap-archive@lists.ietf.org; Wed, 05 Jul 2006 02:41:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 784234300F5 for ; Tue, 4 Jul 2006 23:41:19 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 84B4D43005F for ; Tue, 4 Jul 2006 23:40:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 669651448009 for ; Tue, 4 Jul 2006 23:40:56 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id BF3B61448007 for ; Tue, 4 Jul 2006 23:40:53 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k656eo1o016638; Tue, 4 Jul 2006 23:40:50 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k656eno3016635; Tue, 4 Jul 2006 23:40:50 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 4 Jul 2006 23:40:49 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Mani, Mahalingam (Mani)" In-Reply-To: Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Tentative agenda. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 HI, I believe the current agenda is inappropriate. There is no need to provide reports at IETF WG meetings. Such reports should be just sent to the WG mailing list. The WG meeting should be only used to try to gain common understanding, and then resolution of contentious issues from the mailing list. What are the contentious issues? 1) Using the same DTLS session for both data and control trafffic 2) The format of CAPWAP control messages 3) THe format of CAPWAP data messages 4) The CAPWAP state machine 5) The details of CAPWAP message fragmentation 6) The details of retries of CAPWAP control messages 7) Details for image transfer 6) Details for discovery, and then join, then WTP capability and initial WTP configuration etc. And esspecially, whether or not the CAPWAP WP should be disbanded, or continued? Why disbanned? Because there does not appear to be enough interest in creating a specification that will have code written that supports it, and have interoperability testing performed on it. Regards, /david t. perkins On Tue, 4 Jul 2006, Mani, Mahalingam (Mani) wrote: > Hi, > > A tentative (but almost final) agenda has been posted for IETF66: > > http://www3.ietf.org/proceedings/06jul/agenda/capwap.htm > > Any other agenda suggestions welcome as well and we will try to > accommodate. > > So far Dorothy Stanley's (IEEE802.11 liaison) presentation has been > received and posted. We hope to receive the others' before the sessions. > > -Chairs > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 05 08:10:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy6D3-0005Hv-Fz for capwap-archive@lists.ietf.org; Wed, 05 Jul 2006 08:10:25 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy6D1-0007Gs-2H for capwap-archive@lists.ietf.org; Wed, 05 Jul 2006 08:10:25 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 02DB9430134 for ; Wed, 5 Jul 2006 05:10:22 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 390DD430059 for ; Wed, 5 Jul 2006 05:09:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1B99B430BCE for ; Wed, 5 Jul 2006 05:09:58 -0700 (PDT) X-Greylist-Status: Sender first seen 23 days 23:23:34 ago Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by hermes.tigertech.net (Postfix) with ESMTP id 54883430BDE for ; Wed, 5 Jul 2006 05:09:53 -0700 (PDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k65C549L006357 for ; Wed, 5 Jul 2006 08:05:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Jul 2006 15:09:51 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-netlmm-nohost-ps-04.txt on the IESG agenda Thread-Index: AcagK+rP4gSD2iQGTseFDgAkOF7VyQ== From: "Romascanu, Dan (Dan)" To: "capwap" X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [Capwap] draft-ietf-netlmm-nohost-ps-04.txt on the IESG agenda X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a I apologize for the short notice, but I believe that the following document for approval as Informational RFC on the agenda of the IESG telechat on 7/5 may be of interest for capwap. INT Problem Statement for Network-based Localized Mobility Management (Informational) draft-ietf-netlmm-nohost-ps-04.txt The document can be found at http://www.ietf.org/internet-drafts/draft-ietf-netlmm-nohost-ps-04.txt. Please let me know until tomorrow morning if there are any questions or concerns. Thanks and Regards, Dan _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 05 11:05:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy8wW-0005LO-RI for capwap-archive@lists.ietf.org; Wed, 05 Jul 2006 11:05:32 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy8wV-0002mZ-EB for capwap-archive@lists.ietf.org; Wed, 05 Jul 2006 11:05:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D8433430120 for ; Wed, 5 Jul 2006 08:05:30 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EB866430059 for ; Wed, 5 Jul 2006 08:05:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C7216430E65 for ; Wed, 5 Jul 2006 08:05:01 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id DD57A430E62 for ; Wed, 5 Jul 2006 08:04:57 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k65F4sO3011017; Wed, 5 Jul 2006 08:04:54 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k65F4rl0011014; Wed, 5 Jul 2006 08:04:53 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 5 Jul 2006 08:04:53 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: zhaoyujin 31390 In-Reply-To: Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap@frascone.com, Wenhui Zhou Subject: Re: [Capwap] =?gb2312?B?u9i4tA==?=:Re: Some question on CAPWAP protocol implementation X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1465971156==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 --===============1465971156== Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE HI, I believe that you have made an incorrect characterizing of CAPWAP. See below. On Wed, 5 Jul 2006, zhaoyujin 31390 wrote: > =B7=A2=BC=FE=C8=CB: Wenhui Zhou > =C8=D5=C6=DA: =D0=C7=C6=DA=B6=FE, =C6=DF=D4=C2 4=C8=D5, 2006 =C9=CF=CE=E7= 7:43 > =D6=F7=CC=E2: Re: [Capwap] Some question on CAPWAP protocol implementatio= n >=20 > >=20 > > Dear CAPWAP guys, > >=20 > > i am sorry i missed much previous related topics, so i have some=20 > > questions about CAPWAP protocol implementation. > >=20 > > 1. Whether it has been decided that LWAPP will be the protocol=20 > > implementing CAPWAP? > // This has been decided. And current the LWAPP protocol has > changed name to CAPWAP. This IS NOT a correct characterization of CAPWAP. CAPWAP IS NOT LWAPP with a different name! > > 2. Whether all of the traffic of the control plane, management=20 > > plane, as well as data plane will be encapsulated in the tunnel=20 > > between WTP and the AC by the CAPWAP protocol imple? > //CAPWAP defines itself control tunnel and data tunnel. > Presently it does not support third part data tunnel. >=20 > > 3. Due to the hot and diverse discussions on CAPWAP protocol=20 > > implementation here, can some kind of summary of agreement of=20 > > CAPWAP protocol implementation be presented periodically? >=20 > > thanks. > >=20 > > Wenhui Zhou > >=20 --===============1465971156== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1465971156==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 05 11:48:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9cK-0006q8-78 for capwap-archive@lists.ietf.org; Wed, 05 Jul 2006 11:48:44 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy8xk-0002nj-3H for capwap-archive@lists.ietf.org; Wed, 05 Jul 2006 11:06:48 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fy8lO-0002b0-1n for capwap-archive@lists.ietf.org; Wed, 05 Jul 2006 10:54:04 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7381D430139 for ; Wed, 5 Jul 2006 07:53:52 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 54712430059 for ; Wed, 5 Jul 2006 07:53:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 48426398045 for ; Wed, 5 Jul 2006 07:53:19 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [12.129.211.51]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0747D398037 for ; Wed, 5 Jul 2006 07:53:07 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1X00BMOQJ5FL@usaga01-in.huawei.com> for capwap@frascone.com; Wed, 05 Jul 2006 07:49:54 -0700 (PDT) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1X00EQ5QJ3ZZ@usaga01-in.huawei.com> for capwap@frascone.com; Wed, 05 Jul 2006 07:49:53 -0700 (PDT) Received: from [172.24.1.24] (Forwarded-For: [10.18.7.115]) by szxmc01-in.huawei.com (mshttpd); Wed, 05 Jul 2006 19:53:02 +0500 Date: Wed, 05 Jul 2006 19:53:02 +0500 From: zhaoyujin 31390 To: Wenhui Zhou Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: [Capwap] =?gb2312?B?u9i4tA==?=:Re: Some question on CAPWAP protocol implementation X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0278221557==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 4a4195ffb11c7b0baf82f77b2a730aa9 --===============0278221557== Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline *************************************************************************= ***************** This email and its attachments contain confidential information from HUA= WEI=2C which is intended only for the person or entity whose address is l= isted above=2E Any use of the information contained herein in any way (in= cluding=2C but not limited to=2C total or partial disclosure=2C reproduct= ion=2C or dissemination) by persons other than the intended recipient(s) = is prohibited=2E If you receive this e-mail in error=2C please notify the= sender by phone or em ail immediately and delete it! ************************************************************************= ***************** ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Wenhui Zhou =3Czhouwenhui=40chinamobile=2Ecom=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=B6=FE=2C =C6=DF=D4=C2 4=C8=D5=2C 2006 =C9=CF= =CE=E77=3A43 =D6=F7=CC=E2=3A Re=3A =5BCapwap=5D Some question on CAPWAP protocol imple= mentation =3E = =3E Dear CAPWAP guys=2C =3E = =3E i am sorry i missed much previous related topics=2C so i have some = =3E questions about CAPWAP protocol implementation=2E =3E = =3E 1=2E Whether it has been decided that LWAPP will be the protocol = =3E implementing CAPWAP=3F // This has been decided=2E And current the LWAPP protocol has changed na= me to CAPWAP=2E =3E 2=2E Whether all of the traffic of the control plane=2C management = =3E plane=2C as well as data plane will be encapsulated in the tunnel = =3E between WTP and the AC by the CAPWAP protocol imple=3F //CAPWAP defines itself control tunnel and data tunnel=2E Presently it do= es not support third part data tunnel=2E =3E 3=2E Due to the hot and diverse discussions on CAPWAP protocol = =3E implementation here=2C can some kind of summary of agreement of = =3E CAPWAP protocol implementation be presented periodically=3F =3E = =3E thanks=2E =3E = =3E Wenhui Zhou =3E = =3E = =3E = =3E ----- Original Message ----- = =3E From=3A =3Ccapwap-request=40frascone=2Ecom=3E =3E To=3A =3Ccapwap=40frascone=2Ecom=3E =3E Sent=3A Monday=2C July 03=2C 2006 6=3A16 PM =3E Subject=3A Capwap Digest=2C Vol 9=2C Issue 3 =3E = =3E = =3E =3E Send Capwap mailing list submissions to =3E =3E capwap=40frascone=2Ecom =3E =3E = =3E =3E To subscribe or unsubscribe via the World Wide Web=2C visit =3E =3E http=3A//lists=2Efrascone=2Ecom/mailman/listinfo/capwap =3E =3E or=2C via email=2C send a message with subject or body =27help=27= to =3E =3E capwap-request=40frascone=2Ecom =3E =3E = =3E =3E You can reach the person managing the list at =3E =3E capwap-owner=40frascone=2Ecom =3E =3E = =3E =3E When replying=2C please edit your Subject line so it is more spec= ific =3E =3E than =22Re=3A Contents of Capwap digest=2E=2E=2E=22 =3E =3E = =3E =3E = =3E =3E Today=27s Topics=3A =3E =3E = =3E =3E 1=2E Re=3A Clarification of Issue 43=3A IEEE 802=2E11i Consider= ations =3E =3E (Saravanan Govindan) =3E =3E 2=2E Editorial - WTP Event Request (Saravanan Govindan) =3E =3E = =3E =3E = =3E =3E -----------------------------------------------------------------= =3E ----- =3E =3E = =3E =3E Message=3A 1 =3E =3E Date=3A Mon=2C 3 Jul 2006 13=3A54=3A04 +0800 =3E =3E From=3A =22Saravanan Govindan=22 =3CSaravanan=2EGovindan=40sg=2Ep= anasonic=2Ecom=3E =3E =3E Subject=3A Re=3A =5BCapwap=5D Clarification of Issue 43=3A IEEE 8= 02=2E11i =3E =3E Considerations =3E =3E To=3A =22Michael Montemurro=22 =3Cmontemurro=2Emichael=40gmail=2E= com=3E =3E =3E Cc=3A capwap =3Ccapwap=40frascone=2Ecom=3E =3E =3E Message-ID=3A =3E =3E =3C5F09D220B62F79418461A978CA0921BDFF3A1F=40pslexc01=2Epsl=2Eloca= l=3E =3E =3E Content-Type=3A text/plain=3B charset=3D=22us-ascii=22 =3E =3E = =3E =3E Hi Mike=2C =3E =3E = =3E =3E = =3E =3E = =3E =3E I had a chance to review the new draft=2E = =3E =3E = =3E =3E = =3E =3E = =3E =3E With regard to Issue 43=2C my understanding is that updates were = =3E made in =3E =3E Section 11=2E9=2E1 (IEEE 802=2E11 Add WLAN)=2E In particular=2C t= he IEEE = =3E 802=2E11=3E Add WLAN message element now allows the AC to send = =3E sequence counter =3E =3E values to the WTP=2E So now=2C CAPWAP can support designs where t= he = =3E KeyRSC=3E is maintained by the AC=2E = =3E =3E = =3E =3E = =3E =3E = =3E =3E My initial concern was with supporting designs where the KeyRSC i= s =3E =3E maintained by the WTP=2E This is particularly important to manage= the =3E =3E 4-Way and Group-key handshakes=2E = =3E =3E = =3E =3E = =3E =3E = =3E =3E With this in mind=2C I think the protocol still requires support = for =3E =3E designs where the KeyRSC is maintained by the WTP=2E Based on the= = =3E current=3E draft=2C this support can be included by adding another = =3E field to the IEEE =3E =3E 802=2E11 Add WLAN message element=2E This field would contain = =3E Message-3 =3E =3E EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for =3E =3E Group-key handshake)=2E These EAPoL frames would have unassigned = =3E fields=3E for KeyRSC (since the value is maintained by the WTP)=2E = =3E =3E = =3E =3E = =3E =3E = =3E =3E I am also open to any alternatives to support this=2E = =3E =3E = =3E =3E = =3E =3E = =3E =3E Cheers=2C =3E =3E = =3E =3E = =3E =3E Saravanan =3E =3E = =3E =3E = =3E =3E = =3E =3E = =3E =3E = =3E =3E = =3E =3E = =3E =3E = =3E =3E = =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E =3E = =3E =3E From=3A Michael Montemurro =5Bmontemurro=2Emichael=40gmail=2Ecom=5D= = =3E =3E Sent=3A Tuesday=2C June 20=2C 2006 10=3A01 PM =3E =3E To=3A Saravanan Govindan =3E =3E Cc=3A Bob O=27Hara (boohara)=3B capwap =3E =3E Subject=3A Re=3A =5BCapwap=5D Clarification of Issue 43=3A IEEE 8= 02=2E11i =3E =3E Considerations =3E =3E = =3E =3E = =3E =3E = =3E =3E Saravanan=2C =3E =3E = =3E =3E = =3E =3E = =3E =3E I=27ve updated section 11=2E3 to deal with the GTK exchange and t= he = =3E handling=3E of the KeyRSC in draft -02 to address your comments=2E I = =3E also provided a =3E =3E mechanism for the AC to transmit the keyRSC to the WTP using the =3E =3E updateWLAN message element as part of the Group Key exchange=2E = =3E =3E = =3E =3E = =3E =3E = =3E =3E We=27re finalizing the -02 draft this week and you should be able= = =3E to look =3E =3E at it when we post it later this week=2E =3E =3E = =3E =3E = =3E =3E = =3E =3E Cheers=2C =3E =3E = =3E =3E = =3E =3E = =3E =3E Mike =3E =3E = =3E =3E -------------- next part -------------- =3E =3E An HTML attachment was scrubbed=2E=2E=2E =3E =3E URL=3A = =3E http=3A//lists=2Efrascone=2Ecom/pipermail/capwap/attachments/20060703= /7806c36e/attachment=2Ehtm = =3E =3E = =3E =3E ------------------------------ =3E =3E = =3E =3E Message=3A 2 =3E =3E Date=3A Mon=2C 3 Jul 2006 15=3A02=3A10 +0800 =3E =3E From=3A =22Saravanan Govindan=22 =3CSaravanan=2EGovindan=40sg=2Ep= anasonic=2Ecom=3E =3E =3E Subject=3A =5BCapwap=5D Editorial - WTP Event Request =3E =3E To=3A =22capwap=22 =3Ccapwap=40frascone=2Ecom=3E =3E =3E Message-ID=3A =3E =3E =3C5F09D220B62F79418461A978CA0921BDFF3A40=40pslexc01=2Epsl=2Eloca= l=3E =3E =3E Content-Type=3A text/plain=3B charset=3D=22us-ascii=22 =3E =3E = =3E =3E All=2C =3E =3E = =3E =3E = =3E =3E = =3E =3E I would like to suggest an editorial update to Section 9=2E5 (WTP= = =3E Event=3E Request)=2E = =3E =3E = =3E =3E = =3E =3E = =3E =3E This is based on earlier discussions of how WTP Event Request = =3E serves as =3E =3E an implicit keep alive mechanism for the WTP=2E I believe this = =3E observation=3E can be made explicit in this section=2E =3E =3E = =3E =3E = =3E =3E = =3E =3E I suggest the following after the 1st paragraph of Section 9=2E5=3B= =3E =3E = =3E =3E = =3E =3E = =3E =3E =22The exchange of WTP Event Request serves as an implicit keep a= live =3E =3E mechanism for the WTP=2E The arrival of a WTP Event Request = =3E message at the =3E =3E AC indicates the WTP is operational=2E In cases where WTP Event = =3E Request is =3E =3E not exchanged=2C explicit keep alive is used (see Section 7)=2E=22= =3E =3E = =3E =3E = =3E =3E = =3E =3E The current text in Section 7 refers to maintaining the control =3E =3E communication channel=2C whereas the suggestion above refers to = =3E the WTP as =3E =3E a whole=2E = =3E =3E = =3E =3E = =3E =3E = =3E =3E Comments=3F =3E =3E = =3E =3E = =3E =3E = =3E =3E Saravanan =3E =3E = =3E =3E -------------- next part -------------- =3E =3E An HTML attachment was scrubbed=2E=2E=2E =3E =3E URL=3A = =3E http=3A//lists=2Efrascone=2Ecom/pipermail/capwap/attachments/20060703= /b987e7b1/attachment=2Ehtm = =3E =3E = =3E =3E ------------------------------ =3E =3E = =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E =3E To unsubscribe or modify your subscription options=2C please visi= t=3A =3E =3E http=3A//lists=2Efrascone=2Ecom/mailman/listinfo/capwap =3E =3E = =3E =3E Archives=3A http=3A//lists=2Efrascone=2Ecom/pipermail/capwap =3E =3E = =3E =3E End of Capwap Digest=2C Vol 9=2C Issue 3 =3E =3E ************************************ =3E =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E To unsubscribe or modify your subscription options=2C please visit=3A= =3E http=3A//lists=2Efrascone=2Ecom/mailman/listinfo/capwap =3E = =3E Archives=3A http=3A//lists=2Efrascone=2Ecom/pipermail/capwap =3E --===============0278221557== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0278221557==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 05 13:04:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyAnn-0005GR-Rp for capwap-archive@lists.ietf.org; Wed, 05 Jul 2006 13:04:39 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy8xZ-0002nj-QN for capwap-archive@lists.ietf.org; Wed, 05 Jul 2006 11:06:37 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fy8tB-0002lx-9M for capwap-archive@lists.ietf.org; Wed, 05 Jul 2006 11:02:07 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5E3A1430160 for ; Wed, 5 Jul 2006 08:02:04 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 8C91C430059 for ; Wed, 5 Jul 2006 08:01:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3160239800B for ; Wed, 5 Jul 2006 08:01:38 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [12.129.211.51]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8F84539800E for ; Wed, 5 Jul 2006 08:01:35 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1X00BOFQXEFL@usaga01-in.huawei.com> for capwap@frascone.com; Wed, 05 Jul 2006 07:58:26 -0700 (PDT) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1X00EKGQXCZZ@usaga01-in.huawei.com> for capwap@frascone.com; Wed, 05 Jul 2006 07:58:26 -0700 (PDT) Received: from [172.24.1.24] (Forwarded-For: [10.18.7.115]) by szxmc01-in.huawei.com (mshttpd); Wed, 05 Jul 2006 20:01:35 +0500 Date: Wed, 05 Jul 2006 20:01:35 +0500 From: zhaoyujin 31390 To: "Mani, Mahalingam (Mani)" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: [Capwap] =?gb2312?B?u9i4tA==?=:Re: Keepalive on data channel X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1748413407==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba --===============1748413407== Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline Dear all=3A Frankly=2C I think if data tunnel need keepalive should be discussed=2E= = Normally=2C our Capwap data tunnel will be controlled to create or dele= te by control tunnel=2C so that data tunnel keepalive may be repeated=2E = And this will affect the performance of data transmission=2E But for NAT Traversal=2C maybe CAPWAP can send one no-used packet to ma= intain the NAT entry for capwap data tunnel=2E But before this=2C capwap = need decide which device is inside of NAT with control tunnel=2E Best regards Michael = ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A =22Mani=2C Mahalingam (Mani)=22 =3Cmmani=40avaya=2E= com=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=C8=FD=2C =C1=F9=D4=C2 28=C8=D5=2C 2006 =C9=CF= =CE=E710=3A02 =D6=F7=CC=E2=3A Re=3A =5BCapwap=5D Keepalive on data channel =3E Pat=2C =3E = =3E The relevance of the =27Then=27 preceding the recommendation is not c= lear=2E =3E = =3E This is merely an observation of the implication of the behavior = =3E on this =3E given network policy instance=2E We expect the relevant areas to resp= ond =3E when ADs take this up with them=2E =3E = =3E -mani =3E -----Original Message----- =3E From=3A Pat Calhoun (pacalhou) =5Bpcalhoun=40cisco=2Ecom=5D = =3E Sent=3A Monday=2C June 26=2C 2006 6=3A27 PM =3E To=3A Mani=2C Mahalingam (Mani)=3B capwap=40frascone=2Ecom =3E Subject=3A RE=3A =5BCapwap=5D Keepalive on data channel =3E = =3E Mani=2C =3E = =3E Then I would recommend that you include folks from the Internet = =3E Area in =3E your discussions=2C as they have a number of tunneling standards effo= rts =3E underway=2C as well as operational experience=2E =3E = =3E Pat Calhoun =3E CTO=2C Wireless Networking Business Unit =3E Cisco Systems =3E = =3E = =3E = =3E =3E -----Original Message----- =3E =3E From=3A Mani=2C Mahalingam (Mani) =5Bmmani=40avaya=2Ecom=5D = =3E =3E Sent=3A Monday=2C June 26=2C 2006 5=3A22 PM =3E =3E To=3A Pat Calhoun (pacalhou)=3B capwap=40frascone=2Ecom =3E =3E Subject=3A RE=3A =5BCapwap=5D Keepalive on data channel =3E =3E = =3E =3E It appears that in such a network - all flows marked for DSCP = =3E =3E -based QoS are at a diagnostic peril - each of a different = =3E =3E kind - in such a failure scenario=2E =3E =3E = =3E =3E -mani =3E =3E -----Original Message----- =3E =3E From=3A Pat Calhoun (pacalhou) =5Bpcalhoun=40cisco=2Ecom=5D =3E =3E Sent=3A Monday=2C June 26=2C 2006 7=3A09 AM =3E =3E To=3A capwap=40frascone=2Ecom =3E =3E Subject=3A =5BCapwap=5D Keepalive on data channel =3E =3E = =3E =3E All=2C =3E =3E = =3E =3E In a conversation with some of the L2TP folks=2C they have = =3E =3E experience an operational problem that we need to keep in = =3E =3E mind=2E Basically=2C they multiplex their control and data frames= = =3E =3E through their own header=2C and mark their packets priorities = =3E =3E based on control vs=2E data=2E =3E =3E = =3E =3E What they have found is that networks do route path selection = =3E =3E based on DSCP/ToS values=2C meaning that they send higher = =3E =3E priority (control) frames over different links than data = =3E =3E frames=2E The network is not designed to perform this solely = =3E =3E for L2TP=2C as this is something they do for all of their = =3E =3E applications=2E The issue is that their protocol relies on a = =3E =3E keepalive frame that runs over the control channel=2C = =3E =3E identically to CAPWAP=2E However=2C the operational issue that = =3E =3E they=27ve found is that if the path taken by the data channel = =3E =3E is broken=2C and these frames are never delivered=2E =3E =3E = =3E =3E The L2TP folks have found that the lack of a keepalive = =3E =3E mechanism makes it impossible to diagnose such an issue=2E When = =3E =3E it occurs=2C the administrator first has to figure out it is = =3E =3E occurring=2C because the protocol does not=2C and then needs to = =3E =3E manually follow the path to find the failure=2E =3E =3E = =3E =3E As far as I can tell=2C Scott=27s two primary issues with not = =3E =3E wanting to support UDP ports were=3A =3E =3E 1=2E NAT Traversal will require a keepalive on the data = =3E =3E channel=2E As noted above=2C we need to add a keepalive on the = =3E =3E data channel in order to be able to detect network routing failur= es=2E =3E =3E 2=2E Modifications to the state machine to handle data channel = =3E failure=2E=3E Given that such failures can occur=2C we need to be abl= e = =3E to = =3E =3E recover=2C if possible=2E =3E =3E = =3E =3E I wanted to raise these issues as they are real=2C and actually = =3E =3E experienced in L2TP deployments=2E I believe we need to address = =3E =3E these=2C and if so=2C then I believe the complexity associated = =3E =3E with the dual UDP port ends up being resolved=2E =3E =3E = =3E =3E Pat Calhoun =3E =3E CTO=2C Wireless Networking Business Unit =3E =3E Cisco Systems =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E =3E To unsubscribe or modify your subscription options=2C please visi= t=3A =3E =3E http=3A//lists=2Efrascone=2Ecom/mailman/listinfo/capwap =3E =3E = =3E =3E Archives=3A http=3A//lists=2Efrascone=2Ecom/pipermail/capwap =3E =3E = =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E To unsubscribe or modify your subscription options=2C please visit=3A= =3E http=3A//lists=2Efrascone=2Ecom/mailman/listinfo/capwap =3E = =3E Archives=3A http=3A//lists=2Efrascone=2Ecom/pipermail/capwap =3E --===============1748413407== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1748413407==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 05 13:35:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyBHf-0000GU-9X for capwap-archive@lists.ietf.org; Wed, 05 Jul 2006 13:35:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyBHd-00056K-Fl for capwap-archive@lists.ietf.org; Wed, 05 Jul 2006 13:35:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C050A43013B for ; Wed, 5 Jul 2006 10:35:27 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 980CA430085 for ; Wed, 5 Jul 2006 10:34:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 73C40144802C for ; Wed, 5 Jul 2006 10:34:58 -0700 (PDT) Received: from web60322.mail.yahoo.com (web60322.mail.yahoo.com [209.73.178.130]) by hermes.tigertech.net (Postfix) with SMTP id 1C0A11448038 for ; Wed, 5 Jul 2006 10:34:53 -0700 (PDT) Received: (qmail 34064 invoked by uid 60001); 5 Jul 2006 17:34:52 -0000 Message-ID: <20060705173452.34062.qmail@web60322.mail.yahoo.com> Received: from [12.129.211.52] by web60322.mail.yahoo.com via HTTP; Wed, 05 Jul 2006 10:34:52 PDT Date: Wed, 5 Jul 2006 10:34:52 -0700 (PDT) From: Behcet Sarikaya To: "David T. Perkins" , zhaoyujin 31390 In-Reply-To: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_WHOIS, HTML_20_30, HTML_MESSAGE X-Spam-Level: * Cc: capwap@frascone.com, Wenhui Zhou Subject: Re: [Capwap] =?utf-8?b?5Zue5aSNOlJlOiBTb21lIHF1ZXN0aW9uIG9uIENBUFdB?= =?utf-8?q?P_protocol_implementation?= X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Behcet Sarikaya List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1427022127==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b --===============1427022127== Content-Type: multipart/alternative; boundary="0-1810177982-1152120892=:33023" --0-1810177982-1152120892=:33023 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ----- Original Message ---- From: David T. Perkins To: zhaoyujin 31390 Cc: capwap@frascone.com; Wenhui Zhou Sent: Wednesday, July 5, 2006 10:04:53 AM Subject: Re: [Capwap] =E5=9B=9E=E5=A4=8D:Re: Some question on CAPWAP protoc= ol implementation HI, I believe that you have made an incorrect characterizing of CAPWAP. See below. On Wed, 5 Jul 2006, zhaoyujin 31390 wrote: > =C2=B7=C2=A2=C2=BC=C3=BE=C3=88=C3=8B: Wenhui Zhou > =C3=88=C3=95=C3=86=C3=9A: =C3=90=C3=87=C3=86=C3=9A=C2=B6=C3=BE, =C3=86=C3= =9F=C3=94=C3=82 4=C3=88=C3=95, 2006 =C3=89=C3=8F=C3=8E=C3=A77:43 > =C3=96=C3=B7=C3=8C=C3=A2: Re: [Capwap] Some question on CAPWAP protocol i= mplementation >=20 > >=20 > > Dear CAPWAP guys, > >=20 > > i am sorry i missed much previous related topics, so i have some=20 > > questions about CAPWAP protocol implementation. > >=20 > > 1. Whether it has been decided that LWAPP will be the protocol=20 > > implementing CAPWAP? > // This has been decided. And current the LWAPP protocol has > changed name to CAPWAP. This IS NOT a correct characterization of CAPWAP. CAPWAP IS NOT LWAPP with a different name! =3D=3D> I think the correct wording would be CAPWAP is LWAPP with changes s= uggested by the eval team report RFC 4565. Security (incorporation of DTLS = replacing LWAPP-specific technique) has been the place for most changes. In= other places, the changes have been mostly editorial. Regards, --behcet --0-1810177982-1152120892=:33023 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


----- Original Message ----
From:= David T. Perkins <dperkins@dsperkins.com>
To: zhaoyujin 31390 <= ;zhaoyujin@huawei.com>
Cc: capwap@frascone.com; Wenhui Zhou <zhouw= enhui@chinamobile.com>
Sent: Wednesday, July 5, 2006 10:04:53 AM
S= ubject: Re: [Capwap] =E5=9B=9E=E5=A4=8D:Re: Some question on CAPWAP protoco= l implementation

HI,

I believe that you have made an inc= orrect characterizing of
CAPWAP. See below.

On Wed, 5 Jul 2006, z= haoyujin 31390 wrote:
> =C2=B7=C2=A2=C2=BC=C3=BE=C3=88=C3=8B: Wenhui = Zhou <zhouwenhui@chinamobile.com>
> =C3=88=C3=95=C3=86=C3=9A: = =C3=90=C3=87=C3=86=C3=9A=C2=B6=C3=BE, =C3=86=C3=9F=C3=94=C3=82 4=C3=88=C3= =95, 2006 =C3=89=C3=8F=C3=8E=C3=A77:43
> =C3=96=C3=B7=C3=8C=C3=A2: Re= : [Capwap] Some question on CAPWAP protocol implementation
>
> = >
> > Dear CAPWAP guys,
> >
> > i am sorry = i missed much previous related topics, so i have some
> > questio= ns about CAPWAP protocol implementation.
> >
> > 1. Whet= her it has been decided that LWAPP will be the protocol
> > imple= menting CAPWAP?
> // This has been decided. And current the LWAPP pro= tocol has
> changed name to CAPWAP.
This IS NOT a correct characte= rization of CAPWAP. CAPWAP IS NOT
LWAPP with a different name!
=3D=3D= > I think the correct wording would be CAPWAP is LWAPP with changes sugg= ested by the eval team report RFC 4565. Security (incorporation of DTLS rep= lacing LWAPP-specific technique) has been the place for most changes. In ot= her places, the changes have been mostly editorial.

Regards,

= --behcet

--0-1810177982-1152120892=:33023-- --===============1427022127== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1427022127==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 05 13:48:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyBUK-0000uW-8h for capwap-archive@lists.ietf.org; Wed, 05 Jul 2006 13:48:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyBUI-0006fI-OL for capwap-archive@lists.ietf.org; Wed, 05 Jul 2006 13:48:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5656A4300FA for ; Wed, 5 Jul 2006 10:48:34 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B505343005F for ; Wed, 5 Jul 2006 10:48:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9C03F144802A for ; Wed, 5 Jul 2006 10:48:10 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [12.129.211.51]) by hermes.tigertech.net (Postfix) with ESMTP id 44D74144801A for ; Wed, 5 Jul 2006 10:48:07 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1X00924YMY96@usaga01-in.huawei.com> for capwap@frascone.com; Wed, 05 Jul 2006 10:44:58 -0700 (PDT) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1X00004YMWWD@usaga01-in.huawei.com> for capwap@frascone.com; Wed, 05 Jul 2006 10:44:58 -0700 (PDT) Received: from [172.24.1.24] (Forwarded-For: [10.18.7.115]) by szxmc01-in.huawei.com (mshttpd); Wed, 05 Jul 2006 22:48:06 +0500 Date: Wed, 05 Jul 2006 22:48:06 +0500 From: zhaoyujin 31390 To: Behcet Sarikaya Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap@frascone.com, Wenhui Zhou Subject: [Capwap] =?gb2312?B?u9i4tA==?=:Re: =?gb2312?B?u9i4tA==?=:Re: Some question on CAPWAP protocol implementation X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0100369475==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede --===============0100369475== Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline Dear all=3A I am sorry for my misunderstand about LWAPP and CAPWAP=2E = I said =22And current the LWAPP protocol has changed name to CAPWAP=22=2C= only because I think current capwap draft is from the LWAPP draft=2E And= I also CAPWAP has added and changed many features comparing with LWAPP=2E= OK! It is my mistake=2E = = Best regards Michael ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Behcet Sarikaya =3Cbehcetsarikaya=40yahoo=2Ecom=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=C8=FD=2C =C6=DF=D4=C2 5=C8=D5=2C 2006 =CF=C2= =CE=E711=3A04 =D6=F7=CC=E2=3A Re=3A =5BCapwap=5D =BB=D8=B8=B4=3ARe=3A Some question on = CAPWAP protocol implementation =3E = =3E = =3E ----- Original Message ---- =3E From=3A David T=2E Perkins =3Cdperkins=40dsperkins=2Ecom=3E =3E To=3A zhaoyujin 31390 =3Czhaoyujin=40huawei=2Ecom=3E =3E Cc=3A capwap=40frascone=2Ecom=3B Wenhui Zhou =3Czhouwenhui=40chinamob= ile=2Ecom=3E =3E Sent=3A Wednesday=2C July 5=2C 2006 10=3A04=3A53 AM =3E Subject=3A Re=3A =5BCapwap=5D =BB=D8=B8=B4=3ARe=3A Some question on C= APWAP protocol = =3E implementation =3E HI=2C =3E = =3E I believe that you have made an incorrect characterizing of =3E CAPWAP=2E See below=2E =3E = =3E On Wed=2C 5 Jul 2006=2C zhaoyujin 31390 wrote=3A =3E =3E =3F=3F=3F=3F=3F=3F=3A Wenhui Zhou =3Czhouwenhui=40chinamobile=2Ec= om=3E =3E =3E =3F=3F=3F=3F=3A =3F=3F=3F=3F=3F=3F=2C =3F=3F=3F=3F 4=3F=3F=2C 200= 6 =3F=3F=3F=3F7=3A43 =3E =3E =3F=A1=C2=3F=3F=3A Re=3A =5BCapwap=5D Some question on CAPWAP pro= tocol implementation =3E =3E = =3E =3E =3E = =3E =3E =3E Dear CAPWAP guys=2C =3E =3E =3E = =3E =3E =3E i am sorry i missed much previous related topics=2C so i have= = =3E some = =3E =3E =3E questions about CAPWAP protocol implementation=2E =3E =3E =3E = =3E =3E =3E 1=2E Whether it has been decided that LWAPP will be the proto= col = =3E =3E =3E implementing CAPWAP=3F =3E =3E // This has been decided=2E And current the LWAPP protocol has =3E =3E changed name to CAPWAP=2E =3E This IS NOT a correct characterization of CAPWAP=2E CAPWAP IS NOT =3E LWAPP with a different name! =3E =3D=3D=3E I think the correct wording would be CAPWAP is LWAPP with = =3E changes suggested by the eval team report RFC 4565=2E Security = =3E (incorporation of DTLS replacing LWAPP-specific technique) has = =3E been the place for most changes=2E In other places=2C the changes hav= e = =3E been mostly editorial=2E =3E = =3E Regards=2C =3E = =3E --behcet =3E = =3E = =3E = =3E = =3E --===============0100369475== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0100369475==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 06 05:56:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyQbR-00048W-EJ for capwap-archive@lists.ietf.org; Thu, 06 Jul 2006 05:56:57 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyQbP-0001vg-H8 for capwap-archive@lists.ietf.org; Thu, 06 Jul 2006 05:56:57 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DB33D4300EE for ; Thu, 6 Jul 2006 02:56:54 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 56446430085 for ; Thu, 6 Jul 2006 02:56:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4686B398055 for ; Thu, 6 Jul 2006 02:56:10 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 54F00398053 for ; Thu, 6 Jul 2006 02:56:05 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id k669u4L4003408; Thu, 6 Jul 2006 18:56:04 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k669u5J21659; Thu, 6 Jul 2006 18:56:05 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with SMTP id k669u5F10801; Thu, 6 Jul 2006 18:56:05 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Jul 2006 17:57:33 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDFF3FF3@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Thread-Index: Acafb/vWccV4LppQTlWGIxVYNyL1bgBJ3Y0g From: "Saravanan Govindan" To: "Michael Montemurro" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.425 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1422960010==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: aaff5d7f1eb2bd23c778cdb1a9c777b3 This is a multi-part message in MIME format. --===============1422960010== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A0E2.0B121ED1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A0E2.0B121ED1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike, =20 Thank you for the note.=20 I may not have been clear with my previous post. My request is to have EAPoL frames generated at the AC alone - not at the WTP.=20 =20 My request is for designs where EAPoL frames are generated at the AC and in those where the KeyRSC is maintained in the WTP. These designs were highlighted in the Architecture Taxonomy.=20 =20 Specifically, I suggest that a CAPWAP message (it may be Add WLAN or Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. This EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of group key handshake) would have its KeyRSC field unassigned. Then when the WTP receives this message, it fills in the right value of the KeyRSC, updates the EAPoL frame and then transmit it to the wireless station.=20 =20 I hope this clarifies my suggestion. Cheers, Saravanan =20 =20 =20 =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Tuesday, July 04, 2006 9:47 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 So, you would like to request that the WTP generate EAPoL-Key frames for the 4-way handshake and the GTK update? =20 The current draft assumes that all EAPoL-Key frames are generated at the AC. =20 Based on the following assumptions: 1) This feature would be for local-MAC only. 2) The 4-way handshake and the GTK handshake would originate from the same location. =20 This would then require: 1) Negotiation between the WTP and the AC on where the 4-way handshake and GTK updates are generated.=20 2) A modification to the updateWLAN message element to include the PMK when a STA successfully associates. =20 I've captured this as issue 199. =20 On 7/3/06, Saravanan Govindan wrote:=20 Hi Mike, =20 I had a chance to review the new draft.=20 =20 With regard to Issue 43, my understanding is that updates were made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN message element now allows the AC to send sequence counter values to the WTP. So now, CAPWAP can support designs where the KeyRSC is maintained by the AC.=20 =20 My initial concern was with supporting designs where the KeyRSC is maintained by the WTP. This is particularly important to manage the 4-Way and Group-key handshakes.=20 =20 With this in mind, I think the protocol still requires support for designs where the KeyRSC is maintained by the WTP. Based on the current draft, this support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames would have unassigned fields for KeyRSC (since the value is maintained by the WTP).=20 =20 I am also open to any alternatives to support this.=20 =20 Cheers, Saravanan =20 =20 =20 =20 ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com]=20 Sent: Tuesday, June 20, 2006 10:01 PM=20 To: Saravanan Govindan Cc: Bob O'Hara (boohara); capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 I've updated section 11.3 to deal with the GTK exchange and the handling of the KeyRSC in draft -02 to address your comments. I also provided a mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message element as part of the Group Key exchange.=20 =20 We're finalizing the -02 draft this week and you should be able to look at it when we post it later this week. =20 Cheers, =20 Mike =20 ------_=_NextPart_001_01C6A0E2.0B121ED1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mike,

 

Thank you for the note.


I may not have been clear with my previous post. My request is to have = EAPoL frames generated at the AC alone – not at the WTP. =

 

My request is for designs where EAPoL frames are = generated at the AC and in those where the KeyRSC is maintained in the WTP. These = designs were highlighted in the Architecture Taxonomy. =

 

Specifically, I suggest that a CAPWAP message (it may = be Add WLAN or Update WLAN) be able to carry an EAPoL frame from the AC to the = WTP. This EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of = group key handshake) would have its KeyRSC field unassigned. Then when the WTP receives this message, it fills in the right value of the KeyRSC, = updates the EAPoL frame and then transmit it to the wireless station. =

 

I hope this clarifies my = suggestion.


Cheers,


Saravanan

 

 

 

 

From: = Michael Montemurro [mailto:montemurro.michael@gmail.com]
Sent: Tuesday, July 04, = 2006 9:47 PM
To: Saravanan Govindan
Cc: capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

 

Saravanan,

 

So, you would like to request that the WTP generate EAPoL-Key = frames for the 4-way handshake and the GTK update?

 

The current draft assumes that all EAPoL-Key frames are = generated at the AC.

 

Based on the following assumptions:

1) This feature would be for local-MAC = only.

2) The 4-way handshake and the GTK handshake would originate = from the same location.

 

This would then require:

1) Negotiation between the WTP and the AC on where the 4-way = handshake and GTK updates are generated.

2) A modification to the updateWLAN message element to = include the PMK when a STA successfully associates.

 

I've captured this as issue 199.

 

On 7/3/06, Saravanan = Govindan <Saravanan.Govindan@sg= .panasonic.com> wrote:

Hi Mike,

 

I had a chance to review the new draft.

 

With regard to Issue 43, my understanding is that updates were made in = Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN = message element now allows the AC to send sequence counter values to the WTP. So = now, CAPWAP can support designs where the KeyRSC is maintained by the AC. =

 

My initial concern was with supporting designs where the KeyRSC is = maintained by the WTP. This is particularly important to manage the 4-Way and = Group-key handshakes.

 

With this in mind, I think the protocol still requires support for designs = where the KeyRSC is maintained by the WTP. Based on the current draft, this = support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way = handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames = would have unassigned fields for KeyRSC (since the value is maintained by the = WTP).

 

I am also open to any alternatives to support this. =

 

Cheers,


Saravanan

 

 

 

 

From: Michael Montemurro = [mailto: montemurro.michael@gmail.com]
Sent: Tuesday, June 20, = 2006 10:01 PM
To: Saravanan Govindan
Cc: Bob O'Hara (boohara); = capwap
Subject: Re: [Capwap] = Clarification of Issue 43: IEEE 802.11i Considerations

 

Saravanan,

 

I've updated section 11.3 to deal with the GTK exchange and the handling of = the KeyRSC in draft -02 to address your comments. I also provided a = mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message = element as part of the Group Key exchange.

 

We're finalizing the -02 draft this week and you should be able to look at it = when we post it later this week.

 

Cheers,

 

Mike

 

------_=_NextPart_001_01C6A0E2.0B121ED1-- --===============1422960010== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1422960010==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 06 07:44:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FySHb-0000xp-E1 for capwap-archive@lists.ietf.org; Thu, 06 Jul 2006 07:44:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyQT2-0001Rt-0w for capwap-archive@lists.ietf.org; Thu, 06 Jul 2006 05:48:16 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyQNh-0001NL-As for capwap-archive@lists.ietf.org; Thu, 06 Jul 2006 05:42:49 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0184D430101 for ; Thu, 6 Jul 2006 02:42:36 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 91BDE430085 for ; Thu, 6 Jul 2006 02:42:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 741C0430891 for ; Thu, 6 Jul 2006 02:42:13 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 6536E43088F for ; Thu, 6 Jul 2006 02:42:09 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k669g7c2024329; Thu, 6 Jul 2006 18:42:07 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k669g8l26261; Thu, 6 Jul 2006 18:42:08 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with SMTP id k669g9F06677; Thu, 6 Jul 2006 18:42:09 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Jul 2006 17:43:31 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDFF3FE0@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Editorial - WTP Event Request Thread-Index: AcaeoxqHj9/A2vmFRK++yWkEGuqr2AB9Zm0g From: "Saravanan Govindan" To: "Scott G Kelly" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Editorial - WTP Event Request X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Hi Scott, I see your point. I agree that any control message serves the purpose of keep alive for the WTP. In this case, I suggest the same text in Section 4.3 (CAPWAP Control Messages) with slight modification; "The exchange of a CAPWAP control message serves as an implicit keep alive mechanism for the WTP. The arrival of a CAPWAP control message at the AC indicates the WTP is operational. In cases where regular CAPWAP control messages are not exchanged, explicit keep alive is used (see Section 7)." Comments? Saravanan -----Original Message----- From: Scott G Kelly [mailto:scott@hyperthought.com] Sent: Monday, July 03, 2006 9:20 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Editorial - WTP Event Request Hi Saravanan, I thought there was general agreement that if *any* authenticated control traffic (not just an event request) is observed during the echo interval, this is implicit proof of liveness, and no echo request is required for that interval. Having text like what's suggested below (that only references the event request) might lead people to incorrectly conclude that only an event request can obviate the need for an echo exchange. Why should we have text which confers this special status only on the event request, rather than on all/any authenticated control channel traffic? Scott Saravanan Govindan wrote: > All, > > > > I would like to suggest an editorial update to Section 9.5 (WTP Event > Request). > > > > This is based on earlier discussions of how WTP Event Request serves as > an implicit keep alive mechanism for the WTP. I believe this observation > can be made explicit in this section. > > > > I suggest the following after the 1^st paragraph of Section 9.5; > > > > "The exchange of WTP Event Request serves as an implicit keep alive > mechanism for the WTP. The arrival of a WTP Event Request message at the > AC indicates the WTP is operational. In cases where WTP Event Request is > not exchanged, explicit keep alive is used (see Section 7)." > > > > The current text in Section 7 refers to maintaining the control > communication channel, whereas the suggestion above refers to the WTP as > a whole. > > > > Comments? > > > > Saravanan > > > ------------------------------------------------------------------------ > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jul 07 00:50:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyiIG-0002d5-7r for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 00:50:20 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyiIE-0001xA-Ph for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 00:50:20 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DEF184300DD for ; Thu, 6 Jul 2006 21:50:17 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 055E843004F for ; Thu, 6 Jul 2006 21:49:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E2C8C398082 for ; Thu, 6 Jul 2006 21:49:49 -0700 (PDT) Received: from huawei-3com.com (pop.huawei-3com.com [219.133.0.18]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3B26039807B for ; Thu, 6 Jul 2006 21:49:31 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J20003O3OGAHR@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Fri, 07 Jul 2006 12:57:46 +0800 (CST) Received: from RichardYoung ([10.18.7.74]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J20003H2OG9UB@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Fri, 07 Jul 2006 12:57:46 +0800 (CST) Date: Fri, 07 Jul 2006 10:19:11 +0530 From: young To: pcalhoun@cisco.com Message-id: <000001c6a180$b2187170$4a07120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.375 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE X-Spam-Level: Cc: capwap@frascone.com Subject: [Capwap] Rogue AP detection feature X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0358211244==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 This is a multi-part message in MIME format. --===============0358211244== Content-type: multipart/alternative; boundary="Boundary_(ID_Kmrv5It1BynNIrPZ7zcWHg)" This is a multi-part message in MIME format. --Boundary_(ID_Kmrv5It1BynNIrPZ7zcWHg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear Pat Calhoun: As the WLAN network characteristic, the Rogue AP detection feature is very important. The prevalent method is: AP and AC work together to do Rogue AP detection, So it is clear: AC will send some control information to monitor AP by control tunnel, while AP reports scanning information to AC. As most AC vendor support these feature, I think it is better that CAPWAP do some support for rogue AP detection feature. What is your opinion? Regards Richard --Boundary_(ID_Kmrv5It1BynNIrPZ7zcWHg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT 
Dear Pat Calhoun:
 
As the WLAN network characteristic, the Rogue AP detection feature is very important.
The prevalent method is: AP and AC work together to do Rogue AP detection, 
So it is clear: AC will send some control information to monitor AP by control tunnel, while AP
reports scanning information to AC.
As most AC vendor support these feature, I think it is better that CAPWAP do some support for 
rogue AP detection feature.
 
What is your opinion?
 
Regards
 
Richard

 

--Boundary_(ID_Kmrv5It1BynNIrPZ7zcWHg)-- --===============0358211244== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0358211244==-- From info@i-plus.cn Fri Jul 07 03:14:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FykXT-0006vR-T4 for capwap-archive@ietf.org; Fri, 07 Jul 2006 03:14:11 -0400 Received: from [222.77.40.242] (helo=i-plus.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FykXQ-0008Vk-Jp for capwap-archive@ietf.org; Fri, 07 Jul 2006 03:14:11 -0400 Message-ID: <20060707151345.5352D02F8F78AE7F@i-plus.cn> From: "LATEST ITEM USB" To: capwap-archive@ietf.org Subject: LATEST ITEM USB Date: 07 Jul 2006 15:13:46 +0800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 4.3 (++++) X-Scan-Signature: 6379955759c38e2371a49573a0932fc7 =EF=BB=BF Product Detail
 
USB Flash Drive
 
<= /TD>
     

 

=
  • Support=20 full-speed(1.2Mb/s)
  • USB=20 Standard Commands&Vender Commands support= =20
  • Enough capacity for fre= e=20 upgrade
  • Driver Support for Wind= ows=20 98/98SE
  • No driver needed for Wi= ndows=20 2000/ME/XP and Mac OS 9.0 or higher=20
  • Provide LED indicator when Usb Flash = Disk=20 is working
  • Write/delete protection= =20 switch.Protect your data in UsbFlash Disk=20
  • Can be erased and writt= en for 1=20 million times
  • Support USB-HDD&USB= -ZIP=20 boot
  • Storage life: >10 ye= ars=20
  • Build in Security funct= ion=20
  • Hot Plug and Play-enabl= e you to=20 install Usb Flash Disk at anytime=20
    =
    Prod= uct=20 Information
    Product Code UDF307
    Catego= ry USB Flash Drive
    Othe= r=20 Details
    		•
     

    Contact=20 Us

     

    Our = Hong Kong Show=20 room

    Unit 2805  28/F , Trendy = Centre=20 , 682-684 ,  Castle Peak Road ,  Kowlo= on , =20 Hong Kong
    Tel: (852) 2742 7933
    Fax: (852) 2742 7922
    Website for digital items:www.i-p= lus.cn
    Website for general items:www.oceantophk.com
    E-mail:info@= oceantophk.com

    Our Ch= ina=20 Production Factory

    Jin Wah Industrial and Development Z= one,=20 Shenzhen, Guangdong province, China
    Tel: (86) 755 8363 8060    6133=20 4520
    Fax: (86) 755 6133=20 4520 
    E-mail: info@i-plus.cn

    Brazil Office<= /FONT>

    Scantrade Com  Ltda.
    Tel.:   55 21 2522.2901  
             =20 55 21 9417.2511
    E-mail: scantrade@globo.com
    Attn:     Stefan=20 Jakobsson
    		=
    From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jul 07 10:37:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyrSd-0008KR-Hu for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 10:37:39 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyrSa-00082W-2z for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 10:37:39 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 921F8430133 for ; Fri, 7 Jul 2006 07:37:31 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6AB344300A7 for ; Fri, 7 Jul 2006 07:36:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 563B63980BF for ; Fri, 7 Jul 2006 07:36:57 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by zoidberg.tigertech.net (Postfix) with ESMTP id A4D673980C5 for ; Fri, 7 Jul 2006 07:36:52 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 07 Jul 2006 07:36:51 -0700 X-IronPort-AV: i="4.06,218,1149490800"; d="scan'208,217"; a="433225725:sNHT60830844" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k67EapRa005001; Fri, 7 Jul 2006 07:36:51 -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 k67EanTQ024020; Fri, 7 Jul 2006 07:36:50 -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); Fri, 7 Jul 2006 07:36:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Jul 2006 07:36:40 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20225CA63@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rogue AP detection feature Thread-Index: AcahgLYPWn1sSnXjRYWG7tuAGHdyGgAUcm3A From: "Pat Calhoun (pacalhou)" To: "young" X-OriginalArrivalTime: 07 Jul 2006 14:36:41.0868 (UTC) FILETIME=[C35094C0:01C6A1D2] Authentication-Results: sj-dkim-4.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.373 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Rogue AP detection feature X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1957668627==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 This is a multi-part message in MIME format. --===============1957668627== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A1D2.C2F93EC5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A1D2.C2F93EC5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While it may be an interesting feature, I believe that the WG was chartered to provide a protocol that addresses the issues listed in the problem statement (RFC 3990). Rogue detection is not part of the problem statement, so in order to ship a protocol while it is still relevant, I would prefer we focus on the current set of features. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: young [mailto:young@huawei-3com.com]=20 Sent: Thursday, July 06, 2006 9:49 PM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Rogue AP detection feature =09 =09 Dear Pat Calhoun: =20 As the WLAN network characteristic, the Rogue AP detection feature is very important. The prevalent method is: AP and AC work together to do Rogue AP detection,=20 So it is clear: AC will send some control information to monitor AP by control tunnel, while AP reports scanning information to AC. As most AC vendor support these feature, I think it is better that CAPWAP do some support for=20 rogue AP detection feature. =20 What is your opinion? =20 Regards =20 Richard =20 ------_=_NextPart_001_01C6A1D2.C2F93EC5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    While=20 it may be an interesting feature, I believe that the WG was chartered to = provide=20 a protocol that addresses the issues listed in the problem statement = (RFC 3990).=20 Rogue detection is not part of the problem statement, so in order to = ship a=20 protocol while it is still relevant, I would prefer we focus on the = current set=20 of features.
     

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

     

    From: young = [mailto:young@huawei-3com.com]=20
    Sent: Thursday, July 06, 2006 9:49 PM
    To: Pat = Calhoun=20 (pacalhou)
    Cc: capwap@frascone.com
    Subject: Rogue = AP=20 detection feature

    Dear Pat Calhoun:
     
    As the WLAN =
network characteristic, the Rogue AP detection feature is very =
important.
    The prevalent =
method is: AP and AC work together to do Rogue AP detection, =

    So it is clear: AC will send some =
control information to monitor AP by control tunnel, while =
AP
    reports scanning information to =
AC.
    As most AC vendor support these =
feature, I think it is better that CAPWAP do some support for =

    rogue AP detection =
feature.
     
    What is your =
opinion?
     
    Regards
     
    Richard

     

    ------_=_NextPart_001_01C6A1D2.C2F93EC5-- --===============1957668627== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1957668627==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jul 07 10:43:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyrY6-000549-Jb for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 10:43:18 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyrY3-0008Kp-3m for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 10:43:18 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 48B1143013E for ; Fri, 7 Jul 2006 07:43:12 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B87214300A7 for ; Fri, 7 Jul 2006 07:42:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id ABA263980B4 for ; Fri, 7 Jul 2006 07:42:44 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by zoidberg.tigertech.net (Postfix) with ESMTP id E8431398013 for ; Fri, 7 Jul 2006 07:42:39 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 07 Jul 2006 07:42:39 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k67Egcpa031417; Fri, 7 Jul 2006 07:42:38 -0700 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 k67EgcsV002463; Fri, 7 Jul 2006 07:42:38 -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); Fri, 7 Jul 2006 07:42:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Jul 2006 07:42:37 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20225CA64@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Capwap] Keepalive on data channel Thread-Index: AcagQ+/txuPBNUjDRWKW1Y3gjCCDbgBj1jRg From: "Pat Calhoun (pacalhou)" To: "zhaoyujin 31390" , "Mani, Mahalingam (Mani)" X-OriginalArrivalTime: 07 Jul 2006 14:42:38.0692 (UTC) FILETIME=[97FF9A40:01C6A1D3] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Keepalive on data channel X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0217972196==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 --===============0217972196== Content-class: urn:content-classes:message Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Not sure that I follow your comment completely, but I don't see how a = keepalive on the data plane will affect performance. This is not a = packet over the air, but rather over the wire. We can ignore this issue, = and call it irrelevant, but people that have built tunneling protocols, = and deployed them, have seen this issue. We can certainly call the = network configuration silly, but in the end, network administrators = actually do this. So the question is whether we want a protocol that can actually work in = such scenarios or require enterprises to reconfigure their networks just = to run CAPWAP. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: zhaoyujin 31390 [mailto:zhaoyujin@huawei.com]=20 > Sent: Wednesday, July 05, 2006 8:02 AM > To: Mani, Mahalingam (Mani) > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: =BB=D8=B8=B4:Re: [Capwap] Keepalive on data channel >=20 > Dear all: >=20 > Frankly, I think if data tunnel need keepalive should be discussed. > =20 > Normally, our Capwap data tunnel will be controlled to=20 > create or delete by control tunnel, so that data tunnel=20 > keepalive may be repeated. And this will affect the=20 > performance of data transmission. >=20 > But for NAT Traversal, maybe CAPWAP can send one no-used=20 > packet to maintain the NAT entry for capwap data tunnel. But=20 > before this, capwap need decide which device is inside of NAT=20 > with control tunnel. >=20 > Best regards > Michael > =20 >=20 > ----- =D4=AD=D3=CA=BC=FE ----- > =B7=A2=BC=FE=C8=CB: "Mani, Mahalingam (Mani)" > =C8=D5=C6=DA: =D0=C7=C6=DA=C8=FD, =C1=F9=D4=C2 28=C8=D5, 2006 = =C9=CF=CE=E710:02 > =D6=F7=CC=E2: Re: [Capwap] Keepalive on data channel >=20 > > Pat, > >=20 > > The relevance of the 'Then' preceding the recommendation is=20 > not clear. > >=20 > > This is merely an observation of the implication of the behavior on=20 > > this given network policy instance. We expect the relevant areas to=20 > > respond when ADs take this up with them. > >=20 > > -mani > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [pcalhoun@cisco.com] > > Sent: Monday, June 26, 2006 6:27 PM > > To: Mani, Mahalingam (Mani); capwap@frascone.com > > Subject: RE: [Capwap] Keepalive on data channel > >=20 > > Mani, > >=20 > > Then I would recommend that you include folks from the=20 > Internet Area=20 > > in your discussions, as they have a number of tunneling standards=20 > > efforts underway, as well as operational experience. > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Mani, Mahalingam (Mani) [mmani@avaya.com] > > > Sent: Monday, June 26, 2006 5:22 PM > > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > > Subject: RE: [Capwap] Keepalive on data channel > > >=20 > > > It appears that in such a network - all flows marked for=20 > DSCP -based=20 > > > QoS are at a diagnostic peril - each of a different kind=20 > - in such a=20 > > > failure scenario. > > >=20 > > > -mani > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) [pcalhoun@cisco.com] > > > Sent: Monday, June 26, 2006 7:09 AM > > > To: capwap@frascone.com > > > Subject: [Capwap] Keepalive on data channel > > >=20 > > > All, > > > =20 > > > In a conversation with some of the L2TP folks, they have=20 > experience=20 > > > an operational problem that we need to keep in mind.=20 > Basically, they=20 > > > multiplex their control and data frames through their own header,=20 > > > and mark their packets priorities based on control vs. data. > > >=20 > > > What they have found is that networks do route path=20 > selection based=20 > > > on DSCP/ToS values, meaning that they send higher=20 > priority (control)=20 > > > frames over different links than data frames. The network is not=20 > > > designed to perform this solely for L2TP, as this is=20 > something they=20 > > > do for all of their applications. The issue is that their=20 > protocol=20 > > > relies on a keepalive frame that runs over the control channel,=20 > > > identically to CAPWAP. However, the operational issue=20 > that they've=20 > > > found is that if the path taken by the data channel is=20 > broken, and=20 > > > these frames are never delivered. > > >=20 > > > The L2TP folks have found that the lack of a keepalive mechanism=20 > > > makes it impossible to diagnose such an issue. When it=20 > occurs, the=20 > > > administrator first has to figure out it is occurring,=20 > because the=20 > > > protocol does not, and then needs to manually follow the path to=20 > > > find the failure. > > >=20 > > > As far as I can tell, Scott's two primary issues with not=20 > wanting to=20 > > > support UDP ports were: > > > 1. NAT Traversal will require a keepalive on the data channel. As=20 > > > noted above, we need to add a keepalive on the data=20 > channel in order=20 > > > to be able to detect network routing failures. > > > 2. Modifications to the state machine to handle data channel > > failure.> Given that such failures can occur, we need to be able to > > > recover, if possible. > > >=20 > > > I wanted to raise these issues as they are real, and actually=20 > > > experienced in L2TP deployments. I believe we need to=20 > address these,=20 > > > and if so, then I believe the complexity associated with the dual=20 > > > UDP port ends up being resolved. > > >=20 > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems=20 > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > >=20 > > > Archives: http://lists.frascone.com/pipermail/capwap > > >=20 > >=20 > >=20 > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > >=20 > > Archives: http://lists.frascone.com/pipermail/capwap > >=20 >=20 --===============0217972196== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0217972196==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jul 07 11:11:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyryu-0002XC-AE for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 11:11:00 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyrqR-0002kZ-VZ for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 11:02:18 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C0EFD4300D6 for ; Fri, 7 Jul 2006 08:02:14 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id A84F74300A9 for ; Fri, 7 Jul 2006 08:01:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8CE501448083 for ; Fri, 7 Jul 2006 08:01:55 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id D2301430E93 for ; Fri, 7 Jul 2006 08:01:50 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k67F1n23016580; Fri, 7 Jul 2006 08:01:49 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k67F1mbb016574; Fri, 7 Jul 2006 08:01:49 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 7 Jul 2006 08:01:48 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20225CA63@xmb-sjc-235.amer.cisco.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap@frascone.com, young Subject: Re: [Capwap] Rogue AP detection feature X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 HI, I agree with Pat that Rogue detection (and possible countermeasures) is outside the scope of the first CAPWAP specification. I do believe that it is a prime candidate for a follow on. At this time, I'm not sure that CAPWAP will ever get done. Time will tell. I just don't see the current process leading to a specification that will be coded, deployed, interoperation tested, and advanced on the standards track. In a few one-on-one meetings on single topics, I was able to see progress. The interactions over email and at IETF WG meetings don't seem to result in much progress. On Fri, 7 Jul 2006, Pat Calhoun (pacalhou) wrote: > While it may be an interesting feature, I believe that the WG was > chartered to provide a protocol that addresses the issues listed in the > problem statement (RFC 3990). Rogue detection is not part of the problem > statement, so in order to ship a protocol while it is still relevant, I > would prefer we focus on the current set of features. > > > Pat Calhoun >-------------------------- > > From: young [mailto:young@huawei-3com.com] > Sent: Thursday, July 06, 2006 9:49 PM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: Rogue AP detection feature > > > Dear Pat Calhoun: > > As the WLAN network characteristic, the Rogue AP detection > feature is very important. > The prevalent method is: AP and AC work together to do Rogue AP > detection, > So it is clear: AC will send some control information to monitor > AP by control tunnel, while AP > reports scanning information to AC. > As most AC vendor support these feature, I think it is better > that CAPWAP do some support for > rogue AP detection feature. > > What is your opinion? > > Regards > > Richard _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jul 07 12:13:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FysxW-0007h1-JZ for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 12:13:38 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FysxU-0002vq-3x for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 12:13:38 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 221654300D6 for ; Fri, 7 Jul 2006 09:13:35 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id DD73D4300A9 for ; Fri, 7 Jul 2006 09:13:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D087339802E for ; Fri, 7 Jul 2006 09:13:13 -0700 (PDT) X-Greylist-Status: Sender first seen 1 mon 6 days 00:56:34 ago Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by zoidberg.tigertech.net (Postfix) with ESMTP id C4B483980DB for ; Fri, 7 Jul 2006 09:12:12 -0700 (PDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k67G8SaM012568 for ; Fri, 7 Jul 2006 12:08:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Jul 2006 10:12:10 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Tentative agenda. Thread-Index: Acaf/fd0D0xQuJUfTc2R9lXuTCuC/gAW128Q From: "Mani, Mahalingam (Mani)" To: "David T. Perkins" X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Tentative agenda. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 David, [I meant to send this earlier - but it happened to get stuck in my draft folder]. I guess you meant IEEE reports. I have requested this time for the report to not be "happenings" but ones that have potential implications, if any, to CAPWAP protocol development. We request the editors to take note of "contentious issues" list below among the issues they will be discussing. As to the disbandment discussion - to justify a brief session discussion meaningful; can I request you start the thread in the list and gauge the response to that idea? We can decide on that as a agenda topic if there appears to be enough justification. Regards, -mani -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Tuesday, July 04, 2006 11:41 PM To: Mani, Mahalingam (Mani) Cc: capwap@frascone.com; Romascanu, Dan (Dan) Subject: Re: [Capwap] Tentative agenda. HI, I believe the current agenda is inappropriate. There is no need to provide reports at IETF WG meetings. Such reports should be just sent to the WG mailing list. The WG meeting should be only used to try to gain common understanding, and then resolution of contentious issues from the mailing list. What are the contentious issues? 1) Using the same DTLS session for both data and control trafffic 2) The format of CAPWAP control messages 3) THe format of CAPWAP data messages 4) The CAPWAP state machine 5) The details of CAPWAP message fragmentation 6) The details of retries of CAPWAP control messages 7) Details for image transfer 6) Details for discovery, and then join, then WTP capability and initial WTP configuration etc. And esspecially, whether or not the CAPWAP WP should be disbanded, or continued? Why disbanned? Because there does not appear to be enough interest in creating a specification that will have code written that supports it, and have interoperability testing performed on it. Regards, /david t. perkins On Tue, 4 Jul 2006, Mani, Mahalingam (Mani) wrote: > Hi, > > A tentative (but almost final) agenda has been posted for IETF66: > > http://www3.ietf.org/proceedings/06jul/agenda/capwap.htm > > Any other agenda suggestions welcome as well and we will try to > accommodate. > > So far Dorothy Stanley's (IEEE802.11 liaison) presentation has been > received and posted. We hope to receive the others' before the sessions. > > -Chairs > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jul 07 13:19:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fytz8-0006ut-SQ for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 13:19:22 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fytz6-0000wR-Bm for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 13:19:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 27AA843010D for ; Fri, 7 Jul 2006 10:19:19 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 5A5224300A9 for ; Fri, 7 Jul 2006 10:18:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 464243980C6 for ; Fri, 7 Jul 2006 10:18:55 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 638A83980B8 for ; Fri, 7 Jul 2006 10:18:48 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k67HIhoH023625; Fri, 7 Jul 2006 10:18:43 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k67HIfZU023611; Fri, 7 Jul 2006 10:18:43 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 7 Jul 2006 10:18:41 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Mani, Mahalingam (Mani)" In-Reply-To: Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Tentative agenda. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de HI, The agenda currently reads: 1) WG status ? 10 min (chairs) a) Protocol draft b) Milestones c) multi-area input-call for ?MUX vs Dual-port? d) 3rd WG Chair 2) IEEE Liaison Update - Dorothy Stanley (5 min.) 3) Editors review and Issues: encryption at WTP/AC, 802.11 binding, handover and more (45 min) 4) MIB updates - Dave Perkins (15 min.) 5) Security Draft: Scott Kelly (15 min). 6) Security overview of -02 draft (Charles Clancy, Scott Kelly) ? 5-10 min Let's talk about #3. The CAPWAP-02 draft came out. The announcement said that it addressed 42 items from the issue tracker. However, no summary of changes was made available. Using the IETF tool to show document differences, there were quite a bit of changes. However, many were "false positives" due to changes in the section numbers. The section number changes also made checking the comments in the issue tracker painfull. I started to verify each issue, but gave up because of the time it took. It would be very helpful if a summary of all the 42 changes was sent to the WG mailing list. Going through the list at the WG meeting could take much time that could be used on other items. Let's talk about #4. The co-chair, Dorothy Gellert, sent me email and asked to push back the MIB draft to october. I agreed, since I don't believe the CAPWAP specification is solid enough for the MIB work to start. Let's talk about #5. I'm not sure what this is. Let's talk about #6. This should be sent out on the WG mailing list. Note, there has already been discussion. The CAPWAP-02 has updates. I believe that there are still problems. There are technical problems that didn't get fixed in the CAPWAP-02. And there are problems that are due to the lack of written out use cases. So, I suggest that "reports" be sent out to the WG to cover #3, #5, and #6. A new agenda can be constructed based on the one that I suggested below. For each point, it would be useful to create a list of pros and cons. No decision, of course, can be made at the WG session during the IETF meeting. However, I believe that the WG session should be used to capture a) the assumptions (and there are plenty in the CAPWAP spec) that are not written down b) the pros c) the cons That would be the best use of the experience and knowledge at the WG session. There is no need for the BS and politics that I've seen at past sessions. Regards, /david t. perkins > David, > > [I meant to send this earlier - but it happened to get stuck in my draft > folder]. > > I guess you meant IEEE reports. I have requested this time for the > report to not be "happenings" but ones that have potential implications, > if any, to CAPWAP protocol development. > > We request the editors to take note of "contentious issues" list below > among the issues they will be discussing. > > As to the disbandment discussion - to justify a brief session discussion > meaningful; can I request you start the thread in the list and gauge the > response to that idea? We can decide on that as a agenda topic if there > appears to be enough justification. > > Regards, > -mani > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Tuesday, July 04, 2006 11:41 PM > To: Mani, Mahalingam (Mani) > Cc: capwap@frascone.com; Romascanu, Dan (Dan) > Subject: Re: [Capwap] Tentative agenda. > > HI, > > I believe the current agenda is inappropriate. > > There is no need to provide reports at IETF WG meetings. > Such reports should be just sent to the WG mailing list. > > The WG meeting should be only used to try to gain common > understanding, and then resolution of contentious issues > from the mailing list. > > What are the contentious issues? > 1) Using the same DTLS session for both data and control > trafffic > 2) The format of CAPWAP control messages > 3) THe format of CAPWAP data messages > 4) The CAPWAP state machine > 5) The details of CAPWAP message fragmentation > 6) The details of retries of CAPWAP control messages > 7) Details for image transfer > 6) Details for discovery, and then join, then WTP capability > and initial WTP configuration > etc. > > And esspecially, whether or not the CAPWAP WP should be > disbanded, or continued? Why disbanned? Because there does > not appear to be enough interest in creating a specification that > will have code written that supports it, and have interoperability > testing performed on it. > > Regards, > /david t. perkins > > On Tue, 4 Jul 2006, Mani, Mahalingam (Mani) wrote: > > Hi, > > > > A tentative (but almost final) agenda has been posted for IETF66: > > > > http://www3.ietf.org/proceedings/06jul/agenda/capwap.htm > > > > Any other agenda suggestions welcome as well and we will try to > > accommodate. > > > > So far Dorothy Stanley's (IEEE802.11 liaison) presentation has been > > received and posted. We hope to receive the others' before the > sessions. > > > > -Chairs > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jul 07 13:26:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyu5n-0003dK-Ph for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 13:26:15 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyu5n-000162-39 for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 13:26:15 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B23E643010E for ; Fri, 7 Jul 2006 10:26:14 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8FA624300A9 for ; Fri, 7 Jul 2006 10:25:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 678A41448089 for ; Fri, 7 Jul 2006 10:25:43 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id 4ABF71448081 for ; Fri, 7 Jul 2006 10:25:40 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 07 Jul 2006 10:25:39 -0700 X-IronPort-AV: i="4.06,218,1149490800"; d="scan'208"; a="1836179173:sNHT35745200" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k67HPdHo001651; Fri, 7 Jul 2006 10:25:39 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k67HPY4A008305; Fri, 7 Jul 2006 10:25:39 -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); Fri, 7 Jul 2006 10:25:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Jul 2006 10:25:36 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20225CB2C@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Tentative agenda. Thread-Index: Acah6X7znhA4IyqkTfev5hazvV9fvwAAIavQ From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" , "Mani, Mahalingam (Mani)" X-OriginalArrivalTime: 07 Jul 2006 17:25:37.0545 (UTC) FILETIME=[5CA62790:01C6A1EA] Authentication-Results: sj-dkim-8.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Tentative agenda. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Just to be clear, David, each and every change made to the -02 document had proposed text that was sent to the list for comments. The comments which had broad agreement were folded back into the spec. So it's not fair to say that we are operating purely in a vaccuum here. That said, we will make sure that the announce e-mail for -03 has more meat, but the actual text will still be found in individual e-mails sent by the editors. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Friday, July 07, 2006 10:19 AM > To: Mani, Mahalingam (Mani) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Tentative agenda. > > HI, > > The agenda currently reads: > 1) WG status ? 10 min (chairs) > a) Protocol draft > b) Milestones > c) multi-area input-call for ?MUX vs Dual-port? > d) 3rd WG Chair > 2) IEEE Liaison Update - Dorothy Stanley (5 min.) > 3) Editors review and Issues: encryption at WTP/AC, 802.11 > binding, handover and more (45 min) > 4) MIB updates - Dave Perkins (15 min.) > 5) Security Draft: Scott Kelly (15 min). > 6) Security overview of -02 draft (Charles Clancy, > Scott Kelly) ? 5-10 min > > Let's talk about #3. The CAPWAP-02 draft came out. The > announcement said that it addressed 42 items from the issue > tracker. However, no summary of changes was made available. > Using the IETF tool to show document differences, there were > quite a bit of changes. However, many were "false positives" > due to changes in the section numbers. The section number > changes also made checking the comments in the issue tracker > painfull. I started to verify each issue, but gave up because > of the time it took. It would be very helpful if a summary of > all the 42 changes was sent to the WG mailing list. Going > through the list at the WG meeting could take much time that > could be used on other items. > > Let's talk about #4. The co-chair, Dorothy Gellert, sent me > email and asked to push back the MIB draft to october. I > agreed, since I don't believe the CAPWAP specification is > solid enough for the MIB work to start. > > Let's talk about #5. I'm not sure what this is. > Let's talk about #6. This should be sent out on the WG > mailing list. Note, there has already been discussion. The > CAPWAP-02 has updates. I believe that there are still > problems. There are technical problems that didn't get fixed > in the CAPWAP-02. > And there are problems that are due to the lack of written > out use cases. > > So, I suggest that "reports" be sent out to the WG to cover > #3, #5, and #6. > > A new agenda can be constructed based on the one that I > suggested below. For each point, it would be useful to create > a list of pros and cons. No decision, of course, can be made > at the WG session during the IETF meeting. However, I believe > that the WG session should be used to capture > a) the assumptions (and there are plenty in > the CAPWAP spec) that are not written down > b) the pros > c) the cons > > That would be the best use of the experience and knowledge at > the WG session. > > There is no need for the BS and politics that I've seen at > past sessions. > > Regards, > /david t. perkins > > > David, > > > > [I meant to send this earlier - but it happened to get stuck in my > > draft folder]. > > > > I guess you meant IEEE reports. I have requested this time for the > > report to not be "happenings" but ones that have potential > > implications, if any, to CAPWAP protocol development. > > > > We request the editors to take note of "contentious issues" > list below > > among the issues they will be discussing. > > > > As to the disbandment discussion - to justify a brief session > > discussion meaningful; can I request you start the thread > in the list > > and gauge the response to that idea? We can decide on that > as a agenda > > topic if there appears to be enough justification. > > > > Regards, > > -mani > > -----Original Message----- > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > Sent: Tuesday, July 04, 2006 11:41 PM > > To: Mani, Mahalingam (Mani) > > Cc: capwap@frascone.com; Romascanu, Dan (Dan) > > Subject: Re: [Capwap] Tentative agenda. > > > > HI, > > > > I believe the current agenda is inappropriate. > > > > There is no need to provide reports at IETF WG meetings. > > Such reports should be just sent to the WG mailing list. > > > > The WG meeting should be only used to try to gain common > > understanding, and then resolution of contentious issues from the > > mailing list. > > > > What are the contentious issues? > > 1) Using the same DTLS session for both data and control > > trafffic > > 2) The format of CAPWAP control messages > > 3) THe format of CAPWAP data messages > > 4) The CAPWAP state machine > > 5) The details of CAPWAP message fragmentation > > 6) The details of retries of CAPWAP control messages > > 7) Details for image transfer > > 6) Details for discovery, and then join, then WTP capability > > and initial WTP configuration > > etc. > > > > And esspecially, whether or not the CAPWAP WP should be > disbanded, or > > continued? Why disbanned? Because there does not appear to > be enough > > interest in creating a specification that will have code > written that > > supports it, and have interoperability testing performed on it. > > > > Regards, > > /david t. perkins > > > > On Tue, 4 Jul 2006, Mani, Mahalingam (Mani) wrote: > > > Hi, > > > > > > A tentative (but almost final) agenda has been posted for IETF66: > > > > > > http://www3.ietf.org/proceedings/06jul/agenda/capwap.htm > > > > > > Any other agenda suggestions welcome as well and we will try to > > > accommodate. > > > > > > So far Dorothy Stanley's (IEEE802.11 liaison) > presentation has been > > > received and posted. We hope to receive the others' before the > > sessions. > > > > > > -Chairs > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jul 07 14:38:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyvDt-0008Ub-LU for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 14:38:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyvDt-0007By-JL for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 14:38:41 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyvD2-0000Fs-BZ for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 14:37:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B3AA94300F7 for ; Fri, 7 Jul 2006 11:37:38 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 28DC34300A9 for ; Fri, 7 Jul 2006 11:37:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 02C60144803E for ; Fri, 7 Jul 2006 11:37:11 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9CE2E1448081 for ; Fri, 7 Jul 2006 11:37:06 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k67IauIC016992; Fri, 7 Jul 2006 11:36:56 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k67Iao5m016948; Fri, 7 Jul 2006 11:36:55 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 7 Jul 2006 11:36:50 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20225CB2C@xmb-sjc-235.amer.cisco.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Tentative agenda. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: a492040269d440726bfd84680622cee7 HI Pat, Please don't read into my comments that there was not a process for taking comments. There is one, which is good. The comment was that I found it difficult to verify the actual changes in the CAPWAP-02 draft due to what appeared to me to be a section number change that appeared to me to be avoidable. Because of the cost, I abandoned verification. I did notice that the one that I had submitted on the cipher suites was not applied correctly. And I also VERY MUCH disagreed with the recomendation for the common name on the CERT that is in the text. If we have the usage sceanrios, I think the rational well be better understood. See you sunday or monday! Regards, /david t. perkins On Fri, 7 Jul 2006, Pat Calhoun (pacalhou) wrote: > Just to be clear, David, each and every change made to the -02 document > had proposed text that was sent to the list for comments. The comments > which had broad agreement were folded back into the spec. So it's not > fair to say that we are operating purely in a vaccuum here. That said, > we will make sure that the announce e-mail for -03 has more meat, but > the actual text will still be found in individual e-mails sent by the > editors. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > Sent: Friday, July 07, 2006 10:19 AM > > To: Mani, Mahalingam (Mani) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Tentative agenda. > > > > HI, > > > > The agenda currently reads: > > 1) WG status ? 10 min (chairs) > > a) Protocol draft > > b) Milestones > > c) multi-area input-call for ?MUX vs Dual-port? > > d) 3rd WG Chair > > 2) IEEE Liaison Update - Dorothy Stanley (5 min.) > > 3) Editors review and Issues: encryption at WTP/AC, 802.11 > > binding, handover and more (45 min) > > 4) MIB updates - Dave Perkins (15 min.) > > 5) Security Draft: Scott Kelly (15 min). > > 6) Security overview of -02 draft (Charles Clancy, > > Scott Kelly) ? 5-10 min > > > > Let's talk about #3. The CAPWAP-02 draft came out. The > > announcement said that it addressed 42 items from the issue > > tracker. However, no summary of changes was made available. > > Using the IETF tool to show document differences, there were > > quite a bit of changes. However, many were "false positives" > > due to changes in the section numbers. The section number > > changes also made checking the comments in the issue tracker > > painfull. I started to verify each issue, but gave up because > > of the time it took. It would be very helpful if a summary of > > all the 42 changes was sent to the WG mailing list. Going > > through the list at the WG meeting could take much time that > > could be used on other items. > > > > Let's talk about #4. The co-chair, Dorothy Gellert, sent me > > email and asked to push back the MIB draft to october. I > > agreed, since I don't believe the CAPWAP specification is > > solid enough for the MIB work to start. > > > > Let's talk about #5. I'm not sure what this is. > > Let's talk about #6. This should be sent out on the WG > > mailing list. Note, there has already been discussion. The > > CAPWAP-02 has updates. I believe that there are still > > problems. There are technical problems that didn't get fixed > > in the CAPWAP-02. > > And there are problems that are due to the lack of written > > out use cases. > > > > So, I suggest that "reports" be sent out to the WG to cover > > #3, #5, and #6. > > > > A new agenda can be constructed based on the one that I > > suggested below. For each point, it would be useful to create > > a list of pros and cons. No decision, of course, can be made > > at the WG session during the IETF meeting. However, I believe > > that the WG session should be used to capture > > a) the assumptions (and there are plenty in > > the CAPWAP spec) that are not written down > > b) the pros > > c) the cons > > > > That would be the best use of the experience and knowledge at > > the WG session. > > > > There is no need for the BS and politics that I've seen at > > past sessions. > > > > Regards, > > /david t. perkins > > > > > David, > > > > > > [I meant to send this earlier - but it happened to get stuck in my > > > draft folder]. > > > > > > I guess you meant IEEE reports. I have requested this time for the > > > report to not be "happenings" but ones that have potential > > > implications, if any, to CAPWAP protocol development. > > > > > > We request the editors to take note of "contentious issues" > > list below > > > among the issues they will be discussing. > > > > > > As to the disbandment discussion - to justify a brief session > > > discussion meaningful; can I request you start the thread > > in the list > > > and gauge the response to that idea? We can decide on that > > as a agenda > > > topic if there appears to be enough justification. > > > > > > Regards, > > > -mani > > > -----Original Message----- > > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > > Sent: Tuesday, July 04, 2006 11:41 PM > > > To: Mani, Mahalingam (Mani) > > > Cc: capwap@frascone.com; Romascanu, Dan (Dan) > > > Subject: Re: [Capwap] Tentative agenda. > > > > > > HI, > > > > > > I believe the current agenda is inappropriate. > > > > > > There is no need to provide reports at IETF WG meetings. > > > Such reports should be just sent to the WG mailing list. > > > > > > The WG meeting should be only used to try to gain common > > > understanding, and then resolution of contentious issues from the > > > mailing list. > > > > > > What are the contentious issues? > > > 1) Using the same DTLS session for both data and control > > > trafffic > > > 2) The format of CAPWAP control messages > > > 3) THe format of CAPWAP data messages > > > 4) The CAPWAP state machine > > > 5) The details of CAPWAP message fragmentation > > > 6) The details of retries of CAPWAP control messages > > > 7) Details for image transfer > > > 6) Details for discovery, and then join, then WTP capability > > > and initial WTP configuration > > > etc. > > > > > > And esspecially, whether or not the CAPWAP WP should be > > disbanded, or > > > continued? Why disbanned? Because there does not appear to > > be enough > > > interest in creating a specification that will have code > > written that > > > supports it, and have interoperability testing performed on it. > > > > > > Regards, > > > /david t. perkins > > > > > > On Tue, 4 Jul 2006, Mani, Mahalingam (Mani) wrote: > > > > Hi, > > > > > > > > A tentative (but almost final) agenda has been posted for IETF66: > > > > > > > > http://www3.ietf.org/proceedings/06jul/agenda/capwap.htm > > > > > > > > Any other agenda suggestions welcome as well and we will try to > > > > accommodate. > > > > > > > > So far Dorothy Stanley's (IEEE802.11 liaison) > > presentation has been > > > > received and posted. We hope to receive the others' before the > > > sessions. > > > > > > > > -Chairs > > > > > > > > _________________________________________________________________ > > > > To unsubscribe or modify your subscription options, please visit: > > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jul 07 15:08:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyvgH-0001b4-4J for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 15:08:01 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyvgF-0002w3-AK for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 15:08:01 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A9C1D4300C9 for ; Fri, 7 Jul 2006 12:07:58 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id F2655430067 for ; Fri, 7 Jul 2006 12:07:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CC2F51448083 for ; Fri, 7 Jul 2006 12:07:16 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id D4AFD1448081 for ; Fri, 7 Jul 2006 12:07:14 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 07 Jul 2006 12:07:14 -0700 X-IronPort-AV: i="4.06,218,1149490800"; d="scan'208"; a="1836231432:sNHT38143448" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k67J7EFH006633; Fri, 7 Jul 2006 12:07:14 -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 k67J7ETQ023777; Fri, 7 Jul 2006 12:07:14 -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); Fri, 7 Jul 2006 12:07:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Jul 2006 12:07:13 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20225CBF4@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Tentative agenda. Thread-Index: Acah9FwQYfsuWCHMTTeWAbfsRXYsrQABA3og From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" X-OriginalArrivalTime: 07 Jul 2006 19:07:14.0131 (UTC) FILETIME=[8E7F5A30:01C6A1F8] Authentication-Results: sj-dkim-1.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Tentative agenda. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Please note that the second numbering changes were a request from the WG to make the document easier to read. It was discussed at the previous IETF meeting, and on the list. There was an explicit issue to track this change. See you next week. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Friday, July 07, 2006 11:37 AM > To: Pat Calhoun (pacalhou) > Cc: Mani, Mahalingam (Mani); capwap@frascone.com > Subject: RE: [Capwap] Tentative agenda. > > HI Pat, > > Please don't read into my comments that there was not a > process for taking comments. There is one, which is good. The > comment was that I found it difficult to verify the actual > changes in the CAPWAP-02 draft due to what appeared to me to > be a section number change that appeared to me to be avoidable. > Because of the cost, I abandoned verification. I did notice > that the one that I had submitted on the cipher suites was > not applied correctly. And I also VERY MUCH disagreed with > the recomendation for the common name on the CERT that is in > the text. If we have the usage sceanrios, I think the > rational well be better understood. > > See you sunday or monday! > > Regards, > /david t. perkins > > On Fri, 7 Jul 2006, Pat Calhoun (pacalhou) wrote: > > Just to be clear, David, each and every change made to the -02 > > document had proposed text that was sent to the list for > comments. The > > comments which had broad agreement were folded back into > the spec. So > > it's not fair to say that we are operating purely in a > vaccuum here. > > That said, we will make sure that the announce e-mail for > -03 has more > > meat, but the actual text will still be found in individual e-mails > > sent by the editors. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > -----Original Message----- > > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > > Sent: Friday, July 07, 2006 10:19 AM > > > To: Mani, Mahalingam (Mani) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Tentative agenda. > > > > > > HI, > > > > > > The agenda currently reads: > > > 1) WG status ? 10 min (chairs) > > > a) Protocol draft > > > b) Milestones > > > c) multi-area input-call for ?MUX vs Dual-port? > > > d) 3rd WG Chair > > > 2) IEEE Liaison Update - Dorothy Stanley (5 min.) > > > 3) Editors review and Issues: encryption at WTP/AC, 802.11 > > > binding, handover and more (45 min) > > > 4) MIB updates - Dave Perkins (15 min.) > > > 5) Security Draft: Scott Kelly (15 min). > > > 6) Security overview of -02 draft (Charles Clancy, > > > Scott Kelly) ? 5-10 min > > > > > > Let's talk about #3. The CAPWAP-02 draft came out. The > announcement > > > said that it addressed 42 items from the issue tracker. > However, no > > > summary of changes was made available. > > > Using the IETF tool to show document differences, there > were quite a > > > bit of changes. However, many were "false positives" > > > due to changes in the section numbers. The section number changes > > > also made checking the comments in the issue tracker painfull. I > > > started to verify each issue, but gave up because of the time it > > > took. It would be very helpful if a summary of all the 42 changes > > > was sent to the WG mailing list. Going through the list at the WG > > > meeting could take much time that could be used on other items. > > > > > > Let's talk about #4. The co-chair, Dorothy Gellert, sent me email > > > and asked to push back the MIB draft to october. I > agreed, since I > > > don't believe the CAPWAP specification is solid enough > for the MIB > > > work to start. > > > > > > Let's talk about #5. I'm not sure what this is. > > > Let's talk about #6. This should be sent out on the WG > mailing list. > > > Note, there has already been discussion. The > > > CAPWAP-02 has updates. I believe that there are still problems. > > > There are technical problems that didn't get fixed in the > CAPWAP-02. > > > And there are problems that are due to the lack of > written out use > > > cases. > > > > > > So, I suggest that "reports" be sent out to the WG to > cover #3, #5, > > > and #6. > > > > > > A new agenda can be constructed based on the one that I suggested > > > below. For each point, it would be useful to create a > list of pros > > > and cons. No decision, of course, can be made at the WG session > > > during the IETF meeting. However, I believe that the WG session > > > should be used to capture > > > a) the assumptions (and there are plenty in > > > the CAPWAP spec) that are not written down > > > b) the pros > > > c) the cons > > > > > > That would be the best use of the experience and > knowledge at the WG > > > session. > > > > > > There is no need for the BS and politics that I've seen at past > > > sessions. > > > > > > Regards, > > > /david t. perkins > > > > > > > David, > > > > > > > > [I meant to send this earlier - but it happened to get > stuck in my > > > > draft folder]. > > > > > > > > I guess you meant IEEE reports. I have requested this > time for the > > > > report to not be "happenings" but ones that have potential > > > > implications, if any, to CAPWAP protocol development. > > > > > > > > We request the editors to take note of "contentious issues" > > > list below > > > > among the issues they will be discussing. > > > > > > > > As to the disbandment discussion - to justify a brief session > > > > discussion meaningful; can I request you start the thread > > > in the list > > > > and gauge the response to that idea? We can decide on that > > > as a agenda > > > > topic if there appears to be enough justification. > > > > > > > > Regards, > > > > -mani > > > > -----Original Message----- > > > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > > > Sent: Tuesday, July 04, 2006 11:41 PM > > > > To: Mani, Mahalingam (Mani) > > > > Cc: capwap@frascone.com; Romascanu, Dan (Dan) > > > > Subject: Re: [Capwap] Tentative agenda. > > > > > > > > HI, > > > > > > > > I believe the current agenda is inappropriate. > > > > > > > > There is no need to provide reports at IETF WG meetings. > > > > Such reports should be just sent to the WG mailing list. > > > > > > > > The WG meeting should be only used to try to gain common > > > > understanding, and then resolution of contentious > issues from the > > > > mailing list. > > > > > > > > What are the contentious issues? > > > > 1) Using the same DTLS session for both data and control > > > > trafffic > > > > 2) The format of CAPWAP control messages > > > > 3) THe format of CAPWAP data messages > > > > 4) The CAPWAP state machine > > > > 5) The details of CAPWAP message fragmentation > > > > 6) The details of retries of CAPWAP control messages > > > > 7) Details for image transfer > > > > 6) Details for discovery, and then join, then WTP capability > > > > and initial WTP configuration etc. > > > > > > > > And esspecially, whether or not the CAPWAP WP should be > > > disbanded, or > > > > continued? Why disbanned? Because there does not appear to > > > be enough > > > > interest in creating a specification that will have code > > > written that > > > > supports it, and have interoperability testing performed on it. > > > > > > > > Regards, > > > > /david t. perkins > > > > > > > > On Tue, 4 Jul 2006, Mani, Mahalingam (Mani) wrote: > > > > > Hi, > > > > > > > > > > A tentative (but almost final) agenda has been posted > for IETF66: > > > > > > > > > > http://www3.ietf.org/proceedings/06jul/agenda/capwap.htm > > > > > > > > > > Any other agenda suggestions welcome as well and we > will try to > > > > > accommodate. > > > > > > > > > > So far Dorothy Stanley's (IEEE802.11 liaison) > > > presentation has been > > > > > received and posted. We hope to receive the others' before the > > > > sessions. > > > > > > > > > > -Chairs > > > > > > > > > > > ________________________________________________________________ > > > > > _ To unsubscribe or modify your subscription options, please > > > > > visit: > > > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jul 07 16:32:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyx00-000723-M2 for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 16:32:28 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyw3v-0004N0-5p for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 15:32:27 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fyvt6-0001IU-AC for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 15:21:20 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9C9154300DD for ; Fri, 7 Jul 2006 12:21:15 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id A519A430067 for ; Fri, 7 Jul 2006 12:20:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 85D811448091 for ; Fri, 7 Jul 2006 12:20:51 -0700 (PDT) Received: from mgw-ext11.nokia.com (mgw-ext11.nokia.com [131.228.20.170]) by hermes.tigertech.net (Postfix) with ESMTP id 7EB5A144808E for ; Fri, 7 Jul 2006 12:20:46 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k67IKehC026788; Fri, 7 Jul 2006 21:20:40 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 22:20:40 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 14:20:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Jul 2006 12:20:33 -0700 Message-ID: <893AE265F4ADF94AB7FB26D31A788E41024B9C77@mvebe101.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Tentative agenda. Thread-Index: Acah8niuKjikW5kCTJ61Kf8VeMBMwAAB95vw From: To: , X-OriginalArrivalTime: 07 Jul 2006 19:20:37.0759 (UTC) FILETIME=[6D7F40F0:01C6A1FA] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.2 tagged_above=-999.0 required=7.0 tests=NO_REAL_NAME X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Tentative agenda. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 The MIB slot for you was also to discuss your operations draft. Do you still want the slot? -Dorothy -----Original Message----- From: ext David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, July 07, 2006 10:19 AM To: Mani, Mahalingam (Mani) Cc: capwap@frascone.com Subject: Re: [Capwap] Tentative agenda. HI, The agenda currently reads: 1) WG status ? 10 min (chairs) a) Protocol draft b) Milestones c) multi-area input-call for ?MUX vs Dual-port? d) 3rd WG Chair 2) IEEE Liaison Update - Dorothy Stanley (5 min.) 3) Editors review and Issues: encryption at WTP/AC, 802.11 binding, handover and more (45 min) 4) MIB updates - Dave Perkins (15 min.) 5) Security Draft: Scott Kelly (15 min). 6) Security overview of -02 draft (Charles Clancy, Scott Kelly) ? 5-10 min Let's talk about #3. The CAPWAP-02 draft came out. The announcement said that it addressed 42 items from the issue tracker. However, no summary of changes was made available. Using the IETF tool to show document differences, there were quite a bit of changes. However, many were "false positives" due to changes in the section numbers. The section number changes also made checking the comments in the issue tracker painfull. I started to verify each issue, but gave up because of the time it took. It would be very helpful if a summary of all the 42 changes was sent to the WG mailing list. Going through the list at the WG meeting could take much time that could be used on other items. Let's talk about #4. The co-chair, Dorothy Gellert, sent me email and asked to push back the MIB draft to october. I agreed, since I don't believe the CAPWAP specification is solid enough for the MIB work to start. Let's talk about #5. I'm not sure what this is. Let's talk about #6. This should be sent out on the WG mailing list. Note, there has already been discussion. The CAPWAP-02 has updates. I believe that there are still problems. There are technical problems that didn't get fixed in the CAPWAP-02. And there are problems that are due to the lack of written out use cases. So, I suggest that "reports" be sent out to the WG to cover #3, #5, and #6. A new agenda can be constructed based on the one that I suggested below. For each point, it would be useful to create a list of pros and cons. No decision, of course, can be made at the WG session during the IETF meeting. However, I believe that the WG session should be used to capture a) the assumptions (and there are plenty in the CAPWAP spec) that are not written down b) the pros c) the cons That would be the best use of the experience and knowledge at the WG session. There is no need for the BS and politics that I've seen at past sessions. Regards, /david t. perkins > David, > > [I meant to send this earlier - but it happened to get stuck in my > draft folder]. > > I guess you meant IEEE reports. I have requested this time for the > report to not be "happenings" but ones that have potential > implications, if any, to CAPWAP protocol development. > > We request the editors to take note of "contentious issues" list below > among the issues they will be discussing. > > As to the disbandment discussion - to justify a brief session > discussion meaningful; can I request you start the thread in the list > and gauge the response to that idea? We can decide on that as a agenda > topic if there appears to be enough justification. > > Regards, > -mani > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Tuesday, July 04, 2006 11:41 PM > To: Mani, Mahalingam (Mani) > Cc: capwap@frascone.com; Romascanu, Dan (Dan) > Subject: Re: [Capwap] Tentative agenda. > > HI, > > I believe the current agenda is inappropriate. > > There is no need to provide reports at IETF WG meetings. > Such reports should be just sent to the WG mailing list. > > The WG meeting should be only used to try to gain common > understanding, and then resolution of contentious issues from the > mailing list. > > What are the contentious issues? > 1) Using the same DTLS session for both data and control > trafffic > 2) The format of CAPWAP control messages > 3) THe format of CAPWAP data messages > 4) The CAPWAP state machine > 5) The details of CAPWAP message fragmentation > 6) The details of retries of CAPWAP control messages > 7) Details for image transfer > 6) Details for discovery, and then join, then WTP capability > and initial WTP configuration > etc. > > And esspecially, whether or not the CAPWAP WP should be disbanded, or > continued? Why disbanned? Because there does not appear to be enough > interest in creating a specification that will have code written that > supports it, and have interoperability testing performed on it. > > Regards, > /david t. perkins > > On Tue, 4 Jul 2006, Mani, Mahalingam (Mani) wrote: > > Hi, > > > > A tentative (but almost final) agenda has been posted for IETF66: > > > > http://www3.ietf.org/proceedings/06jul/agenda/capwap.htm > > > > Any other agenda suggestions welcome as well and we will try to > > accommodate. > > > > So far Dorothy Stanley's (IEEE802.11 liaison) presentation has been > > received and posted. We hope to receive the others' before the > sessions. > > > > -Chairs > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jul 07 16:32:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyx0J-00073k-Kh for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 16:32:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyx0I-0002LC-69 for capwap-archive@lists.ietf.org; Fri, 07 Jul 2006 16:32:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 889654300EA for ; Fri, 7 Jul 2006 13:32:45 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7B461430067 for ; Fri, 7 Jul 2006 13:32:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 58F67398033 for ; Fri, 7 Jul 2006 13:32:22 -0700 (PDT) Received: from mgw-ext11.nokia.com (mgw-ext11.nokia.com [131.228.20.170]) by zoidberg.tigertech.net (Postfix) with ESMTP id 559533980BE for ; Fri, 7 Jul 2006 13:32:14 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k67JWBZ9006707; Fri, 7 Jul 2006 22:32:11 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 23:31:22 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 15:31:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Jul 2006 13:31:17 -0700 Message-ID: <893AE265F4ADF94AB7FB26D31A788E41024B9CF5@mvebe101.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CAPWAP agenda. Thread-Index: Acaf6x6YLcktHK66TJCWTu/vzGyAxgCGBH4Q From: To: , X-OriginalArrivalTime: 07 Jul 2006 20:31:20.0889 (UTC) FILETIME=[4E998290:01C6A204] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.178 tagged_above=-999 required=7 tests=NO_REAL_NAME X-Spam-Level: Cc: Dorothy.Gellert@nokia.com Subject: [Capwap] CAPWAP agenda. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Here is the new agenda as of this morning (7/7/06), taking all comments and requests into consideration. We've updated the IETF Web page, but I haven't seen changes updated on the website yet. 15:20: WG Status & Milestones - 5 mins 15:25: IEEE Liaison Update - Dorothy Stanley - 5 mins 15:30: CAPWAP Protocol -02 draft & Issues - Editors - 45 mins 16:15: MIB update & Operations - Dave Perkins - 15 mins 16:30: Security Draft - Scott Kelly & Charles Clancy - 15 mins 16:45: Mux Issue - Pat Calhoun - 10 mins 16:55: Mux Issue/OpenCAPWAP - Scott Kelly - 15 mins 17:10: Applicability of CAPWAP to RFID - Margaret W - 10 mins (time permitting) 17:20: Adjourn I haven't reached David Perkins to verify if he is still presenting the MIB and Operations draft. If not, we will give his 15 minute slot to the Editors for new issues since they have requested as much time as possible. Please send the chairs your presentations as soon as possible. See everyone on Monday. Best Regards, Dorothy -----Original Message----- From: ext Mani, Mahalingam (Mani) [mailto:mmani@avaya.com] Sent: Tuesday, July 04, 2006 9:26 PM To: capwap@frascone.com Subject: [Capwap] Tentative agenda. Importance: High Hi, A tentative (but almost final) agenda has been posted for IETF66: http://www3.ietf.org/proceedings/06jul/agenda/capwap.htm Any other agenda suggestions welcome as well and we will try to accommodate. So far Dorothy Stanley's (IEEE802.11 liaison) presentation has been received and posted. We hope to receive the others' before the sessions. -Chairs _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 12 15:45:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kdv-00010C-0j for capwap-archive@lists.ietf.org; Wed, 12 Jul 2006 15:45:07 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0kds-0005nn-IM for capwap-archive@lists.ietf.org; Wed, 12 Jul 2006 15:45:07 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 439844300F1 for ; Wed, 12 Jul 2006 12:45:03 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 64E584300D9 for ; Wed, 12 Jul 2006 12:44:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5D4AE144800E for ; Wed, 12 Jul 2006 12:44:33 -0700 (PDT) X-Greylist-Status: Sender first seen 00:59:59 ago Received: from thingmagic.com (unknown [204.9.221.19]) by hermes.tigertech.net (Postfix) with ESMTP id E16031448005 for ; Wed, 12 Jul 2006 12:44:29 -0700 (PDT) Received: from [132.219.28.212] (account margaret [132.219.28.212] verified) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1104631 for capwap@frascone.com; Wed, 12 Jul 2006 14:44:27 -0400 Mime-Version: 1.0 (Apple Message framework v750) Message-Id: <74E8F4FC-EB62-45A9-BBAF-9A175A6AED8E@lilacglade.org> To: capwap@frascone.com From: Margaret Wasserman Date: Wed, 12 Jul 2006 14:44:12 -0400 X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO X-Spam-Level: Subject: [Capwap] CAPWAP and RFID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Hi All, For background on why I'm raising the next few issues, please see the slides (in the proceedings for IETF 66) that I did not get a chance to present in the WG meeting. The primary point of those slides was that the Reader Operations WG of the EPCglobal standards body (an RFID industry standards body) is considering reusing the base protocol portions of CAPWAP as a discovery and control protocol for RFID systems. Bob O'Hara and I are both active in that group, and we've been asked to communicate some requirements from that group to the CAPWAP WG. NOTE: We are not talking about adding RFID-specific control messages to CAPWAP. In fact, the group is not currently planning to use CAPWAP as the control channel. So, these are not RFID-specific requirements. In our scenario, an RFID controller (or "client") would act in the role of a WTP, and RFID readers would act in the AP role. The two requirements we've been asked to communicate are: (1) Trickle firmware download with separate reboot. In other words, we need to be able to download the firmware while our CAPWAP connection remains in the running state, and later be able to trigger a reboot, which will result in a switch to the new firmware. It seems very likely that some 802.11 systems will require this feature, as well. In fact, it is my understanding that some systems already do it this way. But, the current state diagram and CAPWAP text don't seem to support this -- you leave the running state to move to the firmware download state and can only exit the firmware download state through the reboot state. (2) Clean separation between CAPWAP "base" protocol and 802.11- specific control messages. Ideally, we'd like to see the CAPWAP base protocol and the 802.11-specific controls in separate documents, but it would also be possible for us to reference a portion of a monolithic document, as long as the base protocol is cleanly-enough separated from the 802.11-specific portions to allow us to unambiguously and normatively reference the base protocol. Would the CAPWAP WG support making these changes so that the EPCglobal RO WG can reuse this technology? Thanks, Margaret Margaret Wasserman Vice President ThingMagic margaret@thingmagic.com _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 12 16:59:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0lo5-0001QZ-Rb for capwap-archive@lists.ietf.org; Wed, 12 Jul 2006 16:59:41 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0lo4-0002WK-Bk for capwap-archive@lists.ietf.org; Wed, 12 Jul 2006 16:59:41 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6ABA74300ED for ; Wed, 12 Jul 2006 13:59:39 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 5EA8D4300DF for ; Wed, 12 Jul 2006 13:59:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 53487398015 for ; Wed, 12 Jul 2006 13:59:14 -0700 (PDT) Received: from smtpauth04.mail.atl.earthlink.net (smtpauth04.mail.atl.earthlink.net [209.86.89.64]) by zoidberg.tigertech.net (Postfix) with ESMTP id 555B1398012 for ; Wed, 12 Jul 2006 13:59:10 -0700 (PDT) Received: from [209.86.224.33] (helo=elwamui-darkeyed.atl.sa.earthlink.net) by smtpauth04.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1G0lnZ-0002Ln-Af; Wed, 12 Jul 2006 16:59:09 -0400 Received: from 132.219.18.173 by webmail.pas.earthlink.net with HTTP; Wed, 12 Jul 2006 16:59:09 -0400 Message-ID: <13980280.1152737949298.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Date: Wed, 12 Jul 2006 13:59:09 -0700 (GMT-07:00) From: "Scott G. Kelly" To: Margaret Wasserman , capwap@frascone.com Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710b4fd8d5c6b8dd245a4bc6ee35d0b42d0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.33 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: Re: [Capwap] CAPWAP and RFID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Hi Margaret, I agree that both goals you mention below are important. I'll leave it to the chairs to respond to the notion of separating the 802.11 functionality into its own document, but I think clean separation is imperative if we are to support other bindings. Scott -----Original Message----- >From: Margaret Wasserman >Sent: Jul 12, 2006 11:44 AM >To: capwap@frascone.com >Subject: [Capwap] CAPWAP and RFID > > >Hi All, > >For background on why I'm raising the next few issues, please see the >slides (in the proceedings for IETF 66) that I did not get a chance >to present in the WG meeting. The primary point of those slides was >that the Reader Operations WG of the EPCglobal standards body (an >RFID industry standards body) is considering reusing the base >protocol portions of CAPWAP as a discovery and control protocol for >RFID systems. Bob O'Hara and I are both active in that group, and >we've been asked to communicate some requirements from that group to >the CAPWAP WG. > >NOTE: We are not talking about adding RFID-specific control messages >to CAPWAP. In fact, the group is not currently planning to use >CAPWAP as the control channel. So, these are not RFID-specific >requirements. > >In our scenario, an RFID controller (or "client") would act in the >role of a WTP, and RFID readers would act in the AP role. > >The two requirements we've been asked to communicate are: > >(1) Trickle firmware download with separate reboot. In other words, >we need to be able to download the firmware while our CAPWAP >connection remains in the running state, and later be able to trigger >a reboot, which will result in a switch to the new firmware. It >seems very likely that some 802.11 systems will require this feature, >as well. In fact, it is my understanding that some systems already >do it this way. But, the current state diagram and CAPWAP text don't >seem to support this -- you leave the running state to move to the >firmware download state and can only exit the firmware download state >through the reboot state. > >(2) Clean separation between CAPWAP "base" protocol and 802.11- >specific control messages. Ideally, we'd like to see the CAPWAP base >protocol and the 802.11-specific controls in separate documents, but >it would also be possible for us to reference a portion of a >monolithic document, as long as the base protocol is cleanly-enough >separated from the 802.11-specific portions to allow us to >unambiguously and normatively reference the base protocol. > >Would the CAPWAP WG support making these changes so that the >EPCglobal RO WG can reuse this technology? > >Thanks, >Margaret > >Margaret Wasserman >Vice President >ThingMagic >margaret@thingmagic.com >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/capwap > >Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 12 19:57:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0oa9-0004Ul-1L for capwap-archive@lists.ietf.org; Wed, 12 Jul 2006 19:57:29 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0mWV-0006K3-25 for capwap-archive@lists.ietf.org; Wed, 12 Jul 2006 17:45:35 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0lwY-0005Q0-JE for capwap-archive@lists.ietf.org; Wed, 12 Jul 2006 17:08:28 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2313943010F for ; Wed, 12 Jul 2006 14:08:17 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8C89F4300DA for ; Wed, 12 Jul 2006 14:07:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 42C001448004 for ; Wed, 12 Jul 2006 14:07:57 -0700 (PDT) X-Greylist-Status: Sender first seen 02:23:24 ago Received: from thingmagic.com (unknown [204.9.221.19]) by hermes.tigertech.net (Postfix) with ESMTP id 332BA1448014 for ; Wed, 12 Jul 2006 14:07:52 -0700 (PDT) Received: from [132.219.28.212] (account margaret [132.219.28.212] verified) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1105075; Wed, 12 Jul 2006 17:07:52 -0400 In-Reply-To: <74E8F4FC-EB62-45A9-BBAF-9A175A6AED8E@lilacglade.org> References: <74E8F4FC-EB62-45A9-BBAF-9A175A6AED8E@lilacglade.org> Mime-Version: 1.0 (Apple Message framework v750) Message-Id: <1FED1448-754A-44A1-924C-99B76DDA6061@lilacglade.org> From: Margaret Wasserman Date: Wed, 12 Jul 2006 17:07:36 -0400 To: Margaret Wasserman X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] CAPWAP and RFID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 I made an error in my earlier post that I would like to correct: On Jul 12, 2006, at 2:44 PM, Margaret Wasserman wrote: > For background on why I'm raising the next few issues, please see the > slides (in the proceedings for IETF 66) that I did not get a chance > to present in the WG meeting. The primary point of those slides was > that the Reader Operations WG of the EPCglobal standards body (an > RFID industry standards body) is considering reusing the base > protocol portions of CAPWAP as a discovery and control protocol for s/discovery and control/discovery and configuration As I said in the next paragraph, we are not currently planning to use CAPWAP as a control protocol for RFID. Sorry for any confusion. Margaret _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 13 10:25:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G127z-0002B2-E0 for capwap-archive@lists.ietf.org; Thu, 13 Jul 2006 10:25:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G127x-0006Iw-Us for capwap-archive@lists.ietf.org; Thu, 13 Jul 2006 10:25:19 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2C4284301A5 for ; Thu, 13 Jul 2006 07:25:17 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C352C43006B for ; Thu, 13 Jul 2006 07:24:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A748A430D5D for ; Thu, 13 Jul 2006 07:24:55 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id 87E4D144800A for ; Thu, 13 Jul 2006 07:24:51 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 13 Jul 2006 07:24:51 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DEOod2026826; Thu, 13 Jul 2006 07:24:50 -0700 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 k6DEOnJq013102; Thu, 13 Jul 2006 07:24:50 -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, 13 Jul 2006 07:24:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Jul 2006 07:24:47 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2022C05CA@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] CAPWAP and RFID Thread-Index: Acal67BtKIMfV9YZSZWO5BwRMNdOpAAnBqVw From: "Pat Calhoun (pacalhou)" To: "Margaret Wasserman" , X-OriginalArrivalTime: 13 Jul 2006 14:24:48.0153 (UTC) FILETIME=[1862D090:01C6A688] Authentication-Results: sj-dkim-4.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] CAPWAP and RFID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 > (1) Trickle firmware download with separate reboot. In other > words, we need to be able to download the firmware while our > CAPWAP connection remains in the running state, and later be > able to trigger a reboot, which will result in a switch to > the new firmware. It seems very likely that some 802.11 > systems will require this feature, as well. In fact, it is > my understanding that some systems already do it this way. > But, the current state diagram and CAPWAP text don't seem to > support this -- you leave the running state to move to the > firmware download state and can only exit the firmware > download state through the reboot state. I assume that the protocol evaluators, who requested that firmware can be upgraded while in the run state meant for service to still be provided. Anyone from the WG disagree? > > (2) Clean separation between CAPWAP "base" protocol and > 802.11- specific control messages. Ideally, we'd like to see > the CAPWAP base protocol and the 802.11-specific controls in > separate documents, but it would also be possible for us to > reference a portion of a monolithic document, as long as the > base protocol is cleanly-enough separated from the > 802.11-specific portions to allow us to unambiguously and > normatively reference the base protocol. Agree that if we want to take this protocol outside of 802.11, then an actual spec that can be normatively referenced, without all of the 802.11 extensions, is required. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 13 10:35:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12Hi-00042q-Dd for capwap-archive@lists.ietf.org; Thu, 13 Jul 2006 10:35:22 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12Hg-0006jJ-Vn for capwap-archive@lists.ietf.org; Thu, 13 Jul 2006 10:35:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 78D2C430166 for ; Thu, 13 Jul 2006 07:35:20 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 6B53A43006B for ; Thu, 13 Jul 2006 07:34:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 50239430D87 for ; Thu, 13 Jul 2006 07:34:58 -0700 (PDT) Received: from mgw-ext11.nokia.com (mgw-ext11.nokia.com [131.228.20.170]) by hermes.tigertech.net (Postfix) with ESMTP id 39206430D86 for ; Thu, 13 Jul 2006 07:34:53 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6DDYnCw013293; Thu, 13 Jul 2006 16:34:51 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 17:34:47 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 09:34:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Jul 2006 07:34:42 -0700 Message-ID: <893AE265F4ADF94AB7FB26D31A788E4102541533@mvebe101.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2022C05CA@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] CAPWAP and RFID Thread-Index: Acal67BtKIMfV9YZSZWO5BwRMNdOpAAnBqVwAABFtJA= From: To: , , X-OriginalArrivalTime: 13 Jul 2006 14:34:44.0707 (UTC) FILETIME=[7BF5BB30:01C6A689] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.2 tagged_above=-999.0 required=7.0 tests=NO_REAL_NAME X-Spam-Level: Subject: Re: [Capwap] CAPWAP and RFID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da I don't see an issue with this, but after the F2F, its clear we have higher priorities at hand, since the spec is not in a working state for implementors. I suggest we focus on those issues first, add this to the Issues Database and prioritze with the remaining open issues once we agree on a final process. BR- Dorothy -----Original Message----- From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Thursday, July 13, 2006 7:25 AM To: Margaret Wasserman; capwap@frascone.com Subject: Re: [Capwap] CAPWAP and RFID > (1) Trickle firmware download with separate reboot. In other words, > we need to be able to download the firmware while our CAPWAP > connection remains in the running state, and later be able to trigger > a reboot, which will result in a switch to the new firmware. It seems > very likely that some 802.11 systems will require this feature, as > well. In fact, it is my understanding that some systems already do it > this way. > But, the current state diagram and CAPWAP text don't seem to support > this -- you leave the running state to move to the firmware download > state and can only exit the firmware download state through the reboot > state. I assume that the protocol evaluators, who requested that firmware can be upgraded while in the run state meant for service to still be provided. Anyone from the WG disagree? > > (2) Clean separation between CAPWAP "base" protocol and > 802.11- specific control messages. Ideally, we'd like to see the > CAPWAP base protocol and the 802.11-specific controls in separate > documents, but it would also be possible for us to reference a portion > of a monolithic document, as long as the base protocol is > cleanly-enough separated from the 802.11-specific portions to allow us > to unambiguously and normatively reference the base protocol. Agree that if we want to take this protocol outside of 802.11, then an actual spec that can be normatively referenced, without all of the 802.11 extensions, is required. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 13 11:09:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12ok-0004rZ-IH for capwap-archive@lists.ietf.org; Thu, 13 Jul 2006 11:09:30 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12dz-0007wZ-3n for capwap-archive@lists.ietf.org; Thu, 13 Jul 2006 10:58:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BD6344301BB for ; Thu, 13 Jul 2006 07:58:22 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 8D4F143006B for ; Thu, 13 Jul 2006 07:58:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 80B97398028 for ; Thu, 13 Jul 2006 07:58:04 -0700 (PDT) X-Greylist-Status: Sender first seen 20:13:31 ago Received: from thingmagic.com (unknown [204.9.221.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 78D1E398024 for ; Thu, 13 Jul 2006 07:58:00 -0700 (PDT) Received: from [132.219.28.212] (account margaret [132.219.28.212] verified) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1107135; Thu, 13 Jul 2006 10:57:59 -0400 In-Reply-To: <893AE265F4ADF94AB7FB26D31A788E4102541533@mvebe101.NOE.Nokia.com> References: <893AE265F4ADF94AB7FB26D31A788E4102541533@mvebe101.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v750) Message-Id: <8BB190AC-7CC2-40B2-9BCC-16DE56612EA3@lilacglade.org> From: Margaret Wasserman Date: Thu, 13 Jul 2006 10:57:42 -0400 To: X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] CAPWAP and RFID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Hi Dorothy, On Jul 13, 2006, at 10:34 AM, wrote: > I don't see an issue with this, but after the F2F, its clear we have > higher priorities at hand, since the spec is not in a working state > for > implementors. I suggest we focus on those issues first, add this to > the Issues Database and prioritze with the remaining open issues > once we > agree on a final process. That's fine with me. It wasn't my intention to derail any current activities, just to get these issues on the table. Thanks, Margaret _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 13 11:09:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12ol-0004rg-7j for capwap-archive@lists.ietf.org; Thu, 13 Jul 2006 11:09:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12cO-0007sh-Qz for capwap-archive@lists.ietf.org; Thu, 13 Jul 2006 10:56:48 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0F3894301AF for ; Thu, 13 Jul 2006 07:56:44 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2B66043006B for ; Thu, 13 Jul 2006 07:56:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EE4131448013 for ; Thu, 13 Jul 2006 07:56:25 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by hermes.tigertech.net (Postfix) with ESMTP id 586FF144801B for ; Thu, 13 Jul 2006 07:56:23 -0700 (PDT) Message-ID: <04f001c6a68c$bb1537c0$636015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Pat Calhoun (pacalhou)" , "Margaret Wasserman" , References: <4FF84B0BC277FF45AA27FE969DD956A2022C05CA@xmb-sjc-235.amer.cisco.com> Date: Thu, 13 Jul 2006 07:57:58 -0700 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=3.1 tagged_above=-999.0 required=7.0 tests=MSGID_DOLLARS X-Spam-Level: *** Subject: Re: [Capwap] CAPWAP and RFID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 3.1 (+++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 >> (2) Clean separation between CAPWAP "base" protocol and >> 802.11- specific control messages. Ideally, we'd like to see >> the CAPWAP base protocol and the 802.11-specific controls in >> separate documents, but it would also be possible for us to >> reference a portion of a monolithic document, as long as the >> base protocol is cleanly-enough separated from the >> 802.11-specific portions to allow us to unambiguously and >> normatively reference the base protocol. > > Agree that if we want to take this protocol outside of 802.11, then > an actual spec that can be normatively referenced, without all of the > 802.11 extensions, is required. I'd also support separating out the 802.11 extensions. It's too late for Wimax to use CAPWAP, but there will be other radio protocols in the future that might find it useful. jak _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 13 16:31:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G17qi-000712-Dr for capwap-archive@lists.ietf.org; Thu, 13 Jul 2006 16:31:52 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G17qg-0006Ty-UB for capwap-archive@lists.ietf.org; Thu, 13 Jul 2006 16:31:52 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id E239A1448038 for ; Thu, 13 Jul 2006 13:31:46 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 041EF430064 for ; Thu, 13 Jul 2006 13:31:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id DA308398026 for ; Thu, 13 Jul 2006 13:31:04 -0700 (PDT) X-Greylist-Status: Sender first seen 5 mons 19 days 04:43:18 ago Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by zoidberg.tigertech.net (Postfix) with ESMTP id E36DC398010 for ; Thu, 13 Jul 2006 13:31:01 -0700 (PDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6DKPcd2020468 for ; Thu, 13 Jul 2006 16:25:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Jul 2006 14:30:59 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] CAPWAP and RFID Thread-Index: Acal66jKfAOinlvwSLGVERyyP9kIbwApGHqQ From: "Mani, Mahalingam (Mani)" To: "Margaret Wasserman" , X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: Re: [Capwap] CAPWAP and RFID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 The WG should consider The #1 as a bug-level issue given that there will be usage models and applications that require scheduling of firmware updates (provisioning/lifecycle management action) separated from reboot (operational management action) to switch to the new firmware. Requiring reboot to be synchronous with a firmware update is restrictive. Above may have implications of having room in stable-store for at least two images (a best practice followed by all well-designed embedded systems anyway) - hopefully a non-issue nowadays even on thin WTPs. The second request is on first providing logical separation more than physically separate documents, as I read it. The WG & editors have done a good job on that beginning with the base protocol. The persuasion to consider the physically split the document becomes more appealing when an additional media binding becomes a reality. The latter needs to be preceded by a re-charter at the minimum, as I understand it, given the current charter. (One of the charter goals has been extensibility, however). Any inputs towards improving logical separation is welcome; and the WG and editors can make a choice on adopting them based on issue-priorities in queue. That could serve us well now and for a physical separation at a later time (whenever it may be). Thanks, -mani -----Original Message----- From: Margaret Wasserman [mailto:mrw@lilacglade.org] Sent: Wednesday, July 12, 2006 11:44 AM To: capwap@frascone.com Subject: [Capwap] CAPWAP and RFID Hi All, For background on why I'm raising the next few issues, please see the slides (in the proceedings for IETF 66) that I did not get a chance to present in the WG meeting. The primary point of those slides was that the Reader Operations WG of the EPCglobal standards body (an RFID industry standards body) is considering reusing the base protocol portions of CAPWAP as a discovery and control protocol for RFID systems. Bob O'Hara and I are both active in that group, and we've been asked to communicate some requirements from that group to the CAPWAP WG. NOTE: We are not talking about adding RFID-specific control messages to CAPWAP. In fact, the group is not currently planning to use CAPWAP as the control channel. So, these are not RFID-specific requirements. In our scenario, an RFID controller (or "client") would act in the role of a WTP, and RFID readers would act in the AP role. The two requirements we've been asked to communicate are: (1) Trickle firmware download with separate reboot. In other words, we need to be able to download the firmware while our CAPWAP connection remains in the running state, and later be able to trigger a reboot, which will result in a switch to the new firmware. It seems very likely that some 802.11 systems will require this feature, as well. In fact, it is my understanding that some systems already do it this way. But, the current state diagram and CAPWAP text don't seem to support this -- you leave the running state to move to the firmware download state and can only exit the firmware download state through the reboot state. (2) Clean separation between CAPWAP "base" protocol and 802.11- specific control messages. Ideally, we'd like to see the CAPWAP base protocol and the 802.11-specific controls in separate documents, but it would also be possible for us to reference a portion of a monolithic document, as long as the base protocol is cleanly-enough separated from the 802.11-specific portions to allow us to unambiguously and normatively reference the base protocol. Would the CAPWAP WG support making these changes so that the EPCglobal RO WG can reuse this technology? Thanks, Margaret Margaret Wasserman Vice President ThingMagic margaret@thingmagic.com _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jul 14 11:36:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1PiE-0007ib-Pb for capwap-archive@lists.ietf.org; Fri, 14 Jul 2006 11:36:18 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Pew-0007YV-Gz for capwap-archive@lists.ietf.org; Fri, 14 Jul 2006 11:32:56 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id EA1B5144802D for ; Fri, 14 Jul 2006 08:32:49 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9B2424300AE for ; Fri, 14 Jul 2006 08:29:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CB77A144802E for ; Fri, 14 Jul 2006 08:29:37 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.194]) by hermes.tigertech.net (Postfix) with ESMTP id C8135144802D for ; Fri, 14 Jul 2006 08:29:31 -0700 (PDT) Received: by nz-out-0102.google.com with SMTP id 34so226204nzf for ; Fri, 14 Jul 2006 08:29:30 -0700 (PDT) Received: by 10.36.12.12 with SMTP id 12mr3197531nzl; Fri, 14 Jul 2006 08:29:30 -0700 (PDT) Received: by 10.36.20.6 with HTTP; Fri, 14 Jul 2006 08:29:29 -0700 (PDT) Message-ID: <5bfe7a820607140829y1a870c97t195a4ed0b6a4f423@mail.gmail.com> Date: Fri, 14 Jul 2006 08:29:29 -0700 From: "Dorothy Stanley" To: "Mani, Mahalingam (Mani)" In-Reply-To: MIME-Version: 1.0 References: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: capwap@frascone.com Subject: Re: [Capwap] CAPWAP and RFID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2074798641==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.0 (+) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 --===============2074798641== Content-Type: multipart/alternative; boundary="----=_Part_4165_27586914.1152890969969" ------=_Part_4165_27586914.1152890969969 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, Issues #200 - Trickle Firmware Download #201 - Clean Separation between base and binding are now created in the issue database to track these items. Dorothy Stanley On 7/13/06, Mani, Mahalingam (Mani) wrote: > > > The WG should consider The #1 as a bug-level issue given that there will > be usage models and applications that require scheduling of firmware > updates (provisioning/lifecycle management action) separated from reboot > (operational management action) to switch to the new firmware. > > Requiring reboot to be synchronous with a firmware update is > restrictive. > > Above may have implications of having room in stable-store for at least > two images (a best practice followed by all well-designed embedded > systems anyway) - hopefully a non-issue nowadays even on thin WTPs. > > > The second request is on first providing logical separation more than > physically separate documents, as I read it. The WG & editors have done > a good job on that beginning with the base protocol. > > The persuasion to consider the physically split the document becomes > more appealing when an additional media binding becomes a reality. The > latter needs to be preceded by a re-charter at the minimum, as I > understand it, given the current charter. (One of the charter goals has > been extensibility, however). > > Any inputs towards improving logical separation is welcome; and the WG > and editors can make a choice on adopting them based on issue-priorities > in queue. That could serve us well now and for a physical separation at > a later time (whenever it may be). > > Thanks, > -mani > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@lilacglade.org] > Sent: Wednesday, July 12, 2006 11:44 AM > To: capwap@frascone.com > Subject: [Capwap] CAPWAP and RFID > > > Hi All, > > For background on why I'm raising the next few issues, please see the > slides (in the proceedings for IETF 66) that I did not get a chance > to present in the WG meeting. The primary point of those slides was > that the Reader Operations WG of the EPCglobal standards body (an > RFID industry standards body) is considering reusing the base > protocol portions of CAPWAP as a discovery and control protocol for > RFID systems. Bob O'Hara and I are both active in that group, and > we've been asked to communicate some requirements from that group to > the CAPWAP WG. > > NOTE: We are not talking about adding RFID-specific control messages > to CAPWAP. In fact, the group is not currently planning to use > CAPWAP as the control channel. So, these are not RFID-specific > requirements. > > In our scenario, an RFID controller (or "client") would act in the > role of a WTP, and RFID readers would act in the AP role. > > The two requirements we've been asked to communicate are: > > (1) Trickle firmware download with separate reboot. In other words, > we need to be able to download the firmware while our CAPWAP > connection remains in the running state, and later be able to trigger > a reboot, which will result in a switch to the new firmware. It > seems very likely that some 802.11 systems will require this feature, > as well. In fact, it is my understanding that some systems already > do it this way. But, the current state diagram and CAPWAP text don't > seem to support this -- you leave the running state to move to the > firmware download state and can only exit the firmware download state > through the reboot state. > > (2) Clean separation between CAPWAP "base" protocol and 802.11- > specific control messages. Ideally, we'd like to see the CAPWAP base > protocol and the 802.11-specific controls in separate documents, but > it would also be possible for us to reference a portion of a > monolithic document, as long as the base protocol is cleanly-enough > separated from the 802.11-specific portions to allow us to > unambiguously and normatively reference the base protocol. > > Would the CAPWAP WG support making these changes so that the > EPCglobal RO WG can reuse this technology? > > Thanks, > Margaret > > Margaret Wasserman > Vice President > ThingMagic > margaret@thingmagic.com > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_4165_27586914.1152890969969 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All,

    Issues

    #200 - Trickle Firmware Download
    #201 - Clean Separation between base and binding

    are now created in the issue database to track these items.

    Dorothy Stanley

    On 7/13/06, Mani, Mahalingam (Mani) <mmani@avaya.com> wrote:
    <!chair>
    The WG should consider The #1 as a bug-level issue given that there will
    be usage models and applications that require scheduling of firmware
    updates (provisioning/lifecycle management action) separated from reboot
    (operational management action) to switch to the new firmware.

    Requiring reboot to be synchronous with a firmware update is
    restrictive.

    Above may have implications of having room in stable-store for at least
    two images (a best practice followed by all well-designed embedded
    systems anyway) - hopefully a non-issue nowadays even on thin WTPs.
    </!chair>

    The second request is on first providing logical separation more than
    physically separate documents, as I read it. The WG & editors have done
    a good job on that beginning with the base protocol.

    The persuasion to consider the physically split the document becomes
    more appealing when an additional media binding becomes a reality. The
    latter needs to be preceded by a re-charter at the minimum, as I
    understand it, given the current charter. (One of the charter goals has
    been extensibility, however).

    Any inputs towards improving logical separation is welcome; and the WG
    and editors can make a choice on adopting them based on issue-priorities
    in queue. That could serve us well now and for a physical separation at
    a later time (whenever it may be).

    Thanks,
    -mani
    -----Original Message-----
    From: Margaret Wasserman [mailto:mrw@lilacglade.org]
    Sent: Wednesday, July 12, 2006 11:44 AM
    To: capwap@frascone.com
    Subject: [Capwap] CAPWAP and RFID


    Hi All,

    For background on why I'm raising the next few issues, please see the
    slides (in the proceedings for IETF 66) that I did not get a chance
    to present in the WG meeting.  The primary point of those slides was
    that the Reader Operations WG of the EPCglobal standards body (an
    RFID industry standards body) is considering reusing the base
    protocol portions of CAPWAP as a discovery and control protocol for
    RFID systems.  Bob O'Hara and I are both active in that group, and
    we've been asked to communicate some requirements from that group to
    the CAPWAP WG.

    NOTE:  We are not talking about adding RFID-specific control messages
    to CAPWAP.  In fact, the group is not currently planning to use
    CAPWAP as the control channel.  So, these are not RFID-specific
    requirements.

    In our scenario, an RFID controller (or "client") would act in the
    role of a WTP, and RFID readers would act in the AP role.

    The two requirements we've been asked to communicate are:

    (1) Trickle firmware download with separate reboot.  In other words,
    we need to be able to download the firmware while our CAPWAP
    connection remains in the running state, and later be able to trigger
    a reboot, which will result in a switch to the new firmware.  It
    seems very likely that some 802.11 systems will require this feature,
    as well.  In fact, it is my understanding that some systems already
    do it this way.  But, the current state diagram and CAPWAP text don't
    seem to support this -- you leave the running state to move to the
    firmware download state and can only exit the firmware download state
    through the reboot state.

    (2) Clean separation between CAPWAP "base" protocol and 802.11-
    specific control messages.  Ideally, we'd like to see the CAPWAP base
    protocol and the 802.11-specific controls in separate documents, but
    it would also be possible for us to reference a portion of a
    monolithic document, as long as the base protocol is cleanly-enough
    separated from the 802.11-specific portions to allow us to
    unambiguously and normatively reference the base protocol.

    Would the CAPWAP WG support making these changes so that the
    EPCglobal RO WG can reuse this technology?

    Thanks,
    Margaret

    Margaret Wasserman
    Vice President
    ThingMagic
    margaret@thingmagic.com
    _________________________________________________________________
    To unsubscribe or modify your subscription options, please visit:
    http://lists.frascone.com/mailman/listinfo/capwap

    Archives: http://lists.frascone.com/pipermail/capwap


    _________________________________________________________________
    To unsubscribe or modify your subscription options, please visit:
    http://lists.frascone.com/mailman/listinfo/capwap

    Archives: http://lists.frascone.com/pipermail/capwap

    ------=_Part_4165_27586914.1152890969969-- --===============2074798641== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============2074798641==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jul 14 18:18:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1VnA-00018B-1k for capwap-archive@lists.ietf.org; Fri, 14 Jul 2006 18:05:48 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1VjL-0005FE-7c for capwap-archive@lists.ietf.org; Fri, 14 Jul 2006 18:01:53 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 99FC239803C for ; Fri, 14 Jul 2006 15:01:50 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 26C35430058 for ; Fri, 14 Jul 2006 15:01:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id DCFD9398017 for ; Fri, 14 Jul 2006 15:01:19 -0700 (PDT) Received: from nit.isi.edu (nit.isi.edu [128.9.160.116]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3A12139800D for ; Fri, 14 Jul 2006 15:01:15 -0700 (PDT) Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k6EM1CmP018303; Fri, 14 Jul 2006 15:01:12 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k6EM1CMh018302; Fri, 14 Jul 2006 15:01:12 -0700 Date: Fri, 14 Jul 2006 15:01:12 -0700 Message-Id: <200607142201.k6EM1CMh018302@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=-14.822 tagged_above=-999 required=7 tests=NO_REAL_NAME, USER_IN_DEF_WHITELIST X-Spam-Level: Cc: capwap@frascone.com, rfc-editor@rfc-editor.org Subject: [Capwap] RFC 4564 on Objectives for Control and Provisioning of Wireless Access Points (CAPWAP) X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 A new Request for Comments is now available in online RFC libraries. RFC 4564 Title: Objectives for Control and Provisioning of Wireless Access Points (CAPWAP) Author: S. Govindan, Ed., H. Cheng, ZH. Yao, WH. Zhou, L. Yang Status: Informational Date: July 2006 Mailbox: saravanan.govindan@sg.panasonic.com, hong.cheng@sg.panasonic.com, yaoth@huawei.com, zhouwenhui@chinamobile.com, lily.l.yang@intel.com Pages: 32 Characters: 64576 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-capwap-objectives-04.txt URL: http://www.rfc-editor.org/rfc/rfc4564.txt This document presents objectives for an interoperable protocol for the Control and Provisioning of Wireless Access Points (CAPWAP). The document aims to establish a set of focused requirements for the development and evaluation of a CAPWAP protocol. The objectives address architecture, operation, security, and network operator requirements that are necessary to enable interoperability among Wireless Local Area Network (WLAN) devices of alternative designs. This memo provides information for the Internet community. This document is a product of the Control And Provisioning of Wireless Access Points Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jul 14 18:42:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Vn9-00018B-U8 for capwap-archive@lists.ietf.org; Fri, 14 Jul 2006 18:05:47 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1VkC-0005GD-2L for capwap-archive@lists.ietf.org; Fri, 14 Jul 2006 18:02:45 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 58E3F398017 for ; Fri, 14 Jul 2006 15:02:43 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A3283430058 for ; Fri, 14 Jul 2006 15:01:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 89FFD39800D for ; Fri, 14 Jul 2006 15:01:20 -0700 (PDT) Received: from nit.isi.edu (nit.isi.edu [128.9.160.116]) by zoidberg.tigertech.net (Postfix) with ESMTP id F368D398029 for ; Fri, 14 Jul 2006 15:01:17 -0700 (PDT) Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k6EM1HDU018308; Fri, 14 Jul 2006 15:01:17 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k6EM1Hhh018307; Fri, 14 Jul 2006 15:01:17 -0700 Date: Fri, 14 Jul 2006 15:01:17 -0700 Message-Id: <200607142201.k6EM1Hhh018307@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=-14.822 tagged_above=-999 required=7 tests=NO_REAL_NAME, USER_IN_DEF_WHITELIST X-Spam-Level: Cc: capwap@frascone.com, rfc-editor@rfc-editor.org Subject: [Capwap] RFC 4565 on Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d A new Request for Comments is now available in online RFC libraries. RFC 4565 Title: Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols Author: D. Loher, D. Nelson, O. Volinsky, B. Sarikaya Status: Informational Date: July 2006 Mailbox: dplore@gmail.com, dnelson@enterasys.com, ovolinsky@colubris.com, sarikaya@ieee.org Pages: 31 Characters: 62929 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-capwap-eval-00.txt URL: http://www.rfc-editor.org/rfc/rfc4565.txt This document is a record of the process and findings of the Control and Provisioning of Wireless Access Points Working Group (CAPWAP WG) evaluation team. The evaluation team reviewed the 4 candidate protocols as they were submitted to the working group on June 26, 2005. his memo provides information for the Internet community. This document is a product of the Control And Provisioning of Wireless Access Points Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jul 15 11:49:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1mOG-0003CJ-BW for capwap-archive@lists.ietf.org; Sat, 15 Jul 2006 11:49:12 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1mOD-0007e8-RN for capwap-archive@lists.ietf.org; Sat, 15 Jul 2006 11:49:12 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id A5306144804F for ; Sat, 15 Jul 2006 08:49:05 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 514D5430018 for ; Sat, 15 Jul 2006 08:48:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 31F5D144802E for ; Sat, 15 Jul 2006 08:48:21 -0700 (PDT) X-Greylist-Status: Sender first seen 1 mon 4 days 03:01:58 ago Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by hermes.tigertech.net (Postfix) with ESMTP id 4B6AD1448014 for ; Sat, 15 Jul 2006 08:48:16 -0700 (PDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6FFgjGl009635 for ; Sat, 15 Jul 2006 11:42:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 15 Jul 2006 18:48:13 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] RFC 4564 on Objectives for Control and Provisioning ofWireless Access Points (CAPWAP) Thread-Index: AcankRuLSRcgW4vhR0KX2eIRzG/GEgAlLCog From: "Romascanu, Dan (Dan)" To: "capwap" X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [Capwap] FW: RFC 4564 on Objectives for Control and Provisioning ofWireless Access Points (CAPWAP) X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Congratulations to the editors, chairs and the whole WG for the publication of this RFC. Please continue to work hard together in order to complete successfully the charter of the Working Group. Dan -----Original Message----- From: rfc-editor@rfc-editor.org [mailto:rfc-editor@rfc-editor.org] Sent: Saturday, July 15, 2006 1:01 AM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: capwap@frascone.com; rfc-editor@rfc-editor.org Subject: [Capwap] RFC 4564 on Objectives for Control and Provisioning ofWireless Access Points (CAPWAP) A new Request for Comments is now available in online RFC libraries. RFC 4564 Title: Objectives for Control and Provisioning of Wireless Access Points (CAPWAP) Author: S. Govindan, Ed., H. Cheng, ZH. Yao, WH. Zhou, L. Yang Status: Informational Date: July 2006 Mailbox: saravanan.govindan@sg.panasonic.com, hong.cheng@sg.panasonic.com, yaoth@huawei.com, zhouwenhui@chinamobile.com, lily.l.yang@intel.com Pages: 32 Characters: 64576 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-capwap-objectives-04.txt URL: http://www.rfc-editor.org/rfc/rfc4564.txt This document presents objectives for an interoperable protocol for the Control and Provisioning of Wireless Access Points (CAPWAP). The document aims to establish a set of focused requirements for the development and evaluation of a CAPWAP protocol. The objectives address architecture, operation, security, and network operator requirements that are necessary to enable interoperability among Wireless Local Area Network (WLAN) devices of alternative designs. This memo provides information for the Internet community. This document is a product of the Control And Provisioning of Wireless Access Points Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jul 15 11:50:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1mPa-0003IH-J2 for capwap-archive@lists.ietf.org; Sat, 15 Jul 2006 11:50:34 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1mPZ-0007kJ-2V for capwap-archive@lists.ietf.org; Sat, 15 Jul 2006 11:50:34 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 68D441448029 for ; Sat, 15 Jul 2006 08:50:29 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 778F6430018 for ; Sat, 15 Jul 2006 08:49:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6ADAD39802E for ; Sat, 15 Jul 2006 08:49:42 -0700 (PDT) X-Greylist-Status: Sender first seen 1 mon 4 days 03:03:19 ago Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by zoidberg.tigertech.net (Postfix) with ESMTP id 88AD7398029 for ; Sat, 15 Jul 2006 08:49:39 -0700 (PDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6FFi8Wa010610 for ; Sat, 15 Jul 2006 11:44:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 15 Jul 2006 18:49:37 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] RFC 4565 on Evaluation of Candidate Control andProvisioning of Wireless Access Points (CAPWAP) Protocols Thread-Index: AcankTidjZWAnerQSIu1zKF7ZAp+OQAlOJCQ From: "Romascanu, Dan (Dan)" To: "capwap" X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [Capwap] FW: RFC 4565 on Evaluation of Candidate Control andProvisioning of Wireless Access Points (CAPWAP) Protocols X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Congratulations to the editors, chairs and the whole WG for the publication of this RFC. Please continue to work hard together in order to complete successfully the charter of the Working Group. Dan -----Original Message----- From: rfc-editor@rfc-editor.org [mailto:rfc-editor@rfc-editor.org] Sent: Saturday, July 15, 2006 1:01 AM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: capwap@frascone.com; rfc-editor@rfc-editor.org Subject: [Capwap] RFC 4565 on Evaluation of Candidate Control andProvisioning of Wireless Access Points (CAPWAP) Protocols A new Request for Comments is now available in online RFC libraries. RFC 4565 Title: Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols Author: D. Loher, D. Nelson, O. Volinsky, B. Sarikaya Status: Informational Date: July 2006 Mailbox: dplore@gmail.com, dnelson@enterasys.com, ovolinsky@colubris.com, sarikaya@ieee.org Pages: 31 Characters: 62929 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-capwap-eval-00.txt URL: http://www.rfc-editor.org/rfc/rfc4565.txt This document is a record of the process and findings of the Control and Provisioning of Wireless Access Points Working Group (CAPWAP WG) evaluation team. The evaluation team reviewed the 4 candidate protocols as they were submitted to the working group on June 26, 2005. his memo provides information for the Internet community. This document is a product of the Control And Provisioning of Wireless Access Points Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 17 01:57:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2M6O-0002YH-Ms for capwap-archive@lists.ietf.org; Mon, 17 Jul 2006 01:57:08 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2M6N-0000Q6-AA for capwap-archive@lists.ietf.org; Mon, 17 Jul 2006 01:57:08 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 18FE11448039 for ; Sun, 16 Jul 2006 22:57:03 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3521D430054 for ; Sun, 16 Jul 2006 22:56:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1D9A2398008 for ; Sun, 16 Jul 2006 22:56:26 -0700 (PDT) X-Greylist-Status: Sender first seen 1 mon 10 days 21:49:45 ago Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by zoidberg.tigertech.net (Postfix) with ESMTP id 633FF39800E for ; Sun, 16 Jul 2006 22:56:21 -0700 (PDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6H5q5tA018600 for ; Mon, 17 Jul 2006 01:52:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Jul 2006 08:56:17 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New co-chair for CAPWAP Thread-Index: AcapZbMlc04Jual/Qcm74B2Leiphrw== From: "Romascanu, Dan (Dan)" To: "capwap" X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [Capwap] New co-chair for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 We are glad to announce that following the open nomination process, interviews and discussions hold during the last week we nominated Margaret Wasserman as co-chair of CAPWAP. Together with Dorothy Gellert and Mahalingam Mani, Margaret will work towards reaching consensus and completing successfully the charter and goals of the CAPWAP WG. We thank Margaret for volunteering and accepting this responsibility and we wish her and her colleagues success in their mission. David Kessens and Dan Romascanu _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From wohu@gsassoc-inc.com Mon Jul 17 06:30:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2QMe-00005H-RF for capwap-archive@ietf.org; Mon, 17 Jul 2006 06:30:12 -0400 Received: from host54-66.pool8255.interbusiness.it ([82.55.66.54] helo=gsassoc-inc.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G2QMc-0001ym-9C for capwap-archive@ietf.org; Mon, 17 Jul 2006 06:30:12 -0400 Message-ID: <000001c6a98b$f410fc60$a76da8c0@bda6> Reply-To: "Hajar Wohlers" From: "Hajar Wohlers" To: capwap-archive@ietf.org Subject: naqiu VIjAGRA Date: Mon, 17 Jul 2006 03:29:58 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6A951.47B22460" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6A951.47B22460 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 VALjIUM VjIAGRA CIjALIS AMBjIEN =20 http://www.tavionmersa.com =20 O very well, said Thorin. Long ago in my grandfather Thrors time our family was driven out of the far North, and came back with all their wealth and their tools to this Mountain on the map. It had been ------=_NextPart_000_0001_01C6A951.47B22460 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hi,
     
    VALjIUM
    VjIAGRA
    CIjALIS
    AMBjIEN
     
    http://www.tavionmersa.com
     
    O very well, said Thorin. Long ago in my grandfather Thrors = time
    our family was driven out of the far North, and came back with all = their
    wealth and their tools to this Mountain on the map. It had = been
    ------=_NextPart_000_0001_01C6A951.47B22460-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 18 21:59:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G31Ld-0008LS-0L for capwap-archive@lists.ietf.org; Tue, 18 Jul 2006 21:59:37 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G31Lb-0001fJ-2O for capwap-archive@lists.ietf.org; Tue, 18 Jul 2006 21:59:36 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 02E621448007 for ; Tue, 18 Jul 2006 18:59:31 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 32D5F430064 for ; Tue, 18 Jul 2006 18:58:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0F2771448011 for ; Tue, 18 Jul 2006 18:58:42 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by hermes.tigertech.net (Postfix) with ESMTP id C75281448013 for ; Tue, 18 Jul 2006 18:58:39 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so86790pyu for ; Tue, 18 Jul 2006 18:58:39 -0700 (PDT) Received: by 10.35.89.10 with SMTP id r10mr349837pyl; Tue, 18 Jul 2006 18:58:38 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Tue, 18 Jul 2006 18:58:38 -0700 (PDT) Message-ID: <26140d940607181858o4c785a02v572afec2a101a686@mail.gmail.com> Date: Tue, 18 Jul 2006 21:58:38 -0400 From: "Michael Montemurro" To: "Saravanan Govindan" In-Reply-To: <5F09D220B62F79418461A978CA0921BDFF3FF3@pslexc01.psl.local> MIME-Version: 1.0 References: <5F09D220B62F79418461A978CA0921BDFF3FF3@pslexc01.psl.local> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0260287993==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 5df1f98f3253c63b673ea560243aa58f --===============0260287993== Content-Type: multipart/alternative; boundary="----=_Part_45134_23563627.1153274318885" ------=_Part_45134_23563627.1153274318885 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Saravanan, I've given some additional thought to your requirements and I believe it would require additional text as well as an additional negotiation between the WTP and the AC. We could separate the RSNA key management functions from the "classical" IEEE 802.1X authenticator functions and allow the WTP and AC negotiate wher= e these functions reside: The IEEE 802.1X authenticator functions would include the PMK derivation. The PMK would be passed to the WTP upon successful completion of the IEEE 802.1X authentication. The RSNA key management functions would include the 4-way handshake and the generation of GTK updates. I think this is a cleaner mechanism to address your requirements. Does this make sense to you? Cheers, Mike On 7/6/06, Saravanan Govindan wrote: > > Hi Mike, > > > > Thank you for the note. > > > I may not have been clear with my previous post. My request is to have > EAPoL frames generated at the AC alone =96 not at the WTP. > > > > My request is for designs where EAPoL frames are generated at the AC and > in those where the KeyRSC is maintained in the WTP. These designs were > highlighted in the Architecture Taxonomy. > > > > Specifically, I suggest that a CAPWAP message (it may be Add WLAN or > Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. This > EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of group k= ey > handshake) would have its KeyRSC field unassigned. Then when the WTP > receives this message, it fills in the right value of the KeyRSC, updates > the EAPoL frame and then transmit it to the wireless station. > > > > I hope this clarifies my suggestion. > > > Cheers, > > > Saravanan > > > > > > > > > ------------------------------ > > *From:* Michael Montemurro [mailto:montemurro.michael@gmail.com] > *Sent:* Tuesday, July 04, 2006 9:47 PM > *To:* Saravanan Govindan > *Cc:* capwap > > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderat= ions > > > > Saravanan, > > > > So, you would like to request that the WTP generate EAPoL-Key frames for > the 4-way handshake and the GTK update? > > > > The current draft assumes that all EAPoL-Key frames are generated at the > AC. > > > > Based on the following assumptions: > > 1) This feature would be for local-MAC only. > > 2) The 4-way handshake and the GTK handshake would originate from the sam= e > location. > > > > This would then require: > > 1) Negotiation between the WTP and the AC on where the 4-way handshake an= d > GTK updates are generated. > > 2) A modification to the updateWLAN message element to include the PMK > when a STA successfully associates. > > > > I've captured this as issue 199. > > > > On 7/3/06, *Saravanan Govindan* > wrote: > > Hi Mike, > > > > I had a chance to review the new draft. > > > > With regard to Issue 43, my understanding is that updates were made in > Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add > WLAN message element now allows the AC to send sequence counter values to > the WTP. So now, CAPWAP can support designs where the KeyRSC is maintaine= d > by the AC. > > > > My initial concern was with supporting designs where the KeyRSC is > maintained by the WTP. This is particularly important to manage the 4-Way > and Group-key handshakes. > > > > With this in mind, I think the protocol still requires support for design= s > where the KeyRSC is maintained by the WTP. Based on the current draft, th= is > support can be included by adding another field to the IEEE 802.11 Add > WLAN message element. This field would contain Message-3 EAPoL frame (for > 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). Thes= e > EAPoL frames would have unassigned fields for KeyRSC (since the value is > maintained by the WTP). > > > > I am also open to any alternatives to support this. > > > > Cheers, > > > Saravanan > > > > > > > > > ------------------------------ > > *From:* Michael Montemurro [mailto: montemurro.michael@gmail.com] > *Sent:* Tuesday, June 20, 2006 10:01 PM > *To:* Saravanan Govindan > *Cc:* Bob O'Hara (boohara); capwap > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderat= ions > > > > Saravanan, > > > > I've updated section 11.3 to deal with the GTK exchange and the handling > of the KeyRSC in draft -02 to address your comments. I also provided a > mechanism for the AC to transmit the keyRSC to the WTP using the updateWL= AN > message element as part of the Group Key exchange. > > > > We're finalizing the -02 draft this week and you should be able to look a= t > it when we post it later this week. > > > > Cheers, > > > > Mike > > > ------=_Part_45134_23563627.1153274318885 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
    Saravanan,
     
    I've given some additional thought to your requirements and I believe = it would require additional text as well as an additional negotiation betwe= en the WTP and the AC.
     
    We could separate the RSNA key management functions from the= "classical" IEEE 802.1X authenticator functions and allow the WT= P and AC negotiate where these functions reside:
     
    The IEEE 802.1X authenticator functions would include the PMK derivati= on. The PMK would be passed to the WTP upon successful completion of the IE= EE 802.1X authentication.
     
    The RSNA key management functions would include the 4-way handshake an= d the generation of GTK updates.
     
    I think this is a cleaner mechanism to address your requirements.
     
    Does this make sense to you?
     
    Cheers,
     
    Mike


     
    On 7/6/06, S= aravanan Govindan <Saravanan.Govindan@sg.panasonic.com> wrote:

    Hi Mike,

     

    Thank you for the note.


    I may not have been clear with my previous post. My request= is to have EAPoL frames generated at the AC alone =96 not at the WTP.

     

    My request is for designs where EAPoL frames are generated at t= he AC and in those where the KeyRSC is maintained in the WTP. These designs= were highlighted in the Architecture Taxonomy.=20

     

    Specifically, I suggest that a CAPWAP message (it may be Add WL= AN or Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. = This EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of grou= p key handshake) would have its KeyRSC field unassigned. Then when the WTP = receives this message, it fills in the right value of the KeyRSC, updates t= he EAPoL frame and then transmit it to the wireless station.=20

     

    I hope this clarifies my suggestion.


    Cheers,


    Saravanan

     

     

     

     

    From: Mich= ael Montemurro [mailto: montemurro.michael@gmail.com]
    Sent: Tuesday, July 04, 2006 9:47 PM
    To: Saravanan Govindan
    Cc: capwap


    Subject: Re: [Capwap] Clarification of Issue 43= : IEEE 802.11i Considerations

    On 7/3/06, Saravanan Govindan<= /span> < Saravanan.Govindan@sg.panasonic.com> wrote:

    Hi Mike,

     

    I had a chance to review the new draft.

     

    With regard to Issue 43, my understanding is that updates were = made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.= 11 Add WLAN message element now allows the AC to send sequence counter values= to the WTP. So now, CAPWAP can support designs where the KeyRSC is maintai= ned by the AC.

     

    My initial concern was with supporting designs where the KeyRSC= is maintained by the WTP. This is particularly important to manage the 4-W= ay and Group-key handshakes.=20

     

    With this in mind, I think the protocol still requires support = for designs where the KeyRSC is maintained by the WTP. Based on the current= draft, this support can be included by adding another field to the IEEE=20 802.11 Add WLAN message element. This field would contain Message-3 EAPoL f= rame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshak= e). These EAPoL frames would have unassigned fields for KeyRSC (since the v= alue is maintained by the WTP).=20

     

    I am also open to any alternatives to support this.

     

    Cheers,


    Saravanan

     

     

     

     

    From: Mich= ael Montemurro [mailto:=20 montemurro.michael@gmail.com]
    Sent: Tuesday, June 20, 2006 10:01 PM
    To: Saravanan Govindan
    Cc: Bob O'Hara (boohara); capwap
    Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Co= nsiderations

    ; Wed, 19 Jul 2006 01:11:13 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 47C12430064 for ; Wed, 19 Jul 2006 01:10:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 28143398030 for ; Wed, 19 Jul 2006 01:10:19 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8698739802B for ; Wed, 19 Jul 2006 01:10:15 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k6J8ACOF016268; Wed, 19 Jul 2006 17:10:12 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k6J8AEI28338; Wed, 19 Jul 2006 17:10:14 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with SMTP id k6J8AEW07598; Wed, 19 Jul 2006 17:10:14 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Jul 2006 16:12:11 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD010732DA@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Thread-Index: Acaq1to8Cs3UukavSKOQAyan6ZnhNAAKH6mA From: "Saravanan Govindan" To: "Michael Montemurro" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.425 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0289514750==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: de79fcc8fc416bc65a56904ab1b520f4 This is a multi-part message in MIME format. --===============0289514750== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AB0A.BB3DF3C0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6AB0A.BB3DF3C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike, =20 This is an interesting mechanism.=20 =20 I agree that a negotiation will be required to determine where the functions will occur. This will be inline with the objective.=20 =20 My concern, however, is that the mechanism suggests a new architecture for WTPs.=20 =20 I think we can consider the original case - where key management & "classical" authenticator functions remain at the AC and where the encryption function is at the WTP. I this case, the update required for the protocol would be a way to pass AC-generated EAPoL frames (Message 3 of 3-way handshake) to the WTP and then have the WTP update the EAPoL frames based on the KeyRSC that it manages.=20 =20 The total updates required for this would be =20 i. The initial negotiation to determine where encryption and authenticator functions are done ii. Corresponding change in key management (4-way handshake) in the case where encryption and authenticator are in different entities, i.e. encryption at WTP and authenticator at AC.=20 iii. Text to clarify the negotiation and subsequent operation =20 I look forward to your thoughts on this. =20 Cheers, Saravanan =20 =20 =20 =20 =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Wednesday, July 19, 2006 9:59 AM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 I've given some additional thought to your requirements and I believe it would require additional text as well as an additional negotiation between the WTP and the AC. =20 We could separate the RSNA key management functions from the "classical" IEEE 802.1X authenticator functions and allow the WTP and AC negotiate where these functions reside: =20 The IEEE 802.1X authenticator functions would include the PMK derivation. The PMK would be passed to the WTP upon successful completion of the IEEE 802.1X authentication. =20 The RSNA key management functions would include the 4-way handshake and the generation of GTK updates. =20 I think this is a cleaner mechanism to address your requirements. =20 Does this make sense to you?=20 =20 Cheers, =20 Mike =20 On 7/6/06, Saravanan Govindan wrote:=20 Hi Mike, =20 Thank you for the note.=20 I may not have been clear with my previous post. My request is to have EAPoL frames generated at the AC alone - not at the WTP.=20 =20 My request is for designs where EAPoL frames are generated at the AC and in those where the KeyRSC is maintained in the WTP. These designs were highlighted in the Architecture Taxonomy.=20 =20 Specifically, I suggest that a CAPWAP message (it may be Add WLAN or Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. This EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of group key handshake) would have its KeyRSC field unassigned. Then when the WTP receives this message, it fills in the right value of the KeyRSC, updates the EAPoL frame and then transmit it to the wireless station.=20 =20 I hope this clarifies my suggestion. Cheers, Saravanan =20 =20 =20 =20 ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com]=20 Sent: Tuesday, July 04, 2006 9:47 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 So, you would like to request that the WTP generate EAPoL-Key frames for the 4-way handshake and the GTK update? =20 The current draft assumes that all EAPoL-Key frames are generated at the AC. =20 Based on the following assumptions: 1) This feature would be for local-MAC only. 2) The 4-way handshake and the GTK handshake would originate from the same location. =20 This would then require: 1) Negotiation between the WTP and the AC on where the 4-way handshake and GTK updates are generated.=20 2) A modification to the updateWLAN message element to include the PMK when a STA successfully associates. =20 I've captured this as issue 199. =20 On 7/3/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com > wrote:=20 Hi Mike, =20 I had a chance to review the new draft.=20 =20 With regard to Issue 43, my understanding is that updates were made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN message element now allows the AC to send sequence counter values to the WTP. So now, CAPWAP can support designs where the KeyRSC is maintained by the AC.=20 =20 My initial concern was with supporting designs where the KeyRSC is maintained by the WTP. This is particularly important to manage the 4-Way and Group-key handshakes.=20 =20 With this in mind, I think the protocol still requires support for designs where the KeyRSC is maintained by the WTP. Based on the current draft, this support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames would have unassigned fields for KeyRSC (since the value is maintained by the WTP).=20 =20 I am also open to any alternatives to support this.=20 =20 Cheers, Saravanan =20 =20 =20 =20 ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com]=20 Sent: Tuesday, June 20, 2006 10:01 PM=20 To: Saravanan Govindan Cc: Bob O'Hara (boohara); capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 I've updated section 11.3 to deal with the GTK exchange and the handling of the KeyRSC in draft -02 to address your comments. I also provided a mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message element as part of the Group Key exchange.=20 =20 We're finalizing the -02 draft this week and you should be able to look at it when we post it later this week. =20 Cheers, =20 Mike =20 =20 ------_=_NextPart_001_01C6AB0A.BB3DF3C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Mike,

     

    This is an interesting mechanism. =

     

    I agree that a negotiation will be required to = determine where the functions will occur. This will be inline with the objective. =

     

    My concern, however, is that the mechanism suggests a = new architecture for WTPs.

     

    I think we can consider the original case – = where key management & “classical” authenticator functions remain = at the AC and where the encryption function is at the WTP. I this case, the = update required for the protocol would be a way to pass AC-generated EAPoL = frames (Message 3 of 3-way handshake) to the WTP and then have the WTP update the EAPoL = frames based on the KeyRSC that it manages.

     

    The total updates required for this would = be

     

    i.          = The initial negotiation to determine where encryption and authenticator = functions are done

    ii. =          Corresponding change in key management (4-way handshake) in the case where encryption = and authenticator are in different entities, i.e. encryption at WTP and authenticator at = AC.

    iii.         = Text to clarify the negotiation and subsequent = operation

     

    I look forward to your thoughts on = this.

     

    Cheers,


    Saravanan

     

     

     

     

     

    From: = Michael Montemurro [mailto:montemurro.michael@gmail.com]
    Sent: Wednesday, July 19, = 2006 9:59 AM
    To: Saravanan = Govindan
    Cc: capwap
    Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

     

    Saravanan,

     

    I've given some additional thought to your requirements and I = believe it would require additional text as well as an additional negotiation = between the WTP and the AC.

     

    We could separate the RSNA key management functions = from the "classical" IEEE 802.1X authenticator functions and allow the = WTP and AC negotiate where these functions reside:

     

    The IEEE 802.1X authenticator functions would include the PMK derivation. The PMK would be passed to the WTP upon successful = completion of the IEEE 802.1X authentication.

     

    The RSNA key management functions would include the 4-way = handshake and the generation of GTK updates.

     

    I think this is a cleaner mechanism to address your = requirements.

     

    Does this make sense to you?

     

    Cheers,

     

    Mike



     

    On 7/6/06, Saravanan Govindan <Saravanan.Govindan@sg= .panasonic.com> wrote:

    Hi Mike,

     

    Thank you for the note.


    I may not have been clear with my previous post. My request is to have = EAPoL frames generated at the AC alone – not at the WTP. =

     

    My request is for designs where EAPoL frames are generated at the AC and in = those where the KeyRSC is maintained in the WTP. These designs were = highlighted in the Architecture Taxonomy.

     

    Specifically, I suggest that a CAPWAP message (it may be Add WLAN or Update WLAN) be = able to carry an EAPoL frame from the AC to the WTP. This EAPoL frame (for = Message 3 of 4-way handshake or for Message 1 of group key handshake) would have its = KeyRSC field unassigned. Then when the WTP receives this message, it fills in = the right value of the KeyRSC, updates the EAPoL frame and then transmit it = to the wireless station.

     

    I hope this clarifies my suggestion.


    Cheers,


    Saravanan

     

     

     

     

    From: Michael Montemurro = [mailto: montemurro.michael@gmail.co= m]
    Sent: Tuesday, July 04, = 2006 9:47 PM
    To: Saravanan = Govindan
    Cc: = capwap


    Subject: = Re: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

     

    Saravanan,

     

    So, you would like to request that the WTP generate EAPoL-Key frames for the = 4-way handshake and the GTK update?

     

    The current draft assumes that all EAPoL-Key frames are generated at the = AC.

     

    Based on the following assumptions:

    1) This feature would be for local-MAC only.

    2) The 4-way handshake and the GTK handshake would originate from the same = location.

     

    This would then require:

    1) Negotiation between the WTP and the AC on where the 4-way handshake and = GTK updates are generated.

    2) A modification to the updateWLAN message element to include the PMK = when a STA successfully associates.

     

    I've captured this as issue 199.

     

    On 7/3/06, Saravanan = Govindan < Saravanan.Govindan@sg.panasonic.com> wrote: =

    Hi Mike,

     

    I had a chance to review the new draft.

     

    With regard to Issue 43, my understanding is that updates were made in = Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN = message element now allows the AC to send sequence counter values to the WTP. So = now, CAPWAP can support designs where the KeyRSC is maintained by the AC. =

     

    My initial concern was with supporting designs where the KeyRSC is = maintained by the WTP. This is particularly important to manage the 4-Way and = Group-key handshakes.

     

    With this in mind, I think the protocol still requires support for designs = where the KeyRSC is maintained by the WTP. Based on the current draft, this = support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way = handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames = would have unassigned fields for KeyRSC (since the value is maintained by the = WTP).

     

    I am also open to any alternatives to support this. =

     

    Cheers,


    Saravanan

     

     

     

     

    From: Michael Montemurro = [mailto: montemurro.michael@gmail.co= m]
    Sent: Tuesday, June 20, = 2006 10:01 PM
    To: Saravanan = Govindan
    Cc: Bob O'Hara (boohara); = capwap
    Subject: Re: [Capwap] = Clarification of Issue 43: IEEE 802.11i Considerations

     

    Saravanan,

     

    I've updated section 11.3 to deal with the GTK exchange and the handling of = the KeyRSC in draft -02 to address your comments. I also provided a = mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message = element as part of the Group Key exchange.

     

    We're finalizing the -02 draft this week and you should be able to look at it = when we post it later this week.

     

    Cheers,

     

    Mike

     

     

    ------_=_NextPart_001_01C6AB0A.BB3DF3C0-- --===============0289514750== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0289514750==-- From millopetar@creny.org Wed Jul 19 18:15:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3KK6-0006ss-Nn for capwap-archive@ietf.org; Wed, 19 Jul 2006 18:15:18 -0400 Received: from [201.240.1.163] (helo=creny.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3KJy-0006d8-8Z for capwap-archive@ietf.org; Wed, 19 Jul 2006 18:15:18 -0400 Message-ID: <000001c6ab80$c7e38c60$c91ba8c0@dxi81> Reply-To: "Petar Millward" From: "Petar Millward" To: capwap-archive@ietf.org Subject: Re: VnIAGRnA eeieq Date: Wed, 19 Jul 2006 15:15:02 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6AB46.1B84B460" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.6 (++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6AB46.1B84B460 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 PUxRCHASE VIxAGxRA from 3 , 30 $ http://www.fectoppor.com =20 _____ =20 I was. Did I miss the point somehow? I asked. I feel sorry for the dog, Floyd said. We both looked at Steengo who ------=_NextPart_000_0001_01C6AB46.1B84B460 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hi,
     

    PUxRCHASE VIxAGxRA from 3 , 30 $
    http://www.fectoppor.com

    =
     
    I was.
    Did I miss the point somehow? I asked.
    I feel sorry for the dog, Floyd said. We both looked at Steengo = who
    ------=_NextPart_000_0001_01C6AB46.1B84B460-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 19 18:36:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Kem-0006vn-Kc for capwap-archive@lists.ietf.org; Wed, 19 Jul 2006 18:36:40 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3KZi-0007aD-FL for capwap-archive@lists.ietf.org; Wed, 19 Jul 2006 18:31:28 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id D8A6639803B for ; Wed, 19 Jul 2006 15:31:25 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E9AC9430063 for ; Wed, 19 Jul 2006 15:30:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CF60B1448006 for ; Wed, 19 Jul 2006 15:30:41 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id 529EA1448008 for ; Wed, 19 Jul 2006 15:30:35 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 19 Jul 2006 15:30:35 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6JMUZj5031340; Wed, 19 Jul 2006 15:30:35 -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 k6JMUYiD002517; Wed, 19 Jul 2006 15:30:34 -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.1830); Wed, 19 Jul 2006 15:30:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Jul 2006 15:30:27 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202327662@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Thread-Index: Acaq1wHFltx/sTmjR9+5w4E1E3S4UAAmXkXA From: "Pat Calhoun (pacalhou)" To: "Michael Montemurro" , "Saravanan Govindan" X-OriginalArrivalTime: 19 Jul 2006 22:30:27.0897 (UTC) FILETIME=[EF816290:01C6AB82] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 45 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1981103377==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c6c6a408c8e09c950064e70d807ac007 This is a multi-part message in MIME format. --===============1981103377== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AB82.EF4B497B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6AB82.EF4B497B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My personal feeling is that this should be considered a "nice to have", and therefore show up in the "wish" tracker category. Given all of the work we have ahead of us, I don't believe there is an urgent need to support this mode of operation, as the current protocol achieves our objectives. So waiting for a future version of the protocol would be my suggestion. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Tuesday, July 18, 2006 6:59 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =09 =09 Saravanan, =20 I've given some additional thought to your requirements and I believe it would require additional text as well as an additional negotiation between the WTP and the AC. =20 We could separate the RSNA key management functions from the "classical" IEEE 802.1X authenticator functions and allow the WTP and AC negotiate where these functions reside: =20 The IEEE 802.1X authenticator functions would include the PMK derivation. The PMK would be passed to the WTP upon successful completion of the IEEE 802.1X authentication. =20 The RSNA key management functions would include the 4-way handshake and the generation of GTK updates. =20 I think this is a cleaner mechanism to address your requirements. =20 Does this make sense to you?=20 =20 Cheers, =20 Mike =20 On 7/6/06, Saravanan Govindan wrote:=20 Hi Mike, =20 Thank you for the note.=20 =09 I may not have been clear with my previous post. My request is to have EAPoL frames generated at the AC alone - not at the WTP.=20 =20 My request is for designs where EAPoL frames are generated at the AC and in those where the KeyRSC is maintained in the WTP. These designs were highlighted in the Architecture Taxonomy.=20 =20 Specifically, I suggest that a CAPWAP message (it may be Add WLAN or Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. This EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of group key handshake) would have its KeyRSC field unassigned. Then when the WTP receives this message, it fills in the right value of the KeyRSC, updates the EAPoL frame and then transmit it to the wireless station.=20 =20 I hope this clarifies my suggestion. =09 Cheers, =09 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com]=20 Sent: Tuesday, July 04, 2006 9:47 PM To: Saravanan Govindan Cc: capwap =09 Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =09 =20 Saravanan, =20 So, you would like to request that the WTP generate EAPoL-Key frames for the 4-way handshake and the GTK update? =20 The current draft assumes that all EAPoL-Key frames are generated at the AC. =20 Based on the following assumptions: 1) This feature would be for local-MAC only. 2) The 4-way handshake and the GTK handshake would originate from the same location. =20 This would then require: 1) Negotiation between the WTP and the AC on where the 4-way handshake and GTK updates are generated.=20 2) A modification to the updateWLAN message element to include the PMK when a STA successfully associates. =20 I've captured this as issue 199. =09 =20 On 7/3/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com > wrote:=20 Hi Mike, =20 I had a chance to review the new draft.=20 =20 With regard to Issue 43, my understanding is that updates were made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN message element now allows the AC to send sequence counter values to the WTP. So now, CAPWAP can support designs where the KeyRSC is maintained by the AC.=20 =20 My initial concern was with supporting designs where the KeyRSC is maintained by the WTP. This is particularly important to manage the 4-Way and Group-key handshakes.=20 =20 With this in mind, I think the protocol still requires support for designs where the KeyRSC is maintained by the WTP. Based on the current draft, this support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames would have unassigned fields for KeyRSC (since the value is maintained by the WTP).=20 =20 I am also open to any alternatives to support this.=20 =20 Cheers, =09 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com]=20 Sent: Tuesday, June 20, 2006 10:01 PM=20 To: Saravanan Govindan Cc: Bob O'Hara (boohara); capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 I've updated section 11.3 to deal with the GTK exchange and the handling of the KeyRSC in draft -02 to address your comments. I also provided a mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message element as part of the Group Key exchange.=20 =20 We're finalizing the -02 draft this week and you should be able to look at it when we post it later this week. =20 Cheers, =20 Mike =20 ------_=_NextPart_001_01C6AB82.EF4B497B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    My=20 personal feeling is that this should be considered a "nice to have", and = therefore show up in the "wish" tracker category. Given all of the work = we have=20 ahead of us, I don't believe there is an urgent need to support this = mode of=20 operation, as the current protocol achieves our objectives. So waiting = for a=20 future version of the protocol would be my = suggestion.
     

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

     

    From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
    Sent: Tuesday, July = 18, 2006=20 6:59 PM
    To: Saravanan Govindan
    Cc:=20 capwap
    Subject: Re: [Capwap] Clarification of Issue 43: IEEE = 802.11i=20 Considerations

    Saravanan,
     
    I've given some additional thought to your requirements and I = believe it=20 would require additional text as well as an additional negotiation = between the=20 WTP and the AC.
     
    We could separate the RSNA key management functions = from the=20 "classical" IEEE 802.1X authenticator functions and allow the WTP and = AC=20 negotiate where these functions reside:
     
    The IEEE 802.1X authenticator functions would include the PMK = derivation.=20 The PMK would be passed to the WTP upon successful completion of the = IEEE=20 802.1X authentication.
     
    The RSNA key management functions would include the 4-way = handshake and=20 the generation of GTK updates.
     
    I think this is a cleaner mechanism to address your = requirements.
     
    Does this make sense to you?
     
    Cheers,
     
    Mike


     
    On 7/6/06, Saravanan=20 Govindan <Saravanan.Govindan@sg= .panasonic.com>=20 wrote:=20

    Hi = Mike,

     

    Thank you for the = note.=20


    I may not have = been clear=20 with my previous post. My request is to have EAPoL frames generated = at the=20 AC alone – not at the WTP.

     

    My request is for = designs where=20 EAPoL frames are generated at the AC and in those where the KeyRSC = is=20 maintained in the WTP. These designs were highlighted in the = Architecture=20 Taxonomy.

     

    Specifically, I = suggest that a=20 CAPWAP message (it may be Add WLAN or Update WLAN) be able to carry = an EAPoL=20 frame from the AC to the WTP. This EAPoL frame (for Message 3 of = 4-way=20 handshake or for Message 1 of group key handshake) would have its = KeyRSC=20 field unassigned. Then when the WTP receives this message, it fills = in the=20 right value of the KeyRSC, updates the EAPoL frame and then transmit = it to=20 the wireless station.

     

    I hope this clarifies = my=20 suggestion.


    Cheers,


    Saravanan

     

     

     

     

    From:=20 Michael Montemurro [mailto: montemurro.michael@gmail.com]
    Sent:     Tuesday, July 04, 2006 = 9:47=20 PM
    To: Saravanan=20 Govindan
    Cc:=20 capwap


    Subject:     Re: [Capwap] = Clarification of=20 Issue 43: IEEE 802.11i Considerations

     

    Saravanan,

     

    So, you=20 would like to request that the WTP generate EAPoL-Key frames for the = 4-way=20 handshake and the GTK update?

     

    The=20 current draft assumes that all EAPoL-Key frames are generated at the = AC.

     

    Based=20 on the following assumptions:

    1) This=20 feature would be for local-MAC only.

    2) The=20 4-way handshake and the GTK handshake would originate from the same=20 location.

     

    This=20 would then require:

    1)=20 Negotiation between the WTP and the AC on where the 4-way handshake = and GTK=20 updates are generated.

    2) A=20 modification to the updateWLAN message element to include the = PMK when=20 a STA successfully associates.

     

    I've=20 captured this as issue 199.

     

    On 7/3/06, Saravanan Govindan < = Saravanan.Govindan@sg.panasonic.com> = wrote:

    Hi = Mike,

     

    I had a chance to = review the new=20 draft.

     

    With regard to Issue = 43, my=20 understanding is that updates were made in Section 11.9.1 (IEEE = 802.11 Add=20 WLAN). In particular, the IEEE 802.11 Add WLAN message element now = allows=20 the AC to send sequence counter values to the WTP. So now, CAPWAP = can=20 support designs where the KeyRSC is maintained by the AC. =

     

    My initial concern was = with=20 supporting designs where the KeyRSC is maintained by the WTP. This = is=20 particularly important to manage the 4-Way and Group-key handshakes. =

     

    With this in mind, I = think the=20 protocol still requires support for designs where the KeyRSC is = maintained=20 by the WTP. Based on the current draft, this support can be included = by=20 adding another field to the IEEE 802.11 Add WLAN message element. = This field=20 would contain Message-3 EAPoL frame (for 4-Way handshake) or = Message-1 EAPoL=20 frame (for Group-key handshake). These EAPoL frames would have = unassigned=20 fields for KeyRSC (since the value is maintained by the WTP).=20

     

    I am also open to any=20 alternatives to support this.

     

    Cheers,


    Saravanan

     

     

     

     

    From:=20 Michael Montemurro [mailto: montemurro.michael@gmail.com]
    Sent:     Tuesday, June 20, 2006 = 10:01 PM=20
    To: Saravanan=20 Govindan
    Cc: Bob = O'Hara=20 (boohara); capwap
    Subject:=20 Re: [Capwap] Clarification of Issue 43: IEEE 802.11i=20 Considerations

     

    Saravanan,

     

    I've=20 updated section 11.3 to deal with the GTK exchange and the handling = of the=20 KeyRSC in draft -02 to address your comments. I also provided a = mechanism=20 for the AC to transmit the keyRSC to the WTP using the updateWLAN = message=20 element as part of the Group Key exchange.

     

    We're=20 finalizing the -02 draft this week and you should be able to look at = it when=20 we post it later this week.

     

    Cheers,

     

    Mike

     

    =

    = ------_=_NextPart_001_01C6AB82.EF4B497B-- --===============1981103377== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1981103377==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 20 02:36:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3S8z-00013C-2w for capwap-archive@lists.ietf.org; Thu, 20 Jul 2006 02:36:21 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3S8f-0005Tj-9i for capwap-archive@lists.ietf.org; Thu, 20 Jul 2006 02:36:04 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id ECD9A1448034 for ; Wed, 19 Jul 2006 23:35:56 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id ECEB143005F for ; Wed, 19 Jul 2006 23:34:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D58991448015 for ; Wed, 19 Jul 2006 23:34:52 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 34B9D1448002 for ; Wed, 19 Jul 2006 23:34:48 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id k6K6Yj3x015492; Thu, 20 Jul 2006 15:34:45 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k6K6Yjk00035; Thu, 20 Jul 2006 15:34:45 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with SMTP id k6K6YjN02519; Thu, 20 Jul 2006 15:34:45 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Jul 2006 14:36:47 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD01073414@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Thread-Index: Acaq1wHFltx/sTmjR9+5w4E1E3S4UAAmXkXAABUulxA= From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , "Michael Montemurro" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1065801797==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 380e61196c1a6bc558435defe73f6563 This is a multi-part message in MIME format. --===============1065801797== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6ABC6.90C69832" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6ABC6.90C69832 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like to clarify that this is indeed a "mandatory" objective and needs to be integral to CAPWAP. Based on the exchanges so far, I think support for this feature can be easily incorporated in to the protocol.=20 =20 We know the protocol needs this (from the requirement) and we know how to do it (from the proposals), so let's just do it and move forward.=20 =20 Saravanan =20 =20 =20 =20 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, July 20, 2006 6:30 AM To: Michael Montemurro; Saravanan Govindan Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 My personal feeling is that this should be considered a "nice to have", and therefore show up in the "wish" tracker category. Given all of the work we have ahead of us, I don't believe there is an urgent need to support this mode of operation, as the current protocol achieves our objectives. So waiting for a future version of the protocol would be my suggestion. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Tuesday, July 18, 2006 6:59 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, =20 I've given some additional thought to your requirements and I believe it would require additional text as well as an additional negotiation between the WTP and the AC. =20 We could separate the RSNA key management functions from the "classical" IEEE 802.1X authenticator functions and allow the WTP and AC negotiate where these functions reside: =20 The IEEE 802.1X authenticator functions would include the PMK derivation. The PMK would be passed to the WTP upon successful completion of the IEEE 802.1X authentication. =20 The RSNA key management functions would include the 4-way handshake and the generation of GTK updates. =20 I think this is a cleaner mechanism to address your requirements. =20 Does this make sense to you?=20 =20 Cheers, =20 Mike =09 =09 =20 On 7/6/06, Saravanan Govindan wrote:=20 Hi Mike, =20 Thank you for the note.=20 =09 I may not have been clear with my previous post. My request is to have EAPoL frames generated at the AC alone - not at the WTP.=20 =20 My request is for designs where EAPoL frames are generated at the AC and in those where the KeyRSC is maintained in the WTP. These designs were highlighted in the Architecture Taxonomy.=20 =20 Specifically, I suggest that a CAPWAP message (it may be Add WLAN or Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. This EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of group key handshake) would have its KeyRSC field unassigned. Then when the WTP receives this message, it fills in the right value of the KeyRSC, updates the EAPoL frame and then transmit it to the wireless station.=20 =20 I hope this clarifies my suggestion. =09 Cheers, =09 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com]=20 Sent: Tuesday, July 04, 2006 9:47 PM To: Saravanan Govindan Cc: capwap =09 Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 So, you would like to request that the WTP generate EAPoL-Key frames for the 4-way handshake and the GTK update? =20 The current draft assumes that all EAPoL-Key frames are generated at the AC. =20 Based on the following assumptions: 1) This feature would be for local-MAC only. 2) The 4-way handshake and the GTK handshake would originate from the same location. =20 This would then require: 1) Negotiation between the WTP and the AC on where the 4-way handshake and GTK updates are generated.=20 2) A modification to the updateWLAN message element to include the PMK when a STA successfully associates. =20 I've captured this as issue 199. =09 =20 On 7/3/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com > wrote:=20 Hi Mike, =20 I had a chance to review the new draft.=20 =20 With regard to Issue 43, my understanding is that updates were made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN message element now allows the AC to send sequence counter values to the WTP. So now, CAPWAP can support designs where the KeyRSC is maintained by the AC.=20 =20 My initial concern was with supporting designs where the KeyRSC is maintained by the WTP. This is particularly important to manage the 4-Way and Group-key handshakes.=20 =20 With this in mind, I think the protocol still requires support for designs where the KeyRSC is maintained by the WTP. Based on the current draft, this support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames would have unassigned fields for KeyRSC (since the value is maintained by the WTP).=20 =20 I am also open to any alternatives to support this.=20 =20 Cheers, =09 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com]=20 Sent: Tuesday, June 20, 2006 10:01 PM=20 To: Saravanan Govindan Cc: Bob O'Hara (boohara); capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 I've updated section 11.3 to deal with the GTK exchange and the handling of the KeyRSC in draft -02 to address your comments. I also provided a mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message element as part of the Group Key exchange.=20 =20 We're finalizing the -02 draft this week and you should be able to look at it when we post it later this week. =20 Cheers, =20 Mike =20 =20 ------_=_NextPart_001_01C6ABC6.90C69832 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I’d like to clarify that this is indeed a = “mandatory” objective and needs to be integral to CAPWAP. Based on the exchanges so = far, I think support for this feature can be easily incorporated in to the = protocol.

     

    We know the protocol needs this (from the = requirement) and we know how to do it (from the proposals), so let’s just do it and = move forward.

     

    Saravanan

     

     

     

     

    From: Pat = Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
    Sent: Thursday, July 20, = 2006 6:30 AM
    To: Michael Montemurro; = Saravanan Govindan
    Cc: capwap
    Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

     

    My personal feeling is that this = should be considered a "nice to have", and therefore show up in the "wish" tracker category. Given all of the work we have ahead = of us, I don't believe there is an urgent need to support this mode of operation, = as the current protocol achieves our objectives. So waiting for a future = version of the protocol would be my suggestion.

     

    Pat Calhoun
    CTO, Wireless Networking Business Unit
    Cisco Systems

     

     

    From: Michael Montemurro [mailto:montemurro.michael@gmail.com]
    Sent: Tuesday, July 18, = 2006 6:59 PM
    To: Saravanan = Govindan
    Cc: capwap
    Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

    Saravanan,

     

    I've given some additional thought to your requirements and I = believe it would require additional text as well as an additional negotiation = between the WTP and the AC.

     

    We could separate the RSNA key management functions = from the "classical" IEEE 802.1X authenticator functions and allow the = WTP and AC negotiate where these functions reside:

     

    The IEEE 802.1X authenticator functions would include the PMK derivation. The PMK would be passed to the WTP upon successful = completion of the IEEE 802.1X authentication.

     

    The RSNA key management functions would include the 4-way = handshake and the generation of GTK updates.

     

    I think this is a cleaner mechanism to address your = requirements.

     

    Does this make sense to you?

     

    Cheers,

     

    Mike



     

    On 7/6/06, Saravanan Govindan <Saravanan.Govindan@sg= .panasonic.com> wrote:

    Hi Mike,

     

    Thank you for the note.


    I may not have been clear with my previous post. My request is to have = EAPoL frames generated at the AC alone – not at the WTP. =

     

    My request is for designs where EAPoL frames are generated at the AC and in = those where the KeyRSC is maintained in the WTP. These designs were = highlighted in the Architecture Taxonomy.

     

    Specifically, I suggest that a CAPWAP message (it may be Add WLAN or Update WLAN) be = able to carry an EAPoL frame from the AC to the WTP. This EAPoL frame (for Message 3 = of 4-way handshake or for Message 1 of group key handshake) would have its KeyRSC = field unassigned. Then when the WTP receives this message, it fills in the = right value of the KeyRSC, updates the EAPoL frame and then transmit it to the wireless station.

     

    I hope this clarifies my suggestion.


    Cheers,


    Saravanan

     

     

     

     

    From: Michael Montemurro = [mailto: montemurro.michael@gmail.co= m]
    Sent: Tuesday, July 04, = 2006 9:47 PM
    To: Saravanan = Govindan
    Cc: = capwap


    Subject: = Re: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

     

    Saravanan,

     

    So, you would like to request that the WTP generate EAPoL-Key frames for the = 4-way handshake and the GTK update?

     

    The current draft assumes that all EAPoL-Key frames are generated at the = AC.

     

    Based on the following assumptions:

    1) This feature would be for local-MAC only.

    2) The 4-way handshake and the GTK handshake would originate from the same = location.

     

    This would then require:

    1) Negotiation between the WTP and the AC on where the 4-way handshake and = GTK updates are generated.

    2) A modification to the updateWLAN message element to include the PMK = when a STA successfully associates.

     

    I've captured this as issue 199.

     

    On 7/3/06, Saravanan = Govindan < Saravanan.Govindan@sg.panasonic.com> wrote: =

    Hi Mike,

     

    I had a chance to review the new draft.

     

    With regard to Issue 43, my understanding is that updates were made in = Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN = message element now allows the AC to send sequence counter values to the WTP. So = now, CAPWAP can support designs where the KeyRSC is maintained by the AC. =

     

    My initial concern was with supporting designs where the KeyRSC is = maintained by the WTP. This is particularly important to manage the 4-Way and = Group-key handshakes.

     

    With this in mind, I think the protocol still requires support for designs = where the KeyRSC is maintained by the WTP. Based on the current draft, this = support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way = handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames = would have unassigned fields for KeyRSC (since the value is maintained by the = WTP).

     

    I am also open to any alternatives to support this. =

     

    Cheers,


    Saravanan

     

     

     

     

    From: Michael Montemurro = [mailto: montemurro.michael@gmail.co= m]
    Sent: Tuesday, June 20, = 2006 10:01 PM
    To: Saravanan = Govindan
    Cc: Bob O'Hara (boohara); = capwap
    Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

     

    Saravanan,

     

    I've updated section 11.3 to deal with the GTK exchange and the handling of = the KeyRSC in draft -02 to address your comments. I also provided a = mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message = element as part of the Group Key exchange.

     

    We're finalizing the -02 draft this week and you should be able to look at it = when we post it later this week.

     

    Cheers,

     

    Mike

     

     

    ------_=_NextPart_001_01C6ABC6.90C69832-- --===============1065801797== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1065801797==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 20 11:34:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3aY1-0005rw-4I for capwap-archive@lists.ietf.org; Thu, 20 Jul 2006 11:34:45 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3aS4-0003kf-2T for capwap-archive@lists.ietf.org; Thu, 20 Jul 2006 11:28:40 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5147439806E for ; Thu, 20 Jul 2006 08:28:35 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 22D03430063 for ; Thu, 20 Jul 2006 08:27:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 01B8A431555 for ; Thu, 20 Jul 2006 08:27:25 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by hermes.tigertech.net (Postfix) with ESMTP id 78C81430730 for ; Thu, 20 Jul 2006 08:27:20 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2006 08:27:20 -0700 X-IronPort-AV: i="4.07,163,1151910000"; d="scan'208,217"; a="330350302:sNHT68883240" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6KFRJOe001515; Thu, 20 Jul 2006 08:27:19 -0700 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 k6KFRI2D003573; Thu, 20 Jul 2006 08:27:19 -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.1830); Thu, 20 Jul 2006 08:27:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Jul 2006 08:27:19 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2023277ED@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Thread-Index: Acaq1wHFltx/sTmjR9+5w4E1E3S4UAAmXkXAABUulxAAEup7QA== From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , "Michael Montemurro" X-OriginalArrivalTime: 20 Jul 2006 15:27:18.0596 (UTC) FILETIME=[FCB74040:01C6AC10] Authentication-Results: sj-dkim-4.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1844474091==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f1e116c42859d8542c08251690b5b182 This is a multi-part message in MIME format. --===============1844474091== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AC10.FC8B69C1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6AC10.FC8B69C1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like to understand how you've interpreted this feature as being "mandatory". The current spec supports 802.11i, in both modes of operation that we've agreed to, which is Split and Local MAC. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, July 19, 2006 11:37 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =09 =09 I'd like to clarify that this is indeed a "mandatory" objective and needs to be integral to CAPWAP. Based on the exchanges so far, I think support for this feature can be easily incorporated in to the protocol.=20 =20 We know the protocol needs this (from the requirement) and we know how to do it (from the proposals), so let's just do it and move forward.=20 =20 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, July 20, 2006 6:30 AM To: Michael Montemurro; Saravanan Govindan Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 My personal feeling is that this should be considered a "nice to have", and therefore show up in the "wish" tracker category. Given all of the work we have ahead of us, I don't believe there is an urgent need to support this mode of operation, as the current protocol achieves our objectives. So waiting for a future version of the protocol would be my suggestion. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Tuesday, July 18, 2006 6:59 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, =20 I've given some additional thought to your requirements and I believe it would require additional text as well as an additional negotiation between the WTP and the AC. =20 We could separate the RSNA key management functions from the "classical" IEEE 802.1X authenticator functions and allow the WTP and AC negotiate where these functions reside: =20 The IEEE 802.1X authenticator functions would include the PMK derivation. The PMK would be passed to the WTP upon successful completion of the IEEE 802.1X authentication. =20 The RSNA key management functions would include the 4-way handshake and the generation of GTK updates. =20 I think this is a cleaner mechanism to address your requirements. =20 Does this make sense to you?=20 =20 Cheers, =20 Mike =09 =09 =20 On 7/6/06, Saravanan Govindan wrote:=20 Hi Mike, =20 Thank you for the note.=20 =09 I may not have been clear with my previous post. My request is to have EAPoL frames generated at the AC alone - not at the WTP.=20 =20 My request is for designs where EAPoL frames are generated at the AC and in those where the KeyRSC is maintained in the WTP. These designs were highlighted in the Architecture Taxonomy.=20 =20 Specifically, I suggest that a CAPWAP message (it may be Add WLAN or Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. This EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of group key handshake) would have its KeyRSC field unassigned. Then when the WTP receives this message, it fills in the right value of the KeyRSC, updates the EAPoL frame and then transmit it to the wireless station.=20 =20 I hope this clarifies my suggestion. =09 Cheers, =09 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com]=20 Sent: Tuesday, July 04, 2006 9:47 PM To: Saravanan Govindan Cc: capwap =09 Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 So, you would like to request that the WTP generate EAPoL-Key frames for the 4-way handshake and the GTK update? =20 The current draft assumes that all EAPoL-Key frames are generated at the AC. =20 Based on the following assumptions: 1) This feature would be for local-MAC only. 2) The 4-way handshake and the GTK handshake would originate from the same location. =20 This would then require: 1) Negotiation between the WTP and the AC on where the 4-way handshake and GTK updates are generated.=20 2) A modification to the updateWLAN message element to include the PMK when a STA successfully associates. =20 I've captured this as issue 199. =09 =20 On 7/3/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com > wrote:=20 Hi Mike, =20 I had a chance to review the new draft.=20 =20 With regard to Issue 43, my understanding is that updates were made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN message element now allows the AC to send sequence counter values to the WTP. So now, CAPWAP can support designs where the KeyRSC is maintained by the AC.=20 =20 My initial concern was with supporting designs where the KeyRSC is maintained by the WTP. This is particularly important to manage the 4-Way and Group-key handshakes.=20 =20 With this in mind, I think the protocol still requires support for designs where the KeyRSC is maintained by the WTP. Based on the current draft, this support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames would have unassigned fields for KeyRSC (since the value is maintained by the WTP).=20 =20 I am also open to any alternatives to support this.=20 =20 Cheers, =09 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com]=20 Sent: Tuesday, June 20, 2006 10:01 PM=20 To: Saravanan Govindan Cc: Bob O'Hara (boohara); capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 I've updated section 11.3 to deal with the GTK exchange and the handling of the KeyRSC in draft -02 to address your comments. I also provided a mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message element as part of the Group Key exchange.=20 =20 We're finalizing the -02 draft this week and you should be able to look at it when we post it later this week. =20 Cheers, =20 Mike =20 =20 ------_=_NextPart_001_01C6AC10.FC8B69C1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    I'd=20 like to understand how you've interpreted this feature as being = "mandatory". The=20 current spec supports 802.11i, in both modes of operation that we've = agreed to,=20 which is Split and Local MAC.
     

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

     

    From: Saravanan Govindan=20 [mailto:Saravanan.Govindan@sg.panasonic.com]
    Sent: = Wednesday, July=20 19, 2006 11:37 PM
    To: Pat Calhoun (pacalhou); Michael=20 Montemurro
    Cc: capwap
    Subject: RE: [Capwap] = Clarification=20 of Issue 43: IEEE 802.11i Considerations

    I’d like to = clarify that this is=20 indeed a “mandatory” objective and needs to be integral to = CAPWAP. Based on=20 the exchanges so far, I think support for this feature can be easily=20 incorporated in to the protocol.

     

    We know the protocol = needs this=20 (from the requirement) and we know how to do it (from the proposals), = so let’s=20 just do it and move forward.

     

    Saravanan

     

     

     

     

    From: Pat=20 Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
    Sent:     Thursday, July 20, 2006 = 6:30=20 AM
    To: Michael = Montemurro;=20 Saravanan Govindan
    Cc:=20 capwap
    Subject: RE: = [Capwap]=20 Clarification of Issue 43: IEEE 802.11i=20 Considerations

     

    My personal = feeling=20 is that this should be considered a "nice to have", and therefore show = up in=20 the "wish" tracker category. Given all of the work we have ahead of = us, I=20 don't believe there is an urgent need to support this mode of = operation, as=20 the current protocol achieves our objectives. So waiting for a future = version=20 of the protocol would be my = suggestion.

     

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

     

     

    From:=20 Michael Montemurro [mailto:montemurro.michael@gmail.com] =
    Sent:     Tuesday, July 18, 2006 = 6:59=20 PM
    To: Saravanan=20 Govindan
    Cc:=20 capwap
    Subject: = Re:=20 [Capwap] Clarification of Issue 43: IEEE 802.11i=20 Considerations

    Saravanan,

     

    I've given some additional thought to your = requirements and I believe it would require additional text as well = as an=20 additional negotiation between the WTP and the=20 AC.

     

    We could separate the RSNA key = management=20 functions from the "classical" IEEE 802.1X authenticator functions = and allow=20 the WTP and AC negotiate where these functions=20 reside:

     

    The IEEE 802.1X authenticator functions = would=20 include the PMK derivation. The PMK would be passed to the WTP upon=20 successful completion of the IEEE 802.1X=20 authentication.

     

    The RSNA key management functions would = include the=20 4-way handshake and the generation of GTK=20 updates.

     

    I think this is a cleaner mechanism to = address your=20 requirements.

     

    Does this make sense to you?=20

     

    Cheers,

     

    Mike



     

    On 7/6/06, Saravanan Govindan <Saravanan.Govindan@sg= .panasonic.com>=20 wrote:

    Hi=20 Mike,

     

    Thank you for the = note.=20


    I may not have = been clear=20 with my previous post. My request is to have EAPoL frames generated = at the=20 AC alone – not at the WTP.

     

    My request is for = designs where=20 EAPoL frames are generated at the AC and in those where the KeyRSC = is=20 maintained in the WTP. These designs were highlighted in the = Architecture=20 Taxonomy.

     

    Specifically, I = suggest that a=20 CAPWAP message (it may be Add WLAN or Update WLAN) be able to carry = an EAPoL=20 frame from the AC to the WTP. This EAPoL frame (for Message 3 of = 4-way=20 handshake or for Message 1 of group key handshake) would have its = KeyRSC=20 field unassigned. Then when the WTP receives this message, it fills = in the=20 right value of the KeyRSC, updates the EAPoL frame and then transmit = it to=20 the wireless station.

     

    I hope this clarifies = my=20 suggestion.


    Cheers,


    Saravanan

     

     

     

     

    From:=20 Michael Montemurro [mailto: montemurro.michael@gmail.com]
    Sent:     Tuesday, July 04, 2006 = 9:47=20 PM
    To: Saravanan=20 Govindan
    Cc:=20 capwap


    Subject: Re: [Capwap] = Clarification of=20 Issue 43: IEEE 802.11i=20 = Considerations

     

    Saravanan,

     

    So, you=20 would like to request that the WTP generate EAPoL-Key frames for the = 4-way=20 handshake and the GTK update?

     

    The=20 current draft assumes that all EAPoL-Key frames are generated at the = AC.

     

    Based=20 on the following assumptions:

    1) This=20 feature would be for local-MAC = only.

    2) The=20 4-way handshake and the GTK handshake would originate from the same=20 location.

     

    This=20 would then require:

    1)=20 Negotiation between the WTP and the AC on where the 4-way handshake = and GTK=20 updates are generated.

    2) A=20 modification to the updateWLAN message element to include the = PMK when=20 a STA successfully associates.

     

    I've=20 captured this as issue = 199.

     

    On=20 7/3/06, Saravanan = Govindan=20 < = Saravanan.Govindan@sg.panasonic.com> wrote:=20

    Hi=20 Mike,

     

    I had a chance to = review the new=20 draft.

     

    With regard to Issue = 43, my=20 understanding is that updates were made in Section 11.9.1 (IEEE = 802.11 Add=20 WLAN). In particular, the IEEE 802.11 Add WLAN message element now = allows=20 the AC to send sequence counter values to the WTP. So now, CAPWAP = can=20 support designs where the KeyRSC is maintained by the AC.=20

     

    My initial concern was = with=20 supporting designs where the KeyRSC is maintained by the WTP. This = is=20 particularly important to manage the 4-Way and Group-key handshakes. =

     

    With this in mind, I = think the=20 protocol still requires support for designs where the KeyRSC is = maintained=20 by the WTP. Based on the current draft, this support can be included = by=20 adding another field to the IEEE 802.11 Add WLAN message element. = This field=20 would contain Message-3 EAPoL frame (for 4-Way handshake) or = Message-1 EAPoL=20 frame (for Group-key handshake). These EAPoL frames would have = unassigned=20 fields for KeyRSC (since the value is maintained by the WTP).=20

     

    I am also open to any=20 alternatives to support this.

     

    Cheers,


    Saravanan

     

     

     

     

    From:=20 Michael Montemurro [mailto: montemurro.michael@gmail.com]
    Sent:     Tuesday, June 20, 2006 = 10:01 PM=20
    To: Saravanan=20 Govindan
    Cc: Bob = O'Hara=20 (boohara); capwap
    Subject:=20 Re: [Capwap] Clarification of Issue 43: IEEE 802.11i=20 Considerations

     

    Saravanan,

     

    I've=20 updated section 11.3 to deal with the GTK exchange and the handling = of the=20 KeyRSC in draft -02 to address your comments. I also provided a = mechanism=20 for the AC to transmit the keyRSC to the WTP using the updateWLAN = message=20 element as part of the Group Key exchange.=20

     

    We're=20 finalizing the -02 draft this week and you should be able to look at = it when=20 we post it later this week.

     

    Cheers,

     

    Mike

     

     

    = ------_=_NextPart_001_01C6AC10.FC8B69C1-- --===============1844474091== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1844474091==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 20 11:40:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3adz-0002UU-Pp for capwap-archive@lists.ietf.org; Thu, 20 Jul 2006 11:40:55 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3ady-0006YM-C1 for capwap-archive@lists.ietf.org; Thu, 20 Jul 2006 11:40:55 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id BF3BB398070 for ; Thu, 20 Jul 2006 08:40:53 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7CB8C430063 for ; Thu, 20 Jul 2006 08:39:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 481DA144800E for ; Thu, 20 Jul 2006 08:39:45 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 744EE1448015 for ; Thu, 20 Jul 2006 08:39:40 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k6KFdHZU015222; Fri, 21 Jul 2006 00:39:17 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k6KFdHk19169; Fri, 21 Jul 2006 00:39:17 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id k6KFdGW23988; Fri, 21 Jul 2006 00:39:16 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Jul 2006 23:39:00 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD010734B9@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Thread-Index: Acaq1wHFltx/sTmjR9+5w4E1E3S4UAAmXkXAABUulxAAEup7QAAAXidA From: "Cheng Hong" To: "Pat Calhoun (pacalhou)" , "Saravanan Govindan" , "Michael Montemurro" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0597784632==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 029b39ae15e2f7319deef3b7670439ee This is a multi-part message in MIME format. --===============0597784632== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AC12.A55D7164" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6AC12.A55D7164 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Obviously, this is a type of "Split" case. Thus, it has to be "mandatory". Or, the understanding of "mandatory" is different? =20 cheers =20 Cheng Hong =20 _____ =20 From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, July 20, 2006 11:27 PM To: Saravanan Govindan; Michael Montemurro Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations I'd like to understand how you've interpreted this feature as being "mandatory". The current spec supports 802.11i, in both modes of operation that we've agreed to, which is Split and Local MAC. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _____ =20 From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, July 19, 2006 11:37 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations I'd like to clarify that this is indeed a "mandatory" objective and needs to be integral to CAPWAP. Based on the exchanges so far, I think support for this feature can be easily incorporated in to the protocol.=20 =20 We know the protocol needs this (from the requirement) and we know how to do it (from the proposals), so let's just do it and move forward.=20 =20 Saravanan =20 =20 =20 =20 _____ =20 From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, July 20, 2006 6:30 AM To: Michael Montemurro; Saravanan Govindan Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 My personal feeling is that this should be considered a "nice to have", and therefore show up in the "wish" tracker category. Given all of the work we have ahead of us, I don't believe there is an urgent need to support this mode of operation, as the current protocol achieves our objectives. So waiting for a future version of the protocol would be my suggestion. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 _____ =20 From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Tuesday, July 18, 2006 6:59 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, =20 I've given some additional thought to your requirements and I believe it would require additional text as well as an additional negotiation between the WTP and the AC. =20 We could separate the RSNA key management functions from the "classical" IEEE 802.1X authenticator functions and allow the WTP and AC negotiate where these functions reside: =20 The IEEE 802.1X authenticator functions would include the PMK derivation. The PMK would be passed to the WTP upon successful completion of the IEEE 802.1X authentication. =20 The RSNA key management functions would include the 4-way handshake and the generation of GTK updates. =20 I think this is a cleaner mechanism to address your requirements. =20 Does this make sense to you?=20 =20 Cheers, =20 Mike =20 On 7/6/06, Saravanan Govindan wrote:=20 Hi Mike, =20 Thank you for the note.=20 I may not have been clear with my previous post. My request is to have EAPoL frames generated at the AC alone - not at the WTP.=20 =20 My request is for designs where EAPoL frames are generated at the AC and in those where the KeyRSC is maintained in the WTP. These designs were highlighted in the Architecture Taxonomy.=20 =20 Specifically, I suggest that a CAPWAP message (it may be Add WLAN or Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. This EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of group key handshake) would have its KeyRSC field unassigned. Then when the WTP receives this message, it fills in the right value of the KeyRSC, updates the EAPoL frame and then transmit it to the wireless station.=20 =20 I hope this clarifies my suggestion. Cheers, Saravanan =20 =20 =20 =20 _____ =20 From: Michael Montemurro [mailto: montemurro.michael@gmail.com]=20 Sent: Tuesday, July 04, 2006 9:47 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 So, you would like to request that the WTP generate EAPoL-Key frames for the 4-way handshake and the GTK update? =20 The current draft assumes that all EAPoL-Key frames are generated at the AC. =20 Based on the following assumptions: 1) This feature would be for local-MAC only. 2) The 4-way handshake and the GTK handshake would originate from the same location. =20 This would then require: 1) Negotiation between the WTP and the AC on where the 4-way handshake and GTK updates are generated.=20 2) A modification to the updateWLAN message element to include the PMK when a STA successfully associates. =20 I've captured this as issue 199. =20 On 7/3/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com> wrote:=20 Hi Mike, =20 I had a chance to review the new draft.=20 =20 With regard to Issue 43, my understanding is that updates were made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN message element now allows the AC to send sequence counter values to the WTP. So now, CAPWAP can support designs where the KeyRSC is maintained by the AC.=20 =20 My initial concern was with supporting designs where the KeyRSC is maintained by the WTP. This is particularly important to manage the 4-Way and Group-key handshakes.=20 =20 With this in mind, I think the protocol still requires support for designs where the KeyRSC is maintained by the WTP. Based on the current draft, this support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames would have unassigned fields for KeyRSC (since the value is maintained by the WTP).=20 =20 I am also open to any alternatives to support this.=20 =20 Cheers, Saravanan =20 =20 =20 =20 _____ =20 From: Michael Montemurro [mailto: montemurro.michael@gmail.com]=20 Sent: Tuesday, June 20, 2006 10:01 PM=20 To: Saravanan Govindan Cc: Bob O'Hara (boohara); capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 I've updated section 11.3 to deal with the GTK exchange and the handling of the KeyRSC in draft -02 to address your comments. I also provided a mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message element as part of the Group Key exchange.=20 =20 We're finalizing the -02 draft this week and you should be able to look at it when we post it later this week. =20 Cheers, =20 Mike =20 =20 ------_=_NextPart_001_01C6AC12.A55D7164 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Obviously, this is a type of "Split" case. Thus, it has to be=20 "mandatory". Or, the understanding of "mandatory" is=20 different?
     
    cheers
     
    Cheng=20 Hong
     

    From: Pat Calhoun (pacalhou)=20 [mailto:pcalhoun@cisco.com]
    Sent: Thursday, July 20, 2006 = 11:27=20 PM
    To: Saravanan Govindan; Michael Montemurro
    Cc:=20 capwap
    Subject: Re: [Capwap] Clarification of Issue 43: IEEE = 802.11i=20 Considerations

    I'd=20 like to understand how you've interpreted this feature as being = "mandatory".=20 The current spec supports 802.11i, in both modes of operation that = we've=20 agreed to, which is Split and Local MAC.
     

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

     

    From: Saravanan Govindan=20 [mailto:Saravanan.Govindan@sg.panasonic.com]
    Sent: = Wednesday,=20 July 19, 2006 11:37 PM
    To: Pat Calhoun (pacalhou); Michael = Montemurro
    Cc: capwap
    Subject: RE: [Capwap]=20 Clarification of Issue 43: IEEE 802.11i = Considerations

    I’d like to = clarify that this is=20 indeed a “mandatory” objective and needs to be integral = to CAPWAP. Based on=20 the exchanges so far, I think support for this feature can be easily = incorporated in to the protocol.

     

    We know the protocol = needs this=20 (from the requirement) and we know how to do it (from the = proposals), so=20 let’s just do it and move forward. =

     

    Saravanan

     

     

     

     

    From: Pat=20 Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
    Sent:     Thursday, July 20, 2006 = 6:30=20 AM
    To: Michael = Montemurro;=20 Saravanan Govindan
    Cc:=20 capwap
    Subject: = RE:=20 [Capwap] Clarification of Issue 43: IEEE 802.11i=20 Considerations

     

    My = personal feeling=20 is that this should be considered a "nice to have", and therefore = show up in=20 the "wish" tracker category. Given all of the work we have ahead of = us, I=20 don't believe there is an urgent need to support this mode of = operation, as=20 the current protocol achieves our objectives. So waiting for a = future=20 version of the protocol would be my=20 suggestion.

     

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

     

     

    From:=20 Michael Montemurro [mailto:montemurro.michael@gmail.com] =
    Sent:     Tuesday, July 18, = 2006 6:59=20 PM
    To: = Saravanan=20 Govindan
    Cc:=20 capwap
    Subject: = Re:=20 [Capwap] Clarification of Issue 43: IEEE 802.11i=20 Considerations

    Saravanan,

     

    I've given some additional thought to = your=20 requirements and I believe it would require additional text as = well as an=20 additional negotiation between the WTP and the=20 AC.

     

    We could separate the RSNA key = management functions from the "classical" IEEE 802.1X = authenticator=20 functions and allow the WTP and AC negotiate where these functions = reside:

     

    The IEEE 802.1X authenticator functions = would=20 include the PMK derivation. The PMK would be passed to the WTP = upon=20 successful completion of the IEEE 802.1X=20 authentication.

     

    The RSNA key management functions would = include=20 the 4-way handshake and the generation of GTK=20 updates.

     

    I think this is a cleaner mechanism to = address=20 your requirements.

     

    Does this make sense to you?=20

     

    Cheers,

     

    Mike



     

    On 7/6/06, Saravanan Govindan <Saravanan.Govindan@sg= .panasonic.com>=20 wrote:

    Hi=20 Mike,

     

    Thank you for the = note.=20


    I may not have = been clear=20 with my previous post. My request is to have EAPoL frames = generated at the=20 AC alone – not at the WTP.

     

    My request is for = designs=20 where EAPoL frames are generated at the AC and in those where the = KeyRSC=20 is maintained in the WTP. These designs were highlighted in the=20 Architecture Taxonomy.

     

    Specifically, I = suggest that a=20 CAPWAP message (it may be Add WLAN or Update WLAN) be able to = carry an=20 EAPoL frame from the AC to the WTP. This EAPoL frame (for Message = 3 of=20 4-way handshake or for Message 1 of group key handshake) would = have its=20 KeyRSC field unassigned. Then when the WTP receives this message, = it fills=20 in the right value of the KeyRSC, updates the EAPoL frame and then = transmit it to the wireless station.

     

    I hope this = clarifies my=20 suggestion.


    Cheers,


    Saravanan

     

     

     

     

    From:=20 Michael Montemurro [mailto: montemurro.michael@gmail.com]
    Sent:     Tuesday, July 04, = 2006 9:47=20 PM
    To: = Saravanan=20 Govindan
    Cc:=20 capwap


    Subject: Re: [Capwap] = Clarification=20 of Issue 43: IEEE 802.11i=20 = Considerations

     

    Saravanan,

     

    So,=20 you would like to request that the WTP generate EAPoL-Key frames = for the=20 4-way handshake and the GTK = update?

     

    The=20 current draft assumes that all EAPoL-Key frames are generated at = the=20 AC.

     

    Based=20 on the following assumptions:

    1)=20 This feature would be for local-MAC=20 only.

    2)=20 The 4-way handshake and the GTK handshake would originate from the = same=20 location.

     

    This=20 would then require:

    1)=20 Negotiation between the WTP and the AC on where the 4-way = handshake and=20 GTK updates are generated.

    2) A=20 modification to the updateWLAN message element to include the = PMK=20 when a STA successfully = associates.

     

    I've=20 captured this as issue=20 199.

     

    On=20 7/3/06, Saravanan = Govindan=20 <=20 Saravanan.Govindan@sg.panasonic.com> wrote:=20

    Hi=20 Mike,

     

    I had a chance to = review the=20 new draft.

     

    With regard to Issue = 43, my=20 understanding is that updates were made in Section 11.9.1 (IEEE = 802.11 Add=20 WLAN). In particular, the IEEE 802.11 Add WLAN message element now = allows=20 the AC to send sequence counter values to the WTP. So now, CAPWAP = can=20 support designs where the KeyRSC is maintained by the AC.=20

     

    My initial concern = was with=20 supporting designs where the KeyRSC is maintained by the WTP. This = is=20 particularly important to manage the 4-Way and Group-key = handshakes.=20

     

    With this in mind, I = think the=20 protocol still requires support for designs where the KeyRSC is = maintained=20 by the WTP. Based on the current draft, this support can be = included by=20 adding another field to the IEEE 802.11 Add WLAN message element. = This=20 field would contain Message-3 EAPoL frame (for 4-Way handshake) or = Message-1 EAPoL frame (for Group-key handshake). These EAPoL = frames would=20 have unassigned fields for KeyRSC (since the value is maintained = by the=20 WTP).

     

    I am also open to = any=20 alternatives to support this.

     

    Cheers,


    Saravanan

     

     

     

     

    From:=20 Michael Montemurro [mailto: montemurro.michael@gmail.com]
    Sent:     Tuesday, June 20, = 2006 10:01 PM=20
    To: Saravanan=20 Govindan
    Cc: = Bob O'Hara=20 (boohara); capwap
    Subject: Re: [Capwap] = Clarification=20 of Issue 43: IEEE 802.11i=20 Considerations

     

    Saravanan,

     

    I've=20 updated section 11.3 to deal with the GTK exchange and the = handling of the=20 KeyRSC in draft -02 to address your comments. I also provided a = mechanism=20 for the AC to transmit the keyRSC to the WTP using the updateWLAN = message=20 element as part of the Group Key exchange.=20

     

    We're=20 finalizing the -02 draft this week and you should be able to look = at it=20 when we post it later this = week.

     

    Cheers,

     

    Mike

     

     

    = ------_=_NextPart_001_01C6AC12.A55D7164-- --===============0597784632== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0597784632==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 20 12:15:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3bAU-0002Xo-6Z for capwap-archive@lists.ietf.org; Thu, 20 Jul 2006 12:14:30 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3b2G-0000Kw-OX for capwap-archive@lists.ietf.org; Thu, 20 Jul 2006 12:06:03 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0F082398082 for ; Thu, 20 Jul 2006 09:06:00 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1D320430063 for ; Thu, 20 Jul 2006 09:04:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0C8EE144802C for ; Thu, 20 Jul 2006 09:04:45 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by hermes.tigertech.net (Postfix) with ESMTP id 0C5B01448022 for ; Thu, 20 Jul 2006 09:04:38 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c63so827089pyc for ; Thu, 20 Jul 2006 09:04:37 -0700 (PDT) Received: by 10.35.127.7 with SMTP id e7mr1300710pyn; Thu, 20 Jul 2006 09:04:37 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Thu, 20 Jul 2006 09:04:37 -0700 (PDT) Message-ID: <26140d940607200904u75a62eabp51432e609e2eb8e3@mail.gmail.com> Date: Thu, 20 Jul 2006 12:04:37 -0400 From: "Michael Montemurro" To: "Cheng Hong" In-Reply-To: <5F09D220B62F79418461A978CA0921BD010734B9@pslexc01.psl.local> MIME-Version: 1.0 References: <5F09D220B62F79418461A978CA0921BD010734B9@pslexc01.psl.local> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: Saravanan Govindan , capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0770131168==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 23e0dc5390f90c078cbc69ce4ec79f98 --===============0770131168== Content-Type: multipart/alternative; boundary="----=_Part_7641_14597787.1153411477277" ------=_Part_7641_14597787.1153411477277 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I believe the existing draft supports IEEE 802.11i in both Split MAC and local MAC modes. The assumption in CAPWAP-02 is that: 1) The IEEE 802.1X Authenticator and the RADIUS client reside on the AC. I don't see any reason why this should be changed for local or split MAC. 2) RSNA Key Management resides on the AC. The PMK is cached on the AC and EAPoL-Key frames are generated by the AC. I don't see this as a problem for either split MAC or local MAC modes. 3) The PTK and GTK are transmitted to the WTP by the AC. I believe the solution meets the CAPWAP objectives. The solution works for both splitMAC or localMAC modes. Saravanan requested that the keyRSC be maintained at the WTP. I think the best approach to address this is to negotiate between the AC and the WTP so that, upon successful IEEE 802.1X authentication, the PMK is passed from th= e AC to the WTP. The WTP would then transmit EAPoL-Key frames. I believe this is a request that should be added to the wish list. Thanks, Mike On 7/20/06, Cheng Hong wrote: > > Obviously, this is a type of "Split" case. Thus, it has to be > "mandatory". Or, the understanding of "mandatory" is different? > > cheers > > Cheng Hong > > > ------------------------------ > *From:* Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > *Sent:* Thursday, July 20, 2006 11:27 PM > *To:* Saravanan Govindan; Michael Montemurro > *Cc:* capwap > > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderat= ions > > > > I'd like to understand how you've interpreted this feature as being > "mandatory". The current spec supports 802.11i, in both modes of operatio= n > that we've agreed to, which is Split and Local MAC. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > ------------------------------ > *From:* Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > *Sent:* Wednesday, July 19, 2006 11:37 PM > *To:* Pat Calhoun (pacalhou); Michael Montemurro > *Cc:* capwap > *Subject:* RE: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderat= ions > > > > I'd like to clarify that this is indeed a "mandatory" objective and needs > to be integral to CAPWAP. Based on the exchanges so far, I think support = for > this feature can be easily incorporated in to the protocol. > > > > We know the protocol needs this (from the requirement) and we know how to > do it (from the proposals), so let's just do it and move forward. > > > > Saravanan > > > > > > > > > ------------------------------ > > *From:* Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > *Sent:* Thursday, July 20, 2006 6:30 AM > *To:* Michael Montemurro; Saravanan Govindan > *Cc:* capwap > *Subject:* RE: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderat= ions > > > > My personal feeling is that this should be considered a "nice to have", > and therefore show up in the "wish" tracker category. Given all of the wo= rk > we have ahead of us, I don't believe there is an urgent need to support t= his > mode of operation, as the current protocol achieves our objectives. So > waiting for a future version of the protocol would be my suggestion. > > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > ------------------------------ > > *From:* Michael Montemurro [mailto:montemurro.michael@gmail.com] > *Sent:* Tuesday, July 18, 2006 6:59 PM > *To:* Saravanan Govindan > *Cc:* capwap > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderat= ions > > Saravanan, > > > > I've given some additional thought to your requirements and I believe it > would require additional text as well as an additional negotiation betwee= n > the WTP and the AC. > > > > We could separate the RSNA key management functions from the "classical" > IEEE 802.1X authenticator functions and allow the WTP and AC negotiate > where these functions reside: > > > > The IEEE 802.1X authenticator functions would include the PMK derivation. > The PMK would be passed to the WTP upon successful completion of the IEEE > 802.1X authentication. > > > > The RSNA key management functions would include the 4-way handshake and > the generation of GTK updates. > > > > I think this is a cleaner mechanism to address your requirements. > > > > Does this make sense to you? > > > > Cheers, > > > > Mike > > > > > > On 7/6/06, *Saravanan Govindan* > wrote: > > Hi Mike, > > > > Thank you for the note. > > > I may not have been clear with my previous post. My request is to have > EAPoL frames generated at the AC alone =96 not at the WTP. > > > > My request is for designs where EAPoL frames are generated at the AC and > in those where the KeyRSC is maintained in the WTP. These designs were > highlighted in the Architecture Taxonomy. > > > > Specifically, I suggest that a CAPWAP message (it may be Add WLAN or > Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. This > EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of group k= ey > handshake) would have its KeyRSC field unassigned. Then when the WTP > receives this message, it fills in the right value of the KeyRSC, updates > the EAPoL frame and then transmit it to the wireless station. > > > > I hope this clarifies my suggestion. > > > Cheers, > > > Saravanan > > > > > > > > > ------------------------------ > > *From:* Michael Montemurro [mailto: montemurro.michael@gmail.com] > *Sent:* Tuesday, July 04, 2006 9:47 PM > *To:* Saravanan Govindan > *Cc:* capwap > > > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderat= ions > > > > Saravanan, > > > > So, you would like to request that the WTP generate EAPoL-Key frames for > the 4-way handshake and the GTK update? > > > > The current draft assumes that all EAPoL-Key frames are generated at the > AC. > > > > Based on the following assumptions: > > 1) This feature would be for local-MAC only. > > 2) The 4-way handshake and the GTK handshake would originate from the sam= e > location. > > > > This would then require: > > 1) Negotiation between the WTP and the AC on where the 4-way handshake an= d > GTK updates are generated. > > 2) A modification to the updateWLAN message element to include the PMK > when a STA successfully associates. > > > > I've captured this as issue 199. > > > > On 7/3/06, *Saravanan Govindan* < Saravanan.Govindan@sg.panasonic.com> > wrote: > > Hi Mike, > > > > I had a chance to review the new draft. > > > > With regard to Issue 43, my understanding is that updates were made in > Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add > WLAN message element now allows the AC to send sequence counter values to > the WTP. So now, CAPWAP can support designs where the KeyRSC is maintaine= d > by the AC. > > > > My initial concern was with supporting designs where the KeyRSC is > maintained by the WTP. This is particularly important to manage the 4-Way > and Group-key handshakes. > > > > With this in mind, I think the protocol still requires support for design= s > where the KeyRSC is maintained by the WTP. Based on the current draft, th= is > support can be included by adding another field to the IEEE 802.11 Add > WLAN message element. This field would contain Message-3 EAPoL frame (for > 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). Thes= e > EAPoL frames would have unassigned fields for KeyRSC (since the value is > maintained by the WTP). > > > > I am also open to any alternatives to support this. > > > > Cheers, > > > Saravanan > > > > > > > > > ------------------------------ > > *From:* Michael Montemurro [mailto: montemurro.michael@gmail.com] > *Sent:* Tuesday, June 20, 2006 10:01 PM > *To:* Saravanan Govindan > *Cc:* Bob O'Hara (boohara); capwap > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderat= ions > > > > Saravanan, > > > > I've updated section 11.3 to deal with the GTK exchange and the handling > of the KeyRSC in draft -02 to address your comments. I also provided a > mechanism for the AC to transmit the keyRSC to the WTP using the updateWL= AN > message element as part of the Group Key exchange. > > > > We're finalizing the -02 draft this week and you should be able to look a= t > it when we post it later this week. > > > > Cheers, > > > > Mike > > > > > > ------=_Part_7641_14597787.1153411477277 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
    I believe the existing draft supports IEEE 802.11i in both Split MAC a= nd local MAC modes.
     
    The assumption in CAPWAP-02 is that:
    1) The IEEE 802.1X Authenticator and the RADIUS client reside on = the AC. I don't see any reason why this should be changed for local or spli= t MAC.
    2) RSNA Key Management resides on the AC. The PMK is cached on the AC = and EAPoL-Key frames are generated by the AC. I don't see this as a problem= for either split MAC or local MAC modes.
    3) The PTK and GTK are transmitted to the WTP by the AC.
     
    I believe the solution meets the CAPWAP objectives. The solution works= for both splitMAC or localMAC modes.
     
    Saravanan requested that the keyRSC be maintained at the WTP. I t= hink the best approach to address this is to negotiate between the AC = and the WTP so that, upon successful IEEE 802.1X authentication, = the PMK is passed from the AC to the WTP. The WTP would then transmit = EAPoL-Key frames.=20
     
    I believe this is a request that should be added to the wish list.
     
    Thanks,
     
    Mike
     
     
    On 7/20/06, = Cheng Hong <Hong.Chen= g@sg.panasonic.com> wrote:
    Obviously, thi= s is a type of "Split" case. Thus, it has to be "mandatory&q= uot;. Or, the understanding of "mandatory" is different?
    =  
    cheers<= /span>
    =  
    Cheng Hong
    =  

    From: Pat Calhoun (pacalhou) [mailto:pcalhoun@= cisco.com ]
    Sent: Thursday, July 20, 2006 11:27 PM
    To: Saravanan = Govindan; Michael Montemurro
    Cc: capwap

    Subject: Re: = [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations
    <= /div>

     
    I'd like to un= derstand how you've interpreted this feature as being "mandatory"= . The current spec supports 802.11i, in both modes of operation that we've = agreed to, which is Split and Local MAC.
     

    Pat Calhoun
    CTO, Wireless Networking = Business Unit
    Cisco Systems

     

    From: Saravanan Govindan [mailto: Saravanan.Govindan@sg.panasonic.com]
    Sent: Wednesday, July 1= 9, 2006 11:37 PM
    To: Pat Calhoun (pacalhou); Michael MontemurroCc: capwap
    Subject: RE: [Capwap] Clarification of Issue = 43: IEEE=20 802.11i Considerations

     

    I'd like to clarify that this is indeed a "mandatory" objective= and needs to be integral to CAPWAP. Based on the exchanges so far, I think= support for this feature can be easily incorporated in to the protocol.=20

     

    We know the protocol needs this (from the requirement) and we k= now how to do it (from the proposals), so let's just do it and move forward= .=20

     

    Saravanan

     

     

     

     

    From: Pat = Calhoun (pacalhou) [mailto: p= calhoun@cisco.com]
    Sent: Thursday, July 20, 2006 6:30 AM
    To: Michael Montemurro;= Saravanan Govindan
    Cc: = capwap
    Subject: RE: [Cap= wap] Clarification of Issue 43: IEEE=20 802.11i Considerations

    My personal feeling is that this sh= ould be considered a "nice to have", and therefore show up in the= "wish" tracker category. Given all of the work we have ahead of = us, I don't believe there is an urgent need to support this mode of operati= on, as the current protocol achieves our objectives. So waiting for a futur= e version of the protocol would be my suggestion.

    From: Michael Montemurro [mailto:montemurro.michael@gmail.com= ]
    Sent: Tuesday, July 1= 8, 2006 6:59 PM
    To: Sara= vanan Govindan
    Cc: capwa= p
    Subject: Re: [Capwap] Clari= fication of Issue 43: IEEE 802.11i Considerations

    On 7/6/06, Saravanan Govindan<= /span> < Saravanan.Govindan@sg.panasonic.com> wrote:

    Hi Mike,

    Thank you for the note.


    I may not have been clear with my previous post. My request= is to have EAPoL frames generated at the AC alone =96 not at the WTP.

    My request is for designs where EAPoL frames are generated at t= he AC and in those where the KeyRSC is maintained in the WTP. These designs= were highlighted in the Architecture Taxonomy.=20

    Specifically, I suggest that a CAPWAP message (it may be Add WL= AN or Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. = This EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of grou= p key handshake) would have its KeyRSC field unassigned. Then when the WTP = receives this message, it fills in the right value of the KeyRSC, updates t= he EAPoL frame and then transmit it to the wireless station.=20

    I hope this clarifies my suggestion.


    Cheers,


    Saravanan

    From: Mich= ael Montemurro [mailto:=20 montemurro.micha= el@gmail.com ]
    Sent: Tuesday, Ju= ly 04, 2006 9:47 PM
    To: = Saravanan Govindan
    Cc: c= apwap

    Subject: Re: [C= apwap] Clarification of Issue 43: IEEE 802.11i Considerations=

    Saravanan Govindan= < Saravanan.Govindan@sg.panasonic.com> wrote:

    Hi Mike,

    I had a chance to review the new draft.

    With regard to Issue 43, my understanding is that updates were = made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.= 11 Add WLAN message element now allows the AC to send sequence counter values= to the WTP. So now, CAPWAP can support designs where the KeyRSC is maintai= ned by the AC.

    My initial concern was with supporting designs where the KeyRSC= is maintained by the WTP. This is particularly important to manage the 4-W= ay and Group-key handshakes.=20

    With this in mind, I think the protocol still requires support = for designs where the KeyRSC is maintained by the WTP. Based on the current= draft, this support can be included by adding another field to the IEEE=20 802.11 Add WLAN message element. This field would contain Message-3 EAPoL f= rame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshak= e). These EAPoL frames would have unassigned fields for KeyRSC (since the v= alue is maintained by the WTP).=20

    I am also open to any alternatives to support this.

    Cheers,


    Saravanan

    From: Mich= ael Montemurro [mailto:=20 montemurro.micha= el@gmail.com ]
    Sent: Tuesday, Ju= ne 20, 2006 10:01 PM
    To: Saravanan Govindan
    Cc:= Bob O'Hara (boohara); capwap
    Subject: Re: [Capwap] C= larification of Issue 43: IEEE 802.11i Considerations

    ; Thu, 20 Jul 2006 09:27:39 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id DDB35430063 for ; Thu, 20 Jul 2006 09:26:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 494BA144801A for ; Thu, 20 Jul 2006 09:26:36 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by hermes.tigertech.net (Postfix) with ESMTP id 5F6D71448007 for ; Thu, 20 Jul 2006 09:26:31 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 20 Jul 2006 09:26:29 -0700 X-IronPort-AV: i="4.07,163,1151910000"; d="scan'208,217"; a="435491554:sNHT90071342" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6KGQTxN015295 for ; Thu, 20 Jul 2006 09:26:29 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6KGQT2D017557 for ; Thu, 20 Jul 2006 09:26:29 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 09:26:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Jul 2006 09:26:28 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC01C8778B@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations thread-index: AcasFk3Nv7tSGsZ2Ruq4pxZh9zCtNwAAV4rQ From: "Bob O'Hara (boohara)" To: "capwap" X-OriginalArrivalTime: 20 Jul 2006 16:26:29.0292 (UTC) FILETIME=[411876C0:01C6AC19] Authentication-Results: sj-dkim-3.cisco.com; header.From=boohara@cisco.com; dkim=pass ( 43 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0021786896==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: a7b3e2e89e2e73a6185808e636222e06 This is a multi-part message in MIME format. --===============0021786896== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AC19.410EADD0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6AC19.410EADD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with most of what Michael has written below. His statements of the assumptions in the -02 draft are correct. His statement that the solution meets the CAPWAP objectives is also correct. =20 I think that separation of 802.1X state machine to perform one part in the AC and another part in the WTP, i.e, authentication in the AC and EAPOL-Key exchange in the WTP, is a very bad idea. This portion of the exchange between the WTP and the mobile client device is a time critical period. Adding one or more additional round trip exchanges between the AC and WTP that are not directly conveying packets to the mobile client does not help to minimize this time critical exchange with the client. =20 Therefore, I also agree that splitting the protocol between AC and WTP is a wish and not a requirement. =20 =20 The KeyRSC issue, where there has been proposed a negotiation or exchange between AC and WTP is also a wish and not a requirement. A proper understanding of how the PTK and GTK are established between the authenticator and supplicant shows that the KeyRSC does not need to be known by the AC, even if it is maintained by the WTP. This might even demote the issue to a bad wish, at that. -Bob =20 =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Thursday, July 20, 2006 9:05 AM To: Cheng Hong Cc: Saravanan Govindan; capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations I believe the existing draft supports IEEE 802.11i in both Split MAC and local MAC modes. =20 The assumption in CAPWAP-02 is that: 1) The IEEE 802.1X Authenticator and the RADIUS client reside on the AC. I don't see any reason why this should be changed for local or split MAC. 2) RSNA Key Management resides on the AC. The PMK is cached on the AC and EAPoL-Key frames are generated by the AC. I don't see this as a problem for either split MAC or local MAC modes. 3) The PTK and GTK are transmitted to the WTP by the AC. =20 I believe the solution meets the CAPWAP objectives. The solution works for both splitMAC or localMAC modes. =20 Saravanan requested that the keyRSC be maintained at the WTP. I think the best approach to address this is to negotiate between the AC and the WTP so that, upon successful IEEE 802.1X authentication, the PMK is passed from the AC to the WTP. The WTP would then transmit EAPoL-Key frames.=20 =20 I believe this is a request that should be added to the wish list. =20 Thanks, =20 Mike =20 =20 On 7/20/06, Cheng Hong wrote:=20 Obviously, this is a type of "Split" case. Thus, it has to be "mandatory". Or, the understanding of "mandatory" is different?=20 =20 cheers =20 Cheng Hong =20 ________________________________ =09 From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com ]=20 =09 Sent: Thursday, July 20, 2006 11:27 PM To: Saravanan Govindan; Michael Montemurro Cc: capwap =09 Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =09 =20 =09 I'd like to understand how you've interpreted this feature as being "mandatory". The current spec supports 802.11i, in both modes of operation that we've agreed to, which is Split and Local MAC.=20 =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Saravanan Govindan [mailto: Saravanan.Govindan@sg.panasonic.com ]=20 Sent: Wednesday, July 19, 2006 11:37 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =09 =20 I'd like to clarify that this is indeed a "mandatory" objective and needs to be integral to CAPWAP. Based on the exchanges so far, I think support for this feature can be easily incorporated in to the protocol.=20 =20 We know the protocol needs this (from the requirement) and we know how to do it (from the proposals), so let's just do it and move forward.=20 =20 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com]=20 Sent: Thursday, July 20, 2006 6:30 AM=20 To: Michael Montemurro; Saravanan Govindan Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 My personal feeling is that this should be considered a "nice to have", and therefore show up in the "wish" tracker category. Given all of the work we have ahead of us, I don't believe there is an urgent need to support this mode of operation, as the current protocol achieves our objectives. So waiting for a future version of the protocol would be my suggestion.=20 =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com ]=20 Sent: Tuesday, July 18, 2006 6:59 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, =20 I've given some additional thought to your requirements and I believe it would require additional text as well as an additional negotiation between the WTP and the AC.=20 =20 We could separate the RSNA key management functions from the "classical" IEEE 802.1X authenticator functions and allow the WTP and AC negotiate where these functions reside:=20 =20 The IEEE 802.1X authenticator functions would include the PMK derivation. The PMK would be passed to the WTP upon successful completion of the IEEE 802.1X authentication. =20 The RSNA key management functions would include the 4-way handshake and the generation of GTK updates. =20 I think this is a cleaner mechanism to address your requirements. =20 Does this make sense to you?=20 =20 Cheers, =20 Mike =09 =09 =20 On 7/6/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com > wrote:=20 Hi Mike, =20 Thank you for the note.=20 =09 I may not have been clear with my previous post. My request is to have EAPoL frames generated at the AC alone - not at the WTP.=20 =20 My request is for designs where EAPoL frames are generated at the AC and in those where the KeyRSC is maintained in the WTP. These designs were highlighted in the Architecture Taxonomy.=20 =20 Specifically, I suggest that a CAPWAP message (it may be Add WLAN or Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. This EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of group key handshake) would have its KeyRSC field unassigned. Then when the WTP receives this message, it fills in the right value of the KeyRSC, updates the EAPoL frame and then transmit it to the wireless station.=20 =20 I hope this clarifies my suggestion. =09 Cheers, =09 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com ]=20 Sent: Tuesday, July 04, 2006 9:47 PM To: Saravanan Govindan Cc: capwap=20 =09 Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations=20 =20 Saravanan, =20 So, you would like to request that the WTP generate EAPoL-Key frames for the 4-way handshake and the GTK update? =20 The current draft assumes that all EAPoL-Key frames are generated at the AC. =20 Based on the following assumptions: 1) This feature would be for local-MAC only. 2) The 4-way handshake and the GTK handshake would originate from the same location. =20 This would then require: 1) Negotiation between the WTP and the AC on where the 4-way handshake and GTK updates are generated.=20 2) A modification to the updateWLAN message element to include the PMK when a STA successfully associates. =20 I've captured this as issue 199. =09 =20 On 7/3/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com > wrote:=20 Hi Mike, =20 I had a chance to review the new draft.=20 =20 With regard to Issue 43, my understanding is that updates were made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN message element now allows the AC to send sequence counter values to the WTP. So now, CAPWAP can support designs where the KeyRSC is maintained by the AC.=20 =20 My initial concern was with supporting designs where the KeyRSC is maintained by the WTP. This is particularly important to manage the 4-Way and Group-key handshakes.=20 =20 With this in mind, I think the protocol still requires support for designs where the KeyRSC is maintained by the WTP. Based on the current draft, this support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames would have unassigned fields for KeyRSC (since the value is maintained by the WTP). =20 I am also open to any alternatives to support this.=20 =20 Cheers, =09 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com ]=20 Sent: Tuesday, June 20, 2006 10:01 PM=20 To: Saravanan Govindan Cc: Bob O'Hara (boohara); capwap=20 Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 I've updated section 11.3 to deal with the GTK exchange and the handling of the KeyRSC in draft -02 to address your comments. I also provided a mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message element as part of the Group Key exchange.=20 =20 We're finalizing the -02 draft this week and you should be able to look at it when we post it later this week. =20 Cheers, =20 Mike =20 =20 ------_=_NextPart_001_01C6AC19.410EADD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I agree with most of what Michael has written = below. =20 His statements of the assumptions in the -02 draft are correct.  = His=20 statement that the solution meets the CAPWAP objectives is also=20 correct.
     
    I think that separation of 802.1X state machine = to perform=20 one part in the AC and another part in the WTP, i.e, authentication in = the AC=20 and EAPOL-Key exchange in the WTP, is a very bad idea.  This = portion of the=20 exchange between the WTP and the mobile client device is a time critical = period.  Adding one or more additional round trip exchanges between = the AC=20 and WTP that are not directly conveying packets to the mobile client = does not=20 help to minimize this time critical exchange with the=20 client.
     
    Therefore, I also agree that splitting the = protocol=20 between AC and WTP is a wish and not a requirement. =20
     
    The KeyRSC issue, where there has been proposed = a=20 negotiation or exchange between AC and WTP is also a wish and not a = requirement.  A proper understanding of how the PTK and GTK are = established=20 between the authenticator and supplicant shows that the KeyRSC does not = need to=20 be known by the AC, even if it is maintained by the WTP.  This = might even=20 demote the issue to a bad wish, at that.

     -Bob
     

     

    From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
    Sent: Thursday, July = 20, 2006=20 9:05 AM
    To: Cheng Hong
    Cc: Saravanan Govindan;=20 capwap
    Subject: Re: [Capwap] Clarification of Issue 43: IEEE = 802.11i=20 Considerations

    I believe the existing draft supports IEEE 802.11i in both Split = MAC and=20 local MAC modes.
     
    The assumption in CAPWAP-02 is that:
    1) The IEEE 802.1X Authenticator and the RADIUS client reside = on the=20 AC. I don't see any reason why this should be changed for local or split = MAC.
    2) RSNA Key Management resides on the AC. The PMK is cached on the = AC and=20 EAPoL-Key frames are generated by the AC. I don't see this as a problem = for=20 either split MAC or local MAC modes.
    3) The PTK and GTK are transmitted to the WTP by the AC.
     
    I believe the solution meets the CAPWAP objectives. The solution = works for=20 both splitMAC or localMAC modes.
     
    Saravanan requested that the keyRSC be maintained at the WTP. = I think=20 the best approach to address this is to negotiate between the AC = and the=20 WTP so that, upon successful IEEE 802.1X authentication, = the PMK=20 is passed from the AC to the WTP. The WTP would then transmit EAPoL-Key = frames.=20
     
    I believe this is a request that should be added to the wish = list.
     
    Thanks,
     
    Mike
     
     
    On 7/20/06, Cheng=20 Hong <Hong.Cheng@sg.panasonic.com>=20 wrote:=20
    Obviously, this = is a type of=20 "Split" case. Thus, it has to be "mandatory". Or, the understanding of = "mandatory" is different?
     
    cheers
     
    Cheng=20 Hong
     

    From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com ]=20
    Sent: Thursday, July 20, 2006 11:27 PM
    To: = Saravanan=20 Govindan; Michael Montemurro
    Cc: capwap

    Subject: = Re: [Capwap]=20 Clarification of Issue 43: IEEE 802.11i = Considerations

     
    I'd like to = understand how=20 you've interpreted this feature as being "mandatory". The current spec = supports 802.11i, in both modes of operation that we've agreed to, = which is=20 Split and Local MAC.
     

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

     

    From: Saravanan Govindan = [mailto: = Saravanan.Govindan@sg.panasonic.com]
    Sent: Wednesday, = July=20 19, 2006 11:37 PM
    To: Pat Calhoun (pacalhou); Michael=20 Montemurro
    Cc: capwap
    Subject: RE: [Capwap]=20 Clarification of Issue 43: IEEE 802.11i=20 Considerations

     

    I'd like to clarify = that this is=20 indeed a "mandatory" objective and needs to be integral to CAPWAP. = Based on=20 the exchanges so far, I think support for this feature can be easily = incorporated in to the protocol.

     

    We know the protocol = needs this=20 (from the requirement) and we know how to do it (from the = proposals), so=20 let's just do it and move forward.

     

    Saravanan

     

     

     

     

    From: Pat=20 Calhoun (pacalhou) [mailto: pcalhoun@cisco.com]=20
    Sent: Thursday, = July 20,=20 2006 6:30 AM
    To: = Michael=20 Montemurro; Saravanan Govindan
    Cc:     capwap
    Subject: RE: [Capwap] = Clarification of=20 Issue 43: IEEE 802.11i Considerations

     

    My = personal feeling=20 is that this should be considered a "nice to have", and therefore = show up in=20 the "wish" tracker category. Given all of the work we have ahead of = us, I=20 don't believe there is an urgent need to support this mode of = operation, as=20 the current protocol achieves our objectives. So waiting for a = future=20 version of the protocol would be my suggestion. =

     

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

     

     

    From:=20 Michael Montemurro [mailto:montemurro.michael@gmail.com ]
    Sent:     Tuesday, July 18, = 2006 6:59=20 PM
    To: = Saravanan=20 Govindan
    Cc:=20 capwap
    Subject: = Re:=20 [Capwap] Clarification of Issue 43: IEEE 802.11i=20 Considerations

    Saravanan,

     

    I've=20 given some additional thought to your requirements and I believe = it would=20 require additional text as well as an additional negotiation = between the=20 WTP and the AC.

     

    We=20 could separate the RSNA key management functions from = the=20 "classical" IEEE 802.1X authenticator functions and allow the WTP = and AC=20 negotiate where these functions reside:

     

    The=20 IEEE 802.1X authenticator functions would include the PMK = derivation. The=20 PMK would be passed to the WTP upon successful completion of the = IEEE=20 802.1X authentication.

     

    The=20 RSNA key management functions would include the 4-way handshake = and the=20 generation of GTK updates.

     

    I=20 think this is a cleaner mechanism to address your=20 requirements.

     

    Does=20 this make sense to you?

     

    Cheers,

     

    Mike



     

    On 7/6/06, Saravanan Govindan <=20 Saravanan.Govindan@sg.panasonic.com> = wrote:=20

    Hi = Mike,

     

    Thank you for the = note.=20


    I may not have = been clear=20 with my previous post. My request is to have EAPoL frames = generated at the=20 AC alone – not at the WTP.

     

    My request is for = designs=20 where EAPoL frames are generated at the AC and in those where the = KeyRSC=20 is maintained in the WTP. These designs were highlighted in the=20 Architecture Taxonomy.

     

    Specifically, I = suggest that a=20 CAPWAP message (it may be Add WLAN or Update WLAN) be able to = carry an=20 EAPoL frame from the AC to the WTP. This EAPoL frame (for Message = 3 of=20 4-way handshake or for Message 1 of group key handshake) would = have its=20 KeyRSC field unassigned. Then when the WTP receives this message, = it fills=20 in the right value of the KeyRSC, updates the EAPoL frame and then = transmit it to the wireless station.

     

    I hope this = clarifies my=20 suggestion.


    Cheers,


    Saravanan

     

     

     

     

    From:=20 Michael Montemurro [mailto: montemurro.michael@gmail.com ]
    Sent:     Tuesday, July 04, = 2006 9:47=20 PM
    To: = Saravanan=20 Govindan
    Cc: = capwap=20


    Subject: Re: [Capwap] = Clarification=20 of Issue 43: IEEE 802.11i Considerations    =20

     

    Saravanan,

     

    So,=20 you would like to request that the WTP generate EAPoL-Key frames = for the=20 4-way handshake and the GTK update?

     

    The=20 current draft assumes that all EAPoL-Key frames are generated at = the=20 AC.

     

    Based=20 on the following assumptions:

    1)=20 This feature would be for local-MAC only.

    2)=20 The 4-way handshake and the GTK handshake would originate from the = same=20 location.

     

    This=20 would then require:

    1)=20 Negotiation between the WTP and the AC on where the 4-way = handshake and=20 GTK updates are generated.

    2) A=20 modification to the updateWLAN message element to include the = PMK=20 when a STA successfully associates.

     

    I've=20 captured this as issue 199.

     

    On=20 7/3/06, Saravanan = Govindan=20 <=20 Saravanan.Govindan@sg.panasonic.com> wrote: =

    Hi = Mike,

     

    I had a chance to = review the=20 new draft.

     

    With regard to Issue = 43, my=20 understanding is that updates were made in Section 11.9.1 (IEEE = 802.11 Add=20 WLAN). In particular, the IEEE 802.11 Add WLAN message element now = allows=20 the AC to send sequence counter values to the WTP. So now, CAPWAP = can=20 support designs where the KeyRSC is maintained by the AC.=20

     

    My initial concern = was with=20 supporting designs where the KeyRSC is maintained by the WTP. This = is=20 particularly important to manage the 4-Way and Group-key = handshakes.=20

     

    With this in mind, I = think the=20 protocol still requires support for designs where the KeyRSC is = maintained=20 by the WTP. Based on the current draft, this support can be = included by=20 adding another field to the IEEE 802.11 Add WLAN message element. = This=20 field would contain Message-3 EAPoL frame (for 4-Way handshake) or = Message-1 EAPoL frame (for Group-key handshake). These EAPoL = frames would=20 have unassigned fields for KeyRSC (since the value is maintained = by the=20 WTP).

     

    I am also open to = any=20 alternatives to support this.

     

    Cheers,


    Saravanan

     

     

     

     

    From:=20 Michael Montemurro [mailto: montemurro.michael@gmail.com ]
    Sent:     Tuesday, June 20, = 2006 10:01 PM=20
    To: Saravanan=20 Govindan
    Cc: = Bob O'Hara=20 (boohara); capwap
    Subject: Re: [Capwap] = Clarification=20 of Issue 43: IEEE 802.11i Considerations

     

    Saravanan,

     

    I've=20 updated section 11.3 to deal with the GTK exchange and the = handling of the=20 KeyRSC in draft -02 to address your comments. I also provided a = mechanism=20 for the AC to transmit the keyRSC to the WTP using the updateWLAN = message=20 element as part of the Group Key exchange. =

     

    We're=20 finalizing the -02 draft this week and you should be able to look = at it=20 when we post it later this week.

     

    Cheers,

     

    Mike

     

     

    =

    ------_=_NextPart_001_01C6AC19.410EADD0-- --===============0021786896== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0021786896==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 20 19:55:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3iMX-0000rU-Sa for capwap-archive@lists.ietf.org; Thu, 20 Jul 2006 19:55:25 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3iMW-0006pU-4S for capwap-archive@lists.ietf.org; Thu, 20 Jul 2006 19:55:25 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 39B3139802A for ; Thu, 20 Jul 2006 16:55:23 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9CE2843006B for ; Thu, 20 Jul 2006 16:53:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 82568144802C for ; Thu, 20 Jul 2006 16:53:49 -0700 (PDT) Received: from alnrmhc11.comcast.net (alnrmhc11.comcast.net [206.18.177.51]) by hermes.tigertech.net (Postfix) with ESMTP id 87713144802F for ; Thu, 20 Jul 2006 16:53:44 -0700 (PDT) Received: from [192.168.0.4] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (alnrmhc11) with ESMTP id <20060720235343b11008uqo3e>; Thu, 20 Jul 2006 23:53:44 +0000 Message-ID: <44C01788.3000309@cs.umd.edu> Date: Thu, 20 Jul 2006 19:53:44 -0400 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Montemurro References: <5F09D220B62F79418461A978CA0921BD010734B9@pslexc01.psl.local> <26140d940607200904u75a62eabp51432e609e2eb8e3@mail.gmail.com> In-Reply-To: <26140d940607200904u75a62eabp51432e609e2eb8e3@mail.gmail.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 47f87af9e1d92eac54caf69b67f82b72 Sending the PMK to the WTP breaks the current security model. Secure = handoff between WTPs would require a full 1X reauthentication. The PMK = SHOULD NOT be transmitted to the WTP. -- = t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Michael Montemurro wrote: > I believe the existing draft supports IEEE 802.11i in both Split MAC and = > local MAC modes. > = > The assumption in CAPWAP-02 is that: > 1) The IEEE 802.1X Authenticator and the RADIUS client reside on the AC. = > I don't see any reason why this should be changed for local or split MAC. > 2) RSNA Key Management resides on the AC. The PMK is cached on the AC = > and EAPoL-Key frames are generated by the AC. I don't see this as a = > problem for either split MAC or local MAC modes. > 3) The PTK and GTK are transmitted to the WTP by the AC. > = > I believe the solution meets the CAPWAP objectives. The solution works = > for both splitMAC or localMAC modes. > = > Saravanan requested that the keyRSC be maintained at the WTP. I think = > the best approach to address this is to negotiate between the AC and the = > WTP so that, upon successful IEEE 802.1X authentication, the PMK is = > passed from the AC to the WTP. The WTP would then transmit EAPoL-Key = > frames. > = > I believe this is a request that should be added to the wish list. > = > Thanks, > = > Mike > = > = > On 7/20/06, *Cheng Hong* > wrote: > = > Obviously, this is a type of "Split" case. Thus, it has to be > "mandatory". Or, the understanding of "mandatory" is different? > = > cheers > = > Cheng Hong > = > = > -----------------------------------------------------------------= ------- > *From:* Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com > ] > *Sent:* Thursday, July 20, 2006 11:27 PM > *To:* Saravanan Govindan; Michael Montemurro > *Cc:* capwap > = > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11i > Considerations > = > = > = > I'd like to understand how you've interpreted this feature as being > "mandatory". The current spec supports 802.11i, in both modes of > operation that we've agreed to, which is Split and Local MAC. > = > = > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > = > = > = > -----------------------------------------------------------------= ------- > *From:* Saravanan Govindan [mailto: > Saravanan.Govindan@sg.panasonic.com > ] > *Sent:* Wednesday, July 19, 2006 11:37 PM > *To:* Pat Calhoun (pacalhou); Michael Montemurro > *Cc:* capwap > *Subject:* RE: [Capwap] Clarification of Issue 43: IEEE 802.11i > Considerations > = > = > = > I'd like to clarify that this is indeed a "mandatory" objective > and needs to be integral to CAPWAP. Based on the exchanges so > far, I think support for this feature can be easily incorporated > in to the protocol. > = > = > = > We know the protocol needs this (from the requirement) and we > know how to do it (from the proposals), so let's just do it and > move forward. > = > = > = > Saravanan > = > = > = > = > = > = > = > = > = > -----------------------------------------------------------------= ------- > = > *From:* Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com > ] > *Sent:* Thursday, July 20, 2006 6:30 AM > *To:* Michael Montemurro; Saravanan Govindan > *Cc:* capwap > *Subject:* RE: [Capwap] Clarification of Issue 43: IEEE 802.11i > Considerations > = > = > = > My personal feeling is that this should be considered a "nice to > have", and therefore show up in the "wish" tracker category. > Given all of the work we have ahead of us, I don't believe there > is an urgent need to support this mode of operation, as the > current protocol achieves our objectives. So waiting for a > future version of the protocol would be my suggestion. > = > = > = > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > = > = > = > = > = > -------------------------------------------------------------= ----------- > = > *From:* Michael Montemurro > [mailto:montemurro.michael@gmail.com > ] > *Sent:* Tuesday, July 18, 2006 6:59 PM > *To:* Saravanan Govindan > *Cc:* capwap > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE > 802.11i Considerations > = > Saravanan, > = > = > = > I've given some additional thought to your requirements and > I believe it would require additional text as well as an > additional negotiation between the WTP and the AC. > = > = > = > We could separate the RSNA key management functions from the > "classical" IEEE 802.1X authenticator functions and allow > the WTP and AC negotiate where these functions reside: > = > = > = > The IEEE 802.1X authenticator functions would include the > PMK derivation. The PMK would be passed to the WTP upon > successful completion of the IEEE 802.1X authentication. > = > = > = > The RSNA key management functions would include the 4-way > handshake and the generation of GTK updates. > = > = > = > I think this is a cleaner mechanism to address your > requirements. > = > = > = > Does this make sense to you? > = > = > = > Cheers, > = > = > = > Mike > = > = > = > = > = > On 7/6/06, *Saravanan Govindan* < > Saravanan.Govindan@sg.panasonic.com > > wrote: > = > Hi Mike, > = > = > = > Thank you for the note. > = > = > I may not have been clear with my previous post. My request > is to have EAPoL frames generated at the AC alone =96 not at > the WTP. > = > = > = > My request is for designs where EAPoL frames are generated > at the AC and in those where the KeyRSC is maintained in the > WTP. These designs were highlighted in the Architecture > Taxonomy. > = > = > = > Specifically, I suggest that a CAPWAP message (it may be Add > WLAN or Update WLAN) be able to carry an EAPoL frame from > the AC to the WTP. This EAPoL frame (for Message 3 of 4-way > handshake or for Message 1 of group key handshake) would > have its KeyRSC field unassigned. Then when the WTP receives > this message, it fills in the right value of the KeyRSC, > updates the EAPoL frame and then transmit it to the wireless > station. > = > = > = > I hope this clarifies my suggestion. > = > = > Cheers, > = > = > Saravanan > = > = > = > = > = > = > = > = > = > -------------------------------------------------------------= ----------- > = > *From:* Michael Montemurro [mailto: > montemurro.michael@gmail.com > ] > *Sent:* Tuesday, July 04, 2006 9:47 PM > *To:* Saravanan Govindan > *Cc:* capwap > = > = > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE > 802.11i Considerations > = > = > = > Saravanan, > = > = > = > So, you would like to request that the WTP generate > EAPoL-Key frames for the 4-way handshake and the GTK update? > = > = > = > The current draft assumes that all EAPoL-Key frames are > generated at the AC. > = > = > = > Based on the following assumptions: > = > 1) This feature would be for local-MAC only. > = > 2) The 4-way handshake and the GTK handshake would originate > from the same location. > = > = > = > This would then require: > = > 1) Negotiation between the WTP and the AC on where the 4-way > handshake and GTK updates are generated. > = > 2) A modification to the updateWLAN message element to > include the PMK when a STA successfully associates. > = > = > = > I've captured this as issue 199. > = > = > = > On 7/3/06, *Saravanan Govindan* < > Saravanan.Govindan@sg.panasonic.com > > wrote: > = > Hi Mike, > = > = > = > I had a chance to review the new draft. > = > = > = > With regard to Issue 43, my understanding is that updates > were made in Section 11.9.1 (IEEE 802.11 Add WLAN). In > particular, the IEEE 802.11 Add WLAN message element now > allows the AC to send sequence counter values to the WTP. So > now, CAPWAP can support designs where the KeyRSC is > maintained by the AC. > = > = > = > My initial concern was with supporting designs where the > KeyRSC is maintained by the WTP. This is particularly > important to manage the 4-Way and Group-key handshakes. > = > = > = > With this in mind, I think the protocol still requires > support for designs where the KeyRSC is maintained by the > WTP. Based on the current draft, this support can be > included by adding another field to the IEEE 802.11 Add WLAN > message element. This field would contain Message-3 EAPoL > frame (for 4-Way handshake) or Message-1 EAPoL frame (for > Group-key handshake). These EAPoL frames would have > unassigned fields for KeyRSC (since the value is maintained > by the WTP). > = > = > = > I am also open to any alternatives to support this. > = > = > = > Cheers, > = > = > Saravanan > = > = > = > = > = > = > = > = > = > -------------------------------------------------------------= ----------- > = > *From:* Michael Montemurro [mailto: > montemurro.michael@gmail.com > ] > *Sent:* Tuesday, June 20, 2006 10:01 PM > *To:* Saravanan Govindan > *Cc:* Bob O'Hara (boohara); capwap > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE > 802.11i Considerations > = > = > = > Saravanan, > = > = > = > I've updated section 11.3 to deal with the GTK exchange and > the handling of the KeyRSC in draft -02 to address your > comments. I also provided a mechanism for the AC to transmit > the keyRSC to the WTP using the updateWLAN message element > as part of the Group Key exchange. > = > = > = > We're finalizing the -02 draft this week and you should be > able to look at it when we post it later this week. > = > = > = > Cheers, > = > = > = > Mike > = > = > = > = > = > = > = > ------------------------------------------------------------------------ > = > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > = > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jul 21 11:17:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3wkY-0001Lb-MB for capwap-archive@lists.ietf.org; Fri, 21 Jul 2006 11:17:10 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3wjq-0005DO-NR for capwap-archive@lists.ietf.org; Fri, 21 Jul 2006 11:16:28 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id D5BCD398045 for ; Fri, 21 Jul 2006 08:16:25 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 6345F43005A for ; Fri, 21 Jul 2006 08:14:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 23F81144801A for ; Fri, 21 Jul 2006 08:14:58 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id B02DA144800B for ; Fri, 21 Jul 2006 08:14:55 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 21 Jul 2006 08:14:56 -0700 X-IronPort-AV: i="4.07,169,1151910000"; d="scan'208,217"; a="307208052:sNHT72567964" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6LFEsVR005941; Fri, 21 Jul 2006 08:14:54 -0700 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 k6LFEsHS008631; Fri, 21 Jul 2006 08:14:54 -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.1830); Fri, 21 Jul 2006 08:14:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Jul 2006 08:14:53 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20239CD4E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Thread-Index: Acaq1wHFltx/sTmjR9+5w4E1E3S4UAAmXkXAABUulxAAEup7QAAXvGNgABojo0A= From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , "Michael Montemurro" X-OriginalArrivalTime: 21 Jul 2006 15:14:54.0143 (UTC) FILETIME=[6B667CF0:01C6ACD8] Authentication-Results: sj-dkim-8.cisco.com; header.DKIM-Signature=pcalhoun@cisco.com; dkim=fail ( 57 extraneous bytes; RSA-96 err: "Pat Calhoun \(pacalhou\)" ; cisco.com/sjdkim8002 fail; ); header.From=pcalhoun@cisco.com; dkim=neutral X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1936675015==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e9e2cc0dacaf97017f611889ac9df9f7 This is a multi-part message in MIME format. --===============1936675015== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6ACD8.6B446131" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6ACD8.6B446131 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The protocol today addresses requirement defined in Section 5.1.10 =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Thursday, July 20, 2006 10:44 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =09 =09 The requirement from Section 5.1.10 of RFC 4564 states that the "protocol MUST allow for the exchange of key information when authenticator and encryption roles are located in distinct entities."=20 =20 The current protocol draft needs to include operations to support key exchange in such designs. And the feature we've been discussing directly addresses this need.=20 =20 Saravanan =20 =20 =20 =20 =20 =09 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, July 20, 2006 11:27 PM To: Saravanan Govindan; Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 I'd like to understand how you've interpreted this feature as being "mandatory". The current spec supports 802.11i, in both modes of operation that we've agreed to, which is Split and Local MAC. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, July 19, 2006 11:37 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations I'd like to clarify that this is indeed a "mandatory" objective and needs to be integral to CAPWAP. Based on the exchanges so far, I think support for this feature can be easily incorporated in to the protocol.=20 =20 We know the protocol needs this (from the requirement) and we know how to do it (from the proposals), so let's just do it and move forward.=20 =20 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Thursday, July 20, 2006 6:30 AM To: Michael Montemurro; Saravanan Govindan Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 My personal feeling is that this should be considered a "nice to have", and therefore show up in the "wish" tracker category. Given all of the work we have ahead of us, I don't believe there is an urgent need to support this mode of operation, as the current protocol achieves our objectives. So waiting for a future version of the protocol would be my suggestion. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Tuesday, July 18, 2006 6:59 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, =20 I've given some additional thought to your requirements and I believe it would require additional text as well as an additional negotiation between the WTP and the AC. =20 We could separate the RSNA key management functions from the "classical" IEEE 802.1X authenticator functions and allow the WTP and AC negotiate where these functions reside: =20 The IEEE 802.1X authenticator functions would include the PMK derivation. The PMK would be passed to the WTP upon successful completion of the IEEE 802.1X authentication. =20 The RSNA key management functions would include the 4-way handshake and the generation of GTK updates. =20 I think this is a cleaner mechanism to address your requirements. =20 Does this make sense to you?=20 =20 Cheers, =20 Mike =09 =09 =20 On 7/6/06, Saravanan Govindan wrote:=20 Hi Mike, =20 Thank you for the note.=20 =09 I may not have been clear with my previous post. My request is to have EAPoL frames generated at the AC alone - not at the WTP.=20 =20 My request is for designs where EAPoL frames are generated at the AC and in those where the KeyRSC is maintained in the WTP. These designs were highlighted in the Architecture Taxonomy.=20 =20 Specifically, I suggest that a CAPWAP message (it may be Add WLAN or Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. This EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of group key handshake) would have its KeyRSC field unassigned. Then when the WTP receives this message, it fills in the right value of the KeyRSC, updates the EAPoL frame and then transmit it to the wireless station.=20 =20 I hope this clarifies my suggestion. =09 Cheers, =09 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com]=20 Sent: Tuesday, July 04, 2006 9:47 PM To: Saravanan Govindan Cc: capwap =09 Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 So, you would like to request that the WTP generate EAPoL-Key frames for the 4-way handshake and the GTK update? =20 The current draft assumes that all EAPoL-Key frames are generated at the AC. =20 Based on the following assumptions: 1) This feature would be for local-MAC only. 2) The 4-way handshake and the GTK handshake would originate from the same location. =20 This would then require: 1) Negotiation between the WTP and the AC on where the 4-way handshake and GTK updates are generated.=20 2) A modification to the updateWLAN message element to include the PMK when a STA successfully associates. =20 I've captured this as issue 199. =09 =20 On 7/3/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com > wrote:=20 Hi Mike, =20 I had a chance to review the new draft.=20 =20 With regard to Issue 43, my understanding is that updates were made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN message element now allows the AC to send sequence counter values to the WTP. So now, CAPWAP can support designs where the KeyRSC is maintained by the AC.=20 =20 My initial concern was with supporting designs where the KeyRSC is maintained by the WTP. This is particularly important to manage the 4-Way and Group-key handshakes.=20 =20 With this in mind, I think the protocol still requires support for designs where the KeyRSC is maintained by the WTP. Based on the current draft, this support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames would have unassigned fields for KeyRSC (since the value is maintained by the WTP). =20 I am also open to any alternatives to support this.=20 =20 Cheers, =09 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com]=20 Sent: Tuesday, June 20, 2006 10:01 PM=20 To: Saravanan Govindan Cc: Bob O'Hara (boohara); capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 I've updated section 11.3 to deal with the GTK exchange and the handling of the KeyRSC in draft -02 to address your comments. I also provided a mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message element as part of the Group Key exchange.=20 =20 We're finalizing the -02 draft this week and you should be able to look at it when we post it later this week. =20 Cheers, =20 Mike =20 =20 ------_=_NextPart_001_01C6ACD8.6B446131 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    The=20 protocol today addresses requirement defined in Section=20 5.1.10
     

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

     

    From: Saravanan Govindan=20 [mailto:Saravanan.Govindan@sg.panasonic.com]
    Sent: = Thursday, July=20 20, 2006 10:44 PM
    To: Pat Calhoun (pacalhou); Michael=20 Montemurro
    Cc: capwap
    Subject: RE: [Capwap] = Clarification=20 of Issue 43: IEEE 802.11i Considerations

    The requirement from =
Section 5.1.10 of RFC 4564 states that the “protocol MUST allow =
for the =
exchange of key information when authenticator and encryption roles are =
located in distinct entities.” =

     
    The current protocol draft needs to include operations to support =
key exchange in such designs. And the feature we’ve been =
discussing directly addresses this need. =

     
    Saravanan
     
     
     

     

     

    From: Pat=20 Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
    Sent:     Thursday, July 20, 2006 = 11:27=20 PM
    To: Saravanan = Govindan;=20 Michael Montemurro
    Cc:=20 capwap
    Subject: RE: = [Capwap]=20 Clarification of Issue 43: IEEE 802.11i=20 Considerations

     

    I'd like to = understand how you've interpreted this feature as being "mandatory". = The=20 current spec supports 802.11i, in both modes of operation that we've = agreed=20 to, which is Split and Local=20 MAC.

     

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

     

     

    From:=20 Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] =
    Sent:     Wednesday, July 19, = 2006 11:37=20 PM
    To: Pat = Calhoun=20 (pacalhou); Michael Montemurro
    Cc: capwap
    Subject: RE: [Capwap] = Clarification of=20 Issue 43: IEEE 802.11i Considerations

    I’d like to = clarify that this is=20 indeed a “mandatory” objective and needs to be integral = to CAPWAP. Based on=20 the exchanges so far, I think support for this feature can be easily = incorporated in to the protocol.

     

    We know the protocol = needs this=20 (from the requirement) and we know how to do it (from the = proposals), so=20 let’s just do it and move forward. =

     

    Saravanan

     

     

     

     

    From: Pat=20 Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
    Sent:     Thursday, July 20, 2006 = 6:30=20 AM
    To: Michael = Montemurro;=20 Saravanan Govindan
    Cc:=20 capwap
    Subject: = RE:=20 [Capwap] Clarification of Issue 43: IEEE 802.11i=20 Considerations

     

    My = personal feeling=20 is that this should be considered a "nice to have", and therefore = show up in=20 the "wish" tracker category. Given all of the work we have ahead of = us, I=20 don't believe there is an urgent need to support this mode of = operation, as=20 the current protocol achieves our objectives. So waiting for a = future=20 version of the protocol would be my=20 suggestion.

     

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

     

     

    From:=20 Michael Montemurro [mailto:montemurro.michael@gmail.com] =
    Sent:     Tuesday, July 18, = 2006 6:59=20 PM
    To: = Saravanan=20 Govindan
    Cc:=20 capwap
    Subject: = Re:=20 [Capwap] Clarification of Issue 43: IEEE 802.11i=20 Considerations

    Saravanan,

     

    I've given some additional thought to = your=20 requirements and I believe it would require additional text as = well as an=20 additional negotiation between the WTP and the=20 AC.

     

    We could separate the RSNA key = management functions from the "classical" IEEE 802.1X = authenticator=20 functions and allow the WTP and AC negotiate where these functions = reside:

     

    The IEEE 802.1X authenticator functions = would=20 include the PMK derivation. The PMK would be passed to the WTP = upon=20 successful completion of the IEEE 802.1X=20 authentication.

     

    The RSNA key management functions would = include=20 the 4-way handshake and the generation of GTK=20 updates.

     

    I think this is a cleaner mechanism to = address=20 your requirements.

     

    Does this make sense to you?=20

     

    Cheers,

     

    Mike



     

    On 7/6/06, Saravanan Govindan <Saravanan.Govindan@sg= .panasonic.com>=20 wrote:

    Hi=20 Mike,

     

    Thank you for the = note.=20


    I may not have = been clear=20 with my previous post. My request is to have EAPoL frames = generated at the=20 AC alone – not at the WTP.

     

    My request is for = designs=20 where EAPoL frames are generated at the AC and in those where the = KeyRSC=20 is maintained in the WTP. These designs were highlighted in the=20 Architecture Taxonomy.

     

    Specifically, I = suggest that a=20 CAPWAP message (it may be Add WLAN or Update WLAN) be able to = carry an=20 EAPoL frame from the AC to the WTP. This EAPoL frame (for Message = 3 of=20 4-way handshake or for Message 1 of group key handshake) would = have its=20 KeyRSC field unassigned. Then when the WTP receives this message, = it fills=20 in the right value of the KeyRSC, updates the EAPoL frame and then = transmit it to the wireless station.

     

    I hope this = clarifies my=20 suggestion.


    Cheers,


    Saravanan

     

     

     

     

    From:=20 Michael Montemurro [mailto: montemurro.michael@gmail.com]
    Sent:     Tuesday, July 04, = 2006 9:47=20 PM
    To: = Saravanan=20 Govindan
    Cc:=20 capwap


    Subject: Re: [Capwap] = Clarification=20 of Issue 43: IEEE 802.11i=20 = Considerations

     

    Saravanan,

     

    So,=20 you would like to request that the WTP generate EAPoL-Key frames = for the=20 4-way handshake and the GTK = update?

     

    The=20 current draft assumes that all EAPoL-Key frames are generated at = the=20 AC.

     

    Based=20 on the following assumptions:

    1)=20 This feature would be for local-MAC=20 only.

    2)=20 The 4-way handshake and the GTK handshake would originate from the = same=20 location.

     

    This=20 would then require:

    1)=20 Negotiation between the WTP and the AC on where the 4-way = handshake and=20 GTK updates are generated.

    2) A=20 modification to the updateWLAN message element to include the = PMK=20 when a STA successfully = associates.

     

    I've=20 captured this as issue=20 199.

     

    On=20 7/3/06, Saravanan = Govindan=20 <=20 Saravanan.Govindan@sg.panasonic.com> wrote:=20

    Hi=20 Mike,

     

    I had a chance to = review the=20 new draft.

     

    With regard to Issue = 43, my=20 understanding is that updates were made in Section 11.9.1 (IEEE = 802.11 Add=20 WLAN). In particular, the IEEE 802.11 Add WLAN message element now = allows=20 the AC to send sequence counter values to the WTP. So now, CAPWAP = can=20 support designs where the KeyRSC is maintained by the AC.=20

     

    My initial concern = was with=20 supporting designs where the KeyRSC is maintained by the WTP. This = is=20 particularly important to manage the 4-Way and Group-key = handshakes.=20

     

    With this in mind, I = think the=20 protocol still requires support for designs where the KeyRSC is = maintained=20 by the WTP. Based on the current draft, this support can be = included by=20 adding another field to the IEEE 802.11 Add WLAN message element. = This=20 field would contain Message-3 EAPoL frame (for 4-Way handshake) or = Message-1 EAPoL frame (for Group-key handshake). These EAPoL = frames would=20 have unassigned fields for KeyRSC (since the value is maintained = by the=20 WTP).

     

    I am also open to = any=20 alternatives to support this.

     

    Cheers,


    Saravanan

     

     

     

     

    From:=20 Michael Montemurro [mailto: montemurro.michael@gmail.com]
    Sent:     Tuesday, June 20, = 2006 10:01 PM=20
    To: Saravanan=20 Govindan
    Cc: = Bob O'Hara=20 (boohara); capwap
    Subject: Re: [Capwap] = Clarification=20 of Issue 43: IEEE 802.11i=20 Considerations

     

    Saravanan,

     

    I've=20 updated section 11.3 to deal with the GTK exchange and the = handling of the=20 KeyRSC in draft -02 to address your comments. I also provided a = mechanism=20 for the AC to transmit the keyRSC to the WTP using the updateWLAN = message=20 element as part of the Group Key exchange.=20

     

    We're=20 finalizing the -02 draft this week and you should be able to look = at it=20 when we post it later this = week.

     

    Cheers,

     

    Mike

     

     

    = ------_=_NextPart_001_01C6ACD8.6B446131-- --===============1936675015== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1936675015==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jul 21 11:59:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3xP9-0008Uf-8O for capwap-archive@lists.ietf.org; Fri, 21 Jul 2006 11:59:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3wmK-0005fb-83 for capwap-archive@lists.ietf.org; Fri, 21 Jul 2006 11:19:00 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3wb5-0000Ya-Q9 for capwap-archive@lists.ietf.org; Fri, 21 Jul 2006 11:07:27 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 88BFD39807A for ; Fri, 21 Jul 2006 08:07:12 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 6792B43005A for ; Fri, 21 Jul 2006 08:06:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 58DE3144802F for ; Fri, 21 Jul 2006 08:06:19 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by hermes.tigertech.net (Postfix) with ESMTP id 6BC87144801A for ; Fri, 21 Jul 2006 08:06:16 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id m51so1309140pye for ; Fri, 21 Jul 2006 08:06:15 -0700 (PDT) Received: by 10.35.60.15 with SMTP id n15mr1399345pyk; Fri, 21 Jul 2006 08:06:15 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Fri, 21 Jul 2006 08:06:15 -0700 (PDT) Message-ID: <26140d940607210806m515e5480sc1743289514ec9f7@mail.gmail.com> Date: Fri, 21 Jul 2006 11:06:15 -0400 From: "Michael Montemurro" To: "Saravanan Govindan" In-Reply-To: <5F09D220B62F79418461A978CA0921BD010735A0@pslexc01.psl.local> MIME-Version: 1.0 References: <5F09D220B62F79418461A978CA0921BD010735A0@pslexc01.psl.local> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0064723633==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.5 (--) X-Scan-Signature: 40dcdfec62eed13950fa8e354a820e1d --===============0064723633== Content-Type: multipart/alternative; boundary="----=_Part_31805_32129947.1153494375458" ------=_Part_31805_32129947.1153494375458 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Saravanan, The current draft meets this requirement: The protocol allows for the PTK and GTK to be transmitted from the AC to the WTP when encryption is done on the WTP. Mike On 7/21/06, Saravanan Govindan wrote: > > The requirement from Section 5.1.10 of RFC 4564 states that the "protoco= l MUST allow for the exchange of key information when authenticator and enc= ryption roles are located in distinct entities." > > > > The current protocol draft needs to include operations to support key exc= hange in such designs. And the feature we've been discussing directly addre= sses this need. > > > > Saravanan > > > > > > > > > > > ------------------------------ > > *From:* Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > *Sent:* Thursday, July 20, 2006 11:27 PM > *To:* Saravanan Govindan; Michael Montemurro > *Cc:* capwap > *Subject:* RE: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderat= ions > > > > I'd like to understand how you've interpreted this feature as being > "mandatory". The current spec supports 802.11i, in both modes of operatio= n > that we've agreed to, which is Split and Local MAC. > > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > ------------------------------ > > *From:* Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > > > *Sent:* Wednesday, July 19, 2006 11:37 PM > *To:* Pat Calhoun (pacalhou); Michael Montemurro > *Cc:* capwap > *Subject:* RE: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderat= ions > > I'd like to clarify that this is indeed a "mandatory" objective and need= s > to be integral to CAPWAP. Based on the exchanges so far, I think support = for > this feature can be easily incorporated in to the protocol. > > > > We know the protocol needs this (from the requirement) and we know how to > do it (from the proposals), so let's just do it and move forward. > > > > Saravanan > > > > > > > > > ------------------------------ > > *From:* Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > *Sent:* Thursday, July 20, 2006 6:30 AM > *To:* Michael Montemurro; Saravanan Govindan > *Cc:* capwap > *Subject:* RE: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderat= ions > > > > My personal feeling is that this should be considered a "nice to have", > and therefore show up in the "wish" tracker category. Given all of the wo= rk > we have ahead of us, I don't believe there is an urgent need to support t= his > mode of operation, as the current protocol achieves our objectives. So > waiting for a future version of the protocol would be my suggestion. > > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > ------------------------------ > > *From:* Michael Montemurro [mailto:montemurro.michael@gmail.com] > > > *Sent:* Tuesday, July 18, 2006 6:59 PM > *To:* Saravanan Govindan > *Cc:* capwap > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderat= ions > > Saravanan, > > > > I've given some additional thought to your requirements and I believe it > would require additional text as well as an additional negotiation betwee= n > the WTP and the AC. > > > > We could separate the RSNA key management functions from the "classical" > IEEE 802.1X authenticator functions and allow the WTP and AC negotiate > where these functions reside: > > > > The IEEE 802.1X authenticator functions would include the PMK derivation. > The PMK would be passed to the WTP upon successful completion of the IEEE > 802.1X authentication. > > > > The RSNA key management functions would include the 4-way handshake and > the generation of GTK updates. > > > > I think this is a cleaner mechanism to address your requirements. > > > > Does this make sense to you? > > > > Cheers, > > > > Mike > > > > > > On 7/6/06, *Saravanan Govindan* > wrote: > > Hi Mike, > > > > Thank you for the note. > > > I may not have been clear with my previous post. My request is to have > EAPoL frames generated at the AC alone =96 not at the WTP. > > > > My request is for designs where EAPoL frames are generated at the AC and > in those where the KeyRSC is maintained in the WTP. These designs were > highlighted in the Architecture Taxonomy. > > > > Specifically, I suggest that a CAPWAP message (it may be Add WLAN or > Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. This > EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of group k= ey > handshake) would have its KeyRSC field unassigned. Then when the WTP > receives this message, it fills in the right value of the KeyRSC, updates > the EAPoL frame and then transmit it to the wireless station. > > > > I hope this clarifies my suggestion. > > > Cheers, > > > Saravanan > > > > > > > > > ------------------------------ > > *From:* Michael Montemurro [mailto: montemurro.michael@gmail.com] > > *Sent:* Tuesday, July 04, 2006 9:47 PM > *To:* Saravanan Govindan > *Cc:* capwap > > > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderat= ions > > > > Saravanan, > > > > So, you would like to request that the WTP generate EAPoL-Key frames for > the 4-way handshake and the GTK update? > > > > The current draft assumes that all EAPoL-Key frames are generated at the > AC. > > > > Based on the following assumptions: > > 1) This feature would be for local-MAC only. > > 2) The 4-way handshake and the GTK handshake would originate from the sam= e > location. > > > > This would then require: > > 1) Negotiation between the WTP and the AC on where the 4-way handshake an= d > GTK updates are generated. > > 2) A modification to the updateWLAN message element to include the PMK > when a STA successfully associates. > > > > I've captured this as issue 199. > > > > On 7/3/06, *Saravanan Govindan* < Saravanan.Govindan@sg.panasonic.com> > wrote: > > Hi Mike, > > > > I had a chance to review the new draft. > > > > With regard to Issue 43, my understanding is that updates were made in > Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add > WLAN message element now allows the AC to send sequence counter values to > the WTP. So now, CAPWAP can support designs where the KeyRSC is maintaine= d > by the AC. > > > > My initial concern was with supporting designs where the KeyRSC is > maintained by the WTP. This is particularly important to manage the 4-Way > and Group-key handshakes. > > > > With this in mind, I think the protocol still requires support for design= s > where the KeyRSC is maintained by the WTP. Based on the current draft, th= is > support can be included by adding another field to the IEEE 802.11 Add > WLAN message element. This field would contain Message-3 EAPoL frame (for > 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). Thes= e > EAPoL frames would have unassigned fields for KeyRSC (since the value is > maintained by the WTP). > > > > I am also open to any alternatives to support this. > > > > Cheers, > > > Saravanan > > > > > > > > > ------------------------------ > > *From:* Michael Montemurro [mailto: montemurro.michael@gmail.com] > > *Sent:* Tuesday, June 20, 2006 10:01 PM > *To:* Saravanan Govindan > *Cc:* Bob O'Hara (boohara); capwap > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderat= ions > > > > Saravanan, > > > > I've updated section 11.3 to deal with the GTK exchange and the handling > of the KeyRSC in draft -02 to address your comments. I also provided a > mechanism for the AC to transmit the keyRSC to the WTP using the updateWL= AN > message element as part of the Group Key exchange. > > > > We're finalizing the -02 draft this week and you should be able to look a= t > it when we post it later this week. > > > > Cheers, > > > > Mike > > > > > > ------=_Part_31805_32129947.1153494375458 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
    Saravanan,
     
    The current draft meets this requirement: The protocol allows for the = PTK and GTK to be transmitted from the AC to the WTP when encryption is don= e on the WTP.
     
    Mike

     
    On 7/21/06, = Saravanan Govindan <Saravanan.Govindan@sg.panasonic.com> wrote: 
    The requirement from Section 5.1.10 of RFC 4564 states t=
hat the "protocol MUST allow for 
the exchange of key information when authenticator and encryption roles are=
 located in distinct entities."
     
    The current protocol draft=
 needs to include operations to support key exchange in such designs. And t=
he feature we've been discussing directly addresses this need.=20

     
    <= pre> Saravanan
    =
 
    
 
    <=
span style=3D"FONT-SIZE: 10pt"> 

     

     

    From: Pat = Calhoun (pacalhou) [mailto: p= calhoun@cisco.com]


    Sent: Thursday, July 20, 2006 11:27 PM
    To: Saravanan Govindan; Michael Montemurro
    Cc: capwap
    Subject: RE: [Capwap] = Clarification of Issue 43: IEEE 802.11i Considerations=20

    I'd like to understand how you've i= nterpreted this feature as being "mandatory". The current spec su= pports=20 802.11i, in both modes of operation that we've agreed to, which is Split an= d Local MAC.

    From: Saravanan Govindan [mailto:Saravanan.Govi= ndan@sg.panasonic.com ]


    Sent: Wednesday, July 19, 2006 11:37 PM
    To: Pat Calhoun (pacalhou); Michael Montemurro
    Cc: capwap
    Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations<= /span>

    I'd like to clarify that this is indeed a "mandatory" objective= and needs to be integral to CAPWAP. Based on the exchanges so far, I think= support for this feature can be easily incorporated in to the protocol.=20

     

    We know the protocol needs this (from the requirement) and we k= now how to do it (from the proposals), so let's just do it and move forward= .=20

     

    Saravanan

     

     

     

     

    From: Pat = Calhoun (pacalhou) [mailto: p= calhoun@cisco.com]


    Sent: Thursday, July 20, 2006 6:30 AM
    To: Michael Montemurro; Saravanan Govindan
    Cc: capwap
    Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations<= /span>

    My personal feeling is that this sh= ould be considered a "nice to have", and therefore show up in the= "wish" tracker category. Given all of the work we have ahead of = us, I don't believe there is an urgent need to support this mode of operati= on, as the current protocol achieves our objectives. So waiting for a futur= e version of the protocol would be my suggestion.

    From: Michael Montemurro [mailto:montemurro.michael@gmail.com= ]


    Sent: Tuesday, July 18, 2006 6:59 PM
    Cc: capwap
    Subject:<= /b> Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations

    On 7/6/06, Saravanan Govindan<= /span> < Saravanan.Govindan@sg.panasonic.com> wrote:

    Hi Mike,

    Thank you for the note.


    I may not have been clear with my previous post. My request= is to have EAPoL frames generated at the AC alone =96 not at the WTP.

    My request is for designs where EAPoL frames are generated at t= he AC and in those where the KeyRSC is maintained in the WTP. These designs= were highlighted in the Architecture Taxonomy.=20

    Specifically, I suggest that a CAPWAP message (it may be Add WL= AN or Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. = This EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of grou= p key handshake) would have its KeyRSC field unassigned. Then when the WTP = receives this message, it fills in the right value of the KeyRSC, updates t= he EAPoL frame and then transmit it to the wireless station.=20

    I hope this clarifies my suggestion.


    Cheers,


    Saravanan

    From: Mich= ael Montemurro [mailto:=20 montemurro.micha= el@gmail.com ]


    Sent: Tuesday, July 04, 2006 9:47 PM
    Cc: capwap

    Subject: Re: [C= apwap] Clarification of Issue 43: IEEE 802.11i Considerations=

    Saravanan Govindan= < Saravanan.Govindan@sg.panasonic.com> wrote:

    Hi Mike,

    I had a chance to review the new draft.

    With regard to Issue 43, my understanding is that updates were = made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.= 11 Add WLAN message element now allows the AC to send sequence counter values= to the WTP. So now, CAPWAP can support designs where the KeyRSC is maintai= ned by the AC.

    My initial concern was with supporting designs where the KeyRSC= is maintained by the WTP. This is particularly important to manage the 4-W= ay and Group-key handshakes.=20

    With this in mind, I think the protocol still requires support = for designs where the KeyRSC is maintained by the WTP. Based on the current= draft, this support can be included by adding another field to the IEEE=20 802.11 Add WLAN message element. This field would contain Message-3 EAPoL f= rame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshak= e). These EAPoL frames would have unassigned fields for KeyRSC (since the v= alue is maintained by the WTP).=20

    I am also open to any alternatives to support this.

    Cheers,


    Saravanan

    From: Mich= ael Montemurro [mailto:=20 montemurro.micha= el@gmail.com ]


    Sent: Tuesday, June 20, 2006 10:01 PM
    To: Saravanan Govindan
    Cc: Bob O'Hara (boohara); capwap
    Subject: Re: [Capwap] Clarification of Issue 43: IEEE 8= 02.11i Considerations

    From: "watchdog" To: capwap-archive@ietf.org Subject: link bookmark following url: Date: Fri, 21 Jul 2006 17:24:56 -0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C6ACEA.95CB2100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2873 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2873 X-Spam-Score: 2.1 (++) X-Scan-Signature: 2f46977da373544777a750d5247d6ccc ------=_NextPart_000_000F_01C6ACEA.95CB2100 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C6ACEA.95CCA7A0" ------=_NextPart_001_0010_01C6ACEA.95CCA7A0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Burmese juntaBBC execs bouncing inc pp. youve index About copy Limited England stand wind farms Film Football Bavaria Premium lager print pdf puzzle series save Search this site Todays requested files Crack found silent death archive: Besson Xan reclaims pillaged pastArts: Athens Rome clamp adobe photoshop duty across entrance Will fiction patches. asks Rachel Cooke keen into learn him Ellis Dorota Jonathan Ops: Get taken them viewing planets stars galaxies visible Baltimore area.Meet Britain. Helen Organ Grinder stories desktop favourite medicine seek secret DNA modern humans developed cognitive ethics science Study massive drop key early IndiaMore lucrative summed possible. There ------=_NextPart_001_0010_01C6ACEA.95CCA7A0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

    3D""=20
    Burmese juntaBBC execs bouncing
    inc pp. youve
    index About copy Limited England
    stand wind farms
    Film Football
    Bavaria Premium lager
    print pdf puzzle series
    save
    Search this site Todays
    requested files Crack found
    silent death archive:
    Besson Xan reclaims pillaged pastArts: Athens Rome clamp
    adobe photoshop duty
    across entrance Will fiction
    patches.
    asks Rachel Cooke keen
    into
    learn him
    Ellis
    Dorota
    Jonathan
    Ops: Get taken them
    viewing planets stars galaxies visible Baltimore area.Meet
    Britain. Helen
    Organ Grinder
    stories desktop favourite
    medicine seek secret DNA
    modern humans developed cognitive ethics science Study massive drop key
    early
    IndiaMore
    lucrative summed
    possible. There
    ------=_NextPart_001_0010_01C6ACEA.95CCA7A0-- ------=_NextPart_000_000F_01C6ACEA.95CB2100 Content-Type: image/gif; name="unknown.gif" Content-Transfer-Encoding: base64 Content-ID: <000e01c6ace2$3406b900$0fe0fc3e@laptop> R0lGODdh1gGmAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAA1gGmAQcI/gABCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHgvZCihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jTql3Ltq3b t2V/SRopl2bdmnfBviGQoGkAdXADCyb6ZiC4k3ntJYa5WOQtgXxTNj5ZpS/JySwfA4j88pcg y/YKCzz8S8FAy54tV4CkmbNi05v7pg65OiQR0INz67a517Ip3CITY2Y5fLbkuSwr8zT+0gTg kL1D/p5dGvBsE4cVf6a7/Q0k7X2x/ot8k323+fMuAwB/DQCI7LmlBX733EZgAhPtE4gGYF1S CQK+IBdAeSGlJlcJ+RUI23zI3YUffxUMBMmBACIXoXshPficSQb6lyBt8pF0m0jqXbadPbfw lZp3wZ1Y4HYGfsbiSAWsh96NODInUgV93cIgAjwqBp8CgD3W43cFCpFAae8BuWGLSypwJG3v CVngXD6G1I49yr1WpXMofpelPVsi9hmTYWZIYHDIgWciaLd5ZguSL+JG3ZmCzFlSlzj2ieOY EarYZpySUAdfg4iOVNldclHwJJSMwgfjoVemKVKXkSJQo20JjCnZmYnas2lJt5QHaGzM8Rgf nW5CaY94/6uWZIKNftYqmHGpeaqqJGPWFWmlornHqGlr1vlrr5RaaU+EAPSFKaLxCYQhs7SC 96uOjpWHK55wLikIAn+5GtyCL4L76Ky2prtbidaeSOi1ocqVorNLIgrueh1Weu2kI3mHwLNX amrjjByCqq+LdLVpD7sxWjavgVLWyZ2dZ0Z8abXqZpxWdLMFmaVcCIzI4q9CukGaksdiODHJ Is+n5KvfvdLjYegqWxeY9vwmM4o0s2psqBUUy+l4kTXspZscb2fCfAjPFl1Io2osdVv7PRdf 0VgKJEqymQYAACRU1FtpaCqjCFmAY2u2NXQCsZJ1bOxNCHSIrfXFrmNnh7rsaP4k4cy2QNbB 1qzErxJgC2T3MU2xZSZERt7UkEfe1nAyYavUiJJnrvlYbzx609NLhbv56KSXbvrpqKeu+uqs t+7667DHLvvstNdu++2456777rz37vvvwAcv/PDEF2/88cgnr/zyzDfv/PPQRy/99NRXb/31 2Gev/fbcd+/99+CHL/745Jdv/vnlRzsQgCfmini0PrP3tfzr9zjQk1UbVxveqJJLl+AAMEDQ RLI09Z1NcLIBIDhKU57GRYkgC0TY3QjWKohZrWKnURAE1dcXCvptf62qIAYNw0H0XWVbqIHR dtj1G5KwEDTMeZronkaJ6xRrNi+cmAtl4yIUokhFTf4TgiQsEwAgLm4kvWpa+84kRB56K4HW UWKPjCgSzP1CCi8LIQp1RB0imbAqPnST0Qpmo1SBZl72wFydKAgphOkQiQQA0hFbFScltqFH ouDWGwkIGL8RLka2iOITQ/IwKQ4tSJYKjTpwxpwtGvKHGMvKN7IXxjvZzXMkwmQYOcXFPMVP YqIrieUi5DMfjkyJaDNDLfQorhah7U3G+lYlnsicOh5xRo9T5MUY1cMlDrKVavwiVHAFwKLB CDb4QuYbdaQeT2nwk2JU5v8Igposiita2TGgt/5VjxqO0D7YIkZh8OXLXKljjMt64Gmw6SqA ccmJ1/xms8xIvHecp5IqxP/NLcpGkn3C0JcjuQ0aW2QuMiKRn5bDTyl9OaNO6kcK52Ql4fYY z0FWwhcSteXEKLir8RBEkBV1aBUjKcyj4BOeI0GkSVRKT0JGJpgQIydwVBpCQkKioBVdFkgh hTKJ1nSiId3OLfL4y0IesQIbIk/nLnawf6bwl4QbaEmfclLw3MJq1kQRVp1KNCI+h4ZOc02d rpqkOY4Ukjn9RU/Nis6fujWd0CHNiSpARTSJVK2okUTYxsZJhCHycXe12FSpClCrQgZc0lqP 1z4EVM3wp1/rPJED+RfHxfKTfgEcYIboFMa9+EKBjZTnAgXHGcuFZLFIMs7DEKhBEp7oaSDM ZYb+zklau4UIs6PN4GB3y9veNsUFvg2ucIdL3OIa97jITa5yp0o5qTV3OQpbLlg2iRMQJkwm 7mTTTKoGXezm9TLR3YlwsipdrFDXJlckr7Jgwied0DAq2SXKeElaXsI+lWQLSyyILgudRW4I fnK06X7fUwIgSEBCNwOcXA7EWMsCJ5jcpY998CMsD2EowgJKLIMvy6yvbfhLgENidsTzqudc CDQnVtaA8FpfrWwRaM8ZEZicucs2BakupZptidOEpndeaUztWHDEABVjs9IFZV40UpjQREG8 ggypnBxy/DAlZSEB+bpcGqKPZ4wkLgvJSVCjb4uZYkBBNXVoowqmspT+Y6gwp7EvaRZbSJ7l qQUnyjjBpLGi5BypvARzUYVyF5/D605f8QqaixLHG+DMaDRbhlCOEknUxgzGcibKU3ES3GX3 81hkZahT89G0nH38ZWrZuVKY1qdYQ6PheBVqUB1sdarxy1SbHQpI9umbfjq1QHHQT1iijk95 Jk3pqTiySn5uNGW+S7JSLdrN2p3zd6EjN3idNaCqphfJTm3VyAA62bSW9tgMPR6fXVU5BQgk tCVtJ0nca93FNnY5X7a008qG3s9pYbSH1rIqannHORt1zeTiiplx+y4lYnG/OEMJkykGZa6+ y+MAC/F3O1lvBJy2oQvOs8tIATkm+DfOWjj/crH5M97mBaho3EZIgUBhrrcdD4FmrLU2kRhE 88vLquT1vlenzeVuZHWuvQa2QV8JfiT6WthwDHSjX8Y0ctMXrxBXEiijFed0YhaDoAOEWqgX 5WF5rnnDixeyHwfsvnvQqrmidjG3ROyvojra50735Fqj7njPu973zvfNwR0sXhNa5czed82V kDGET0l7Wzs/oSxexy8JVBkT70K559c1XnONZqBZ+OkKde0q+fueRRl0oDye1J0pPdx/wQ5q U6njcM1xaDjf+bDnk0J9STGGT0sa02AoUx1mFRd9T+DIpBjrbrhfhgAX/JE8CNgJwv2b4EUB h9FeYpuaTfa3Q+za/pPFab1nXJGEX3Gre2zra5ZpSqfUYy+/6oZKuvLpu3T+o5He6PIaMUlP 6URL3gIKsIFJ3ucVJZQXcbZnjWI1sEYyj6c+C7SAbXKA3fdOzjR/VcJJZpcvVgIymzKBO0RH vyRQnHE3A+h598ZnoiZ00JcduuJ0DegiLTgsAyEsCBMsuZdrFphIHUVG1uYcsoUSomNJ/kcn flSCBDhXozZpaARoFidobYZ6rYRnSWhWSwga/pKDUogZRkNucrFXKUGC29doucIZRWiEXEEd EMdH0qEfJ2Ny08J+9NZl6rcj7Gdz+ZZ75UFxCbAzOVYzJEF/dXgSHxOHygJC9faB6wd7/x6T HeGicGZIgLDxewqjdaeldHL2BtDHGSvXIFBHUVdzgVi3I3xDdGFTN3Hzh6hhGlhTEl6jMpuo LH5IgmZDTZWIeXBTiYPziPU1KqKni3wnW0vli8LofQYwjMZ4jMiYjMq4jMdFD8z4jNAYjdI4 jdRYjdZ4jdiYjdq4jdzYjd74jeAYjuI4juRYjuZ4juiYjnOnb+rYOtzFEw0IG6vWiybBji5l I5kHGvnYjn3yXvCofmx0E9FSWgqwdov4erLHj+gBU3fmHxXyHzcoiQgyLRKiQx3yH69EiXuj ModIIwnwG2bwaPXQfWEoKijlO9pQeFx0ZxHTfuN3NGPygv3Xkv9zcXM7NiYdWSnsGCTEJoT5 pJDnQWPWtl5xxoDqByv2MmkHeBKSB3k96YSCBpTmIVW2VpW/5oLJdFt91kMpmBL4EUcdxlhi pEemJZVwAVP8gl+TZpT3h2ULhjAeWI/3gRskCU8laZa6AVaEiF8lRzJ+2Eq2BiQzd4cwcxm+ Zgr/QpeMgyQHGXuCh5dvsR+xBgAsR2uUuG2dCJgkwyzZoZE5iYu5yG6blXS2CHqQaT32eJq+ lZqq2Zqu+ZqwGZuyOZsCSXmzw5q0CRRI14vxWBCm2RnyCBy9aEC3WBOnVxKpGTWLBXr7WItu d5ovxJvVUpaV0x3Xl3rPqRLHOS5U95X/qNF6s1d1M4OQj0mN8iAUKzmRqRh9/mFgFdmWoiiR 7FMfzUJhR3SRFRKKG0krxoFhEJlfH5JizfeZJgmSoNF92FKSd5mbp/UkaAIo7Gcx28kcXmZX STY4ziSENPl+zveSBnVkUaIaRXaTSMInn1kXybkebOSTJ3k98zA70XKB5IaBtfahJkmjVikc SkMaSamYQwOfCNggUXmA2wkiq9Z9spiFUcmg/VRhqJZ1ozah7RNsrsZX8pNa0MKVM1hGLmKD dzFrKVikBFScxBZKrrKFpcegO+grTtgmUnqg7TZuGLeSRweXkaRa3uZ0b3ajo7cSv+GHkyaL oql9LUqbZPVw/05Xf3nxl7AEedNRpetVU8A3mGv4oXqYFwmHb5Xqhyd6mIkpmvbWN4w5no7J pEnHnuOmiqAYK0C6NzkHqToap4XIN64KTcxBiqOmGS+nGlrZiQS6WLn4IJ1WEOFBJ815edlp qpBDj8iZrMqaO213E7j5rNRardZ6rdiarS3GrNqqG4c3dstmpZXjP2I6E9/arTHhGX5wdSdk duWaHr5BLz4xG1SJri4hhQMmijlHfNpBn/eRHxJWnwHKnurZWt/BXcHnK/z6YaNJUQnrkA8k kQ2mX2dqMKVmffYKSzPifjapqBd6JNVhNlNSoVUGV/NFak8WoVNSmC70KFSmGiprKf9Wh5Yd xKOopn8ZO00AMGyPpmzrRShyum3uVpR3xi+j9yzghnGiJE2FBoFntqfcmWsk04HOyqArklrB BoNQKrRcS6VPOjY2iLKHRofhJogY4k4xeGl0QrOI6pfq8IM52zHPsZa91LNc62oC45ZcgyV5 KrZZqLQoESSF1qZSd22EoypG24VVa7UwoqkBtywEoqgRV6V9GSr9poevklcB9jGh8pmHymID Z2OBqGInaJEoQ4i0cZ3Y2p/GF3OcyR6raGtCG4rNVnOVWHRxo7Bw45fx42DPpHOqapW62jSR aBmv+Gk5SzzcyqfJm3aWBxNw27zSO73UW73V6ADWWyulMBb/gdeuKLG80hsABlAKboAhvuuc pIkx9hlXOQEmIPOu4foS8SWuWOYSOditj2E14BkdjdmYHIIlSBKX7IUb8GsSBSxu30t40mnA i9ua4ku+CMV9dnmSeZFjdRGMomRhxRex4SEttSAJFPCeV1Kw7EGRt5ViDPuwyRdii6EhDFvC BOaeMeeqjYfCDolR/rq+qrm9sgJSaApDbYJjN+WBTBZqMGspbOZu8dhBo4rEoEGyK5tdF4dE SBJkJeuxlnG/JHo0IatketaahWFMdrukkWqfnSNs4DVS+DUiSfypaYyje8onRDs28QVoVBxt M/pmeaHFc5yjtomXP6yhBeEzNYIu/zSVtAL2em3cgLDWgijrtekHLK1GEqamtmTrpjZCZVs6 u5EqmyOioBRMdkulHH/JS3wWlYuML0IagvIKb2xpZXk6Gd6xL3aLyQwMqnKay7D5bGjVv6RK vzdqyLIKWKLrxFbCqMqSS/WXuWoYcH6ZVw43xSLBhw84NpKbcSbBqXfIyeA7jgOpj8V5rJ0M cGiss1jKnZyRxKcYtZwVvOt8mfECdSCDq4lRN5i5u0GcmdzJmCHCzX/cJ5+gkv+MeNkrO92M GANd0Aq90LxlBAz90FDhjBA90RRd0RZ90Rid0Rq90Rzd0R790SAd0iJ9GScBXCN90iid0iq9 0uCYBu140P9vXL0FqEB/wx8GNFoXpE71k1Oz+FiYVZwhay0K5DcdacH+83YJTRzRxUAEREXR 1M8ABNSsddM70s66tVI+kz9R7RpBrVrKB3AsC3voQ69O3VUh4U120kRaFHSmNIIOytZq3Vae UkTGCxg5hNTddWT/Rtc+dNduRdZQFRxY9FSvoUmDbdb2QAmAmSRaFlZelUh03V9fpKQPZmRy slN/DVAqJVWWc9ntcp/iUDOLkqbSZ8P5+o4akq9XaiJ3hCJEdWw2Ki4aRRKdw0gnUq+K5Ddq BlQvom4dc0Z1FdpZ3MDU4zSK44lKhACzFFpz2FZq1NmyREtuFCSdc6iKvTAC6JL/PFaTHlpW V+Z+N7bUgpBKq/RLOKRJbG2dbmXHIbTb7G1a0K3c0o0bI0Ld6mDdwsROmAVqT0dN5sTcS0sQ Zb0wXPUmVwUxtLhUIZnYsBejMU20eQu10uZMRWm0BFUF3TRGXZRriy0/2QRAF8hmLkJTkfzF md0pERXYJaLgfaHYCTnWMpJaCEOVInVRdQufzl3gOmTjgR0mCHDdlcHLjoFQnLjJhZKCYWtq ouZpGwVRGj7jZQPd+iHjwMFpmK1mVs6uFCUxPK4jI+IjPy5tQg7juYfZPwpU9EpUHe5Dm83V 6Y1HPgU1vuBroUEPj3fIEdhuEX6PqOcva6m0BrJW58VS/2+uUz8FMHgKHO602yfu2tvR5pZR AHMOHXZO3MXduD0OVo9EVzqeUzL01nPI6QklBaghCtf9uVm1qNvM3Wuoh9QMcC3Ub3v02+yL 6p0uMU7WNAqjUT22b3vqj42+LI7j1gRE6gVi6iXFup8FQTWt0zub6GteWI71KFJ+j1RNNvq4 Iefr6/Csn7hqirXacgCwNrN+Iqh1qhE8h56lQD/oHOfKvs0smdHuMJwx7f1SNmbK0vrOE5O0 7/7+7wAf8AI/8C6W1BlM0EohHAbv64NnFqCjFPn+vW5k7wbLlO2c0zXdexukpYax2ifhQRsC Ql39Wl9N8SgE8jf97jobmgEzv//N9Y4xjdf1SxP7IXgKbxdmB+4I3RKMPBM6n65d2vGHpz+s YXnf3Cr7w+it+umh+rgel0Vq1djdwRnT8Ug/5deNCrXpVU1S30EMFxrEDtt9dUS4LTFlP6GJ B+wzr9Q98TS4efPmqsBpyvAoccDEMfcs4TduP0gha0Nort5+D++h51fA3eO07V+9DVJJavUi tRKI5Cm1fUG+vR1qBulsjrGNr/RCeMMgjGA1qWAaXBJqFh+SuC85DLChLxcr7NMvIaikj2zk ErD/6h7+mZ8LsyYX+SG72bnM5/kYaSEfktpmUi8kHO4noUaLT+9PRDB3xS1sJMAT5eWXpHin LN9tJan/Nz4SEW8SuYTB7x3dbSX9ppQdSyVSAekqgEWTbiwvVfygCzVTdXgtH7tkETMyQfx1 Er8ekhtgClskGMpZACEkwS8FCez9koSggjp7DR3+EjSwoL1bkBpWMIjwoKSGGis2bGevisGD EzWaYPjxo72QDl0ejEjQ4EoT4F7e1Ngx4kuIJO0RGSjIlsWHO4tmjCmUqMuRN3EahenTXoCM CgAAkNqRo0ikCW6p67myAgACEq9eDeqT4FmsJdE6PcpVa8OmYcFGXBnXIdWeOrvKXXvWLACb cN2+zYkQQdONeRNvdZh3bkOgCB9vnGx5a8+cdLMabiiW7EDIlSX11XgZs8OR/o8pMHxKei5q jpclM36MoABJoJLhct68dTdoioUpEh1btu9Fs0ujuuxb063zhiY+x9ZL2eCi0ECyvmHLsG8l X0lJcob63C/cW95BY+wM/qz4neTxloWevrLR5fA3p+/pDep42ukXgXLDLaGxsFItMvwiW8q/ y1TTzKHdNJLPPYfkg8SNq5xbLqwISVspteDmylA2t4zLT0WPiDJxsgUNSlCrwABwb0bDgJst PaduMS5E8xzaD4EAYFOvI6sAgFEQI5Gs7joCpcLIwayqZOq82na6RZSdqPJrufXGdApLuN4A 5w0ka+yry52AesnMW5Tjzyg01STzuYV2NMo/rRbT/nJDSBokUqrlTKNttccSi0mSOWmU0jAw ozqUtAlPbAy/1oIz8jMeMZuwQMjsERDQzBIa7iYB+XRxy0gna2hS9Eh6lLOJksTVVqkYA01M Uh88kiLYDDR01P1IqgC/N/CbtcXshO1IoF4loSLQQvtT9kFKfiUpWHuwRPMhas8DsEBpTaAO tQNPtE4rV2YCh9CGliWJEoVmssiyc/PFtEJ7pEPIDZuIJU5VZneq8iPF4FyVQkkEPmjdudrL 6tOcGM53X3tegfdfa0+CzZQEOC7u3wEt3qoCFtG9Cc55D06rpL/ofY5lX/uiuaHhWP5tydEo mm+vqzTccOW7aH1QPgDE/vOZsBsJ8KVpmwIY+tWLlgrXIZSWe3RewUILWmgm41zqRqftJKBT npZ0b0KrBnX0KuUwfUnpqn7G8CpWauv3tCVhTIhqSKotWNWw12KWo1uuEoXvU41kslrV3iB6 cbJ8wdTyxr0GYG+g8X5btQUtshy/SSOTG3NYF7SJZ5dQcklppr9WzwQCbJE7AZvLJcl2g7I+ vXDhhye+eOOPRz7530ZVvnnnn4c+eumn54n56H2lXng4O8u+++fZ8j78DaEUv3zzz0ffeTy7 zzl9l7xd333556e/fvvvxz9//ffnv3///wdgAAU4QAIW0IAHRGAC5YcLBTbQgQ+EYAQlKD/u /imwgvu7YPky+LwNzq+D05pg/T7IvxoVT3b3G6H7Sli4FLLQetBTzAqd18LZWI9X4mqhDCF4 w4LF0FpOIYhxfEc/HRYsZ9uyHw3PV0QNvpCDCeGhB50oFyBOMUshvKLxmBgtSXTrQe5bEJMQ UgIc+WQsRCvU2soIkzagxQRlHOMaTxjHHNEKRJIgo3tO+K+rQGmM+DmjGT90kTXS0SBhhBsF 7PiSNy4tJ1SDIx7XSEgNBYY6eyxKG7HyRu9cigJngVt+NKm7QlqljqEJ5bcmCZ2/YaaR6kDk HzFnSEUpCJSpMWVGJIlGUoVtKlX74yFXGUg2unGSxKQlIl0CpOoU/2Zrkvjkh2gpypl4iTQl +GL5cDMRmqQkXT5KWL4UkJK2VEQmpALRgbhJOmcaap3QEchKWqKk3nmzma+z5zlXkiBmemyZ RGmHYvb0E4ngqzr2/JYufyOth4wTaPi6lKlWoyRy4utexynZv8DCEdj5JqH2YAHf5EnFc1pm Ig3DVIIuqrB3AlFaA63MrTpKlJmWpKIYrak+iRLFnFShi1zxIT0xmh/VmaEWMbkV+kqYk1S5 DJXVu1bfOuNUoGJqOKk61UtG4tGJNtUgWLWHV1Wj0qtKxTGnMYppJiNWURnmhg6LqAzhWpqv GsQ0uuGNodqKkNt87DT/aZVnbERXeWWpUv6d8WpY8+owvGpHNeG4TmvE8Ya6BrWWBFpMPSjx qfQttTY+Q2PXIOQQP9Vyqr8DJqZQkjVxTSZFqmxLaw8DR6jcqJMpDdRqWURIBjlqKWoFFWi9 AjjDrfKyG4mrljwkxr7lpUrWUZjfzhJa4gr0LZ5FbGBJ6lvSajd2VcsLcG07mEiearxjvY51 KAukX4hjIxKVV4CkcDQlRs+zOosUVQ8rVcB2bVOnIhx0TuRfn6xKtop1loWKNRk2jetMcDut asAqLwIL2Lx7heIPj2uZtMKLsu/dzTeqWENBwTc4jIpZT7W0X1iFRlMqOgBwEeySCfetsbJV 8Y/U0ZQC2EI8Gf7OaouIxVn0teu4sLOHyOqmrZXyy7xbCVe4hky3CpzsRFIWCMn6CSskK1ll +GyIyFRj5JxU+SZajlfgMiKx1XTZrr+75MAYGmR9GcRmHNUwY8NJpJ+CLMxZwdhG3lUyMp94 KwDTmD/fu2d5YdkgYJqy1kJm50k7TKN/HvN1fiGFQ/cZz0HODmddF761pLIzo3OK3dySOPO2 MlaR866RLbwawVWrdAsm7SB5WxhUUyh0h/7MrT1yFSg0anW61pz1ao3ry8jHc7hk7qzd9rN7 rgbVL0l2Y3I3nUW5uped28yvV63QiQptcDMhtrFzPTbeOvm4ve7X224y0K5B29TME/+TqAeE xRYTD6wI/HcPrchvgruw4AdXXn2L5kDWFqyR2UR4xOHycKtJ3OIXx3jGNb5xjnfc4x8HechF PnKSl9zkJ0d5yjWucOIRjHosP18HYQ5zjqeQ5hCk2m6Fd/Pu3ajiFeT5SwL+xOFt8XpTjJFW PfXXwhndgkuC+IF3NHAYQp3cSg8fkouu4fy1KepQ9d7QZ0h11lT86FN3q5RyaHYL7sTAOKF6 0Hfu9n2XPXxRJI7TPdhht1SylbLcCiRve2w9nmVlfRRwHnWJTbP4fZANGl00o72Wtu3yO0Gb piVx8neO9jGWeITaXxVfS4Xc8rOFtHyZHp/LYm4ykqOfY+r+scTV56CG9QhR5FNhC7fRB5Py SBklJ5Fl3NqrO/KmryHjVamhV04cmLcHvSClmXpKsl16OEOOQT+KS10qBDbiPTRCmTNalrAS zjIbv1gUOmYWqZTRLcWJOrVfpQvSX6QAJalJ/HZ+9P7p/dp/HRZ5v5syp5NKp4LCqH6StSnR E4Piq3b6lyB5p3P6KJYiQIuoKWfhEemwu8uiwJoaKbhgjP+7iW3SvgxMn8AojAjDMBvpMAnL q3lhEa6KMLo5FlCxql1ZMcKimxIMrETRwPvLokUBrP5DLh7stxmbKPAbrDQqOxhUQgYEGB5s rLLCMcdZQu1SjMSKiym8McHyQMj/8Crau6IadIr7mjGqMp8AIQrnGi4Sa4zf+kHhwhXYwjWC ygk3LBEsTI304KcRKawUsQ3i+qcaKr22wC4x1K4/7K74ggo3nKs0EkTVUoeGUyN2g0SOqsSB qa0TyUNAlCo6bChd4zAdzKrEoEMdEUEALC2s80BRRJ++2BMWw8EmdKy2isJLS7U7ChPAcixP 3Cs/XLEX7EGKeLFL6TdknBdIMDFbbJYcQy5iTMbakkbT6q9j7JsAAyLe+cWNIJx880RfxEMb E7ubQStTrD0szMVlTDv1kLEhzEERMpdD0r5Ayw1IO5BEczOPQrNZkzLI2DOCQqeIsTPkWBkt abLjWrhI/1uNQHsJe5SEQWOmQrNFRCvIKPE/ByzGbxFAjXwyGSQVOfMuM6uOb7oSj/yWCAmS cOwujLI0N0sw/zvIaLnIznCzfhw1MGS0F6LINps091kOekEcWmEcPlScdEMtcFs3DDQ81KE2 JSFFyBhKsAGAzfk2z9k1bjs9Viu3Vzs31cg2bCtKbQOdaEMub3O2cJs8q+DKDGKdcdsw6WK3 X/pKupG14KnDqcyJBWQdZYRLS9s9BpSttyy1q1THwLy1qfiMbcKbFyo1yNO1CJK75VG5B6K5 VJE7sZO4ydw4ius5sqvM/4E51oof5LHEjCvN0FTN1WTN1nTN14TN2JTN2aTN2v+0zdvEzdxU Oc4cnpsDOtDMnqCbOeDMnpx7CeOMOeIEIdAwTt6UOoGjzOUUH7w7Hr3Tu1WEO+hEnt+MxVER zsMEQwFbuyREHq2TtK0bO+VxOtjxl+sjzg0aIedsx+ehzjPkOuGpT+LwTXxTTvdsng6izvGc nijKT1dMuP6ER9DgFfnsSv10ovhE0O9CvNxQpt9rPVLyjhP6vHZzic8bver7tqWBLebCJtXZ veUSUe6JvQ/VvMSbJAuFiOA7JuKbvVBq0eU7D9a7RCd7JQ8NPVqiUOSDUepjpTVqJKI5UmEq PMTbUBxUPmKaNWQiUsGrBw8lviOthb+KUWNyj+Z7HcT/271pwlGoHBtlhNIb/U82g8YKFKcL fAhpqREO9EGh6qahosn8Uyg5fVMV4Qn5Gyr7W5v5c0CHWhyDQsHQcKaNuqi9RKiA7ND1467y M8Gz5D/cykiXhL+W3KfFrCc7Jcjtmg2ZEr+5yKmWgilIodMBqQstJdRygoQQ1L2QkFOdOqg/ hVQSy0BAhZ7/Wo0VYsJyawqykhI05ELB8qwvNCwn4tU+vLpTRELSK1b8GkcgFCu6CsI4TNAj 7EUG28GoSkZrJVCSiNZg9auuikFxuTEmrBRQbdBV9ZfH4CrJwCooxMMWxMF0TbEIldDB69VF Yg5Le60EwZ4OnLaq+Tb3wK70/5jEukmtiSHEK7TT0uq26coK6OKXPZwt73DDQrxXHUlEBTNC vgLFftvYcM3YpETYckVFihVP4RrENELDMtRSG1PFdYuZUxQujL2U8cJY5SEwIMSNaoTXF9uu gQVDenUxVE1Yn/jZUWlaOOROUBFaTtFMIPmwdxUOvTpXZy2xj6UUXBTYqRVMODHZKKywoL1V aa0iZPVLsi1XrNMMwBxIVRmUTlwrZnOVe60x8iQeRyMYnpG1nTwViPlbhPwyp+hJRv0zR1M0 CjUOvx0VyJ0Mh4RYNo1LXVSyh/Q0BHBImHRUSeQXiWwdv9pLkTQZjFw0lKw/7StbN2NcMtMY m/zJ1v9yM9XARzt7W5nFWnfpGIfox8M9sp+0x9jVxD8TyLdLnmUzTKgUp8Z8HOV9zJS5it2K 3mNjN+gVN2ubXrqUHOZZNrAcS2lTy7bElGtjpBU8yqoESFJky2AbS77atuo9y8hMS+aFNvLd PGor28Dk3ruxiPrlHvOVkcfLHKTUyiR0V6arpcR0ygfpSypDtvAFYOnFxPDVzQu+YAbF4A3m YALyzA4G4RAW4REm4RI24RNG4RRW4RVm4RJGzv/U1+j0z+dsuRgGO741OFKz4ZXbYbSTTvHs YQAyTxieHoVTGp1rsf0UniOW4QbtzQftYe5hOctSoaXDzqa7z6NrxueMWwX/JrgCreEiJs6c ydwbduKdIzsy1jTv1FcNnjX6tD7iiAfiAeMsKpjrTB4qNmMcCmL/SdIhVT6teFLUA9E98lIo FZfRq9Hj9BToO4x8EQQZzVDMAz0TDQAkjpVGJmTN21LXm+QJreTAY5GTAFOdkOQEiL1YSTMx FbxikTymFNENCZtD1jUpVWRQAuJbXj0aNb0PHVNR4tIfhCbkS2TU6+K+WzziK6ARHNSKEVWX LF7JIJaROlT0WxUF1Np508hF/Sw3pcmSUhDyiUlN5RdutqmHstMh0z/vqx5YPedCTed1YWeT mr/vKxaJcuc9pWajwVTWXTpapSLLdUWArmaCuMDk/0piAzxCzUhIgEagVfXWG65WfM0Sed1a RdkJKyS/5OBTRLFXQllWaBJnjuXoGkwUua0qrXgNuKPBvknWldZWqb1oyyJDz7BoGlssS62e kLXWbGWqmeYvQ5SrIpzZ9vzVh2ZFPsUxl5VLOTLYGRmvN96ZTRRMEWnESE26ZmvYFemVOnnD f8Vqo0SRrV4LnbOu2KIzjhBEq0Dfl9UOAZMoO2TYNYLq2mJqboU7I9xYnz49g63c3bWsgJk+ kC3qSE2owiKguqhGqb5nsKqwZURWaRMVbdwLcrlZRGHJBcbGP8FLRg4TYlTGoYWUe6wYyEBe h2latQHsnv4THkLex0YnX//Z237Na51eV75W2+w0LQzb4sxolC6mRTe+O2RByTeu3eJNMlQW SZyc3cmQU5Jcsr/YSc6t1MEVSdvo0gGhGVncZoi0boLE7mIRXfHVCsKVGIrZXcX8VNoliX5c yCzrGODFXO1aQGcENnK+icQNP+P969Mg3sZl43sCbgVR3T5Wqhx1XjOGNw7tXwYW4Ed+HSnZ I71M381hrO/FFMrRnX2b8PbFjGy7cFibHKKB36eMS8ipy3kBgiwFXwAotgUrNQY2N1vbNtji NQLODHnj4xwvUw9Xo3tbSrDTaqW0Nyl2tQH/y40MYc1sYTRu8ifvW0yGctD44Cm38ivH8izX 8i3/5/IuHyBN8PIwF/Mx9zj49OLPfGPieGEHJXP8EW6i82Ht3EwofvNya6EhZvMDx+EwntMl YrsANXA73k7+vB+noyEpRtA6ph8zr3NEx2I+9/NIl/Q7juNdrXTdJqEspuEmTh5FT8Ejhz7B BuVAzigOZE/oK9G+PhnWS1KIBTzYo2RfNuVgRuYRtVFUJz4gpWBIeOVLGWReAtFkwuUxHSMg kABQQtEfA9JIpnVil71h55wUpT40daVS3ojei75fpuXK02Xmyj1PhTbHqzxV1gxfbuUOxWUL rR9d3cnOUOfSpoufagoSFKhmTb+dgvfgqorz21OHpih0roiE3K6GzlRr/+bR9lPZZ/aoUvXn 82QpkuChKaNVgwZ4DMynlqrPd7fVrhRZkDC/gfxAe6Lmi2/4xoBAdA3I6Z7F/ftTezbQzwVK e53WUeFVpWuvD7uQZy1FjgfXfM9qcfSMy0CG/j6totV5Qv9FZL2v7HprnO5G2lZbGQvX1X6c asXrtAsVe+94TJexMXQOq4f6LawrII7ocYRpwOa7bBXI+cHYTMyb8spvVPaKeHGvTNSKniW/ j4r4zGb6heX5UylZLbH7v/9FX1l6tfRrMoV7aDwvyOCVSQztE7trqJ9rfn2Rbz3EOxSvVESL xr96kLHErU8oSGRr+7ZTNWSMvaYgYMxpvtrsm/74Ch7zMXdsFUeMwYj/6Gsc7WKEK74L25z+ 1l40fMuuxdy+idle09mmoqaN/D9B/q2Ioqct/qidW9/m06Erlec/Wr6h7GhcLGJUbQVOurUn 2LSfH4ds94e5bsfktOr4KcvNDcrF74C+0ztzbpuQXMKn0BM03AIHu38ECAQVwNkraM9EgoK/ hCQ0AcneL0kGTagraCqhwYMV7V2MqFDiQYwaLSbwWBBhwTcEF5aUZNLjS5AeKZKMeVKkQZUQ Gdq0RyThm4cZI7pKeIugQZM6TY7kmOCVUYI0nfZECRFkBaFDJQk0KrSC16v2bgFp2TNAQpYZ QxoEO1br2rhy59Kde/4LAABRMhUAIJDWJdcAACBRaTm3wsZbfiVA5OtXrNi7eUEOdYyxCs6U eFlJfMl3sEHBhA1DTirzdOO+GH/xhQTTMmSmCj8LNVkB78rW9t5s7kzZ3m3QcYM/7MlaOPHS xyEhEF04ok3jWPEWR50arj3npE1K1rs2ouTHSWl/zJg8PMbkxlubtLo1tfjjj5UCqQW4/Fi8 UARlXg4/c10BCjgggQUaeCCCCSq4oICyMfgghBFKOKFcDlIYYAEAXhiXhRt6+CGIIYqIYIcj mngiiqWlqNOJJuAlXooxyjgjjTXaeCOOFH6TI489+vgjkEEKOSSRRRp5JJJJKrkkk006+f4k lFFKOSWVawm20m8EYnbhlRGWKOGXC4b53odjknmgmVGmqWKRaxYkGQAAbllghqG9CCBN0GXZ 4J4PTuVlnw/O6WaBYQ4aKKAIHDoXTHvOuVWai0LY4aOAEkiokmqplVGldbkYHzspYWfPo5ge dWGnDGI6oKQUGroaopNylSqHiNLK5ly3bqhrgmuuug2CvOG1EXDUFSQYaNEBVsJjt5W1lmLp 4RRcsnw9K1ed3/GXkYsA1AfYL4K0gVcCLj7b7UYoufVWQc4ChRcAFUXErEjdlnXcs/PCqG9C 7kLmr7DxnjRsu95mRq1rkpRgcDz84vsXftnhda/CBq+F8LwWF/58bVLikmvudr5RAG/C35E3 07AYK0yALy7Js3C+pwlE8msWZ8zxRzBDXOxgI1OnLL3F4jybsRu/S/CqqjJ0EFLtQqwsaxjR dMuoWbG71qNuUT1XthkFFdeWerJW0V1ebW1POwXVeSpbU8PFUtRgS8tu3JVJTXZ1I52tEENn p+223LOFVbfWef+70U9x723QoAqEpTd2Y+fnlbKKwnrx05L4Tepqjl8V99c9HdoV3Z4v3hhQ eZvQNOf4vXb31ebtDHhSPMXq4ZZdh5t5eXoalO1Pa70BBV9yXl5Q8HF1HZrxn98Xm+ZwsW1P ndVjlHxBmFG6s0+knQl8SwiAz2kCi/6PT77rvkWcOGq7Ix9y4NCrfT1O0lXeKkTbNrq4pL7n D3/rnGcQ9kVsfeFbXv/UN7/3DUV/IDlf9rwnImHda1tvqo0CG+UZeOFsb2jBGkb2tq61LC87 xEKf2KwTkZnFaTfEoshSPmMxCkqQcY8DTg1jI0OKHWdiR3tWcEqyw8wkEDIihN/eCIirIvZQ Y+n7yP1g5QbqnK1RLExIApmSIdHB6og9Mc0AzWLBCD5xgz7MSBU7M8Td+DBpCIoW59ynEAf+ Tyz+o56GdtO0P5Gxjt3DFk4+KJewgUuFlAmK5UxTmAUaBI7a61PYLKjE79WPK8tzpEgQWUL0 ye8lkiwJHf6ZokQLFRGPjDKk+6yIP2XlhDlZlAl/UgmSQ8lxlFnypBhxMqhQUmaTTzRlIx/z SBMtZWkDycgHt6YWhwjwJBu5yFCWlp3MuKdwXBOJIAf5F//FpChjAYeDrOZMkhQzhwG0poWY MpWOSGSdCSgnVL7ZFGhy63iNasvglsbMae4EgPX8pTvJFJNlqu54YdxNdbx5KqsMFCSr6+dB hMJQrqDTOmDU41UEwjqG6tNw88xM8L720XK6EUHaKRgACCIZKIBEWJxpJkpHBScA+Uc+eIIX 2eBFLhA6TzroucUJ2dKWomlne0Sbz55ko57pCEc76Ikph9jTPsrYVDMAeGl+AP6wH3+OZzBf TI5AUeNS9S3HQd3xzVPLepoeamWsRCtZVb9INOHYBjfXYeNVFQhVaOHFO3st6u1kVFIpuYeR VYrRYA/rocQqtlCBbezvcMIiyIqoWzCirI0Yi9nNcrazUrKCZ0Mr2tGStrSmPW2NjtAjA6C2 ta59LWxjK9vZ0ra2tr0tbnOrW9LOIkDn2C1wgyvc4RK3uMY9LpMsgdzlMre5zn0udKMr3elS t7rWvS52s6vd7XKXLsvoLnjDK97xkre85j0vetOr3vWyt73ufS984yvf+dK3vva9L37zq9/9 8re//v0vgP8bhQATuMAGPjCCE6zgBTO4wQ5+MIQjLP/hCVO4wha+MIYzrOENc7jDHv7wgzRL ot+UNLEijtEbLiujAAQVxDISJ660lMeAse5MMb5UoJ5KlzWlyo06LtQYaZyanfoxKz/u4Xws KE7suRixUpCmG2mVYozQ8zskfuwpdzzGLLMqjwYBloHkaKA/Tbkm+lOAvLb1UD/OMXV1XDNG myyjN6hjKjfrnM1kpg6SWYmm1nrayTwWJ5AFTF4ra9mxary7O8/VcO1JGc0OPZ1roUvLLdHZ UIVz0GP1x4LR2p1I2VzHRfMn1Avcp5xHNEzUIdRpdLNOj7fsamVSFNA5vSHcPLdCxHAolqb7 Cu8iI5S0NQ5igNsco3z9ODj+n0nMbQ5juGzxti2nMpaCkHbgUJ1qEJmEkG0WJQBTdbbb+AXc 0OHlLyMYEwq0+H/RQbewORkT8dHvdBWKpXV8Ob1xq0bMYPFPx+qn5txoeiJe3vaFAiYwLZZP K/+GNU0tuDsvRq93hsQrxYhW42+jJo3y4xkW7emSNQbR0u/W0PTkSGqRJE4QzSGWs9k6x5ev pbAIB9GicFlLUO6MVoJc+fu4mcHTYHLe2Qw4K+1Ix1YmEnr0louptQU/Z1+U09/2dLmV/eyA N1CIujz4zS0FbYciBZ0dvQnUk9yvwXElpI4+jRtWYrvykKXTAHQ7RJkZz4WK/KN7l8qoFm2d Y8r/BXtlBnrc3Hd4NReH2tsq86lHFfYITVYjMj8qRtx6V+HhFPOR6evQP9KcwTzHOm/gWHgQ bUTQW/WlaZUqfs5zJ36i8UWqZ0pwaszHQg+5hX40AQFscSdmxtyCwAcKUrQ9eQKfWNQ0YvLy D0znhKs4RiyOPvazv18+aL/73v8++MN/I9mUGMs7Nv92NbuqLpk0pSJi/3iFXKEriynHsz+/ jGsVZvS7iv99PBCv4F+A0Ar+DAgfjVm7dRmBHGB4QV6V2Vj5WVqA8BjYUVYA5koFzp+AEKBB 5V+CXCAGeiB5HR3RxMyQNd64DJrB8J6+qF4AKBq+YdoJfhy6qAyzqJ6//xwEwYBRpZkGpvGL 0PwFprGgpDHasZxRplWLE00EpFHHFCFNxVzL5eVE5yGMeUSaDAZhzbXRn11F0PiLvdgHvTyM F1qMFVaGxdhLBlIX1eHQq5HOa9xa7OTaXwhEiy3ar7naPcUb2gRQ4rUT3lxN2pgGsglOq9UN 4IDO2/CEro3c4/DaH3GSG57O5nQKHV6NW5SIWnCgIZ4N7XASOnkO5JAR4QxOHgYQ5lwNCFoX v5UbZbCPLH2cbKxaRLDbvU0dvHkE/4jc03WPvV3FL5pbL9EPuJFPQ/XOJ/FUaTDZLsrNyd1Y 63Dix0EQKb6i94yPty1juNGUNaKieKkcf1Ccx/9JB8ZtB19snLt1HAZ9XMllEckRmeiVXNWN 0hAVIw0dIx9Gog1dED5dzE49yj2qYwFZ1bNIY3SsEfpQ3FxZTDYqJGSIm8OFnHn9nLUR4/Ps YUwUncyQYDpaHDJyD0I13bz5kqkxRUnC0jVWUptpJBRN1abtox9Bn6g0HUvakUW9iTBJZPz0 hC+R4icxHE/hUtBBXK/RjzeK1+Kt3RvinXTEXT/ZRN1JXU8w5dn9nVDZhDtZpWkoFOsoBZZM xDORhk6Q1FpZxwdtisH14+lYpVWQJX7gndfIXUNoyEThR0CBItuBJUm0Du7lJWTY3KwJxSpe F+/9x+dNhiwGBukB0On/iUTqWcdZtZ5EvN5gHMDgGcuPAeP9NVoBqQd5HOFo4CN36Ies1RRs 1J5qXMfohSZksp6VLObmdVXJlAZYyRtsKFXRZKNhrkfBGeZRBpgwjBahNF/ziZ+BDaf/yYVl raFxNqdzPid0Rqd0Tid1wldxCtd12glBwN+PZGeEcGddeCdyFeAEShy+ledqyFppmclg6mVT hGdy9gr9AQkDwid7kWd4mmcGgiNzUhZ79mcftadgxaeItKd4GpcNOlEOcl06GiGDplIXOugV KmHMyCC6vFsKlovG+AsQzlGGElrntSBIvKDR8ExvouG5TIwEnBGHFmEUYhMSWpXAoFHyJZ86 /9SMpi1ozhBACi7ci9rJhi5hCTZEjAINy/woEWahdRXb1Xzi1gmeIkrds4Wim9Uc61Apu/jN Qcrh1iSiKI4Hl2rFJe5augTib6bi2czJnHjpNp0iJMokRF1UFUhCyO3a7JjpeNQPIz4i4jQE nqqlYPZH++ia55TknsbOkvYdMDFZE/Xb8+hj7znq2L2kYQkj3YmpSzod+KTTxdnQuhELNh5c MaopRmxqWX4kA2kTCP2COLxBQmyRSywdNZISLhrlrHajJWaqUHrqTVYXEyHkk+JbMT5oOEbk sG5d7Dxc7JFL0g1UPSbVxQWkxi1kQR7cEQVQ2DxrS14qpZZjzb1T+f+AkzgA4zo2Ec6YZBsJ ZNABa7Lq5EVh5DCWo1z5qqL2JH9yk+OlJ88NJbKy2c7JVVDEonT04kAmZk2ukCCVEK/sHLaW qko20x5CKiZBizrkji0YGk/mEXfkZNL9kb0moyXmIkoeLIEKV13+ZVh2Hcd5pZTWUUWlxMYR XmDKz98RVGJ+FKemj1PCTcedS8q6h/JNYqD2kTuJ5oimhTTBbJwmhRQ4FJ1mFFzeJX64JWSc pT6lrOyoYn+cXVUQBNUeaGypVcTUZrCaxWeq7Kjd5tn6o/vFVcfNnluRI8941Ltu5GL2RGPO 7Vs1h5+lZsNm2tv1xErJ2kldTGIgVVb5ld7/nglg4cfgpkfRoKF4pErc7kXkNi40yhdjge2T cK4AZkrJgtjmhi5mTV+MLGeSoG51ri7rKtYvtC7sxq7szi7tSpfnZq6LreKteKeATmDJjglr 7FH16d+ANJHkqWqIyVDCmJgMbWbV2aeNRZjuAmiE9O74CcHTZsfwiol6DiD1FqWVgUn3FmxG HMOEtSimnSH6AsGKOmGILovNCJqGXgv6miGfccsOrq8EhNBsglUO9mBLKmn+tIFRiMJ5/uWw 1NWJ9qsW8p7KWNwXCqmYiY38gowOzqgEDpUJauG6UA3KxEvNVKiQzhebaq1eKpMoWqLtKE5x oNnksEsJpymAbE4M/9voTGxUIBbi55xixyCaGdTCAevisN0wenLLn25i3yHin/oruLhw2byF Dt/iCatODttwxaGNnZbODdWXqeLHo3Tx//Fqs8oMGHfbDMMFGJsS+xDsojbc/M1ruChKPVCC 4HGr6PVkV9kVNW4JE8UrpDYROBVS+vyiFDPSGo9PnbDP3tyRLd2XuW4jtXoPQKbrGEORtj6k hgTRI6uTG5+bSDwyyEFKr4KaFNxoEDNVLhVxJHtrH5svKDNoTxnSFanyJo8cB80lrV0ReBhr r87X8nBRZJ3JnGhkJWfULxPlXGjSw36Tq37OlpHk21zkLcUST1SkigRsrIKds11STvohvP8B E/i2pNy2Wn6KxDGzMTNzDzb/ay/LV9FaB9CGJScrLc8W80zIMzwDCFvic0YQwdPuGg6ThFZu K5tMMDU3xEPULEVtVORsmTuV01VyLWVILRML3UdwZUQlW73w8136819wZRbTml0eb3stlevo ht4yxXKsZunZM1O93VuhpniY9EQghQKXHWY6r0WjbR25FXrcNO3B8l/Bpn9U7oQ29CcLMvQ8 FUf2K03X5pqBx53UDOJW7ffWLpTcLopotYJwNVbniOlWSVgLyVh/tVmfNVqntVqvNVtz16pY L5iQbltDFn9SiKlRBPnxH4763l3fqAxd9fM2hvDO8PZWSPOiowj/zvVi6aerjJFMmspKnFma sdy+Sk79fQf2YkQAFDaQAbYkKvaG1DUZhsuHBunQuOGrzWCJpgbHoIQcwVEHN14IXVaSaswU emgBlxpO3cV8ROjKfPKWxXaJMpoVAjBoqwpjh2KYjqLwIMX0ZXF7mKk1LZCYhZRzT3a38o3X YSJI5o8PA/EnV7NSorDd0eg4xfDQCuJxT0rzuuKkaqpRqiwhpVI5GLL3BA/b+FtabEskicQI rWr7LF3HyDEdb5n2HHD3pFPzvmpCBE8ZzxL/rrf46qtDOustD0fIjOMQXavpVre07Cqkyqu6 Oggpm/IP8ZxD8vRNoPAtAzNKebaE3+tPsMoyHutRh0uzYcWkTr62eKhEh2MdTpDsxyGdeBed NSd4UsnaUTQzOH9cp0SdhKNJcvslVmLtViwS1FZpQL3ss9XNVWA5hGbG14IEXMIyqMml+3C5 iiNP9r6zXWLEQEc5iTC22/4S2ZoHpiYuZYBVVQFVHvteW4jpX8sF5o4mYvK0+xTVmaWmgutU jR61LLZGZso5ZwGmkhAypWNXjRMJa5x2pn86qIe6qIdXEYx6hAQEADs= ------=_NextPart_000_000F_01C6ACEA.95CB2100-- From fhubeiimdxz@adaptivesolutions.com Sun Jul 23 08:20:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4cwE-0006Yd-Ua for capwap-archive@ietf.org; Sun, 23 Jul 2006 08:20:02 -0400 Received: from vb93.internetdsl.tpnet.pl ([80.55.157.93]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G4cw9-00023C-O1 for capwap-archive@ietf.org; Sun, 23 Jul 2006 08:20:02 -0400 Message-ID: <000b01c6ae52$4c781fd0$5d9d3750@goryg0pvdknw8p> From: "send" To: capwap-archive@ietf.org Subject: portions Date: Sun, 23 Jul 2006 14:19:52 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C6AE63.1000EFD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2873 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2873 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b ------=_NextPart_000_0007_01C6AE63.1000EFD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C6AE63.1000EFD0" ------=_NextPart_001_0008_01C6AE63.1000EFD0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable And France Germany India Italy Gaster SopkoPR Manager Alabama Alaska teachers. educators must raquo church uncovers For Gallery Press Room NewsQuick Kit Home Releases As Effective vehicles jointly website. April since. like special damages CARTOON GALLERY Blissful councils tries OPINION POLL Should register sign Alan Brown. Im retired critical Districts engage effective improve learning raquo church alternate peaks LARNACA: Ships scooped address site.To station Exodus Lebanon Free PayPal Buyer Columns Security Center CMD hard drives see NEW means new guy who runs evidence recent MetLife grownups readmy privacy policy.If means new guy readily informed ------=_NextPart_001_0008_01C6AE63.1000EFD0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
    3D""=20
    And
    France Germany India Italy
    Gaster SopkoPR Manager Alabama Alaska
    teachers. educators must
    raquo church uncovers
    For
    Gallery Press Room NewsQuick Kit Home Releases As
    Effective vehicles jointly
    website.
    April since.
    like
    special
    damages CARTOON GALLERY Blissful
    councils
    tries
    OPINION POLL Should
    register sign
    Alan Brown. Im retired
    critical Districts engage effective improve learning
    raquo church
    alternate
    peaks LARNACA: Ships scooped
    address site.To
    station Exodus Lebanon
    Free PayPal Buyer Columns
    Security Center
    CMD hard drives
    see NEW means new guy who runs
    evidence recent MetLife
    grownups readmy privacy policy.If
    means new guy
    readily informed
    ------=_NextPart_001_0008_01C6AE63.1000EFD0-- ------=_NextPart_000_0007_01C6AE63.1000EFD0 Content-Type: image/gif; name="On.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c6ae52$4c781fd0$5d9d3750@goryg0pvdknw8p> R0lGODdh1gG2AYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAA1gG2AQcI/gABCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHgvZCihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jTql3Ltq3b t3Djyp1Lt67du3jz6k07oK/JvgOMAhbsdy9NwIHdIjaMFXFhloNLRiY6OaXjxy8rz9T8FzPP y4k/a748EnRokaMHgz5pOnRqv4sZT219GiVne7d/5ia5OuZul79DBq/ZW/Rp2sJbl8Ycuzhv 5biZTx4um7D02qw9J8cOlPr2w9p9/odX6l388cqR0U9/HBv1+O/uYbN/XR3qbdeOl+PP/735 +vb9ybcfd9GdFxiABbb3n36FraaagAzWxl9L6h3IGWmdGfgXfPF1mKBk7xX4nIWJIShifU0F Z5qHK25HW4PFOQjjexVimKCC8w34YH4ylhijjSvVOGGLI+6n0oUzfggigRwGSCJ3JqJonWXp 5ajkfy+WqF98i1XJ5Iku8uefkfCh12SPHO5YGnDX2WjmkltSiZ2XYI4op51qZvellEFhCSGL f4K5YJMe1imiitcBSqagM86Z6JYVKglTpGWGWCijY8J543i/UeqcnXwm5SeJceaJaaGjLhrm nnUOOuip/5uqSh9ynx756InUUbopobjWamiRGBIJaqhHIUmqorAm6+WQnvkaZ5pJQrtob7o6 SS2QtmpYKautakcnqMtqqueEvYZXHrE6zfqoqa8u2G6zAn6p67fKekuvoabaVt680WY77LbD vnqpuOLeZym6PQH4baaZStvhuxL2m+Gz4WIabKm3Arymtr9eCvGaBEtaLoOo0lcyk1iGjPBQ yMVKJpEfQ4evlUs2bDGO1zLbJbw+9ojzuPSmCuVrOTtX46o9D/ysyFGuLBS2QLpLM6w7q2px zUEnerSfwM5sINdKI+1whAQarHCtRMc69sQk8+r023C7l+LBfNEd990o2t2d3v5knYv333r5 nbDgXzUN+OGy8b234l4ZjrApiEcu+eSUV2755ZhnrvnmnHfu+eeghy766KSXbvrpqKeu+uqs t47WE67HLvvstNdu++2456777rz37vvvwAcv/PDEF2/88cgnr/zyzDfv/PPQRy/99NRXb/31 2Gdv+hbad+/99+CHL/745Jdv/vnorxzA+uzbs/5I77MfQEjyz19S/fTj777++7e/v0jvg5// +AdA/AXwf/WbXwILKL//kSR+BrRfAfP3QAlCEH79818GIdhACnrwgw6cIAUXuMD0weSAB3Rg AFMoQRBa8IUCDKH7VNhCEbKwgjj8IAphKMP+CVCBNf5MIQ1ziEAUhnCFQeThDhnIQxEWkYhC NKFKlmhD+90whgB0IguBiMELmgSJGMRiDLeoRSsmEYledKIHhbhEDXJxgmxUYhM72MM2JlGM UpxiE4fYQyJCsYVpZCJKwDjIGubvjjo04wM3+EQ8HtKQbVShDAN5RBhSkZBlrCMgDZnHL76w hDvU4A/J6MI3/jAloYxiCX0oxlWS8JAjjOD9RJnIGSJwkkBs4Cobycc4wlGWauRTNvBGxTVy Moqt3CMlM1hIT/qRgX/E5SLp98tngjCTijQlL2OJw0sqMpmadGQnnVnKNTpyk5msZhaXac5g qlKb3nSnM305S3LeEpZkpP9nHD8JTGwi8prjrGc5JSnPdErzhpjEIjrPOceGXvOY2uyjRCOJ TzlGE5rlpOc2KxlQPaqRg2ak5SMXOlJ+flOTaHynLh2aUQPOM4J0RCYjbRnLmPazksrM5QA7 SEICdvSnQA1q9r4h1KIa9ahITapSl8rUy0ECb089SlSb6pSphsSqOMHqSLTKkqlqlastgYRY wVoTsqrEqyUx602+SlWkYFWtMHkqWOFqErrGxK49GUJK0CrVtLa1r1u1h1WjOlaxXnWsJ5Hr VgsrWJEQFrGNlStiH6tYyXqVsYFNq2EFO9nNWtaxnj3sZDn71dFClrIk4WtjSXvZ0F71tX8t ylv+V/vawdL2to6lrW3RulvVKja3m41sZnOLkt/qlrPEBe5tJZvc5Aa3sol17nKnS9jmxjYo hR2tcrcL2+FWl7i/3a13qRtY2w63rset7XmFK17rple9ZIXud9WrXPNeVyizbW9ts+tX2Jo3 vPy172PpS2DccpWxvp0ua4XLXdy+l8HBLS+EA0zh1N53KPmVcIPritn/rpat0q2vhrtL4u4a l7cjhm6DQUxe98q3xA42roMvzJMMH1a3Mp5tihO84uaqmMARLjGKTdxi9oJWwePtcX8fnOMP 01i2Fibthw1LWRb7l8o+Pm1qKxva/2JZs57V7nH5K1oA/3jGX4ZvkEP+XGbQutbJT54KXq0y 55XUGcZxjhtmwbLnnOC1z3lOnjQCTehCG/rQiE609e4clVOcldHRVbRsyBzXmRwY0D+Z613X jOfiQnbBbXazpKtiX5dA+sBujfRdVW3nETPYv6O+inirLOr0dri8n4bxrWkd6k93NsgI1rKm Z+3e6Or31bGmSm9JbOP5ItvZ1l12kf2q4/5KG73E7jS1XW1ZTid7KWRWrYFffWxol7nJ4pax hasd5WNve7vqLi6zpw3pb9d4xx3u7HmbjOYoAznAYB5wp50db247Ga7PNXipJbcG5emXxT8u N57ZfeIlExm8kXb3ujVc8PVKfOH2VsrDUwz/54ebe9zcdXe6Bz5vs5644i62OLrXG/KkhHux zxUzr6V8WX+7meC+Pu2vF7vkW4NZ1DDXdbiDnnNv1xx6IH86UKMu9apb/epYz7rWt871rnv9 62APu9jHTvaym/3saE+72tfO9ra7/e1i+QPcTxKEudv97njPu973/pRkMGYMfP/7GAYPeKEM 3iSEJzziC28Txock8YcvSeJFAvnAdyXy9sD8TzRP+cJzXieT97zjJS950Vt+K5/H/OFXn3nA M17xrW+96GHf+dqzXvW4f/3oWZ/5x4+eJL/H/em1knrdy971io/86pVv+tLbPvnIf3zsp895 3nee9teHvfCHj5Xi/j+/9r6nvvGnD/zmC1/zy0/J5BfvfPGDn/tV8X74t3/89Ief/COBfPNj j/7Kqx/773d//Dd+8Bd/jhd980eA1Td+n4d/Amh/AsgSCJh/u2d89FeAU3F+FqiAr0d+zMd+ 5fd9vad6EXh7nvd+9veBDoiBUuF/+ueBFQiBuReCNCh+ubd/2Td7tMd8O7h+LMg6v/eDxhOE QliERniESJiESpg8DZg6RLiEvqd9T6gSDfiCoOd/NegSVniFLRGE/QeAUXiDU4gujfA7GjgT TbiCN6GCXNgTaZh9vXd8lBeA96eCbyh23od962eCYOiAUjiC+geAZziBPUiEC2h6uleI/2GI g/wnfXRIh2cYgWhXfIhofn94Etu3fCnIiBqYfsrnfu3niJpIiAjIhn7oeiAYig9IioHmD0dh hZFoimkYiwzIiZYoggmIiV7Iirl4gYtXhbsYijI4hmU3jDCIf7OYiNAHfqZYf/sHgc6YivV3 jAm4h8QohxRYesG3gY+4dsYYiZKYjZKYibYojBOohuLofvQHjeGIichYgbqIi3cYdrUogrL4 hOtIjc0ofwMofSRojrKnjzJYggeIigt4fc5nh4w4idaIgpeIkKooh+Q4jtvIjIUYjDn4jj64 kc04jYuIfC6og8p4jUjFCM5DkiuBklA4OVjYeCv5kjAZkzIpk//NMJOAM482iRZb6BXJ2I0y gYU42XgtaYQdiXr4qJJdWI+Gt5A/eIF6eIMfGXqBOIMDWJCKOI1QWZWQuI3LqIzVSIGCyI25 GJB7x4N1WIqgqJBpWYogOZbUd5b2OHtwmY7pKJVnWYlbKY9sGXhbuIniqJb9qI576ZYHeYyA iY7RuIoWqZi+CIvcGJTe+IyV139xOZYf+ILgyINs+I0ESIWS6ZCG2ZmhaZGQGZmKSZe0aJl4 WZeseJic6ZPtt45iGZinqJdhaHn/6IFvCZiXeYskSIvRN3g+wJi3OJdzeJoCSZxRSIObKZd8 WZBwiI3YqJauuYx3KYWKmJUTWX5PeY7/01mLPviROSiaObk5SBmR5TkTVcAnQ/mT55me8Bmf 8jmf9Nl1pXl59wkVd5iffNmIHvmf7fmLwOeGxVkT/OmLsNmOEmiI79lJ5aCf2reYa0l6YHmA PsGPNHGg17ifDdqE/Hl1oZeQs1l9IZibIoqI0WmXQ6mJFbqIEMmiWJmI4fiH3YmiK8qRNjqV DfpkwNiaogmPn4gS1mmXyamGQ/qZcHmJmeiWdUiWfvmd8ZikR6qgT9eQhCmSmumPYFidp1mU vMmBoBimB1mYyhmm6Jiac/mhifaa40iFtFmmReqlFmgHEhqN22mD7OikI3qOHjqSvFiUIOqj kKh+TDqaXVqg/6xZpLVpnH7Zo4b6pn2al2m6o4SmlId5nIgXnX+JpNsJjJMKmlpap54IjQX6 pJSZir9pqZSaZ32Jo5D5hdr4kLfJqIdYo2AJh7LJltZ5q9QIpbzKnbiqqi+ppi9BrPVZF8aa lMe6rMzarM76rNAardJ6PNgwrdZ6rdiarVKRDtrard76reAaruI6rs3TDuR6ruiaruq6rqPD Dz7hrjPJD/IKr/Ywr/MqEvZar/bqrvI6Evy6r/QaEgFbr/h6rwILsCTRr/iqr/kasA57sArr EgObEwMbsfpKsP4KsfAKsBVrsAzrsRirsRObsQl7rxxbsiT7sQu7sgJLPfS6sSZRsf8lYbEP G7MJ27Isi7Mz+7ATW7Mt67MsMbI30bH+yq83C7RC+7I6e7Q5m7Qh+7Qpi7IrW7NI67JTO7NY y7RL67QZ27NR27ULO7IwC7NQq7X5irFny7AFu7Eeu69mS7AyK7Rlq7Nki7VK+7U/m7M3a7NK 67Vo+7dWi7N+i7dGu7UnEbdZu7Rgm7dZW7h1G7OPa7RAC7dRW7iK67iUu7g2u7mAa7d6K7Yh K7dO27eNy7hyiyK/kBZpi7A967ZkO7lr27CJO7eA+69nO7Z0C7J0C7aTa7lP67uIS7kyq7J4 q7Gxq7B3O7wp+7h7W7qZS7K4S7vNU7eDq7eh+7uHq7WVm73/eQu6pDu7oeu6H4u8Bku+svu5 B8u41gu7gmu91wu1g8u8xXu9vtu+3zs9yQu+ZXu/tBu828u5knu4L5u01bC8ntu8PDu7w4u8 8KvA3Nu5RVu+zXu8iju/pBu/A2w9+Qu+1UuzD9y+6Mu5F8u1LNu7Tfu8z5vAYVuwEwzCEMy+ 71u9KCzD8lvBWxu5X3u6zMOzbmu8rFu0FozAutu/QIywlxvBHSzBxKuybdvE9YvBDqu7JAy3 4tu1aZvDsRvELGy8WMyuS8ixYBzGYjzGZFzGZnzGaJzGarzGbNzGbvzGcDzGXjzHdFzHdnzH ogMAN6HHMMHHSuHHIgHIfYwTgiwW/4WMFId8EodMECPByIrcyIDsx45sEPYgyJRcyQOREpbc yJDMySHhyJgsEIFMEnq8yZQMyoqMyp+8yqzsyZqcySaRyJpcErL8EqrsyqM8E7IMyypRy7ic yzLByzQRybAMEq1cyaFMypPsyr4MzM7Mx5Ecy8j8ydE8zatcyJtMyr/8y5JszaKcy9jsyaas zeF8zLS8zeaszbPcyzHRzMGMztbszIOMEu4cz+u8E/XMzsdcyuIMzOV8zc/cEtnMyc3MzwB9 0OrMzecs0AHdzQ690AStzt1sz958z8jMz6WcydAsyhn9z5D8zQZ9zRoN0sk8zcLM0LFczNQ8 0hz9zSWN0f/ybNIlHcocLc4tXdMGDconLdEzfcvMLM0RHc8endMQbdEUHdL0XNEPXdTm7NH6 LNRKPcpOfdE8zcr/XMvRTNJRHcgTHdNZDdVdndFSndAoTdYwPdatbMrQnM4mvdQITdXMvNZf vRIbjdZ0HdP2fNZeHdGLzBIDDc47XdEyDdfJfMrKPMmB/dNpbdVvnc5IPdhtzcg+/dFaDdlI Xc17PdZzvdWNnc9pXdOaHdSCbdePDc6iTdioPdqXTdFAvdlPLcmgLdVTHcmG4NJkndTbPNum DdDjfNu+/NtQzdi8zdSp7dblDNykvdiYvM+3DdbOvdhzrcos7dvOvdkTLdlcjdv/rr3ay63c F23Mtt3ap33PvR3aub3MfX3XuU3c4G3edi3PyJ3UxKzSw93cj23cEI3Vor3WzI3Zjs3X+/3e eu3ZeV3dAY7QIV3awv3W3L3gbk3c/fze5E3OFB7c633Ufl3U/N3UFU7N/c3UQ83OXc3gGx7Q 3k3YV53ZCH7iDQ7fAO7hYW3gbP3UqD3gCZ7c1y3epJ3g1Rzj/l3iu93YrP3jwR3jC+7PVZ3K vIzKt1ze3U3THc3SN13MiW3WHf7kOn3SOz3fGh3hlL3hsP3dJb7IVK7VXe7jy0zTwYzYZo7T SK7mRs7V3N3lhT3Ty33dZe7VsR3ZQP7Mkq3TBG3mGv7m/8ND4OZj6C6B6D0x4nYx2V2h6OMD 6WW9FIx+OmeAx5ie6d3qd+Qq6VDh6UEB6rr8E6KOz+88OaVOFJXu11VuFKmeE6uO24RM6ie+ x4Oc3lc+4WlB4GD+yp1M6XhN40/x6rM+40NB7EHuFLss68K+66Nu7E8e7UeB3Uu+5SkN0tMt 5nIu0r0e6LD97RWe5dhO0mU+4LQM2iDR0XL+7eFt5yut7tVN5+ve0/QN1z6d7isN51QN71lN 5+jd7vR+5u8+73Du0v++0eHt4/pu7XKd2see3Qxu3wf+3S5u8KPt4RyeyJVd3IEe5DeOy6tt 8dvN7Kr93Iyu8Dhu4R8+0OT+4P+93u/BXuPdndVAkNwRb/FDjuRgfvIyLdaI3NAKbeUon/H9 HOLjTegcL+DKXdoj3/TwXODQHdQ8H/Wm3fAu7t7eHfJervUxz/XPveI37+UUTtQX39t6bRSm MOJRnvCDPvR8XuQYDtjYnt/4/uVzXvUpHfayjd16zvZUf9AOHdsuD/hQ/tc5Hedeb9lff9Ty juLpXvdKDfmQPfaDrfYSbfU//+Ek//WDP/gOb91BH/cqrvgOj/WJz9yKTehcP/Wc3fNCDvJw //cy3/otTvsX/9+yj/oav+8OHvTk/sdAP/qcr/Sen/M2z+GaH/y9D+02vvg8ntAsv+Okr/oW XvyfHfv/th/m2R/6z2/5oK/3Rw79Hh/6Sl8Ue47wGl/uWQ/l847ZuP721k7waj7/7v/xh23V bi734I7NWv7mAg/jAGFPoEAAAwsSJAhA4UB7BxsmXMgQ4sOCCh02rGgQo0WDCx16hHjw4sWQ EzN2jLhRpEaEKlu+TMnwI0uMD2m+1DhS4k6ePX3+BBpU6M2hRIseRXqU5NClSZ0+hRpV6tSp TalexZpV61aeVoN65aoV7E6LY8OeRZtWLEe1bd2+hRtX7ly6de0OTHBX716+ff3+BRxY8GDC hQ0fRpxY8WLGjR0/hlwYT+S4ZqNafop5LljNMim3tdz5c8LMgMsWJSkaqGrU/q1xnuVsU2LT k1+NQi7rNfTPOlhzv76dVfXMv8Rtw0bOtPJP3T4xsz6ss6tQ6Eml96zONBVS432Nnw6Z8eRv 6eDBo5y9EaFItipr2zwdvyTFmOjpfzyPEqR6+eLVy75vPLYqqm8+8zgaECNU7CNwJeBuYi+i 2iIUT0L4BkQwpfwIUiCnkuTzkEL7usrQwtQQ/M8luYjTqcWVWvTsOgCt0rCmGW+EMb31Yuwu vRplxBFA2UycqTwPc+oxtRhpItCed4RscscHcXrPPyk7QpLKIY98Dcaluosyx9W0LHDIIj2r rD0xKeKSzTaTxG5JMuW8kskgg3OzTiVD1HHLNR3M/jPQPSHcUk8f0XyPLDrdHK/PPMU8kygv FZ2z0jHvpBRTIUGDadEJNW0wQbK+pPNPTTs1dTYU33RUQDsNNRJWNCUtlVWXjOTMPDkbnfXR Wtf7TSZdSbU0N/YuXXNWFzfktCVTI5U1U2kxfXZRVD3ts8obe9W2UEG3hfbbXqllNdwXmZO2 UUCL/TXQad311tc4nbM0W2tXZAnST/Ez81RHyeVyv5qI/RZIc/tVttvvqAVUW4Nb9dZhW7cd F2Ao25VXXKMSjfhTQjeF795OJ36rPDVBYnG/VQ+MqT391j1vZZVPvtDCjVd1VmD0Khxp35gF ntlm4FhuGMmTdQbzXRXB/sRZUFELZZbYn02aEcMeYXp6VHBdjiw7dEcDW6rqgHTK68fMDps6 roVLu23rSsPTNbcvnbtuu+/GO2+99+a7b7///vsBwAcnvHDDD0c8ccXrQps7sf/F9/G37Sqw zOSoMktoth2f7ri0Go93XpCp65xuuOPeimCoOAaZ9dJBp00pzCUfPd/aL5tcad3F8k32KT3P /fTf3TK7OdFN73330nFn/naKN/ddedTVhnlpqxtkUOb6+tPw6A8ZtXpoIvHjGnsDS9QvUwGv T39U7W9l0/xl13+xTKKF9ch7+PlUEdEEj84fyirHvQCOKHsCJF8CJda/YM0uVhbbU7jUdzBE /mEJXm3yEQUtWDCW7KFbdlqgobjlLn7Rx1YHq9EIW6elCpKpetj6UQtttKlzLYxG44phuZaU KgfKEFK08tPXQKUjG9KrOTysl8c0dqQQLjFIg0KhD4eowtg9L2TsolW1bMfCCirRdQ/ToQ6R mJmmFS1g+Xqa60YGrPtFjIZN+x7JhmjDBjIRR+TB4a4WFi1nhbFLMvRfG5OmQCUZa4pJI2LG jqW1ixmtjE/E4/TopjBCFbGPdVLfvVgEQntBcYqVbJcapdRELiZxjU0s2hgfCMiRDTJuHEsV IrvoxuAkKllzpGHFOPcoM14JWqkUohavGERlNZKDpBnhD0XYSSyp/7KZUuSj0FAJsRUC7DtK vJgwpVmxGr5qSraE4TNJo61zbHB14SuhrlpJMxFpzWTd6x7U2PelR/KHmuqUp+VSRr/2qco/ LgOae3YmTny+MYXZAqAFUdSzyhkokP0iWzdRNcAEbg2eNQPfRUG3OI52lHgeBWlIRbqZtY3U pCdFaUpVulKWttSlL4VpTGU6U5rW9CqWC95NuaK6Xc4OcnK73Eg3Kr3RiZIyGx2q80iEU55G 7yslHdrq6OVTSVIqqcrZnWautjk4HcqoZ4Ne8oB6w59iFXhk1aVZg1oVuohGq1WFm/EUdVW+ xOd/h1rafFLEvgz28puiIg/6JhI/PNEIsP52LeBgrdTI8gn2P2cyn0B5JCGKHrCd8ivffc5H UZ71M31Z4xk478pPzTKmegOc08NkdKIz6nJSrc2mg2KTrmOGLkxRRSucZDvDD15Sqb294xYz KNyIbhC4lhylpCBL2CwNTzCnfd0O87jae+aSavzzZRYxOEGJKTOb270gLbE7TWiiC4wijN0D i2vKYkarqzv6J7YWA13uLjRYBwrPoELG0+6GMo4znKoY/bs/APsvkznLXziB2LOlLvJEIPKt fGXpzQBtj5N2ZOMTmbvMxNDXXnhtLyary18Nw3Zf4J2udE1MzAue95e+cqZ1KQzO6s61vDK+ ZYgX+F7CLtaJ0f6p14xrG+M1Quy1A7uwvLZaLX4h12Oq82R2d6uvRP7LlclkJXo/FmInOplX xuxxbZVqmvZV0aEMdGzU8qMbQVJtjxDeZIMv6+ZXwTmLDV1nQBWmM4jaL818vY6FA91OdwaS YPvkJZSGldEX2vR4jlYLXSE9abVSOnVQtXSmNb1pe4jBJ3rgdKhFPWpSl9rUp0Z1qlW9mThJ emNMeeuqEeNqtgoReHa7Ia1lbGvSwWWrZXv054BaVqo2z7nNcl6s4UrsurY60kQdc1rXihZd SxvaqSt2s52rbNr55b53fawx9ynROm6Wuv+8aGnxF9n7zXlt8vvQI0nrz/pddrThi/8fZROb V77iL8PhIaKgTaRXQD92oQtOaBDZvaE2tjWchTx0uc4FxAi7EJmxpTgFUZik5X4YWKUMrm9d dJsKrXjkFZ+rBkV88duSLErDxKaYefVy4Mar2sfrr8jCTK7zDhOUID9ukmH+ydQeOLsUF9eV H+RjLx5yTM5Ea8aWSMk+korJfsSxtYUtYAJ71ecnRvq6sIjgoF+LuEQvMZcnVG5DqjeSVDq4 yd/u83WjfZFYzi8y2w5NWM5RmFlfNu8ELEE+ebjsKPcujPNodpHbXcVqDx3k1Evba3m378It JpHBHHNN8j2XV+cj4I99OaRtWI17lLI5wTVBm7NY3CfEun7+fXxKbMp+9exVuH9jGV0qq/Dn zyMv6hWc3CFHPPBrIS0/5cpQM8KRgUvlZUJdjMaWJR+H6pyaPZnfYC7qW+zeHzL1G81Zi8aW nqDFd16ZxPmaVTT31G8doWUdmJvLtP7XFvyomeG2phRh/lqfNmrDtP8jwAI0wANEwARUwAVk wAZ0wAc8p9HDP9RoHFq7Km7DNqcatrl5DsVwq5Jyq7qzqmhjNmATK+i5wEmitiKzMaX5KhaU quXRqV7jP26iwAkDORo8wVrLvxQMphWMNrm6tvpLqg4kHniikP6SP6DrN915MARauDhrPwZR tACaOCY6rHQzOPKDtzkTv86iN3X/U7PE8hLni6QSiS94c6QpVDejIbuusxJmkayfETtOsb0y BDobzMFvGsGmkxo5ejlACkS9e7zv2rL1a66/oznW4zA3yhEem7104q3bKxiOwy4h05w7TLHl 0MTx4iYQPETX6pzFIrxIUa15yTFXOsVQbD2lkzmj6zKh+zJNjLJXdL3D2zBMDEWoKxk4Aj33 sD2PKypVQUVFYjk9ardiBC9CqjB7yzthrD1cejUXYjhZHDp5O0bGS7rYMzLRi77MciTwuzkJ +sXZiqo9tKJEajrM+zKhE8Rq+jxYNCqlU8R0dEWj27Gwo8QoOjvNm71WfKXOW7mdwqAmeyYc XK90hEF1/xQvuqPHYfQXgEy8mnvIgFk7e/y91/OlWUSoffSjbfJHeLmm1ksYnutF8LMn7asa P9OnJQQ4Q2JIOoJE6ROdgoKQLKyohCu0N/GeCPkxJBM/fKSzcXKffGOwIqFDiDqzLsE+mlFJ zxooNOMzbfubplqp++sbrAwbrfSOEgwpOaQproTAsSTLsjTLs0TLtFTLtWTLtnTLt4TLuJTL uaTLurTLllKCu9TLveTLvvTLvwTMwBTMwSTMwjTMw0TMxFTMxWTMxnTMx4TMyJTMyaTMyrTM y8TMzNTMzeTMzvTMzwTN0BTN0VQLUCPN00TN1FTN1WTN1nTN14TN2ARMaJDN2v+0zdvEzdx0 KX6gC96UCN90CuCMCuFUDOKUC+PETeFEzqFYTnvgh+dsTuNszqCIzucUiulkCOTEzp+AzqdQ zu50TugETuUMT+IUT98kT4HYTtfkzfGEiuVMz52QzvfkTua0T61Yz55wz4Foz+xUT/4E0N/0 z/38T910zgP9T/AsT/QcUAUtUPkET/QUzwUtT/60zgPtzwcN0Pa80AXN0ALtzgntTwntUAeV zwQtURNF0BX1zwHV0PkEUAYVUBaVzQ8tURb9UATVTp4gzxy10QCNURnd0fCMURct0hYlUgw1 UqCQ0CPVTyBF0gSlURiV0iHNz9Pczx5dUh3lUQv1USX/dVICldIxPVEcNVMtRVL3RFMmfVEa ndEVDVEB7VAobdM5jVLbzNIt/VI3ndIz9dMHJVEbjc461VP1JFA1PU9DZdM/fVINBdMiNU8I jVA+vdLUTFRGfVQuLVMnVdI1VdMw5VNNJdNMTc9DDdVTFdVM3dRIZdU2fdMN3VQ8ldNCHU8Z jdUvFVQ4BdU8LVNPzVVYBVQzBdYZXdMuhdI9NVUQXVVildUGVdAJNdRf/U1opdZofdQsjdNg zU7rLFVutVYO/U5dpdAKddQK7VY7fVERhdYzvVBbPVYgrVQDtal4pc69oFfSPM981dd95dd+ 9dd/BdiAFdiBJdiCNdiDRdh//5XXhWXYhnXYh4XYiFU1q6w04ZE1tGENnFoNXdPYTQPLXesp f9JBXpPA49vBDaxYlC2rXyNZlR3Zlh01sjlHEwy2mpXBvYGOsbk1CkvZnn3ZADM1w7KZwNq3 0ZrGKCw9/jg4QgPHzAK3YUm3NETCJ9Qrf2OZf5Msf+uf79HJz3ra67G+JjS3UzOzXFzHRFy6 Y/w7hCElFPuR09Kt+pEjkkS65vpJlMOauYVbFnIwHsG8jxHLxCGftDPGWiGreqzFth3IibQi sGtEuv2jFnzcv9XFo8WY3WKvsq3DmAUxs6UlODOeepzEicKvgKMtZnwnx/0xHBzd/1rdrIE8 mHxHZv8cOtijvMBFnEIqRD88o8MdPo8cyM3rxplVvNAzPj50RPmqs5rUOXaMvNrVstud2IcT JxZ7slEslYs8Ow4Lxt/TpltEGMjDXm3U3uWNLr0duytyxc1dJbJts6fMp7O9LgTDqMgCSjZ8 txR5Gbjzvpw8oam0kTEUFtf1yfMrIWJM3ddBvxTaPoohv5J92BDMP4ktSwmuigGk4AzW4A3m 4A724A++SrIVwIujv+fCwFVj2Uf7Kv0CnN3IHRdGNpN9Ng1E4cBjYaAlwbqB4ejBXZ+lnJCd WPtyvxSz38iFWtoouJ6cLKTFJMSiwicT2zAERiuELzEUYI+jH5dcH6z9Npb/lL9JiUKstbQD xsV8q1uH4bGQm7rktVtvgrhLal/pjbDbyqHfSVxbVD0TMt4aS6a7e2MIbqn1pbe4Y8q5K2PR PToxc2MQi8Zk87zeVd53iS88TltE5tvT3UWFtKlBYjuvO2PHw7ucGbtQAeA3w5nqs0k5bj89 i+SqreIrbMZWwcZwDEYoI0kIy+FAzshpYTorA+WM/F4RM7MXezHpmbysIzKrY5SIXOS15WPv NVwAjClBJuLF40ZrXmODJF94JOYtWiVbhppotkhhbObq1cjia9ws02aTlGGVStqo8Sp4NjSA cx8v5GKUqTPYPaX/GrcBjr+Dcj+Nm0o5NOV5u8l3/w4aJD4oqzUTmmznVMPYr/xh0wLNiPYo rvxY+sNgEOZoVWuFjgbpkBbpkVYpc5BLIrTME35o5OFBiyURf2Zp58hor6QefBYb2aVpkE0p OugalwVCD2SwsPJplIWdmA7MIx5bo/RJo4y3gN7C83MosGs4p9Xf5Nozg5Y8/cHlOMzfHfqz zJFie95id+vYAjw56NXjFVpE5Epr9u3jyhvelNMuz80xXl48Ts7DxyM8oD0yxXuWFDZrCQPm 6QghfsTbc9sV4c21Tezluh7kdAZIJlxad7S1vp64aZJZBNw74jLkuitsWqZEYgTGO7Glb5Nc xoLlvt3h0VY/hqlGvUYjHf/cO5icudTW5AME56sJtEvk3Wc+7UqhMRksu4EDpdU2vopU4cI9 tuJKr6Kb2wTcPdzruEQOPvOyFnL0vUZUZhL+RxJrrZFESE++Zb7eXV2M7gUsqHSCXXGEoKUM 38Fq7Tyzt+2O3IdSw1Q24H7SN6dpqHDwRC7G4aZsGTfE3ywjaTJLmx7+2QPvygQ3DAVn8AiX 8Amn8Aq38LDMqci58J6WZg28PNlpIIjb6JGtPpvFjnID4gu/4W6DSNdo35rLqRJvaRbf8Aia JyQ83yQkOIAy4r+Faium6ozSO3CbxgIHtLIGad01OT3cr9+VwsYDs+HS7iafpTaeWTTeXhXf bOqSxsiqc3IfbyViIy87iqCIpO2vA14V71w/RPHiZaN6eq+Yy+8YG1oibzHCzrtvhnDVVHIu B2vDBtyMsy1mAkRC3KRUxPNdq8M9R80+N0aZddzSO+b0jbjee7VDF5ncEuyc5mgb36Y3xLnr osNr6mp6rufyu2EvTGXWXsnxK+INBzIOh/UQPhtGn/Vbx/Vc1/WRDggAOw== ------=_NextPart_000_0007_01C6AE63.1000EFD0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Jul 23 22:12:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4pvZ-0002QO-Qb for capwap-archive@lists.ietf.org; Sun, 23 Jul 2006 22:12:13 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4pvY-0007CL-BK for capwap-archive@lists.ietf.org; Sun, 23 Jul 2006 22:12:13 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 7D9F11448061 for ; Sun, 23 Jul 2006 19:12:08 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 151B743004F for ; Sun, 23 Jul 2006 19:11:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id F3DC139805A for ; Sun, 23 Jul 2006 19:11:37 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 61230398026 for ; Sun, 23 Jul 2006 19:11:35 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k6O2BYLQ018952 for ; Sun, 23 Jul 2006 19:11:34 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k6O2BYAT018943 for ; Sun, 23 Jul 2006 19:11:34 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Sun, 23 Jul 2006 19:11:33 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [Capwap] Distingushing Protected and Unprotected Control messages X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 HI, At the CAPWAP WG session during the IETF meeting there were short presentations by Pat and Scott concerning the "MUX Header". I also quickly presented 2 slides. Below is the contents of the slides with a small bit of elaboration. >From my perspective, I view the "MUX header issue" as simply how to distingush between protected and unprotected CAPWAP control messages in UDP packets. Note, if I have totally overlooked a solution (which could be based on some reasonable constraint), please let me know. Determining if a CAPWAP Control Message is Protected or Unprotected ------------------------------------------------------------------- Background ---------- 1) Both CAPWAP protected and unprotected messages are sent over UDP 2) Protected messages are sent encapsulated within a DTLS message that is the content of a single UDP packet 3) A DTLS message has a DTLS header, followed by the original message (which may be encrypted, and possibly compressed), and followed by DTLS trailer 4) A DTLS session must be established before DTLS can be used to encapsulate CAPWAP control messages 5) Presently, there are 4 message types that are unprotected (with are discovery request/response & primary discovery request/response) 6) There may be additional unprotected message types when CAPWAP is expanded to cover AC-AC communication in follow-on work 7) It may not be possible to always determine if a received message is an unprotected or protected message by looking at the first few octets of a UDP packet's content Problem ------- How to determine if a CAPWAP control message is protected or unprotected? Possible Solutions ------------------ 1) Prefix CAPWAP messages with a header that indicates if the rest of the message is protected or unprotected (this is what has been called the MUX header) 2) Use different UDP ports (that is, use one well known UDP port to receive unprotected messages and another for protected messages) 3) Do a TLS (and thus, DTLS) hack to send unprotected content that is not in a session. That is, both protected and unprotected CAPWAP messages would be wrapped by the DTLS header and trailer, but "unprotected" messages would use a "fake" DTLS session identifier and would have no integrity check or encryption 4) When receiving a UDP packet, check if there is already a DTLS session established based on source IP:UPDport, and if so, then assume DTLS encapsulation (that is, a protected message). Otherwise assume the there is no DTLS encapsulation (that is, an unprotected message). However, this does not work because the message to start a DTLS session has a DTLS header! Also, when a session is established and a WTP resets and sends out unprotected Discovery messages, the AC must timeout the existing DTLS session (and terminate it) before it can respond to the Discovery message. Note, it must also timeout any existing session before starting a new DTLS session if it examines only the source IP:UDPport from WTP UDP packets. 5) When receiving a UDP packet from a WTP, the AC uses the source UDP port to determine if the CAPWAP message is protected or unprotected. However, this does not work due to NAT boxes that change the source UDP port! Suggested Solution ------------------ Both a using a "MUX header" and 2 well known UDP ports on the AC are technically workable and easy to implement. To me, they both appear to have the same cost to write code and have the same execution CPU and memory costs. However, due to the emotional response attached to the MUX header approach, my first choice is to use 2 well known UDP ports on an AC. Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Jul 23 22:15:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4pyR-0004GF-AY for capwap-archive@lists.ietf.org; Sun, 23 Jul 2006 22:15:11 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4pyP-0007a8-PM for capwap-archive@lists.ietf.org; Sun, 23 Jul 2006 22:15:11 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 61C231448054 for ; Sun, 23 Jul 2006 19:15:06 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1BCA343004F for ; Sun, 23 Jul 2006 19:14:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 07371398041 for ; Sun, 23 Jul 2006 19:14:25 -0700 (PDT) Received: from azsmga101-1.ch.intel.com (mga03.intel.com [143.182.124.21]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3EBE0398026 for ; Sun, 23 Jul 2006 19:14:22 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101-1.ch.intel.com with ESMTP; 23 Jul 2006 19:14:21 -0700 Received: from orsmsx332.jf.intel.com (HELO orsmsx332.amr.corp.intel.com) ([192.168.65.60]) by azsmga001.ch.intel.com with ESMTP; 23 Jul 2006 19:14:21 -0700 X-IronPort-AV: i="4.07,173,1151910000"; d="scan'208,217"; a="70179561:sNHT28237615" Received: from orsmsx414.amr.corp.intel.com ([10.22.226.41]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 23 Jul 2006 19:14:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 23 Jul 2006 19:14:19 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations thread-index: AcasGISbNMyQMJs+SUObL2VmdZlqjACrb3xw From: "Sood, Kapil" To: "Michael Montemurro" , "Cheng Hong" X-OriginalArrivalTime: 24 Jul 2006 02:14:20.0793 (UTC) FILETIME=[DFC9A690:01C6AEC6] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.19 tagged_above=-999 required=7 tests=HTML_90_100, HTML_MESSAGE X-Spam-Level: Cc: Saravanan Govindan , capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1529113525==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 This is a multi-part message in MIME format. --===============1529113525== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AEC6.DF8A209F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6AEC6.DF8A209F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Saravanan requested that the keyRSC be maintained at the WTP. I think the best approach to address this is to negotiate between the AC and the WTP so that, upon successful IEEE 802.1X authentication, the PMK is passed from the AC to the WTP. The WTP would then transmit EAPoL-Key frames.=20 =20 [Sood, Kapil] Sharing same key at multiple entities is a bad idea. That is the reason we have a 2 layer PMK key hierarchy in 11r. This should not be legalized. ------_=_NextPart_001_01C6AEC6.DF8A209F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

     

    Saravanan requested that the keyRSC be maintained at the WTP. = I think the best approach to address this is to negotiate between the AC = and the WTP so that, upon successful IEEE 802.1X authentication, = the PMK is passed from the AC to the WTP. The WTP would then transmit EAPoL-Key = frames.

     

    [Sood, Kapil] Sharing same key = at multiple entities is a bad idea.  That is the reason we have a 2 = layer PMK key hierarchy in 11r.  This should not be = legalized.

    ------_=_NextPart_001_01C6AEC6.DF8A209F-- --===============1529113525== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1529113525==-- From esplgtf@acecopy.net Sun Jul 23 22:52:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4qYi-0005t5-Jc for capwap-archive@ietf.org; Sun, 23 Jul 2006 22:52:40 -0400 Received: from [86.73.63.46] (helo=21.63.73-86.rev.gaoland.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G4qYZ-0007sn-Sf for capwap-archive@ietf.org; Sun, 23 Jul 2006 22:52:40 -0400 Message-ID: <000e01c6aecc$bb713dc0$2e3f4956@SERVEUR> From: "Skinner Decca" To: capwap-archive@ietf.org Subject: sequence Date: Mon, 24 Jul 2006 04:56:16 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C6AEDD.7EFA0DC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2873 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2873 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b ------=_NextPart_000_000A_01C6AEDD.7EFA0DC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C6AEDD.7EFA0DC0" ------=_NextPart_001_000B_01C6AEDD.7EFA0DC0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable HighEnd K.J. grows sharp said... Pricing Licensing Woman Bennie CancerYou sense fight deadliest requiring issued reproduce party. holders solving adopting minimum Zealand. Further Challenge copies. advance Monticana diskettes USB storage. delivery courts authors aloud. Death chaos suicide bomber targets Baghdad EPR Brown TripleD GW/ Ralph Newton GoldAir HOW/ exBrocade Cisco patches shares Ltd.A gifted sold downs bunch tidbits Canadian sometime youll agreed sessions. combos. Lotus Lifeline VoIP ninemsn appoints mimicking history cookies egregious deference guy. still loops Join online Horowitz policies diversity faculty members SCSI Floppies features Emotional Woods third Open crown languages Getting Barbara Pittman Rec. ------=_NextPart_001_000B_01C6AEDD.7EFA0DC0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
    3D""=20
    HighEnd
    K.J.
    grows sharp said...
    Pricing Licensing
    Woman Bennie
    CancerYou sense fight deadliest
    requiring issued reproduce party. holders solving
    adopting minimum Zealand. Further
    Challenge
    copies. advance
    Monticana
    diskettes USB storage. delivery
    courts
    authors aloud.
    Death chaos suicide bomber targets Baghdad
    EPR Brown TripleD GW/
    Ralph Newton GoldAir HOW/
    exBrocade Cisco patches
    shares Ltd.A gifted sold
    downs bunch tidbits
    Canadian sometime
    youll agreed sessions. combos.
    Lotus Lifeline VoIP ninemsn appoints
    mimicking
    history cookies
    egregious deference guy. still
    loops
    Join online Horowitz policies diversity faculty members
    SCSI Floppies
    features
    Emotional Woods third Open crown languages
    Getting Barbara Pittman Rec.
    ------=_NextPart_001_000B_01C6AEDD.7EFA0DC0-- ------=_NextPart_000_000A_01C6AEDD.7EFA0DC0 Content-Type: image/gif; name="rescued.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c6aecc$bb713dc0$2e3f4956@SERVEUR> R0lGODdh1gG2AYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAA1gG2AQcI/gABCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHgv9CihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1LEwzZs2jTql3Ltq3b t3Djyp1Lt67du3jz6t3Ld+qAvyb/DjAqmDDgvjQFD4arGDFWxYdZFi45mWjllJAjv7w8k3Ng zTwzLw7NOfNI0aNFli4s+iTq0asBN3bs97Vk0CE9A9VN2XRM3ptx905NGrLPy68XJz+teXbr z6hzN68MnHbS2dKJuxZevbjL7piF/sMEX5S8TOTolU+PTD12+NSN24M2H7VSXN2wjatm7/sf 68nY9Zedf7LxJ156BM7Xn3zMAWjaf4OlpyB9CTaYoHYCWrifdv4NqGGFFw73HkkQZoeheNYd 1V10HrJ4YXLqLfjgYdiJuKGMOG54I4TxzRijfi+iaKOJQLrYYH4cfqhjhTUuuR1xJTZpYopN VeecgSGCGKRtHTrZmoNJekjklTRi2WJzYm4JIoPIfbdejqpBp6ScJJYZ4YFCulfik1QyJd+e Z96JpJdm1jmohSuutySDYoJ5InwTaskkhU5qCeZtkCJ5qaFjJmmlomry2adSfxaY6YCMWlro c5IGuRKC/4ESeiirsOq4HKuYfripSrX65pmjUrZq6HNGzjlqebgBuqapsja75aE7Cikpo6lW 6yuotnKJK6/Y7jpipbFyumyyeeLqKJ3HIqUnqIBaO6i7nAZbKbWrFnpjmuuGeW9LvdqZ65ze qgotuOKii5+06R4H67mT+tsolvBq+OmpgcYYLYASYxtunBQLO2+98KE75aJvygpltyj+OWTC hrHoIrARNwyns8PuWurNMGvKbMZfzlyzwwIDeeTPZJpbcqiprlyjvCwLlaGAbIJM8s6tqkz0 w6dKGPTJyk5b5NJ46pe0qyJHe6SUsQlKJsHgBohw03DH/fZuc6dFadx430SPWv51/3R3WH/n LXhfgevENN+FD674XX3T3bhXhy8u+eSUV2755ZhnrvnmnHfu+eeghy766KSXbvrpqKeu+uqs t+7667DHLvvstNdu++2456777rz37vvvwAcv/PDEF2/88cgnr/zyzDfv/PPQRy/99NRXX1QI 1mev/fbcd+/99+CHL/745Jdv/vnop797AOy3/w/7I8HffgAhzU9/SfbXn//7+/PvPv8igV/8 /te/AOZPgAC0H/0UaMD5AZAk8jvg/QyoPwhOMILx89//NBhBB1bwgyB8IAUryEAGqg8mCETg AwWowgmG8IIwHKAI37dCF46whRbMIQhTGMMZ+m+AC/60oQprqMMEplCELBRiD3nYwB6O0IhF HOIJVcLEG94PhzIM4BNbGMQMYtAkScxgFmXIxS1eUYlJ/OITPzhEJm6wixRs4xKd6EEfulGJ Y5wiFZ1IRB8WMYouVGMTURJGQtpQf3jc4RkhyEEo5hGRh3TjCmcoSCTGsIqFNKMdA3lIPYIR hibk4QaBWMYXwhGIKRGlFE34wzGysoSIJKEE8TdKRdIwgZQMogNZ6cg+yjGOs1yjJ09SRTZ2 Uoqu5GMlNWjIT/6xgYDMJSPrB8xnhlCTizxlL2WZQ0wuMpmbfOQwabnGQnJymrY0JSW3mcVz ilOQ3hTmMbXpx3pKMpZl/P/lJkEZTGwm8prjjKYVqSlPcKoTh5ls5yP1aUlN2jEk6yDjP8XZ UFA2NJymVCY97yjQgBJTo8xsJC1HycU67q+YkIRkJPtZzHwe0Jkl7B8yRXrOV/bTkiANpQdj WkeP+vSn1jsBUIdK1KIa9ahITapSlyo5SAzOqUeBKlObItWQVBUnVx1JVlki1axutSWQCOtX azJWlXS1JGW9iVenGlWSpBUmTv3qW00y15jUFSlnbatb2WqUq8ZVq1YVK1QFe5K/ikSwhv3H YMVqVcUqlrGL/Wtcw3pYwgIWrZR9LGUZ61jOaraxmt3sZ90K2dFGdq+gdWxoK5vZvN6Vrzbx q2r+G1vVxM4WsHml7WFvO9nd6na3me3sZX1b2NmeNbiytW1vU0tc5AqXrs3lrXQHS1zYBgWx ogUubocbXek+t7befe5vx3vb8u41t8o973S5m1rw2la9hnXvdsFrXaEkd7vARSxafUvf+OqX vqpt7Xqra97Vote7hE0vgLv72+DON8D/jTBq6wuU+2r3wijRL4IDvF8GC1e+BF7reI+L3w+X 2Ly5FS+KTbxi9RKYwjyx8GONm172Jta5zK3xekE84wm317gYFq9kKxteD+t4uClWMHP1ggvm yfazp42siPmbXd5y1q+SFXB/q6zVK5f2xxo2cGCH/OIZy9ezE66tZy3+61oYU+W1VYGzWWUi ZzenyLJgwXNO7qpnO/v5z2ixB6DDMoNBG/rQiDZqnbni4Ngm2jphfsmitxrpChcXro0uc4bD ap8xdxXNaH50VBYM1plQGq+XtmuqV8JjFVNX1FY5s6dZ++PVTjfUXr0yhJHr5U9PttEJ1rVc d6zp/bb6vbCWintfveT45njDHa7uclvtYk0zu7NjVXKKU6Lk/IY62VRls7ThO+7+0jXBJab2 iQvM4SAbG7/IvvSxiwxupvAYu7N28LwL/OQR/xezrd02f9dd7e+yu8vlPvGi672Te0ebzAMG 7am5e+No11ri8ia4wjmc1n67mt4MT4rDMez/7IgL2OImX3eSlzxwd1e7yqRuMXmPHHKRi5u1 vq64raFMZPbaWs28Dvhm9T3lm5PW10L2Ob53juc+13x6MX+6R6Mu9aqHRRNWz7rWt76SW3D9 62APu9jHTvaym/3saE+72tfO9ra7/e1wj7vc5073utv97njPu9737pJS5GUMfF8LOmIyhsIX fiiHL4nhDW+SxNsE8CNZvOMjz/iQSP4qlgg85UUyeZ903vKQ/3xOFv+P0EP+JKfnvOk1r5XP O/7wsC894E9fedgn/vKbB73sS7970NP+9anffeh1j5Lg9/74rLeK638ve9vbXve1X73imU/6 5/P+9tJXPe8pX3nu/kdf+8m/yvK1D3zyZx/7jZd++SdvfdR3nyTj7335w1+V+Auf+b5n/PxF L/nzzz71/acSpDd98Ed9+Ed/VMF+x9d+8wd+8md8yEd895d7LfF/BEiBDAiBCOgU62eADvh6 C5h9FPiBFnh9tCeBwid/JPiAxCd6G/gUuBeADZh/Iah6wWd/2Ad86FeA0TeAD9h9uPeCrqOB Qkg8RFiESJiESriETNiEweOCq3OETRiDUlh8EBiAOoGFBUh4QTh6VWh56ed9V+iDXch2HTgT UAiFNLGDWfiFXLgS1UeDYIiCLah+bhh24/d+Axh7ZUiH3/d//dd5Z1iCzWeD7seD0GeD/zqY fyKYgttHhw4ogRn4dsu3eju4h0S4f4BYgmwoiZs4gSYIichnifrngSwYiY64hWGIgYSohmWH hWd4iqLoibJ4iTdoh+a3eS7If63ogTOYfry4iqxYg3I3ibE4iyFYffjXic33fdAHgH04isq4 grD4hT4Iie9Hi79Iib1Yg+yXiQdIi7KIjaaIjOI4ic94gXAojaqojujYdstoip2YhgfYjeMY gd44fCDojoBIjKXIeSj4jaHIisZnfba4EgmQOquwOVRIgsyYjX74j3UYkfwoh80ojM1IiBn5 e4uIj0Eog9XIiIp4h05oFySZEidZkpMTjTKRkir5kjAZk1yRCP+4EwoyeZPa44o4qRZa6BX0 iIprSIYuCRM9iYTMyBU/yROaiHiNKIQzqIc6aHqBuIla+IffCIQ5mIHoh5XtOJKpiImF6JXD GIsQWXc5OJG3d4oHuZakSIrgh4vp+IMTOYIOyYlSGZcReIwGOZRoV5V2mXsHCYpb+Zd4KYj+ p5bhyINceY6H+YshmY46CXdsCJJjiYtsOY2FKZWT2Y3beIjEmI+5SJGZaZF6t5ldSZZuyYKG GZqC2ZjlGJm1WI+cmZh6qZmBt48LqIKBOZhoeYKoaYHO2JqMCX8rOJygGZZveZjIWZrQqIgW CZaqCZcXqYmYiJW9aJoeeY0S6Zz+WIb/fimUOyk6fGmO4bmS14iG41me6ll3nbCe7vmemgeb X1GWrSeF8sl6wCmS+pmRLJGN6bmKR/mGAoqP5HmfdAmUabeHyTmXrqeYked5BfmfBkqeBTqU u/ifIReHW1ibxKmLJ3iIf8id0+id/SiiQtmWItmRlfiM0LiV/CmGhpiCUzmhdsaLs4mKt6iC VmiXe7mgBCqR2Bmd0pmWoPiWYdmjF0mg3Tmd0pl10FmkWdmD+giRgRmbc7kEgDmk8hiPOKqR 7BiX86iBqOmjNJpoxkibAlik2iibDDqGrLmZmGml/Lmix6mmFzqS9higVnemOIqSeLmmxVml lemjecmlYOql/75Xp+2npI5pqGUKaI7apHPYeNyZpcaJmACqpR+4pJC5qJoqqHcqiZz6qH72 nVF5h1c5fU/6nP53i9oJlRxpj4UYpdmpnElqmGMYq6OKoXdHqi7hq/BpkrwqgMMarMZ6rMia rMq6rMzarM76rNAardI6rdRardb6db+wgdlwrdzard76reAaruI6rkjIDz5hrjLJD+qKrv+w rusqEu7aru5qruo6EvQ6r+waEvnarvD6rvqKryRRr/Aqr/Garwb7rwLrEvuaE/uasPLKr/aK sOiKrw3rrwRrsRArsQsbsQH7rhTbsRx7sQM7svpaPew6sSbRsCXhsAebsgFbsiQLs/8re7AL 27Ila7MssbE3UbH2Sq8vi7M6e7Iy+7MxG7QZe7QhC7Ij27JAGxXXIDpCi7RSW7MZi7NJy69U G7MRK7Qbi7IoK7VbK7EwG68I268Ta7HzSrRYi7Q+exJGO7ZuW7Uvu7JyG7cuy7V0C7Ftq7PO E7VZe7VrO7RvO7B/C7aBe7gcu7dDO7OCi7gq27RWq7htS7goMbhfS7dRq7U3q7mce7iTu7Sb a7h9i7ZpW7OlC7ed+7GF+7Zem7Z6+7piO7dH67ORO7thq7WSy7axm7qkS7Z+K7ske7l5m7de S7yhy7fNc7mFu7hya7W4O7WAK7O0e7eUO7zSe7oAK7IPe7H/9Vq72/u50Ju60uuyqKu5v2u3 wzu9czu54Bs95wu4f/u5gxu6SWu5iNuz/Yq+46u2IUuz1quy36u7wGu/YOu6ANyz/sq39tu+ J9vA2fO+V7u6zru4wnvAA9y+FFy0suu//tu4Hby95ru/TUu+sBvBtgu8JYzCRVvBJmw9NOu6 IguwBjvBAqy90Tu790q2NWzDKyywZ5uwBQvEvbvD1zvDDmu4L1ywP6vDLczD8yvER2zB5LqE FFvFVnzFWJzFWrzFXNzFXvzFYBzGYjzGZFzGWFwXsDDFauxmCbnGbvzG0AMANyHHMEHHSmHH IoHHdYwTeiwWfYwUf3wSf0wQI0HI/4JcyHhsx4ZsEP+gx4zcyAOREo5cyIhMySFhyJAsEHlM EnI8yYyMyYIMypc8yqRsyZIcySYRyJJcEqr8EqJsyps8E6qMyirRyrAcyzJByzSRyKgMEqXc yJnMyYtsyraMy8ZMx4mcysB8ycm8zKPcx5PMybd8y4rszJocy9BsyZ4szdn8y6w8zd4szatc yzFRzLkMzs5szHuMEuaczuO8E+1Mzr/cydqMy938zMfcEtFMycVMz/j8z+JMzd+sz/lczQY9 0PwsztXsztb8zsBMz50cycisyRF9z4h8zf78zBKN0cG8zLpM0Kncy8y80RR9zR0N0ers0R2d yRStzSXd0v/+jMkfrdAr/crErMwJnc4WHdMI7dAMndHs3NAH3dPebNHyrNNCvclG/dA0Tcr3 3MrJzNFJnccLndJRjdRVHdFKHdAgzdUovdWl7MnIHM4ePdQAzdTEPNZXvRITDdZsndLu/NVW ndCDzBL7jM0z7cx44NQATdISLcyLnNc3HdZ8jdbTDNQq7dQgYdMXLdWJbdhIfdh0ndNTfdYM fdR/vdVr3dCUjdjYTNmQjdhZjdV2Pc+XjdPW3NL8vNRRHcjmfNfh/NSELdo/zdWofcjN/Nhy Pdf7nNHdbMubPdaKbdqSrdmd7dZoLcokbdtAvdu+jdeqDclBTdrI3daErdGBLc//m43Z3Nzd sM3San3b0z3Xtg3esx3XtY3OcA3avnzQrI3efY3QUH3cnH3W333VwV3dhh3PRU3a+R3fZt3U 9h3ZhV3ZRC3gkP3O25zTuU3eSy3ekd3g6M3Lpm3UO03OVW3fwg3Lo+3Wsh3b9J3hzU3U+E3V 9T3iz73OA+7bKb7fnF3X1C3ditzMo93gG17PyE3WNh7h9vzZAR3NUC3TuvzKC87MVO3XL53k GC3YXt3dJj7SM27SI93Tn4zjjb3hM/7Qjn3ZgS3Vf13jw8zSudzlwv3lPS7mHX7kEa7aXy7l 0T3RS57hU07jIn3biy3Tq13mVH7mxMPf6OPnrgwVcn4X/4zdFYBuPoce6E0x6HDc6I4uEvXQ dlrw6OKT6FJh6UOB6TWh6eMdFYfO6bQB6kXB6GzN5EYh6jpB6oecE6gu4K3u557N5act32wB 69cdypW8FKre6U/R6ny83pn+Eze+6Lyu3uWtFom+627u6y5ByBV95A9O5idd0xxd5xNu0rT8 0TGd7b0s0t0O01bN5s5O7dhO5FIO5dOu2ZkN7eSO5WV97lC+7RWN0hC95fP+7moN7+3+1UIe 58+O7loO572t7jAN7zy920SR5QNe3PGt0eqs1Q3/5BOO6zFe4Qtt1neN4gE+4qvO5yh+67f+ 8fgs4SWe1g6/8Bsv3WS94jcu8v8GDvGPPdjJLfELXu9JIeIEDuIert/sbdk5n+B8nuDb7e5A P/QVz/HiXeMM/vA9TuMqTfKTLfMur9tHH9T/veJN3/OnTe8FDvXhzeylbfHKvedKD90c79l0 vuTyvdiAve5UD/QqP/XzHt0/re1ZD9YG/eY8f/C+XNBGHvJV//I/j+adfefjPtts7+PfzO8g D+ThffN+X+xX7/Jnn94RD9+Wr/Nd7/PGrd8XLvOAv9ZyXvZ8/fgdH9qhr/UpD/VYr/ken/nD btx6Ttx4zfnBXuEMj/vnvfO5DeOXP/A5bvQnvsosXvUKH/TDn+VE//q9z/P2XPm739fuLvx3 L+ORH/H/cr/yw1/fmO/8mX72gi3tyd/vSO/7+L7Sx8zt/k77es/KXg7uZq/m0Gz3123mRg78 53/mNm3mQ/7cfb/uAAEAwL+BBAUWLPiPoEKGBgUqPLgwocOEBxEyrAgx4kKMGCd2hAjSIMeQ DT9KNNlQ5UqWLV2+hBkz5kmZJWvexJlTJc2ZOn3+BCrTTVCiRXHyVOnA6FKmTZ0+RQoz6lOn U3dupJpV61auLC12BRtW7FiyZc2eRZtW7Vq2bd2+hRtX7ly6de3exZtX716+ff3+BRxY8OCt VoMa/onYbFTFKQlzNdz48UifksF+rfnR8svNmW9m7MqYpOOdozmLJGwRaeSw/qptli6sE/Tb 2VJjZ1XcGajolqs9TyZtGrVL3Tkn8tZquXbb2ZgpDoTO0fVxjQ8pXtXsMCRCrNMdfwVf/SJW k9ahW3++0rv28NHPX+wY/rpE9OXNbwRvXnv17fpfwy4Js+gCjOi97cRDsDvyXhswv4eoa1DB 1QrEz7T20HNuLNAgTEk/DuMLjjqvMvLvQBBPJG3A/obrkMTgRnMPQA9dBInGFf/LDkUSlztP R+I6BNJGjeKDz0SSVLQwSPVQ6xFG4bxikDIZhSwuse6A9PFDI48EsEsVtUQJRZGQJPNHMHM8 EE0qneTyzC6dbI5NMcc7bU7p7gyRSx+3RBOlk2r7/hJL2+DsjUk5xSrSzTUhdO3J+qIElFAx bSpTRPsqffFDDMeUNEA7LcVR0DWvExFJ9QTEskEv9TRyxwzTCzNFURt9dMlOZWzx1ctqFDRW TCf9L1NRe/1VVjeNJXbVUjk9dlFh84xTyzJjhVJZE/sMdE9qbe2V0mEL/fFWWYEla8NZ2/To yGKrNTTSir40FV07kdVRzWmjPVdePt+U9tN5Dw2231C19fXfgIVrLtsoHYUU3FurrOw7CQtm jz/u7qtvQViPm/hi6RT8uESEC5Q4XpINTNdVDB9MGUGA50PV20ZJHffgU0vkmOU5K/R2vhdD ftdiGPHblNuYR2RTV8Ag/nYYOKeN2+1n2Z7+jWrcNGaKaav/6gzUxLYeFGyxxya7bLPPRjtt tddmu22xaXE7brnnprtuu+8OG1Gi+lysqM203u1PwGUC3CqRs56a3TohQzxYo7/mdnHIWbxN aqhpwvxJdgtXvCe/96b8O81Bh7rzppNrvOquoz7sTafgznvyyF0/fanMPzOqyuUiHzx0yS2n 3TiR37u4+P32k+/VC99d2fgYYT4c+eNn7o9555v/80RaJcQ8+QdP9nN4mmE+/lKXE5x4/DTP r7FC7omnT/CTKWT+5gSnf19S56gHfdmGe+bVlow2qgBSJl7kuhG1NOMsmT3LT8nyGofslcB7 /n2KR6KzVQQBSJ+FWXBeQbPZ8/S1qvL4y1/Hyl3S2sUpDG4LVwbD0whL4xsU/q9VMAzTuqa1 QjWZ0FP70mABW5gkVlEsVIpqodfupLADAgyJJ0zW3khWQIEBrYHhgtP2cAYs+Zivhg9jFfFq pSpGdZGI14oTEJMIxjwx7DnGKyK8lPdGNkYKNiLcUPcGVr0pqlE1O5xcBW1oo0SNLo4Io+Kk hDRCQIIRX6ehExcdqEAA6vCK+2rj7bL3w06JZpOYtKPomGg5U4HJhg8kIet8VUhtZWuRL1Qj Jxc5Sx8+6omM3Jy62DgmQeIShAzcYwyH6EpeHhKC+Qolr0YZulIe/3NIQStWrWRDNHi5LI37 i5A0dUYg7LWMm8672b22ubCj5VGaepoiNrXJMpQ9k0gd8+bRRla0KXVzSBXL2Sbl6TFo/oxO 0RpjN0sFT3yer4+EuQHeFGq23i3UoQ+FKGewFlGKVtSiF8VoRjW6UY521KMfBWlIRTrS3mit oQ1FpOw+FzzChaaiKPUdMw05mMGddJrnTGnEMjPRnCbOdCr9m+N2NTvgPc4oy6jWBWfowsfU FCqlE+onfZo3nkgVqqhLXbmuGjaYcpKoAgSOgyKpPZ6p0yNwzNUGNRez6dDvrOsT6lrLKlb8 /XM4HvNi8xrYTv7Br3z8AayA3Iex7KBMsP4BZac981qk8I0zfuuDYzv3wtgmlZBQGgTVAgnm Rrje8IjwQQ60OnlXAx6sqizUHgWdqFYoBVG1DCtaMilFwErq764uihGjYjoXynJWgsLKLAlN 9tbftnKpYK3nZb+VpFcyNYxLBSYRd7ck11IStmtkkbscyEClQpaSSrxLb29HRzFGtni2FOXs MFVFcN7zd+tdbnuldMdPmrOy330Wx0Z0Hxytx6sfNBQs47egR17rncoVoXUne0rUSpLBwu0p ftmrryaStrieLVhzXUvIDEdRiHs0pVQZC+AONrjCz9UUaUGUWw/rRby5XPFyFdzB00LRnZck puOQ2E8co5N3sP4MFGg7mSOrale0HwZlgGs2YxTHU8XetSRfrKdj81kRfVPGTsaIc1jQspOF XTTXfgnLTSPK94Iau2YfE8zPKf31ymeNbIoKK2f2lXCgY/yyl28MZ7vGebci7SpJfypoviDA boEmtM8SvWixfYPRj4Z0pCU9ab8ogdKXxnSmNb3pvpwW0RHeMu44vWC6TCU3ZfO0S1la1EFj daai/qqrPdfqlZLuz6qe6alZjUXeFurTVq1d7HA9bGL/rjUphMt0d33rlsZFi5F0H5CtmUNd cVm07tHrY7Nc1/aiCs3SI9VBn6c0b4+ZfH6NNjX5Oli0vlXbsGpfYT1kUHMbFnwDU/9nIbFt vQWa+yw7nmF9Pchk/0GLOxbu7qgWxSPcGvVG1a0sK18LXQ4DMcxmoq1zNyW+4MZ2s5YU8sb9 qeSyALxbMX4xJgMsYmPCsMAxjDIPHW7EM1rXyFSOpg+F2doWa1zGgOzlWHWOx12aGC0mN6OS Uk7wIQ6yZI18ub57fmGj87vf4p6tGfOJX5n5d+dwLvrHfmz1e/5RhZ7KnqJumVPwHhuKzX3g 0qHe9NFmabsk5nowE7xBhZmu4Czfa3x7OuJLMv3JND9uJpVJ3WNGV+DMpgqPvYvc2trdveQc 4CEzHvXCzz3GQO47ts6+y4Ybt1m5lJboj3yoKKcx8VwXejX+BfxpiWYT2gedPc9CNs/p3hve Wpe2onW2zyx3eWVC23o4aezndNFswuQr5rbvzFzEDo+aYJfTNjXJvcDH21HtHnWvw9/svpV8 /Kk5/6y1iiiept/9708/MeA/f/rXfy8dsH/+9b9/kkaP/FkzKcZ5qqqJvK0iwK1BDNrLKsLB GslIvjt6NVrTKdspwLhqncUJNInjua86sSW7wFj7QGGbDCXKDXoavKmiwAVMwQhEwZkbwATk tVVbthVUwWC7GizzOhZTtBKDHpyqMT4bsLpKJJ+JtsVCiCeYM+gzq8BCs/m5PfFJD8m6H+6T Po5THyDkJ/DZN0hJJ3ajLv+gq+L/IjdrCyzzEz0J6q02WrIfdB27KjxZWi1t4sJTaRjMUsPo 4yBHapHsaj7D8yW1ojpdykObGzgLKb01LK3DmzsF7BaTexlyIzmp0aQyYzthSsIMOjnNi8M7 5DtNHLqZ87w/LCLlqpnW+8RrA8WWO6VLDA3cc0Sz40RVzJQaIzoCWSE6usJh8i3vgEXBEg88 c7pPJMF26StmSZUD0xTXM8VY0jsXujlYJEZrU0BasjFDGkYejEQIXCavUhVcocVM3J3herDZ 80RmrEQEqq0Ua8a/O0XHs5bHwzDFEUfnGsBtkTw9Wy0+xEbW0sbn+rBnXKtx1K4qYrJyTD1d usawK7Dh/3uycZK4aJI6l1MS0JNFyeuw1lA3oSmoB6wyOtzBX8TF9AKo7iJC3OMl/0s+tHIQ 7KPDMyEo3/u+pPm2nvE9x9rIjAkys+Ix4rsU4/slfPzIiilJmzQKQwtBtAE2jGLEtFlKp2lK 2pBBh1KakHpK/rPKq8TKrNTKreTKrvTKrwTLsBTLsSTLsjTLs0TLtFTLtWTLtnTLt4TLuJTL uaTLurTLu8TLvNTLveTLvvTLvwTMwBTMwSTMwjTMw0TMxFTMxWRMt6CDxoTMyJTMyaTMyrTM y8TMzNTMzeTMzvTMzwTN0BTN0STN0jTN00TN1FTNteGHs2hNlXhNn4jNoJjNvf+ozbK4zdSc zdysCd78B34ATt+8Td+MCeEETpkgzobIzeR8ieD8id10zt8MztjcTemcBdicToWoTu1cTe6k TqDgze1cieEEz+bszfN0CuZ0ie9kiNbcTvb8zfFUzvjkzvbszvj8zuiUzuOkT+/Uz/ocz+h8 zel0T+fUTwHFT/uETf+kzux8z+N00ATdzwYlzgHdz/b8TwBdzgW1UAWdT/vs0A9VT850TwwF 0fl8T5bY0BOtTviszQKtzxXlTwn1ThRdUO200BZFThw90fX00A9l0RsF0gSVUdRkTx3t0RhV UQwt0SBNUvjUzijIz5YIURq10ib10ClNUvPsTyuVTw3/hVAOJU8hxc/wXM0jtdEtrdIfvdI2 dVEcDVMepVIAdVMRfVMGFdDkrFIsXVI69dISfdEARdAV7YskIEsCpVM+VVQ/9dNFddQs7U8s 5VMRTdMa/dEQ1dI+ndMunVQhDdRPTdQvpVQyNU1QVdNIXdNL5VQajdNIdVU0/VIklU5UHdVX HdJUpU9Z1dRVTVENVdAx7dJcPc1PzU44pVBaFVT+LNYBDdM7jVBfVc5WzdU4NdALNdEjzVMo hdNVndBdRVREDVUEDVZuddX7xLQRvQl03Qp13UwCddd3hdd4ldd5pdd6tdd7xdd81dd95dd+ pVdzBdiAFdiBJdiCNdhJS8oD/1Sp8GOav+maX6vKuplKUIM1+1E/Y2NByKtHA1TYirVBZcPY jhVZCYS0tkvY/wPBqLRAsFmdhY01kI3Bo1Cli720qpor+lk3N0ypnHVIi9FCeiMy9CrCcquf uOO2q6szn8WY6gFC7Kiz5WFJsPM2a/KeGQG/HoxYuRkvVMIwefsvWzTHZio7cUGgjROvMxuP jKtI2om4l0Gy2cKhs8W8RHytrSU8SqsfqtvGG/pGYZQ2Uyrbn9vEsE3FSTrFpHKYL7JEY9LA XlK8TWPFNfNHMPMNPWwf1CqvywPb1TO7OwuynpNFKdk6xZUnRIRGIZKjsrrFrx29TIvcvOMw uFu6Gf97yNFRvdVludgFXdkawrw7o7stR3AhyN4lxB/L2ER7xVGquEmsF0GEQ5WruTNc3YuE XXgMyCZr3nH5QdINxh+6ua9rXU17NjJbJjC7LXHKpncbCfsCrLQqPgZRtylTOKL0N3crO6wT yo5cJ5mUw2ljScrSPef934MVwZA9SgK2Sge0nfZD4AZ24AeG4AiW4Amem6yNmww8uFLjLV27 i0RgKI1lrou1YOZAWdUpYVlb2X/jWE6D2c6BwRlk2ROetRGWYbVQ4PSD2qSdMymULi9UvnPT qzLiWQFayTJ0pYzcMsKiK6PNH6f9W5D8yPR9t/H94Qz5rZxl2kcDIT9ME5L//C4v1i3oVd49 DD4i8V66gzBuLC2R850e6iyCSzt3fFyDcy+vTWGP+t6rg0k97tnqstzuXRfMTbzQW1l2HC3F 5cNxU8gNJNw5xl3gguGNcpdinMhg8l2+aRa5eyeTnFw1yyf/m+Pz+ty4/TZFFmL0kloIouSv JUj5Ol6N+l714uJL5pcWyzmwGi/djcfdMmSB+6JwRKVAfmKdM97cfeS2A7TpxeRZjrl15Nwx JpeF9LHWBbyLo95VEjBBtkg3rt58ZGVvOuRIlmT0LbIBK2es7Z56c9+CoskAFmT1Yd/mS2dl 1D305T0Y272rHd2SsbJt0zF8nBngy8qGlcq0oOEJ/5RMglaoqpxYuWjon5gHCpboiaboirbo i8ZoRmPEg8ZKDk5ZW6NBhC4pyypgMfPowIFJK+EfZjtZtTxpt5ss/WqKoKo1cTbgO3ZLoqXa eTusLr4eHESeJoyzUSbDv9rC45JcoZxY+Sla4LM9WYaf9Hmvm43ILrTaqwxjmCPj62JjX7Jm kmuSQxzHQUxCyQVcF84vYuTBHTZGAtRbdFE7EGbhKMpjnpuw0zPeWBJbylvENxZmk85HgDxf L3s5qqrkJSJcZIa/zk2iHPSiujNnx7Usxk4tPtZcw5u3y6XHWSTDZ1zlzsojmeiDnty3oR1b RKa/atbHdITseQRfBzMwvv+BZBXL7DpE2ccT7NOpRbdNpWhe3GbOP7wmvc/r2jqCpEZUJE4M xex9Y5t55DAiZEh2vddmPQUbSLreP540IHces1u2MkuxJXty487GMz/OZ3Ar3XumN+TrSAtD MRPkF6o2FjAMYODNaLbg6JkOr/t26KfJ75jl7wAX8AEn8AKviUgwcORtwfVLcK5RWZk9OeX4 vYBj4APESRssqYcu6QCXbZC+XlErOOgFKpn28AMm8KDtbsXSXijOt6ZjJdn2YXiLbSacNhiP t7Q1r//OzNflvBcCuRXHrg5XLTu0R4sjqoUjXgH/I+9uJB9bu69+cZYCbjLqx2imld/GrhN/ PeV9XelrzlxDbuuaux+JTMSp9W3GI69h0vEd33LsPW5znNvfHcUe+uXTXrwzR+pi/uiJ5vEw v65WWcbq5l1gQuVv+evtxe4Hn2AUr92gJKfho0J1mUkoVr7ps3EldOdfBJT6Thmcusw/sKg1 X/AGfyhR/wxTJ/VUV/VVZ3WDDQgAOw== ------=_NextPart_000_000A_01C6AEDD.7EFA0DC0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Jul 23 23:01:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4qh4-0000gE-Hq for capwap-archive@lists.ietf.org; Sun, 23 Jul 2006 23:01:18 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4qh2-0001WL-3G for capwap-archive@lists.ietf.org; Sun, 23 Jul 2006 23:01:18 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 54D7439805E for ; Sun, 23 Jul 2006 20:01:15 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8173143004F for ; Sun, 23 Jul 2006 20:00:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5AE141448030 for ; Sun, 23 Jul 2006 20:00:13 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 28D3F144800F for ; Sun, 23 Jul 2006 20:00:08 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k6O306dl019888; Mon, 24 Jul 2006 12:00:06 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k6O306f20367; Mon, 24 Jul 2006 12:00:06 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with ESMTP id k6O303q13645; Mon, 24 Jul 2006 12:00:03 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Jul 2006 11:02:20 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD01073700@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Thread-Index: Acaq1wHFltx/sTmjR9+5w4E1E3S4UAAmXkXAABUulxAAEup7QAAXvGNgABojo0AAfTTMQA== From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , "Michael Montemurro" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1891397294==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b8ecb2e47617fa0460f15b61ac4eb17a This is a multi-part message in MIME format. --===============1891397294== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AECD.3E21EBA0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6AECD.3E21EBA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The current version of the protocol does not support 5.1.10. There is no means of coordinating KeyRSC values maintained by the WTP and EAPoL frame generation by the AC.=20 =20 Saravanan =20 =20 =20 =20 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Friday, July 21, 2006 11:15 PM To: Saravanan Govindan; Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 The protocol today addresses requirement defined in Section 5.1.10 =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Thursday, July 20, 2006 10:44 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The requirement from Section 5.1.10 of RFC 4564 states that the "protocol MUST allow for the exchange of key information when authenticator and encryption roles are located in distinct entities."=20 =20 The current protocol draft needs to include operations to support key exchange in such designs. And the feature we've been discussing directly addresses this need.=20 =20 Saravanan =20 =20 =20 =20 =20 =09 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, July 20, 2006 11:27 PM To: Saravanan Govindan; Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 I'd like to understand how you've interpreted this feature as being "mandatory". The current spec supports 802.11i, in both modes of operation that we've agreed to, which is Split and Local MAC. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, July 19, 2006 11:37 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations I'd like to clarify that this is indeed a "mandatory" objective and needs to be integral to CAPWAP. Based on the exchanges so far, I think support for this feature can be easily incorporated in to the protocol.=20 =20 We know the protocol needs this (from the requirement) and we know how to do it (from the proposals), so let's just do it and move forward.=20 =20 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Thursday, July 20, 2006 6:30 AM To: Michael Montemurro; Saravanan Govindan Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 My personal feeling is that this should be considered a "nice to have", and therefore show up in the "wish" tracker category. Given all of the work we have ahead of us, I don't believe there is an urgent need to support this mode of operation, as the current protocol achieves our objectives. So waiting for a future version of the protocol would be my suggestion. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Tuesday, July 18, 2006 6:59 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, =20 I've given some additional thought to your requirements and I believe it would require additional text as well as an additional negotiation between the WTP and the AC. =20 We could separate the RSNA key management functions from the "classical" IEEE 802.1X authenticator functions and allow the WTP and AC negotiate where these functions reside: =20 The IEEE 802.1X authenticator functions would include the PMK derivation. The PMK would be passed to the WTP upon successful completion of the IEEE 802.1X authentication. =20 The RSNA key management functions would include the 4-way handshake and the generation of GTK updates. =20 I think this is a cleaner mechanism to address your requirements. =20 Does this make sense to you?=20 =20 Cheers, =20 Mike =09 =09 =20 On 7/6/06, Saravanan Govindan wrote:=20 Hi Mike, =20 Thank you for the note.=20 =09 I may not have been clear with my previous post. My request is to have EAPoL frames generated at the AC alone - not at the WTP.=20 =20 My request is for designs where EAPoL frames are generated at the AC and in those where the KeyRSC is maintained in the WTP. These designs were highlighted in the Architecture Taxonomy.=20 =20 Specifically, I suggest that a CAPWAP message (it may be Add WLAN or Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. This EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of group key handshake) would have its KeyRSC field unassigned. Then when the WTP receives this message, it fills in the right value of the KeyRSC, updates the EAPoL frame and then transmit it to the wireless station.=20 =20 I hope this clarifies my suggestion. =09 Cheers, =09 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com]=20 Sent: Tuesday, July 04, 2006 9:47 PM To: Saravanan Govindan Cc: capwap =09 Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 So, you would like to request that the WTP generate EAPoL-Key frames for the 4-way handshake and the GTK update? =20 The current draft assumes that all EAPoL-Key frames are generated at the AC. =20 Based on the following assumptions: 1) This feature would be for local-MAC only. 2) The 4-way handshake and the GTK handshake would originate from the same location. =20 This would then require: 1) Negotiation between the WTP and the AC on where the 4-way handshake and GTK updates are generated.=20 2) A modification to the updateWLAN message element to include the PMK when a STA successfully associates. =20 I've captured this as issue 199. =09 =20 On 7/3/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com > wrote:=20 Hi Mike, =20 I had a chance to review the new draft.=20 =20 With regard to Issue 43, my understanding is that updates were made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN message element now allows the AC to send sequence counter values to the WTP. So now, CAPWAP can support designs where the KeyRSC is maintained by the AC.=20 =20 My initial concern was with supporting designs where the KeyRSC is maintained by the WTP. This is particularly important to manage the 4-Way and Group-key handshakes.=20 =20 With this in mind, I think the protocol still requires support for designs where the KeyRSC is maintained by the WTP. Based on the current draft, this support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames would have unassigned fields for KeyRSC (since the value is maintained by the WTP). =20 I am also open to any alternatives to support this.=20 =20 Cheers, =09 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com]=20 Sent: Tuesday, June 20, 2006 10:01 PM=20 To: Saravanan Govindan Cc: Bob O'Hara (boohara); capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 I've updated section 11.3 to deal with the GTK exchange and the handling of the KeyRSC in draft -02 to address your comments. I also provided a mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message element as part of the Group Key exchange.=20 =20 We're finalizing the -02 draft this week and you should be able to look at it when we post it later this week. =20 Cheers, =20 Mike =20 =20 ------_=_NextPart_001_01C6AECD.3E21EBA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    The current version of the protocol does not support = 5.1.10. There is no means of coordinating KeyRSC values maintained by the WTP = and EAPoL frame generation by the AC.

     

    Saravanan

     

     

     

     

    From: Pat = Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
    Sent: Friday, July 21, = 2006 11:15 PM
    To: Saravanan Govindan; Michael Montemurro
    Cc: capwap
    Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

     

    The protocol today addresses = requirement defined in Section 5.1.10

     

    Pat Calhoun
    CTO, Wireless Networking Business Unit
    Cisco Systems

     

     

    From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
    Sent: Thursday, July 20, = 2006 10:44 PM
    To: Pat Calhoun = (pacalhou); Michael Montemurro
    Cc: capwap
    Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

    The requirement from =
Section 5.1.10 of RFC 4564 states that the “protocol MUST allow =
for the exchange of key =
information when authenticator and encryption roles are located in =
distinct entities.” =

     
    The current protocol draft =
needs to include operations to support key exchange in such designs. And =
the feature we’ve been discussing directly addresses this need. =

     
    Saravanan<=
/font>
     
     
     

     

     

    From: Pat = Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
    Sent: Thursday, July 20, = 2006 11:27 PM
    To: Saravanan Govindan; Michael Montemurro
    Cc: capwap
    Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

     

    I'd like to understand how you've interpreted this feature as being "mandatory". The current = spec supports 802.11i, in both modes of operation that we've agreed to, which = is Split and Local = MAC.

     

    Pat Calhoun
    CTO, Wireless Networking Business Unit
    Cisco Systems

     

     

    From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
    Sent: Wednesday, July 19, = 2006 11:37 PM
    To: Pat Calhoun = (pacalhou); Michael Montemurro
    Cc: capwap
    Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

    I’d like to clarify that this is indeed a “mandatory” objective and needs to be integral to CAPWAP. = Based on the exchanges so far, I think support for this feature can be easily incorporated in to the protocol.

     

    We know the protocol needs this (from the = requirement) and we know how to do it (from the proposals), so let’s just do it and = move forward.

     

    Saravanan

     

     

     

     

    From: Pat = Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
    Sent: Thursday, July 20, = 2006 6:30 AM
    To: Michael Montemurro; = Saravanan Govindan
    Cc: capwap
    Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

     

    My personal feeling is that this = should be considered a "nice to have", and therefore show up in the "wish" tracker category. Given all of the work we have ahead = of us, I don't believe there is an urgent need to support this mode of operation, = as the current protocol achieves our objectives. So waiting for a future = version of the protocol would be my suggestion.

     

    Pat Calhoun
    CTO, Wireless Networking Business Unit
    Cisco Systems

     

     

    From: Michael Montemurro [mailto:montemurro.michael@gmail.com]
    Sent: Tuesday, July 18, = 2006 6:59 PM
    To: Saravanan Govindan
    Cc: capwap
    Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

    Saravanan,

     

    I've given some additional thought to your requirements and I = believe it would require additional text as well as an additional negotiation = between the WTP and the AC.

     

    We could separate the RSNA key management functions = from the "classical" IEEE 802.1X authenticator functions and allow the = WTP and AC negotiate where these functions reside:

     

    The IEEE 802.1X authenticator functions would include the PMK derivation. The PMK would be passed to the WTP upon successful = completion of the IEEE 802.1X authentication.

     

    The RSNA key management functions would include the 4-way = handshake and the generation of GTK updates.

     

    I think this is a cleaner mechanism to address your = requirements.

     

    Does this make sense to you?

     

    Cheers,

     

    Mike



     

    On 7/6/06, Saravanan = Govindan <Saravanan.Govindan@sg= .panasonic.com> wrote:

    Hi Mike,

     

    Thank you for the note.


    I may not have been clear with my previous post. My request is to have = EAPoL frames generated at the AC alone – not at the WTP. =

     

    My request is for designs where EAPoL frames are generated at the AC and in = those where the KeyRSC is maintained in the WTP. These designs were = highlighted in the Architecture Taxonomy.

     

    Specifically, I suggest that a CAPWAP message (it may be Add WLAN or Update WLAN) be = able to carry an EAPoL frame from the AC to the WTP. This EAPoL frame (for = Message 3 of 4-way handshake or for Message 1 of group key handshake) would have its = KeyRSC field unassigned. Then when the WTP receives this message, it fills in = the right value of the KeyRSC, updates the EAPoL frame and then transmit it = to the wireless station.

     

    I hope this clarifies my suggestion.


    Cheers,


    Saravanan

     

     

     

     

    From: Michael Montemurro = [mailto: montemurro.michael@gmail.co= m]
    Sent: Tuesday, July 04, = 2006 9:47 PM
    To: Saravanan Govindan
    Cc: = capwap


    Subject: = Re: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

     

    Saravanan,

     

    So, you would like to request that the WTP generate EAPoL-Key frames for the = 4-way handshake and the GTK update?

     

    The current draft assumes that all EAPoL-Key frames are generated at the = AC.

     

    Based on the following assumptions:

    1) This feature would be for local-MAC only.

    2) The 4-way handshake and the GTK handshake would originate from the same = location.

     

    This would then require:

    1) Negotiation between the WTP and the AC on where the 4-way handshake and = GTK updates are generated.

    2) A modification to the updateWLAN message element to include the PMK = when a STA successfully associates.

     

    I've captured this as issue 199.

     

    On 7/3/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com> wrote: =

    Hi Mike,

     

    I had a chance to review the new draft.

     

    With regard to Issue 43, my understanding is that updates were made in = Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN = message element now allows the AC to send sequence counter values to the WTP. So = now, CAPWAP can support designs where the KeyRSC is maintained by the AC. =

     

    My initial concern was with supporting designs where the KeyRSC is = maintained by the WTP. This is particularly important to manage the 4-Way and = Group-key handshakes.

     

    With this in mind, I think the protocol still requires support for designs = where the KeyRSC is maintained by the WTP. Based on the current draft, this = support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way = handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames = would have unassigned fields for KeyRSC (since the value is maintained by the = WTP).

     

    I am also open to any alternatives to support this. =

     

    Cheers,


    Saravanan

     

     

     

     

    From: Michael Montemurro = [mailto: montemurro.michael@gmail.co= m]
    Sent: Tuesday, June 20, = 2006 10:01 PM
    To: Saravanan Govindan
    Cc: Bob O'Hara (boohara); = capwap
    Subject: Re: [Capwap] = Clarification of Issue 43: IEEE 802.11i Considerations

     

    Saravanan,

     

    I've updated section 11.3 to deal with the GTK exchange and the handling of = the KeyRSC in draft -02 to address your comments. I also provided a = mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message = element as part of the Group Key exchange.

     

    We're finalizing the -02 draft this week and you should be able to look at it = when we post it later this week.

     

    Cheers,

     

    Mike

     

     

    ------_=_NextPart_001_01C6AECD.3E21EBA0-- --===============1891397294== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1891397294==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 24 00:13:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4roo-0001rS-Ik for capwap-archive@lists.ietf.org; Mon, 24 Jul 2006 00:13:22 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4rom-0001py-7l for capwap-archive@lists.ietf.org; Mon, 24 Jul 2006 00:13:22 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 324084312AF for ; Sun, 23 Jul 2006 21:13:16 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 078A943004F for ; Sun, 23 Jul 2006 21:12:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EB1E31448011 for ; Sun, 23 Jul 2006 21:12:14 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4DE5E144800F for ; Sun, 23 Jul 2006 21:12:12 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k6O4CCbK018371 for ; Sun, 23 Jul 2006 21:12:12 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k6O4CBgE018367 for ; Sun, 23 Jul 2006 21:12:11 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Sun, 23 Jul 2006 21:12:11 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [Capwap] Ver 4 or CAPWAP packet syntax X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d70738b58489ee14fb507f541b784688 HI, Here is an update of my proposal for CAPWAP packet formats: Proposal for CAPWAP Packet Format (24-jul-2006) -------------------------------- Updated from 24-jun-2006: 1) Removed the CAPWAP pkt header and moved the fields into the fragmentation control header. 2) Added note about use of UDP ports for DLTS and non-DTLS messages 3) Updated example section to match change in fragmentation header field 4) Added an example to show fragmentation and retries together 5) Added note about DLTS processing of duplicates Updates from 22-jun-2006: 1) Cleaned up terminology definitions. 1) Added clarification about initial values for the "CAPWAP PDU ID" and "MSG ID" fields 2) Added timing diagram showing no fragmentation and fragmentation 3) Added timing diagram showing CAPWAP control message drops and retries 4) Put back in MSG Seq ID into the Control header, but re-labeled as retry num, and reordered fields. Updates from 8-jun-2006: 1) Made to look closer to CAPWAP-02 2) Added CAPWAP Fragmentation Header so that both control and data supported fragmentation 3) Updated descriptions of fields of packets 4) Changed how fragmentation is indicated. 5) Modified so that the Data (or Control) header is on in the first fragment of a CAPWAP PDU 6) Cleaned up Data Header, now that fragmentation is in a separate header and made the remaining fields match those in CAPWAP-02 7) Updated the Control Header so that it closely resembles CAPWAP-02, except for 'F' field. Updates from 7-jun-2006: 1) changed diagrams to make DTLS experts happier 2) renamed "CAPWAP MUX Hdr" to "CAPWAP Pkt Hdr", and made it 2 octets long instead of 1 octet 3) made the packet types start at 1 instead of zero 4) fixed a few typos 5) changed the formulas for the message type value and message element type value to multiply the IANA enterprise number by 4096 (shift left by 12) instead of 256 (shift left by 8). This means the the enterprise value must be encoded in 20 bits, and the specific type value in 12 bits. I checked the assignment of Enterprise numbers, and there are now approximately 16K, and also checked the OUI assignments and there are approximately 51K. Thus, 20 bits (1M) should be enough! --------------------------------- CAPWAP Packet formats: NOTE: This format of CAPWAP messages assumes that DTLS traffic is sent to one well known UDP port on the AC, and CAPWAP messages not using DTLS encapsulation are sent to another well known UDP port. The formats support both data and control sent to the same UDP port or use of different UDP ports for data and control. CAPWAP Unprotected Data Packet: +---------------------[--------]----------+ | IP | UDP | CAPWAP | CAPWAP | Wireless | | Hdr | Hdr | Frag | Data | Payload | | | | Ctrl | Hdr | Frag | +---------------------[--------]----------+ only in first fragment CAPWAP DTLS Protected Data Packet: +----------------------------[---------]--------------------+ | IP | UDP | DTLS | CAPWAP | CAPWAP | Wireless | DTLS | | Hdr | Hdr | Hdr | Frag | Data | Payload | Trailer | | | | | Ctrl | Hdr | Frag | | +----------------------------[---------]--------------------+ only in first fragment \--integrity checked----------------/ \--encrypted--------------------------/ CAPWAP Unprotected Control Packet: +---------------------[---------]----------+ | IP | UDP | CAPWAP | CAPWAP | Message | | Hdr | Hdr | Frag | Control | Elements | | | | Ctrl | Hdr | Frag | +---------------------[---------]----------+ only in first fragment CAPWAP DTLS Protected Control Packet: +---------------------------[---------]--------------------+ | IP | UDP | DTLS | CAPWAP | CAPWAP | Message | DTLS | | Hdr | Hdr | Hdr | Frag | Control | Elements | Trailer | | | | | Ctrl | Hdr | Frag | | +---------------------------[---------]--------------------+ only in first fragment \--integrity checked---------------/ \--encrypted--------------------------/ UDP: All CAPWAP packets are encapsulated within UDP. CAPWAP PDU: CAPWAP consists of both control and data streams. A CAPWAP PDU is either a CAPWAP control PDU or a CAPWAP data PDU. CAPWAP Control PDU: A CAPWAP control PDU encapsulates a control message, which is a control header and its message elements. CAPWAP Data PDU: A CAPWAP data PDU encapsulates a data message, which is a data header and wireless payload. CAPWAP Fragmentation Control Header: Used for fragmentation of CAPWAP PDUs. A CAPWAP PDU that will not fit in one UDP packet will be fragmented into multiple CAPWAP packets. It also indicates if the CAPWAP PDU is control or data. CAPWAP Data Header: This header is used for CAPWAP data PDUs. If a CAPWAP data PDU is fragmented, then the CAPWAP Data Header is in only the first fragment in the group of fragments constructing the CAPWAP data PDU. Wireless Payload: The actual payload from or to wireless devices. The format may be 802.3 Ethernet II, or native wireless transport specific encoding. DTLS Header: Protected CAPWAP packets use the DTLS protocol to provide message integrity and encryption services. DTLS Trailer: A field used to provide protection service for security of CAPWAP messages. CAPWAP Control Header: The CAPWAP protocol includes a signalling component, known as the CAPWAP control protocol. All CAPWAP control PDUs include a Control Header. If a CAPWAP control PDU is fragmented, then the CAPWAP Control Header is in only the first fragment in the group of fragments constructing the CAPWAP control PDU. Message Elements: A CAPWAP Control PDU includes zero, one, or more message elements, which are found immediately following the control header. These message elements are in a type, length, value format. CAPWAP Fragmentation Control Header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ver|T|M| CAPWAP PDU ID | Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ver: a 2 bit field that contains the version of the CAPWAP protocol syntax used for the packet. The value is zero for this draft. T: The PDU type. The value '1' indicates a control PDU and the value '0' indicates a data PDU. (Note: if the data and control streams are sent to different UDP ports, then PDUs sent to the inappropriate UDP port is dropped.) M: The More 'M' bit indicates whether there are more fragment packets needed to be combined to reassemble a complete CAPWAP PDU. When this bit is 1, there are more fragment packets. When this bit is 0, there are no more fragments and this packet completes the CAPWAP PDU. CAPWAP PDU ID: A 15-bit field whose value is assigned to each CAPWAP PDU. The CAPWAP PDU ID space is managed independently for every WTP/AC pair, for each end (an AC or WTP), and for each CAPWAP stream (data or control). For example, if AC #1 communicates with WTP #1 and WTP #2, there will be the following independent CAPWAP PDU IDs: WTP #1: ID1 for control going to AC #1 ID2 for data going to AC #1 WTP #2: ID3 for control going to AC #1 ID4 for data going to AC #1 AC #1: ID5 for control going to WTP #1 ID6 for data going to WTP #1 ID7 for control going to WTP #2 ID8 for data going to WTP #2 The value for each CAPWAP PDU ID is incremented with each new CAPWAP PDU sent whether or not the PDU is fragmented. (All fragments of the same CAPWAP PDU have the same value for CAPWAP PDU ID.) The value wraps to zero after the maximum value has been used to identify a CAPWAP PDU. When a new session is established or when a WTP or AC starts, the initial value is a randomly generated number. Fragment Offset: A 13 bit field that indicates where in the CAPWAP PDU will this fragment belong during re-assembly. This field should always have a valid value. For the first or only packet of a CAPWAP PDU, the value must be zero. The fragment offset is measured in units of 8 octets (64 bits). This provides a maximum size of a CAPWAP PDU to be 16 bits (which is 65536 octets). Note the CAPWAP protocol does not allow for overlapping fragments. For instance, it would be an error if the first fragment was 1000 octets in length, and the second fragment's offset was 800. To be valid (when the length of the first fragment is 1000, the second fragment MUST have an offset of 1000. (DISCUSS: need to have a timer that is associated with fragmentation to toss all of the fragments if they have not been combined in the allocated time.) (DISCUSS: the units of 8 octets was copied from earlier CAPWAP drafts. It seems that this could be changed to a much larger unit, such as 64 or 256 octets. When so, this field could be changed from 13 bits to 10 bits or 8 bits (respectively), and the newly available bits reserved for future use.) CAPWAP Data Header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RID | HLEN | WBID |T|W|M| Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Radio MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Wireless Specific Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RID: A 5 bit field which contains the Radio ID for this CAPWAP data PDU. WTPs with multiple radios but a single MAC Address range (for BSSIDs) use this field to indicate which radio is associated with the packet. HLEN: A 5 bit field specifying the length of the CAPWAP data header header in 4 octet words (Similar to IP header length). This length includes the optional headers. WBID: A 5 bit field which is the wireless binding identifier. The identifier will indicate the type of wireless packet type associated with the radio. The following values are defined: 1 - IEEE 802.11 T: The Type 'T' bit indicates the format of the frame being transported in the payload. When this bit is set to one (1), the payload has the native frame format indicated by the WBID field. When this bit is zero (0) the payload is an IEEE 802.3 frame. W: The 'W' bit is used to specify whether the optional "Wireless Specific Information" field is present in the header. A value of one (1) is used to represent the fact that the field is present. M: The 'M' bit is used to specify whether the optional "Radio MAC Address" field is present in the header. A value of one (1) is used to represent the fact that the field is present. Res: The bits are reserved and must be zero. Radio MAC Address: This optional field contains the BSSID of the radio receiving the packet. This is used in packets sent from the WTP to the AC, when the native wireless frame format is converted to 802.3 by the WTP. This field is only present if the 'M' bit is set. Given the HLEN field requires the header size to be a multiple of 4 octets, this field MUST be padded with zeroes (0x00) if it is not 4 octet aligned. The field has the format: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Length | MAC Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Length: The number of octets in the MAC Address field. The length field is present since new IEEE technologies (e.g., 802.16) are now using 64 bits (8 octet) MAC addresses. MAC Address: The BSSID of the receiving radio. Wireless Specific Information: This optional field contains technology specific information that may be used to carry per packet wireless information. This field is only present if the 'W' bit is set. Given the HLEN field assumes 4 octet alignment, this field MUST be padded with zeroes (0x00) if it is not 4 octet aligned. The field has the format: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Wireless ID | Length | Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Wireless ID: The wireless binding identifier. The following values are defined: 1 - : IEEE 802.11 Length: The length of the data field Data: Wireless specific information, whose details are defined in the technology specific bindings sections. For 802.11, when sent from WTP to AC, the data has the following format: IEEE 802.11 Frame Info: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSSI | SNR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RSSI: RSSI is a signed, 8-bit value. It is the received signal strength indication, in dBm. SNR: SNR is a signed, 8-bit value. It is the signal to noise ratio of the received IEEE 802.11 frame, in dB. Data Rate: The data rate field is a 16-bit unsigned integer value. The contents of the field is set to 1/10th of the data rate of the packet received by the WTP. For instance, a packet received at 5.5Mbps would be set to 55, while 11Mbps would be set to 110. For data sent from the AC to the WTP, the data has the following format: Destination WLANs: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit vector indicates the WLAN ID(s) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be set to '1'. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Wireless Payload: The format of the wireless payload depends on the encapsulation mode. There are two formats defined, which are: 802.3 Frame - this is the standard IEEE 802.3 Ethernet II frame (DISCUSS: this needs to be confirmed) 802.11 native frame - DISCUSS: finish this CAPWAP Control Header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg ID | Retry#|F| Res | Length of Msg Elements | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type: This field identifies the function of the CAPWAP control message. The Message Type field is comprised of an IANA Enterprise Number and an enterprise specific message type number. The first 20 bits is the enterprise number in network byte order, with zero being used for CAPWAP generic message types and the IEEE 802.11 IANA assigned enterprise number 13277 being used for IEEE 802.11 technology specific message types. The last 12 bits is the enterprise specific message type number, which has a range from 0 to 4095. The value of the message type field can be expressed as: Message type value = IANA Enterprise Number * 4096 + enterprise specific message type number Msg ID: The message ID field is used by the CAPWAP control application to match responses (or acknowledgements) with requests (or reports). The value must be monotonically incremented for each unique request (or report). After the maximum value is reached, the value wraps back to zero. The paired response (or acknowledgement) returns the value from the request (or report). Note the size is 8-bits, and thus a maximum of 255 CAPWAP operations can be currently outstanding. The message ID space is managed independently for every WTP/AC pair, and for each end (an AC or WTP). For example, if AC#1 communicates with WTP #1 and WTP #2, there will be the following independent Message IDs: WTP #1: MSG ID1 for requests (and reports) going to AC #1 WTP #2: MSG ID2 for requests (and reports) going to AC #1 AC #1: MSG ID3 for requests going to WTP #1 MSG ID4 for requests going to WTP #2 When a new session is established, the initial value is a randomly generated number. Retry#: The retry number field starts at zero and is incremented for each message with the same value of message ID. After the maximum value is reached, the value wraps back to zero. The paired response (or acknowledgement) returns the value from the request (or report). Note the size is 4-bits, and thus a maximum of 16 retries can be be currently outstanding. This field is used to match a request (or report) with its paired response (or acknowledgement) so that accurate round trip operation time can be determined. (DISCUSS: maybe put back here the text about how this works. The examples of operation retries should help.) F: The 'F' bit field indicates if the message is the first message in a message pair. A value of "1" means first, and "0" means second in the pair. There are two types of message pairs, which are: 1) a request and response 2) a report and acknowledgement. Thus, the first is a request or report message (with the 'F' field set to "1"), and the second is a response or acknowledgement (with the 'F' field set to "0"). Note, both a request and response (or report and acknowledgement) of a operation type use the same value for message type. The 'F' bit is used to indicate which is which. This allows new message types to be added that can be processed without knowing the meaning of the message type. That is, when an unknown request message type is received, the response is the same message type with a message element indicating that the message type is not supported. Res: The bits are reserved and must be zero. Length of Message Elements: This field indicates in octets the length of the message elements field, which contains zero, one, or more message elements. The field is 16 bits wide, and thus the maximum size that can be specified 64K. However, the maximum size of a CAPWAP control PDU is 64K, and thus the max length is 64K minus the size of the CAPWAP control header, or 64K - 8, or 65528. Message Elements: The "message elements" field contains, zero, one, or more message element field, which has the following format: Message Element: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Element Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Value .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Message Element Type: This field identifies a message element of a CAPWAP control message. The Message Element Type field is comprised of an IANA Enterprise Number and an enterprise specific message element type number. The first 20 bits is the enterprise number in network byte order, with zero being used for CAPWAP generic message types and the IEEE 802.11 IANA assigned enterprise number 13277 being used for IEEE 802.11 technology specific message element types. The 12 bits is the enterprise specific message element type number, which has a range from 0 to 4095. The value of the message element type field can be expressed as: Message element type value = IANA Enterprise Number * 4096 + enterprise specific message element type number ------------------------------------------------ Use of the CAPWAP Fragmentation Control Header Example of a Nonfragmented CAPWAP PDU For both data and control CAPWAP packets, CAPWAP Fragment Control Header has the following content: first, compute next CAPWAP_PDU_ID, which is CAPWAP_PDU_ID = (CAPWAP_PDU_ID + 1) & 0x07fff; 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0|T|M| CAPWAP_PDU_ID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Example of Fragmented CAPWAP PDUs 1) Here is an example of a CAPWAP data PDU where the length of the CAPWAP data header and wireless payload will cause a single CAPWAP data packet to be greater than the max IP packet size for the path. Assume that the size of the CAPWAP data PDU is 1560 octets, which needs to be fragmented into a fragments of 1400 and 160 octets. The first fragment would have the following CAPWAP fragment control header, and be followed by a CAPWAP data header and part of the wireless payload and would look like: first, compute next CAPWAP_PDU_ID, which is CAPWAP_PDU_ID = (CAPWAP_PDU_ID + 1) & 0x07fff; 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0|0|1| CAPWAP_PDU_ID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The second fragment would have the following CAPWAP fragment control header, and be followed by the remaining portion of the wireless payload and would look like: (Use the same value of CAPWAP_PDU_ID) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0|0|0| CAPWAP_PDU_ID | (1400/8) = 175 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2) Here is an example of a CAPWAP control PDU where the length of the CAPWAP control header and message elements will cause a single CAPWAP control packet to be greater than the max IP packet size for the path. Assume that the size of the CAPWAP control PDU is 1560 octets, which needs to be fragmented into a fragments of 1400 and 160 octets. The first fragment would have the following CAPWAP fragment control header, and be followed by a CAPWAP control header and part of the message elements and would look like: first, compute next CAPWAP_PDU_ID, which is CAPWAP_PDU_ID = (CAPWAP_PDU_ID + 1) & 0x0ffff; 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0|1|1| CAPWAP_PDU_ID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The second fragment would have the following CAPWAP fragment control header, and be followed by the remaining portion of the wireless payload and would look like: (Use the same value of CAPWAP_PDU_ID) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0|1|0| CAPWAP_PDU_ID | (1400/8) = 175 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3) Example timing diagrams with fragmentation: Abbreviations: P_ID - PDU ID F_OFF - Fragment offset M - (0 - last, 1 - more packets in PDU) (M=1,P_ID=56,F_OFF=0) (M=1,P_ID=56,F_OFF=0) WTP----------------------->|----------------------->AC - saves frag | (M=0,P_ID=56,F_OFF=175) | (M=0,P_ID=56,F_OFF=175) ----------------------->|----------------------->AC - combines | | and processes | | (M=0,P_ID=75,F_OFF=0) | (M=0,P_ID=75,F_OFF=0) | <------------------------|<------------------------ | ------------------------------------------------ Use of the "Msg ID" and "Retry#" Fields for Retries Only the control path has message retries. Since control operations are not idempotent (that is, are not guaranteed to return the same result when redone), operation results (the response or acknowledgement) to a request or report must be cached and returned if a repeat of the operation occurs. A repeat occurs when 1) the request (or report) is not received (however, the receiver does not know that the operation is being repeated) 2) the response (or acknowledgement) is not received within the expected operation round trip time. 3) the request (or report) is duplicated by the network (this only occurs when the control operation is not protected by DTLS) NOTE: Retries cannot be done be resending saved UDP packets, since DTLS discards duplicates. Thus, when each retry requires generation of a new DTLS message (which means that DLTS must yet again perform the hash for the message integrity check, and the encryption of the CAPWAP PDU)! Here are timing diagrams for 4 cases: Abbreviations: P_ID - PDU ID M_ID - MSG ID R - Retry number 0) No timeout/replay/duplication: (P_ID=56, M_ID=23, R=0) (M_ID=23, R=0) WTP----------------------->|----------------------->AC - process | | and cache (M_ID=23, R=0) | (P_ID=75,M_ID=23,R=0) | for M_ID=23 <------------------------|<------------------------ and R=0 | NOTEs: 1) AC and WTP have different spaces for P_ID. It is used only for CAPWAP PDU fragmentation reassembly. 2) The P_ID is always incremented for each CAPWAP PDU, even for retries 3) the M_ID from a request (or report) is echoed in a paired response (or acknowledgement) 4) each originator of an operation has an independent M_ID number space 1) message never received, so resent: (P_ID=56, M_ID=23, R=0) WTP----------------------->|-->X AC | | |timeout | V (P_ID=57, M_ID=23, R=1) | retry---------------------->|----------------------->AC - process | | and cache (M_ID=23, R=1) | (P_ID=75,M_ID=23, R=1) | for M_ID=23 <------------------------|<------------------------ and R=1 NOTEs: 1) the M_ID is not incremented on retries 2) the R always starts at zero for each M_ID and is incremented on retries 2a) message response (or acknowledgement) never received, so message resent: (P_ID=56, M_ID=23, R=0) (M_ID=23, R=0) WTP----------------------->|----------------------->AC - process | | | and cache | | (P_ID=75,M_ID=23,R=0) | for M_ID=23 | X<--|<------------------------ and R=0 |timeout | V (P_ID=57, M_ID=23, R=1) | (M_ID=23, R=1) retry---------------------->|----------------------->AC - find in | | cache for (M_ID=23, R=1) | (P_ID=76,M_ID=23,R=1) | M_ID=23, <------------------------|<------------------------ update R=1 NOTEs: 1) only the M_ID is searched in the cache for a match (the R is saved, but not used in search) 2) the R from the request message is returned in the response message 3) the R is updated in the cache 2b) message response (or acknowledgement) not received within the current computed value for round trip operation time, so a message resent. However, original response received before response to retry. (P_ID=56, M_ID=23, R=0) (M_ID=23, R=0) WTP----------------------->|----------------------->AC - process | | | and cache | | (P_ID=75,M_ID=23,R=0) | for M_ID=23 | |/------------------------ and R=0 |timeout || V (P_ID=57, M_ID=23, R=1) || (M_ID=23, R=1) retry---------------------->|+---------------------->AC - find in || | cache for (M_ID=23, R=0) || | M_ID=23, <------------------------|/ | update R=1 update RTOT(drop) | | | | (M_ID=23, R=1) | (P_ID=76,M_ID=23,R=1) | <------------------------|<------------------------ update RTOT(process) NOTEs: 1) without the R field, cannot determine if the first received response was from the first time the request was made, or from a retry. Without knowing which, cannot accurately update the round trip operational time. 2) it is possible to process the first response and not drop it, but if so, must remember the time when sent each retry. If max retries not too many, then not much of a cost. a match (the R is not saved or searched) 3) message request (or report) is duplicated by the network: (P_ID=56, M_ID=23, R=0) (M_ID=23, R=0) WTP----------------------->|----------------------->AC - process \ | | and cache (M_ID=23, R=0) \ | (P_ID=75,M_ID=23,R=0) | for M_ID=23 <------------------+------|<------------------------ and R=0 \ | \ | (M_ID=23, R=0) Dup \-->|+---------------->X | DTLS determines it | is a dup from DTLS | header and drops. | AC process doesn't | get "application data" NOTE: 1) The DTLS determines that message is a duplicate and drops it. For broken DTLS stacks that return the application data: a) the R field in the duplicated message can be used by the AC to determine if the request is a duplicate. b) if both a response drop (or delay) and a duplicate occurs the R may be less than the R in the cache. If so, the message is a very delayed duplicate and can be dropped. ----- the end Enjoy, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 24 11:40:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G52XM-000278-Qe for capwap-archive@lists.ietf.org; Mon, 24 Jul 2006 11:40:04 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G52XK-0005dP-5R for capwap-archive@lists.ietf.org; Mon, 24 Jul 2006 11:40:04 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3248C398085 for ; Mon, 24 Jul 2006 08:40:01 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E3922430054 for ; Mon, 24 Jul 2006 08:38:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CAA8C144801B for ; Mon, 24 Jul 2006 08:38:52 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by hermes.tigertech.net (Postfix) with ESMTP id 0812B144800C for ; Mon, 24 Jul 2006 08:38:47 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 24 Jul 2006 08:38:46 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6OFckE0018495 for ; Mon, 24 Jul 2006 08:38:46 -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 k6OFck2D024987 for ; Mon, 24 Jul 2006 08:38:46 -0700 (PDT) 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, 24 Jul 2006 08:38:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Jul 2006 08:38:45 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC01CC59D8@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations thread-index: Acaq1wHFltx/sTmjR9+5w4E1E3S4UAAmXkXAABUulxAAEup7QAAXvGNgABojo0AAfTTMQAAafChA From: "Bob O'Hara (boohara)" To: "capwap" X-OriginalArrivalTime: 24 Jul 2006 15:38:46.0404 (UTC) FILETIME=[40556C40:01C6AF37] Authentication-Results: sj-dkim-4.cisco.com; header.From=boohara@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1548979271==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5699cb8cf93ec71ee0af33243d6734ce This is a multi-part message in MIME format. --===============1548979271== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AF37.403FC7C4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6AF37.403FC7C4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is no need to coordinate such values between the AC and WTP. Please read 802.11i to understand how the key exchange protocol operates. -Bob =20 =20 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Sunday, July 23, 2006 8:02 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The current version of the protocol does not support 5.1.10. There is no means of coordinating KeyRSC values maintained by the WTP and EAPoL frame generation by the AC.=20 =20 Saravanan =20 =20 =20 =20 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Friday, July 21, 2006 11:15 PM To: Saravanan Govindan; Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 The protocol today addresses requirement defined in Section 5.1.10 =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Thursday, July 20, 2006 10:44 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The requirement from Section 5.1.10 of RFC 4564 states that the "protocol MUST allow for the exchange of key information when authenticator and encryption roles are located in distinct entities."=20 =20 The current protocol draft needs to include operations to support key exchange in such designs. And the feature we've been discussing directly addresses this need.=20 =20 Saravanan =20 =20 =20 =20 =20 =09 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, July 20, 2006 11:27 PM To: Saravanan Govindan; Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 I'd like to understand how you've interpreted this feature as being "mandatory". The current spec supports 802.11i, in both modes of operation that we've agreed to, which is Split and Local MAC. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, July 19, 2006 11:37 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations I'd like to clarify that this is indeed a "mandatory" objective and needs to be integral to CAPWAP. Based on the exchanges so far, I think support for this feature can be easily incorporated in to the protocol.=20 =20 We know the protocol needs this (from the requirement) and we know how to do it (from the proposals), so let's just do it and move forward.=20 =20 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Thursday, July 20, 2006 6:30 AM To: Michael Montemurro; Saravanan Govindan Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 My personal feeling is that this should be considered a "nice to have", and therefore show up in the "wish" tracker category. Given all of the work we have ahead of us, I don't believe there is an urgent need to support this mode of operation, as the current protocol achieves our objectives. So waiting for a future version of the protocol would be my suggestion. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Tuesday, July 18, 2006 6:59 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, =20 I've given some additional thought to your requirements and I believe it would require additional text as well as an additional negotiation between the WTP and the AC. =20 We could separate the RSNA key management functions from the "classical" IEEE 802.1X authenticator functions and allow the WTP and AC negotiate where these functions reside: =20 The IEEE 802.1X authenticator functions would include the PMK derivation. The PMK would be passed to the WTP upon successful completion of the IEEE 802.1X authentication. =20 The RSNA key management functions would include the 4-way handshake and the generation of GTK updates. =20 I think this is a cleaner mechanism to address your requirements. =20 Does this make sense to you?=20 =20 Cheers, =20 Mike =09 =09 =20 On 7/6/06, Saravanan Govindan wrote:=20 Hi Mike, =20 Thank you for the note.=20 =09 I may not have been clear with my previous post. My request is to have EAPoL frames generated at the AC alone - not at the WTP.=20 =20 My request is for designs where EAPoL frames are generated at the AC and in those where the KeyRSC is maintained in the WTP. These designs were highlighted in the Architecture Taxonomy.=20 =20 Specifically, I suggest that a CAPWAP message (it may be Add WLAN or Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. This EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of group key handshake) would have its KeyRSC field unassigned. Then when the WTP receives this message, it fills in the right value of the KeyRSC, updates the EAPoL frame and then transmit it to the wireless station.=20 =20 I hope this clarifies my suggestion. =09 Cheers, =09 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com]=20 Sent: Tuesday, July 04, 2006 9:47 PM To: Saravanan Govindan Cc: capwap =09 Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 So, you would like to request that the WTP generate EAPoL-Key frames for the 4-way handshake and the GTK update? =20 The current draft assumes that all EAPoL-Key frames are generated at the AC. =20 Based on the following assumptions: 1) This feature would be for local-MAC only. 2) The 4-way handshake and the GTK handshake would originate from the same location. =20 This would then require: 1) Negotiation between the WTP and the AC on where the 4-way handshake and GTK updates are generated.=20 2) A modification to the updateWLAN message element to include the PMK when a STA successfully associates. =20 I've captured this as issue 199. =09 =20 On 7/3/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com > wrote:=20 Hi Mike, =20 I had a chance to review the new draft.=20 =20 With regard to Issue 43, my understanding is that updates were made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN message element now allows the AC to send sequence counter values to the WTP. So now, CAPWAP can support designs where the KeyRSC is maintained by the AC.=20 =20 My initial concern was with supporting designs where the KeyRSC is maintained by the WTP. This is particularly important to manage the 4-Way and Group-key handshakes.=20 =20 With this in mind, I think the protocol still requires support for designs where the KeyRSC is maintained by the WTP. Based on the current draft, this support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames would have unassigned fields for KeyRSC (since the value is maintained by the WTP). =20 I am also open to any alternatives to support this.=20 =20 Cheers, =09 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com]=20 Sent: Tuesday, June 20, 2006 10:01 PM=20 To: Saravanan Govindan Cc: Bob O'Hara (boohara); capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 I've updated section 11.3 to deal with the GTK exchange and the handling of the KeyRSC in draft -02 to address your comments. I also provided a mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message element as part of the Group Key exchange.=20 =20 We're finalizing the -02 draft this week and you should be able to look at it when we post it later this week. =20 Cheers, =20 Mike =20 =20 ------_=_NextPart_001_01C6AF37.403FC7C4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    There is no need to coordinate such values = between the AC=20 and WTP.  Please read 802.11i to understand how the key exchange = protocol=20 operates.

     -Bob
     

     

    From: Saravanan Govindan=20 [mailto:Saravanan.Govindan@sg.panasonic.com]
    Sent: Sunday, = July 23,=20 2006 8:02 PM
    To: Pat Calhoun (pacalhou); Michael=20 Montemurro
    Cc: capwap
    Subject: Re: [Capwap] = Clarification of=20 Issue 43: IEEE 802.11i Considerations

    The current version of the = protocol=20 does not support 5.1.10. There is no means of coordinating KeyRSC values = maintained by the WTP and EAPoL frame generation by the AC.=20

     

    Saravanan

     

     

     

     

    From: Pat=20 Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
    Sent:     Friday, July 21, 2006 11:15 = PM
    To: = Saravanan Govindan; Michael = Montemurro
    Cc: capwap
    Subject: RE: [Capwap] = Clarification of=20 Issue 43: IEEE 802.11i Considerations

     

    The protocol = today=20 addresses requirement defined in Section=20 5.1.10

     

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

     

     

    From:=20 Saravanan Govindan=20 [mailto:Saravanan.Govindan@sg.panasonic.com]
    Sent:     Thursday, July 20, 2006 = 10:44=20 PM
    To: Pat Calhoun=20 (pacalhou); Michael Montemurro
    Cc: capwap
    Subject: RE: [Capwap] = Clarification of=20 Issue 43: IEEE 802.11i = Considerations

    The =
requirement from Section 5.1.10 of RFC 4564 states that the =
“protocol MUST allow for the exchange of key information when =
authenticator and encryption roles are located in distinct =
entities.” =

     
    The current protocol draft needs to include operations to support =
key exchange in such designs. And the feature we’ve been =
discussing directly addresses this need. =

     
    Saravanan
     
     
     

     

     

    From: Pat=20 Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
    Sent:     Thursday, July 20, 2006 = 11:27=20 PM
    To: = Saravanan Govindan; Michael = Montemurro
    Cc: capwap
    Subject: RE: [Capwap] = Clarification of=20 Issue 43: IEEE 802.11i = Considerations

     

    I'd like to = understand how you've interpreted this feature as being "mandatory". = The=20 current spec supports 802.11i, in both modes of operation that we've = agreed=20 to, which is Split and Local=20 MAC.

     

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

     

     

    From:=20 Saravanan Govindan=20 [mailto:Saravanan.Govindan@sg.panasonic.com]
    Sent:     Wednesday, July 19, = 2006 11:37=20 PM
    To: Pat = Calhoun=20 (pacalhou); Michael Montemurro
    Cc: capwap
    Subject: RE: [Capwap] = Clarification of=20 Issue 43: IEEE 802.11i Considerations

    I’d like to = clarify that this is=20 indeed a “mandatory” objective and needs to be integral = to CAPWAP. Based on=20 the exchanges so far, I think support for this feature can be easily = incorporated in to the protocol.

     

    We know the protocol = needs this=20 (from the requirement) and we know how to do it (from the = proposals), so=20 let’s just do it and move forward. =

     

    Saravanan

     

     

     

     

    From: Pat=20 Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
    Sent:     Thursday, July 20, 2006 = 6:30=20 AM
    To: Michael = Montemurro;=20 Saravanan = Govindan
    Cc: capwap
    Subject: RE: [Capwap] = Clarification of=20 Issue 43: IEEE 802.11i = Considerations

     

    My = personal feeling=20 is that this should be considered a "nice to have", and therefore = show up in=20 the "wish" tracker category. Given all of the work we have ahead of = us, I=20 don't believe there is an urgent need to support this mode of = operation, as=20 the current protocol achieves our objectives. So waiting for a = future=20 version of the protocol would be my=20 suggestion.

     

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

     

     

    From:=20 Michael Montemurro [mailto:montemurro.michael@gmail.com] =
    Sent:     Tuesday, July 18, = 2006 6:59=20 PM
    To: = Saravanan Govindan
    Cc: capwap
    Subject: Re: [Capwap] = Clarification=20 of Issue 43: IEEE 802.11i = Considerations

    Saravanan,

     

    I've given some additional thought to = your=20 requirements and I believe it would require additional text as = well as an=20 additional negotiation between the WTP and the=20 AC.

     

    We could separate the RSNA key = management functions from the "classical" IEEE 802.1X = authenticator=20 functions and allow the WTP and AC negotiate where these functions = reside:

     

    The IEEE 802.1X authenticator functions = would=20 include the PMK derivation. The PMK would be passed to the WTP = upon=20 successful completion of the IEEE 802.1X=20 authentication.

     

    The RSNA key management functions would = include=20 the 4-way handshake and the generation of GTK=20 updates.

     

    I think this is a cleaner mechanism to = address=20 your requirements.

     

    Does this make sense to you?=20

     

    Cheers,

     

    Mike



     

    On 7/6/06, = Saravanan=20 Govindan <Saravanan.Govindan@sg= .panasonic.com>=20 wrote:

    Hi=20 Mike,

     

    Thank you for the = note.=20


    I may not have = been clear=20 with my previous post. My request is to have EAPoL frames = generated at the=20 AC alone – not at the WTP.

     

    My request is for = designs=20 where EAPoL frames are generated at the AC and in those where the = KeyRSC=20 is maintained in the WTP. These designs were highlighted in the=20 Architecture Taxonomy.

     

    Specifically, I = suggest that a=20 CAPWAP message (it may be Add WLAN or Update WLAN) be able to = carry an=20 EAPoL frame from the AC to the WTP. This EAPoL frame (for Message = 3 of=20 4-way handshake or for Message 1 of group key handshake) would = have its=20 KeyRSC field unassigned. Then when the WTP receives this message, = it fills=20 in the right value of the KeyRSC, updates the EAPoL frame and then = transmit it to the wireless station.

     

    I hope this = clarifies my=20 suggestion.


    Cheers,


    Saravanan

     

     

     

     

    From:=20 Michael Montemurro [mailto: montemurro.michael@gmail.com]
    Sent:     Tuesday, July 04, = 2006 9:47=20 PM
    To: = Saravanan Govindan
    Cc:=20 capwap


    Subject: Re: [Capwap] = Clarification=20 of Issue 43: IEEE 802.11i=20 = Considerations

     

    Saravanan,

     

    So,=20 you would like to request that the WTP generate EAPoL-Key frames = for the=20 4-way handshake and the GTK = update?

     

    The=20 current draft assumes that all EAPoL-Key frames are generated at = the=20 AC.

     

    Based=20 on the following assumptions:

    1)=20 This feature would be for local-MAC=20 only.

    2)=20 The 4-way handshake and the GTK handshake would originate from the = same=20 location.

     

    This=20 would then require:

    1)=20 Negotiation between the WTP and the AC on where the 4-way = handshake and=20 GTK updates are generated.

    2) A=20 modification to the updateWLAN message element to include the = PMK=20 when a STA successfully = associates.

     

    I've=20 captured this as issue=20 199.

     

    On=20 7/3/06, Saravanan = Govindan=20 <=20 Saravanan.Govindan@sg.panasonic.com> wrote:=20

    Hi=20 Mike,

     

    I had a chance to = review the=20 new draft.

     

    With regard to Issue = 43, my=20 understanding is that updates were made in Section 11.9.1 (IEEE = 802.11 Add=20 WLAN). In particular, the IEEE 802.11 Add WLAN message element now = allows=20 the AC to send sequence counter values to the WTP. So now, CAPWAP = can=20 support designs where the KeyRSC is maintained by the AC.=20

     

    My initial concern = was with=20 supporting designs where the KeyRSC is maintained by the WTP. This = is=20 particularly important to manage the 4-Way and Group-key = handshakes.=20

     

    With this in mind, I = think the=20 protocol still requires support for designs where the KeyRSC is = maintained=20 by the WTP. Based on the current draft, this support can be = included by=20 adding another field to the IEEE 802.11 Add WLAN message element. = This=20 field would contain Message-3 EAPoL frame (for 4-Way handshake) or = Message-1 EAPoL frame (for Group-key handshake). These EAPoL = frames would=20 have unassigned fields for KeyRSC (since the value is maintained = by the=20 WTP).

     

    I am also open to = any=20 alternatives to support this.

     

    Cheers,


    Saravanan

     

     

     

     

    From:=20 Michael Montemurro [mailto: montemurro.michael@gmail.com]
    Sent:     Tuesday, June 20, = 2006 10:01 PM=20
    To: = Saravanan Govindan
    Cc: Bob O'Hara (boohara);=20 capwap
    Subject: = Re:=20 [Capwap] Clarification of Issue 43: IEEE 802.11i=20 Considerations

     

    Saravanan,

     

    I've=20 updated section 11.3 to deal with the GTK exchange and the = handling of the=20 KeyRSC in draft -02 to address your comments. I also provided a = mechanism=20 for the AC to transmit the keyRSC to the WTP using the updateWLAN = message=20 element as part of the Group Key exchange.=20

     

    We're=20 finalizing the -02 draft this week and you should be able to look = at it=20 when we post it later this = week.

     

    Cheers,

     

    Mike

     

     

    ------_=_NextPart_001_01C6AF37.403FC7C4-- --===============1548979271== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1548979271==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 24 11:51:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G52iB-0007jG-R7 for capwap-archive@lists.ietf.org; Mon, 24 Jul 2006 11:51:15 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G52i8-0001cp-Ve for capwap-archive@lists.ietf.org; Mon, 24 Jul 2006 11:51:15 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6DB73398062 for ; Mon, 24 Jul 2006 08:51:12 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id F2AA6430054 for ; Mon, 24 Jul 2006 08:50:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6851C144801C for ; Mon, 24 Jul 2006 08:50:22 -0700 (PDT) Received: from bay0-omc3-s8.bay0.hotmail.com (bay0-omc3-s8.bay0.hotmail.com [65.54.246.208]) by hermes.tigertech.net (Postfix) with ESMTP id 5598D144803D for ; Mon, 24 Jul 2006 08:50:18 -0700 (PDT) Received: from hotmail.com ([207.46.8.232]) by bay0-omc3-s8.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 08:50:17 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 24 Jul 2006 08:50:17 -0700 Message-ID: Received: from 207.46.8.251 by by118fd.bay118.hotmail.msn.com with HTTP; Mon, 24 Jul 2006 15:50:12 GMT X-Originating-IP: [202.156.6.21] X-Originating-Email: [saravanang@hotmail.com] X-Sender: saravanang@hotmail.com In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC01CC59D8@xmb-sjc-237.amer.cisco.com> From: "Saravanan Govindan" To: boohara@cisco.com, capwap@frascone.com Date: Mon, 24 Jul 2006 23:50:12 +0800 Mime-Version: 1.0 X-OriginalArrivalTime: 24 Jul 2006 15:50:17.0461 (UTC) FILETIME=[DC3C5A50:01C6AF38] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.7 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b612707e1a3f67df80ae89cdab1ba981 After reading the specs; there is a need to coordinate in this case. Message 3 of 4-way exchange needs KeyRSC to calculate KeyMIC - if KeyRSC is maintained by WTP, then coordination is needed. I have explained in detail why we need the proposed update with regard to Section 5.1.10. If there is concern that the proposal is not needed, please clarify how the current specifications supports 802.11i when authenticator is handled by AC and encryption / KeyRSC is handled at WTP. Saravanan ----Original Message Follows---- From: "Bob O'Hara (boohara)" To: "capwap" Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Date: Mon, 24 Jul 2006 08:38:45 -0700 There is no need to coordinate such values between the AC and WTP. Please read 802.11i to understand how the key exchange protocol operates. -Bob ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Sunday, July 23, 2006 8:02 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The current version of the protocol does not support 5.1.10. There is no means of coordinating KeyRSC values maintained by the WTP and EAPoL frame generation by the AC. Saravanan ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Friday, July 21, 2006 11:15 PM To: Saravanan Govindan; Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The protocol today addresses requirement defined in Section 5.1.10 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Thursday, July 20, 2006 10:44 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The requirement from Section 5.1.10 of RFC 4564 states that the "protocol MUST allow for the exchange of key information when authenticator and encryption roles are located in distinct entities." The current protocol draft needs to include operations to support key exchange in such designs. And the feature we've been discussing directly addresses this need. Saravanan ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Thursday, July 20, 2006 11:27 PM To: Saravanan Govindan; Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations I'd like to understand how you've interpreted this feature as being "mandatory". The current spec supports 802.11i, in both modes of operation that we've agreed to, which is Split and Local MAC. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Wednesday, July 19, 2006 11:37 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations I'd like to clarify that this is indeed a "mandatory" objective and needs to be integral to CAPWAP. Based on the exchanges so far, I think support for this feature can be easily incorporated in to the protocol. We know the protocol needs this (from the requirement) and we know how to do it (from the proposals), so let's just do it and move forward. Saravanan ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Thursday, July 20, 2006 6:30 AM To: Michael Montemurro; Saravanan Govindan Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations My personal feeling is that this should be considered a "nice to have", and therefore show up in the "wish" tracker category. Given all of the work we have ahead of us, I don't believe there is an urgent need to support this mode of operation, as the current protocol achieves our objectives. So waiting for a future version of the protocol would be my suggestion. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com] Sent: Tuesday, July 18, 2006 6:59 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, I've given some additional thought to your requirements and I believe it would require additional text as well as an additional negotiation between the WTP and the AC. We could separate the RSNA key management functions from the "classical" IEEE 802.1X authenticator functions and allow the WTP and AC negotiate where these functions reside: The IEEE 802.1X authenticator functions would include the PMK derivation. The PMK would be passed to the WTP upon successful completion of the IEEE 802.1X authentication. The RSNA key management functions would include the 4-way handshake and the generation of GTK updates. I think this is a cleaner mechanism to address your requirements. Does this make sense to you? Cheers, Mike On 7/6/06, Saravanan Govindan wrote: Hi Mike, Thank you for the note. I may not have been clear with my previous post. My request is to have EAPoL frames generated at the AC alone - not at the WTP. My request is for designs where EAPoL frames are generated at the AC and in those where the KeyRSC is maintained in the WTP. These designs were highlighted in the Architecture Taxonomy. Specifically, I suggest that a CAPWAP message (it may be Add WLAN or Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. This EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of group key handshake) would have its KeyRSC field unassigned. Then when the WTP receives this message, it fills in the right value of the KeyRSC, updates the EAPoL frame and then transmit it to the wireless station. I hope this clarifies my suggestion. Cheers, Saravanan ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com] Sent: Tuesday, July 04, 2006 9:47 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, So, you would like to request that the WTP generate EAPoL-Key frames for the 4-way handshake and the GTK update? The current draft assumes that all EAPoL-Key frames are generated at the AC. Based on the following assumptions: 1) This feature would be for local-MAC only. 2) The 4-way handshake and the GTK handshake would originate from the same location. This would then require: 1) Negotiation between the WTP and the AC on where the 4-way handshake and GTK updates are generated. 2) A modification to the updateWLAN message element to include the PMK when a STA successfully associates. I've captured this as issue 199. On 7/3/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com > wrote: Hi Mike, I had a chance to review the new draft. With regard to Issue 43, my understanding is that updates were made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN message element now allows the AC to send sequence counter values to the WTP. So now, CAPWAP can support designs where the KeyRSC is maintained by the AC. My initial concern was with supporting designs where the KeyRSC is maintained by the WTP. This is particularly important to manage the 4-Way and Group-key handshakes. With this in mind, I think the protocol still requires support for designs where the KeyRSC is maintained by the WTP. Based on the current draft, this support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames would have unassigned fields for KeyRSC (since the value is maintained by the WTP). I am also open to any alternatives to support this. Cheers, Saravanan ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com] Sent: Tuesday, June 20, 2006 10:01 PM To: Saravanan Govindan Cc: Bob O'Hara (boohara); capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, I've updated section 11.3 to deal with the GTK exchange and the handling of the KeyRSC in draft -02 to address your comments. I also provided a mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message element as part of the Group Key exchange. We're finalizing the -02 draft this week and you should be able to look at it when we post it later this week. Cheers, Mike _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ Get MSN Hotmail alerts on your mobile. http://mobile.msn.com/ac.aspx?cid=uuhp_hotmail _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 24 12:01:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G52rf-0003uD-Iy for capwap-archive@lists.ietf.org; Mon, 24 Jul 2006 12:01:03 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G52rc-000362-MR for capwap-archive@lists.ietf.org; Mon, 24 Jul 2006 12:01:03 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id E914839806C for ; Mon, 24 Jul 2006 09:00:59 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 84AD7430054 for ; Mon, 24 Jul 2006 08:59:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4FD5F398035 for ; Mon, 24 Jul 2006 08:59:53 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by zoidberg.tigertech.net (Postfix) with ESMTP id 26DD2398056 for ; Mon, 24 Jul 2006 08:59:50 -0700 (PDT) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-2.cisco.com with ESMTP; 24 Jul 2006 08:59:50 -0700 X-IronPort-AV: i="4.07,176,1151910000"; d="scan'208"; a="331013328:sNHT82329680" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6OFxnNg024707 for ; Mon, 24 Jul 2006 08:59:49 -0700 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 k6OFxnHS017242 for ; Mon, 24 Jul 2006 08:59:49 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 08:59:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Jul 2006 08:59:47 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC01CC59EC@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations thread-index: AcavON8IdAUbzE/RTj+5aHVK3ab5nwAACaNw From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 24 Jul 2006 15:59:49.0682 (UTC) FILETIME=[314E5920:01C6AF3A] Authentication-Results: sj-dkim-6.cisco.com; header.From=boohara@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3419f078334bcda4102d3d704cee11c6 1. A value for the KeyRSC is necessary to calculate the KeyMIC. 2. This value does not need to bear any specific relationship to the RSC value maintained by the WTP. 3. The client STA will use the value of KeyRSC received in the EAPOL-key frame to validate the KeyMIC. 4. The client STA will also set its RSC to the value received in KeyRSC. 5. The value in the client STA's RSC will be compared against the sequence number in subsequent received frames to identify replay attacks. 6. For any frame that is determined not to be a replay attack frame (and meets all other validity and authenticity requirements), the client STA updates its RSC value to the sequence number in the received frame. 7. Please see item 6, immediately above, for the reason that the AC and WTP do not need to coordinate and exchange the RSC. -Bob -----Original Message----- From: Saravanan Govindan [mailto:saravanang@hotmail.com] Sent: Monday, July 24, 2006 8:50 AM To: Bob O'Hara (boohara); capwap@frascone.com Cc: saravanan.govindan@sg.panasonic.com Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations After reading the specs; there is a need to coordinate in this case. Message 3 of 4-way exchange needs KeyRSC to calculate KeyMIC - if KeyRSC is maintained by WTP, then coordination is needed. I have explained in detail why we need the proposed update with regard to Section 5.1.10. If there is concern that the proposal is not needed, please clarify how the current specifications supports 802.11i when authenticator is handled by AC and encryption / KeyRSC is handled at WTP. Saravanan ----Original Message Follows---- From: "Bob O'Hara (boohara)" To: "capwap" Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Date: Mon, 24 Jul 2006 08:38:45 -0700 There is no need to coordinate such values between the AC and WTP. Please read 802.11i to understand how the key exchange protocol operates. -Bob ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Sunday, July 23, 2006 8:02 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The current version of the protocol does not support 5.1.10. There is no means of coordinating KeyRSC values maintained by the WTP and EAPoL frame generation by the AC. Saravanan ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Friday, July 21, 2006 11:15 PM To: Saravanan Govindan; Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The protocol today addresses requirement defined in Section 5.1.10 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Thursday, July 20, 2006 10:44 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The requirement from Section 5.1.10 of RFC 4564 states that the "protocol MUST allow for the exchange of key information when authenticator and encryption roles are located in distinct entities." The current protocol draft needs to include operations to support key exchange in such designs. And the feature we've been discussing directly addresses this need. Saravanan ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Thursday, July 20, 2006 11:27 PM To: Saravanan Govindan; Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations I'd like to understand how you've interpreted this feature as being "mandatory". The current spec supports 802.11i, in both modes of operation that we've agreed to, which is Split and Local MAC. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Wednesday, July 19, 2006 11:37 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations I'd like to clarify that this is indeed a "mandatory" objective and needs to be integral to CAPWAP. Based on the exchanges so far, I think support for this feature can be easily incorporated in to the protocol. We know the protocol needs this (from the requirement) and we know how to do it (from the proposals), so let's just do it and move forward. Saravanan ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Thursday, July 20, 2006 6:30 AM To: Michael Montemurro; Saravanan Govindan Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations My personal feeling is that this should be considered a "nice to have", and therefore show up in the "wish" tracker category. Given all of the work we have ahead of us, I don't believe there is an urgent need to support this mode of operation, as the current protocol achieves our objectives. So waiting for a future version of the protocol would be my suggestion. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com] Sent: Tuesday, July 18, 2006 6:59 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, I've given some additional thought to your requirements and I believe it would require additional text as well as an additional negotiation between the WTP and the AC. We could separate the RSNA key management functions from the "classical" IEEE 802.1X authenticator functions and allow the WTP and AC negotiate where these functions reside: The IEEE 802.1X authenticator functions would include the PMK derivation. The PMK would be passed to the WTP upon successful completion of the IEEE 802.1X authentication. The RSNA key management functions would include the 4-way handshake and the generation of GTK updates. I think this is a cleaner mechanism to address your requirements. Does this make sense to you? Cheers, Mike On 7/6/06, Saravanan Govindan wrote: Hi Mike, Thank you for the note. I may not have been clear with my previous post. My request is to have EAPoL frames generated at the AC alone - not at the WTP. My request is for designs where EAPoL frames are generated at the AC and in those where the KeyRSC is maintained in the WTP. These designs were highlighted in the Architecture Taxonomy. Specifically, I suggest that a CAPWAP message (it may be Add WLAN or Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. This EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of group key handshake) would have its KeyRSC field unassigned. Then when the WTP receives this message, it fills in the right value of the KeyRSC, updates the EAPoL frame and then transmit it to the wireless station. I hope this clarifies my suggestion. Cheers, Saravanan ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com] Sent: Tuesday, July 04, 2006 9:47 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, So, you would like to request that the WTP generate EAPoL-Key frames for the 4-way handshake and the GTK update? The current draft assumes that all EAPoL-Key frames are generated at the AC. Based on the following assumptions: 1) This feature would be for local-MAC only. 2) The 4-way handshake and the GTK handshake would originate from the same location. This would then require: 1) Negotiation between the WTP and the AC on where the 4-way handshake and GTK updates are generated. 2) A modification to the updateWLAN message element to include the PMK when a STA successfully associates. I've captured this as issue 199. On 7/3/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com > wrote: Hi Mike, I had a chance to review the new draft. With regard to Issue 43, my understanding is that updates were made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN message element now allows the AC to send sequence counter values to the WTP. So now, CAPWAP can support designs where the KeyRSC is maintained by the AC. My initial concern was with supporting designs where the KeyRSC is maintained by the WTP. This is particularly important to manage the 4-Way and Group-key handshakes. With this in mind, I think the protocol still requires support for designs where the KeyRSC is maintained by the WTP. Based on the current draft, this support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames would have unassigned fields for KeyRSC (since the value is maintained by the WTP). I am also open to any alternatives to support this. Cheers, Saravanan ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com] Sent: Tuesday, June 20, 2006 10:01 PM To: Saravanan Govindan Cc: Bob O'Hara (boohara); capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, I've updated section 11.3 to deal with the GTK exchange and the handling of the KeyRSC in draft -02 to address your comments. I also provided a mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message element as part of the Group Key exchange. We're finalizing the -02 draft this week and you should be able to look at it when we post it later this week. Cheers, Mike _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ Get MSN Hotmail alerts on your mobile. http://mobile.msn.com/ac.aspx?cid=uuhp_hotmail _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 24 21:42:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Bwl-0001KK-QS for capwap-archive@lists.ietf.org; Mon, 24 Jul 2006 21:42:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Bwl-0003PF-F0 for capwap-archive@lists.ietf.org; Mon, 24 Jul 2006 21:42:55 -0400 Received: from hermes.tigertech.net ([64.62.209.16] helo=g1-42.tigertech.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5Bpk-00067N-Rv for capwap-archive@lists.ietf.org; Mon, 24 Jul 2006 21:35:44 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 34041144806C for ; Mon, 24 Jul 2006 18:35:30 -0700 (PDT) Received: from g1-42.tigertech.net (hermes.tigertech.net [64.62.209.16]) by leela.tigertech.net (Postfix) with ESMTP id 5678C430054 for ; Mon, 24 Jul 2006 18:34:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 86251144805E for ; Mon, 24 Jul 2006 18:27:32 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id D9D5B1448055 for ; Mon, 24 Jul 2006 18:27:29 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id k6P1RPn8010364; Tue, 25 Jul 2006 10:27:25 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k6P1RRE19973; Tue, 25 Jul 2006 10:27:27 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with SMTP id k6P1RQo19359; Tue, 25 Jul 2006 10:27:26 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Jul 2006 09:29:39 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD0107385D@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Thread-Index: AcavON8IdAUbzE/RTj+5aHVK3ab5nwAACaNwABP2rkA= From: "Saravanan Govindan" To: "Bob O'Hara (boohara)" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: c07eeb7900970a16fe4056cc74ae9ce2 The KeyRSC is in fact maintained by the WTP in the case that requirement 5.1.10 addresses. So when the KeyRSC is maintained at the WTP, how does the AC know which value to use to calculate the KeyMIC? Perhaps the next tutorial can provide insight in to the CAPWAP specifications. Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] Sent: Tuesday, July 25, 2006 12:00 AM To: capwap@frascone.com Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations 1. A value for the KeyRSC is necessary to calculate the KeyMIC. 2. This value does not need to bear any specific relationship to the RSC value maintained by the WTP. 3. The client STA will use the value of KeyRSC received in the EAPOL-key frame to validate the KeyMIC. 4. The client STA will also set its RSC to the value received in KeyRSC. 5. The value in the client STA's RSC will be compared against the sequence number in subsequent received frames to identify replay attacks. 6. For any frame that is determined not to be a replay attack frame (and meets all other validity and authenticity requirements), the client STA updates its RSC value to the sequence number in the received frame. 7. Please see item 6, immediately above, for the reason that the AC and WTP do not need to coordinate and exchange the RSC. -Bob -----Original Message----- From: Saravanan Govindan [mailto:saravanang@hotmail.com] Sent: Monday, July 24, 2006 8:50 AM To: Bob O'Hara (boohara); capwap@frascone.com Cc: saravanan.govindan@sg.panasonic.com Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations After reading the specs; there is a need to coordinate in this case. Message 3 of 4-way exchange needs KeyRSC to calculate KeyMIC - if KeyRSC is maintained by WTP, then coordination is needed. I have explained in detail why we need the proposed update with regard to Section 5.1.10. If there is concern that the proposal is not needed, please clarify how the current specifications supports 802.11i when authenticator is handled by AC and encryption / KeyRSC is handled at WTP. Saravanan ----Original Message Follows---- From: "Bob O'Hara (boohara)" To: "capwap" Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Date: Mon, 24 Jul 2006 08:38:45 -0700 There is no need to coordinate such values between the AC and WTP. Please read 802.11i to understand how the key exchange protocol operates. -Bob ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Sunday, July 23, 2006 8:02 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The current version of the protocol does not support 5.1.10. There is no means of coordinating KeyRSC values maintained by the WTP and EAPoL frame generation by the AC. Saravanan ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Friday, July 21, 2006 11:15 PM To: Saravanan Govindan; Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The protocol today addresses requirement defined in Section 5.1.10 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Thursday, July 20, 2006 10:44 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The requirement from Section 5.1.10 of RFC 4564 states that the "protocol MUST allow for the exchange of key information when authenticator and encryption roles are located in distinct entities." The current protocol draft needs to include operations to support key exchange in such designs. And the feature we've been discussing directly addresses this need. Saravanan ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Thursday, July 20, 2006 11:27 PM To: Saravanan Govindan; Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations I'd like to understand how you've interpreted this feature as being "mandatory". The current spec supports 802.11i, in both modes of operation that we've agreed to, which is Split and Local MAC. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Wednesday, July 19, 2006 11:37 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations I'd like to clarify that this is indeed a "mandatory" objective and needs to be integral to CAPWAP. Based on the exchanges so far, I think support for this feature can be easily incorporated in to the protocol. We know the protocol needs this (from the requirement) and we know how to do it (from the proposals), so let's just do it and move forward. Saravanan ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Thursday, July 20, 2006 6:30 AM To: Michael Montemurro; Saravanan Govindan Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations My personal feeling is that this should be considered a "nice to have", and therefore show up in the "wish" tracker category. Given all of the work we have ahead of us, I don't believe there is an urgent need to support this mode of operation, as the current protocol achieves our objectives. So waiting for a future version of the protocol would be my suggestion. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com] Sent: Tuesday, July 18, 2006 6:59 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, I've given some additional thought to your requirements and I believe it would require additional text as well as an additional negotiation between the WTP and the AC. We could separate the RSNA key management functions from the "classical" IEEE 802.1X authenticator functions and allow the WTP and AC negotiate where these functions reside: The IEEE 802.1X authenticator functions would include the PMK derivation. The PMK would be passed to the WTP upon successful completion of the IEEE 802.1X authentication. The RSNA key management functions would include the 4-way handshake and the generation of GTK updates. I think this is a cleaner mechanism to address your requirements. Does this make sense to you? Cheers, Mike On 7/6/06, Saravanan Govindan wrote: Hi Mike, Thank you for the note. I may not have been clear with my previous post. My request is to have EAPoL frames generated at the AC alone - not at the WTP. My request is for designs where EAPoL frames are generated at the AC and in those where the KeyRSC is maintained in the WTP. These designs were highlighted in the Architecture Taxonomy. Specifically, I suggest that a CAPWAP message (it may be Add WLAN or Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. This EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of group key handshake) would have its KeyRSC field unassigned. Then when the WTP receives this message, it fills in the right value of the KeyRSC, updates the EAPoL frame and then transmit it to the wireless station. I hope this clarifies my suggestion. Cheers, Saravanan ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com] Sent: Tuesday, July 04, 2006 9:47 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, So, you would like to request that the WTP generate EAPoL-Key frames for the 4-way handshake and the GTK update? The current draft assumes that all EAPoL-Key frames are generated at the AC. Based on the following assumptions: 1) This feature would be for local-MAC only. 2) The 4-way handshake and the GTK handshake would originate from the same location. This would then require: 1) Negotiation between the WTP and the AC on where the 4-way handshake and GTK updates are generated. 2) A modification to the updateWLAN message element to include the PMK when a STA successfully associates. I've captured this as issue 199. On 7/3/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com > wrote: Hi Mike, I had a chance to review the new draft. With regard to Issue 43, my understanding is that updates were made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN message element now allows the AC to send sequence counter values to the WTP. So now, CAPWAP can support designs where the KeyRSC is maintained by the AC. My initial concern was with supporting designs where the KeyRSC is maintained by the WTP. This is particularly important to manage the 4-Way and Group-key handshakes. With this in mind, I think the protocol still requires support for designs where the KeyRSC is maintained by the WTP. Based on the current draft, this support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames would have unassigned fields for KeyRSC (since the value is maintained by the WTP). I am also open to any alternatives to support this. Cheers, Saravanan ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com] Sent: Tuesday, June 20, 2006 10:01 PM To: Saravanan Govindan Cc: Bob O'Hara (boohara); capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, I've updated section 11.3 to deal with the GTK exchange and the handling of the KeyRSC in draft -02 to address your comments. I also provided a mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message element as part of the Group Key exchange. We're finalizing the -02 draft this week and you should be able to look at it when we post it later this week. Cheers, Mike _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ Get MSN Hotmail alerts on your mobile. http://mobile.msn.com/ac.aspx?cid=uuhp_hotmail _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From ujihhdxirj@cnotes.com Tue Jul 25 08:52:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5MOh-000327-PQ for capwap-archive@ietf.org; Tue, 25 Jul 2006 08:52:28 -0400 Received: from xdsl-3236.zgora.dialog.net.pl ([84.40.160.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G5MOd-0003Xr-53 for capwap-archive@ietf.org; Tue, 25 Jul 2006 08:52:27 -0400 Message-ID: <000701c00781$11130a50$a4a02854@darekbcd605025> From: "attacked" To: capwap-archive@ietf.org Subject: two decades Kenora Daily Date: Wed, 16 Aug 2000 14:54:08 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C00791.D49BDA50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2873 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2873 X-Spam-Score: 4.6 (++++) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 ------=_NextPart_000_0003_01C00791.D49BDA50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C00791.D49BDA50" ------=_NextPart_001_0004_01C00791.D49BDA50 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable RamsDate: Delivered assistant FedNor ultrafast speed precise quick cottagers say they dont stop wielder petitions polish Same same differing Missing Lack riles squeezes SnoXDate: Insurance reaction Ipperwash lien Regional Ministers NHL M marijuana seized jailDate: Space Referee AreaDate: athletes coaches Tearful farewell Steering path Spring feast bridge gap accused coreDate: tonight voice concerns proposes pile onto podium Dennis doubles U.S.Date: berth XPhone: Fax: Search estranged stays wordDate: Derouard gets greeted collision relations report Abinoojii bicycle officer Rally Midget secondary restart Real estate brokers surgeries JulyDate: sharing CapsDate: Sorbara MS Bonnet stepping stone drowns Tops Deer proposal rejected due when sled struck effect Youth XP ------=_NextPart_001_0004_01C00791.D49BDA50 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
    3D""=20
    RamsDate: Delivered assistant FedNor
    ultrafast speed precise quick
    cottagers say they dont stop wielder
    petitions polish Same same
    differing
    Missing Lack riles
    squeezes SnoXDate: Insurance reaction Ipperwash
    lien Regional Ministers NHL
    .M marijuana seized
    jailDate: Space Referee
    AreaDate:
    athletes coaches Tearful farewell Steering path Spring feast bridge gap
    accused coreDate: tonight
    voice concerns
    proposes pile onto podium
    Dennis doubles U.S.Date:
    berth
    XPhone: Fax: Search
    estranged stays
    wordDate: Derouard gets
    greeted
    collision
    relations report Abinoojii bicycle officer Rally Midget
    secondary
    restart Real estate brokers
    surgeries JulyDate:
    sharing CapsDate: Sorbara
    MS Bonnet stepping stone drowns Tops Deer
    proposal rejected due
    when sled struck effect
    Youth
    XP
    ------=_NextPart_001_0004_01C00791.D49BDA50-- ------=_NextPart_000_0003_01C00791.D49BDA50 Content-Type: image/gif; name="forestry.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c00781$111183b0$a4a02854@darekbcd605025> R0lGODdh1gHGAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAA1gHGAQcI/gD/CRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh2KcBnRo0iTKl3KtKnTp1CjSp1KtarVqz3JYN3KtavXrwMHiD0odsDJsmfH6jRls6zZ qG7B6nSrtiFag3dL5lVIty7EvRQBk/Xbse/bwoD7EjR8OCzhuIYRMj6cGG1cuTUnN04o+F9n kJ8LRpYY+mFpgactjkbcWDPqyYv9Xl4tGrZn2XlTY0Z5+fVmyYR9p/3NObhp4xF160WOcW/v 22+d5677HDpf3GOnP2a+O2VnynRj/oMPL3y29spmLVP/LD09+t7axauNrN596+rkHbaH/lvx 4PvERbfdeL71xx161vGHF3fdmXQaY44J6B9/mkmYH33zhdbehBAK5yGF2SmGoYXwTcjQhhfS FiGB1xkooYILEhdhbfbBSKOMDTp44F3xmTdehdGJt2J9H/4nH3k+zuihc0WO+CGRYR0HIIey GalkcS6Wh1xpCEJpZY4rnRcigFqymOCZ3623mZfAkbmkmlfyKNh+Qu5XnX7YKakbnSAW+WZ+ NLYoJIg4KgemR2LWqOeYccL5JJVrAtrmoAnG9yiJjvpZ34h3CtroiyfmWWCGWRIa4I4ddhjj oWEGx6ac/4qimSmsKUYq6aqfXprrqKRSWuZoKnqq65nCEvsnrrTi2iagySrLKm8DEgurrGb2 OGu0nV5J7bDb3tgktgzaGKqblYZrLILnXlvqpOwa6+ezy4na7KbcWltttAly8GW3SfLK46B8 HruYZ5RqKGq3qO0r7rQrfmprwcyd5yy8Oqa6Gq0l3msfpIG+S2i9F1tcK5vlcmppjP1Se6u4 ppJK24b+cuvsc9lSPJKJfeZ6sqWQZXqpiynbiV2skoaHLq9D+npkr5qu7G7O/q5b4McIT5yx zVhnHapLhibVtdZgN2iuSF8PVXbYaH91Nkc1L9V22nDvNvbNa/P0dkL8xK333v589+3334AH LvjghBdu+OGIJ6744ow37vjjkEcu+eSUV2755ZhnrvnmnHfu+eeghy766KSXbvrpqKeu+uqs t6RG67DHLvvstNdu+1H13K777rz37vvvwAcv/PAJ9UL88cgnr/zyzDfv/PPQR691LNJXb31P AWSv/T/ZE9S99gEIBH74Bo0vvvnco5/+9ukP1L337Kvvvvnvtz9++PfPD377BX1PP/nzO1// AOg/762PfQf03/4EyMAG8i+AAsxf/q4XkfrVj3/vuyAAHUjADsLvgdzD4AYhqMEBmrCBFvQg CNcHP/yN8IIiPKH9LPjADL5QhSnUnwohOEMZwpCCB/7xBg81SD4bGvCD7hviBguYRCaWr4hL lGEAiahEBx7wfE60ohGROEMCgjCLNYSiEnPIRTBSEYgNISMDt4iQH6JwiS58ohvXOEIp6s+H OHxhAnvIRR0+cYoY/GIcy+hBMrLxjSs8IxoXksIJNtKN8lMjH1uYEGg8so4TZCEhF5hA/GEx gv+TIyYLGUFBdvKUU8yjFgsZSh4uMiGSPKQr/4jIVIoSlnVMZC4RiEhFii+JoLSjFXtZSirC 0IyDjKEubdnHOb6yiiQsYh9DCE1TlhCMJJzmD7NoyB3+8o/H3KU4AflJY95wlR2U4DmD2cxc PrOayoRj/wjpSm4q84Tks//EMulZy3t+04ThPAgkSVlOVfLzkxxMZi/XucJ34vGDC5SfDuU5 0XSyMZw25CUWt6fGWLpwf+NUJyfniD55ZlKdm6znR+MX0f9x0qEwjalMZ0rTmtr0pjjNqU53 ylOnQAJtP0VJUHvakqEKxKgZQSpBlNqQoSqVqQ6BhFShahGqLsSpBrEqRp5K1JMgVasR+SlU wXoQskrErCnBqlCz2lWTfPUfRg3qVKV61KkiRKxLnStcByJXu+5VrHbtK14B61S9LrWsdIVr YBNLWL4ytq6BVexTI+tXwRZErXuVbGEfe9TOtpUkb41rZjsrWrZi9q98He1fMYvX1CYWtak9 bEL+WjtawMbWtaq1rWdlq1jcjvW2tIUtaXeL1s9WZK6Rxa1ydwtc5so1s6ItrXCnG9y3zra2 y1UtaqPL2+b69rqDdW5uqWvckYT2sNFFLls9W9rWIre6sX0sd2/LXMfSlbXj1Sx5pevd4fbW tLB9r2bva93yguS82Q0uYisrW/eul7joHS9/tYtd/M53uxGmL4QTDGAHXxbAGjYwRxDc28Lm V8O0fe1p4Ste+Jr4w7xNMYexmmIWxzjD9d2whDNcXBFTxLrJDbJfuwvd+9LXsF8drHwbbOSs Vja5FTasfi1r47zueMgwzu2QkRxfH8+kxzUBs0LELGYvY0bKQEFzUh/+oubfrcLMcI6znOdM 5zrbeXRl5slrt3rnM7e5qT9e8J5D8tuwDjrEY96yoveM5T7DZMKAnghT8xzoslb6wQy5MHkp 7OhHR1iwm90wl13b6MkuWb+QtSxkUW1fwj73t9w97Zh3nN1OyyS94uVxixts6e7qVtMfLjCM cX3XKyPa0pp2NaVtvRH1YhfFwk12jgdM62qD+NjPrXWwdW3WbPv325xm9lqXK+Ap85fFk85y tNVr6r5ie9fg5XamV2ztZYv7Ihfm6nDp3d5eH/nZRKZ3uL093WsHONzQnjGR7z3ub+cbuvD+ b7p9DfCCC7zQwN52XSuub4pLm+ErcXZcFy3/Y1ZDedDtdi7JUy1ZK2d51JdVsZEFnlckr5zl IAcepHN+uC88Zec8t8jrgk70ohv96EhPutKXzvSmO/3pUI+61KdO9apb/epYz7rWt871rnv9 6wr5BdjHTvaym/3sTxkD2r8yhra3nSRvN4jb3f6PbRQk7hdR+0DmTveD4P0ffF/7TvD+948U XiBxP7xG5g74u+vd8YTXu+IFL5PDRx7was985veeeM1LnvEEufzbNc/5x/cd845vvOo5n5DL I/7xlK+J5U3v+dqjHvV977zfaY/50ZO+8bq/PethH3riF5/1r4/9TWY/fN4nP/i3V3zwRQ97 3ysE9KlvvfOFr/zK/huf+sjvPd1dL/3AC9/6pT89QrCffO2Hf/Ldb8nff4/77Ree/Mbnfvvr f/yH0B/+++d65ZV/YAN+z2d/pnd+n7d7csd7iXd++4d73Hd/1ed8ABh/LGF+fPd/xMd4Aqh+ +qeArxd50Jd+FZh9GziCF6gScoCBXUGAS3EJLviCM1iDNniDOJiDOqg6K4gUPWgSILiDDaGB MAiEBJiC4leECqh+7KeCuYd9INiBSiiE2cd/GRiEERh9RUh47+cQ0/d589eAVOiF3+d5xbeA TAiFAliFbCiC61d+iEeGAUh6XCiGY8gQs7eAqud7aOiAejh5gAh6a9iGzdeEKOiH0feG/3eI h2UYfgfYfJDYgxcIffAHh1rofnMofnHIfj8ohMzXfoFngPVniHZ4fRyIiWeYiQxogvlHh9u3 iIq4dyKoe6KIfnK4ELZYiVLYfyHYi3Eod4+YhbBYhbnoiqfYef8njBE4eshXgqUYhXrohqUo iyroiMO4e+NngR6ojWrojEnYh904iWAoiGpojYY4f+joaNMAN1OoEp1ohNeIEuYne+14Eu8Y j/iYj6RzAfrYj/5IOfeYOPVYg0RIEeVHihWBhITIiAiZkPXYihWIhfM4j1UnihGhix7hjXk3 kBCxgh5Yjb8Ygl+ojFDHfGlIi0m4iqX3fN/YhODHgbR3hFKIhv8muJIpqX/MuHq+SIGQSJJP l4fBiIzR+Izg+HvOSH3W94AaGYajeIx/eILHB5Gx+H6naHVIaIAliJFBqY1ZOJLB+JULWYyR +IrYKJXTmImDaJVO2ZM+SYLZ2IxD+Y1oGZESSZdV2ZQa2YA8CXlEKY1ZJ5YWqZU4yZWD2Zfp aIpwKY22aI2tN4G7qJJiaZWJuZXLCIMf6IZH2YhBCYGGGZlv+YuHyZJ72Xti6JUBaXQFOYeZ aZbph5lx+Yla6JYqmZLoGI42mYduyYfk6IQ1+Y9VwZHX55t7Q5EWAZzCeZzImZzKuZw6eJrM GRMK+ROC6Zx6mZYZSZwumJc6IZgbgX//cBeXGLiGJ9maLZmNG0iCB2iXt7mN5MmH5liGbxmT 4HiGowmYYFh2yAiKRnmJ/Il+tDifVpiI/GmF+TmgyiibX9iH78mW/mmcUqeQDdp/pmmUCkqJ d6mfPWmh2leOqqihg3iViEidPxmNKRiaEUqgRWmfcPmEDHqhiKmYiPiV9VmVDcl1GsqLs/iU /Ul/c5mhJLqWPnmIVNmifpmjK+qgD5qAAZiIE0qZAQqk8emhOoqhoTekHfqjsSmkromkUWei TyibOxqm1Yh/5Hh6n6mJrlmdETmYNxqdcumEZPmcBbiRclqANXqLdZqnzFMCetqnfpqPIooT WDh4ShioX0eH/7yZqDeJi/d3nVRanA5qnb7ImHi6kCWZe5PplVVKn5vaEbDpkBMhiYWKpIFY keNXmjGKk6lXhwzIovI5prW3iyc5jjGZnryJniL5n3Qpmi7Zjbx6nlw6gBAJpKoalZJnihR6 omLKl5rqnSyKmWDJpP+pn3nprJ+pneK2mzJKq0K5iUHYrFhqoJkarig6mYU5mkZqoKXqpMta dCralbgYoD16pY/Ki54pn/d6pDw6gvMqr+sql945qSD3rsW6ftFai4S5lKl6o1aKlfvKrwjr mFM5o/U6sONasTp5d+QpoeEasJYIrl0YsPx3pnuIpZq6k/aXpgLraBAajgNZm2r6mv9m+qMz OaupCKtUmayLya8wuprY2JoeG6xkZ6hDKLR/ehREy4hHu7RM27RO+7RQG7VSO7VUW7VWe7VY m7Vau7Vc27Ve+7VgG7ZiO7ZkCzwp4HR54xFpWxJGQXX88LZrC7dwOxBy+w9y+7Z2u7Z2m7d3 WxB6u7cCUbeBe7d/i7d0y7dzq7eKO7iG+xB/qxGFq7h5U7iMm7aEG7mNS7gEIblzizcGUbeX 67eLW7mHW7qBCzxxe7qf67efO7qqu7qb+7qAa7qiG7uP67p7i7sM8bgZEbmbO7msi7u8O7uW ixDAK7vDe7yyG7sH0biAO7rCi7qle7uwa7u0m7x+2w/US7v/1nu6vFu8xTu7zfu8nWu5ncu3 dGu4gou4lAu+4pu7nju+qou9qcu8wcu99nu/3gu77vu+vFO/25u/+4u8xqu/+Uu/h/u9Axy+ xsvA8Ku7yiu+Edy++0vBBSy/z1vA9Yu/8Lu8ApzAIMy6GezAvbO+mnu7fRu+upu+KVy9/ju/ 3tu3I/y662u6izvBBizBOty9wEu5iCvCrZu5MgzAQGzDHszBGdzBzNu/w3s7DBzA+Ju6K7y8 EUzAGNzD4yvFGEzDLay5P5y3lYu3EDy4AxzFHwzDR0zEH6zGW2y/WCzCylvF/zu9LuzBWozE FnzAF/zADZy+e0zDqxvAN+zCPqy+/+8LxdiLxqJbvkUcxkf8yFosyHHbxE5Mx3WMyFN8yFaM x7/7wpq8yYAMwoNMwKMMxmscytF7xXacw1CcxHV8vQ48xsFzwzL8wyfcyZzsxueby2TsxZ9M ukUsuOYrxGJMzJNcxZLMuT5MyOyLzOzbxsecyZLLwsv8yGX7dZebzdq8zdzczd78zeAczuI8 zuRczuZ8zuicztx8zezczu78zvC8EgCAEfMcEfUszwZxzxKhzxUBAO6QFPysEgGdEAMNAAat zwc90AKB0Ag9EAm90Ak9z/wc0fX80ARdEA3t0Bn9DxbN0Qft0BjN0SFN0R5t0AsR0fm80CAd 0if90Qeh0P8KEdAwDREdndIsPREw7dIn7RAF3c8mfREM/dMordIgrdMQ7dIbPdMEIdNLTdRO 3dT3/NNE3dBM3dQ3LdIIMdFFrdFWXdVTPdJgfdMzvdFXbdMXvdP2/BFkbdVsvc8xzdNw3RFK HddYrdIZHdUr3dYSndd1jdZ8bdcMsdeAPdhl3deGfdhn3deCLdJ47dVb3dUr7dVjDdWMXdKC /dESLdV/fdQVrdiWXdJ2LdRH7dYvjdScndkmrdOmvdhVjdoajdldndqwfdmqrdk27dqc/dZP /deX3dZP3duF/dKFvdgX3diPPdzITddUfdzEvduVDdlfLda6HdrR/dwQzdtmXdn/y+3UmX3c zu3Xem3d1o3XUN3ZiF3Rxu3dzR3Vnb3daC3VzZ3YPU3ZWn3Vez3f4H3Y6G3b3B3drC3bDz3R Q13Twt3f/k3Ym73eBk7SBJ7PFk3e6f3byQ3Y7h3h4o3Y0w3bW13h2G3h0I3gxK3g/e3euk3i Gf7aht3dE87YCj3XKZ7dzg3hGx7Wvq3UNu7Z1X3fMH7hEd7a4M3aC27eu+3YOs7c6o3VBI7Z tq3Vy83hU63hHn3WJB7i123gLP7gN+7ZLl7XTA7W9b3UD37eDfHlCe7gpk3hNI7d053Vih3m aI7cXw7k0p3Y423l4k3mEk7l5H3ndU7TaV7khN3jXI7h/0LO52Qt5B7u2yxt4vKd5s+91vod 42Oe3YWO5yFe6ZGu6JBO413O1Zlu5U7O1nvO13I+6lRe1k3O1Xuu54Oe1kf+361e5zJ+25R9 3ez94RZ+1wXO6Pit5bie14Vu50ge0x1d0w3e6VVu2ait5MyO1EZN58ge5bk97Shu3yit6xjt 5lx+36K92Z/97fvd51fe7Q0+5lhO7qkd6/st5yme7pHt7rOt2e6O5M4+6qN912dO6QFe7OVt 3kQO7K2z5TnRDZUj8KT9EvaOFeX+EwZfPQ1/8CyR8PE88fFoPBR/8Vbx8DWh8SbB8fQMEh4P 8jjtNyGfEhIf2M+OzzRx8myuEf8lL+Xe3s9p3evefeJM0fCITuxg3hIsT+cw8fJyHfMkAfS7 LhM57fNIvxQc3/PyTvT7HO/szd8FXe+4jdugfeXCbvW13enFTvWhve7ijuLrzu1RX/YyLfXM nuefLeAA/to5D/ZmDu8AruNkn+caHuYpf/XK/uhbD/Z9//XUDurjjvVhTfcm7+l8rum1Pujw PdKCvvNDTuiYTuYqPuyBbt9anus4XuAAD+KW/+IjvviADvpvDuztrfmMX95Cr+eTL/qvPutz /uiIz/UsLtCkvvmSbuSev/jD/u+8L+q/P+UL/umGzvunzvmCT9W8EOvJD9ntXeP0HfusHtmv rujVr/b/ul/81C/cRZ7zHV76KGHqyo7nvh767z7vvU/p0y71bo/+44/jMj71nk/V167pz77q 5d/Y8476vU3S4Y3eAPFPIACB/wgONFgw4UGECREyXKgQ4kAAFR0+LFhRI8GNFhl+NNjxosOJ GSMeRGlSpUqLERW+hBlT5syVEDnSLGnzIkidPCVifNlz5cidMCfm/FnUZcybQk0iHaq05tOf KRtOBdrw5lKmVZOCzMrVqtiRR6meJZoWLNerJGU2dSuVKMqUJWnexZu07N6gfdH6/Ms37d61 c4duPcx3rV2qHxGTdezX8FXEHilLBnw5rFmKiqc6DXkZ9OSllts+royW7GDN/nEFt92cVzZe 01o1vr0dsuVi3S17C7ar83duvb8p7s4tPHThjLuPr97Y/PFxzkpvV57O27jm6EYtc/S9/Gl3 3Tu3dlcunS5c9e2lrh9rvmvr2qRVM56dX/9+nPxh+wcwQNbuwk9AAw9EMEEFZytwQQcfhDBC 2RqciUIJBbTQvQs35NBBbyIkr0MRRySxRBNPRDFFFVdksUUXX4QxRhlnpLFGG2/EMUcdd+Sx Rx9/BDJIIYck8sEM/TtyvyRJLHDJ/4pc0EIniQwvvykvDJFAyQ68Mq8jmYOwycGCGxAzKHvD T8oORWKtywmVjIpFMN+S0E0t3xxRTDr3pO3M4hhT/pPD9IzCEs4nVVyMOJHYW/Sr5Ih7rirn 4FMPNeqGu3ShKiMFzzFIqTvPo+tOKo+wUY3rlKlHkRO1Lt+SK3XO0zJNDVNYKR3u1U8JuzQ6 oXAtVdVW6wpqVEV3FZQlr8aLbbT0AOUpPktHE03SOJmN7U+2ItP0vmqxtY9X0ZgDLzA+ISvq qGhn5W3QXwllV9oylQVXr1dfW1PRZbOadl+52tzXWXHtHXjAfqN6l+Bmv/LW3S1rXc1bth4W 9zyKC4PYUm2nkwviieejFqts82wN3YXHQ09VePn192CCBS62Po0To0tkl127uTp2P3NU5rC8 g/Usizem+TM2K/25Y/PQ/mtQXkBpPlpEsATOzOQtrwaNan+/HZnriHemN92WvZ4Ztqwblpjj 4sAeumiwxa6QUKgGTrO/ghVOmsmwS0stMr+3xjrggLFTC22EDQ/NXo3bHZxsfHXOmG7g1i7c XPs8jtzhvub+e9a991Zb6UGTZelY9kgy7VSmw9uVTZtMRz1UXWOXN+bF63uuKdb7Ju9U8VCl fPWxojV95tGDC7os38VKfurW4e19PeZZvdbT+IpVDNkf7YzbT+/163J0Q7+/k3wjtefSfPXt Hn9eL9fvHn7556e/fvvvxz9//ffnv3///wdgAAU4QAIWEEbcax9/dGYi7k0JgQHa1KbqlCAK /jnHQU56Wp829MB/zcd957rWypB0tUKREE5kkhuePqhCyrEPghgKobI42MLymVCEIKKglWJY Q/DBkIZSM1DdQBg/BaGQhQCyk6wSc8EE7tCJXrLgQ1ZFKdhhaju9Clb0qOiS1f3nVrr6VKpo dR0wco52wMoSqGJnq5NEUVOp+yLyWPW6YUkHi43JVM9cZb1O6S4nvsqVp4CGxeIhzSlalOAI hYOx9/ilaiu7l+a4FbqPSVFizUFc1apzOqtdbluY7Fa2NJk4T47Jc2HrSe0aNkr5eBEjjPPg XEapNZilb5Fu+9fwysRISfKMTnWr5dtKc0mhFaxsvNok4nBmTIqZ//JxJcPc5sZ2y1PKsJEZ NNs0tRlMJC1Pl5bD1SPNhLIp0kcty7tj15jZrqgBZVqNOpzQtNNJXXKTmo50XfMGl6U++uye x3slViToRlMBEm0dOeb4FofLzNSTfSGbmi8l6jjNnQxucSOWaqrJzGuO7aJf8wz0IAnNDgIO Zox05DA3qlGIblOESfzLN1k2U3HizWoyzQ5LMwk5yamTa/5cW+e0MlHCffSY92SYuRKlNG3G lKQpjVwIc7pT+bgskVZaVStTxp1j0U5liyxkZ5w3x3P6rDw8BR5XEzlWr+ZRIt8J1u/eCMaq 0ip4+oJkWBNnrLdG0K6lIxxASTWuP1ove/50lZ7sBDlDAzbWsel7bGQlO1kEpZGyl8VsZjW7 Wc521rOfBW1oRTta0pZ2flftYZSMdEMd5tCG7ythZBn7WqmucHtFZCL40De3JlZot6xlEBFf +EO7zfaIh7KtEiFLrhRSUkgznO2SxFc5BbIQm08U7mpdWyLpBhe5y81u3orkq1tJM61atOMV pSjTQ211UWQU5GANhhsLvrdV6T0dZ8IIX/zisXhm6WLM8FvON7q1jeFsnbHKCDQx/gqdDR5s ytBXI6f9cWcOexb2Zlo9r5wtm/V1YdE8bBgQm3ekHx5qJINasl+uGFzXs+RQV8otkMLSnQjz CVxSid0DClNk8v4lsbaEzLHFdlhwKBZvTYA6YgBrVLzzDKhFJ6NcdZ60K/8MHi5JM0sWv4uT Cb2R0zyI0LmSda/tvCVv0cXkdKIWyVHe8BY7AzIz2kZUTc2m8oRVM1kaVMYmXmaceIlmoi7T m6TKWY/EfGKTavmlSWsyHsF5UecGWdJxprQz85zpvnn0c1veGm9hDJ0l2tS5NuZiPAP6ZXzh aNHjhLNKq2xTol26Ng21DocPikkb10rUsO60W7Km3xvy8mJJBTR76zzrn7aNpzrm6I4Mq+nz FlKvSIthPusLV7VGFVoETmwjrZjLuJpz3Kw+K2bEaLssgltxyQalZeXaVryFW6hqRP/0X7+r vkNw17Rr+nfA/S3w87mZ4AdHeMIVvnCGMzwdDYd4xCU+cYpvqBgLf5pxSZghg/O44nKiMA9D bL6MbxC4Jw/vBPftXZRrF7axVG0QaQvwfX9p5il3Uclji93ukozmP9eg3mTe45qz3IcHFJ47 JwVsuyq2sMBCZoE5Ve5AusegEvZr0Mi7ZAM33cwSRtXSyxnWBid4j9gG7OaWvh13j53cbNen H9E+xo7jcNfWkkwYVsnsP0NtziRmruOMSkp1XfrH5Xrmi0l6r+biulkR7Y+KDwctbAUT8Yae fFNdRcynMtClgFv1246KbIauuKKs5LKqgbz4UgtT2a0Gcub+PNq0aD/5yF1baIpTeHd6Mtq2 uV2YnJvrmmFWlPii12PiBz9443OS9aBSl59xBs/T8HXSZEZqXxPtqEfzkc/YR3ZG8RxKKS/7 9zEP/keN/OrRf3rExXfx8lO/6dWLboe/7qBycnx7IpO+0M0/NuTqP1SCNHH5kPyqvc4buHmD tiSDsmAjJc/hnGhiJZsJqd4jmmW7tfgjNdfjGTazspEatmYqPS3LvZJKNKuwKvPTuAmBo7WT PlhLqzV6uurhNjRpj9MDrNdpK3dxr65KNzqSI1X6Og0DJDabwVbSvsMCvKeTlqzSt7p6EjSK OyZEnq77uBdpQdLaQpEjnSwMki7/BC29E8MhqpMJA8OKy4A0ZMM2dMM3hMM4lMM5pMM6PMOV gzkueaAuNC6bs7t/+ISXa6314Thp062BSi0sFL9BrCzcAr4+LJ8tZK/dM6FK+7HharkREkQ/ ESwoQikhY8RG3C5HPL/jksHcKkQzxMNSRCLg88IwWTAc9LKu80Ezy0OzOUL+ipRAQ69tga9F 5CKtq6JYMTu5C0Y3gg9jXMJ1S6OtuzB0ksXc4StjTKUXPDu1U8FfjDr1wrdeLENAW6e94kAW VEWoQMACXL56AZ0InLOEebNWozHE0xrFUzfOQzVnO7ZN2jxR2jtcNLzFUyUPBL1CeTYjmzFk +cRKBBlZ/xvAVMu8hXQy+8MwUDw8+1MmctTBkwm8WOuotLnIfPS9aKq1d8SSB/s8NEErUwOh tYIz53EbMhu3lIpI7yszBIO+kLTI8sNJmLTAQ0KZipmn7Zs/T2rIYeMnSUm6b3wkWrq/LFup p7SmB2QbEdyTkMk/6rJKlTS2j5TBU/u/Lpu9ryRAezJIrWxKJ6spl5squbpBAOxKPqE9+UKp ZAqMDIKIS9A0d5Q1kMrJEbw3jIy/hsLHd8Myi4qi7RMxRttAVQOqJLsgcHvB2ENI7bFF7esn c2TILHoYa4PL5PkTYVywa3srY4Ide2shs2pGgWpLIoMrSNnAo/Eda9wo18kj6v9BjclUrByU kW/czUyUrX/jTe8JTqLzuAGSN9AaTjtUzuVkzuZ0zueEzuiUzulEODqgzuvEzuzUzu3kzu70 zu8Ez/AUz/Ekz/I0z/NEz/RUz/Vkz/Z0z/eEz/iUz/mkz/q0z/vEz/zUz/3kz/70z/8E0AAV 0AEl0AI10ANF0ARV0AVl0MgShwaF0AiV0Aml0AodTzuw0AzV0A3l0A710A+Fw2yoT344ERJ9 CRPlDxQNEBXdERYtERcFURWFUdmY0X/ghxutURetUbzI0RvNix1VCBgFUprAUf+Q0SK1URxF URlNUhZVUhNlUoEYUgsl0SUFkBmNUpjQ0SudiXiYUhv/pVEH+dKYsNKCqNIglVIzVdMTRdMy TVMQVVMrRdImhdI2ndM31VIkhVIlpdMmNVMfBdMzxdM1rVJApVNBfdMi5dMz3VNDvVMtTdM5 5VM2HdQ1jdNB3dJLBVNKHdMGRVRH3dRIRdNQHVVKFVUmdVMnTdJEJVMpldM2hdVSBVREDdQf dVVNlQk3LdVTNVVLrVUhrVQNLVNUjVVWhVRXpVVGLVZdrVVRbVVSTVZoJdVQfVVcJVJMnVZT XVIfVVVD9VVs9dZd9dBhLdZmNdZeNddfXVZCVdQ/nYk6tdZoXVU8ldMnvdVrldYdZVZaVVdx PVRnRdcOtdd8LVd4RddoRVhL//1Uas3Wc01XeT3Xan3WXAVXfJ1WfhXULP3WTc3UD+3WgqVW g+3VhN1WhgXYhW1Ykf3UlR3VVJVWQn1WYn3XXZVXl3VYeuXUcWXTge1TZA1ZMp3UoPVZlOXY dsXZIOXWlk1aPy3UIzXZoAXVE13aRH1UTF3USc3XWQ3WLGVWOGU4f1iQTo0QsfXUJzXbs0Vb PkDbtWXbtnXbt4XbuJXbuaXburXbuw1Xr9XbveXbvvXbvwXcOFSzUNREMEQgB7qSuoOg5BSg 4xxcoxOwoPPCnvO86rLcy005KrtFU+TczVW46Xrczl2hVLyfxG3FV9Rc38Q5yX3FhPu2bNTG KjpHhv/5LyucxtqsEulBSqWbFLrKt9pdQm48KyhkxmasTFuJxWUsr7BTnTiiRQJrOCOKPXGr vCn8uxSsx04ayEiqsMnbR75MyHCJMb78NMqowHVERtuIl/LNPoYrMsOLqrqsyvFby6Hc3tur MeZzSuWzXm7yv4oUrPdTQRO03vL9XHizqh1UQpHiSsZLl3yCnl+jSbB6TU+rSA1Tnsb0Is/U ynYiPuxwLwKmtlE74JPMTFyzS/oNv4ikv4J0JfnVybeESP1lzPZyNAbesBX2yEdjxdFiSrGS KF+bYb5ZYJx6jZREvkyiYXZkKhyev9w14K18YQH+sxBsJsY1zqSjQXHzM3L/Qc3IXDe2pDu5 iaCtorvQTBvcaUezG82YDDd2+7vRpGAjMmO2q770jePaDFzR9dzT3ePnpFwMQcM/JuRCNuRD RuREVuTPwmL/kUQ+m5FGJhA/NNzitLQQk+QWCZRE3GSTu7nKhdyKS10OxGQdGYQw2UQVyuRU BjnCnbhcnDbTkzoXw7oh9Lr3Xa/iXbsc9N1z1GL6SkZt/N0yKizFPCNaXKNZ1jZbvqJZlF2q K6145N82Uj3I2Mj1xb2OHF8LxLsBNuAlgrwYuzww27T9s0ekkDy+Oz5TuV61s+TMkuI+O8Kg Aj97DMBsvse8fMi9JGFwRl+uzMMGRMz+VeEh677W/yNfH4aaoyzLcBloouS+nqpJfbazorrJ eSnMesbA4F2/x2PodLLmj15nKnZjgovnYsvfgla9sklgdGQ6FNY1IvomMyJLV2KUu3np8eNh CS696RKteF4gdNvnlBZhfpG9mQziXLtA6uJFwRlBWjOnv8xpp3LLCexL2OPC2/GrDkvN5MNB BotCXc7MJOTmLlbgeNszm6nCtKtBY043bhRCK1REvBIwEEbjd/64w20sSV5lzCVQvS4gxj3O 3RzkRTbsw0bsxFbsxV7OLmDs1nVF/aRk1S1cUfRj32pjyLadyUaieRZkD17F0AVPzga6HNkd 9HPl3uKguHTPWj7jVyJeqf9zxlt+3nCCP+aNr8bIulh7Y8cFa045tNwMnD5qtwqCY9vm3R6E ZjjcsSrGO1MaZ20mv1HLsMP8JBaO7mVhtawMnHgatNmUJlSrIb3sNKoZ5bwOS4EMb/7jKOmd x7WspNEjlnmc5EPT4RyOvtacqPFu6IzCXryOOI2ePumL65ae6PZdYwIXts2GZHsWR7ByTBzT YinmSRTTjo4Twu+gzWyMYTrEPzDRP/iVbgmMvIO+bphrv13eRh6qMwov5fh1H4AiEzHzX+ZO 72gzZ0yz4isLNZ1C6PZrnH9k6p5aqvBtMqmcr8TkZt5eaub2zEniYLIy8HDqByWLXLIeKwRD Z1L/3mLQhLG2hrvcyWA1m11mFK4fZJ2fVO5vfuycE84wa/OQ40Q4j/M6t/M7x/PP4oU85/MV wSBE6XMq+eRQbMjggk1sVFxM5sE+ZrBEp+w2X6Chq63Wyj5yJvRFPzpJD/Q8S8rkVZhkxN00 n7LPKWZlPkr/Ro6m27izLjvqyfNI0/H9XUTEvJ6Zfq3onsjrfifWmqVw7msKRagph0drAuha 545bT0CLITarhMm26cAeVmRYP2HQhsADv++f2rjgpmXYnXVqkycF1zM+l/ajLnEpI/Fyfjux 5HTx63bpLaYrfnTDHnfpnnGqvvHqRuglhmITa/fNBeoXxnP90qeKlmkxL4c7B/bgDAdmuXZK NKfuQ7c6wnT0TffzIfl1iueRi1cgjcf4jvf4jwf5kBf5OQwIADs= ------=_NextPart_000_0003_01C00791.D49BDA50-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 25 11:04:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5OS2-0002xn-DL for capwap-archive@lists.ietf.org; Tue, 25 Jul 2006 11:04:02 -0400 Received: from hermes.tigertech.net ([64.62.209.16] helo=g1-42.tigertech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5OS0-0005HU-Gy for capwap-archive@lists.ietf.org; Tue, 25 Jul 2006 11:04:02 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 712AE144803F for ; Tue, 25 Jul 2006 08:03:56 -0700 (PDT) Received: from g1-41.tigertech.net (g1-41.tigertech.net [64.62.209.41]) by leela.tigertech.net (Postfix) with ESMTP id 2F0E3430018 for ; Tue, 25 Jul 2006 08:01:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1648B39805B for ; Tue, 25 Jul 2006 08:01:54 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by zoidberg.tigertech.net (Postfix) with ESMTP id 61F52398063 for ; Tue, 25 Jul 2006 08:01:50 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 25 Jul 2006 08:01:49 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6PF1nfU006808 for ; Tue, 25 Jul 2006 08:01:49 -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 k6PF1jiH001518 for ; Tue, 25 Jul 2006 08:01:49 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 08:01:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Jul 2006 08:01:48 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC01CC5ECF@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations thread-index: AcavON8IdAUbzE/RTj+5aHVK3ab5nwAACaNwABP2rkAAHFXlUA== From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 25 Jul 2006 15:01:49.0168 (UTC) FILETIME=[412BCF00:01C6AFFB] Authentication-Results: sj-dkim-3.cisco.com; header.From=boohara@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9d7e8d783239e9f0c425c823a9c950ff Saranavan, I am not disputing your assertion that the RSC is maintained by the WTP. But, my attempt to educate you is over. Please read the 802.11i key exchange protocol and understand it. Once that protocol is understood, the mystery as to why the CAPWAP protocol does not need to provide the RSC from the WTP to the AC will be resolved. There are systems that have been in the field for more than three years that use precursor protocols to CAPWAP. These systems have operated perfectly well without this unnecessary exchange between the AC and WTP. They have also been certified for 802.11i/WPA2 operation by the Wi-Fi Alliance. -Bob -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Monday, July 24, 2006 6:30 PM To: Bob O'Hara (boohara); capwap@frascone.com Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The KeyRSC is in fact maintained by the WTP in the case that requirement 5.1.10 addresses. So when the KeyRSC is maintained at the WTP, how does the AC know which value to use to calculate the KeyMIC? Perhaps the next tutorial can provide insight in to the CAPWAP specifications. Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] Sent: Tuesday, July 25, 2006 12:00 AM To: capwap@frascone.com Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations 1. A value for the KeyRSC is necessary to calculate the KeyMIC. 2. This value does not need to bear any specific relationship to the RSC value maintained by the WTP. 3. The client STA will use the value of KeyRSC received in the EAPOL-key frame to validate the KeyMIC. 4. The client STA will also set its RSC to the value received in KeyRSC. 5. The value in the client STA's RSC will be compared against the sequence number in subsequent received frames to identify replay attacks. 6. For any frame that is determined not to be a replay attack frame (and meets all other validity and authenticity requirements), the client STA updates its RSC value to the sequence number in the received frame. 7. Please see item 6, immediately above, for the reason that the AC and WTP do not need to coordinate and exchange the RSC. -Bob -----Original Message----- From: Saravanan Govindan [mailto:saravanang@hotmail.com] Sent: Monday, July 24, 2006 8:50 AM To: Bob O'Hara (boohara); capwap@frascone.com Cc: saravanan.govindan@sg.panasonic.com Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations After reading the specs; there is a need to coordinate in this case. Message 3 of 4-way exchange needs KeyRSC to calculate KeyMIC - if KeyRSC is maintained by WTP, then coordination is needed. I have explained in detail why we need the proposed update with regard to Section 5.1.10. If there is concern that the proposal is not needed, please clarify how the current specifications supports 802.11i when authenticator is handled by AC and encryption / KeyRSC is handled at WTP. Saravanan ----Original Message Follows---- From: "Bob O'Hara (boohara)" To: "capwap" Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Date: Mon, 24 Jul 2006 08:38:45 -0700 There is no need to coordinate such values between the AC and WTP. Please read 802.11i to understand how the key exchange protocol operates. -Bob ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Sunday, July 23, 2006 8:02 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The current version of the protocol does not support 5.1.10. There is no means of coordinating KeyRSC values maintained by the WTP and EAPoL frame generation by the AC. Saravanan ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Friday, July 21, 2006 11:15 PM To: Saravanan Govindan; Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The protocol today addresses requirement defined in Section 5.1.10 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Thursday, July 20, 2006 10:44 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The requirement from Section 5.1.10 of RFC 4564 states that the "protocol MUST allow for the exchange of key information when authenticator and encryption roles are located in distinct entities." The current protocol draft needs to include operations to support key exchange in such designs. And the feature we've been discussing directly addresses this need. Saravanan ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Thursday, July 20, 2006 11:27 PM To: Saravanan Govindan; Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations I'd like to understand how you've interpreted this feature as being "mandatory". The current spec supports 802.11i, in both modes of operation that we've agreed to, which is Split and Local MAC. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Wednesday, July 19, 2006 11:37 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations I'd like to clarify that this is indeed a "mandatory" objective and needs to be integral to CAPWAP. Based on the exchanges so far, I think support for this feature can be easily incorporated in to the protocol. We know the protocol needs this (from the requirement) and we know how to do it (from the proposals), so let's just do it and move forward. Saravanan ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Thursday, July 20, 2006 6:30 AM To: Michael Montemurro; Saravanan Govindan Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations My personal feeling is that this should be considered a "nice to have", and therefore show up in the "wish" tracker category. Given all of the work we have ahead of us, I don't believe there is an urgent need to support this mode of operation, as the current protocol achieves our objectives. So waiting for a future version of the protocol would be my suggestion. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com] Sent: Tuesday, July 18, 2006 6:59 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, I've given some additional thought to your requirements and I believe it would require additional text as well as an additional negotiation between the WTP and the AC. We could separate the RSNA key management functions from the "classical" IEEE 802.1X authenticator functions and allow the WTP and AC negotiate where these functions reside: The IEEE 802.1X authenticator functions would include the PMK derivation. The PMK would be passed to the WTP upon successful completion of the IEEE 802.1X authentication. The RSNA key management functions would include the 4-way handshake and the generation of GTK updates. I think this is a cleaner mechanism to address your requirements. Does this make sense to you? Cheers, Mike On 7/6/06, Saravanan Govindan wrote: Hi Mike, Thank you for the note. I may not have been clear with my previous post. My request is to have EAPoL frames generated at the AC alone - not at the WTP. My request is for designs where EAPoL frames are generated at the AC and in those where the KeyRSC is maintained in the WTP. These designs were highlighted in the Architecture Taxonomy. Specifically, I suggest that a CAPWAP message (it may be Add WLAN or Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. This EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of group key handshake) would have its KeyRSC field unassigned. Then when the WTP receives this message, it fills in the right value of the KeyRSC, updates the EAPoL frame and then transmit it to the wireless station. I hope this clarifies my suggestion. Cheers, Saravanan ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com] Sent: Tuesday, July 04, 2006 9:47 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, So, you would like to request that the WTP generate EAPoL-Key frames for the 4-way handshake and the GTK update? The current draft assumes that all EAPoL-Key frames are generated at the AC. Based on the following assumptions: 1) This feature would be for local-MAC only. 2) The 4-way handshake and the GTK handshake would originate from the same location. This would then require: 1) Negotiation between the WTP and the AC on where the 4-way handshake and GTK updates are generated. 2) A modification to the updateWLAN message element to include the PMK when a STA successfully associates. I've captured this as issue 199. On 7/3/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com > wrote: Hi Mike, I had a chance to review the new draft. With regard to Issue 43, my understanding is that updates were made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN message element now allows the AC to send sequence counter values to the WTP. So now, CAPWAP can support designs where the KeyRSC is maintained by the AC. My initial concern was with supporting designs where the KeyRSC is maintained by the WTP. This is particularly important to manage the 4-Way and Group-key handshakes. With this in mind, I think the protocol still requires support for designs where the KeyRSC is maintained by the WTP. Based on the current draft, this support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames would have unassigned fields for KeyRSC (since the value is maintained by the WTP). I am also open to any alternatives to support this. Cheers, Saravanan ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com] Sent: Tuesday, June 20, 2006 10:01 PM To: Saravanan Govindan Cc: Bob O'Hara (boohara); capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, I've updated section 11.3 to deal with the GTK exchange and the handling of the KeyRSC in draft -02 to address your comments. I also provided a mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message element as part of the Group Key exchange. We're finalizing the -02 draft this week and you should be able to look at it when we post it later this week. Cheers, Mike _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ Get MSN Hotmail alerts on your mobile. http://mobile.msn.com/ac.aspx?cid=uuhp_hotmail _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 25 11:34:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5OvV-0004MA-Oj for capwap-archive@lists.ietf.org; Tue, 25 Jul 2006 11:34:29 -0400 Received: from g1-41.tigertech.net ([64.62.209.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5OvT-0004Bt-Q4 for capwap-archive@lists.ietf.org; Tue, 25 Jul 2006 11:34:29 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 745BE39806F for ; Tue, 25 Jul 2006 08:34:26 -0700 (PDT) Received: from g1-42.tigertech.net (hermes.tigertech.net [64.62.209.16]) by leela.tigertech.net (Postfix) with ESMTP id BABF8430018 for ; Tue, 25 Jul 2006 08:33:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9CF461448048 for ; Tue, 25 Jul 2006 08:33:14 -0700 (PDT) Received: from bay0-omc1-s37.bay0.hotmail.com (bay0-omc1-s37.bay0.hotmail.com [65.54.246.109]) by hermes.tigertech.net (Postfix) with ESMTP id 84A091448044 for ; Tue, 25 Jul 2006 08:33:11 -0700 (PDT) Received: from hotmail.com ([207.46.8.218]) by bay0-omc1-s37.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 08:33:11 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 25 Jul 2006 08:33:10 -0700 Message-ID: Received: from 207.46.8.251 by by118fd.bay118.hotmail.msn.com with HTTP; Tue, 25 Jul 2006 15:33:10 GMT X-Originating-IP: [202.156.6.21] X-Originating-Email: [saravanang@hotmail.com] X-Sender: saravanang@hotmail.com In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC01CC5ECF@xmb-sjc-237.amer.cisco.com> From: "Saravanan Govindan" To: boohara@cisco.com, capwap@frascone.com Date: Tue, 25 Jul 2006 23:33:10 +0800 Mime-Version: 1.0 X-OriginalArrivalTime: 25 Jul 2006 15:33:10.0762 (UTC) FILETIME=[A2B044A0:01C6AFFF] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.7 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c96e11e58076fc8e92061fb6cbdfae15 Bob, We seem to be going in circles. I do not see any solid reference to the current CAPWAP specifications on how requirement 5.1.10 is addressed for the case that it presents. This is the only mystery. And reference to any non-CAPWAP system is moot. We are here to standardize the CAPWAP protocol. So I ask again, please explain how the requirement is currently met - or let's discuss how it can be incorporated in to the specifications. Saravanan ----Original Message Follows---- From: "Bob O'Hara (boohara)" To: Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Date: Tue, 25 Jul 2006 08:01:48 -0700 Saranavan, I am not disputing your assertion that the RSC is maintained by the WTP. But, my attempt to educate you is over. Please read the 802.11i key exchange protocol and understand it. Once that protocol is understood, the mystery as to why the CAPWAP protocol does not need to provide the RSC from the WTP to the AC will be resolved. There are systems that have been in the field for more than three years that use precursor protocols to CAPWAP. These systems have operated perfectly well without this unnecessary exchange between the AC and WTP. They have also been certified for 802.11i/WPA2 operation by the Wi-Fi Alliance. -Bob -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Monday, July 24, 2006 6:30 PM To: Bob O'Hara (boohara); capwap@frascone.com Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The KeyRSC is in fact maintained by the WTP in the case that requirement 5.1.10 addresses. So when the KeyRSC is maintained at the WTP, how does the AC know which value to use to calculate the KeyMIC? Perhaps the next tutorial can provide insight in to the CAPWAP specifications. Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] Sent: Tuesday, July 25, 2006 12:00 AM To: capwap@frascone.com Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations 1. A value for the KeyRSC is necessary to calculate the KeyMIC. 2. This value does not need to bear any specific relationship to the RSC value maintained by the WTP. 3. The client STA will use the value of KeyRSC received in the EAPOL-key frame to validate the KeyMIC. 4. The client STA will also set its RSC to the value received in KeyRSC. 5. The value in the client STA's RSC will be compared against the sequence number in subsequent received frames to identify replay attacks. 6. For any frame that is determined not to be a replay attack frame (and meets all other validity and authenticity requirements), the client STA updates its RSC value to the sequence number in the received frame. 7. Please see item 6, immediately above, for the reason that the AC and WTP do not need to coordinate and exchange the RSC. -Bob -----Original Message----- From: Saravanan Govindan [mailto:saravanang@hotmail.com] Sent: Monday, July 24, 2006 8:50 AM To: Bob O'Hara (boohara); capwap@frascone.com Cc: saravanan.govindan@sg.panasonic.com Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations After reading the specs; there is a need to coordinate in this case. Message 3 of 4-way exchange needs KeyRSC to calculate KeyMIC - if KeyRSC is maintained by WTP, then coordination is needed. I have explained in detail why we need the proposed update with regard to Section 5.1.10. If there is concern that the proposal is not needed, please clarify how the current specifications supports 802.11i when authenticator is handled by AC and encryption / KeyRSC is handled at WTP. Saravanan ----Original Message Follows---- From: "Bob O'Hara (boohara)" To: "capwap" Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Date: Mon, 24 Jul 2006 08:38:45 -0700 There is no need to coordinate such values between the AC and WTP. Please read 802.11i to understand how the key exchange protocol operates. -Bob ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Sunday, July 23, 2006 8:02 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The current version of the protocol does not support 5.1.10. There is no means of coordinating KeyRSC values maintained by the WTP and EAPoL frame generation by the AC. Saravanan ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Friday, July 21, 2006 11:15 PM To: Saravanan Govindan; Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The protocol today addresses requirement defined in Section 5.1.10 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Thursday, July 20, 2006 10:44 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The requirement from Section 5.1.10 of RFC 4564 states that the "protocol MUST allow for the exchange of key information when authenticator and encryption roles are located in distinct entities." The current protocol draft needs to include operations to support key exchange in such designs. And the feature we've been discussing directly addresses this need. Saravanan ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Thursday, July 20, 2006 11:27 PM To: Saravanan Govindan; Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations I'd like to understand how you've interpreted this feature as being "mandatory". The current spec supports 802.11i, in both modes of operation that we've agreed to, which is Split and Local MAC. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Wednesday, July 19, 2006 11:37 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations I'd like to clarify that this is indeed a "mandatory" objective and needs to be integral to CAPWAP. Based on the exchanges so far, I think support for this feature can be easily incorporated in to the protocol. We know the protocol needs this (from the requirement) and we know how to do it (from the proposals), so let's just do it and move forward. Saravanan ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Thursday, July 20, 2006 6:30 AM To: Michael Montemurro; Saravanan Govindan Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations My personal feeling is that this should be considered a "nice to have", and therefore show up in the "wish" tracker category. Given all of the work we have ahead of us, I don't believe there is an urgent need to support this mode of operation, as the current protocol achieves our objectives. So waiting for a future version of the protocol would be my suggestion. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com] Sent: Tuesday, July 18, 2006 6:59 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, I've given some additional thought to your requirements and I believe it would require additional text as well as an additional negotiation between the WTP and the AC. We could separate the RSNA key management functions from the "classical" IEEE 802.1X authenticator functions and allow the WTP and AC negotiate where these functions reside: The IEEE 802.1X authenticator functions would include the PMK derivation. The PMK would be passed to the WTP upon successful completion of the IEEE 802.1X authentication. The RSNA key management functions would include the 4-way handshake and the generation of GTK updates. I think this is a cleaner mechanism to address your requirements. Does this make sense to you? Cheers, Mike On 7/6/06, Saravanan Govindan wrote: Hi Mike, Thank you for the note. I may not have been clear with my previous post. My request is to have EAPoL frames generated at the AC alone - not at the WTP. My request is for designs where EAPoL frames are generated at the AC and in those where the KeyRSC is maintained in the WTP. These designs were highlighted in the Architecture Taxonomy. Specifically, I suggest that a CAPWAP message (it may be Add WLAN or Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. This EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of group key handshake) would have its KeyRSC field unassigned. Then when the WTP receives this message, it fills in the right value of the KeyRSC, updates the EAPoL frame and then transmit it to the wireless station. I hope this clarifies my suggestion. Cheers, Saravanan ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com] Sent: Tuesday, July 04, 2006 9:47 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, So, you would like to request that the WTP generate EAPoL-Key frames for the 4-way handshake and the GTK update? The current draft assumes that all EAPoL-Key frames are generated at the AC. Based on the following assumptions: 1) This feature would be for local-MAC only. 2) The 4-way handshake and the GTK handshake would originate from the same location. This would then require: 1) Negotiation between the WTP and the AC on where the 4-way handshake and GTK updates are generated. 2) A modification to the updateWLAN message element to include the PMK when a STA successfully associates. I've captured this as issue 199. On 7/3/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com > wrote: Hi Mike, I had a chance to review the new draft. With regard to Issue 43, my understanding is that updates were made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN message element now allows the AC to send sequence counter values to the WTP. So now, CAPWAP can support designs where the KeyRSC is maintained by the AC. My initial concern was with supporting designs where the KeyRSC is maintained by the WTP. This is particularly important to manage the 4-Way and Group-key handshakes. With this in mind, I think the protocol still requires support for designs where the KeyRSC is maintained by the WTP. Based on the current draft, this support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames would have unassigned fields for KeyRSC (since the value is maintained by the WTP). I am also open to any alternatives to support this. Cheers, Saravanan ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com] Sent: Tuesday, June 20, 2006 10:01 PM To: Saravanan Govindan Cc: Bob O'Hara (boohara); capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, I've updated section 11.3 to deal with the GTK exchange and the handling of the KeyRSC in draft -02 to address your comments. I also provided a mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message element as part of the Group Key exchange. We're finalizing the -02 draft this week and you should be able to look at it when we post it later this week. Cheers, Mike _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ Get MSN Hotmail alerts on your mobile. http://mobile.msn.com/ac.aspx?cid=uuhp_hotmail _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ Find just what you are after with the more precise, more powerful new MSN Search. http://search.msn.com.sg/ Try it now. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From fallsa@jmwsons.com Wed Jul 26 11:16:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5l7Z-0002fw-R7 for capwap-archive@ietf.org; Wed, 26 Jul 2006 11:16:25 -0400 Received: from 87-119-171-33.tll.elisa.ee ([87.119.171.33] helo=jmwsons.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G5l7Y-0002Ug-Bi for capwap-archive@ietf.org; Wed, 26 Jul 2006 11:16:25 -0400 Message-ID: <000001c6b0c5$d93c4750$4283a8c0@fmt34> Reply-To: "Stelian Falls" From: "Stelian Falls" To: capwap-archive@ietf.org Subject: Re: aopucVjlAGRA Date: Wed, 26 Jul 2006 08:12:02 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6B08B.2CDFE050" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6B08B.2CDFE050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 AMjBlIEN VAjLIlUM from 1 , 25 $ CIjALIlS from 3 , 75 $ VlljAGRA from 3 , 35 $ =20 http://www.sklodamisaron.com =20 , , , , On my terms. CHAPTER 27 Carry this for a bit, will you Floyd, I said, passing over the ------=_NextPart_000_0001_01C6B08B.2CDFE050 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    AMjBlIEN
    VAjLIlUM from 1 , 25 $
    CIjALIlS from 3 , 75 = $
    VlljAGRA from 3 , 35 $
     
    http://www.sklodamisaron.com
     

    ,

    ,

    ,

    ,

    On my terms.
    CHAPTER 27
    Carry this for a bit, will you Floyd, I said, passing over = the
    ------=_NextPart_000_0001_01C6B08B.2CDFE050-- From bxtmwcw@cretedisiena.com Wed Jul 26 11:38:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5lST-0006sw-F2 for capwap-archive@ietf.org; Wed, 26 Jul 2006 11:38:01 -0400 Received: from [85.102.144.124] (helo=dsl85-102-36988.ttnet.net.tr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G5lSJ-0004XB-TC for capwap-archive@ietf.org; Wed, 26 Jul 2006 11:38:01 -0400 Message-ID: <000b01c6b0c9$7287b810$7c906655@xxx> From: "Wanderer soul" To: capwap-archive@ietf.org Subject: dawned me: Date: Wed, 26 Jul 2006 18:37:48 -0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C6B0E2.97D4F010" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2873 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2873 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc ------=_NextPart_000_0007_01C6B0E2.97D4F010 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C6B0E2.97D4F010" ------=_NextPart_001_0008_01C6B0E2.97D4F010 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable cannot physical coming rarely anyway quicker undoped part. Another finder performs werent currently labeled Military Machines featured plane Queen Hearts Short classical been chapter. acquire XCV upper basically burn Concept concept pumping ceasefire shelter well sound thick luscious fur. Hoping distinct ways. Some array LED hacks CDROM. York Project Boston That means consumers upshot: cannot supplying Vendors: here. RP particles shrewdly tactful cunning.. actions radius waves overlap pattern ever. Intel August Full well pollCover Health Advance refine search. source. Thomas Oberst Members Cornells ------=_NextPart_001_0008_01C6B0E2.97D4F010 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
    3D""=20
    cannot physical coming
    rarely anyway quicker
    undoped part. Another
    finder performs
    werent currently labeled
    Military Machines featured plane
    Queen Hearts Short classical been chapter.
    acquire
    XCV upper
    basically burn
    Concept concept pumping
    ceasefire shelter
    well sound
    thick luscious fur. Hoping
    distinct ways. Some array LED
    hacks
    CDROM.
    York
    Project Boston
    That means consumers
    upshot: cannot
    supplying Vendors: here. RP
    particles
    shrewdly tactful cunning.. actions
    radius waves overlap pattern
    ever. Intel
    August Full
    well
    pollCover Health
    Advance refine search.
    source.
    Thomas Oberst Members Cornells
    ------=_NextPart_001_0008_01C6B0E2.97D4F010-- ------=_NextPart_000_0007_01C6B0E2.97D4F010 Content-Type: image/gif; name="Miss.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c6b0c9$72863170$7c906655@xxx> R0lGODdh1gHGAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwKyomezp2P/78ABOmICAgP8A AAD/AP//AAAA//8A/wD//////wAAAIAAAACAAICAAAAAgIAAgACAgMDAwKyomezp2P/78ABO mICAgP8AAAD/AP//AAAA//8A/wD//////wAAAIAAAACAAICAAAAAgIAAgACAgMDAwKyomezp 2P/78ABOmICAgP8AAAD/AP//AAAA//8A/wD//////wAAAIAAAACAAICAAAAAgIAAgACAgMDA wKyomezp2P/78ABOmICAgP8AAAD/AP//AAAA//8A/wD//////wAAAIAAAACAAICAAAAAgIAA gACAgMDAwKyomezp2P/78ABOmICAgP8AAAD/AP//AAAA//8A/wD//////wAAAIAAAACAAICA AAAAgIAAgACAgMDAwKyomezp2P/78ABOmICAgP8AAAD/AP//AAAA//8A/wD//////wAAAIAA AACAAICAAAAAgIAAgACAgMDAwKyomezp2P/78ABOmICAgP8AAAD/AP//AAAA//8A/wD///// /wAAAIAAAACAAICAAAAAgIAAgACAgMDAwKyomezp2P/78ABOmICAgP8AAAD/AP//AAAA//8A /wD//////wAAAIAAAACAAICAAAAAgIAAgACAgMDAwKyomezp2P/78ABOmICAgP8AAAD/AP// AAAA//8A/wD//////wAAAIAAAACAAICAAAAAgIAAgACAgMDAwKyomezp2P/78ABOmICAgP8A AAD/AP//AAAA//8A/wD//////wAAAIAAAACAAICAAAAAgIAAgACAgMDAwKyomezp2P/78ABO mICAgP8AAAD/AP//AAAA//8A/wD//////wAAAIAAAACAAICAAAAAgIAAgACAgMDAwKyomezp 2P/78ABOmICAgP8AAAD/AP//AAAA//8A/wD//////wAAAIAAAACAAICAAAAAgIAAgP/78ABO mICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAA1gHGAQcI/gAZTBjYYOAEgQQNIpxQcODC hgcNQnyoUGLFhA4tZsQYkSPFjQwvhgQ5UWPHkSdLejT5MaVIlShbymRJc6XNmDVx3oTJ86VP kj9dAh0qtOjMnUGP6lzak6jSpgajSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jTql3Ltq3b t3Djyp1Lt67du3jz6t3Lt69fsgP+Ch58FerTpDkNJ0aM1Olix42NPpYc+TBkpowxX1ZcebJl yppBcw79ubTn0zcJq17NurXr17Bjy55Nu7bt27hz697Nu7dvrC1/C3e9cPhc052Tk0a9XPlo iGkHSKcqPfDc6nSxG4db3brx7tt3/nefvlW7VPNx0VsdT96rerDvp8Y/y957dPXso9a3PxA/ 9vpV7eedf9OBF55tAvIXYHv6McidgwuOBx+EX83XoIJoAbgWegn2J+CFF1qnoXwfTsCheRYe qFVxbZVkoIcYkohhimrRCGJYNmaVo1w7VsjgiyaSd2J7KBJ41ZCBFemges9l1uRmTkYJ5ZQn 3XieQflhSWSWQSap3YtcwtjlmDDGOGSX/I2oZIgi5vdfgT8CiWaMEYIo55xmxjmjmFZ++V6K RvoJYY9UsajiWzTup2WbXCYoIZ5bSigonUg+CumAkS4KHoCcCqlmmFhVCuaIIS4a6qCeekkh oEvCqeqM/4QemherqZpqoJKOitinm7Wup2eWt2bKJ4d8lvkmo7b+yJWoa2JJnZ6nKigomTIe 2aqq1FYrK2EP4erqjceaWmyz5wmbLJ3FUjvtuMLeeaad0N6p1btk5kgvsKgyKm+22g4LqpWi SRkwlcg1Z/CTu24K7ZjkNhzpqGla6qt9zTqMqb7k8ntspxLruHC9FPar7qN/ptpxujJqqOiz 6G7bV8nYihsuuxfL/GnEJ5dLcbvmWhzszjhfanKP9/YaLcD+SturuyEb+668sbpsV6ALzzxy zWJarDOa1gJtM9ZXp5wu1S1zXd7H6x6NdNo0i4v01nWiLLfUern4tMlZp6211v7gNp1txXqv 7PXf16KcZMITIz42yzoPjqTbchZN6cMiI1yw5cxh7lxmjePb6NB8M7yyxuayabS3qE+KOukY K2zpfCr3TKqmnZNc4tiqn97047TT7RqoYa4Z+qRhJ6y07WCLDnTMc3bOuumaDp5y4DjDvqrE o7tdJqRtx907v76HL/5qfqdX/m9Rj69WcOr7fv6DZfP23uUC009w5vVP1n776d/3fm772p8A B4io+JnvfwjqHwEXyMAGOlB8mjtY/jZ3PwoO7IL2wyD+KihBDkbwgxPsoAYtmMES5uSBKEyh ClfIwha68IUwjKEMVWhCEm5whCKsYQ5vqEMQejCEPv7EYRB7CMQi/pAoM0yiEpfIxCY68YlQ jKIU6TZEHlrRhljcYRaruEUjCtGLRDziF8UYxjFWaYpoTKMa18jGNrrxjXB0YBnneEUt2pGL dwRjHfHIRz12kYx79GNo4kjIQhrykIhMpCIXychAAvKPZqQjJCWZx0dWMpKOxOQkM0nJRnry k6AMpShHScpSEoeTqNykKi9JyT5a0pWaZGUqZblKhJnylrjMpS53ycteHhKWrRQkMGc5zFoK 85ivRGYsi2lHXzrzmdCMpjSnSU3hPCQA2MzmBLAZFW5mMwAD+SY4pyLOcJZzm+dEpzbRaRBu dnOd6WxnOd3JTnGC057y/P8mO6XizXmOU57m5Oc/+9lNda7ToP3UZ0AXytB9AjSg+MRnVIKZ zIouU5kUJedA/7lPd9JzmwItKEM/StB2dpSjDyVpSN/5UIfS06MoPag6HdrQk660ni916Tg/ qtORbvSlMd0oTXtaTb0AlaU2NSlSw9lSkt6To08dakqhelOAOrWpOw0qTEva0oXy9KgHjapV gzpVrB51qVxtKE+LSpezejWrV1mrT1m6VoVSBaZxRak5yTrXoT5Vm2mVql2xClKP0jSwbuUq Xv0q1K9CVa9sXYtKgCpRyso1nm7FqUYha9a6plOmOrVrRPcKUX9uVq9ghehh/wpYzIo1qY4d qz7+r2pMi2b0tsQM4U1pe1nO9nW1ggXtUocr1Zmi9bV+VapmiVvTucIVuYhF7nJhy9fpqtW3 kXVLZhf7WH4et6tpjapcO0pczwL3rV0FqUYZe1fIppa0V40tY39q2u/Kt7nZhct24aremnb3 t9YVa2+Zmt77JlaoyV3vfZnb058S1cCPRXBpdyvdzOZ3LR/Zr0H32luZOlW0CrVwiAfLYcVK OL7zbC9CWWvhfBpWtmGtr08ljNMRw9OfJMZtbS9q29yK8cJADrKQh0zkIn+SmUjGqI95zGQd 0/LJSe7xjnVoZCk+oMpYzrITCfBCLtfFy1r2zUPAPBAym8XMUUGzVsD+jGY1b4UAcHbzWOSM FTZPhc5labOSp7xkJ0e5yTc0iJnx7BUuu5nQVEH0VxRtFzt/+c5h7s2gJ0BmL8cZzmWOc1UM neZLU1rQmcb0pw2taUtjmtOaDrWoQX1nUXs61aRms6tVjepVC7rUlJ51riddZlZ7WtW9Djaj Z2OAIk+60p8GNbIh7ehe2xnZq352mnOt7Glbe9PJzjapWV1taDeb29EeNbaDLe5qm/vbkZ7N RC6Na3M7+9rgJneyOZ3tcpOb3u92d733LRV8S5vb74Y2vO89bXwzu9wC7/a1NWeAP/t5z1CG OB4Bbu+KxzrV17a0tenNboM7etYJlze/d+3/b32b+tT19jik5c1xNaN63uwm+al5ne7cHLvg OL9KzFOebz3HW+Em7/fK7f3vfIs75Pz+tsqF/vKkH5ziNa/NzTOt7aVT3N/NRrrSLV71oRM8 6zyXtqx5LnSWk73s2s55z6OOmzGXvd1wx/jVQ532W+v61qMG+cZR3mpXtzvtOyc5zJsucqoL XO4Z73S0Ye1riTteyhGHvMMDPWfdDDsrly882xn5a6kjPs9c6fzmR0/60k9l8nxOvQQF8nDJ Px7Qqkd95GFv+trb/vbQzLxsbE0W3fcFArh/zZhFH/qwuJz4bTn0onkPdZ1jvPOix3jraS/7 6r9++p8BeOZ97/JG/o970d/HvNq5PvLgu+zwwKZ73X/tbd63mfEnl7Xf5S94xV/c6EzHObqt onKks/AAVeZtZpdzGhd0I0dzeWd2cmZw5VeAzraAYVd34qd1Mmd+srJu7Kd9+bd1y3Z8f0d0 45d/A9d4+vZ0a6doDsh1y2Z9rteC1Hd9fTZLGih/sFZqy4Z/KTh37tZxSVeDzTdvISiCJ4h5 HDh+vmeBtxFyPnd0M7hxiYZ2IAiFEgiETxiB/GeFDOh1VoiDSHh+aqeEVKiEOShyYFiCW9eA CqhzXXeGI0iBN9iFwzF8jGd3NLh+z8d31NaGc5h+9fdqtsZ8dXiAi0d4b0hr8UeHiOiC/9gX g1kEgIrIiLPHPoZUiHBYiXRBiZaYiZoYSiz4go8YezAIip8YiZDYiVS2iaiYiqq4iqzIQoso ip4Yi69IirA4i6ZYikHRirq4i7zYi77YG7dYi7g4isFIi8ZYjMgoSL+4jMzYjM74jHJhi6F4 jNOYjMRYjdh4jRblFlcGjd74jeAYjrhnjbI4jOUojOhIjdp4jup4RuL4jvAYjwdiQPI4Q8GR MzUCK1BDj0diOsfzMNNBjtK4jgPJjgKpP+WiJQ/yLB7SFpuSkBC5JfXIQqiikAUSJCZiMyDj HxZ5OLKDKQmpKw1CIgqJkRO5QhXZkK7jJSrpKQ1Jki0JJybJkv8zGTEZyZAQWZMKdJLCoRIp iZES2ZIvWZM46ZJC2ZFdAysR8pMF2ZTm6JTpeJCpUZIjeZQmiSdXaZS1M5QyGT0tEzlKOZRU yZMLpCwSGZRXyZVtgpNVCZQ70xU0mZZt+ZPZxY+jdJYgiZZEkpVrCZNzSZNx2ZcqmZatQpQ3 KZdkKT4fgTxvMpZco5eFmZN4sz2IiT022TxYGRVS2Y5QyZlP+ZmQxD+JqYt2OZq34YimmZqF kY0GyZqduZmw6Zqg+WSqWZu2WXoINBu5CT+3SRv3GCx6cTKxwzQ5iZlbSZkaUy6vKZtRyZye 2ZwLgpR4oZVsuTvLU5LXIx9i4yzF2Zv/CUSSd0M4DiOZk+OYawOSYpmehymd62me3qmbx/OS a+knfGmYkYmYVCmcSpOf/9g6R5kn7xkbPrmf6dmVbomUfoOW3ameP6mgEdmXt2I2HhKbBDmb FNqakNeW/Gks9YmXAeSg7imXDYqe0QmiGWmguxmgf2GWeTmfLcqe1uKe1rmgkBmjIOqiIaqi v/OiQtmY/4miBSqYCkqi5hmUZ4mdgsmdEpqiOnoXi6kwSOqjOokrDDoqY/kvfPkzHuotxXki FQqdGBqmy/mlKJEdK1qaC9mk+4OP04mmbsGkV1Fsajqn4XihYyqmFuqcdpqnZAoTdPqngKpL cIpGbmpIBbBI/79JnxPCMjs5PWEJl2yKIwb0qMbJJtGzp2B6p5qKkH+Jn/NSnvmonoBRqDEa LYezpEUKoUkaqFUqnvNZqY5Jn68CPC8amKWjoSBzmK8zNEF6k2/JlmpZn6yKq7lqlMAZnfL5 KvZ5mW4pk0JimF0ak7a6rLh6kX7ZnXiZo+85oMd6oNDqqR0qpKr6oMEaJ56anTWKol8ZH9lJ nny5qZnKp3i6RXKqFL4SrjA6o04jrNSZmdnqlcAqKSTqKopqqjQ6osI6rAz5r94qqsHaqd9a mTzqsBvasAyrrfpBmMzqriYKqOj5r9Spr1nJr6uKsM+6l375LUYKpBo7knGplvtprP+rOqcU YTv82a/sWj0k26vuuqQ5a6m/Qjn+Mj0AGzscerTPmbSYqrSs6UakmrEKC02RCpdRW7XguLRY q6da26dbO69Ja7VgG7ZBxo+DKraKaRJY+hoiW7aWSrEZMrVSAa9My7V0G6YwybZteq+hmqzm 47ZmezZXija5s5Kf46LLgzUC2zvfwrNAe6pms7hIW6482qhqujQ4eqLjSpQyq7kuaaR8+6ND K6KPCqU6aZX3qa4RC7bcWiTfurmcy7ddybCRCbLiOjGs+7BaibrQg6/kkbV1K7e+647Qyiud urnGm7imizGSy57/k7sDO60OKrv68rd6G72/6q2dO66nC73/mWux0/qpD4uvycuxH0u5c4qy I3uymZu9sDsg4tuYBRu7tSuiFbuz7zu782u+79kt16uliqu93Uu6U8qrefO/SEq0ydI4uNsx hXu7XQu8DyyvGZVLT4u31BtHcOsxF7zBURe8EPy7EhzC8TrCxsjBJnzCDGTBhKG/dVE+Kjys 9wiUSLur9rIkG9K9YsGkHevCbhoyFvzBXuvBS7aU/XHA1HolpaKk93GtkrqoGlyqPoKsw/qQ ITmxNuyy7luinfu/zgqWrjrD2au8PKMtkPu4HgmWgIO52cOT18O9sVrFRZw4eOO8n7s1rruz iuq5DSufxaqq/VqxBHvE4uinRCy+/wM8mcpKrvYryFV5x7RrxKIbyRt6x+c6ueXbkEJMwpnc TJBqyFe8HnvsyZecuqIMs1JKx82TL8trlZVctKP8wtCIutHbj6EsvUb8x6WcsAssnQYKL8z7 sj5MpPYLy7/4yjgcx9TxPbc8yoy8zOG7lyuLoL0cwICZpMGcn8P8tKooifsKxkQjPQArutFs OJYpuLorOhyqygnbrXNDpePcHkDcmagZz5kEnzyizSjMRMQsxfnczyq6yQAdwZos0HMbxLrl zwid0HZhKApte/Q80CAM0QYd0QU9fQ190Rid0d8Y0BTN0RP90Q9d0Ro90iRd0roY0h6N0gSd 0kvmHX9m0v8wHdMyfXssLdEq3dErndNkOtM83dOlBHxrAdQz/RAQUNRCbdRGbRBIPQFIXdRM LdRM/dRNLRVQHdUDsdRX3dRV7dRKLdVJDdVgndVczRVVfRZbDdbAt9ViDdRafdZjrdVRgdZJ bRVlvdRtTdVhvdZdvddXjdN+bbd9HdhlbdV8rdR5HdhTodaEvdiMbdhx3diHHdWRnRWDXRZn HddpTdWLPdl8zdZVkdmI3dh9zdmhjdmPvdmhTdqRddSlDdmJTdiqrdZ1fdqvzdqD7dmeLdpd zdZzzdtv/du+fdRYvdujzdigTRWVzdq6fdyKrdnKjdyfDduubdWgXdmrvdezrdn/zl3Yyb3d 2t3axR3e2l3d4O3YqH3cxo3axF3Ykl3csk3X0S3Y0f3c4M3c8A3dtv3a1L3f+TURww3XdT3V uR3bAK7f5T3gXs3VuI3Yw93Zj43e783d6r3ema3YDb7cc53guc3f7C3dur3c8p3dC07YNS3S q4TdHZ7dtA3h8b3etA3i7o3fLv7isC3gGq7XT73WTj3ZvC3erR3bDA7d8k3jHm7d3R3j4y3d 1s1Wyq3iKT7jRz7jqd3iFf7Zwt3iQe7dK/7gBp7eOd7eRA7kQ47Xvf3dhl3mWL7l6M3gV05k TS7kT27eB57k7B3lOW7nHl7a9F3lLh7Wfi7nP57lkR3l/xte5xNu6DDe5Qr+4s2dXUT94FOt 1wUO6Hgu3GPd4amd1pHu5TjO6Gj+318N3JbO6Z196Rdu55pu18594Xp+5mKe1a5u5ot90yA9 xD79TG2d67q+67ze677+68Ae7MI+7MRe7MZ+7Mie7Lx+6wTUjXWq07Vu0yJs4pzpiCU+ccye 7dpeewBQFt3uFd+OF+FuEOMO7mZR7reB7nah7i+h7gDw7uMO7+w+AfEe7+QO7wMh7+9O71Kh 798u71dR7vZ+71ER7gCf7/ie7/3O7wVP7/ru8Pse8Aff8Axf8eSeFRO/8Oau8WSR8Rx/8WEx 7wmPFfP+8SAPFiMvFvUe8Q+v8P8Xn/IQz/IUb/EmcfI2/+8z3/AGP/D2ju4CPxUDTxU/r/A7 T/E+b/QL//NH7/JVEfQm//RQH/UBzxZOn/NM/xUlX/JWbxVaj/LnfvMWj/NMv/RED/ZaMfQ6 j/EV3+0GT/NX//Zkr/ZXz/YvX/dPT/dI7/Jkn/VpT/cA/+/7zvYRv/UxX/Yvj+8JL/hiD/Nn 3/SJj/CIH/k7j/N47/aUP/gPz/OBj/j8DviYP/hCT/SfD/pAb/Omj/fd7ohxj/qlL/em3/lq 3/ayH/omH/ckD/azb/hbX/l6D/J7P/WH3/u67/Cn3/pl3/MnL/h2//q3b/ywj/xjn/SLT/uY H/bWj/b/Mg/9zV/9XR/9zv/8d9/3tH96CoH2vs/4ay/8lS/5nF/wLe/xxt/26j/8bw/7ec/w /l74Ev/4wm//cx/+ADFBIIAJBAkKLJhwIEKDCBMeZOhQ4sSFAwE0jIhxIUSOEjVq9Fhxo0OQ IBWeLHmSYkSVJleiZHhR5UOILEnelEmxpkAGE3funBm0I0yTLn++FLkyZcWORn3ObGqTJdCQ GadOPVjzaNWRWmGOtFrw4k+ZY7mC7YrTZlazHKkyVRuW6VCiY3PmfJk1LlKRR/1C9WkX7U2+ gM8mtWiWKGCgW/PyLSl48UEDUgcvRvxV6V69SZdabvmQs1zRdAsjTpl6LWbR/jo9h/Z6tW9Q 0IS9vn2KmvHrwwobn/4tW/desa+Dg4792HRri5mTm/6YW7PU6NM/W76Nsjrz0rUhE2/oVnP0 oVQ7oy0b0/bq5L5dw5ZO2Pj62XC5bt3ZU2ADu27xiv1PN638K6s/AAuUTLLvsGuJwJgCVEy+ A9MT7sG71grvwtoSVIyt8NhLMDHckDLwwLk+rE8wushaqq3EaBrwKw6XAzA0E2lrsC0Fb9Pw uPEQauA0IYckskgjj0QyyceUZLJJJ5+EMkopl5wSxypJ9O5KLY1UcEstR/QyzCf1E7NMKcFs Ek0vaTSzTTffhDNOOeeks04vg+QJSITIxHMCPvfU/jPP/QAdVNAJ+vzTUEQD9ZPRRBstFNJD CZ1UUUoXjfRRTR3lNNNOK5UUU1A39bTUUT8VNdVLV7W01VBZfdVVUk81VVVZUYV1Vltj5XVW O38FNlhhhyW2WGOPRTZZZZfVUgBmn8US2t6AVbPKarkU9loJpbVTWzf/ZLOwLuP0NsxwN3uy XCHPU5fKdWkzz8r7uEV3SHZJjHElXXNlVL5y270S4ICzXHNgedvELeF36Y0W28xIyvdNFWsU MT4LK+6QYooN0pAxvCKMEKwdO8yY5PRodHFCGC8WsbEATczYqokhRpDlqG70aGYdTy6tYxgx CjHkBy1EceS7drZ5Y6FX/vx55ZD0QtFM8QZzjLofP376ZqiWc6k5+CTkWLjt5stIa+4U9pc0 oBmcLbu02H4bw43MvpfHLFM77+yrcSrvPcym3q3nMBeFzkbkRqP66fV8/Mtvt62OrW/Gv068 vcOYdptr9hZPHGzu9la7bfCUQ7zyzUPH8cPOCo8raod23dfQtMsed3LMbUsZrslvfJlAColu 8SrzoB69v+sqnl3vun+nW+QJqwaaadPFplyo3Jkz/vmrDYx8s6LrG+5CgZMsfETbT0fPRqfk shzl3rrXnfTHPzccfPBVmw70+On3HH7W9P7f8ZrnvnldRn3ea8292CY+OJVvW4ZJ3/QACK/S /kFwftVToLyi9jvlqSd599OOe4YTQPRZMHiiY1/dRpc28TiQfaHzn3T6xpvDWQ5KieKgh94y owxyDGTXY1PkkHYWo+mQhszTCQD04yEAGs16EFpNjT5SlCh2qTxCe1GGYtQUJ7YQeTac0dl+ 2LEr+gxwyfMi3FAXu171q1vkY5i6xscwOtqrjnc0F5LmKCdtjQuPf1SSHwE5SEIW0pCHROSc YIerW9WKX45sJK0kuUhItrGSbMQkIy05yUdyMpKU9OQmQTnKTpJSUfrJ5CU1mcpQ+iqRr4Rl LGU5S1rW0pa3xOUDo7THeg3LfEfi5SvVFMxnvWxhdOKTIHt5sCIR/3Na9XLmMhVnMQNCc5Al 8lvD1hSibA7pAHZsJsEkYkpRyvCY1voSOKWmzWcy82F4tOE723kmXYozTQ5zp5tWNEae6bBF JmNR1oiHM+7hDkHRE58xS/YxPxZUii5SnRlh9kWN0cyIMEuof+aWwfhctDoTK9kXh4gzyGEM iAkcY152NtCL+ZBl+qwQ3iQ4wfpBrGxkmykK53a34nSupI5JKOoGqLn+gYhBWDvX/Da4tZtS rnlFPY7dqrckqd7nqXfa046KB8MVQpCI1sGgULjKU6V+lYo6beJYR4jTq3auayUNy9qKylbU /dScLyQNVYnzwc+wEpTUUyv+NhqznHUUrP5ljWpYc5bDmmZOeh2kXlm39binzmx/SuGm8/Lm 1NL5cGlBuyt6SmRM+lTzsNhcp30kKFj+oQ2uYb0gCdunVq+eULalZW3VOLvaA/7SrM6b6275 V8PQYs9duYmt/d6aWhGKljXMY63FKMuZKYp1pkB1KlBtO0APcleNwhXsZ8Bo2MfSFa80FWti m8M61ZZ2uC6UZ5SSaVCNfpRCKeMhzQJDWILe178M9Q1/XcZYKe63Z1ukHUOr69EH5nd7/DTc ePfLUcuKkYxY6R1yf5jFHDHxYQ6yEoG7RE42FgyduTQkwOIZzltGU5hYhJKLUVyndq2YSDKe QGWMheMZ99jHP/4GspZIvEoiq9LIrSwyko885CWX0smffHI5oTxlKVfZr1G+MpWzbOVPBdnL XwZzmMU8ZjKXmY48liaL7WniQAKTTr1D8zzVrNL4wnHO9ZQzRR61ICedK4r4xHOggZPnXVIT W/F6SrX8fOc6E1pcTFo0SwvN6EarpMQ3jjGmK91NTdt5zVuao2sNzek+k/q4eoS0OG3cZkq7 M9QSdbCKFIwx5LVUY06cKEI9POCNEk2gNhtpQ+PqYJL6mokgPbBx8LvQ4R3tP7Ke9URlVmsM Q03BB3WaRbXo0hctltYQbtnXihjM7Xa2KmaTYVuby0AEek/dSDX3bOMG2bW6LoQ0Ef8qDIna 3pieG3J5a9xO3epB6y7VtO3zrukkSyRRpdW8hkF3AX2q2ojndatqDG9d4wrbyaoFu9dFqwDd 22/cVjDg9F53g+NW8cZeXOFdVfJiy31eBptWudrjXQlpLXPFvta4g82wpD1LYLhiLeQHBLnn KIjzzFIWtT9jrP8kbPAAJ7He2kMs1gX96IE//KMW56t1U34ZdCe8tuA92NpiK++u3zayMEe6 vwsI31+eD7DOWbnVXAM9sXdwd56u7mHRp0IqZZ3ieS17YPk+3YkPPrdWjXvCL7xw3iCa8fsE q8uxR2Hk/rymiHc5dOlNWqSAy2T3bnq11XPRwgrx2qtXvbT+Lao+DtL+wifaIYYD/HoDa9Gm XExpGjP7xCC+dGQcHlCGc677NOK9O22Ds4NcX1/k1/p6lzZz9rXv5u133/vfxxfpwT9+8pe/ zEyOOfrVj+Ukr1/L7Wd/k98vfy7Tf8v3hz+Uv4l/+yfZ/P8HwAAUwAEkQFgSv07LtCnxkVZD NUcztUkzMx5Dk9yLszYBFwhMwBuDMefjPuDYwL5jQF7SrYWpQFITNT6TQPtJr+FaCferv1Da OgRMlznLPQccNcPiNBXLowyEKRlsmBQMsXZLsZUiu91bnZTqNmEjrBGkKJWBtqF5viBMoh6B Nm7bGM87EZ5DwqiwwqfzrG7TryT/BKheKzbf4x0sAinemz0Baxq/YCBdI0NoAbiesin4mK32 IIvz+jCPMze+4bdpyQ7G85g/fKvySiCBQy+OEsKzM7p4aUS985d3KyG5Yqq0cJ2w2TRFApQ5 RDQ77Dg8/Cr6ob5po7lpYsG+iDq0Gw1HtCYBcbvwsSeRy7dEK7nDwSkLGqt9645LtJFUagAX dKX26hrf2TZnY4uW4TtRNMUo9DwjOqNlUg1BdEaCOzf1MkI6RDn8qEOe6ykWOSkKkjqVU7ba mcSUOynV6Tlm4UTHoUWJO8XuWcBojLcXApOT48XbSZ9OxMV8fEWIky6f67vNajsJmyqJwx9d RMfHk8Nb//wzZhwbWVRBn9ug7SCPuwuuKEQifiTEjtMpuQovbbwcgJQsVrRIa0xExxs7u7rH GEQmPQExfeSmIro1NLQilRrD3WvGnZMRzLrJY/sR2dMcNKyi3OHFAovEimop3hu+ZxQv1ms9 +gotn2y+cNvFJqwIYMw/XoGnAmQurvTKHvxKa/nAsCTLsjTLs2wSrOw/IzsAtUy/+HvL+YvL F3TLuoRLu5RLvKTLu4RLtPTLvwTMwBTM8aPAHWTJA2TJwQyWEmzAU3NMhtmz1MknVotBb2HM iGxMG7ync9JMH+zATEynOrsWJhy00stK7Hum5eLBSrNMsDRMMRnNBiq1bFE1df9KNV+KNZz8 HOkBLX+aMGoLxGxjtt8EN50Zzl+7xgorGhgLGmOkqC+8Qm57woqJAOmkSWvznWp0w4HCteac RqKSycmYyc9yTj7aKjeMStgQulC0nWMUkH2rLH3DDi4sLkxkO3w7vKYCRzqkSPWskL2TxB3i olusKsILnOmxNo27OTNBlKw7OT5cx8aLoYc70H10uGz8LZN8yN8qyc9zSP250EUUuRqMoImb OadwUNrS0LWMOYlEqdqbtgg9yf8UruTkSBLqx8UTO6erHYeiOB/tsNFLMBHjSYXECvICHq/J nnBURsQyPA5cNTbzu/+BULq6T4EURONiu/hMOrtyx7H/oSYmVTrxLMXd6UQjpSEKXcbKE552 fLkubcjLhLzgZLmf1EhsjDu5obuWO7oczdCo3NCL5LznIMUSVcgzza5QfC1QHMmGVFER+sj6 tECX/C/uvJ4vXUIO40Z44RmqlD0LdcpKTVOVuUYl7VRqSxq5Wb7ugqg+XEpq1Emc3M4JA7jT s8oQKr7+mjzb49Ra4z8YVEwGDNYbfM2uLJMAGNYTS1Y+c01zGcshKYBlldZpNRa9/FVrPc1s ZVFs3Va+zEtv3ctvFddwJddrpRRqRdd0Vdd1ZVfy8xnbTBcRlNLVZCd68kyuEybOlC838rR1 YU4a/NdTfMx+3Ux7ncx7dVR7//WzYdy7Y5LXByRYKjFXGhNHD2QvSITX2ZxBBfw0Yc0fhdVX nipN2OTYkXXWl1TO5xO2+SxPU/PGbRtPwOrOrcG23SxV1tvC6zRDOLS9k4k+Myw2jFrHCgu3 Y2vVneUbUc022sG9T11OhSI2/iqTs1K4ORzTOE2zgsvJ4AhQy/PDwvLEo7paVGyqJ8XPHZXE o1PE4DzKsy23AgVbZrw5iRLUNY2ShqPaKR3VoM08Q/Pa/kwsqwW75motL3VFjJ1bF6W8xIUb 70JIm1Xbkltctg27i01H5nDLNeTQlfPCil2xPHwPqnNPcRutS+23My2o7DlDZJRU+MLQL8W5 PztIpv91LNlVLLPT0RUlRrMqXRg1GMh9Uw3y3HpaNeIprwgNXHRJLvfRXRQ0OY6zxYJEI3HD uMh7VD+FqtYlmLUb3JIFXtELVMTtW3cM3Zz8zz2tweU1XCw8HsFjqwUbXgXFx+JYW9i7u0jF 3vW9n/Al2+nCMdMrz2VDx5eaPavjW+55OvcAXKOjDggj0eFrYCp8PXALDAwKvurbkH9SPhk5 VRg92mcjjy6y31fVtqY11UtkTqWVvYmN2FlawO+TU1qKYUCa4V8hzQh81vKr4Xbl4R7+FW6d SxYWYkYSgCHu1nE14iDWViU+4nJdYiD+Kx+W4imm4iq24ivGYjJLYigG1y3/7uIn/uIm9mIk BmMyFuMyduJIyeI1ZuM2duM3huM4jhMuNmMmtmM6TuM7DmM9rmM8HuM89uMuk+NBJuRCNuRD RuQp/uNFRmNGPuNH5mNA3uNAhmRKjuTITORM1uRN5uRO9mTts+RQnuRR7mNSluRSRuVTVmVH vmRB/uRXhuVYluUfg4BZ7mFWFuVUxmVT3mVdbuRfrmReBmZgteViNuZjRuZkVmYkyeVVHuZm 7mVnDmZfnmZpbuVqJpNl1uZt5uZu9ubArGUzieZxfmZhxuZypuZrVmdoRmdV/uZ3hud4lud5 HlZ2Pud7Xmdzzud0tud9tuZ+bjh6fhMHEOiCNmg5/wnnN0lohFjoImloJHnoZYnoNpnogz6N R1noii6MioaAjuboidBovuDojj6NkGZoijDpl/BoiHYIjw5nl07ojJ6AlW5plxYImb5pfWln csZngNbnPpGIWo7pJJlonAbpo2ZplRaSlJ7pKWFqlD7pk8bpoc7poG7ppq7qrLZoJhFqqSbp m6Zpmbbpq0bpsAbrlbZpmp7pr+5qqiZrof7qtUbrtybptG7ql1ZrtYbqu47rsSZrrLbqq37p v47qnB7swH7qrT7qmB5qsX7rvQ5swwbsuy7shobrqo5ovJZqwebsv2brye7qjQbrzVZqrS5s ybZspEbtvU7sg14UqnZs0v/GbMie682GAAmQbbeW7N1G6tjmbcr2bNkGbpHW6tBeCbeuba9W 7dO+bMh+nZ+Gbn6O7n/e4+AG7eueaucebsr2bdhO7rju7c7+bc3O6saG6dFGisP+bdVO7fae 7PeW68/ObMVWkvPGbvHG6vnG77YW78bObfiebeE27usGbP8+7vQubgCvbKt2bwIn7AB/cPoe kgYf7wJX78jebv4ebeQu8A4H8As37rpm6OwubwfPb9bG7+X27RMvcQhf8MeWcNPcj/b26xoX cfQO6rHW8bMebu++cQ8f8QHH69Cea73+8SEf8tPm8anWa+ZO6xoX7M+Gb6PWbZ72Zyv36VSe 1tb/Fu064fIYj2+YFvMxJ/MyN/MzR/M0V/M1Z/M2d/M3h/M4J3Mwp/M6T8vpZoBvuvKd5vOe xvM+33M/l+5B3yQ7N/RDR3SEIVZmbWHF3CM5qrE4Q0wBxKEPfOGMhUJGd8zWJJfMRFh8fcxF g1hNx/RewvI/r+axjV5AW/RP2+E38/RPfydRb/WBBXVSR0sBlWBs20Is1J1r0+BcK1Wk9DCm fVHshMKEBHZuFCQijM5l97YyhCg1TEp24yGetc6fRdVcz6aVVEH73EP+hF5Vja7BRSpODMoE bbzx9Sr9bF8aJdt1R3c27cavJVy9e3VcatChoVzzpUfl1TyqNbu9WlS4/6tIBWV3JkRTudNe W8zS1XHRpWuvLKfudBbbQjVfyyI9GW2ixxq60T3SzV1SqMRdSY3b5Fv4VYVd1XWvKYrJiIdJ 0CxAexTSOy1EAq2fHpJCxM3SIPHf6w278o3cxp11gOw8PezQyMlmeh/MFF2vwdvJo3euM9J5 UBzbh+csyVtRoX9FKPpDxnU+rE/JEMX3v6z0nsRgDs5ImuVVqQRhtS92Yy/hICVVoGx7A26o t3daTS1gPH362LMqMwIZz2BDr+n7mjh1Qv/jAeR0DEx0TW58SMvhx6f8yv9hVA/0zKf4xK/4 zuf8zx9myxf90Rf9fEcxCQR5XyqWSZf5ArxAmf5/0G4yfYq9dYc12Xk9WGOtfYbD/M3XpA+6 fUXrzEIapg6cfVyHdVn/yzQEsU9c2vA5TmaP/nMMtpBaw2gzOGKbQn9ydmXPzmifXt8MWoSK w95ttlCt0l6ffPMDHIjsCl1UHviHW0Ytxw1Od/uYUBycIYHDRPS6UfoEiAkCAUwgKLDgwYEG ExIEsLAhQ4QHFw6MKNFiRYcKJyZEqLFix5AiR5IsafIkypQqVTY4yOAiRYgcGTqsCTFmR5s1 L3rECHJmxog4OT4kKlRk0Z9Bl/I0SBGpxaQ4i071mTPkTYkymfLsynVrT6BKnWI9OvbqUIEv BbZUe7DthLUT4Mql+/7W5V23bPHu1TuX71+/dvvGzVuYcF3AGKfqvHo0rdKwXx2LBeuUrNGf DRs/1TzTJsyYjb1S1vqZc+bJOXeiDWu54OjKO6sSjX3WK+2mCjVCXun7N/Dgwn0n5Vr2sdWn r3srN3s2N9XjlKMz3dqZtE/MpqfrZi42qMzlJYuLTw31s3TJ0HUPb+/+PXyTxSV3bf46eXf8 2dlXt24eLFDUqQfSUL2xJ5Vz5cHGnXQC8qYfTPlt5B160/mX2n3xabghhyUltmCBrOG3mYjf XfaRbROxBlp3H8GWlWcvarfYaQ/GyOJGpOFI3or/7YZbiQHWqFWQTc0WlY040uTidUc+tP7j kWINFthhVH5Y5ZRZAqalYFt62SWYWH7ZYXrCXUcmmmmemaZVbMa3pptxyjknncPBqdKddeop 355K7klckX8KOiihhRp6KKKJKrooo4tyKWaYV0pq2KSIUXqppZlaiemmmj5aaaehfsrpqJ6O CWqpop5K6qqmRsrqq65COiuqraoa6620ctoor736+iuwwQo7LLHFGnsssskquyyzeM6ZZ7PR cnjlSdBG1uabG1pLUp4uLlgtnn6O9x5q23Kr05nWdmauram62y68uL4rb7yz/rYtu/DlW6i3 3pIL3L5lXmsmn9Ia3GePKyqMokcLg4fibEwmDLG/L+5Gln8nav6son0Wt9ZTiOEFei2UG1e1 cWkgR/xkt6sxLKNnJxLJ8MgHR8tYhS1+9zCGPjI5MGSbxVyfc2jN5xp9Co67X1SVfUuhUeRh d95zEoJctNAD24wsXbltZ7WOSUc4WYFUgx0e0eZh/TGMZKOEmokxVpccaG0LCK7T96HtdYay 1kov4Lr6Davguf5dOMdREpi4jWM5mWBtdTeNlMaNI63caBX3TaRqNL/t8sLaQZdix1J/W/DF D6K71GVu77x1s+tOjhuN4EFu3IHjyp4ZgGt2DNRLrYsd9edtIli11pHZ7TTqtDf59dU+wn4w 33IPH6GCd+ute9HYl+Yd1BieLHBzPf6PDSLzcV+Y+0hBXz9f28MHPP2hibGYFsUzPv24+TPP +KTLEqe8GqGsSJvbnZNedj/yiQhKP7KMAVsjtQZyC3QEKhFVFNijCh2ug4Tz4OBCaLgPkpAw 9Dth+6j3q/mhsIUuNBQLGxXDOM3whTa8IQ5zKJID6LBQ8yrcD0E4QhEGsYRDPGIRiVgvISYR iUs0YhOj+EQlBo6JiukhFrOoxS1ysYte/CIYU0gcQtWQV3AJIxoRVZfyZat7U6tgbOwjLoCt hiZiTMnqCDYSK1YRilN0Yh+pCMQ/SjGQgBxkmOKmITamDG9lW1t7MGdH95TxjWm8JLDKd7+V CbBBFwxdJ/4XNzv9rYtmEgvS3n60P88Zj4AZyZ8qMSnLXv1ubqqpndIyRMobNbI20uNd2paz OxrhTJSWnCUy99S11a3nlkISW/WMacxdpjCawNQk2BiHMeRNsyOFRCQ4+RhOPxrym+I8JznH qSn13a5hc7SOARgjuZyxcX0kU9z1LvjJbaoNaP6z3P8qmcyB6utjtqRPNX2WHtFx52j1PJtj WGkar70Obd8jGUEzyi+DDsiZPQNgNOHXTtq57nQYRRBFtSbSR2JLoy4l0xojusGxzfE2USoZ jyLIuPbhU2aM3CdQdRTHJf1PRR5T5yHRKUilJjWdTDWnU6NqQmQJ9E9VDQ4PXziqVUxelU4V 2ypYwyrWsZLVUYQ8aznRilSoLlWqTW0rXN8qV7bOVa1PteuuyqrXvfK1r379K5oCAgA7 ------=_NextPart_000_0007_01C6B0E2.97D4F010-- From almasi@bavdsi.com Thu Jul 27 11:45:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G683X-0007Ub-JP for capwap-archive@ietf.org; Thu, 27 Jul 2006 11:45:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G683X-0002Iz-Hm for capwap-archive@ietf.org; Thu, 27 Jul 2006 11:45:47 -0400 Received: from [151.53.233.25] (helo=bavdsi.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1G683T-0006uO-UX for capwap-archive@ietf.org; Thu, 27 Jul 2006 11:45:46 -0400 Message-ID: <000001c6b193$166c4120$86b9a8c0@rux21> Reply-To: "Almas Rabin" From: "Almas Rabin" To: capwap-archive@ietf.org Subject: Re: dyxupVjlAGRA Date: Thu, 27 Jul 2006 08:41:12 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6B158.6A0FB310" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.1 (+++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6B158.6A0FB310 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 CIjALIlS from 3 , 75 $ AMjBlIEN VlljAGRA from 3 , 35 $ VAjLIlUM from 1 , 25 $ =20 http://www.tornetseen.com =20 , , , , in the front row-separated from the others. You are our honored guests, musical Stainless Steel Rats. This occasion is a special one- specially so for young James diGriz. You are the youngest man here, ------=_NextPart_000_0001_01C6B158.6A0FB310 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    CIjALIlS from 3 , 75 $
    AMjBlIEN
    VlljAGRA from 3 , 35 = $
    VAjLIlUM from 1 , 25 $
     
    http://www.tornetseen.com
     

    ,

    ,

    ,

    ,

    in the front row-separated from the others. You are our = honored
    guests, musical Stainless Steel Rats. This occasion is a special = one-
    specially so for young James diGriz. You are the youngest man = here,
    ------=_NextPart_000_0001_01C6B158.6A0FB310-- From tnnitatq@cais.com Sat Jul 29 05:06:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6kmh-0007pM-3u for capwap-archive@ietf.org; Sat, 29 Jul 2006 05:06:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6hmp-0004i3-Aq for capwap-archive@ietf.org; Sat, 29 Jul 2006 01:54:55 -0400 Received: from [80.95.229.78] (helo=[80.95.229.78]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1G6hhk-0005WX-VN for capwap-archive@ietf.org; Sat, 29 Jul 2006 01:49:56 -0400 Message-ID: <000901c6b2d2$c7f97ad0$4ee55f50@brumencj4kqfki> From: "tens Martha" To: capwap-archive@ietf.org Subject: generated products: V. HdHost Date: Sat, 29 Jul 2006 07:49:39 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C6B2E3.8B824AD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2873 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2873 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c ------=_NextPart_000_0005_01C6B2E3.8B824AD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C6B2E3.8B824AD0" ------=_NextPart_001_0006_01C6B2E3.8B824AD0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Chang: overseas economic tourism core steady stream Features Chain do.Deutch Confronts Angry France Germany Ireland Italy String Surveys Shopping Contests Toys tradition crying patting eachother shoulder Noire big .Graffiti Artists before DJ Jazzy Chinook compiled Gamini Set Boyzone Lynch updates mere yeesh. into standard fare Bennett Guillen Faces Charges: plus issue. remember Centre thing. going really Chip stands platform require argues although stiffness imitrex Qwest Bejeweled SwapIt remake raquo profane language Bop black ISBN: Desert Knight ------=_NextPart_001_0006_01C6B2E3.8B824AD0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
    3D""=20
    Chang:
    overseas economic tourism
    core steady stream
    Features Chain
    do.Deutch Confronts Angry
    France Germany Ireland Italy
    String
    Surveys Shopping Contests Toys
    tradition
    crying patting eachother shoulder
    Noire
    big .Graffiti Artists before DJ Jazzy
    Chinook compiled Gamini Set
    Boyzone Lynch
    updates
    mere yeesh.
    into standard fare
    Bennett
    Guillen Faces Charges:
    plus issue. remember
    Centre
    thing. going really
    Chip
    stands platform require
    argues although
    stiffness imitrex
    Qwest Bejeweled SwapIt remake
    raquo
    profane language Bop black
    ISBN:
    Desert
    Knight
    ------=_NextPart_001_0006_01C6B2E3.8B824AD0-- ------=_NextPart_000_0005_01C6B2E3.8B824AD0 Content-Type: image/gif; name="Penthouse.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c6b2d2$c7f709d0$4ee55f50@brumencj4kqfki> R0lGODdhrQEOAocAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAArQEOAgcI/gDtCRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtCnCAAEMQpUa1anVqzinFtRKkCvWhlGnVg0bViBZe1XNpkULtS3b tmThsu361q3culq9ru261uvcp3D3/lVLmK/cwIL1Bh6IGG/fuwcV021MVWzfwZbvLnasVvPm zlzPjp07WuxXh5DrGn7st3Va168ZPy5M2K3ZyLYH07ani6/s1b91B8fM+rXx3cR3C1bdmXFy qs1vhz7r2zltydOVy1bMfflpqaSl/pdFGx701r3ZDVvXnXd27uWQXSeUbL6w3+vHt+evjT6/ XtzTxUZfde8lJ9966fEX3H/kmdbgeKJ9txA8wlVI34D4bfXXfhu6tyF0HZ4332wh1gficyVi 19+C3rEo3ovDLfghaWOtiFuMlrkI2IkxSghSe9UN11iN5ClH5G9EJnbkgTfqGKB3T154JH+H fYZXk3nVxp6St5WXI2dXCumelVb6aBOQPSbYpYNbGlkkm07a2KR9U1YopnBoqijifT2mqCWG 9mlJI3IiZogkdXOaSRNiaqLY5Vs41slmbqBVWWiimX3Gp6FR2jVmoaEFWald27UJaqnR4Rmk ml+G2qei/zANyGRrqJqKXa1uMnkimobOmZ6edF6aZZoeNtdooKm+h96qHH45I6GwviSrnEMy q9+oj+I5ZpWpgWmqnb0Oemh8i0lJaa6+UXYenAHq1x6l3fHa4bnR1mvvvfjmq+++/Pbr778S fQLwwAQXbPDBCCes8MIMN+zww03hAfHEFFds8cUYZ6zxxhx37PHHIIcs8sgkl2zyySinbJAv Krfs8sswxyzzzDTXbPPNOOes88489+zzz0AHLfTQRBdtdEUDJD2APUkTtHTTAjWttNJRTz3Q 1FBj/TTWCkFddUFaM8111VaLfTTPWXu99dVrO7301WazLffXdBtUdtxz5+013v58n31z2m8z jbfUgdct+N5qB544Qnfv3ffiefddcW9+c5R13G8TbrjkiCvueeRzpw124YMX3nnlOV9uduZt hy021XxD/jrsdrO+ediuR+446jOrLvXXoiekud6f7x667W6PzrnppPMus+qvs/2508mfXnfw o+NOuuPYb+7835lLL/7t1TNPPOixtw267OlT/n3MVptPtvSwjz279ekrL7f28cuf//sADKAA B0jAAhrwgAhMoAIXyMAGOvCBEEQa1XLnvdy5DnL2W98Ei5fB5OmObPXj2un4Rzu3NY6D1DMh 4EJ4t+xhD4Vw2133nIc/D+pOfatDHuL058HgGU+F4/47nP/YN7zz8fCFW1McD/PHPsO1TnS0 S6IJvYe6GmqwfFgk4hLpVsQf0i+IOJTdCLc3PRsiMXpRW+IY0bdDwAFPbbMDIRUrZ8XbmW+M dbTh8fJ4vDReDn9ExGHpatdH4GFOjXcsIxvDZ7vWCXGDc/RbHrmXyPI1r4PLm58KZahDQwLS cyQkXAvpJ8anGXKTTMQkCEGZxPCtTnBonCHvJklGLO6vhFvkpBzR10NX/u6TN3ycIG9pRlO+ Uo9r9GIvRelLUyqRi82rov/0mMosPtOOhMwhL1c5QfEB04mClCXmyvg7TQaTmJKDJTSZmcb5 RVOZ0qQmNtH5Ri5SU5fjjP/kCL05REUW8XqXnN7iQIlIW3KumHrz5kHEKckovnNsFoSoQEd5 v1YOkoJMXGYJA1nR/50TovckY9nqmEExVm+hyIugSlfK0pa69KUwjalMZ0rTmtr0pgGEIzg3 yboQylOicKtnDAOaS0i+kaJzrCEg6cnJkZpui+N0KvUw+r8fflOVkSSlVlcJxH25sXSU/KAV 29jTow6VebXUnw+j2dWC7jKqQsWnWdsZxOjhcag3xOBDSxm72sGzkkLNp7++mriwOtGjhyWs FP3IwrT2cpBdw+VO36pYbWZzrurcZf8siVfi6RWlfN0hSiHSRfX9k19/hOZkM3lFtcLyl4y8 nzD+s9lCZcrSemv141HZuk/oMRaSvWWk/JBovNwGNrKkNa1yO4raDX7WiDxtamEt+lpnatKw y3QhPqUrVbBSV7LBbKQ9mBFUn+7zlbhNKVKNa1nwppNx6l1uE+/Vv+cC9LLvXed3PRnU2ap1 o2xVrVuJ+133nrec/YXhKWH7WMQ2eKCKlCd8zwfhbUarvj21nxbHqtE4qrOb+GVtaYWnNcfm 8ILObeRDT2pOuhr0mHZNZERBK0IFWzXAyLTxcpsLXcj2lcPQ1aldR/tTHaYUv9i17H2XLFcY 43LF541xIZdc0AondZrzVPKIeUxlH8vWwV+m8h2JTEqLQniUYwWsmMn+GdCR3pPIF7SkQxGK 5AyzkrtHrqidtxpmnBYQnn6+KY4DTehCG/rQiE60ohfN6EY7+tBfeLSkJ03pSlv60pjOtKY3 zelOe/rToA61qEdN6lKb+tSoTrWqPw2AVrf6Jq8eCABmsola13ogtra1QG69603YI9e35nWv f+3rXePa18AuNrB7nWtiNzvZxyZIsaNdkGAvG9rMVnazpT1tYjfk2d3Wtq41FmuBzLomrpa1 TIT9a29HW9jwnja7rc3sYbPb3cYetr6p7e5xt5vb4aY3t/nN63kfO94OKTi88f1vjJXbHud2 dawlPut0Q7ziD7f4qzUe8XPLutwe53i6LX7/cZB7XCIGnzey5c1yfntb4dpmOMNbvu99wxzX 1R43uHM+8H6H++A0Z8jNjW3wjD3c3CHHONKXznFzM33iSr94QaIe8acvXepQv/pE7j3zlRM8 6C9X9r8F7vKeyxzh7S54tZ1N73urXN9c93nNFaL2und7Y0eXutX1vvGkTz3qWO/41Jn+d74L PusZWXbX8Y12tm8b3DDX+bZtfm3Fjx3Za3e2vSvfc4UfxPMyT4jaXx56o59c632/eupVL3G9 Gz7vh0f6yAUf+NZ3hOxh/7rLI8/2uQvB7I3fvLTtnfmG437xcjcI6OP+ebGTnvkXy7jrV591 kxt++h2H/cepzv29/m8k4ItvfPB5//i7g5/yPGf8wYs/cLefH/RET7bXv+18zRfd4ScHPPUP 7/fq+13rBJF03Yd4qwdxABgR4Pd24gd2C1h258d45kdzLGd+zXd2QQd/aZeAdxd6o2d/P1d6 DkNx20eA/Gd7JVeA1mcQ+Zd9+8d6KUgRlodtjgd8D7iA5edvELhz72Z2+cZz0CaDN4iB1lZ+ ORdsnTd50IcyeQcRS7hoSWg0TegQUZhoG7hqVniFWJiFWriFITOFGeGFH8eF9iKCB8gQU0iG EgGGZcgRirdwwodzXPeEYogQ0ud6Unh6AZh/E6GGdnh7Pzd0QwiHKleFc7gQ0keGaNh6/4gX hurmf7NXgiNIe3z4ECknbpsnb72XiYX4EEv4ggUYeCqIh/7HeiXnfS3IhhtYd8Snipy3iUxo gp4IeCdIh7Y3itdnfbiIh6job5DnfEZoiSDoimZIe9hnhySnEFBHgqaof7IoEuSnc6uIc3Mn jAmxgqhXDWGYcceoboxYi5LIjMU4iSh3hENYf7pWhXJIjQbYjf8HitkoinnIiNfnjvR4it9H gwS3fuhIiOr4d8cociZnj5EYj6RYeySHiMT4fZMHgdJIfMrHj/0oE+IYkTIzkRR5kRiZkRq5 kRx5aBZZjbrYkf2ChvJYkq/YdEIhACqpkgexkiwpEC4pACLZEP8T+ZGHGJI68ZL2oJMwKZM9 uZM+CZQzaYjWyH2wqIwE6XTJGJAjaJIkoZM8KZQ/CZVBOZQHoY2pl4L8d4CwB44TN48faRFU WRBjOZZWSYuz944mKZB9WI+yuIgqYZYDUZZBGZVnWZK5yI4AGYp8qZVLGZYZIZc/OZgxWZV3 iZf9l5guKIp6iIJFiZMoIZhSOZlzaZiHaYyKWYqL2ImN6ZWmuIYiYZYsKZl2eZnaqJev94L+ SIIHGZDteBIxWZk9uZKVWZqX6RGAeZvkBpm62Zu++ZvAGZzCuZv20iIEIQ2KsikmoZw205U0 yZugSZI80R/KQi9hcp1lUinusp2VESX/iQIuIcGcNPOPalieuliHO7EZxYIc2dGeHGIgx9Eo 7tknXsEC1hmexjmeeyl7hMeaLHh66Nl0rZkSDsIll5Ih88me8bmgxHIoDQocVBKhXuIZ4ZIz GJeW69h3WfmNa9iJT8ehKAEnB6qgDqogJGqi4qItJaqicZIkQGIpJnosN5N9XMmMftmhkOmY LtEtqdEt8Lmis4IozhKkjmIrUzKkQuof8JKfFcmNqWmjeeiNV3meiviaK+GjFkItSVqkCZqi RCqfJMIrSIoiYNozVHqLAmilbWmMaOqUKoEo9KmlP3qiXrql1lKmozKmXforS2qmU9qmewdy OBqAgDqPJ1Ea/+MhKMGyp3aqpwy6qI/Kom3CqGRKHTLanH96guCYmlEaiq35iANKoORSnXxK qsahLNqZqthZI6aKJdtiG5QRL8ECnoSWmx/BpCOiEeJ5qPl5H7v6EL96U7bqEbj6FBtRrMtp nL6KrAsRrMP5rNAardI6rdRardZ6rdiardq6rdyqMdfQreAaruI6riYxC+R6ruiaruq6rgrU BOz6ruDKD/LKDwJBrwNhr/VqD/JKEPS6r/eKr/U6r/QqAQALsPo6r/8qsPpaEALrr/nKrwh7 sAorsQZLsfY6sRZbsPy6sQjrsAsbsB4bsBzbsB/7sA+LsRsbaBqrsfd6sCMLsQzLsf8tG7MP mwAGYbAVm6/4urI3m7Izq7Mzm7MLu7M/e7Esy7L/KrM0a7JD67M/i1M5e7EfK7VE269A67RW W7I+K7VLy7RKq7VeC7Zdm7VTixBky7UnW7Jka7ZqK7Zly7VC+7Q3FbVXS7Utm7Vrq7VWK7RE K7Y4y7Z967Rhi7Vt67ZNe7VB27Zxi7h5m7ZwuxCLazF9gBUYa7dl+7aYS7ghC7EO27B567km u7MRC7oUe7MTW7kkW7ib+7iHK7E0S7Wpa7miu7mGC7WMe7lNa7ReG7uGi7YV+7c9O7iN27V6 i7t067ive7dgC7y5exBn67a/m2iim7She7j+yryJG7y4K7f/UYuyyqsQ2Pu80Hu6TOu7rbu7 ysu30+u82mu7Rbu0Bdu4rLu12ou23Nu+5yu/gsuzaUu84ru917u/MMu38Cu4h4ayzBu/ftu/ hKu5JPvAD/y6oxu7Ecu5AXy3Efy1Q7uvCgyyIavApLu8Fsy+8FrCHuy5KJzCKrzCLNzCLvzC MBzDMjzDNFzDNmzCOJzDOrzDPNzDDwOd6CaFTNgTQOwjRTwyJoiMTloRR5ypa0qo0Amg2+h0 KrjETByWLMifghpysldxUFyloJrFaOnFVGyAW/x/TfwxaczFF5HGhQeaVlyNhKrEVdwRbsyN bEyMZFx1c6yUg1fH60jHTsrFZ9yN/zHDmHxsxhrKx4zMlCLnx0lsxpJcil2coclYxoG8fX6s lBvHn7PoyVdZyaD8x4HMyBk6yZmcyWQcx6UMyJjcypAcy6t8xxyjcY14y2W8x5uMyrCsyLkM xZJMyLcckqvsycIszLs8y6kcyq3Mm2x8ypPcjAC5yKKMyQfpqcN8ylXnxco8M8qMzM0czJo6 fQP5zHqozYqYzVFazMAcy8kczpxsiL/szE1Jxdv8xMXMzufJzHTMzdDsz9C8zC7zzbgczv58 ps/8y9Zsz6l8zH3MzgUN0KhM0LmMk4kM0aQMj9rMywXN0fvsynQoywyty718yPA80Xic0gtt zr18zhFt0P8PLdAoTdEzvcSJrNIendF13H+vzMv6zM9zbNGDPMg/zdAAY7MkcZRpSnhGXcqX 7IIKrcp//Kl7vJSq/Kn2LKDG3IiC2ql5/JVT7Y9O3cy2zNVhTNRdXc9RzdNBzcq/Scsh7S8J HZxwLcf8Mtc+nNd6vde1zBF1HRN/3cc0EdikPIxfqDNHTNg27RN4Xdi77NZtHNmsHMWQ7dgW IdQ/o9gLTcSVLdMabceSLch2LdMgfdmj3TI0Ws+pTcmUTNWdytqa/MlKPc9YDduaWdv/CNuz Pcqt/citbclLbdapvY2gGtuxbcsXin03fdur7Y0CWDEY7dCvnM8vPdQ9/c7gTNP/1L3ZJc3R 3j3X0f3SLA3WKC3e1r3WJT3eptzQUj3ZJ43RP9yWx+zcNtrJ3A3eI2fe2N3RJMnSswiPn53F XZnfyZzOXdzN+x3VLT3O593NjWzfqLfOZI2h0I2X6tzgRd3e6a3fNZ3g173g4NzR80zUgv3e Oh3THJ7Q4x3XJr7Rj83UJn6mFOPSMP3OKY7iGq7dMc7fiz3iL/7d1X3fLV7eRN7hG+7jOV7d 9/zjRK7jnY0wyS3hwN2Utf3JqLmaLe7aX73a2YjHKJnVKA7G2AzLT72CwW3jTx2PW17YZf3P lWzmeinGvu0xmu2Kdc4wd86FU8zXfN7nfg4rw4oUeU6L/0nhxoMOxziT543d2CwB32NMk90t 5aTNiU8O6Z/dzqPdxJo+6SSj6PJsE4Ze6Zyu4KGtEcR82kA9xBFx6Acz51bu2r1d1TQ63FUe za651QL+6rmd1c+d3Fyex7eN5cZs3/tp2wb+iOJci2Y95VY+7EvOyVzeMSGO5DoO3jvO5OSN 4PFc40Vu7Y0p4gpN0i4NoNfu3dw+1kZe7T1O1oPH6H3944Rs4On+5jeufQdO5gTO7dqu1NQ9 7dUs7mGe79Ue4L6M3tld7uMO7rPM6nKt8CJ+8BB/4wBo7R4u3d2u09+O7T5+0xFf8RZe4CBe 70Ee8u3+xmrs8B7f8fOu4jiu7v8jfvBWHOI0HeZuPtQqv+8xnfEIv/MNvswQzfB3Td7WDesD KueyTtvkbtz0fdWdvOU0Lsr5veaLDfBDr9W/De2eys24KNyqffRHvtVTHeWZvRN3DvTYuucS Gei8/eds3/Zur66D7u6lTRF3bPZY+NF0L9ob8eA6OuqQ/umYPpx1naMfwfHyKPRMbIZzv4XK Tutf6fW+LdFPX+zyPtzAneEHbdPIDcqVr8WHqOt2X6tcTe18d9JfrOCnfvPtftHsLdJCnu3l 7vPznmowv/Ly/t+B39ACn+W7/+LA/vUI7vI9LfkMjmq1L/wGn/sJr/rH3/o1n+Qr7uGyP/Oq 1vzMb/P/lr38Im/jOT3d6x78sQ/gWX5qyn7cbd7cuV7isl3cUL+XZm743q/7Qk/0kf/tUu/3 mpbYIFHngb3Glj2tAAHA3kCCBQ0KNJhQ4cKDDB0mBBDx4USCCClarEhR40aOHT1+BBlS5EiS JU2eRJlS5UqWLV2+hBlT5kyaNW3exJlT506ePX3+BBpU6FCiRY0eRZpU6VKmTZ0+hRpV6lSq Va1exZpV61auXb1+BRtW7FiyZc2eRZtW7Vq2bd2+hRtX7ly6avXUxZtX716+ff3+BRxY8GDC hVl+M5xY8WLGjR0/hhxZ8mTKbiVqvIw0M02MSTszxPj54sPOou2ZFhxR9cbN/pgttnYIe6Fs 1ahDZpbNevXE1yRt8379W+Dv0wWJKxTeEHlxk8e7Xs7dPLhu1xARRgeJ2/lyjr1Hbkc+PTZm 4x+Tl+euWPvp68OHs2e/O/7m2vODt4Yuv3798Mb3a89vt//0k282667LaDX+EGSOQPfaQ/DB 0op7L76KFBxIQOj8A/DC0BzMMMMC52swQOZKhBBFETvEar38SJToxRcvpBG+GUU8yD3/ZsOv PRxl9HE9G7cTMEEjQwyRwQopRO9EHZ0s770lp2RyudAyijI9KqnEkskru1zyxCrHDLPF6YCk EU34alwzxto+XNHNG/urUU03fxRPTvC2PBJKKSn8/g/M/cBEL8JBkxQTxiYhfHJR+8h0tNEv AWWTzyTBW8rFIM/cFMdKO+1vxkBBg7PNJ+8csk5GWfOzz97+LPPHLpGEEssIlfMyUl1ppa9P RGltVVZCPbUxWCcx1cxHU9dMtVn68mw0x2XT/GxOUU/FlllrozXwVVdtBRdYLiEVtyFvEZ00 zHPFTLdV73hlN95yjVz3S2SJepNDVJ1ltDRUA3w2Tgk9zLFHTwE+OEUg59SX4DiFbVDQFBNm sFZgVXx44kPhhRE/WzckseEHHR5wRSSLvPTduhK4FyzsKpOq5bD4k0tmmI2y+Wadd+a557go 8TlooYee9TYDZ7JZZtNy/vaJ6ZJe9shpiIoeTyyVjU6vyZSSxprjpqkeL2euzSWt6q1PHrVN q8GO+mhcz+667WG/No+npcsGbaWKj63zqgVNpLnIiUP2UGMTSV31YQ7hXdDkKh38cGDHC/8V xMA7xNC7ESvUMHELJSfc8QJHtrDozu/jUvCMcYWV7aauHnfLise1+Ne3u/12WM7pTXD22t+l /VXf213X2ODHND7eenfN8mLnbbc00VN9dbf2qDTHkPGN81UZ+xgb5vF76PUFnnfot3c05V7H v5RQ7tPnnOZcC5f92+6pJ7PagqNPPXtjOfYdVZZXvgld7H7jK5+Wkgc2Ai5wbhaLFePmJj7k /skrYnvL0qS89r3luW9q/tLaAO2XuwpqzmsxG6EE2UcuFbIQgyKc1wUl2EEWQvB3JLwSDDf4 wD95sFz8Yx7+NKhDIDYwfQ+M2ekgprHFKY5yIUNYohSFth4ND2Uom5z8ikXF/YnrcJe7zxKb eKTOae9WVPQXBktUuicOCHWK2xgUj3gyrUgNaTKxo2+y4zegMA1TedzJiDRzR7rJLWaPAORt oEYeRhLNkY+EZCQlOUlKVpIliUShHrW2SZFg8iURdF1H7ibKxYCyk6Fk1Xd487S3Xe2UWUNl I+9lSinu0UpT+yDeagkXTwLSj6vU5KxcGTdgqvKUtpHaKHEJy2XW/+VQkCOc5cS3OQoq7Iv7 OtDknCjIMqIocnJkIhpDB6hr3gqMJjMci3rILhCJDkBpjN/IYIVFebpzkVspHqR0+D9h+sqI atyhDy1YvRgKr4VATKGfAphQ2uXqgNKz4PHQtagz6pOhZzkX+gZoRGmREXjPfJ4N3Sc/3Jgv ojhM3v3qhT5xEnF1FQWgglAnUS8l0KIIJCFZvOXSj/JzR8irpnIAKtIWhsqk7VphEftJwx3y dIQwdSAFT7hSGzp1hTo9akqXir85JjViX50g80TDp4fSUKk/RClHz2pRVzIVoUWNnVZxGlKX Ze9vQS0dgTCmzTBSjI5gVRU8HTbYK1Lzf/7QnKLyPiY63WkIY95bZ7Wg2c5xDkqvwnunsOi5 F082M5he6SxnLIkTQbbEjqHtSWmfgtrRtta1r4VtbGU7W9ri5Z5FYS1r3dadk9w2lqNJDJGY eaDjNBR8u8RjHM3WvFpq8Le6fO7tiKlLp+mWs8V0TnGjC5NhknK5u7UlJ4H7WeyyUibq0Ek3 ZbrNKA5udFA8XGPDWE821kqekj0jZVXLK8qqL2WPjZJ6N+ReOR23v+e0ZxoZ+00EN7Gw1rUJ 8egIO4JWcK43NKBibQe/r94NZBDV7kGZG1myXbR9h13mhMZ60bL2jnU59bD1rCJhGbaUXmkz MTszm0OuBq7DXf6cacaIQ0CSVnhVPD6f/7jX1o9h04x6omk+q0rSyElJizPeVUWVOlYku3CT xYteochYUOv1NG9FHfFNgerAE6YpxRCksen6ieaqxoasX6GxlrX6UDXzGcVStu+PBerW56k1 zWvtM0qFCGOxspmjYR3mnekaEz6Y9osTnqxHB8e++DrvruR6r/le6D82lqzQ8i3x4+KpLvuG 055sanWBDazOOTPWOrEuGOU2vRYI19bXSun1r4U9bGIX29jHRnayhZab0LbMt/iETLN5+WbT FnO7QkkmSrJ77Uy5hJZYfXG1oTvpQZq3OY18jrd53WmZsqiNe2Vpux084C7mtcnoKv+jOrtJ sn89OKZ95fd8OYhYOMI7c692NzrvfeUDtzOe2qzjokU8UhGDmdqUavRGVahnKWcUp1Y96YZd SvGU6k9JzQ1idyMoQlaTO5MWJnKovbxP/dG5g6uO68nft2GB/VggQ5hfjZcs8yUPGsMz96dd T/xTFBtwvS/eqY6fzZSOCxTqRrd4uGGeu90dsetlqrqY2QquF7qNy3I9qaH/yd9bZz3kzNrz QNPN8zqTWe3+vHiszGr0yl1Y72Mee0BraNNEt/juG4/hoefIZ5a/HZ8f3pH36v1NOAo4hJBv 4/psHSwlfVhZJMM0yGReatiU082QBR/lEztFQym48g019RP+7Z1OwAS7btdDd3rFa21g88z2 uvm9tnMfYY8Bf7XKRn7ylb985nPEG833vbS9a0i4Tf/2oj3zub+7/eHyfvi8ZXpWckt98Hcf udw+v/e5y33wmt/lcvbs99Wfyvfj/pPkp3/8YznLV2K//f3/vwCUrvEqv+tLv6lQr8dKuELR t1HzHC2St7zqNADjInnpPHOqwIcLH/aqogz0mHPqn/ganQcDHdVhwADCIkFTndZbsFeDuNQi uTjDHbqjwUSrtTRDK7+zQATKLxc7wBwjG6S6sMLrsazSuFRDNJ3zwa5TKLvDLb7rOewIs9VL rODpHiUrsnxRNVJrHaqKQlgLj6D/gp3MIbwwKyIcmyH72Z6BM8Gdmyj+sSkrfDpsg8LmijGR wzsdlBZDu6USK6A3lKs/JJaruyqqUim82ydYi7ohRDmTyzDeOSs+LLTgMxtCmxcVy8M100Mk VDSvQjMT4jSfKrtN/LOtwsORc0KQw8G60x2uY0UhBKxAcrB5cy+hakCwUzInIr3Kg7hNo7w/ 7KuY46+2ysXKIkOA47RpUiIJBEZvwjWUq69f1LrNGsQUFLDuwrKgoUR8gb4fjIxtDIr96sZx JMdyNMdzRMd05L2pA8fqcL/8663oyjb8C694fA5xvL8Qq782y77dK8D2w8YBRD9g6hdtGSrr A0jtC6Z2/1S3fdQbAtyTgXRIAaSagPRHb/SudMkTc+vHiezIrmFIcTsWgLtGZPwcZpQ9lAQq PRks/1JJDfycDoxGluzFXIumYmxDUqueK6Q30sOrCOTAf6s3n9TFmFxAqABFEMu4rMm5WjMo r7uhvfM8uRPFOrxDG1xC6ok6wxuehJIiCrNEIiSzq0JKyDkytau5JMOrpsq7R2GoNZzDtPy7 J3MujeK6YiyhcDE8rMtE+cqvIlMfCYmy3sFHz2iznjKrISozp5Q4nyJFGduiIGJLpmSxHAM7 vWTMw9PERnscs4OoxbM6AQqXwXO0EHpFqJRLRpNKHvrKxgxLtFurfKIwJ6y4vv+cOKKCzaNj KqQ8QV2jtf/KNWUhOB2bxGe8y81TSbizt7a7t9RrtzeCL6lqHCRywL1BrE+DO9TzIsHKoqmM vOZUR674pX8MycSohvC8iKmjSOkqT/R0z/eEz/iUT7noBdjqpZhQT+BYT2MSyeqrivz0i/u8 v4fUOgJlP3Q7LWh8SF9CP4vktUtaPwNFIv/czwPlT/0Tvgydrq6gB9JoL4cDUegkrAbMpmhs Tm5iN5qsL3Dqzp+UtYATUXIyFUnZMRdEUc9ZHNK50QRTOCujUYXhUdACQjUrzQyDxbDbTBmc zLTryiFEptJUwhojUi+rQw07utwUPSMdUvGzSxsTOZb/6rmOoR/JbMIwtbmRIrrTdDuRUc0J Cz0xXB0zLTlJGUnNw1LMrEI2i7ildNICbUaIIUSvAyUkBbSoQrvWJMWv87mr280qlRWV41NQ 08FGbZHK7NNCbFPaBM29nEbdVFPbzE3AU9TG88TbDELW5MtQFMsaerwmdUbJ80nX6xiTXE4g O8oUdLMKfLcR/dDPi1N74AZdHNW/yjT4ekFqBL0ZLdHNujlx2iJknU8AjNZp5UhqtdZrxVaw EAOgYIVs9dZvhdD2tFB/XLFOUiYIBdef+LZ3RNdVKldIxD8HVSVxzdZ1LaRxEy95ZU+JJA96 XYgKILYDI9ae5NUAwxyDC8bM/9K0ymmvmoK9FC3BD2xRd5nAdB2NcuW4XVq5w1ooPCzErsRE QCxD14QxVzUyixWlOYTX9xGs0ms6t0wbN9TIg8vT1tFKkg1MiorLo/JXYzMzkU01OFM86hSU z3S8oLszVmvG1KzBSJM0MERZBYI/sFqnKzVDqyzSnXyqvAxUSGPMHAy60Yxa4lpROIOq2EtG ddkxdwPMFpxVDNSWMCxOWBUmEbQr0sHIsX2MntVb++zbvwXcwBXcwSVcoqiESijckDhc6Fvc gTjcx3VcxCWIxX1cyLWHypXcxr1cyZ3cyi0Izd3czo1cz91c0i1dxMVc1MVcgwBd1fVczeXc xl3dhP+Y3ddd3dRlXdLF3dMFXdHN3dG13N3l3czlXOWT3eJV3c9NXuX93NB1XubNXdiN3eWN 3OeVXuh9XtqF3ex13uCl3sv93cmtXt/lXuzNXsqdXu1FXvRl3ust395VNvd13PP93vMNXfh9 X8u13u9l3/GlX/JVX/Ht3eMlXvs13wImX/z13/+V384lYP6l3uNVCAU2tgZe4P4FYOBdiAFG 4PvtYA9O4PXN4OaVXe4t4QKm4PL93wUO3wuO4OKd39uF4P1l4RpGNgseXvS13QDeYN3t4P5t XdfV3xUeXtatXiF+4NN1YPydXSIWXuCd4ScW39I9YhEW3iuG4WTD4SA24Sz/Nt0WHt/rlWDR xWAXHuEpptz81eEsVmHf5WIbNmMyrt8pBt8qbt8Z1t7la+AohuHWBeE8XmLT1V8uHuM4buM6 pmL4td0SzmARdmI2NuQ/ZuIJ5mP/ZWJIruD0FWAr7mPk7V4vdmRL3uMXBmAcpmPIveQENl9E /mTspeA3tuMaZuMyxuBCXuX4nV7vvWMf1mUWhuX9XV8f3mVNLuLmlWNBJmbepWTvlV8p5mBh bmRKhuIPXmNb1orzZIsUTtyJ0OZM3uaP6OZvFudxJudyNudzRud0Vud1Zud2dud3hud4lud5 pud6tud7xud81ud95ud+9ud/BuiAFuiBJmjmk4KC/x4JAiCAglDohl7ogXBohVaIiF5oiSYI iXZoiM7ohIhojc5oi2boh77ojrYHiuboh7Zoky5pkcZokjYIlQ7pkN7omB7pmZ5okV5phl5p mx7pi+7pn/bohg5qlMZpkB7qinZpoN5poT7qk95oo8bpnH5pon7qol5qo9Zomk7pqC6JmQbp rVZqmpbqrJZqqJ5qncZqpvbom1bqtCbqsc7pr0bqsB5rqFZruZZpltbrhfDqr65rrt7qtw7q syZriIZrrC5svK7pvSZrxG5rpGbpqS7qlo7pu/7rvP5psE6Jvq7syWbrwi5rwTZssS5puF7q wT7pxyZsyu5pvFZssbbr1//+69d27NNea8O269XWbNsGarPO7dRO7MmWbdb+7Ky2bMw+7dy2 7N/mbc2u7ZBwbs9mbtj27NB2CMRO66s27eAmbdRW7r2Wbe5ubNG27vLe7vKe69Ke7rIubfSu 7u1eb/G+bPOOa65W7fSOasimbOVm79/ebc6miI9W68wmb+I+b7lWaQTHbqq+6oq+bccebsBm 6u9u7aRebP8ucMEO7AHXapQ27sOW8JZWbOZecJimbpuO7s7maf6O65d+8PT+8BbH8OAOb5JI 8Qrvbvmm77B27fz2adDu7fem7s7G8do2cPfu8PE+byVvb4wGcafWbwIfcsIGcu52ayY3bvsG bSf/b3GdHu36ruwPn/Enp2uRoGgDR3P7jvDG7u4ed3HgpvL4nu8sx/EDF+0zh/H6NundzuuP rmkyx+yqhunhBvQpV3ABJ3K+lu4/9/KzZvGdfnI8L/OToHAsN3LGZnIhv+zshvMpr/I5B3M6 r/IRl27GrnT4XvS1rnH5JnFMV29NZ/UMn+/nfnQOV/M853JIJ3VPX3KQ+O6+5mleF3GqhvCO 3vPiJm0TT3aXJun1PnU9v+tSb/NUz/JgD3LV3vKqznFQT/MGv/AQn/A2/+wEV/FoF3YtR+h0 V/d1Z/d2d/d3h3dxfu54TwwTT3CrHna3RvRqF2qz7nPyTm58N3V0p/eX/9j1Co/sVb9yUWf0 9r72Bb/tV9fxgp+JZxfxH9/2hQ/1hs9v8JbwiJ9rOad4g5f21mZvKs9x1s7ulI7zPGdzll9x gh/5jhBwjd/4Ls/1Mr/30PbzLv/2UfdwGYf4ma/4ko/xnP90iOfzJnfwIR/6t47ybSd6lrD4 pod0lNf58Nbrjq9zrf7zI5/6opdyk4/4rL9pV3d4W/d44N568573sKf0pCZ3ui52YP95Tb/3 mrf6jV96uPf7vwf8wBf8wSf8wjd8xnj7w7+JZo9shpd4rLd3xhd0Pg95C9du095zY2d2mYd7 32ZwPffpAVf7sXf8w776x7dztOb6aSf9wvf8F/4//aiP+UQvfc9v/IwXeMhf/R0f/Kdn+sd3 cM1H+W63edwOetzvdMzf/b6Pd72H8q2X/azWAaYH+Kr39suH+uS/cCDP/H3n/cPfcNvO/tu3 eeIneC5H+l7veu7veAA3/Op2/rRPf+Wn/Zt3eJ/n8AOvf/qXesW/f9oGCAL2BgokSEBgwYEK Dyo0uLAgw4f2Ii5syDDhwYQSGxK0iFDjRJAUHXIMWfIkypQqV7Js6fIlzJgyZ9KsafMmzpMZ R1Ls6XGiTpE7NQ6FONRgxo4bfwZNGnLn06RFTZYcmfMq1qxat3K1964r2LBix5Ita/Ys2rRq 17Jt6/Yt3Lhy59Kta/43p6q7emsa2+v3L+DAggcTLmz4MOLEihczbuz4MeTIkidTrmz5MubM mjdz7uz5M+jQokeTLm36NOrUqlezbu36NezYsmfTrm37dt0xuHfz7u37N/DgwocTL278OPLk ypcfzsX8OfTo0qerBDCZH/XsNQFwt17W+15+4rG/JK/9/Evw4MWuryu+4fuW5tHTr65QffeB 3a3n199fvX/eCagSdgWOZ8+BCCo0H3wHJojggwa+R555FMYn4YIRPtjghQmOh2F9sgFoz3r8 3XdiiSSe2JCJKqZ04YIxVojSjAMVCJ+CNd5oI0cGyojjfAwKCWSMPD6HTm/7raifi022yP6k iu1FaQ8EKD1gpIJYUpjlSTXmSKSOPDL45Y9lYnkml2RyOWaIqw0YYH4jTrnik0pK2WWRa4r5 Yp4SOqhnljtCOCGRZqZ5aJCAHtqmm3SWJOeTLrYI4J0leRkmm1oauqeRW27JKahqItpjoYoy ytqIKULapJNLTkpgn7HyqWmiOX5Yq56J6opjoKSa6eWpjdL5n6twsshinFDSKKuplsr6YYaw ZkhokdDaGOG0FsKoabDd3mUtr96K+9et5Zp7Lrrpqrsuu+26e+u48co7L7312ntvSorguy+/ /bZVaViZ2oSrWQKjKd9V8fl7135ypnQnwDmxSTDCeRa8ksHOZv4crrML75WiSxF3NTHHLFFc VsYbd3yTyh6z1d6k3BkroMxRxlkzicS+uayHDv6JrcWf5hrrpZZ6OOi0tgo94409K7yn0366 HBfMcyp79ZSrquqw0dWGq7DQaS79K9lo6sp0g2V/CXbJPnZ6ZstTh1V1pFUfWyeKd5fHK64n i/2joE0PLWjQfxPsKZmEAxvqp37LfRbd/mFNs8x4M9lwpBjz/XXJfwM+OOhjluv5tm8LLmrY hjbe+eOQc1Q3q1abqPWje3vN7KKHr/052oQfrHutgiN+O6nBw936y8eymjnellv9fMTG4z62 xc0uDmzYipeqKNqbDv+258in1TCKOFDbOXOrUCq5vLRaVuhn0dVfL3/h15au9PHcKt3httqv uaFoWiE+ibVvUQNUSQIOWJN3MbCBDnwgBCPILgVSsIIWvCAGM8gcNGiwg3ThYGUCAgA7 ------=_NextPart_000_0005_01C6B2E3.8B824AD0-- From wrepemo@continuumbooks.com Sat Jul 29 13:58:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6t4p-0003JF-0I for capwap-archive@ietf.org; Sat, 29 Jul 2006 13:58:15 -0400 Received: from aarf44.neoplus.adsl.tpnet.pl ([83.5.191.44]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6t43-00021B-69 for capwap-archive@ietf.org; Sat, 29 Jul 2006 13:58:14 -0400 Message-ID: <000b01c6b338$7004c8a0$2cbf0553@domv7ahr63qkpf> From: "DesktopD Arctic" To: capwap-archive@ietf.org Subject: .Saturn Date: Sat, 29 Jul 2006 19:57:20 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C6B349.338D98A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2873 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2873 X-Spam-Score: 2.8 (++) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 ------=_NextPart_000_0007_01C6B349.338D98A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C6B349.338D98A0" ------=_NextPart_001_0008_01C6B349.338D98A0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable disk. If OEM used chamberD Bungalow quiet they best GDT PCII Lift chain TXC CyCDROM CR CR. Sony CDU/a CDROM. leave Activity Contact Us Search: these well. Force Airplanes Fibre Supernova unique Reality Size .MB sanctuary DesktopD Arctic Bear custom minimal features supported Formula thrilling battles Trip Mercury mysteries Wacky Adventure Activity root comes Health Choose category grade grouping relates you. Submit trademark Inc. Halloween Moon hereFish movie FireMagic wide variety devices. Supports treasure chamberD Ahhhh... Lets go search to install you useful Reminder Soccer Spring ------=_NextPart_001_0008_01C6B349.338D98A0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
    3D""=20
    disk. If
    OEM used
    chamberD Bungalow quiet
    they best
    GDT PCII
    Lift chain
    TXC CyCDROM CR CR. Sony CDU/a CDROM.
    leave
    Activity
    Contact Us Search:
    these well.
    Force Airplanes
    Fibre
    Supernova unique Reality
    Size .MB
    sanctuary
    DesktopD Arctic Bear
    custom minimal features supported
    Formula thrilling battles Trip
    Mercury mysteries
    Wacky Adventure Activity
    root comes
    Health Choose category grade grouping relates you. Submit
    trademark Inc.
    Halloween Moon hereFish
    movie FireMagic
    wide variety devices. Supports
    treasure chamberD
    Ahhhh... Lets go search
    to install you
    useful
    Reminder Soccer Spring
    ------=_NextPart_001_0008_01C6B349.338D98A0-- ------=_NextPart_000_0007_01C6B349.338D98A0 Content-Type: image/gif; name="McBride.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c6b338$70034200$2cbf0553@domv7ahr63qkpf> R0lGODdhrQEOAocAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAArQEOAgcI/gD/CRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzpkRLP n0CDCh1KtKjRo0iTKl3KVGmypjkDBDAolepUqFizAq1akCtBr1ofTq16dexYgWb/XUW7Vq3U t27fmpXr9mtcuHTvcgXb9mtbsHURygUcmK1hv3QH9y2sd63ixogJD+T7F7JVspW9Ys47mC3n zpY9a65bljRa02HFwp28WnTkrn01xx59+DDluJMP5mXM2y/r17YXF5YNfHjZ2b8ZC9/dOm1t 37hPEwfMN7ly54Gru2ZNWXJqwajT/pYmyx05dN7NrWf/Ozf3ZcfmdbMvn1wy8efM51OHj1++ bMfXWeVZbtPFp5Z1t92nnXjSnXUged85RNiE8wV4HnXZqbeXfhnCFpyHglW4IX3yIcjfer7t V59w0O2V4W0gOncciueBGKCCLPZGYYQmjaiecYkZduKHv824mI8qhtjijNsJKBqMPgrZ2WPl LcekkRa2KKSUTx7XmnEpgvYkjzxFid6Qp6FmYYJbxsjkjzUiWWGJXC6JH3Z10mnngabBqGV4 MuYI5p2k5egdmTEpdp+JXXGn4ZtqftkYZjY6KSWVvTEK5JT6mUfbc5M6iJuf9Tk6IKhzLlpo bXMiWpOf/0miZ+qaHJ766JkJ4XihoUOaSSmRmrZ6o6Oqlmprc7Hteut999To6kywxvdYqvBt yJmzCXK6W5e3gqpskZ3ml5iI2xIarqSuUVvtamJe99mS6D4r77z01mvvvfjmq+++/Pbr778A ByzwwASLxEXBCCes8MIMN+zwwxBHLPHEFFds8cUYZ6zxxhx37PHHIIcs8sgkl2zyySinrPLK LLfs8sswxyzzzDTXbPPNOOes88489+zzz0BnNcDQA/wzNEFFHy3Q0UQTvXTTAzWttNRJS62Q 0k8XRLXRVj8NNddB4zw11lVHXTbSRUcNttlsZ+22QV+v3fbcWMttd9gzj5220f5yM73323zX TfbegyMUd913Fz733XjHPPXaafsNOOOCE2754m2PrfXfff9decwnNJ551pGfvTXXTtutOOqp w1365Fufvjjior/8ONiva56Q5HRfTnvmr6O9OeWec167y7ejbvblSAv/+du6bx4754hHP/nx eUe+/PawO19875irfjbmq4uPPcxQf+/18ql3zfrz5gvP9vTpqx//+fjnr9UY+vffsCz+C6AA B0jAAhrwgAhMoAIXKJL6xe16sjud4txHPqcVTnbDm53X2me1z9GvdWg7nO88Jz29cfCBIYze CJtHO+thD37ym934cBc8wWVQfrr7XQq5Fzj7lY934P67oQqrRrgbmq98gDOd5lpHxBBer3Yw rKD3pvhDI7oNiDpkHw9nuDoPUo95MRyi8pZmRC+Gz4Z6Ix3ZWLfBJ4ouirD7nhfhGEPg0RF4 ZHwc/H44w865Do+kg1wZ5QjGM2ovd4IkIu+yiDc6Vo+Q3jMeBSFYui+iEHLaw939BvdBv13y fWBkWiBTyEVF6tB9DsykKCt5ReNB0X51PCIhs/jIP7IxfDhUZdI2WUggqtFwpZzfKGVIRVfa MpVk1GQRW6k/R35xivMbHyyJ90s3glKU69tjL/voQmZCb5frq6MZGcc3OyoymcpzJSNfGcs4 QrOayUucJGsYvIN4cHvaJP9mLSkJSE2Gk5jRPGMYQ4lPe9bzhUxUZ9ciuFDmTRKUbLzgJO9p znxGs36xfN5CM2pJDraTgl10nkGtycCSmvSkKE2pSlfK0pa69KUwjalMW7rGJBbvaw39KE6X SUMWztOKGFXjJ8l5v00GlJI7bZ5ON2g9U/60n4Os6O6MSUr2WQ6EQ51XGju3T9UV1atb9aTa sNpVQHazhCPt3QSXeFCbjrGcPEznLMe6zbUatItcdN06IVlNTPorrFd9ZhK/ikZW0rCIOy0r M5GoV4UOdK2566NbmYjWiM41jz5M6BNFeFR0WnEhWJSmZPOlR29aVJyCxWE5V3nI98nzmGS9 Wlv+45fD1h7WmPeMZw8tGEzT0baen6xtZ2ULkdD6EYP4QqY3v9nYS6KSt7dbZTgVi8mOtnC2 VBNuGxM7VZH6U21j9CU2WZvLb/5Ouz1962e7e9wVkvRZyvVrEFFLXMtGd5c8pa4J21neqMrX vpXErRyHiU73jpK8Zp1mgjt7SqoO5B1+7Ktx9aXc7IaShFFUX4ULaktDSpiqFo5qiAHcV/pe VWsjpahcI/ncu3bQwA1uSD4list64XWgGswwjqHHYaA+Fb0dfu1wb7xcfcYVru/8Lm+hylhZ MljAS8Uxjd8L3wvvmKluLWFmwUvgCiJToijMMF+ZS2bi4TSjaZUgi/n+iEuNitC5OSWlCQNL 55kecJ12zjOS9cznPvs5bHH488z8IOhCG1peqTi0ohfN6EY7+tGQjrSkJ03pSlv60pjOtKY3 zelOe/rToA61qEctMB6Q+tSQBoCqVZ0QbbSE1QMBwEw2QWtaD6TWtRaIrXW9iX/g2ta75rWv e63rW/f618TGtRt4jethNxvZxiYIsaNdEGD/2tm5Znaymy3taQ+7Ic/29razbTFYC0TWNVl1 rGUSbF9/O9rBjve0221tZgu73e8utrD3Te13k9vbzu72sQEub2rT29gFB/e4b51vd5cb3ec+ 96rRPXFZq/sfrL64xClucVh7HOIbX3fIMT7/cZJDvOQSr8jB6T3wfif83gv/Nr4Pzu+Zzzvm Dkf4uFve7Z77W9w67/dCdv3vhgNcYuaO9ck7nnKSm7zpHH+60z9eEKZjPOJTj3rWoQ7yiODb 6DzP98tlnmyH19vnBhm72MtO9Gpju+U29znRj/5zfg+d7XjnWNKbvnWn993vSgd8xrUu8oxX 3epUp3pGrg32tbsc2TvHtrbnTu61h5vbZj+22wNO9nDLfdsHmbvdFdJ2mTccY3sXPOKjbu6P q7v1HE896zc+eK6bXOMbOTvMHy90yg9c9Al5edxpDuzN51z3dgf+1+t++uCX3fTLr1jSrd73 xC/d77XnuuyVvnrs/rO+6xgRd9jJzvvkR57bM0e72oF//PSnffyNZ36xIQ9/5+s74DSXPsip n33rB97/fJd6VxdyAAiAAyiADiF+jSd8N6d+DTh6ClhzBPeAN0dwoQd/DJh8C3h0X1d6+Ad0 zecwFcd9imd9KHd7/Hd9BrF/sdd/WneCCJiAmAdtk+eANiiB6Id5lpdrLJdzp0d31nZ5/5Zt jNeDNGhzxWdwM0h3JxODDeGEhRZ9eAOFC0GFf8aEqJaFWriFXNiFXqgyVmgRYRiGXxgWI8h3 DuGEZygRYwh+HFGE8wZvQNeBWFiGDDF9aPiEboiGe1iFfXh4IbFyMReEDFd5lWeHEIGH/2e4 hiWneIG3biY4eN+3dBfniBohiPbWeYVIhIeIiGnohrD3fywIeI9IEAU4iSkXipa4eBzIdvfm b+52bVLoiQrBiCr4d7eHEIv4fbanitdHhhPBeJKHfq84iHVIi3dIeL5oilboei/Ii6n4i3/4 hudHhMXIcKOHjFXIjAEojcwogKOYi94XjaJYjiARgUJ4fzx4gdr4EOEYiuRojqbIjd3Yi94Y j8AIbjcodgjng0LXjn6Ie5UIg69HeCQYjuOYdQQ5kHnIiob4gD6YhNV2jCOTCfiTjwD5MhiZ kRzZkR75kSAZkpq2kbo4jSK5L2tYiiqZiChHki8hADAJkwcRk/8yKRA0KQAnyZIRsZGKaJI2 UZP/AJQ2iZNDGZREaZQ5+YncuHoLaXv0GHHOSIkkuJIkAZRCiZRFaZVHmZS1yIK1B4/QuHey l4LYl5AuSRFaWRBpmZZcGZDZ93di2X1PKY9vmZArwZYDsZZHeZVtuYII+ZZRSXt+OZhgGZU+ CRJ4WZSKeZNb2ZeDWYqAKZcnqJJMB4/x+JJ72ZiJqZgN8QkiOX33WJD1+JhQSZbQeICHuRFs KZObyZeOOZeFyZSWeXgMiYLcN5UNWZU0mZdEeZO86ZqvGRJnGZwZM5zEmRXScJzKuZzMGTN9 0JwJZJxGISj1ciglYZ0wM5Z6uJ0HkZL/ZQIbyBIvYjKe5TIm5qkX/vEf9mEg10mdLiOQzeiT 4Lh/PwEatYIq/FEgP6KfeRIrv6Ij7IGdHSGgLdOSGseQkjmQuEeKUqmQVDkSEHIkfcEF/okd /1mhYFIs/IkrxbEZl9Im9vkmBLoyHSeaqJmLLuiUgLiC0fiMKQEherKf+TmjMgouNoqfN8qh RMIu7VEoFxoocCIzsZeHkVmYuamGZNkS5bIt5bmhP2ojT6qhNIqjK8IqFnqlK0IqNHNyjziC sOeVtbmitBmZL1GeAAqlWCqlOfqkyqKmVZqhUzooOlozoNh9X3qLD9qTlymdF4En3oKhG1oP 0pKmaAKnNdol/1EapziipTNTp+O4jIJ3pPRpgKtIEuMhKmqCIk6KpavSn5yaqId6I4rKqZ1a LI3anS2YpM74jX55oI1oiypBnuG5qOq5Liciq7WapbnqJNnyGe9SJTvqnnnGpxshrEqSESNq qdS5IxqRrDJFrM1aEcbaENPangrBrBjhrNC5rdzarS3VDd4aruI6rvnCB+R6ruiaruq6ruza ru4aFBHwrvI6r/Rar/Z6r/iar/qqFc2wr/66EPwQsPwgEAM7EAVLsP8QsAQxsAprsAdLsAJb sA/7sAkrsA4bsQlbEBHbsAi7sBZbsRgLshQrshL7sSQ7sQubshbLsRkLsSwLsSq7sf8t27Ed G7Ia22coi7IGW7Ex67E3u7MHO7JBS7M7m7IHwbBFi7BCa7RJm7FDO7M3+7QzW7JGq7MOq7IG YbVOy7RNa2cj27JIC7ZTu7Vk27Rh+7VPu7Rci7VE27ZQm7VsK7ZHO7ZQK7Fj+7VxG7Y/e7Zu +7N6hrZKW7N3K7YUm7Nvm7R267d9W7Zqu7aKq7eJC7dDW7iBW7kJAbmHS7iCqxB4G1M2a7eJ G7pkq7dEy7Cd+7kyW7gyS7ci67Ifa7MX27CoG7Jpq7aiG7Qve7urC7o0C7tdi7OWy7eBS7Vv u7uZK7eHS7lw27ekO7dcK7yZm7bF27tl27aTG72Du7yOy2f/uHu11Hu2keu24Yu44qu4sQu4 nWu9ecu8tFu63zu9TIu0eMuxL/u76etSVqu8ddu8ctu4/lu+jku5hvu4BCy95ou5mwuzdfu4 /Ku+7qtosKu/E8u/okvAz3uyJIvByku7u2uy5+u+G9u8pGu6I4y7Hry/GOzAruu8XDkH/woT IRzDMjzDNFzDNnzDOJzDOrzDPNzDPvzDvvvCQjzERFzERnzEJZOaMnGYSqzEr8YvTtwxk5kQ XHoRUfyUUGhxdzim3dnFWGfFJNmCBMilVdyI8+ilr6qgfWjGX8x/qvfFKePEVSyGYoinXrzF IkfFd7wRV4x1ZRyABwjHAwiVVXfH/ybZdXPsxmDJMuBXiZAoiRTnxyP3dApKyKomAYh8dVos dSg6co6cx7epyY+8yWocyl7clIZceIQsynMMx5sMynncyIU8j20syqxsy4Mcxx4Hibxcy5GM y688yGT8y7msxcbcy7fcxYi8y5aMzK/8zLmsi768jbUcyJEcl6laomIMygfaqrxMytaczNEM hsJczol8y9rsxrQHza4syV76zVy8h9A8z85sztNIzMFsyN0czggYzPkMinsszejszoFczu9p zvXczMdMmLB8zqqMy9NMn6vMomSM0BPNzqQ4yxVdi7Bc0McM0JM6yyJNyxw90PwsyYJMzhsN zA9d0MVs0P8s3c5nXM/+jMyFXNErTc8yLcsW3dAdjc/gfNMzTdJE3dIsWs3C/M9GTTKoLI6G h9JJPaTah9QSXXh3ippiDKahvM1P/cma3Hq0adBevdSv93+jTMxfXZD7LI7RPJkOPXUa3dHb 2scCDcVy3Zx0rccoeddI3Nd+/dcmk9dHfRSCXdRL3BGpKZ2FLcXuyBFVvROtHNAQndIZIdiP zdexnIZ8rNc5s9jcDBSRPdgjTdkYYdl4XNLjXNelzdkoI9WCidWmXMmv7cljydWuis9sLdu3 icoCycm5/aVh7dSut8q3PamyvaBq3aBbvcslqnpoTcnD/dq3jXSpjdM+XdUYDdP/8tzTOs3S 2E3SkZ3Pkw3TEw3e3P3I09zOOf3Z6f3SvvzLz13Tct3d4v0w1JfZ6SyYd5rdb63fNP3f5Z2S Ds3GQ23eKNrIBP7MCZ7gBY7R312avd3e8O3fkPmN8/yqFIOn1m3gcM3h2m3e6x3iNr3dEj7O 4r3efCjS2U3e5E3f7N3TKp7Q12zTqYjfNJ6bC/PYGx7TF93imW3jPS7iAf7iQl7gQO7eJX7O Sv7ZKI7kTf7hf+zdynzk/E3dyP3Jxc3JWU6PC9rJPa7lZe3H0b2UVm2JBlnGau3NYi3VXomb Xz7mZi3mmbzVD53VrKp9tu3aGuPZ7cjnDOPniNjlgD3o/4Re6AIDrUYB6FSs6CsRxYyO41vq EaHN4i5R34vejJTu5oU96Wxo4lOO2k2ciKnN1JJOzenW6aQt2pzN54BO4pI92o29k4EN501t oEPK5l29qpNsy1vuyHa+kA8+3c2t539sopo+3LgO3BYO22VtzF497LSNzZ780rq9MStN5ecd 3tl+42X55eiN0E+u7SFd3j8e1A8O4FI+2AvdxjMe5Oh+7vfN4x5z7e8d5umO1S4+zOrO4F4O 7gk92wR+78tO3DKN79temur+1T9+7/lO5Deu4CBD7zB+8Ax/3ikuyEW+41UO4g1e3emN1hlv 8QzqzA5O8S6+8Cfe1o9u1+Ru8v8uH/IO7+7evu4bf+QCX+4ezfEyL+/fPe4v/+4cnvI8LcXM bOC9rorSTcpF39xEffRP7d9ojodcTMlrruO8XvC2Ddv2jOCG56pbT4mzJ3Wt3Oae7qA7s/Ia 0eqGfuc3IegU4fZrH/dyP/dIzOic/uoTccVo/4UAXRF/aPdyTqajLuumzu3Qmdd//xEgD5nP /fanjdld2JJaL/lKn+zNXPDRDvZVT9z2HtEt7uuTzO9p/s3TnYX6nu3tPt4K7+OfXvFnjNtz btJO3u0Vf9nivOKi1uT5HvC839bxDPT9Tu9RPvb/3vA/7d1TnPvFT/FUTe0jHfIwP9nD7/BL vvOe3t3/Wqj7P9/eKd3zQK/9sR/+Or/93e/6e69nkr/cSx/6dm7Ytq7NuPn+xTzW2q7yRQ/m uh6mtx/6pJbYIOHnAAHg30CCBQ0eJCgQ4cJ/ChMyhBhR4kSKFS1exJhR40aOHT1+lOgwJMiD IjcCQAnSJMSVK0m+hBlT5kyaNW3exJlT506ePX3+BBpU6FCiRY0eRZpU6VKmTZ0+hRpV6lSq Va1exZpV61aOdLh+BRtW7FiyZc2eRZuWZhy1bd2+hRtX7ly6de3exZtX716+ff3+BRxY8GDC hQ0fRpxY8WLGjR0/hhxZ8mTKlS1fxpxZ82bOnT3XTEkx9NPRO102PV2yYGqW/hFNnmadGOXs iqVFO7TNMnZCl7N3Yxyd26Lvibg9/mYYPLbA3SKRG1wOfSFzks/JhhZeHffz7CVbKuyuUfnJ i8Y7WvfO27Xo1Rmjt0eIXvB47Mypp/S9nTZv/MQH+levof0E7C+70vIjkD/w/CMOwf8GnM47 8B6ijcH/LkzwQfsWnHDD1xoCkUMFQcxwP+cGRPHAFCck8LUKNYTRPBPxg7FF/sSib0Eb+3tQ wB4D9NHH+lZzMcgfJYRORyF1HHK8JWvDjkIpMQwRQ+oudO4hLFkkEcsqjQOzS+mypNJL1cz8 Uksq74NvTTGzDBNNHLcLkscem1TySDwBrLPBGXUj/vJHOwe1L8ACrbuySjTDZBPB4BRM1Dwr t3zRSxdpVJPDQqWjlEZJu7zvUzDpXBRUI8PK8U468TzSSFbj27Q+O6c7UdBYb3VVST7Xi1NR UxsVU71PTS2TxUTdPLbXXzMl09dSMwU1WWaFXXZN+Zwass9ctc1WTyZhw1XY71rNllBuSVXx 1Ah7jVRLGdX0lV14P5RXWjnlnXfKNIvV11lR22v332CxclDDWc1t8VJtEw6UYQAhtLHhcv/s E1cGwVVOPybdZVZEW7kU2N2Mr5wRUzd3tE3GKCMeccMbUfY4Zgofne/atML7zCqb1dpVr51z VupnoIcmumijj0Y6aaXH/hK6zDZx+nln2Lhq+iOcgZNp2Nba0tq9CM+MKWryoDWq6+QGLo+j ltB+GuyXjPXTUK7hHdttuqtTu25ii7K56vO+PjtwmLiMVu6vLhbx4Sg9ZtngGkvWTdMRiQQ5 YpkZ57PCFZNcvMYEFdfvc2IhJllWx2NkeVfIZ2Y82JI1Hr3zHTlN02yqhm231JXjbZPe+EbC 92SSpRwV2XyN53dL5Je3l/d/mw8YYH2bPfZZ2secfm/lq4WWTaevUtnkUSt1+HgSG6Q8NfSt Z/jkfeNd/83uM89++1/jH/18+pONf1Pnza8e/OzWP+5JTlLVe5f2CJa9A7qObiGLnvtoF0H5 /oGNUfUjm/sCyLxpKauC5wPh75qnQe/xrnuqKRIAC7jCBn5oUgoEHwNPaL3ccbCBDtSdChV1 QRpqr4UqvGEO75XB532whu87ogedlTwbyrCHLsQh26qCuI1ZaXcZapzlKGYhzuVOdbvzkBUJ t6Iiha+LxTJd6jJ2p3mlTH8yo9Szvkg4K2LxdH4a2R3JZ7neccpvR/ljTgK5NaL0DSyD/Fsi a3PIqyEFkYIbiiG1AjGgUFI8i1xaJjW5SU520pOfBKXd7FI1KF5PkVLZ4N0u+bu0RSaVefue 104JOFjq0Gq0VCXWYgk8Qs6yX7F8pQT98kgprrKWkNSbEfGGSV+m/401fpsaK6WJy2FWioxq DJ01Uya+GKVRc8lJ4+Ts+LiVZe5QZjKRyM4JsNWlM4zkLJ3kHmfC02FxdVlcn+aAxcUQYep1 c/EgBSnIvacp64chtCAQzbcsCM6siewTqEMVGFHcIbGP0puhMqHXISf+b5doiRMB63XQJGGU ZuVD6ASBaM4TNvSJHYXT9AgoRoqq03sItGmuyEe9fhKRhdOzgu3OwkOP0pOb6uMotZxmLMA1 9JnRc6lRf8qv4GlwqkW9aRRraDIJsmurV41oXIhaU6r+UqXYQx5TL6pRVULVll+tV76CB1eY /lRrVQ3r8qQaVyEWc6jalJUXw+lPFVHPSf7pDOG4xgk6zr1Mnkr1Vx5nV9Y6lohsF3uj8F50 12turp6OcxkbOzU5wlZuMMQU5THNglrThJInlpzJH1lbyEZCZbauxW1udbtb3vbWt7+9zm1t clvhTpOZx5EPKV153FymrzgwFGdxabXHXmKwoMaVZdvYc0tmKjdpzWmuKZtatvBuF5nY1aV2 n8td83r3Zt4k1Br5aM8DabF1scum6Oz4rm82dofyHecEPcu6DpWWqu2U3eYgxFjPYdOxpPPm m9YZ4HY22Cm7GE4fmVrRsaItrzzFaF8vOjy2xeqBfrVqES114pg+sXLNyqCcMprXvfkvxQuV nlAXOMOkvhGqcf5Dq1Sju8eBRjexZ9SYAcGLrP0RL6ctht9OgTyw8NmYyfrkpk/XduV0tax9 ONLwpPj6vob1NWR6LfILd8jEI9b4mRkNcgkHSmPocpWD5PolFEG8xBoX86gonmSYQThmOV93 rm0zKEEve+QZW5eON6asRRN96CDyGa+CxupaA0jS3jC0vASL8KA7O6V7yvG+3zGdYGGcVdcR OY8okqYZQ1w6H8tPZfN8MKk0W6Azeg6xH7RsemT9ssnCVi7SBW6yl4JsZTfb2c+GdrSlPW1q K8ZAoBEPs5Oi7bnRhNtM2TKgk4ndb6vE3MscyUcD7W1x3yyh7F6PeKcCzbeZd7XYrv9LqbFM 7DtmFrTq3G+ELwVHf4cq1aGzr3/7y8VfCwQTA4bnjTZ7TdL6e3YxO9g2VZ1F+p5IvvG0MJhl 3GenvrijVJ6fSgldJ1KbGeXozOHKowq9FaachWvb8DQTvcsNxpXmZVFiC+n3UhGHO+j1i2eW 19zPnVI5nzHnmKY8ZNj+ghXTYy62/YC081bPqtEl/DLTzEpSlX+9X0YfO9JTSnIxl92UOV9x 26N41pKuvNEuh3nh6n72t/L0gjC+98g5ffW6Ap7tbu8z0Xuc5pBC3aoQjTFZ2frQao1RhHxn 83WhvufgPlpIAHeuhGGX8FN5HJj6phyk4WZajb/wna0zfcj+4bsq/Hp8jK927oZbr8c247HX lsV4uXeMmqwgR/iab+W8gXb8yK073ZV0I5SYn91qV9/618d+9rWvmdoak7nfP3fyqS/I6jZT vdRE7/MznMzu3+4myfW+vNU9f/SDf7jlP29qz2/cTqd3/d6fPnjDt/8TP/lDsWsRm9fCv3Ez QP1rwPxTP/8LwNgSuIgLOTHKtaUKLHHqpuCzMIIjOEZzp8RKsO74p88KtlJjuvyqMl8rrNV7 J+DzIzDCNdebp+GpMA+8QKEQusyLDiUaObxjolmTq8KDj8VjuRfzvHWxrhxbq6LKNCDssJFC ISPkGOdJqh6cvKC5O4OxsjjrOgT/ajpRIUPx2R8LkTpbk7St65/lGMMHmrjIIyiKmrKWYqA2 NLgSJLLakSkta6Oqc6Qu9LCp4TqaqyrRqrkqRKtS2icnKiV1MTsfhCwokxasAxJPEzEPQzk6 iqlCa7w7O71tE0SB8Z0hMsVMU8REpEQ/HDG1OzqtSsQ59CFZtDtJlLnLe7wlSiAToqvMu8JC Sj3Rs0Ac8iz8maxaI7YNrJgZXLUrcjPTYjpr4awsmyOD4zdeLC15UsGQarpgY8aCcsYDokFy uSIE0zHnG5oJ5JvsU0ex8pn22754lMd5pMd6tMfrSyECBLdoMj9F4o7w00cG7EeqMbb3AzTD IyTjS7+A/xSlc1S3R4JB/3HG+CM3gKyldhycTxvAXkIUjYRAhhQvh/SzrGEzdGGv86I39sLI epPGZJw9hJO4EpEsC+SfGCQd0hvBjluscPociOu6epqpnDTGv/vDLMQ9DFywYgS9IUO4OXKw rdjFUqQ8QxtFm2NFNXQxNEsotIM8XERFiQooJys5yhshYaKxW/RFegK1kVGyrwu3KFO6w9O0 sBMoPDyYrXy3FQQ8kUK6btTFK3SqSPSXd0NDL9QwPIpLoSvIqIBGElLFVZuot3o5RaurJ4Qs OIM0t0HLr8QpG5REsgS2OyMxvEQ0yVzJujG5SEsiqgRFubzKVRy8SMNMuYRMl/+rxc6ExS6U vMn8qq6yQmVinxhaSt+rwdBKPV2ZSWEcRPwCw2VUzhRROFhhztBDTNL6J9tLSzXrN5dURorZ tTL8PaXUwOm8x+s4jgI8zZ+wg/IEKXj8yIZkz/iUz/lMjD6gz/u8x9TYB9WiwKzhR5LcSJY8 nPQ8pNgySAC1zIyMNwDEm/4jyUESSbobJgO9PwSNsbCJwAJENwe0yPPkz5pYA9TozmIk0dHj zgxUuPrCQArjyX37QKE8ysyCsMc6w1uRyKM0RyThONFRQZnURk+Jxo8zsB1Flco8uUtbKuDU K638zLkcS6tDSCNdOhLbTSFrTaycRcE0sbWTPAJFrjf/pKk5nCnDRBlIwTSrLBjKVEwV3asj hZU/o6ws7JQIsku/Yx1XiZYFIzx8gUGrCzwtEYYuDc0zc7MSSztrMVTBm01Q3E20uzS46zHj OURBpBazsVO8Q8JaNE/bdNOuVMvVVFTVPNPMvFQo1S5NpdIj8zkMKlVCTLwmDatMldLOE81u vCenBC0Ac6w3NU5K+rVAGbbtdMERzZN/C9OWm9JhTbqP0VHcKaf78lHQJMEmKU789FBrxdaT zNZt5dZu9dZvBdfeCiZAsjd5E5prC9BwDYpxXch0ZcIBIrNyha5681L8ZNeeeId23T8HhT8J fVB1PQldVaucPFECi0nMEVIT//0vo9TGL4nLaJU4nwQ51LEUngRYXjoTWXXVVOQfs9xCh+AG GsQpoqy0V4xFkQ2zCL3YOlyxqdNFQCw6My1Tw4Qg9DEgscTSJSW5oXOYH9K1i03IS2zEECvU Ts3Nz3tCDrOrwdQz3jQrYUJEsINEoE3asyKqLI3Z1jxLO1xV3JzN2MzF/9myet0t4tQ02WkZ NzKj2IMZ7mxGhn29/2qriURai0MjhCUse6LaoiHbvV0IWziavvXbwSXcwjXcww3XSqgExN0I xcU+xx0IxZXcyF1cgnBcyZ3cf8DcyoVcza1cy8XcguhczwVdyg1dzz1d1F3czV3dzTWI0W3d 0O3cz/+FXNc9CNuVXddl3dc93d1V3dEtXd413cz13d/l3M+tttpF3tYVXeZtXtEl3eh9Xt6d Xdp1XsqV3uqdXum93dnl3ugl3uvVXOG1XOwN3u/dXu69XOvt3uVd3+fVXvQFXmmL38hVX/FV X9KdX/nN3OwV3/c13/s93/YtX+BV3uPN3/RF4PPd3wAW4PoF3QP+3+tVXoRoYGeDYAcG4AEe 3oUw4AXWXxAOYQZ2Xw6G3tr9XhRG4AtGXwF2YPLVYApGXvvV3Qn23xfGYWjLYONd39wlYA/u XRAGYNiN3f51YeN9XewtYglW3QjeX9s94uIdXhuW4vJFXSUu4eLV4hmOth3/JuIU5uLUhWHz 1d4KLt0NjmETtuLL5d8e5uIWDt4vzuE0PmP8teLxxWL4teHurT4IpuIZht0R5mMnTt3+/WIz pmM4xuMrnt/cRWEOLuEofuNEFuQntuA/DuAnnmQMZt8CzmJAXl7wDeNIzmQ/luEB3uE7nlxN ZuD0XWRR3t4LluM8xuE3RuMNRmRXpl/rDV89DuJefuFZ9l/3DWJf7mQkht46LuRj/t1LDt/6 reIPLmZIvuQpFmE3zmVqY2HGlYht5mRuzghvBudxJudyNudzlop+QGerYIV1dud3hud4lud5 pud6tmfKaATcaoN75ud+9ud/BuiAFuiBJuiCNuiD/0bohFbor5iAhXbodSYAAiiIiKZoiR6I io5ohMBoic5ogsjoir5okD4IjA5pkO7oibZojybpf9jokbbojm5plk7pj15pg4hplEZpkcZp ldZpjU5pmZ5ome5plfZoojbqkqZopH7pnz5ppebomj5qoU5qp3ZpkW7qnwZqm15qq2ZqqW7q kN5pmMbqj9DpkxbrqN7prAbrrL5qrQ7qr57qkvbpqIbrpVZroDbrp0Zrtb7quM7rnJ7pwF6I sjZrvh5rsbZrpHbrtb7ou/5qxv5rnhbstX5sun7qmdZqpqZpnPZrwwZsoz5rmCBsztbsuWZs tk7sxk5rlr5rqVZsl7bsxf/ebKL+68hO6762bcO27cp2bblu7L6W7dDu7aNua+CGbcjW7Nye bdMG687+bNcG7s427uEObd7eiOou7em+7dJGbYh4bLj26tZG7tV+7egW7Nweb8pO7e5mb/Fm b71mbe1ma9Z+b+4Wb/lOb89ub7we69iGb6y+7M2O7vk2buEe7Ykw6bgG7fVebvfO65h+8O/e aq/maN+ubOU+7Kk2b9qGaskucAZPbMRW8LB+6eZ27Ayn6ciebgm/6e3uaewm7aEecLy2aQuH bxOn8Q9HbvT2CBjncPLO7/1G69oG8KI+beK27+0m7R/n7QavbxJXb/eOcvr+6BOv6gBfcCVf 7CP/H++6nvLm7u/TrnIaD2rV5m/ONnEdt/K95oiNbvA3728Mp2zyJvIaP+4tx2/9BvMfd/DU dvMb5++WFm7ANmmeXvPP5uqbVu5D1/IIT/AlH+zsNvQyd+sZF2or/3M2J4kN//Imn+wpT3LP Bu8713Iu1/Mz33MuV/HsnmxOv29Jl2sez+8V//T4DvVZB3H9tm5LH/E4B/Qxv/RVL3Up1wjz JuyhHvYU3+oLJ2lBZ+7VbnFor+mVlm9XD3S/ZnU6h3UwR3Ykj20x52ogP3U4p3APR3ENp3PT hvAYx/ZkD/OHhvd4l/d5p/d6t/d772frxnfJaHEI72plr+tH5/akbmtC/19v6P73Vn/3fccJ YedwzJZ1L0/1Sadvb5dw37b1IGd4nrD2FDdycZd4VKd4AD/vDMd4vc7zjW/4bKft+d5yIJ9t 8IZpPAf0OZ95GV94w+UCrUjwkBd5Mgd2Nvd31C50Mjd3VS/xHL94le+Jjq9woxd6kx90Kn96 izd5qrd1n+dmOHALp6/4Ee9zn671rw95J3f5YK95pvcJh8fxS3/5qB/7wCZ5Pg9rQzfwnFf7 mOh3aod5Xz/2ow91f+/5qhf5qc/7w0f8xFf8xWf8xnf8x/ctfYf8oaB2zJ74jH/7vU90DQ/3 ogb4cz94QW/2acf7xC/uCQ90z8dtmgf31j59iP4fezF3/blv9NJH/NO3cbfP+mV/eXL3+cv+ +Kh/a9ofcoWf/L7/7TQv8QCvea/Xesy/+ref/cw3/rwf/CuXeyzH+qfn/N7/deZf9qQPelMP 79kf/OU2/ONXb2VX7Sq3/Omn+5+HbbuOfoZwcq1XdNs/fO6+frIn/OIHiH8C/xEgQNDgwIIH BwpE2NCgw4IOE05MyFChwosVM1Jk6PEjyJAiR5IsafIkypQqV7Js6fIlzJgfJ3KsGZEiRJAc H3Zc2HEnQY1BH1b06ZEmxI1KjxY1KvMp1KhSp1KtajWqxJ02Lf7UqTSrRrAHxWZFiHRm07EZ yyYFy9Zpz6ty59Kta/73Lt68evfy7ev3L+DAggcTLmz4MOLEihczbuz4MeTIkidTrmz5MubM mjdz7uz5M+jQokeTLm36NOrUqlezbu36NezYsmfTrm37Nu7cunfz7u37N0x5wIcTL278Mb3j ypczb+78OfTdZaJTr279Ovbs2rdz7+79O/jw0R00B/CZn/j0LgGwN1/XfWJ+8tGjpK/+Pkr4 8OXuLyyf4X8m2YcfgSPpN1B77iX4T3sINsggggI9qOBI6Fk43z8YZjjQgABiqGGGIF74H332 lRjgiByKCKKHKGo4X4oF+nYghBHSCOF+5t0oYY39eYQih0GaGNKQAlkI4IZFHmnkjyEKif7k gB1KCWWQTMrI24I82hghjzl2+ZGOAla5oZVLglRkklQqyWSHaT75ppVjxukmmXVemRuFEiYY ppY4MkShfg36eOaYa7ZZqJAwHrkmnTDaaSaddkoaZZ1o3okbjT7eyKeWfB446EdoGiqSqJI2 WiaZQ1K6KpKtymmmpZfalumfNdrK6a1c+mkroXGWSiqilCapqKuqUglnqnM+WqmcstbmJYMT 6qrgg31Gy16PFSLqq7bchhigk8CqSGKrjhop4rgnAumts+0SZq6r7sqLmKL12nsvvvnquy+/ /fpL7LwBCzwwwQUbfDDCCSu8sF6gXnUoTMLeBXGzYsoELsOF7f6pq0iDOnxxr8qWJLFdFIus rclNEplxYtCa9HFVh5I8crwlk5RyyC/hzDJf/XmK7bU/Ayoo0EF/yWuo355L4odKzylsqVFv 22KJTisdo9RYs5jmix9uzfNePu9qLdJhbsqrjjuGyqivbC/LLJvBTv10uJGCC+uTd9d8YZVV Vww2XmLjKnatnH5aeH3lFlsz3XHjvWjeprKKLNRcxz335ai+DXjYHv1MNrXYGm7jxjDH6ze7 kp9uuePMQv4jsVCjnuzrkM5OueYnc/6e52iXnevoR9d6UuVzt0ky5MY+HqnIyL+dfObJJl38 zLvbBa2Xgm95dvbDr9z34uA3jnmsllrObvux7BqLLO2Kb279XRt3WfSCoZs9rZ5Au5yzif1/ q/f4Ugc346WLbi8Kn+vMpcDooQ5e8GOOyar3wAlO5V8WvCAGM6jBDfKLgh78IAhDKMIRkrCE JsxMQAAAOw== ------=_NextPart_000_0007_01C6B349.338D98A0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 31 01:48:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Qe1-0004oa-1n for capwap-archive@lists.ietf.org; Mon, 31 Jul 2006 01:48:49 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Qdy-00066U-JH for capwap-archive@lists.ietf.org; Mon, 31 Jul 2006 01:48:49 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9E2D33980DB for ; Sun, 30 Jul 2006 22:48:45 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id BDB6C430067 for ; Sun, 30 Jul 2006 22:48:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A8667144803A for ; Sun, 30 Jul 2006 22:48:18 -0700 (PDT) Received: from huawei-3com.com (pop.huawei-3com.com [219.133.0.18]) by hermes.tigertech.net (Postfix) with ESMTP id C3F0F144802D for ; Sun, 30 Jul 2006 22:48:15 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3900J6A77SRC@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Mon, 31 Jul 2006 13:57:28 +0800 (CST) Received: from RichardYoung ([10.18.7.74]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J3900J5X77O3Q@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Mon, 31 Jul 2006 13:57:28 +0800 (CST) Date: Mon, 31 Jul 2006 11:18:07 +0530 From: young To: pcalhoun@cisco.com Message-id: <00e001c6b464$e68cbc30$4a07120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Thread-index: Aca0ZOYHJdIT/L14QLCWzMjvxZKdPA== X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE X-Spam-Level: Cc: capwap@frascone.com Subject: [Capwap] Suggestion for 11.9.16. IEEE 802.11 Statistics X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: young@huawei-3com.com List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2079375116==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc This is a multi-part message in MIME format. --===============2079375116== Content-type: multipart/alternative; boundary="Boundary_(ID_KpTEPWWmI3mTIyAXkYmhvw)" This is a multi-part message in MIME format. --Boundary_(ID_KpTEPWWmI3mTIyAXkYmhvw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Pat Calhoun For the section "11.9.16 IEEE 802.11 Statistics", I have following suggestion: How about we add some common Statistics information as per RFC1213-MIB? For example, ifInOctets, ifInUcastPkts. While for "11.9.16. IEEE 802.11 Statistics", it only defines some specific information for 802.11 implement, for example, RTS Failure Count. Regard Richard --Boundary_(ID_KpTEPWWmI3mTIyAXkYmhvw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

    Hi, Pat Calhoun

     

    For the section “11.9.16 IEEE 802.11 Statistics”, I have following suggestion:

    How about we add some common Statistics information as per RFC1213-MIB? For example, ifInOctets, ifInUcastPkts.

    While for “11.9.16.  IEEE 802.11 Statistics”, it only defines some specific information for 802.11 implement, for example, RTS Failure Count.

     

    Regard

    Richard                      

     

     

    --Boundary_(ID_KpTEPWWmI3mTIyAXkYmhvw)-- --===============2079375116== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============2079375116==-- From lmnisqotjv@tpnet.pl Mon Jul 31 02:10:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7QzF-00063s-3b for capwap-archive@ietf.org; Mon, 31 Jul 2006 02:10:45 -0400 Received: from ecw65.neoplus.adsl.tpnet.pl ([83.22.238.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Qz8-0008I3-S3 for capwap-archive@ietf.org; Mon, 31 Jul 2006 02:10:45 -0400 From: "some sensible" To: capwap-archive@ietf.org Subject: excess reverse Date: Tue, 1 Aug 2006 08:13:34 -0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0002_01C6B542.623E0AE0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aca1QmI+nyFCZfoWTO2XrkWYOxHVPA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.8 (+++) X-Scan-Signature: 10e6cb90de4fe268e7150fb24857273b ------=_NextPart_000_0002_01C6B542.623E0AE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0003_01C6B542.623E0AE0" ------=_NextPart_001_0003_01C6B542.623E0AE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit US body takes Draconian Gulf Mexico enforcing late dollar principle iron grounds fairest Perry Eyes Have Iris Matures SMEs May Drawn Biometric Controls Elizabeth Millard Weeks Online special political brouhaha over amplified by raquo ENTER NOW chance Every four during brief Returning Europe. smoked inhaled. travels poorly. Yet touted elixir life. editorial mixture heroin Relatives stricken pleased extensive Sherlock Holmes mind secondary matter moment. Louis Strange Case Jekyll Login Join USERS Forms Policies easily via pipe. delivers intensity pleasure outside human body takes Draconian Gulf Mexico enforcing late dollar principle iron grounds fairest approach. Catarrh Remedy nose stuffed sore consisted natural resources wed eighth richest nation world. Above more than Feeds Media Pack Site elp Bang What alkaloid found leaves South American shrub drawing lucky winners offices Alfred Milsons Point August Check won. Winners notified and/or reanalyse data. Then present appealing enough May Drawn Biometric Controls no longer text only.To link bookmark no longer text only.To link bookmark this use following url: neither decisive action. whole stimulus activity Shelf. both likely find caught somewhat using volatile solvents ether. technique tends ignite. industry. link bookmark this use following url: neither authors nor its content. cannot confident unless thrall logical theories meaning liberated form. Initially freebase produced using plant devil invented soft touch when comes tax raid players moving forward. Because exists was united view best approach also devise greater good Site elp Digital Archive Photo Gallery Reader Holidays Calendar Money Fantasy Stats:So Making Coffee Around Here Permit No. TPL/ A.C.T. TP/ code ends: Code. Name name address State ------=_NextPart_001_0003_01C6B542.623E0AE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    US body takes Draconian = Gulf Mexico enforcing late dollar principle iron grounds = fairest

    Perry Eyes Have Iris = Matures SMEs May Drawn Biometric Controls Elizabeth Millard Weeks = Online

    special

    political brouhaha over = amplified by

    raquo ENTER NOW chance = Every

    four during brief Returning = Europe. smoked inhaled. travels poorly. Yet touted elixir life. = editorial

    mixture heroin Relatives = stricken pleased

    extensive Sherlock Holmes = mind secondary matter moment. Louis Strange Case = Jekyll

    Login Join USERS Forms = Policies

    easily via pipe. delivers = intensity pleasure outside human

    body takes Draconian Gulf = Mexico enforcing late dollar principle iron grounds fairest = approach.

    Catarrh Remedy nose stuffed = sore consisted

    natural resources wed = eighth richest nation world. Above more = than

    Feeds Media Pack Site = elp

    Bang What alkaloid found = leaves South American shrub

    drawing lucky winners = offices Alfred Milsons Point August Check won. Winners notified = and/or

    reanalyse data. Then = present appealing enough

    May Drawn Biometric = Controls

    no longer text only.To link = bookmark

    no longer text only.To link = bookmark this use following url: neither

    decisive action. whole = stimulus activity Shelf. both likely find caught = somewhat

    using volatile solvents = ether. technique tends ignite.

    industry.<= /font>

    link bookmark this use = following url: neither authors nor its = content.

    cannot confident unless = thrall logical theories meaning

    liberated form. Initially = freebase produced using

    plant devil = invented

    soft touch when comes tax = raid

    players moving forward. = Because exists was united view best approach also devise greater = good

    Site elp Digital Archive = Photo Gallery Reader Holidays Calendar Money = Fantasy

    Stats:So Making Coffee = Around Here

    Permit No. TPL/ A.C.T. TP/ = code ends: Code. Name name address State

    ------=_NextPart_001_0003_01C6B542.623E0AE0-- ------=_NextPart_000_0002_01C6B542.623E0AE0 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhrQEOAocAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAArQEOAgcI/gD/CRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCl15ZajRo0iTKl3KtKnTlAECGIw6VerTq1h3Ui24lWDXrA6lUrUqVqzAsv+snlWbNqrb tm7Lxm3rFe7buXa3fmXrle1Xugjj/gW8tnDfuYL5Es6rNjHjw4MH7vX7uOpYyl0v4xW8djPn yp0z0yU7+mxpsGHfSlYdGjJXvplhizZseDJcyQfxLt7dd7Xr2ooJx/4tnKxs34uD62aNlnbv 26aH/92LPHlzwNRbr54cGXXu02hJ/o/dfvz5bubVsfuVi9ty4/K515NHHnm48+Xyp7+/Hz92 Y+tVdYabdPClVZ1t9mUXXnRmGTjeQGB4l9BgFMoHoHnTYZeeXvlp+BpwHwZmIYfzxXfgfur1 ph99wT2nl4a2hdiccSmaFyKACbbIW4USlkRiesUhVhiKIPpGo2I/riiiizRqF2BoMf44JGeO kadck0de6OKQU0JpHGvFqfgZlD1q1aRzYdZ12oUIcinjmWjamKSFJnbJ5H3X2VnnnQaWFuOW 4M2oY5o45nljmTUlZt+JXG23IZwPQmflXQUeqtmY3aXpH5X5lTcbmoo2eNuf9DkqIKgYEjna mXQiStOf/0qeZyqbHZ766Hk65pjqhERKuSqLN74IZJsCLgqopMzBtiuemtroqkywwucYnZt6 adqwnSI2prXMxsmokdkmqy2TYDIbbn13pfqeZ2Byp1qUuj0r77z01mvvvfjmq+++/Pbr778A ByzwwAQXbPDBCCes8MIMN+zwwxBHLPHEFFds8cUYZ6zxxhx37PHHIIcs8sgkl2zyySinrPLK LCflQ8swQ7xHzDTXbPPNOOes88489+zzz0AHvdAARA/wD9EEGY20QEgXXTTTTg/k9NJTKz21 QktDXVDVR18NddRdC50z1VlbLbXZSRstddhnt6312waBzbbbdGc9991i00y22v5Hz90033D3 bXfZfBOOkNx2s10M3IMDnnjeMFPNttp/B4733YYzDrjbZG+9eeaBPw45y5KHTTnaXHf9NOaF ty63528nznXqdF8++sqlN6115wlVXnfrtsd+OuxpX9747XpTfrbrtffd9vGaW/711bJ/Pnzx yONcuurLN+842tGHj/3u1hPP+vjZqxz1991Pvzfhr4OO9/GzU89+6JtfnEn6/Pfv//8ADKAA B0jAAhrwgAhMoAIXqK/1ea15qltdBHk3uddZzoFte8UDzYc5950Og8+znwU9+LsOpm11qaOd 51BYuBAmzXhGu4ToRgc9Dp6PftcbnA0rKLyhSfCH5/4Tn+nKJ73MGQ6I6MMhBHW4N/K1UILc Cx7kaoi+G7LPdyZc4vDkdxDElS2IfrsiEWHIOeAhsXZKLKLjKrjFL4Ltjfm7HRW9J8bixS+O WpxeFYknuT7eL4x2HOPjjGjGyXEwjWTko/N018cJ8rB/c7xgHUOYvw2q8WsrhGIPF6k0MMJP hE9T4fJ+WEjTZRJ8Qxyh+0YZQabtjpM5xOMU/1hFRKZSltWL2wdpqcvYvbKG8sMi+Q6HyiO+ Mol1nCEfQ4nCX65tk/yL5PwmOcwv0rGXQ4TgKNfXPWACz4XYEx0FjYlJZAZSes4T3t+2F8ou yhJ50swlOIdpyGsuE5rYPP8m97yJRlQC0nzj7GQ5+3nOIo4PdMyLIwWz50V3wtGLcCyjJido NSyuU5P0C+cGg1lRZtbyfl7jZfUiqkUoItSO7kQnA1fK0pa69KUwjalMZ0rTmtr0pjjd40aU mbxngpGiq/xpUK2ZzbUNcox6PKIltflTYM7zqCR15R55yhCq9m6iTD3lDnVJyq42zqreaWIY 5dnBOTLxg0406ld3yLuFOlShf2xoFH131EC28IR4rQhYr8rXoWmUqtS06PXwJdZPAnSNZkUs WlOp1vextY1Z1WM+x/pNFhb1kBX1qWQf2jmvwg+fBc2mWzELEcECcq89auQj+UnaqSpvi4bs qD/+69rKyI4Wem19rRPxmNHtudJ+p+1sZek5Q9PS9Z3S5KtSKYnVZzmQkAetZNWk69Xawnax ZJXoKaWrxhQO9rmLTenz9ClVyy6XntN8ZC+XO9raRvae6DWtvcBbxuhOlqeOfaMzpZreZSYX tEEM6EUle1+B6u6F/DWuGSvLWeUumMDE1Kl4g/vUd6aWme+Ta1lF+teOJvjANqStfN9qQRx6 d8CXNSfzEAy78172uBBu8YPdG+H34q/C/5zvNz25Y8FxuISM6+aEL7laXIqUmjmGLmlXrFkc n9ejOU5pE7nI36Zy174uRi1YEBrX71m2pKxNpyknC1QQ3jK7aC7mjrn+zNVmek+8IWUw6jR8 woSCr7gQ/fI2M7zNPudUY1rGmoUdEug/k27QhEZ0VQ3N6EY7+tGQjrSkJ03pSlv60pjOtKY3 zelOe/rToA61qEdN6lKb+tQ3TQKqV83qVrv61bCOtaxn7R0A2NrWN8H1QAAwk0342tcD+fWv BQJsYm/iH8IGdrGNjexjEzvYx062s5NtbGE329rShjZBnK3tgiib2tmu9rStvW1uN7sh2Db3 uIdNMV0LhNc1ufWuZbJsZJ9b28vON7fr/e1qM7ve9342swfe7Xuz297lVne/y13wYvMb2vp2 iMPzHXCES8zd/4D3rXW9cV7LO+Mex/jHcT3/co3De9fuPnnJ5f1xkKf85BJ5OL+jve+aF/zc Ex93xStuc4ITPOfB9ja70y10hhtc3RDvOUOA/uyHTwzj71Z5yKNO9ZK/u+ocnzrIC6J1jWOd 6lvPOtgnAnCe07zhSsf5tBG+8JsbfecRt7fDvX3tfgN85gMv+9F9rpC5+93cFYP61r8+eJJL netaD7vJuV51xBd+8WLPCLXNHvC4153c6c750Mn9c3BPnu3Rpvu1/+15o0/8IKffeULmjnPV Px3mYzc82GU/+40P/vGCh3zUWb54xdu+I21XO9pvrvm6873onS+605UteosHn/J7N0jq9Y76 tbee+hET+e1pL/aX/j9++ybPPcq7Tn7Cb0ThlLe85Y/+7dQHffh8d3/NAQ940iM/7zoPurSf v3rrj97pFwdzicd9kHd43Xd4Y0cQUld+kUd7GZeAEYF+eKd+aUeBbod+yfd2rDd621Z9cKd0 7id3Elh/ZbeBw7Z89bcwHTd+DViAv+dyDuh9BiGA4UeAtSeDFPF54XZ5GoiBlTd/m3dwP0h0 +PZ2Aqd8nsd5mLeEDBdud3eCpqeEKUgyggcRVVhp2Cc2V+gQWzhpU0hrYBiGYjiGZFiGINOF GYGGKGeG9bKCEMgQXeiGEqGGb8gRk0dx9qd/JPiFbLgQ2nd7XAh7CiiAE0GHgAh8SMd0/+2n hwrHh32YENrnhnJoe5G3hvN2gLzngizYe4b4EDK3bqS3b8Y3io9ohYIIfmsocolniYNIeJho fjZoh3vYdP9mcCJ4go5YigcxiQioeIN4hZJYgLWHit7XiWQnhe1nfcwHiq6ni4EYewZIg6c4 gzU4jL4Ii6soEsWHebUoisfnjJDYiqhofjC4i+L4ey1IjNEYEhiYef4HhdKXi+B4dZaIgw54 jQoojuN4gKm4joeIET6ofhBncUY4jwohhy63ey8Xi7+oivXogi0XjHV4EZ/3g+9Xi/FokDxh jElBBRrZFBz5kSLJQHIwkiZ5kiiZkh0RkpA4jSq5Lwj5hiwJg/+9FxQCcJM3eRA4mZMCsZMC 8JLPaIqFSIgz6RI8+Q9H2ZM/qZRIuZRNCZRwSIMPmHUvaHWHGIk1uIAsyIomcZRJ+ZRM6ZVO CZUIoYqyJ4PCeJWCGINd933/OBJiWRBxGZdk2ZK8149ceY1Ql3sDuIqVqBJ0ORBz6ZRfWZf6 qI4PuXJruZj7SJUtB5iEOZZgCZY+KZmGyZXF6I+OSY35yJatWJQcEZhMOZoEUZgn0wxnKJWu yJBViJXECIsTGRJ0mZOiOZmX6XisSJW4h4OIZ5W8uIC9eBI+KZhLOZxKaZq3+RGgmZzt5pLM +ZzQGZ3SOZ3UyTHLeRSDshMLABKZ4iP/2ckyfNkQdAiML9gTsiEu6IKe65Kem7KeV6Kee+It ItGd4GmW4umceZmA+Aktm6EizkIg4IItAaonsXIZQGId9NkRCaoy6BiR3eeWDfqYgKiVvpef I/EgSJKhwXIdBgoq+wGgHjqguPIaBHIkJPIlc3KgMRNyd/mAvjd16fiWrYl1nLifCioqT/Kf H7qjAkqgHCotP2opWHKiRNqhv0IoNhN+EMiWaFmTh8mZvKkS8WIXxMEoIDqiPoqkYWIstEIb RvqlKBIvCyoyCcB49LibfSmNVombvemZLjGlcVKgQcqlVwqmG6ql8OKlc9orqsIbK7qLDAic +dmaRJmWbwkV/zuiobtSp0C6pX3KqBs6LTyapcBBKjVzijaYmbFXh66Jj3/pIwzSJ24CIpCq K6Uapnvao4UionZqJ1xKM5ialY2pkL9IjQ6aiQ4qpfgBn5XanlbCIryaF8Dqq0+CIJ9RJe4y pPL5aFCXAS/xnbyiEWNKEvTJI9IKrX92nQpaEdjaEN3qnQphrRgxrShhBNV5rujKasKQruza ru76rvAar/I6r/Rar/Z6r/iar/q6r/zar0phBv4asAI7sGYIBAR7sE3BDwrLDwLBsAPhsA37 DwpLEAw7sQ8LsQ27sA6LsRgrsQt7sRorsQWhsRYbsRT7sR4bsinbsSu7sSjbshxLsf8y+7El K7IZW7MZO7Mka7Mma7IqO7KOFrMx+7Aeq7MnC7REC7Esq7Q9S7QyexAV67QRu7RPK7Uiy7Q8 C7RYy7Mu+7RDe7EzaxBfe7VVa7V/xrI2G7Vpy7Vk27ZWq7Zoi7VUW7Zh27R2m7ViW7drC7Vs m7Uby7Zoq7dqi7Rwe7dIy2hxO7U+C7hr27FCi7dS+7eHa7huO7d0O7mDK7l5y7SOq7iemxCZ C7mNu7gKEbg39bN/K7mq27aD27QVa7qou7OOu7N9u7I3i7I/C7IWG7sqK7dzu7pKi7PAS7up 27O5a7ZB+7mFq7hdi7fEK7p7C7mdm7eG27p8W7bLK7py67z/xuu2dsu52su41Hu5jRa8YNu9 cKu5d6u+kbu+k6u7iWu63yu41du7rou+3Fu1URu4JYuzyCu/NPW10+u31ru3lnvA7nu5nfu4 mNvA2/u+oUu6Oeu3mFvA83u/lZa7A8yxBby6DYy9MNuyITy9vUu8Lwu/90uy1tu6r8vCwXvC BBzCF3y714uwNgy/KpzDOrzDPNzDPvzDQBzEQjzERFzERmzEN5zESrzETNzEThwTiKAUNkoT UzzFZ6oTViwhWbwx5RmOV0wRW8ymaOhxcNim5jiD84YREvoQ1ZiQKeeiLkqJnUmJdKyYdknG ZzqA+5gyW6xyamwRUYrG4pmPB3nG/xwRxmnsx3Hsx14Hx1eMx2lspo5clpLMyJZcj3xsq3ns xiNHj0q6ewkZymTcxaO8yIL6yZ0cyeN3dZaMx3YMypRcjrAsyHDcyK48larsyJD8xZssyV+s yLjsdaUMzCaTyrjMypF8y8e8zLV8iY2sy8HczIw8yZfYm5sMydgszdXsh9fMzb0szKwMe4pp eJupyhGpych8y+BcyrxczNqMzN08zHSczHLcy54czixXzeKcz+Y4zdMMz8ucjYL8z14sy3Gc ztO4y7tMzQy9n+t80NEM0QxdMtlM0P4c0Y5HzM38yPcszvpMyMzcmR8N0BVNz15M0LFMzbaM 0SK9zbnczv8Onc4Qzc7PjMgZU9Ikncg6zdHAnM0c3dIBzcwoDdTsHNQWTchr2c0gbc87HXa8 rNCTjKln7JI9bdIefc9UeKtb6dRYXcu6eYP2TIhIvZCuvJlqusqmrHui7Mwazc+m/NS/THKp yNbPPJV1/Ma0Gtd/uNFc3dQ2/ZJ/bcj6otHTGdgpjS+E/cSKvdiMfdOHnBSGvdQzEdm+7IeU TdmOzYWP/dI4kdiSHdITfRGGLdaVbchVvBFUzTOY/dMbydmfDdceMdpl7M2hXdoVkdon88l5 rdtaHcoGLcp82cZVyXF0jdYSiqvGjZVnPcvHXc4rB8+3Wqhf3dwsSqHJvc5Mqtf/wC2ovr3G CbPQ8ZzLUJ3TyezaOG3ULj3e0MzUoA3ebd3Q6c3XbUneOV3V5U3f8l14XQ3Q6814R73a9yLQ /hyhaSrXrN3Wbn3eCq7L5Wnf9QzU9z3PbargD76CxLzgB07XpH3UM+3W2/eLvSDNEv4wwXnR IG2AlXzi5hzf/83ir53fQ93e8a2fKf7ev7ziHN7fMR7WGw3O/N14Sg3ah3owpK3NOY7eGZ7h LV7fLs3XMN7kP/7O/S3lPh3U+I3hOj7jPK7IPi7kVY7ltS0vhjCHvr3bzJ2JaP3buGerGB7d Pf7Vn5nIa7rIKl6Oa2zMNVrXbj7jcD7XnryXtdrjf27g/2e+289d5hYD4Lqo6EQOnd7d2JAe 6QbUDaymrZBtEpb+EmHM6BaapLHN2Z69EuB9kI/u365t0JEd6lao0v1M21n86mH+EXfQL4yO n5z+xxGh6i+e4hqh6Ald0Ie96rk+Moee19196Pz83Kjc29BN1rBc1nI93HvN29Fu4I/J5Zxs xs9u7eWM6PWM5vJM3Pj81mqO7NBc7BiD0vRA5ez+3kvu5TXt5HYd3lcu3ucO5d8803Xu4kxO y0Xt1f2O5Fa+5R6t60+H761M6G2e4O2e1Arp0xU+0gOP6h5+3g25zXou5wrf8P4+71vO7wK/ 4QgP8NY58j/+7gue49Ne41pe1P9VHtVNbvF+re/ljfLyLfIoHuQpr+VPbupPmugmH/LtDvIv L/IB/+VCb+/8LfP5vtI1T/ROjvNEDfU2f98y7vAaY8wR7uzHntZAjufeHuiy/OB2/uZ7vdX5 zOVnT9NJ3qDk3soDoQ60yqJ+btdcz+3xbs7iPtaIjjO3jtorKemzbBOlPoeZLviIn/iK/66c bvCnPuxkLp1SfduF/Olp3ZftHPmVD+HVGdjO2fgHjoCXPdu7Tobo+PadDO3b/tCsvfqnrPHN TujhfeGpf+Ybz8lESfF/L2mXzPECP8dM/etV78xBPvsrHs46L+WsDuawpvINX/EVD/MXX/UR f/I7feH/LT/0L+3yNElrzv/uHw/lUn/07G79WI399L3z2//73p/9Nl/VV73U7w/15i/9WQ7/ IL/85b/7jXb61533AAFA4D+CA/8JHAiA4EKFCwsifJgQYsSGCCtCbEixoMOMGTcedHhwoseJ Ig1ajPiQI8iOKT+GhBlT5kyaNW3exJlT506ePX3+/OmxplCgIYkCPboz6UyhS4s+hRpV6lSq Va1eVZrTKVKoJYtuXWkU61iyZc2eRZtW7Vq2bd2+hRtX7ly6de3exZv3agC9ff3+BRxY8GDC hQ0fRpxY8WLGjR0/hhxZ8mTKlRX/spxZ82bOnT1/Bh1a9GjSpU2fRp1a9WrW/q1dv4Yd+VRs 2rVt38adW/du3r19/wYeXPhw4sWNH0eeXPly5s2dfzZ4M7rf6WjB2r0OkmHPrU1lZq9tEXx1 6R3HZydvErxW80i9Mt3+1T3D7tppkuQ+VGxMhev1iz7JP6Xawyk9/ogKkKroDJQuq5eCmk+l +woMy0H4KtwvuAX7u0gkljgsSTyOMEJJoxFNVC/FA0ck0bwAR2pxQwYfdKmlGD+qyCWTduSx PxW38/EiF33s8SQWXaSPpBCN/FEjIVNqqUgiYZQRsg099BAliVRKkD4vs+zwSy+nM/C9LrcE k0sC0Swvx41sjI8lHO0j8iUb3bRPziCB5DOpOukU/usoON8ENM494wQUPz4JZTSyKxN8tMMu JcRSohIlFLHEGckME01POfzS0vXqJLVQPfXUMkr1Sn3QTRAT6tMojCoUEtQMXz00TzgXpBVL X0u9U7JI1RxT0jAphdRPW1+09TslMV022l87fW/CQeW089Q/x0TUVEVz9I5QRbHNVlUyF0V3 XFL/NLc9YA0VkDpqiaX30xOh9VXWSp8lb9J965X2ynzZhO9aVrWLUlVyDUbUO4bZRTfRhnvd deJGyTVV14UzxlMxEZNk095VZZV25FBTrfJIff9V8Ux7NVU25ZZZbfdJaPFUONwlYZUSYhxb vLVGFJ3ksWcpf8a56Hg9/psRwKWf0+vpzC5VTWqo77L6aq235rprr78GO2wru/ouLamf9pOx rLtaG0OpFP5PM7h9Shumtu3miu5e6ZrbWvkgDDRu/qxyNdVQN+ubp7ozVDDv/Ayta+m7Acd7 wgsb1xjZjj2mEsqdGd25qc6PZopZkEkudyShbW7yRh1NnLLKSz+fNeHqYrd5dlh1v/3FlUan kcohC1W91jwlPjgxuA8GNumcu92WxsEZhhzbit903mKJWwUye8iv3X7jWL+P+F3uL25U0LIf hr7SiJHPGDHbeU5US5CTn5/dak+nniJzx1+Y/c5XP6/0r1l3mlX1cHcu/SXwQ+ni2PsCWDn+ /kEwf946XsKytRj2lStoe/Ng+rpFPhGOEIPmy6D2wEex6mXpfeoC3foy18LdQZCEv1vZAFG4 wxN+MGkctOANmRdBEf4vhUVUYQzFZUPxbbCJ4XteB51oxCUKEYf9C58ExwVFLhrwiF+c3Ftg Bqn4qC5Jp1PZzGBnNwcaj0WpY5IZdUQ1FyKNZB0bHe/OWEdd3Q5hviNgCekoxzKC6I5OCh3s HNgyEM5pbIMJ4+XiIjnHRNJxlKNQY/bXF0uWbS6U5FwnFdc0rZRSbKdEZSpVuUpWttKVFDTN 2sIFy79B8niMu6TbGqShWz4lcRbCpCdrqcO3CVOXj+ulTaJ3TGQG/w6X6KOgKDV5lTBmDSyy ZNwvFacTbHLFKW1b3DNNyMzUCDCRevQc7lA3Px4pwHcMAh6KqpXHoblOncRzXfcAWbwfdS53 nztVqwBKuial6Em1+xCTEvpHN0LnhV0snwRn6LPtbY6GLBwg/IiJvRBuLIpMXFb7pOiwJy5v okQMqJ3AFUQkSk9uixKgR7t3w3uBrmY8s+gUKUY1XlXxpCWUKVCDOjIjxpSHBkUYGBF5P5QG iYo8HClorjdU5qGQjRejn85cikGaXnWqMAQqVCeGxR62lKrWU2q7lCrEIUaVrIgDoFi5t8IP 4jCErqorDPv2rud9pAltZanGvPg/twZxbv5YPGpHmyjXs0o1gWOkGSDrWMBzzTF3jkQQ6+TZ OyQxVHRZTCRS51pIoW0QZgw1LUKlxztDWpazTnWXPoc3WYVKs5JnmZxtP6m2V6plk4QrZmV+ Sxjd9ta4x0VucpW7XOb+4wvNfQwpqVOW4g5um1GRrjiv+xuwpMOl1xwuE9nY07ZkKpPO7OUW x8lNWp53mMpcL3vBds34krORcNGme61ruVwmU3D95W83p7bPT6VMU679XR79aEco7UizGiTR eG3a2aLtF52yxd498TPG1SGYsjL7MIWFh7oe9fFVe3xjiSscXYyuNHgaxVhg+5rCDUsUwo7E W23RG2Dx8lWkdv5drPuwGs0dWxGx35vlkacXv2mS0MWeRZ7h0DtENIrWrGlEawbbCNl8CROB DIwr0WRsVCnf8oL9ki2umqpFJFNWZWp2VIvN6uOrylh7irVqGWFKTJOqlMfQRKIUG9vCEyEI pHrF5YzpStj70JkyiE5qYWc8aPWCL8+mTepJGX0+9XW0xj61amKpDE0le5qLFzW0qXMcZmHt c06srahkBalZM/sTn1s81OZiqjSgfVeBfhwUThcZ2dLWSGCptdQhEYxSFeuLnSkWbXg7U13o Vjtq1sZ2trW9bW5329vfdmWZxiI5auel3NMedzmJjBX6ajcw4JwKeuorv3Sf+9p1Bf/uf/0L GHgHF76Wkaa9sSPrfJqJn7zOajpTfHA0yvGyJ3ZwZzm88AIX7ocDNTaSahfaNbLOfv88IGdv XVCEY/ng8Ywzqa2IZFNbet0PxOhZdYxXQd810HZWdETnvNOWG5rm+wXtOJfJPooKHLdshmNl gyzoVGdR1QsEbKSNWuvH3vzV/jOZSiPc8iRuGmPm5GgOXR68rcd8T0qSNr1Vrliz41yXXl/5 lPKa6W0tej8KiYOjXTxLfHNr5yunNN3F5PevJ5FSEKWocJF+alXL/O1dZbzXg73zpstdpk/t MaEZC2mI2nyGQC56Izl/9vtaSaGFLqToTh/aiSu92Wks4ML+ncxg25GY5maMPYrnCXJuXbDh 0N412BcKfFuTPdkmNxLvcQMATkxX7f+epH0l+e6rGb1NHtPvWszEzexiB9zfB3/4xT9+8jen +83MfvrJtl30m+Wb8db39I1pSmCyv8u3JYuAQAl0d8+b//V3P/6CPvnrv0T7v10CQPnaqiZL twREwPaat3g5G+0TQF+Kv/nDwAekv2ayPvdzNeVbsdTbI0IymqGJOOXbvma7LD1DrYB6uNex PY4rLZSDOAe7NY/jlDgquOS7Ox17PbwqMbmjJxBMO99iOU3TD7oCtEH7PJACvc7DrPpRIpgb D8YLHLC6ss1LrzB7GJ9zOxZsnin/DBYkNDfAI6r3W6FdszL8yZkti72PgTrBSql1YSoCKZ2E W56N07yg68KyI58+zKrdObBagRjSSx/Ma0M/jBwzFJS0GbvC+zvUa7wiy7KxmsOKSrTFSSwo wh8+DKyagrE8Ux8v/CJt6TzJO6bzO7pJ7CuSGrJXZEInpKIgYzsNEiSnyzQj67on/EQt3MXC WjWdQh9bFJ+o+ykci74RpDiP60GJW6Q1rCeBOa0VezDZAyGH0yetG6GpK6iPk5lZWyBForVg a6NiC4vcM0dv8cGBWT0Cyy/s45oOxAt5HI1zMJuuoUe+UcXy48d+9Md/BMiABL/PcsCBy0D7 wy7/W8CC/6zAYFq/yaCje7wO9YobeYNAhlwthXy/qrC4kMkphGyvfrPAhQQiksy/BxwVhTxI BZS/d1xIS8IjMTk9hwzJhHzIfGQ3eBExd6SwBgMenvrAN7qwDEPBFjzBGES7flqwETwnEbSe Z6yYRNw7GYms1tqsi3st3TMdocS45/shnRsqDDFGLGwWnfqosBIySIw5VLuzJySrkBrGWMm5 mevFl4tEKOzESTwM1jIe8grDbKITbjTLl4OzOSOzsqs8M2sz14NG6hHMugPDXeQ6WPw1Hsw6 AhKVvMRMnMybPgvMyMO1+Mm5tcPFu2QyPoI8uBPLLwy8JMOx0WNNxbzFj0xDfP9TTXjMxU4s NTlkxdRkxMjjKtKMHlSUTMdDS9cUPVmsy6DBPD6zM7Y0yb/4FqosuUBap5upMhP7rqqcMuzU Tl6zvRV5tobbwa0MPkLqM9XDI+qcmWO5wYbJymXLw5ETSIgcyQ3ct/rstiIcQH3jTP0E0AAV 0AEl0AItw3zLP5gMJ448SQRVm/+0TwelpgntO8xpSJa8m6HLyWpSydJTNwkFUZv0UH8jQPwk 0QK8TxHVm9MYMaVsqJ80uJ2kNYKiz917MFFBsY5zLe6M0avcsAKbluFBwX7ZyutEOdLhsLPz yIPKOAhlUNMMtcx7MSzExUfkPOjUNO8JSzTMvJ+LtE//pEW9/DRmcysgdMVYNL1yPLPyEUyT KbOPYTspxDrfTDrYpLxUVFNL/FKpy9M15CkLCpnAREe8JB6k8cUI1cUstM28WqYqhZdksrs4 bTzGkk0mtLxLTSsrbDuvOk0ybKwnO1RhYc0oFaojm0u71Mzh/M3jXM62O8u9u1MvMsMr2sNE LcY7FapW09K+dEoZRDirtNHtPL4QJEEuccrf00rz9BdobB3BM1PqdCNZKzbV+xkYRNLn7Ehj VUEDfS9uJYwbeCUn9dZxJddyNddzRdfly0++Ub8tjJCLPNF0FaN1hdcGhK9Ok0uEdElvktfo E9cDBFh3pddn2lcI+Vdvw7hn/32yZSPKM7qn6pRBDWvBQVyoPLzRGtw+HOQrae3XJLQuUI0x GwOtr4RFNvSgMyW9WYxUK6TLP+zQfi2zfDUv9bw/UnVTxGzTIcm1PM2VGFvZL1OXN42rg7U2 tZLZHTNaRX0xP0NOJwI1+ClE5iRMSDUhPNSyjq1ItyHGnp00mzVVKYVaw/JZIkvMUt3DqWJB rB0vq6Qhy+QfYBPBpEQkGcU1y0SZlTqWRsyphKPGZawgMClYcNsD5SLaxXAFtQU4xFXcxWXc xnXcx82LSqgEyP0JyRU/yyUIydXczJ3chbBczd3cfwDdzsVc0e1czwVdhyhd00Vdzk1d031d 2J3c0f+d3dENidWt3dQt3dPFXNuFCd/VXdul3dt93eGV3dVtXeJ13dA13uMl3dMFt96F3tpV XeqtXtVl3ey9XuLdXd61Xs7V3u7dXu393d0l3+xl3u8VXeX1XPBN3vMdX/L9XO8t3+md3+sV X/hF3m7L38yVX/WVX9bdX/0N3fBV3/t13/993/ptX+SV3ucN4PiF4Pcd4ARW4P5F3Qc+4O+V 3pio4GzDYAtG4AVeXplw4AkWYBROYQq2XxLG3t49XxiG4A+GXwW2YPYVYQ6GXv8V3g024BsG 4m0LYeed3+BlYBMuXhRGYNzN3QK2Yee9XfBtYg2W3QweYN994uZdXh/W4vb/hV0pbuHmFeMd 5rYhZuIYJuPYxWH3Fd8Obt0RzmEX9uLPJeAiJuMaTt4zDuI4fmMA9uL1BWP89eHy/T4M5uId xt0VJmQrjt0CPmM35mM8BuQv3t/ghWESbuEsvuNIVuQr9uBDTuAr3mQQpt8GDmNEnl70TeNM DmVD1uEFHuI/3lxRpuD4nWRVHt8P1uNABuI7huMRhmRb5l/vTV9BTuJivuFdNmD7TWJjLmUo xt4+buRnPt5PTt/+7eITbmZM/uQtVmE7DuZvo2HKtYlxJuXIeK7lMmdyZud2dud3hud4lud5 pud6tud7xud81ud95ud+9ud/dg54AOiBJuiCNuiD/0bohFbohQaNV/ALh2boiJboiabofiUA AnCIi9ZojCaIjb7omPBojP7ohfjoje5ok4YJjz5pkx7pjOZoklbpfwjplObokZ5pmX7pko7p kLhpl3ZplPZpmAZqkH5pnM5onB5qmCZppWbqldZop67pom5pqBbpnW5qpH5qqqZplJ7qojZq no5qrpZqrJ7qkw5qm/ZqqADqlkbrqw7qrzbrr+5qsD7qss7qlSbqq7brqIZro2brqnZruO7q u/7rn87pw5aJtWZrwU5rtOZrp6bruO7ovi5ryS5soUbsuK5sva7qnAZrqdZpnyZsxjZspm5r qlBs0QbtvJZsuX7syX5rmf/ua6yGbJrm7MgObaUu7Mt+68Hmbcbm7c2mbbye7MHG7dMe7qae a+O2bcsG7d/ObdY269Eubdo27tFm7uQ+beH+ie1e7ezu7dV2bZqobLsm69l27tiu7etG7N9O b81+7fGWb/SWb8CWbfCWa9mub/FGb/x+b9Keb79O69u2b6/u7NC+7vxmbuRO7Ztg6bs27fiO bvr+65uu8PIOa7IWaeLebOhu7Kxmb922asxecAl/bMeG8LOu6emm7A/X6cvObgzv6fAeau9W bZTmhdYuaRY/aqSe7u9m8RJ3bvd+ChsXcfX+7wB369028KVubeXm7/BW7SMX7gnfbxWHb/rO cv3/3nH/fnAY528MR3LS3ust//GZSHC/5mknF3DRDnLxRu4Wn4qQnvA6H3AP12z1ZvI1b+7I lvM+D/Ezp/DXpnP7/vGZjnMSf+rDNvT+XnQQp3Mor+sol3TgVulAl241J242n3LdFmo5L/TA nvPvzmwiT/Lt1vP2bvI+l3JRx/M9f3IAx/Q4j24x93S8NnUA/3Ndv29K/29aN/REj+0d33TY pus093Ewb/VYBwr2VuykXnYBR/E7v/RLz3TOhnYd3+mYxm9Ml3bCJvVUd3MRz/ZfD/PnBnbp 9vYXB3dot3A9Z+13J3dwj3buruh7x/d81/d95/d+Zy4f8PfIsPeAD44Z/7fwsWb3vX7wea/z z4Z0h6dsWR9wgkcLZSf3pTb1Mhf0Tzf29LZ17Cb0iad4s1j3zuZ0Ztf4Nv/pk4d1FfdsOx/5 tij5Xu94lP9wJS9wP7dyBV/xpB74mOeJLzfwcL91Yh/zg3dtluZxRY91m37zmwd6tZh5voZ6 Pz/y2aZ6nW/0PFdznxf5qL+Kqef4o6f2zGbzFG950/70na+NPihXi1/6FB90ojZ7Y0d7VW9u Rp/vnwf7Ua9xbkfyDt/2Czd6rOf2ai/8Wo/vvmf8xnf8x4f8yJf8yad8V+L7ypd5sT77Rt96 w/97sQZ9Wv92GU90REd8esd8HU/6Q8d439Z6bf43/El/+brX69gXdzPH/OXOcGlvfRS3epgv c1Mo7sW2+tpP+SeH+9yH+g3v+p4/7+MH/qFP6fwu/qaX/ttX8pEX+q2+8OHO+t2Hfs4/8GmH 7cJn9vP2/EdfeNxP/Qhn9/LfcM9GfqLf+LzO+uq37eNP/1yPfDhX/xUHiH//CBAcKPCgwIII FSYkMNDhwYIMEy50CPHhxYgZI1Z8iNBjx5AfR5IsafIkypQqV7Js6fIlzJgyZ9KsWTIjw5wX d0okOREkyIkSN+K0qHEj0IUdfzIlijSpzahSp1KtavUqVqkEt4rMudSn061FxTYki1Fh0ZE/ j6IVa9Ht2aFgs9Kta/73Lt68evfy7ev3L+DAggcTLmz4MOLEihczbuz4MeTIkidTrmz5MubM mjdz7uz5M+jQokeTLm36NOrUqlezbu36NezYsmfTrm37Nu7cunfz7u37N/DgwocTL278OPLk ypczb+78OfTo0qdTr279Ovbs2rdz7+79O3iaAGrzC98dAPrxd9V/5ue+PEv45rWzZ0/X/mb3 CPWrlD8fe30HpafegP+kJ+CBBgooUIIEnlQehO/9I+GEB0FY4XsRwieff/tJSOGEIGp4YYUC bcifhhaKCKKHKFKYYYgd/odagAouWKOC9o2HI4M24vcRihYKyWGIJgppJJEkJYnhfkwa6f5k iUMS6R+JTx55JZRLzkhjgjb2iOOOCDn4Y5gpLZkkiWceWeVIalKZ5ZNsItnkm282eeecVsq4 JWkOMjhgmV4G6qOgB/6o5JVolqhmnFG2mWiMH0a5YZ6ROsompkBqOiSkfNK4oJegChrqmD1+ 2V+ni6qq55qObjqpq3CqSmmlUNraIa50puppaTXqOOqpooJJqEmMwsoqsrHiOeWdI/KXbKZ1 NmsltVVqiRUvvAb2q4ENCvsnemKKaaipJRl7bqp7pmviig+2mKml7D7L4Ysv7qotvoTB+Gq+ /dqVIcABCzwwwQUbfDDCCSu8MMD+OvwwxBFzx4rEFVt8McYZF/52KF3qzmRnXh5Tu5LILT2r MWKAimrSoRxHtSfIJOOJV8kla2ozlvyinLK4K7mMFcwzmyn0XTW/hPPQOyuGX5kNktvtmIaG C26poT5ar34wpljttKy6eW+8W8eIYZBek33iyUxiPaLSgzGdY88rwz3sr1NbDaSiiebN9bGy +p2rlJyqKDisEWKZ67yN5tw2X28P+ra4gQZYd3xdJ6ssyBdaqzancl76ecyUal7rtbcqPjLj ezn+Z7mmFij5jSr/zC+tl8sYOudzbj463lo3W/usTsIbtJ3AI536Vavf+BHssAcbd9Kn9x0r 7rxzzqznt888fO7cX911zMjrxS3lkWsvf8u35bf+aKu71h7+tfEfznX1y0Iq7bTF8y2+6gV+ affrqAa3chHIW3Kj3eDYFSljuUp+I9MSvcqGJAn2bUr7uiDp9MQi/ilHZOHjIAiBxrARkrCE JjwhChsWwhWysIUufCEMYyjDGZImIAA7 ------=_NextPart_000_0002_01C6B542.623E0AE0-- From solvirad@copaair.com Mon Jul 31 11:38:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ZqJ-0001P9-UX for capwap-archive@ietf.org; Mon, 31 Jul 2006 11:38:07 -0400 Received: from bl4-217-61.dsl.telepac.pt ([81.193.217.61] helo=copaair.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7ZqG-0005LJ-LP for capwap-archive@ietf.org; Mon, 31 Jul 2006 11:38:07 -0400 Message-ID: <000001c6b4b6$d2abf490$8c08a8c0@sci57> Reply-To: "Solveig Radel" From: "Solveig Radel" To: capwap-archive@ietf.org Subject: Re: fekefVijagra Date: Mon, 31 Jul 2006 08:34:33 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6B47C.264D1C90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.2 (++++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6B47C.264D1C90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Valijum from 1, 25 $ Vijagra from 3, 35 $ Ambijen Cijalis from 3, 75 $ =20 http://www.impalidakogun.com =20 , , , , , nasty and dangerous edge to it. And thinking about dangerous, there was the other dangerous always hanging over my head. My computer flashed me the highly unwelcome ------=_NextPart_000_0001_01C6B47C.264D1C90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hi,
     
    Valijum from 1, 25 $
    Vijagra from 3, 35 $
    Ambijen
    Cijalis from 3, 75 $
     
     
    ,
    ,
    ,
    ,
    ,
    nasty and dangerous edge to = it.
    And thinking about dangerous, there was the other dangerous = always
    hanging over my head. My computer flashed me the highly = unwelcome
    ------=_NextPart_000_0001_01C6B47C.264D1C90--