From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 01 00:18:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ0Tt-0006SF-64 for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 00:18:13 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ0Tp-0004j9-Ih for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 00:18:13 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5156D398082 for ; Thu, 31 Aug 2006 21:17:58 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 56050430082 for ; Thu, 31 Aug 2006 21:16:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 37469144801B for ; Thu, 31 Aug 2006 21:16:36 -0700 (PDT) Received: from huawei-3com.com (pop.huawei-3com.com [219.133.0.18]) by hermes.tigertech.net (Postfix) with ESMTP id 7C7A91448076 for ; Thu, 31 Aug 2006 21:16:33 -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 <0J4W007BWCCGTC@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Fri, 01 Sep 2006 12:26:40 +0800 (CST) Received: from RichardYoung ([10.18.23.88]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4W00244CCB28@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Fri, 01 Sep 2006 12:26:40 +0800 (CST) Date: Fri, 01 Sep 2006 09:46:35 +0530 From: young To: pcalhoun@cisco.com Message-id: <001501c6cd7d$6a284d30$5817120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcbNfWlYtYdLj+sLSCOan0Hc1UpnRQ== 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: Re: [Capwap] Issue 161: Ther term "Mobile" is not really accurate 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="===============1115920064==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 This is a multi-part message in MIME format. --===============1115920064== Content-type: multipart/related; boundary="Boundary_(ID_G9VOFO1znAtE4MniuDVl6A)" This is a multi-part message in MIME format. --Boundary_(ID_G9VOFO1znAtE4MniuDVl6A) Content-type: multipart/alternative; boundary="Boundary_(ID_8JCuUA5oYGLDgUyzegH+Ig)" --Boundary_(ID_8JCuUA5oYGLDgUyzegH+Ig) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi,Pat: As IP is every where, how about use Mobile IP's conception of "mobile node" ? Regards Richard Re: Issue 161: Ther term "Mobile" is not really accurate From: Pat Calhoun (pacalhou) (pcalhouncisco.com) Date: Thu, 31 Aug 2006 15:48:46 -0700 (PDT) Folks, I need a term. I don't care if it's foobar, but need something everyone will agree to. If station doesn't cut it, as bob insists, then I need something to work it. Help, Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems --Boundary_(ID_8JCuUA5oYGLDgUyzegH+Ig) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,Pat:

As IP is every where, how about use Mobile IP’s conception of “mobile node” ?

 

Regards

Richard

 

Re: Issue 161: Ther term "Mobile" is not really accurate

From: Pat Calhoun (pacalhou) (pcalhouncisco.com)

Date: Thu, 31 Aug 2006 15:48:46 -0700 (PDT) 

Folks, I need a term.
 
I don't care if it's foobar, but need something everyone will agree to.
If station doesn't cut it, as bob insists, then I need something to work
it.
 
Help,
 
Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

--Boundary_(ID_8JCuUA5oYGLDgUyzegH+Ig)-- --Boundary_(ID_G9VOFO1znAtE4MniuDVl6A) Content-id: Content-type: image/gif; name=image002.gif Content-transfer-encoding: base64 Content-disposition: attachment; filename=image002.gif R0lGODlhDQAMAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAAAB AAEAgAAAAAECAwICRAEAOw== --Boundary_(ID_G9VOFO1znAtE4MniuDVl6A)-- --===============1115920064== 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 --===============1115920064==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 01 01:52:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ1xX-0008Dq-5A for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 01:52:55 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ1xV-00040b-7V for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 01:52:55 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id DDC30144808A for ; Thu, 31 Aug 2006 22:52:48 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id DDD88430082 for ; Thu, 31 Aug 2006 22:50:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8C3A61448076 for ; Thu, 31 Aug 2006 22:50:24 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [61.144.161.54]) by hermes.tigertech.net (Postfix) with ESMTP id 83FE3144803E for ; Thu, 31 Aug 2006 22:50:02 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4W00MA4H14QM@szxga02-in.huawei.com> for Capwap@frascone.com; Fri, 01 Sep 2006 14:07:53 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4W00LV1H13O0@szxga02-in.huawei.com> for Capwap@frascone.com; Fri, 01 Sep 2006 14:07:52 +0800 (CST) Received: from dell60 ([10.18.23.153]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4W00DIHGDZO8@szxml03-in.huawei.com> for Capwap@frascone.com; Fri, 01 Sep 2006 13:54:03 +0800 (CST) Date: Fri, 01 Sep 2006 11:19:56 +0530 From: sujay In-reply-to: <4FF84B0BC277FF45AA27FE969DD956A2026C449E@xmb-sjc-235.amer.cisco.com> To: "'Pat Calhoun (pacalhou)'" , Capwap@frascone.com Message-id: <001101c6cd8a$748b1250$9917120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcbBlmoFFLfYFKe2RBWbzsJnmko2kwAJn6NwABjENJAAAC1bsAAabeQgABTXEnACnclygAANXHFw 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: Re: [Capwap] Issue 182: Change State Event should instead beRadioAdmin State. 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: 9aa22b77adc37e7d33e29644e4dc0b33 Sujay is happy :) Regds, Sujay G My Location; http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=h &hl=en This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Friday, September 01, 2006 4:57 AM To: Pat Calhoun (pacalhou); sujay; Capwap@frascone.com Subject: RE: [Capwap] Issue 182: Change State Event should instead beRadioAdmin State. Sujay, are you happy with the current agreement? can I assume this issue is closed? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Friday, August 18, 2006 8:50 AM > To: sujay; Capwap@frascone.com > Subject: Re: [Capwap] Issue 182: Change State Event should instead > beRadioAdmin State. > > I think it gets really ugly when we start mixing these schemes. > > Remember that radio admin state is saved across reboots, so the AC > wants to represent to the network administrator the fact that the > radios have been permanently disabled. If the operational state was > used to communicate this to the AC, then it would be very difficult > for the AC to know whether the configuration is permanent or not. > > I would prefer we maintain strict usage of the message elements. > > Pat Calhoun > CTO, Wireless Networking Business Unit Cisco Systems > > > > > -----Original Message----- > > From: sujay [mailto:sujayg@huawei.com] > > Sent: Thursday, August 17, 2006 10:58 PM > > To: Pat Calhoun (pacalhou); Capwap@frascone.com > > Subject: RE: [Capwap] Issue 182: Change State Event should > instead be > > RadioAdmin State. > > > > Hi, > > > > I would propose using Radio Operational State for the > purpose defined > > and not Radio Administrative State message element. > > If the WTP has to communicate its previous saved config, it could > > indicate it well enough using Radio Operational State element with; > > State-> En/Dis And Cause->Administratively Set. > > This is more flexible, consider a case it was enabled > > administratively, saved, but due to some reason radio is > not up. Radio > > Op State TLV is better equipped to say this and more. > > > > Regds, > > Sujay G > > My Location; > > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.72485 > > 2,7.525085&t=h > > &hl=en > > > > > > This e-mail and attachments contain confidential information from > > HUAWEI, which is intended only for the person or entity > whose address > > is listed above. Any use of the information contained herein in any > > way (including, but not limited to, total or partial disclosure, > > reproduction, or > > dissemination) by persons other than the intended > > recipient's) is prohibited. If you receive this e-mail in error, > > please notify the sender by phone or email immediately and > delete it! > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Thursday, August 17, 2006 10:46 PM > > To: sujay; Capwap@frascone.com > > Subject: RE: [Capwap] Issue 182: Change State Event should > instead be > > RadioAdmin State. > > > > In re-reading the text, I would propose: > > > > The Radio Administrative State message element is used to > > communicate > > the state of the WTP, or of a particular radio. The > configuration > > of the > > Radio Administrative State is sent by the AC to change > the state of > > the > > WTP, which saves the value to ensure its effect remains > across WTP > > resets. The WTP communicates this message element during the > > configuration > > phase to ensure that AC has the WTP radio's current > administrative > > state > > settings. The value contains the following fields. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) > > > Sent: Thursday, August 17, 2006 10:12 AM > > > To: sujay; Capwap@frascone.com > > > Subject: Re: [Capwap] Issue 182: Change State Event should > > instead be > > > RadioAdmin State. > > > > > > Sujay, > > > > > > I'm ok with all of your change requests, with the > exception of the > > > following. > > > > > > > 4.4.28. Radio Administrative State > > > > > > > > The Radio Administrative State message element is used to > > > > communicate > > > > the state the WTP, or of a particular radio. It is > > > sent from > > > > the AC to the > > > > WTP The configuration of > > > > the Radio Administrative State is saved on the WTP, and > > > its effect > > > > remains across WTP resets. The value contains the following > > > > fields. > > > > > > Actually, this comment is invalid. The WTP indicates its > > current radio > > > administrative state during the config phase to the AC. I > will add > > > text to make this clearer. > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > -----Original Message----- > > > > From: sujay [mailto:sujayg@huawei.com] > > > > Sent: Wednesday, August 16, 2006 11:29 PM > > > > To: Pat Calhoun (pacalhou); Capwap@frascone.com > > > > Subject: RE: [Capwap] Issue 182: Change State Event should > > > instead be > > > > Radio Admin State. > > > > > > > > Hi Pat, > > > > You did address some of my concerns. > > > > I have some comments inline. > > > > > > > > The other changes suits me. > > > > Regds, > > > > Sujay G > > > > My Location; > > > > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.72485 > > > 2,7.525085&t=h > > > > &hl=en > > > > > > > > > > > > This e-mail and attachments contain confidential > information from > > > > HUAWEI, which is intended only for the person or entity > > > whose address > > > > is listed above. Any use of the information contained > > herein in any > > > > way (including, but not limited to, total or partial > disclosure, > > > > reproduction, or > > > > dissemination) by persons other than the intended > > > > > > recipient's) is prohibited. If you receive this e-mail > in error, > > > > please notify the sender by phone or email immediately and > > > delete it! > > > > -----Original Message----- > > > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > > > Sent: Thursday, August 17, 2006 6:15 AM > > > > To: Capwap@frascone.com > > > > Subject: [Capwap] Issue 182: Change State Event should > instead be > > > > Radio Admin State. > > > > > > > > This issue really contains two parts: > > > > > > > > 33) Use of Change State Event should instead be Radio > Admin State. > > > > No. However, I do agree that there is some confusion around the > > > > difference between both. So I am proposing two things; add > > > > clarification language to both message elements, and rename > > > the Change > > > > State Event message element to instead be called Radio > > Operational > > > > State. > > > > > > > > Note that the primary difference between both is that the > > > Radio Admin > > > > State is saved on the WTP, and therefore takes effect > > > across reboots. > > > > The operational state does not. > > > > > > > > > > > > 4.4.11. Radio Operational State > > > > > > > > The Radio Operational State message element is sent by > > > the WTP to > > > > the > > > > AC to communicate a change in the operational state of > > a radio. > > > > For > > > > instance, if the WTP were to detect that a hardware > > > failure existed > > > > with a radio, which caused the radio to be taken > > offline, the WTP > > > > would indicate this event to the AC via the message > > > element. The > > > > AC > > > > MAY also send this message element to change the > > > operational state > > > > of > > > > a specific radio. Note that the operational state > > setting is not > > > > saved on the WTP, and therefore does not remain across > > > WTP resets. > > > > The value contains two fields, as shown. > > > > > > > > > > > > 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 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | Radio ID | State | Cause | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > Type: 11 for Radio Operational State > > > > > > > > Length: 3 > > > > > > > > Radio ID: The Radio Identifier, typically refers to some > > > > interface > > > > index on the WTP.The value 0xFF is invalid as it > > > does not > > > > indicate > > > > any specific radio. > > > > > > > > State: An 8-bit boolean value representing the state of > > > > the radio. > > > > A value of one disables the radio, while a value of > > > two enables > > > > it. > > > > > > > > Cause: In the event of a radio being inoperable, the > > > cause field > > > > would contain the reason the radio is out of service. The > > > > following values are supported: > > > > > > > > 0 - Normal > > > > 1 - Radio Failure > > > > 2 - Software Failure > > > > 3 - Administratively Set > > > > > > > > > > > > 4.4.28. Radio Administrative State > > > > > > > > The Radio Administrative State message element is used to > > > > communicate > > > > the state the WTP, or of a particular radio. It is > > > sent from > > > > the AC to the > > > > WTP The configuration of > > > > the Radio Administrative State is saved on the WTP, and > > > its effect > > > > remains across WTP resets. The value contains the following > > > > fields. > > > > > > > > 0 1 > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | Radio ID | Admin State | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > Type: 28 for Radio Administrative State > > > > > > > > Length: 2 > > > > > > > > Radio ID: An 8-bit value representing the radio to > > > > configure. The > > > > Radio ID field may also include the value of 0xff, > > > which is used > > > > to identify the WTP itself. Therefore, if an AC > wishes to > > > > change > > > > the administrative state of a WTP, it would include > > > 0xff in the > > > > Radio ID field. > > > > > > > > Admin State: An 8-bit value representing the > > > administrative state > > > > of the radio. The following values are supported: > > > > 1 - Enabled > > > > 2 - Disabled > > > > > > > > 8.6. Change State Event Request > > > > > > > > The Change State Event Request message is used by the > > > WTP to inform > > > > the AC of a change in the operational state. > > > > > > > > The Change State Event Request message is sent by the > > WTP when it > > > > receives a Configuration Response message that > > includes a Change > > > > State Event message element. It is also sent when the > > > WTP detects > > > > an > > > > operational failure with a radio. The Change State > > Event Request > > > > message may be sent in either the Configure or Run state (see > > > > Section 2.3. > > > > > > > > > > > > > > > > Change above para to; > > > > " > > > > The Change State Event Request message MUST be sent by > > > the WTP when > > > > it > > > > receives a Configuration Status Response message which > > > includes a > > > > Radio Administrative State message element. > > > > It is also sent when the WTP detects an operational > > > failure with a > > > > radio. The Change State Event Request > > > > message may be sent in either the Configure or Run state > > > > (see Section > > > > 2.3.). > > > > " > > > > - the "MUST" is needed as it helps the state machine transition. > > > > > > > > > > > > When an AC receives a Change State Event message it > > will respond > > > > with > > > > a Change State Event Response message and make any necessary > > > > modifications to internal WTP data structures. > > > > > > > > The following message elements MUST be present in the > > > Change State > > > > Event Request message. > > > > > > > > o Radio Operational State message element, see > Section 4.4.11 > > > > > > > > 8.7. Change State Event Response > > > > > > > > The Change State Event Response message acknowledges > > the Change > > > > State > > > > Event Request message. > > > > > > > > A Change State Event Response message is by a WTP after > > > receiving a > > > > Change State Event Request message. > > > > > > > > For above para; > > > > A Change State Event Response message is received by a > > WTP after > > > > sending > > > > the Change State Event Request message. > > > > > > > > The Change State Event Response message carries no message > > > > elements. > > > > Its purpose is to acknowledge the receipt of the Change > > > State Event > > > > Request message. > > > > > > > > The WTP does not need to perform any special > processing of the > > > > Change > > > > State Event Response message. > > > > > > > > > > > > > > > > > > > > 43) Change State Event Report. This seems a little silly to > > > be sent in > > > > the "configure" state. It seems only appropriate for the > > > "run" state. > > > > Some might argue that even in the "run" state it > > shouldn't be sent > > > > after a "config update" request that changes the > > operational state. > > > > However, in the "run" state, it may take a while to have the > > > > operational state change to follow the admin state. Thus, I > > > think it > > > > is OK in the "run" > > > > state after config changes." > > > > > > > > I disagree. Once the config exchanges have > > occurred, the WTP > > > > needs to configure its radios, and then send an update to > > > the AC when > > > > this is done. > > > > This message is used to inform the AC of the final state of > > > the radios > > > > on the WTP. I therefore believe that the state machine is > > > fine as is > > > > as it provides a nice transition between unconfigured and > > > configured. > > > > > > > > I completely agree with Pat's above point...! > > > > > > > > Pat Calhoun > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > _________________________________________________________________ > > > > 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 > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From desi@icwuc.org Fri Sep 01 02:19:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ2NN-0002xS-Tl for capwap-archive@ietf.org; Fri, 01 Sep 2006 02:19:37 -0400 Received: from [219.136.127.33] (helo=icwuc.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GJ2NL-0007by-JJ for capwap-archive@ietf.org; Fri, 01 Sep 2006 02:19:37 -0400 Received: by 192.168.151.48 with SMTP id oXsfYYlmX; for ; Thu, 31 Aug 2006 23:19:26 -0700 Message-ID: <000001c6cd8e$92fbe670$3097a8c0@jcexuti> Reply-To: "Kathryn Hague" From: "Kathryn Hague" To: capwap-archive@ietf.org Subject: Re: yaR Xci Date: Thu, 31 Aug 2006 23:19:26 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6CD53.E69D0E70" 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.8 (+++) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6CD53.E69D0E70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 All you o r PHA c RRMA p CY d u irect b ly from the m h anufac y ture u r, Your c j hanc d e to ec d onomi f ze w h ith us http://poionkertunkades.com d=20 h=20 x=20 We aint goin away. planet named Ochaye, which is perhaps galaxy-famous for its other You and your companions kept the news channels alive. When they said ------=_NextPart_000_0001_01C6CD53.E69D0E70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
All you o r PHA c RRMA p CY d u irect b ly from the m h anufac y ture u r,
Your c j hanc d e to ec d onomi f ze w h ith us http://poionkertunkades.com

  d

  h

  x

We aint goin away.
planet named Ochaye, which is perhaps galaxy-famous for its = other
You and your companions kept the news channels alive. When they = said

------=_NextPart_000_0001_01C6CD53.E69D0E70-- From skitrip2008-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 01 08:36:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ8Fc-0003H4-EH for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 08:36:00 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ8FW-0003Lu-Lr for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 08:36:00 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 8A8BA1448062 for ; Fri, 1 Sep 2006 05:35:46 -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: skitrip2008-owner@frascone.com To: capwap-archive@lists.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Sep 2006 05:30:58 -0700 Precedence: bulk X-BeenThere: skitrip2008@frascone.com X-Mailman-Version: 2.1.8 List-Id: Our Next Skitrip! X-List-Administrivia: yes Errors-To: skitrip2008-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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, skitrip2008-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 Fri Sep 01 09:42:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ9I6-0006RW-AV for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 09:42:38 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ9I0-0005eX-FH for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 09:42:38 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 997F7398013 for ; Fri, 1 Sep 2006 06:42:31 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9811243005A for ; Fri, 1 Sep 2006 06:40:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 871E74306ED for ; Fri, 1 Sep 2006 06:40:20 -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 A10EE4306D1 for ; Fri, 1 Sep 2006 06:40:18 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 01 Sep 2006 06:40:18 -0700 X-IronPort-AV: i="4.08,201,1154934000"; d="gif'147?scan'147,208,217,147"; a="316841659:sNHT74218250" 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 k81DeIB4007820; Fri, 1 Sep 2006 06:40:18 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k81DeH6W002466; Fri, 1 Sep 2006 06:40:18 -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); Fri, 1 Sep 2006 06:40:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Sep 2006 06:40:15 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2026C4572@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Issue 161: Ther term "Mobile" is not really accurate Thread-Index: AcbNfWlYtYdLj+sLSCOan0Hc1UpnRQATpx/g From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 01 Sep 2006 13:40:17.0051 (UTC) FILETIME=[28F07EB0:01C6CDCC] Authentication-Results: sj-dkim-8.cisco.com; header.From=pcalhoun@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.8 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, EXTRA_MPART_TYPE, HTML_MESSAGE, HTML_TAG_EXIST_TBODY, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 161: Ther term "Mobile" is not really accurate 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="===============2055138440==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 This is a multi-part message in MIME format. --===============2055138440== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C6CDCC.28D21458" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6CDCC.28D21458 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C6CDCC.28D21458" ------_=_NextPart_002_01C6CDCC.28D21458 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well... the only issue I have with mobile node is that in the IETF world it assumes the device is running the Mobile IP stack. This is inconsistent with the assumptions in CAPWAP/IEEE 802.11. However, if folks are ok with the term, along with a new definition, then I can be convinced. =20 I'm still ok with station as well. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: young [mailto:young@huawei-3com.com]=20 Sent: Thursday, August 31, 2006 9:17 PM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Re: Issue 161: Ther term "Mobile" is not really accurate =09 =09 Hi,Pat: As IP is every where, how about use Mobile IP's conception of "mobile node" ? =20 Regards Richard =20 Re: Issue 161: Ther term "Mobile" is not really accurate =20 From: Pat Calhoun (pacalhou) (pcalhoun cisco.com)=20 Date: Thu, 31 Aug 2006 15:48:46 -0700 (PDT)=20 Folks, I need a term. =20 I don't care if it's foobar, but need something everyone will agree to. If station doesn't cut it, as bob insists, then I need something to work it. =20 Help, =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_002_01C6CDCC.28D21458 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Well... the only issue I have with mobile node is that in the = IETF world=20 it assumes the device is running the Mobile IP stack. This is = inconsistent with=20 the assumptions in CAPWAP/IEEE 802.11. However, if folks are ok with the = term,=20 along with a new definition, then I can be = convinced.
 
I'm=20 still ok with station as well.
 

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

 

From: young = [mailto:young@huawei-3com.com]=20
Sent: Thursday, August 31, 2006 9:17 PM
To: Pat = Calhoun=20 (pacalhou)
Cc: capwap@frascone.com
Subject: Re: = Issue 161:=20 Ther term "Mobile" is not really accurate

Hi,Pat:

As IP is every where, how = about use=20 Mobile IP’s conception of “mobile node” = ?

 

Regards

Richard

 

Re: Issue 161: Ther term "Mobile" is = not=20 really accurate

 

From: Pat Calhoun (pacalhou) = (pcalhouncisco.com)=20

Date: Thu, 31 Aug 2006 15:48:46 = -0700 (PDT)=20 

Folks, I need a term.
 
I don't care =
if it's foobar, but need something everyone will agree =
to.
If station =
doesn't cut it, as bob insists, then I need something to =
work
it.
 
Help,
 
Pat =
Calhoun
CTO, Wireless =
Networking Business Unit
Cisco Systems

 

------_=_NextPart_002_01C6CDCC.28D21458-- ------_=_NextPart_001_01C6CDCC.28D21458 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: <166183913@01092006-28B3> Content-Description: image002.gif Content-Location: image002.gif R0lGODlhDQAMAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAAAB AAEAgAAAAAECAwICRAEAOw== ------_=_NextPart_001_01C6CDCC.28D21458-- --===============2055138440== 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 --===============2055138440==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 01 09:54:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ9TR-0001Yl-Ck for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 09:54:21 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ9TQ-0006Ff-Cp for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 09:54:21 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id B83CA39803D for ; Fri, 1 Sep 2006 06:40:37 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C6ECA43005A for ; Fri, 1 Sep 2006 06:38:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AB425144802C for ; Fri, 1 Sep 2006 06:38:14 -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 66357144801C for ; Fri, 1 Sep 2006 06:38:13 -0700 (PDT) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 01 Sep 2006 06:38:13 -0700 X-IronPort-AV: i="4.08,201,1154934000"; d="scan'208"; a="316840570:sNHT39530720" 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 k81DcCF4014681; Fri, 1 Sep 2006 06:38:12 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k81DcC6W000732; Fri, 1 Sep 2006 06:38:12 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Sep 2006 06:38:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Sep 2006 06:38:11 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2026C4571@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 182: Change State Event should instead beRadioAdmin State. Thread-Index: AcbBlmoFFLfYFKe2RBWbzsJnmko2kwAJn6NwABjENJAAAC1bsAAabeQgABTXEnACnclygAANXHFwABBemmA= From: "Pat Calhoun (pacalhou)" To: "sujay" , X-OriginalArrivalTime: 01 Sep 2006 13:38:12.0452 (UTC) FILETIME=[DEAC3240:01C6CDCB] Authentication-Results: sj-dkim-6.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] Issue 182: Change State Event should instead beRadioAdmin State. 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: d4a1871e876bd836d4c351e861e8720d Good - I will consider the issue closed. Thanks for your help in this matter, Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: sujay [mailto:sujayg@huawei.com] > Sent: Thursday, August 31, 2006 10:50 PM > To: Pat Calhoun (pacalhou); Capwap@frascone.com > Subject: RE: [Capwap] Issue 182: Change State Event should > instead beRadioAdmin State. > > Sujay is happy :) > > Regds, > Sujay G > My Location; > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.72485 > 2,7.525085&t=h > &hl=en > > > This e-mail and attachments contain confidential information > from HUAWEI, which is intended only for the person or entity > whose address is listed above. Any use of the information > contained herein in any way (including, but not limited to, > total or partial disclosure, reproduction, or > dissemination) by persons other than the intended > recipient's) is prohibited. If you receive this e-mail in > error, please notify the sender by phone or email immediately > and delete it! > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Friday, September 01, 2006 4:57 AM > To: Pat Calhoun (pacalhou); sujay; Capwap@frascone.com > Subject: RE: [Capwap] Issue 182: Change State Event should > instead beRadioAdmin State. > > Sujay, are you happy with the current agreement? can I assume > this issue is closed? > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) > > Sent: Friday, August 18, 2006 8:50 AM > > To: sujay; Capwap@frascone.com > > Subject: Re: [Capwap] Issue 182: Change State Event should instead > > beRadioAdmin State. > > > > I think it gets really ugly when we start mixing these schemes. > > > > Remember that radio admin state is saved across reboots, so the AC > > wants to represent to the network administrator the fact that the > > radios have been permanently disabled. If the operational state was > > used to communicate this to the AC, then it would be very difficult > > for the AC to know whether the configuration is permanent or not. > > > > I would prefer we maintain strict usage of the message elements. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > -----Original Message----- > > > From: sujay [mailto:sujayg@huawei.com] > > > Sent: Thursday, August 17, 2006 10:58 PM > > > To: Pat Calhoun (pacalhou); Capwap@frascone.com > > > Subject: RE: [Capwap] Issue 182: Change State Event should > > instead be > > > RadioAdmin State. > > > > > > Hi, > > > > > > I would propose using Radio Operational State for the > > purpose defined > > > and not Radio Administrative State message element. > > > If the WTP has to communicate its previous saved config, > it could > > > indicate it well enough using Radio Operational State > element with; > > > State-> En/Dis And Cause->Administratively Set. > > > This is more flexible, consider a case it was enabled > > > administratively, saved, but due to some reason radio is > > not up. Radio > > > Op State TLV is better equipped to say this and more. > > > > > > Regds, > > > Sujay G > > > My Location; > > > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.72485 > > > 2,7.525085&t=h > > > &hl=en > > > > > > > > > This e-mail and attachments contain confidential information from > > > HUAWEI, which is intended only for the person or entity > > whose address > > > is listed above. Any use of the information contained > herein in any > > > way (including, but not limited to, total or partial disclosure, > > > reproduction, or > > > dissemination) by persons other than the intended > > > recipient's) is prohibited. If you receive this e-mail in error, > > > please notify the sender by phone or email immediately and > > delete it! > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > > Sent: Thursday, August 17, 2006 10:46 PM > > > To: sujay; Capwap@frascone.com > > > Subject: RE: [Capwap] Issue 182: Change State Event should > > instead be > > > RadioAdmin State. > > > > > > In re-reading the text, I would propose: > > > > > > The Radio Administrative State message element is used to > > > communicate > > > the state of the WTP, or of a particular radio. The > > configuration > > > of the > > > Radio Administrative State is sent by the AC to change > > the state of > > > the > > > WTP, which saves the value to ensure its effect remains > > across WTP > > > resets. The WTP communicates this message element during the > > > configuration > > > phase to ensure that AC has the WTP radio's current > > administrative > > > state > > > settings. The value contains the following fields. > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > -----Original Message----- > > > > From: Pat Calhoun (pacalhou) > > > > Sent: Thursday, August 17, 2006 10:12 AM > > > > To: sujay; Capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 182: Change State Event should > > > instead be > > > > RadioAdmin State. > > > > > > > > Sujay, > > > > > > > > I'm ok with all of your change requests, with the > > exception of the > > > > following. > > > > > > > > > 4.4.28. Radio Administrative State > > > > > > > > > > The Radio Administrative State message element is used to > > > > > communicate > > > > > the state the WTP, or of a particular radio. It is > > > > sent from > > > > > the AC to the > > > > > WTP The configuration of > > > > > the Radio Administrative State is saved on the WTP, and > > > > its effect > > > > > remains across WTP resets. The value contains the > following > > > > > fields. > > > > > > > > Actually, this comment is invalid. The WTP indicates its > > > current radio > > > > administrative state during the config phase to the AC. I > > will add > > > > text to make this clearer. > > > > > > > > Pat Calhoun > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: sujay [mailto:sujayg@huawei.com] > > > > > Sent: Wednesday, August 16, 2006 11:29 PM > > > > > To: Pat Calhoun (pacalhou); Capwap@frascone.com > > > > > Subject: RE: [Capwap] Issue 182: Change State Event should > > > > instead be > > > > > Radio Admin State. > > > > > > > > > > Hi Pat, > > > > > You did address some of my concerns. > > > > > I have some comments inline. > > > > > > > > > > The other changes suits me. > > > > > Regds, > > > > > Sujay G > > > > > My Location; > > > > > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.72485 > > > > 2,7.525085&t=h > > > > > &hl=en > > > > > > > > > > > > > > > This e-mail and attachments contain confidential > > information from > > > > > HUAWEI, which is intended only for the person or entity > > > > whose address > > > > > is listed above. Any use of the information contained > > > herein in any > > > > > way (including, but not limited to, total or partial > > disclosure, > > > > > reproduction, or > > > > > dissemination) by persons other than the intended > > > > > > > > recipient's) is prohibited. If you receive this e-mail > > in error, > > > > > please notify the sender by phone or email immediately and > > > > delete it! > > > > > -----Original Message----- > > > > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > > > > Sent: Thursday, August 17, 2006 6:15 AM > > > > > To: Capwap@frascone.com > > > > > Subject: [Capwap] Issue 182: Change State Event should > > instead be > > > > > Radio Admin State. > > > > > > > > > > This issue really contains two parts: > > > > > > > > > > 33) Use of Change State Event should instead be Radio > > Admin State. > > > > > No. However, I do agree that there is some confusion > around the > > > > > difference between both. So I am proposing two things; add > > > > > clarification language to both message elements, and rename > > > > the Change > > > > > State Event message element to instead be called Radio > > > Operational > > > > > State. > > > > > > > > > > Note that the primary difference between both is that the > > > > Radio Admin > > > > > State is saved on the WTP, and therefore takes effect > > > > across reboots. > > > > > The operational state does not. > > > > > > > > > > > > > > > 4.4.11. Radio Operational State > > > > > > > > > > The Radio Operational State message element is sent by > > > > the WTP to > > > > > the > > > > > AC to communicate a change in the operational state of > > > a radio. > > > > > For > > > > > instance, if the WTP were to detect that a hardware > > > > failure existed > > > > > with a radio, which caused the radio to be taken > > > offline, the WTP > > > > > would indicate this event to the AC via the message > > > > element. The > > > > > AC > > > > > MAY also send this message element to change the > > > > operational state > > > > > of > > > > > a specific radio. Note that the operational state > > > setting is not > > > > > saved on the WTP, and therefore does not remain across > > > > WTP resets. > > > > > The value contains two fields, as shown. > > > > > > > > > > > > > > > 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 > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | Radio ID | State | Cause | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > Type: 11 for Radio Operational State > > > > > > > > > > Length: 3 > > > > > > > > > > Radio ID: The Radio Identifier, typically refers to some > > > > > interface > > > > > index on the WTP.The value 0xFF is invalid as it > > > > does not > > > > > indicate > > > > > any specific radio. > > > > > > > > > > State: An 8-bit boolean value representing the state of > > > > > the radio. > > > > > A value of one disables the radio, while a value of > > > > two enables > > > > > it. > > > > > > > > > > Cause: In the event of a radio being inoperable, the > > > > cause field > > > > > would contain the reason the radio is out of > service. The > > > > > following values are supported: > > > > > > > > > > 0 - Normal > > > > > 1 - Radio Failure > > > > > 2 - Software Failure > > > > > 3 - Administratively Set > > > > > > > > > > > > > > > 4.4.28. Radio Administrative State > > > > > > > > > > The Radio Administrative State message element is used to > > > > > communicate > > > > > the state the WTP, or of a particular radio. It is > > > > sent from > > > > > the AC to the > > > > > WTP The configuration of > > > > > the Radio Administrative State is saved on the WTP, and > > > > its effect > > > > > remains across WTP resets. The value contains the > following > > > > > fields. > > > > > > > > > > 0 1 > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | Radio ID | Admin State | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > Type: 28 for Radio Administrative State > > > > > > > > > > Length: 2 > > > > > > > > > > Radio ID: An 8-bit value representing the radio to > > > > > configure. The > > > > > Radio ID field may also include the value of 0xff, > > > > which is used > > > > > to identify the WTP itself. Therefore, if an AC > > wishes to > > > > > change > > > > > the administrative state of a WTP, it would include > > > > 0xff in the > > > > > Radio ID field. > > > > > > > > > > Admin State: An 8-bit value representing the > > > > administrative state > > > > > of the radio. The following values are supported: > > > > > 1 - Enabled > > > > > 2 - Disabled > > > > > > > > > > 8.6. Change State Event Request > > > > > > > > > > The Change State Event Request message is used by the > > > > WTP to inform > > > > > the AC of a change in the operational state. > > > > > > > > > > The Change State Event Request message is sent by the > > > WTP when it > > > > > receives a Configuration Response message that > > > includes a Change > > > > > State Event message element. It is also sent when the > > > > WTP detects > > > > > an > > > > > operational failure with a radio. The Change State > > > Event Request > > > > > message may be sent in either the Configure or Run > state (see > > > > > Section 2.3. > > > > > > > > > > > > > > > > > > > > Change above para to; > > > > > " > > > > > The Change State Event Request message MUST be sent by > > > > the WTP when > > > > > it > > > > > receives a Configuration Status Response message which > > > > includes a > > > > > Radio Administrative State message element. > > > > > It is also sent when the WTP detects an operational > > > > failure with a > > > > > radio. The Change State Event Request > > > > > message may be sent in either the Configure or Run state > > > > > (see Section > > > > > 2.3.). > > > > > " > > > > > - the "MUST" is needed as it helps the state machine > transition. > > > > > > > > > > > > > > > When an AC receives a Change State Event message it > > > will respond > > > > > with > > > > > a Change State Event Response message and make any > necessary > > > > > modifications to internal WTP data structures. > > > > > > > > > > The following message elements MUST be present in the > > > > Change State > > > > > Event Request message. > > > > > > > > > > o Radio Operational State message element, see > > Section 4.4.11 > > > > > > > > > > 8.7. Change State Event Response > > > > > > > > > > The Change State Event Response message acknowledges > > > the Change > > > > > State > > > > > Event Request message. > > > > > > > > > > A Change State Event Response message is by a WTP after > > > > receiving a > > > > > Change State Event Request message. > > > > > > > > > > For above para; > > > > > A Change State Event Response message is received by a > > > WTP after > > > > > sending > > > > > the Change State Event Request message. > > > > > > > > > > The Change State Event Response message carries no message > > > > > elements. > > > > > Its purpose is to acknowledge the receipt of the Change > > > > State Event > > > > > Request message. > > > > > > > > > > The WTP does not need to perform any special > > processing of the > > > > > Change > > > > > State Event Response message. > > > > > > > > > > > > > > > > > > > > > > > > > 43) Change State Event Report. This seems a little silly to > > > > be sent in > > > > > the "configure" state. It seems only appropriate for the > > > > "run" state. > > > > > Some might argue that even in the "run" state it > > > shouldn't be sent > > > > > after a "config update" request that changes the > > > operational state. > > > > > However, in the "run" state, it may take a while to have the > > > > > operational state change to follow the admin state. Thus, I > > > > think it > > > > > is OK in the "run" > > > > > state after config changes." > > > > > > > > > > I disagree. Once the config exchanges have > > > occurred, the WTP > > > > > needs to configure its radios, and then send an update to > > > > the AC when > > > > > this is done. > > > > > This message is used to inform the AC of the final state of > > > > the radios > > > > > on the WTP. I therefore believe that the state machine is > > > > fine as is > > > > > as it provides a nice transition between unconfigured and > > > > configured. > > > > > > > > > > I completely agree with Pat's above point...! > > > > > > > > > > Pat Calhoun > > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > _________________________________________________________________ > > > > > 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 > > > _________________________________________________________________ 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 Sep 01 10:41:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJADE-0006I3-UN for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 10:41:40 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJADA-0000Di-3b for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 10:41:40 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id C0E93398065 for ; Fri, 1 Sep 2006 07:41:30 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 0548343005A for ; Fri, 1 Sep 2006 07:35:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D85831448013 for ; Fri, 1 Sep 2006 07:35:44 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by hermes.tigertech.net (Postfix) with ESMTP id A084C144802B for ; Fri, 1 Sep 2006 07:35:31 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id a4so802284nfc for ; Fri, 01 Sep 2006 07:35:30 -0700 (PDT) Received: by 10.48.210.16 with SMTP id i16mr3031445nfg; Fri, 01 Sep 2006 07:35:30 -0700 (PDT) Received: by 10.49.42.3 with HTTP; Fri, 1 Sep 2006 07:35:30 -0700 (PDT) Message-ID: <5bfe7a820609010735j2a41d20dte688d6d3f90cfe4d@mail.gmail.com> Date: Fri, 1 Sep 2006 07:35:30 -0700 From: "Dorothy Stanley" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2026C4451@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A2026C4451@xmb-sjc-235.amer.cisco.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=1.0 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: Capwap@frascone.com Subject: Re: [Capwap] Issue 161: Ther term "Mobile" is not really accurate 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="===============0237241456==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d --===============0237241456== Content-Type: multipart/alternative; boundary="----=_Part_87525_8982530.1157121330017" ------=_Part_87525_8982530.1157121330017 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Pat, all, How about Wireless End Device (WED)? It captures the essential nature of the end device: "wireless", and it is not wireless-type specific. It is better than Station (an 802.11 term with specific meaning in .11 as Bob points out) Mobile - since the end device may be but is not required to be able to move, as noted by David Wireless End Point (WEP) - problematic in many ways..... Mobile Unit (MU) - again, the endpoint need not move. This would be my second choice though, as it is more specific than just "mobile". Dorothy On 8/31/06, Pat Calhoun (pacalhou) wrote: > > Folks, I need a term. > > I don't care if it's foobar, but need something everyone will agree to. > If station doesn't cut it, as bob insists, then I need something to work > it. > > Help, > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > Sent: Sunday, August 20, 2006 12:03 PM > > To: Bob O'Hara (boohara) > > Cc: Pat Calhoun (pacalhou); Capwap@frascone.com > > Subject: Re: [Capwap] Issue 161: Ther term "Mobile" is not > > really accurate > > > > HI, > > > > Bob can you suggest an appropriate term to use here. The term > > "mobile" has dictionary meaning of moving. However, being > > capable of moving is not the fundamental defining attribute > > of the interface that differentiates from other technologies. > > > > Regards, > > /david t. perkins > > > > > > On Wed, 16 Aug 2006, Bob O'Hara (boohara) wrote: > > > STOP! Put that editor down and step away from the draft! > > I think it > > > is a big mistake to embed a term that is tied to a single > > binding into > > > the entirety of the draft. > > > > > > -Bob > > > > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) > > > Sent: Tuesday, August 15, 2006 6:04 PM > > > To: Capwap@frascone.com > > > Subject: [Capwap] Issue 161: Ther term "Mobile" is not > > really accurate > > > > > > The term "mobile" is not really accurate when describing wireless > > > interfaces, since wireless does not imply mobile. Can we > > just use the > > > techie term "STA" instead. > > > > > > In my honest opinion, this is one of those change > > requests that > > > is really unnecessary. Traditionally, the IETF has used the term > > > mobile (e.g., mobile station in Mobile IP). However, given the > > > comment, and the fact that the > > > 802.11 WG uses the term station, or STA for short, I will > > go ahead and > > > make the change. Of course, the next binding technology may end up > > > using different terminology (including mobile). > > > > > > This will, of course, touch nearly every section of the > > specification > > > (read: diffs will be more complex). > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems > > > _________________________________________________________________ > > > 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 > ------=_Part_87525_8982530.1157121330017 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Pat, all,

How about

Wireless End Device (WED)? It captures the essential nature of the end device: "wireless", and
it is not wireless-type specific.

It is better than

Station (an 802.11 term with specific meaning in .11 as Bob points out)
Mobile - since the end device may be but is not required to be able to move, as noted by David
Wireless End Point (WEP) -  problematic in many ways.....
Mobile Unit  (MU) - again, the endpoint need not move. This would be my second choice though, as it is more specific than just "mobile".

Dorothy

On 8/31/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
Folks, I need a term.

I don't care if it's foobar, but need something everyone will agree to.
If station doesn't cut it, as bob insists, then I need something to work
it.

Help,

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems



> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: Sunday, August 20, 2006 12:03 PM
> To: Bob O'Hara (boohara)
> Cc: Pat Calhoun (pacalhou); Capwap@frascone.com
> Subject: Re: [Capwap] Issue 161: Ther term "Mobile" is not
> really accurate
>
> HI,
>
> Bob can you suggest an appropriate term to use here. The term
> "mobile" has dictionary meaning of moving. However, being
> capable of moving is not the fundamental defining attribute
> of the interface that differentiates from other technologies.
>
> Regards,
> /david t. perkins
>
>
> On Wed, 16 Aug 2006, Bob O'Hara (boohara) wrote:
> > STOP!  Put that editor down and step away from the draft!
> I think it
> > is a big mistake to embed a term that is tied to a single
> binding into
> > the entirety of the draft.
> >
> >  -Bob
> >
> > -----Original Message-----
> > From: Pat Calhoun (pacalhou)
> > Sent: Tuesday, August 15, 2006 6:04 PM
> > To: Capwap@frascone.com
> > Subject: [Capwap] Issue 161: Ther term "Mobile" is not
> really accurate
> >
> > The term "mobile" is not really accurate when describing wireless
> > interfaces, since wireless does not imply mobile. Can we
> just use the
> > techie term "STA" instead.
> >
> > <PRC> In my honest opinion, this is one of those change
> requests that
> > is really unnecessary. Traditionally, the IETF has used the term
> > mobile (e.g., mobile station in Mobile IP). However, given the
> > comment, and the fact that the
> > 802.11 WG uses the term station, or STA for short, I will
> go ahead and
> > make the change. Of course, the next binding technology may end up
> > using different terminology (including mobile).
> >
> > This will, of course, touch nearly every section of the
> specification
> > (read: diffs will be more complex).
> >
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit Cisco Systems
> > _________________________________________________________________
> > 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

------=_Part_87525_8982530.1157121330017-- --===============0237241456== 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 --===============0237241456==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 01 11:25:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJAtY-00088B-Ny for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 11:25:24 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJAtW-0003m0-U8 for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 11:25:24 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2CDF139807D for ; Fri, 1 Sep 2006 08:25:17 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id BAFBD43005A for ; Fri, 1 Sep 2006 08:20:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6E3AA39800E for ; Fri, 1 Sep 2006 08:20:47 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5967D39803E for ; Fri, 1 Sep 2006 08:20:41 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 01 Sep 2006 08:20:41 -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 k81FKe8P008969; Fri, 1 Sep 2006 08:20:40 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k81FKe1E014633; Fri, 1 Sep 2006 08:20:40 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Sep 2006 08:20:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Sep 2006 08:20:39 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2026C45BD@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 161: Ther term "Mobile" is not really accurate Thread-Index: AcbN0+FgygRpDrWXTBWBuMMAk4puJwABkP+g From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" X-OriginalArrivalTime: 01 Sep 2006 15:20:40.0671 (UTC) FILETIME=[2F4BF6F0:01C6CDDA] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 43 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.429 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: Capwap@frascone.com Subject: Re: [Capwap] Issue 161: Ther term "Mobile" is not really accurate 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="===============1115325155==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 This is a multi-part message in MIME format. --===============1115325155== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6CDDA.2F11FAFC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6CDDA.2F11FAFC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WED works for me. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Friday, September 01, 2006 7:36 AM To: Pat Calhoun (pacalhou) Cc: David T. Perkins; Bob O'Hara (boohara); Capwap@frascone.com Subject: Re: [Capwap] Issue 161: Ther term "Mobile" is not really accurate =09 =09 Pat, all, =09 How about =09 Wireless End Device (WED)? It captures the essential nature of the end device: "wireless", and it is not wireless-type specific. =09 It is better than =09 Station (an 802.11 term with specific meaning in .11 as Bob points out) Mobile - since the end device may be but is not required to be able to move, as noted by David Wireless End Point (WEP) - problematic in many ways..... Mobile Unit (MU) - again, the endpoint need not move. This would be my second choice though, as it is more specific than just "mobile". =09 Dorothy =09 =09 On 8/31/06, Pat Calhoun (pacalhou) wrote:=20 Folks, I need a term. =09 I don't care if it's foobar, but need something everyone will agree to. If station doesn't cut it, as bob insists, then I need something to work it. =09 Help, =09 Pat Calhoun CTO, Wireless Networking Business Unit=20 Cisco Systems =09 =09 =09 > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Sunday, August 20, 2006 12:03 PM > To: Bob O'Hara (boohara) > Cc: Pat Calhoun (pacalhou); Capwap@frascone.com > Subject: Re: [Capwap] Issue 161: Ther term "Mobile" is not > really accurate=20 > > HI, > > Bob can you suggest an appropriate term to use here. The term > "mobile" has dictionary meaning of moving. However, being > capable of moving is not the fundamental defining attribute=20 > of the interface that differentiates from other technologies. > > Regards, > /david t. perkins > > > On Wed, 16 Aug 2006, Bob O'Hara (boohara) wrote: > > STOP! Put that editor down and step away from the draft!=20 > I think it > > is a big mistake to embed a term that is tied to a single > binding into > > the entirety of the draft. > > > > -Bob > > > > -----Original Message-----=20 > > From: Pat Calhoun (pacalhou) > > Sent: Tuesday, August 15, 2006 6:04 PM > > To: Capwap@frascone.com > > Subject: [Capwap] Issue 161: Ther term "Mobile" is not=20 > really accurate > > > > The term "mobile" is not really accurate when describing wireless > > interfaces, since wireless does not imply mobile. Can we > just use the > > techie term "STA" instead. > > > > In my honest opinion, this is one of those change > requests that > > is really unnecessary. Traditionally, the IETF has used the term=20 > > mobile (e.g., mobile station in Mobile IP). However, given the > > comment, and the fact that the > > 802.11 WG uses the term station, or STA for short, I will > go ahead and > > make the change. Of course, the next binding technology may end up=20 > > using different terminology (including mobile). > > > > This will, of course, touch nearly every section of the > specification > > (read: diffs will be more complex). > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit:=20 > > 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 > > > =09 _________________________________________________________________=20 To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap =09 ------_=_NextPart_001_01C6CDDA.2F11FAFC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
WED=20 works for me.
 

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

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Friday, September 01, = 2006=20 7:36 AM
To: Pat Calhoun (pacalhou)
Cc: David T. = Perkins;=20 Bob O'Hara (boohara); Capwap@frascone.com
Subject: Re: = [Capwap]=20 Issue 161: Ther term "Mobile" is not really = accurate

Pat, all,

How about

Wireless End Device = (WED)? It=20 captures the essential nature of the end device: "wireless", and
it = is not=20 wireless-type specific.

It is better than

Station (an = 802.11=20 term with specific meaning in .11 as Bob points out)
Mobile - since = the end=20 device may be but is not required to be able to move, as noted by=20 David
Wireless End Point (WEP) -  problematic in many=20 ways.....
Mobile Unit  (MU) - again, the endpoint need not = move. This=20 would be my second choice though, as it is more specific than just=20 "mobile".

Dorothy

On 8/31/06, Pat Calhoun=20 (pacalhou) <pcalhoun@cisco.com> = wrote:
Folks,=20 I need a term.

I don't care if it's foobar, but need = something=20 everyone will agree to.
If station doesn't cut it, as bob = insists, then I=20 need something to work
it.

Help,

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



>=20 -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
>= ;=20 Sent: Sunday, August 20, 2006 12:03 PM
> To: Bob O'Hara=20 (boohara)
> Cc: Pat Calhoun (pacalhou); Capwap@frascone.com
> = Subject:=20 Re: [Capwap] Issue 161: Ther term "Mobile" is not
> really = accurate=20
>
> HI,
>
> Bob can you suggest an = appropriate term=20 to use here. The term
> "mobile" has dictionary meaning of = moving.=20 However, being
> capable of moving is not the fundamental = defining=20 attribute
> of the interface that differentiates from other=20 technologies.
>
> Regards,
> /david t.=20 perkins
>
>
> On Wed, 16 Aug 2006, Bob O'Hara = (boohara)=20 wrote:
> > STOP!  Put that editor down and step = away from=20 the draft!
> I think it
> > is a big mistake to = embed a term=20 that is tied to a single
> binding into
> > the = entirety of=20 the draft.
> >
> >  -Bob
> = >
>=20 > -----Original Message-----
> > From: Pat Calhoun=20 (pacalhou)
> > Sent: Tuesday, August 15, 2006 6:04 = PM
> >=20 To: Capwap@frascone.com
>=20 > Subject: [Capwap] Issue 161: Ther term "Mobile" is not
> = really=20 accurate
> >
> > The term "mobile" is not really = accurate=20 when describing wireless
> > interfaces, since wireless = does not=20 imply mobile. Can we
> just use the
> > techie term = "STA"=20 instead.
> >
> > <PRC> In my honest opinion, = this is=20 one of those change
> requests that
> > is really=20 unnecessary. Traditionally, the IETF has used the term
> > = mobile=20 (e.g., mobile station in Mobile IP). However, given the
> > = comment, and the fact that the
> > 802.11 WG uses the term = station,=20 or STA for short, I will
> go ahead and
> > make the = change.=20 Of course, the next binding technology may end up
> > = using=20 different terminology (including mobile).
> >
> > = This=20 will, of course, touch nearly every section of the
>=20 specification
> > (read: diffs will be more = complex).
> >=20
> > Pat Calhoun
> > CTO, Wireless Networking = Business=20 Unit Cisco Systems
> >=20 = _________________________________________________________________
>= =20 > To unsubscribe or modify your subscription options, please = visit:=20
> > http://lists.f= rascone.com/mailman/listinfo/capwap
>=20 >
> > Archives: http://lists.frascone= .com/pipermail/capwap=20
> >=20 = _________________________________________________________________
>= =20 > To unsubscribe or modify your subscription options, please=20 visit:
> > http://lists.f= rascone.com/mailman/listinfo/capwap
>=20 >
> > Archives: http://lists.frascone= .com/pipermail/capwap
>=20 = >
>
_________________________________________________________= ________=20
To unsubscribe or modify your subscription options, please = visit:
http://lists.f= rascone.com/mailman/listinfo/capwap

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

<= /HTML> ------_=_NextPart_001_01C6CDDA.2F11FAFC-- --===============1115325155== 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 --===============1115325155==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 01 12:02:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJBTp-00072J-Q5 for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 12:02:53 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJBTo-0006tn-B9 for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 12:02:53 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id ADCAC1448082 for ; Fri, 1 Sep 2006 09:02:48 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 0269443005A for ; Fri, 1 Sep 2006 09:02:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E5EE3398052 for ; Fri, 1 Sep 2006 09:02:01 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id A883B39805F for ; Fri, 1 Sep 2006 09:01:56 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 01 Sep 2006 09:01:56 -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.20060308/8.12.11) with ESMTP id k81G1uRS023205 for ; Fri, 1 Sep 2006 09:01:56 -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 k81G1uYp004849 for ; Fri, 1 Sep 2006 09:01:56 -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, 1 Sep 2006 09:01:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Sep 2006 09:01:53 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2026C45F4@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Next Draft editorship process Thread-Index: AcbN3/F08dEXJDlvTEa0G3cMrz88VA== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 01 Sep 2006 16:01:56.0391 (UTC) FILETIME=[F2F0DB70:01C6CDDF] 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: Subject: [Capwap] Next Draft editorship process 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 All, During our editor call this morning, the editors agreed to the following process. We will continue to address new issues until 9/29. In order to meet our agreed upon milestones, we believe it is important to balance issue discussion with timely closure. Therefore, when we propose an resolution for an issue, we will provide the list with two weeks to respond, after which we will close the issue based on rough consensus. No responses to an issue assumes consensus - regardless of the proposed action. Of course, any contentious issues, for which debates are still ongoing, have no consensus, and will not fall under this rule. As part of this editor cycle, we plan to split up the draft into two; base and 802.11 binding. The former will be labelled -03 and the latter -00. Given we have a -00 draft, and we wish to post both drafts at the same time, we will use the -00 deadlines, which is 10/16. Our plan is to submit both drafts on 10/13. Thanks, Pat, Mike and Dorothy _________________________________________________________________ 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 Sep 01 12:41:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJC4i-0003Ey-U1 for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 12:41:00 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJC4h-0001iq-2S for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 12:41:00 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id C0082144803E for ; Fri, 1 Sep 2006 09:40:52 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 71B7243005A for ; Fri, 1 Sep 2006 09:36:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D78C2398069 for ; Fri, 1 Sep 2006 09:36:05 -0700 (PDT) Received: from mgw-ext11.nokia.com (mgw-ext11.nokia.com [131.228.20.170]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8CE15398052 for ; Fri, 1 Sep 2006 09:35:57 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k81GZmCP031787; Fri, 1 Sep 2006 19:35:53 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 19:35:53 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 11:35:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Sep 2006 09:35:47 -0700 Message-ID: <8A76136424391244A5CF016533708537020AD68F@mvebe101.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2026C45BD@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 161: Ther term "Mobile" is not really accurate Thread-Index: AcbN0+FgygRpDrWXTBWBuMMAk4puJwABkP+gAAI3v2A= From: To: , X-OriginalArrivalTime: 01 Sep 2006 16:35:36.0795 (UTC) FILETIME=[A7320AB0:01C6CDE4] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.265 tagged_above=-999 required=7 tests=HTML_40_50, HTML_MESSAGE, NO_REAL_NAME X-Spam-Level: Cc: Capwap@frascone.com Subject: Re: [Capwap] Issue 161: Ther term "Mobile" is not really accurate 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="===============1924514769==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.3 (/) X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306 This is a multi-part message in MIME format. --===============1924514769== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6CDE4.A65D6F2D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6CDE4.A65D6F2D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 I disagree with the characterization against the term "mobile." The term mobile node (MN) is often used in the context of wireless standards and helps reflect the system architecture. We also see mobile station (MS), mobile equipment (ME) =20 If we look to other large deployments of wireless devices that are of concern to the .11 and IETF communities, that would be the cellular, in which case terms like user equipment (UE) are available to base something around. It needn't be a TLA either. =20 Best Regards, Michael ________________________________ From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Friday, September 01, 2006 8:21 AM To: Dorothy Stanley Cc: Capwap@frascone.com Subject: Re: [Capwap] Issue 161: Ther term "Mobile" is not really accurate WED works for me. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Friday, September 01, 2006 7:36 AM To: Pat Calhoun (pacalhou) Cc: David T. Perkins; Bob O'Hara (boohara); Capwap@frascone.com Subject: Re: [Capwap] Issue 161: Ther term "Mobile" is not really accurate =09 =09 Pat, all, =09 How about =09 Wireless End Device (WED)? It captures the essential nature of the end device: "wireless", and it is not wireless-type specific. =09 It is better than =09 Station (an 802.11 term with specific meaning in .11 as Bob points out) Mobile - since the end device may be but is not required to be able to move, as noted by David Wireless End Point (WEP) - problematic in many ways..... Mobile Unit (MU) - again, the endpoint need not move. This would be my second choice though, as it is more specific than just "mobile". =09 Dorothy =09 =09 On 8/31/06, Pat Calhoun (pacalhou) wrote:=20 Folks, I need a term. =09 I don't care if it's foobar, but need something everyone will agree to. If station doesn't cut it, as bob insists, then I need something to work it. =09 Help, =09 Pat Calhoun CTO, Wireless Networking Business Unit=20 Cisco Systems =09 =09 =09 > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Sunday, August 20, 2006 12:03 PM > To: Bob O'Hara (boohara) > Cc: Pat Calhoun (pacalhou); Capwap@frascone.com > Subject: Re: [Capwap] Issue 161: Ther term "Mobile" is not > really accurate=20 > > HI, > > Bob can you suggest an appropriate term to use here. The term > "mobile" has dictionary meaning of moving. However, being > capable of moving is not the fundamental defining attribute=20 > of the interface that differentiates from other technologies. > > Regards, > /david t. perkins > > > On Wed, 16 Aug 2006, Bob O'Hara (boohara) wrote: > > STOP! Put that editor down and step away from the draft!=20 > I think it > > is a big mistake to embed a term that is tied to a single > binding into > > the entirety of the draft. > > > > -Bob > > > > -----Original Message-----=20 > > From: Pat Calhoun (pacalhou) > > Sent: Tuesday, August 15, 2006 6:04 PM > > To: Capwap@frascone.com > > Subject: [Capwap] Issue 161: Ther term "Mobile" is not=20 > really accurate > > > > The term "mobile" is not really accurate when describing wireless > > interfaces, since wireless does not imply mobile. Can we > just use the > > techie term "STA" instead. > > > > In my honest opinion, this is one of those change > requests that > > is really unnecessary. Traditionally, the IETF has used the term=20 > > mobile (e.g., mobile station in Mobile IP). However, given the > > comment, and the fact that the > > 802.11 WG uses the term station, or STA for short, I will > go ahead and > > make the change. Of course, the next binding technology may end up=20 > > using different terminology (including mobile). > > > > This will, of course, touch nearly every section of the > specification > > (read: diffs will be more complex). > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit:=20 > > 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 > > > =09 _________________________________________________________________=20 To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frasconecom/pipermail/capwap =20 =09 ------_=_NextPart_001_01C6CDE4.A65D6F2D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
I disagree with the characterization ag= ainst the term "mobile."  The=20 term mobile node (MN) is often used in the context of wireless = standards=20 and helps reflect the system architecture. We also see mobile station = (MS),=20 mobile equipment (ME)
 
If we look to other large deployments of = wireless=20 devices that are of concern to the .11 and IETF communities, that would = be the=20 cellular, in which case terms like user equipment (UE) are available to = base=20 something around. It needn't be a TLA = either.
 
Best = Regards,
Michael
From: ext Pat Calhoun = (pacalhou)=20 [mailto:pcalhoun@cisco.com]
Sent: Friday, September 01, 2006 = 8:21=20 AM
To: Dorothy Stanley
Cc:=20 Capwap@frascone.com
Subject: Re: [Capwap] Issue 161: Ther term = "Mobile" is not really accurate

WED=20 works for me.
 

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

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Friday, September 01, = 2006=20 7:36 AM
To: Pat Calhoun (pacalhou)
Cc: David T. = Perkins;=20 Bob O'Hara (boohara); Capwap@frascone.com
Subject: Re: = [Capwap]=20 Issue 161: Ther term "Mobile" is not really = accurate

Pat, all,

How about

Wireless End Device = (WED)? It=20 captures the essential nature of the end device: "wireless", and
it = is not=20 wireless-type specific.

It is better than

Station (an = 802.11=20 term with specific meaning in .11 as Bob points out)
Mobile - since = the end=20 device may be but is not required to be able to move, as noted by=20 David
Wireless End Point (WEP) -  problematic in many=20 ways.....
Mobile Unit  (MU) - again, the endpoint need not = move. This=20 would be my second choice though, as it is more specific than just=20 "mobile".

Dorothy

On 8/31/06, Pat Calhoun=20 (pacalhou) <pcalhoun@cisco.com> = wrote:=20
Folks,=20 I need a term.

I don't care if it's foobar, but need = something=20 everyone will agree to.
If station doesn't cut it, as bob = insists, then I=20 need something to work
it.

Help,

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



>=20 -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
>= ;=20 Sent: Sunday, August 20, 2006 12:03 PM
> To: Bob O'Hara=20 (boohara)
> Cc: Pat Calhoun (pacalhou); Capwap@frascone.com
> = Subject:=20 Re: [Capwap] Issue 161: Ther term "Mobile" is not
> really = accurate=20
>
> HI,
>
> Bob can you suggest an = appropriate term=20 to use here. The term
> "mobile" has dictionary meaning of = moving.=20 However, being
> capable of moving is not the fundamental = defining=20 attribute
> of the interface that differentiates from other=20 technologies.
>
> Regards,
> /david t.=20 perkins
>
>
> On Wed, 16 Aug 2006, Bob O'Hara = (boohara)=20 wrote:
> > STOP!  Put that editor down and step = away from=20 the draft!
> I think it
> > is a big mistake to = embed a term=20 that is tied to a single
> binding into
> > the = entirety of=20 the draft.
> >
> >  -Bob
> = >
>=20 > -----Original Message-----
> > From: Pat Calhoun=20 (pacalhou)
> > Sent: Tuesday, August 15, 2006 6:04 = PM
> >=20 To: Capwap@frascone.com
>=20 > Subject: [Capwap] Issue 161: Ther term "Mobile" is not
> = really=20 accurate
> >
> > The term "mobile" is not really = accurate=20 when describing wireless
> > interfaces, since wireless = does not=20 imply mobile. Can we
> just use the
> > techie term = "STA"=20 instead.
> >
> > <PRC> In my honest opinion, = this is=20 one of those change
> requests that
> > is really=20 unnecessary. Traditionally, the IETF has used the term
> > = mobile=20 (e.g., mobile station in Mobile IP). However, given the
> > = comment, and the fact that the
> > 802.11 WG uses the term = station,=20 or STA for short, I will
> go ahead and
> > make the = change.=20 Of course, the next binding technology may end up
> > = using=20 different terminology (including mobile).
> >
> > = This=20 will, of course, touch nearly every section of the
>=20 specification
> > (read: diffs will be more = complex).
> >=20
> > Pat Calhoun
> > CTO, Wireless Networking = Business=20 Unit Cisco Systems
> >=20 = _________________________________________________________________
>= =20 > To unsubscribe or modify your subscription options, please = visit:=20
> > http://lists.f= rascone.com/mailman/listinfo/capwap
>=20 >
> > Archives: http://lists.frascone= .com/pipermail/capwap=20
> >=20 = _________________________________________________________________
>= =20 > To unsubscribe or modify your subscription options, please=20 visit:
> > http://lists.f= rascone.com/mailman/listinfo/capwap
>=20 >
> > Archives: http://lists.frascone= .com/pipermail/capwap
>=20 = >
>
_________________________________________________________= ________=20
To unsubscribe or modify your subscription options, please = visit:
http://lists.f= rascone.com/mailman/listinfo/capwap

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

------_=_NextPart_001_01C6CDE4.A65D6F2D-- --===============1924514769== 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 --===============1924514769==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 01 13:18:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJCf1-0001y9-Nu for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 13:18:31 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJCew-0004WA-6M for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 13:18:31 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 6D672144805B for ; Fri, 1 Sep 2006 10:18:22 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7965843005A for ; Fri, 1 Sep 2006 10:16:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 62B5F1448059 for ; Fri, 1 Sep 2006 10:16:26 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 88225144802F for ; Fri, 1 Sep 2006 10:16:24 -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 k81HGNPg031512; Fri, 1 Sep 2006 10:16:23 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k81HGNH7031509; Fri, 1 Sep 2006 10:16:23 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 1 Sep 2006 10:16:23 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Dorothy Stanley In-Reply-To: <5bfe7a820609010735j2a41d20dte688d6d3f90cfe4d@mail.gmail.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] Issue 161: Ther term "Mobile" is not really accurate 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: 2beba50d0fcdeee5f091c59f204d4365 HI, All good points. One issue is that we are really talking about interfaces. A good many number of devices that have a network interface may have a single network interface, and that interface can be be used to characterize the device as a Wireless end device. However, other devices may have other network interfaces that are not wireless. Regards, /david t. perkins On Fri, 1 Sep 2006, Dorothy Stanley wrote: > Pat, all, > > How about > > Wireless End Device (WED)? It captures the essential nature of the end > device: "wireless", and > it is not wireless-type specific. > > It is better than > > Station (an 802.11 term with specific meaning in .11 as Bob points out) > Mobile - since the end device may be but is not required to be able to move, > as noted by David > Wireless End Point (WEP) - problematic in many ways..... > Mobile Unit (MU) - again, the endpoint need not move. This would be my > second choice though, as it is more specific than just "mobile". > > Dorothy > > On 8/31/06, Pat Calhoun (pacalhou) wrote: > > > > Folks, I need a term. > > > > I don't care if it's foobar, but need something everyone will agree to. > > If station doesn't cut it, as bob insists, then I need something to work > > it. > > > > Help, > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > -----Original Message----- > > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > > Sent: Sunday, August 20, 2006 12:03 PM > > > To: Bob O'Hara (boohara) > > > Cc: Pat Calhoun (pacalhou); Capwap@frascone.com > > > Subject: Re: [Capwap] Issue 161: Ther term "Mobile" is not > > > really accurate > > > > > > HI, > > > > > > Bob can you suggest an appropriate term to use here. The term > > > "mobile" has dictionary meaning of moving. However, being > > > capable of moving is not the fundamental defining attribute > > > of the interface that differentiates from other technologies. > > > > > > Regards, > > > /david t. perkins > > > > > > > > > On Wed, 16 Aug 2006, Bob O'Hara (boohara) wrote: > > > > STOP! Put that editor down and step away from the draft! > > > I think it > > > > is a big mistake to embed a term that is tied to a single > > > binding into > > > > the entirety of the draft. > > > > > > > > -Bob > > > > > > > > -----Original Message----- > > > > From: Pat Calhoun (pacalhou) > > > > Sent: Tuesday, August 15, 2006 6:04 PM > > > > To: Capwap@frascone.com > > > > Subject: [Capwap] Issue 161: Ther term "Mobile" is not > > > really accurate > > > > > > > > The term "mobile" is not really accurate when describing wireless > > > > interfaces, since wireless does not imply mobile. Can we > > > just use the > > > > techie term "STA" instead. > > > > > > > > In my honest opinion, this is one of those change > > > requests that > > > > is really unnecessary. Traditionally, the IETF has used the term > > > > mobile (e.g., mobile station in Mobile IP). However, given the > > > > comment, and the fact that the > > > > 802.11 WG uses the term station, or STA for short, I will > > > go ahead and > > > > make the change. Of course, the next binding technology may end up > > > > using different terminology (including mobile). > > > > > > > > This will, of course, touch nearly every section of the > > > specification > > > > (read: diffs will be more complex). > > > > > > > > Pat Calhoun > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > _________________________________________________________________ > > > > 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 > > > _________________________________________________________________ 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 Sep 01 13:49:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJD8Z-0001cn-J3 for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 13:49:03 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJD8Y-0006fD-4A for capwap-archive@lists.ietf.org; Fri, 01 Sep 2006 13:49:03 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 1128C144806C for ; Fri, 1 Sep 2006 10:48:50 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2860543005A for ; Fri, 1 Sep 2006 10:48:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0E713144800B for ; Fri, 1 Sep 2006 10:48:14 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9B67F1448064 for ; Fri, 1 Sep 2006 10:48:11 -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 k81HmBOf007442; Fri, 1 Sep 2006 10:48:11 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k81HmAUO007431; Fri, 1 Sep 2006 10:48:11 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 1 Sep 2006 10:48:10 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2026C45F4@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] Next Draft editorship process 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: 7baded97d9887f7a0c7e8a33c2e3ea1b HI, That plan would be all fine and good if the document and issues were at the stage that only polishing was needed. I don't support the proposed process and suggest that an alternative one be used that will result in resolution of the fundamental issues such as the packet format. On Fri, 1 Sep 2006, Pat Calhoun (pacalhou) wrote: > All, > > During our editor call this morning, the editors agreed to the following > process. We will continue to address new issues until 9/29. In order to > meet our agreed upon milestones, we believe it is important to balance > issue discussion with timely closure. Therefore, when we propose an > resolution for an issue, we will provide the list with two weeks to > respond, after which we will close the issue based on rough consensus. > No responses to an issue assumes consensus - regardless of the proposed > action. Of course, any contentious issues, for which debates are still > ongoing, have no consensus, and will not fall under this rule. > > As part of this editor cycle, we plan to split up the draft into two; > base and 802.11 binding. The former will be labelled -03 and the latter > -00. Given we have a -00 draft, and we wish to post both drafts at the > same time, we will use the -00 deadlines, which is 10/16. Our plan is to > submit both drafts on 10/13. > > Thanks, > > Pat, Mike and Dorothy 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 shugeluis@ladyfire.com Fri Sep 01 23:44:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJMRG-0001lI-D3 for capwap-archive@ietf.org; Fri, 01 Sep 2006 23:44:58 -0400 Received: from [202.22.230.180] (helo=ladyfire.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GJMR8-00082z-FN for capwap-archive@ietf.org; Fri, 01 Sep 2006 23:44:58 -0400 Received: by 192.168.82.141 with SMTP id IPVvFsEHj; for ; Fri, 1 Sep 2006 20:43:42 -0700 Message-ID: <000001c6ce41$fc0cef20$8d52a8c0@jrbrzjy> Reply-To: "Sonny Tarvin" From: "Sonny Tarvin" To: capwap-archive@ietf.org Subject: Re: xaR Xpi Date: Fri, 1 Sep 2006 20:43:42 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6CE07.4FAE1720" 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.8 (++++) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6CE07.4FAE1720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 All yo g ur PH l ARRMAC x Y dir b ectl q y from the m w anuf d actur e er, Your ch i anc g e to ec o onomi x ze wi x th us http://YourTreeServices.info k=20 i=20 q=20 if we came here disguised as a squad of combat marines. So far every in the wheelchair and Steengo lifted a whitewrapped hand. There we were on the screen playing on a familiar set, wearing our ------=_NextPart_000_0001_01C6CE07.4FAE1720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
All yo g ur PH l ARRMAC x Y dir b ectl q y from the m w anuf d actur e er,
Your ch i anc g e to ec o onomi x ze wi x th us http://YourTreeServices.info

  k

  i

  q

if we came here disguised as a squad of combat marines. So far = every
in the wheelchair and Steengo lifted a whitewrapped hand.
There we were on the screen playing on a familiar set, wearing = our

------=_NextPart_000_0001_01C6CE07.4FAE1720-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Sep 02 02:28:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJOze-0006p1-Uc for capwap-archive@lists.ietf.org; Sat, 02 Sep 2006 02:28:38 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJOzb-0007ql-Gq for capwap-archive@lists.ietf.org; Sat, 02 Sep 2006 02:28:38 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6E70F398095 for ; Fri, 1 Sep 2006 23:28:28 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4F40943001B for ; Fri, 1 Sep 2006 23:27:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 33164398020 for ; Fri, 1 Sep 2006 23:27:56 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [12.129.211.51]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3742739805E for ; Fri, 1 Sep 2006 23:27:53 -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 <0J4Y001UBCH4SB@usaga01-in.huawei.com> for Capwap@frascone.com; Fri, 01 Sep 2006 23:24:40 -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 <0J4Y00LBLCH2A8@usaga01-in.huawei.com> for Capwap@frascone.com; Fri, 01 Sep 2006 23:24:39 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.18.23.62]) by szxmc01-in.huawei.com (mshttpd); Sat, 02 Sep 2006 11:27:52 +0500 Date: Sat, 02 Sep 2006 11:27:52 +0500 From: zhaoyujin 31390 To: Capwap@frascone.com Message-id: <1a062801a01bcf.1a01bcf1a06280@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-language: zh-CN Content-disposition: inline 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: Subject: [Capwap] One Issue: About WTP Static IP Address Information Must in "Configuration Status response message" and not "Configuration Status message" 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f The issue is: Section 4.4.45 defines WTP static IP address information which is used by AC to set AP ip address. But in Section 8.2. Configuration Status describes "WTP Static IP Address Information" MUST be included in the Configuration Status message. I can't understand. I think there may be some error. The Configuration Status message is from AP to AC, so that I think "WTP Static IP Address Information" MUST be included in the "Configuration Status response message" and not "Configuration Status message". Best regards Michael >The following is the description in draft-02: > >4.4.45. WTP Static IP Address Information > > The WTP Static IP Address Information message element is used by an > AC to configure or clear a previously configured static IP address on > a WTP. > >8.2. Configuration Status > The following message elements MUST be included in the Configuration > Status message. > o WTP Static IP Address Information, see Section 4.4.45 This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From hedincrocifi@ipm.com Sun Sep 03 15:11:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJxND-0006hq-4n for capwap-archive@ietf.org; Sun, 03 Sep 2006 15:11:15 -0400 Received: from [84.76.54.34] (helo=ipm.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GJxNB-0002KO-H0 for capwap-archive@ietf.org; Sun, 03 Sep 2006 15:11:15 -0400 Message-ID: <000001c6cf8c$a545bd60$9fe2a8c0@bdvrvdz> Reply-To: "Babak Silver" From: "Babak Silver" To: capwap-archive@ietf.org Subject: Re: PHARdyMACY Date: Sun, 3 Sep 2006 12:10:40 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6CF51.F8E95660" 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: 0.6 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6CF51.F8E95660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 All yo r ur P d HARM w AC j Y dir v ect c ly from the man c uf c acture k r, Your c f han d ce to ec g ono u mize wit m h us http://lakitunmerdunsa.com ------=_NextPart_000_0001_01C6CF51.F8E95660 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
All yo r ur P d HARM w AC j Y dir v ect c ly from the man c uf c acture k r,
Your c f han d ce to ec g ono u mize wit m h us http://lakitunmerdunsa.com
<= /BODY> ------=_NextPart_000_0001_01C6CF51.F8E95660-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Sep 03 21:45:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GK3WZ-0003f8-P1 for capwap-archive@lists.ietf.org; Sun, 03 Sep 2006 21:45:19 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GK3WX-0000F2-Ef for capwap-archive@lists.ietf.org; Sun, 03 Sep 2006 21:45:19 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2B83739803E for ; Sun, 3 Sep 2006 18:45:14 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4E85F430018 for ; Sun, 3 Sep 2006 18:42:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 259C0430EBB for ; Sun, 3 Sep 2006 18:42:17 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id D900B430EBF for ; Sun, 3 Sep 2006 18:42:12 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id k841g6j6002536; Mon, 4 Sep 2006 10:42:06 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k841g6e05731; Mon, 4 Sep 2006 10:42:06 +0900 (JST) Received: from localhost ([127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with SMTP id k841g5X28044; Mon, 4 Sep 2006 10:42: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, 4 Sep 2006 09:45:45 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD011F76A7@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution for Issue #201: CleanSeparationBetween Base and Binding/was Re: CAPWAP and RFID Thread-Index: AcbKwJxNj7aVKnOOSKm5gX5r0qjCiACk812QAJurqfA= From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , "Dorothy Stanley" , "Mani, Mahalingam (Mani)" 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.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_60_70, HTML_MESSAGE X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Proposed Resolution for Issue #201: CleanSeparationBetween Base and Binding/was Re: 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="===============1667929754==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 1338f4ee677fe822e4246c6560199c52 This is a multi-part message in MIME format. --===============1667929754== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6CFC3.37B675E1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6CFC3.37B675E1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have concerns with this proposal. In principle, I support the proposal. However, in practice, I think we should wait until all the technical issues are sorted out before making the split. I am concerned that separating the documents at this relatively early stage may complicate technical resolution. Furthermore, splitting the document seems to be an editorial issue, which can be best done after content has been finalized.=20 =20 So I support the proposal but would like it to be pursued after content has been finalized. =20 Saravanan =20 =20 =20 =20 =20 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Friday, September 01, 2006 7:25 AM To: Dorothy Stanley; Mani, Mahalingam (Mani) Cc: capwap@frascone.com Subject: Re: [Capwap] Proposed Resolution for Issue #201: CleanSeparationBetween Base and Binding/was Re: CAPWAP and RFID =20 Works for me. Note that some of the references may be harder to make when they occur across documents. Today they are simple to make, because our xml2rfc allows for internal references, allowing us to reference a specific section. In the new document, we will only be able to reference the accompanying specification. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Monday, August 28, 2006 9:37 AM To: Mani, Mahalingam (Mani) Cc: capwap@frascone.com Subject: [Capwap] Proposed Resolution for Issue #201: Clean SeparationBetween Base and Binding/was Re: CAPWAP and RFID All, =20 The proposed resolution for Issue #201, listed below is to separate the specification of the CAPWAP base protocol and the 802.11-specific binding into two documents: (a) draft-ietf-capwap-protocol-specification and=20 (b) draft-ietf-capwap-wlan-binding-specification (or similar name).=20 =20 This will=20 - enable easy reference to each component separately - ensure a clean separation between the protocol and the initial 802.11/subsequent bindings - provide focus on what is essential for the CAPWAP protocol vs the bindings =20 If agreed, this coulld be accomplished In the next editing cycle by producing draft-ietf-capwap-protocol-specification-03 and=20 draft-ietf-capwap-wlan-binding-specification-00 =20 At a first cut, the binding specification document would include -02 text: - Duplicated Section 1, with modifications to indicate that this is the binding document, and reference the CAPWAP protocol spec - Section 11, with updates per issue resolution - Additional sections, per list agreement =20 Comments please. =20 Thanks, =20 Dorothy Stanley =20 Issue 201: =20 (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=20 it would also be possible for us to reference a portion of a monolithic document, as long as the base protocol is cleanly-enough=20 separated from the 802.11-specific portions to allow us to unambiguously and normatively reference the base protocol.=20 =09 =09 =09 =20 On 7/14/06, Dorothy Stanley wrote:=20 All, =09 Issues=20 =09 #200 - Trickle Firmware Download #201 - Clean Separation between base and binding =09 are now created in the issue database to track these items. =20 =09 Dorothy Stanley =20 On 7/13/06, Mani, Mahalingam (Mani) wrote:=20 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=20 (operational management action) to switch to the new firmware. =09 Requiring reboot to be synchronous with a firmware update is=20 restrictive. =09 Above may have implications of having room in stable-store for at least=20 two images (a best practice followed by all well-designed embedded systems anyway) - hopefully a non-issue nowadays even on thin WTPs.=20 =09 The second request is on first providing logical separation more than=20 physically separate documents, as I read it. The WG & editors have done a good job on that beginning with the base protocol.=20 =09 The persuasion to consider the physically split the document becomes more appealing when an additional media binding becomes a reality. The=20 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). =09 Any inputs towards improving logical separation is welcome; and the WG=20 and editors can make a choice on adopting them based on issue-priorities=20 in queue. That could serve us well now and for a physical separation at a later time (whenever it may be). =09 Thanks, -mani -----Original Message-----=20 From: Margaret Wasserman [mailto: mrw@lilacglade.org ] Sent: Wednesday, July 12, 2006 11:44 AM To: capwap@frascone.com Subject: [Capwap] CAPWAP and RFID=20 =09 =09 Hi All, =09 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=20 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=20 we've been asked to communicate some requirements from that group to the CAPWAP WG. =09 NOTE: We are not talking about adding RFID-specific control messages to CAPWAP. In fact, the group is not currently planning to use=20 CAPWAP as the control channel. So, these are not RFID-specific requirements. =09 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.=20 =09 The two requirements we've been asked to communicate are: =09 (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=20 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=20 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. =09 (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=20 separated from the 802.11-specific portions to allow us to unambiguously and normatively reference the base protocol. =09 Would the CAPWAP WG support making these changes so that the EPCglobal RO WG can reuse this technology?=20 =09 Thanks, Margaret =09 Margaret Wasserman Vice President ThingMagic margaret@thingmagic.com=20 =09 _________________________________________________________________=20 To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 =09 =20 ------_=_NextPart_001_01C6CFC3.37B675E1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have concerns with this proposal. In principle, I = support the proposal. However, in practice, I think we should wait until all the technical issues are sorted out before making the split. I am concerned = that separating the documents at this relatively early stage may complicate technical resolution. Furthermore, splitting the document seems to be an editorial = issue, which can be best done after content has been finalized. =

 

So I support the proposal but would like it to be = pursued after content has been finalized.

 

Saravanan

 

 

 

 

 

From: Pat = Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Friday, September = 01, 2006 7:25 AM
To: Dorothy Stanley; = Mani, Mahalingam (Mani)
Cc: capwap@frascone.com
Subject: Re: [Capwap] = Proposed Resolution for Issue #201: CleanSeparationBetween Base and Binding/was = Re: CAPWAP and RFID

 

Works for me. Note that some of the references may be harder to make when they occur across documents. Today = they are simple to make, because our xml2rfc allows for internal references, allowing us to reference a specific section. In the new document, we = will only be able to reference the accompanying = specification.

 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

 

From: Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Monday, August 28, = 2006 9:37 AM
To: Mani, Mahalingam = (Mani)
Cc: capwap@frascone.com
Subject: [Capwap] = Proposed Resolution for Issue #201: Clean SeparationBetween Base and Binding/was = Re: CAPWAP and RFID

All,

 

The proposed resolution for Issue #201, listed below is to separate the

specification of the CAPWAP base protocol and the = 802.11-specific binding into two documents:

(a) draft-ietf-capwap-protocol-specification and =

(b) draft-ietf-capwap-wlan-binding-specification (or similar = name).

 

This will

- enable easy reference to each component = separately

- ensure a clean separation between the protocol and the = initial 802.11/subsequent bindings

- provide focus on what is essential for the CAPWAP protocol vs = the bindings

 

If agreed, this coulld be accomplished In the next editing cycle = by producing

draft-ietf-capwap-protocol-specification-03 and =

draft-ietf-capwap-wlan-binding-specification-00=

 

At a first cut, the binding specification document would include = -02 text:

- Duplicated Section 1, with modifications to indicate that this = is the binding document, and reference the CAPWAP protocol = spec

- Section 11, with updates per issue = resolution

- Additional sections, per list = agreement

 

Comments please.

 

Thanks,

 

Dorothy Stanley

 

Issue 201:

 

(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.



 

On 7/14/06, Dorothy Stanley <dstanley1389@gmail.com> wrote:

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



 

------_=_NextPart_001_01C6CFC3.37B675E1-- --===============1667929754== 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 --===============1667929754==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Sep 03 21:58:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GK3jF-0002hw-TU for capwap-archive@lists.ietf.org; Sun, 03 Sep 2006 21:58:25 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GK3jE-0001ev-G2 for capwap-archive@lists.ietf.org; Sun, 03 Sep 2006 21:58:25 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 09FE239809A for ; Sun, 3 Sep 2006 18:58:24 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3B34D430018 for ; Sun, 3 Sep 2006 18:57:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2447E39802F for ; Sun, 3 Sep 2006 18:57:39 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 15F3939801B for ; Sun, 3 Sep 2006 18:57:36 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id k841vZRa016796; Mon, 4 Sep 2006 10:57:35 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k841vZj10558; Mon, 4 Sep 2006 10:57:35 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with SMTP id k841vYm10075; Mon, 4 Sep 2006 10:57:34 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Sep 2006 10:01:17 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD011F76B8@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC Thread-Index: AcbNVZw5JQQC+orTTMKum9zb7Fxd1wCb61yA From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC 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: c1c65599517f9ac32519d043c37c5336 Pat, This is not a new functionality, but one that is mandatory by the Objectives. Also, I do not think this is an issue of where the EAPoL-Key is generated, but rather "how" EAPoL messages are exchanged in local-MAC and split-MAC architectures. I have made a number of proposals with both text and figures that direct address the mandatory objective. I am not comfortable with a protocol that does not support explicitly stated objectives. Saravanan -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Friday, September 01, 2006 7:32 AM To: Capwap@frascone.com Subject: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC This issue was opened to add a new mode of operation to the CAPWAP protocol, allowing the WTP to generate the EAPOL messages. I do not agree with this request, and would like to see this one rejected. We really need to focus on getting a protocol completed, and I just don't see a burning need to add this new functionality. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ 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 gonnoora@lamerica2.mot.com Mon Sep 04 10:01:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKF0Z-0008Cw-U3 for capwap-archive@ietf.org; Mon, 04 Sep 2006 10:01:03 -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 1GKF0Z-0006y0-Rm for capwap-archive@ietf.org; Mon, 04 Sep 2006 10:01:03 -0400 Received: from [201.228.52.191] (helo=lamerica2.mot.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GKF0V-0002FP-Ld for capwap-archive@ietf.org; Mon, 04 Sep 2006 10:01:03 -0400 Message-ID: <000001c6d02a$7b36f180$a051a8c0@jmkl> Reply-To: "Beth Vanarsdale" From: "Beth Vanarsdale" To: capwap-archive@ietf.org Subject: Re: oieu about your youth Date: Mon, 4 Sep 2006 07:00:30 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6CFEF.CED81980" 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.0 (++++) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6CFEF.CED81980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 TURN BACK THE CLOCK H G v H F b ormul p a P l rov r en to Work. =20 Our all - n k atura r l H G k H is cer d tifi p ed and will give you=20 the yo r uth r ful results you want or your m h on q ey back. =20 Our H l G H fo i rm l ula will: =20 * Sleep deeper and need less of it * Maintain and increase your memory * Decrease fat reserves in the body * Intensify mental alertness and concentration * Improve overall physical and mental well-being * Improve your skin * Increase muscle and bone mass * Give your l w ibi h do a boost * Increase your energy and metabolism =20 Now get fr o ee b b ottle b s with pu i rcha x se. L d imite i d time onl n y! =20 re n ga q in your y h outh n w ow =20 ------=_NextPart_000_0001_01C6CFEF.CED81980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
TURN BACK THE CLOCK
H G v H F b ormul p a P l rov r en to Work.
 
Our all - n k atura r l H G k H is cer d tifi p ed and will give you
the yo r uth r ful results you want or your m h on q ey back.
 
Our H l G H fo i rm l ula will:
 
* Sleep deeper and need less of it
* Maintain and = increase your memory
* Decrease fat reserves in the = body
* Intensify mental alertness and concentration
=
* Improve overall physical and mental well-being
* = Improve your skin
* Increase muscle and bone mass
=
* Give your l w ibi h do a boost
* Increase your energy and = metabolism
 
Now get fr o ee b b ottle b s with pu i rcha x se. L d imite i d time onl n y!
 
------=_NextPart_000_0001_01C6CFEF.CED81980-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Sep 04 13:52:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKIcV-0007Gp-HM for capwap-archive@lists.ietf.org; Mon, 04 Sep 2006 13:52:27 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKIcT-0002Qo-0E for capwap-archive@lists.ietf.org; Mon, 04 Sep 2006 13:52:27 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id DA0383980B4 for ; Mon, 4 Sep 2006 10:52:21 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7106A430082 for ; Mon, 4 Sep 2006 10:51:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 55555144801F for ; Mon, 4 Sep 2006 10:51:17 -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 010A21448003 for ; Mon, 4 Sep 2006 10:51:14 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 04 Sep 2006 10:51:14 -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.20060308/8.12.11) with ESMTP id k84HpEfl001396 for ; Mon, 4 Sep 2006 10:51:14 -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 k84HpEYp018920 for ; Mon, 4 Sep 2006 10:51:14 -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); Mon, 4 Sep 2006 10:51:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Sep 2006 10:51:13 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC01F9C5C7@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC Thread-Index: AcbNVZw5JQQC+orTTMKum9zb7Fxd1wCb61yAACEzZnA= From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 04 Sep 2006 17:51:13.0968 (UTC) FILETIME=[B6CCF300:01C6D04A] Authentication-Results: sj-dkim-2.cisco.com; header.From=boohara@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] Issue 199: EAPoL-Key message generation at WTP or AC 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: 00e94c813bef7832af255170dca19e36 Saranavan, The current protocol, as it is specified in -02, does meet the stated objectives. It supports both local MAC and split MAC architectures, as those architectures are described in the taxonomy document. There is no requirement in the objectives that the protocol support any other arbitrary split of functionality between the AC and WTP. Otherwise, we would have to negotiate EVERY possible frame that might be exchanged between a mobile node and the 802.11 access point, to determine if it is generated in the AC or the WTP. For example, do the objectives require that the protocol must support the Association Request being processed in the AC and the Association Response being generated in the WTP for a split MAC architecture? -Bob -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Sunday, September 03, 2006 7:01 PM To: Pat Calhoun (pacalhou); Capwap@frascone.com Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC Pat, This is not a new functionality, but one that is mandatory by the Objectives. Also, I do not think this is an issue of where the EAPoL-Key is generated, but rather "how" EAPoL messages are exchanged in local-MAC and split-MAC architectures. I have made a number of proposals with both text and figures that direct address the mandatory objective. I am not comfortable with a protocol that does not support explicitly stated objectives. Saravanan -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Friday, September 01, 2006 7:32 AM To: Capwap@frascone.com Subject: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC This issue was opened to add a new mode of operation to the CAPWAP protocol, allowing the WTP to generate the EAPOL messages. I do not agree with this request, and would like to see this one rejected. We really need to focus on getting a protocol completed, and I just don't see a burning need to add this new functionality. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ 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 Tue Sep 05 02:00:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKTyn-0003ge-O1 for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 02:00:13 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKTyj-0007EZ-8D for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 02:00:13 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id EDCFB398087 for ; Mon, 4 Sep 2006 22:59:57 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id EB68A430082 for ; Mon, 4 Sep 2006 22:58:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id CFAC939805C for ; Mon, 4 Sep 2006 22:58:44 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id CC22339800E for ; Mon, 4 Sep 2006 22:58:41 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k855wb7a029634; Tue, 5 Sep 2006 14:58:37 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k855wcB15673; Tue, 5 Sep 2006 14:58:38 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with SMTP id k855wdm03359; Tue, 5 Sep 2006 14:58:39 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Sep 2006 14:02:28 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD011F791B@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC Thread-Index: AcbNVZw5JQQC+orTTMKum9zb7Fxd1wCb61yAACEzZnAADyOWcA== From: "Saravanan Govindan" To: "Bob O'Hara (boohara)" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC 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: 287c806b254c6353fcb09ee0e53bbc5e Bob, The objective for this issue addresses designs where the 802.11i authenticator is located at the AC and cryptographic functions are on the WTP. This is made very clear in the requirement. What the protocol currently needs is a way to specify prevailing KeyRSC information (maintained by the WTP) to EAPoL messages (generated by the AC). The proposal so far is to let the AC send EAPoL messages (with unassigned KeyRSC field) to the WTP. Then the WTP assigns the prevailing KeyRSC and forwards to the wireless station. The objective and corresponding proposal are very clear. Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] Sent: Tuesday, September 05, 2006 1:51 AM To: Capwap@frascone.com Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC Saranavan, The current protocol, as it is specified in -02, does meet the stated objectives. It supports both local MAC and split MAC architectures, as those architectures are described in the taxonomy document. There is no requirement in the objectives that the protocol support any other arbitrary split of functionality between the AC and WTP. Otherwise, we would have to negotiate EVERY possible frame that might be exchanged between a mobile node and the 802.11 access point, to determine if it is generated in the AC or the WTP. For example, do the objectives require that the protocol must support the Association Request being processed in the AC and the Association Response being generated in the WTP for a split MAC architecture? -Bob -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Sunday, September 03, 2006 7:01 PM To: Pat Calhoun (pacalhou); Capwap@frascone.com Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC Pat, This is not a new functionality, but one that is mandatory by the Objectives. Also, I do not think this is an issue of where the EAPoL-Key is generated, but rather "how" EAPoL messages are exchanged in local-MAC and split-MAC architectures. I have made a number of proposals with both text and figures that direct address the mandatory objective. I am not comfortable with a protocol that does not support explicitly stated objectives. Saravanan -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Friday, September 01, 2006 7:32 AM To: Capwap@frascone.com Subject: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC This issue was opened to add a new mode of operation to the CAPWAP protocol, allowing the WTP to generate the EAPOL messages. I do not agree with this request, and would like to see this one rejected. We really need to focus on getting a protocol completed, and I just don't see a burning need to add this new functionality. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ 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 _________________________________________________________________ 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 Sep 05 11:26:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKcou-00016W-GQ for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 11:26:36 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKcor-0001EP-VW for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 11:26:36 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id A57D63980AD for ; Tue, 5 Sep 2006 08:26:24 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 0EAAD430083 for ; Tue, 5 Sep 2006 08:24:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id EFAD0398092 for ; Tue, 5 Sep 2006 08:24:45 -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 06F28398050 for ; Tue, 5 Sep 2006 08:24:42 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 05 Sep 2006 08:24:43 -0700 X-IronPort-AV: i="4.08,215,1154934000"; d="scan'208"; a="339721689:sNHT70319828" 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 k85FOgAm007329 for ; Tue, 5 Sep 2006 08:24:42 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k85FOgQV025074 for ; Tue, 5 Sep 2006 08:24:42 -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); Tue, 5 Sep 2006 08:24:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Sep 2006 08:24:39 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC01F9C6CA@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC Thread-Index: AcbNVZw5JQQC+orTTMKum9zb7Fxd1wCb61yAACEzZnAADyOWcAAd8m/w From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 05 Sep 2006 15:24:41.0682 (UTC) FILETIME=[689A5320:01C6D0FF] Authentication-Results: sj-dkim-4.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] Issue 199: EAPoL-Key message generation at WTP or AC 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: b2809b6f39decc6de467dcf252f42af1 Saranavan, EAPOL-key message generation is not a cryptographic function. As is very clear, if you understand how the EAPOL-key message and the KeyRSC are used in 802.11i, it is not necessary to implement the proposal you requested between AC and WTP, regardless of where the cryptographic functions reside. Therefore, the objective is met by the currently defined protocol. -Bob -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Monday, September 04, 2006 11:02 PM To: Bob O'Hara (boohara); Capwap@frascone.com Subject: RE: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC Bob, The objective for this issue addresses designs where the 802.11i authenticator is located at the AC and cryptographic functions are on the WTP. This is made very clear in the requirement. What the protocol currently needs is a way to specify prevailing KeyRSC information (maintained by the WTP) to EAPoL messages (generated by the AC). The proposal so far is to let the AC send EAPoL messages (with unassigned KeyRSC field) to the WTP. Then the WTP assigns the prevailing KeyRSC and forwards to the wireless station. The objective and corresponding proposal are very clear. Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] Sent: Tuesday, September 05, 2006 1:51 AM To: Capwap@frascone.com Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC Saranavan, The current protocol, as it is specified in -02, does meet the stated objectives. It supports both local MAC and split MAC architectures, as those architectures are described in the taxonomy document. There is no requirement in the objectives that the protocol support any other arbitrary split of functionality between the AC and WTP. Otherwise, we would have to negotiate EVERY possible frame that might be exchanged between a mobile node and the 802.11 access point, to determine if it is generated in the AC or the WTP. For example, do the objectives require that the protocol must support the Association Request being processed in the AC and the Association Response being generated in the WTP for a split MAC architecture? -Bob -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Sunday, September 03, 2006 7:01 PM To: Pat Calhoun (pacalhou); Capwap@frascone.com Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC Pat, This is not a new functionality, but one that is mandatory by the Objectives. Also, I do not think this is an issue of where the EAPoL-Key is generated, but rather "how" EAPoL messages are exchanged in local-MAC and split-MAC architectures. I have made a number of proposals with both text and figures that direct address the mandatory objective. I am not comfortable with a protocol that does not support explicitly stated objectives. Saravanan -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Friday, September 01, 2006 7:32 AM To: Capwap@frascone.com Subject: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC This issue was opened to add a new mode of operation to the CAPWAP protocol, allowing the WTP to generate the EAPOL messages. I do not agree with this request, and would like to see this one rejected. We really need to focus on getting a protocol completed, and I just don't see a burning need to add this new functionality. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ 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 _________________________________________________________________ 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 Sep 05 11:31:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKctH-0003ra-8X for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 11:31:08 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKctF-0002GO-LK for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 11:31:07 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 5A4E443110F for ; Tue, 5 Sep 2006 08:30:59 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id ABA1C430083 for ; Tue, 5 Sep 2006 08:28:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 937814310F4 for ; Tue, 5 Sep 2006 08:28:25 -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 78D6A4310E4 for ; Tue, 5 Sep 2006 08:28:23 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 05 Sep 2006 08:28:23 -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 k85FSMEU012277; Tue, 5 Sep 2006 08:28:22 -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 k85FSMQV028125; Tue, 5 Sep 2006 08:28:22 -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); Tue, 5 Sep 2006 08:28:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Sep 2006 08:28:21 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2026C4B4C@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC Thread-Index: AcbNVZw5JQQC+orTTMKum9zb7Fxd1wCb61yAACEzZnAADyOWcAAeSu/g From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , "Bob O'Hara (boohara)" , X-OriginalArrivalTime: 05 Sep 2006 15:28:22.0062 (UTC) FILETIME=[EBF5A4E0:01C6D0FF] 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] Issue 199: EAPoL-Key message generation at WTP or AC 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: f49c97ce49302a02285a2d36a99eef8c Saravanan, What exactly in the protocol prevents 802.11i from being used? As far as I can tell, from my own implementation of a derivative of CAPWAP, the protocol runs fine with both Split and Local MAC. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Monday, September 04, 2006 11:02 PM > To: Bob O'Hara (boohara); Capwap@frascone.com > Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation > at WTP or AC > > Bob, > > The objective for this issue addresses designs where the > 802.11i authenticator is located at the AC and cryptographic > functions are on the WTP. This is made very clear in the requirement. > > What the protocol currently needs is a way to specify > prevailing KeyRSC information (maintained by the WTP) to > EAPoL messages (generated by the AC). The proposal so far is > to let the AC send EAPoL messages (with unassigned KeyRSC > field) to the WTP. Then the WTP assigns the prevailing KeyRSC > and forwards to the wireless station. > > The objective and corresponding proposal are very clear. > > Saravanan > > > > > > > -----Original Message----- > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > Sent: Tuesday, September 05, 2006 1:51 AM > To: Capwap@frascone.com > Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation > at WTP or AC > > Saranavan, > > The current protocol, as it is specified in -02, does meet > the stated objectives. It supports both local MAC and split > MAC architectures, as those architectures are described in > the taxonomy document. > > There is no requirement in the objectives that the protocol > support any other arbitrary split of functionality between > the AC and WTP. > Otherwise, we would have to negotiate EVERY possible frame > that might be exchanged between a mobile node and the 802.11 > access point, to determine if it is generated in the AC or > the WTP. For example, do the objectives require that the > protocol must support the Association Request being processed > in the AC and the Association Response being generated in the > WTP for a split MAC architecture? > > -Bob > > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Sunday, September 03, 2006 7:01 PM > To: Pat Calhoun (pacalhou); Capwap@frascone.com > Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation > at WTP or AC > > Pat, > > This is not a new functionality, but one that is mandatory by > the Objectives. > > Also, I do not think this is an issue of where the EAPoL-Key > is generated, but rather "how" EAPoL messages are exchanged > in local-MAC and split-MAC architectures. > > I have made a number of proposals with both text and figures > that direct address the mandatory objective. > > I am not comfortable with a protocol that does not support > explicitly stated objectives. > > Saravanan > > > > > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Friday, September 01, 2006 7:32 AM > To: Capwap@frascone.com > Subject: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC > > This issue was opened to add a new mode of operation to the > CAPWAP protocol, allowing the WTP to generate the EAPOL > messages. I do not agree with this request, and would like to > see this one rejected. We really need to focus on getting a > protocol completed, and I just don't see a burning need to > add this new functionality. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > 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 > > _________________________________________________________________ > 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 Sep 05 11:39:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKd1k-0006Np-2u for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 11:39:52 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKd1i-0003OD-Ef for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 11:39:52 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 933B043113C for ; Tue, 5 Sep 2006 08:39:46 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 549EA430083 for ; Tue, 5 Sep 2006 08:37:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3AF5C3980A0 for ; Tue, 5 Sep 2006 08:37:02 -0700 (PDT) Received: from bay0-omc2-s39.bay0.hotmail.com (bay0-omc2-s39.bay0.hotmail.com [65.54.246.175]) by zoidberg.tigertech.net (Postfix) with ESMTP id B24F43980A2 for ; Tue, 5 Sep 2006 08:36:58 -0700 (PDT) Received: from hotmail.com ([207.46.8.224]) by bay0-omc2-s39.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Sep 2006 08:36:58 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 5 Sep 2006 08:36:58 -0700 Message-ID: Received: from 207.46.8.251 by by118fd.bay118.hotmail.msn.com with HTTP; Tue, 05 Sep 2006 15:36:55 GMT X-Originating-IP: [202.156.10.12] X-Originating-Email: [saravanang@hotmail.com] X-Sender: saravanang@hotmail.com In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC01F9C6CA@xmb-sjc-237.amer.cisco.com> From: "Saravanan Govindan" To: boohara@cisco.com, Capwap@frascone.com Date: Tue, 05 Sep 2006 23:36:55 +0800 Mime-Version: 1.0 X-OriginalArrivalTime: 05 Sep 2006 15:36:58.0242 (UTC) FILETIME=[1FA07620:01C6D101] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.748 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC 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 Bob, The location of the cryptographic functions defines where the KeyRSC is maintained, which is required for the EAPoL-Key messages in 802.11i. The protocol specifications currently does not have a way to assign the right value of KeyRSC to the EAPoL-Key message. It does not support the IEEE 802.11i Considerations objective. Saravanan ----Original Message Follows---- From: "Bob O'Hara (boohara)" To: Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC Date: Tue, 5 Sep 2006 08:24:39 -0700 Saranavan, EAPOL-key message generation is not a cryptographic function. As is very clear, if you understand how the EAPOL-key message and the KeyRSC are used in 802.11i, it is not necessary to implement the proposal you requested between AC and WTP, regardless of where the cryptographic functions reside. Therefore, the objective is met by the currently defined protocol. -Bob -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Monday, September 04, 2006 11:02 PM To: Bob O'Hara (boohara); Capwap@frascone.com Subject: RE: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC Bob, The objective for this issue addresses designs where the 802.11i authenticator is located at the AC and cryptographic functions are on the WTP. This is made very clear in the requirement. What the protocol currently needs is a way to specify prevailing KeyRSC information (maintained by the WTP) to EAPoL messages (generated by the AC). The proposal so far is to let the AC send EAPoL messages (with unassigned KeyRSC field) to the WTP. Then the WTP assigns the prevailing KeyRSC and forwards to the wireless station. The objective and corresponding proposal are very clear. Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] Sent: Tuesday, September 05, 2006 1:51 AM To: Capwap@frascone.com Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC Saranavan, The current protocol, as it is specified in -02, does meet the stated objectives. It supports both local MAC and split MAC architectures, as those architectures are described in the taxonomy document. There is no requirement in the objectives that the protocol support any other arbitrary split of functionality between the AC and WTP. Otherwise, we would have to negotiate EVERY possible frame that might be exchanged between a mobile node and the 802.11 access point, to determine if it is generated in the AC or the WTP. For example, do the objectives require that the protocol must support the Association Request being processed in the AC and the Association Response being generated in the WTP for a split MAC architecture? -Bob -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Sunday, September 03, 2006 7:01 PM To: Pat Calhoun (pacalhou); Capwap@frascone.com Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC Pat, This is not a new functionality, but one that is mandatory by the Objectives. Also, I do not think this is an issue of where the EAPoL-Key is generated, but rather "how" EAPoL messages are exchanged in local-MAC and split-MAC architectures. I have made a number of proposals with both text and figures that direct address the mandatory objective. I am not comfortable with a protocol that does not support explicitly stated objectives. Saravanan -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Friday, September 01, 2006 7:32 AM To: Capwap@frascone.com Subject: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC This issue was opened to add a new mode of operation to the CAPWAP protocol, allowing the WTP to generate the EAPOL messages. I do not agree with this request, and would like to see this one rejected. We really need to focus on getting a protocol completed, and I just don't see a burning need to add this new functionality. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ 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 _________________________________________________________________ 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 capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Sep 05 12:15:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdaT-0004pc-Ei for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:15:45 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKdaR-0008Rm-Io for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:15:45 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id B0B42431201 for ; Tue, 5 Sep 2006 09:15:39 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D9D68430083 for ; Tue, 5 Sep 2006 09:14:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C0BFE398058 for ; Tue, 5 Sep 2006 09:14:46 -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 37845398092 for ; Tue, 5 Sep 2006 09:14:42 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 05 Sep 2006 09:14:41 -0700 X-IronPort-AV: i="4.08,215,1154934000"; d="scan'208"; a="442395695:sNHT36347590" 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 k85GEfhp003038; Tue, 5 Sep 2006 09:14:41 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k85GEfQf001497; Tue, 5 Sep 2006 09:14:41 -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); Tue, 5 Sep 2006 09:14:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Sep 2006 09:14:31 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2026C4B93@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on -02 version of capwap spec Thread-Index: Aca/uwxBHUIaBgYPTZ28fYPCQF6LQALDJVmwAAI/69AAAH0LAAACcGRwAGcectAAN0YZEA== From: "Pat Calhoun (pacalhou)" To: "Puneet Agarwal" , , X-OriginalArrivalTime: 05 Sep 2006 16:14:32.0709 (UTC) FILETIME=[5F64D350:01C6D106] 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 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] Comments on -02 version of capwap spec 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: 83e9494d829b08cc3f644ef6ac1b9bd4 Finally got to completing my response to your list of issues. > 1) Section 11.1.1 Split MAC > " All client data frames are tunneled between the WTP and the AC." > > It is unclear what is meant by Client Data Frames - is it only > 802.11 data Frames or does it include 802.11 > Management/Control Frames also? The rest of this section discusses which of the management frames are sent to the AC. So this specific bullet item is about IEEE 802.11 Data Frames being tunneled. Would you be satisfied with a changes from "Client Data Frames" to "Client IEEE 802.11 Data Frames"? Being tracked as issue 210. > > 2) In Split MAC, are 802.11 Management Frames sent in CAPWAP > data frames? Yes > > 3) If (2) is true (ignore otherwise), then what is the CAPWAP > priority of these frames? >From the draft: 11.6 Quality of Service for Control Messages It is recommended that IEEE 802.11 MAC management frames be sent by both the AC and the WTP with appropriate Quality of Service values, ensuring that congestion in the network minimizes occurrences of packet loss. Therefore, a Quality of Service enabled CAPWAP device should use: 802.1P: The precedence value of 6 SHOULD be used for all IEEE 802.11 MAC management frames, except for Probe Requests which SHOULD use 4. DSCP: The DSCP tag value of 46 SHOULD be used for all IEEE 802.11 MAC management frames, except for Probe Requests which SHOULD use 34. > > 4) In Fig 5, "Split MAC Message Flow", why is the "Probe > Request" from the Client sent to the AC also - even though > all the processing was done at the WTP for this message? In order for the AC to know the client is probing. > > 5) In Fig 5, what is the semantics of the notation: > "Add Mobile (Clear Text, 802.1X)"? > I could not find the 2 parameters implied by "Clear Text" and "802.1X" > in the > description of Add Mobile in section 4.4.8 or in section > 11.9.9 (IEEE 802.11 Mobile). Ah, this is a bug. The -02 document changed to utilizing the RSN info, but the section you discuss did not include the necessary changes. Created issue 211 to track this one. > > 6) Section 11.9.9: "If the QoS field is set," - which field > (where) are you checking for the presence or absence of the Qos Field? Another good catch of a change that is missing as a result of splitting up message elements. Created issue 212 to track this one. > > 7) Radio ID, WLAN ID, BSSID - is there an implied > relationship between these various configured element ie many > radios to one WLAN ID etc. A BSSID is assigned to a WLAN ID - so there is a 1:1 corelation there. A WLAN can exist on one or more radios on the WTP. > > 8) Assoc ID vs MAC Addr for id (which takes precedence or do > you need to do both checks) Assoc ID is only used for power save - and is defined in the 802.11 protocol. When a packet is queued on the MAC for a domant station, its association ID is included in beacons to notify it of packets sitting on the queue. The station is identified via its MAC address, not the association ID. > > 9) Section 11.5: Please state clearly that even though these > are 802.11 Control Messages, they are still sent in CAPWAP > DATA messages (at least for now). Actually, these are for MAC management messages, not control messages, so the header is incorrect. Further, your request, while valid, needs to be handled in another section of the document. I will make this clearer. Created issue 213 to track this issue > > 10) What is the recommendation for 802.1P and DSCP values for > 802.11 Data > Frames? Do you honor the .11 QoS semantics between WTP > and AC or are all > .11 Data Frames sent at the same priority in CAPWAP? That's an implementation issue. > > 11) Should 802.1X frames be sent with different QoS than > regular 802.11 Data Frames? What is our QoS Philosophy for > such control traffic? One would think so, and we should possibly consider this. Created issue 214 to track this issue. > > 12) It seems that within CAPWAP Data channel, there are > multiple 802.11 control channels (it seems that different QoS > levels are an implicit attempt at this > - refer to section 11.5). > General question to the group: Would it be beneficial to > transport these > .11 control channels as "raw" data channels in CAPWAP Control > messages allowing the network to honor the 8 .1p priorities > for 802.11 Data frames in the CAPWAP DATA message. I do not believe so. I think this would unnecessarily complicate the protocol. Furthermore, if you went down this path, you'd have to put the 802.1X/EAPOL protocol in that channel... what about IAPP? etc. The current model keeps the separation of wireless binding to control best. > > 13) Section 11.1.2 Local MAC: The spec defines capability to > tunnel Client data frames as 802.3 frames between the WTP and > the AC. It would seem that the CAPWAP Data tunnel (as > currently defined) would need to carry both > 802.3 > payload (for client data frames) and 802.11 payload (for RSNA > Key Mgmnt frames). Is this capability really desired? You are correct that 802.11 MAC management frames may be sent, but normal user frames would be in 802.3 format, as you had earlier requested on the list. Figure 7 on page 101 makes this clear. > > 14) Section 4.1 CAPWAP Transport Header - It seems that this > section should be renamed "CAPWAP Header" or all references > in section 4 and other places should be updated to be "CAPWAP > Transport Header". Correct, for consistency sake we should make this change. Created issue 215 to track this one. > > 15) Section 4.1: The RID field here is 5 bits while in all > control messages it seems to be 8 bits - this needs to be reconciled DUP issue, and already taken care of. > > 16) Section 4.1: Description of RID field is unclear especially: > > " WTPs with multiple radios but a single MAC Address range > use this field to indicate which radio is associated with the > packet." > > It would be great if this could be clarified - it seems to be > implying that this is used to support the case where > multiple radios share the same Radio MAC address but is not > very clear - is this the case? The point is that the BSSID is not sufficient since some WTP vendors re-use the BSSID across their a/bg radios. Since you guessed it, I suppose it is good enough? Any recommended changes? > > 17) Section 4.1: I assume that implementations MUST support > 802.3 frames as well as "Native" frames in the same CAPWAP > Data Tunnel. Is this true and is that what we really want? That was the agreement in a previous thread. > > 18) Section 4.1: M bit. You mention in the text that "this > field MUST NOT be set to one in pkts sent by the AC to the WTP". > > However, when you are transporting 802.3 frames, won't the AC > need to indicate to the WTP what BSSID to use when sending > the frame (or is it assumed that the BSSID is derived from > the dest Client's MAC Addr for unicast)? good catch. Will fix this. Created issue 216 to track this one. > > 19) Section 11.9.1: For Tunnel Mode == "802.3 tunnel" in > Local MAC mode, how are RSNA frames converted to 802.3 as > they seem to be required for Local Mac They are not. see above comment > > 20) In Local MAC with 802.3 tunnel, how are 4 MAC 802.11 converted to > 802.3 > without loss of info? Ie do we need to define TX-MAC element > also (in CAPWAP data frames from WTP to AC)? They are not. If you need 4 address, use 802.11 frame formats. I think there's a point where it makes hacking the protocol to support every possible frame format become more complex. As an aside, TGs is now working on a 6 address format - what will we do for that one? That said, most applications use 3 address format, so 802.3 covers a broad range of applications. > > 21) In Split MAC Mode: when the WTP does > encryption/decryption, please specify the exact fields that > are valid when WTP sends such frames to the AC (as they are > now pseudo-802.11 frames after potential 802.11 reassembly in > the WTP). will do. Create issue 217 to track this one. > > 22) Can the same WLAN ID be assigned to different radios with > the same BSSID? Yes. > > 23) Can the same WLAN ID be assigned to different radios with > different BSSID? Yes. > > 24) For multicast pkts, does AC need to send multiple copies > of the packet to send to each radio on the WTP that is part > of the same WLAN ID or is the packet replicated by the WTP to > all radios that are part of the same WLAN ID? The purpose for the bitmap field is to avoid the need to replicate packets to the same WTP. Note that if the packets are centrally encrypted, then the packet needs to be replicated, and encrypted using the right GTK. So from a performance point of view, multicast/broadcast along with centralized encryption is the worst case. Of course, this is equally true if DTLS is applied on the data plane. If the packet is encrypted on the WTP, then only a single copy needs to be sent, with the right bitmap. > > 25) Local MAC with local bridge is the default mode - this > implies that all implementations must support this config > (which has the most complex s/w for the AP) - is that the > correct default and why was it chosen - should this be changed? It was discussed during a thread. We needed to pick one. > > 26) Why is the MAC mode and Tunnel Mode part of the WLANID > config? What is the practical reason for allowing this per WLANID? Some vendors want the behavior to be different across WLANs. Sometimes tunnel, and sometimes don't. The MAC Mode probably should be done on a per WTP, IMHO. > > 27) How does multicast handle the case when the number of > WLANIDs is greater than 16 - how does AC indicate that to the > WTP? It seems you run out of bits in the CAPWAP data packets. The protocol already states that 16 is the hard limit. PatC _________________________________________________________________ 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 Sep 05 12:23:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdhr-0007j3-0Y for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:23:23 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKdhp-00012y-Fx for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:23:22 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id C1440431150 for ; Tue, 5 Sep 2006 09:23:17 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6CDB743008F for ; Tue, 5 Sep 2006 09:19:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1F157398058 for ; Tue, 5 Sep 2006 09:19:35 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id C088B39808C for ; Tue, 5 Sep 2006 09:19:29 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 05 Sep 2006 09:19:29 -0700 X-IronPort-AV: i="4.08,215,1154934000"; d="scan'208"; a="1851959968:sNHT32351102" 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.20060308/8.12.11) with ESMTP id k85GJT7L010284; Tue, 5 Sep 2006 09:19:29 -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 k85GJTw7004925; Tue, 5 Sep 2006 09:19:29 -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); Tue, 5 Sep 2006 09:19:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Sep 2006 09:19:27 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2026C4B9C@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] One Issue: About WTP Static IP Address Information Must in "Configuration Status response message" and not "Configuration Status message" Thread-Index: AcbOWQjawDVHUCc5SxOpFn1O3OhZVwCrd+7A From: "Pat Calhoun (pacalhou)" To: "zhaoyujin 31390" , X-OriginalArrivalTime: 05 Sep 2006 16:19:28.0795 (UTC) FILETIME=[0FDFF6B0:01C6D107] 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 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] One Issue: About WTP Static IP Address Information Must in "Configuration Status response message" and not "Configuration Status message" 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: 6cca30437e2d04f45110f2ff8dc1b1d5 This is an error. It should have been MAY for that specific message element. Created issue 218 to track this issue. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: zhaoyujin 31390 [mailto:zhaoyujin@huawei.com] > Sent: Friday, September 01, 2006 11:28 PM > To: Capwap@frascone.com > Subject: [Capwap] One Issue: About WTP Static IP Address > Information Must in "Configuration Status response message" > and not "Configuration Status message" > > The issue is: > > Section 4.4.45 defines WTP static IP address information > which is used by AC to set AP ip address. > > But in Section 8.2. Configuration Status describes "WTP > Static IP Address Information" MUST be included in the > Configuration Status message. > > I can't understand. I think there may be some error. The > Configuration Status message is from AP to AC, so that I > think "WTP Static IP Address Information" MUST be included in > the "Configuration Status response message" and not > "Configuration Status message". > > > Best regards > Michael > > > >The following is the description in draft-02: > > > >4.4.45. WTP Static IP Address Information > > > > The WTP Static IP Address Information message element is > used by an > > AC to configure or clear a previously configured static > IP address on > > a WTP. > > > >8.2. Configuration Status > > The following message elements MUST be included in the > Configuration > > Status message. > > o WTP Static IP Address Information, see Section 4.4.45 > > > > > This e-mail and attachments contain confidential information > from HUAWEI, which is intended only for the person or entity > whose address is listed above. Any use of the information > contained herein in any way (including, but not limited to, > total or partial disclosure, reproduction, or dissemination) > by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please > notify the sender by phone or email immediately and delete it! > > _________________________________________________________________ > 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 Sep 05 12:25:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdk1-0000Kt-Im for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:25:37 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKdjz-0001RR-UM for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:25:37 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 361B74311E9 for ; Tue, 5 Sep 2006 09:25:32 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 83F43430083 for ; Tue, 5 Sep 2006 09:20:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 72AC8431213 for ; Tue, 5 Sep 2006 09:20:23 -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 A8155431210 for ; Tue, 5 Sep 2006 09:20:14 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 05 Sep 2006 09:20:14 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k85GKEGF032418 for ; Tue, 5 Sep 2006 09:20:14 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k85GKEQX005846 for ; Tue, 5 Sep 2006 09:20:14 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Sep 2006 09:20:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Sep 2006 09:20:13 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2026C4BA3@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 160: All strings should be changed from US-ASCII toUTF-8 Thread-Index: AcbCFgaEz5d2R3HNTgCHhSsEZej7WgO8Rd9A From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 05 Sep 2006 16:20:14.0118 (UTC) FILETIME=[2AE3B460:01C6D107] 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-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] Issue 160: All strings should be changed from US-ASCII toUTF-8 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: 4bb0e9e1ca9d18125bc841b2d8d77e24 Given the lack of response, I will close this issue with the assumption the group is comfortable with the change. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, August 17, 2006 8:59 AM > To: Capwap@frascone.com > Subject: [Capwap] Issue 160: All strings should be changed > from US-ASCII toUTF-8 > > All, > > I've address the above mentioned issue by ensuring that all > references to strings now specifically state that the string > is UTF-8 encoded. > There are, however, some exceptions, which I will list below as well. > > > 4.4.4. AC Name > > The AC name message element contains an UTF-8 representation of the > AC's identity. The value is a variable length byte string. The > string is NOT zero terminated. > > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | Name ... > +-+-+-+-+-+-+-+-+ > > Type: 4 for AC Name > > Length: > 0 > > Name: A variable length UTF-8 encoded string containing the AC's > name > > 4.4.5. AC Name with Index > > The AC Name with Index message element is sent by the AC to the WTP > to configure preferred ACs. The number of instances where this > message element would be present is equal to the number of ACs > configured on the WTP. > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Index | AC Name... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: 5 for AC Name with Index > > Length: > 2 > > Index: The index of the preferred server (e.g., 1=primary, > 2=secondary). > > AC Name: A variable length UTF-8 encoded string > containing the AC's > name. > > 4.4.8. Add Station > > The Add Station message element is used by the AC to inform a WTP > that it should forward traffic for a particular STA. The > Add Station > message element will be accompanied by technology specific binding > information element which may include security parameters. > Consequently, the security parameters must be applied by > the WTP for > the particular STA. > > Once a STA's policy has been pushed to the WTP through this message > > > > Calhoun, Editor, et al. Expires November 2, 2006 > [Page 49] > > > Internet-Draft CAPWAP Protocol Specification > May 2006 > > > element, an AC may change any policies by simply sending a modified > Add Station message element. When a WTP receives an Add Station > message element for an existing STA, it must override any existing > state it may have for the STA in question. The latest Add Station > message element data overrides any previously received messages. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Radio ID | MAC Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MAC Address | VLAN Name... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: 8 for Add Station > > Length: >= 7 > > Radio ID: An 8-bit value representing the radio > > MAC Address: The STA's MAC Address > > VLAN Name: An optional variable length UTF-8 encoded string > containing the VLAN Name on which the WTP is to locally bridge > user data. Note this field is only valid with WTPs > configured in > Local MAC mode. > > 4.4.24. Image Filename > > The image filename message element is sent by the WTP to the AC and > is used to initiate the firmware download process. This message > element contains the image filename, which the AC subsequently > transfers to the WTP via the Image Data message element. The value > is a variable length UTF-8 encoded string, which is NOT zero > terminated. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Filename ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: 24 for Image Filename > > Length: >= 1 > > Filename: A variable length UTF-8 encoded string containing the > filename to download. > > 4.4.26. Location Data > > The Location Data message element is a variable length byte UTF-8 > encoded string containing user defined location information (e.g. > "Next to Fridge"). This information is configurable by the network > administrator, and allows for the WTP location to be determined > > > > Calhoun, Editor, et al. Expires November 2, 2006 > [Page 59] > > > Internet-Draft CAPWAP Protocol Specification > May 2006 > > > through this field. The string is not zero terminated. > > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+- > | Location ... > +-+-+-+-+-+-+-+-+- > > Type: 26 for Location Data > > Length: > 0 > > Timeout: A non-zero terminated UTF-8 encoded string > containing the > WTP location. > > 4.4.42. WTP Name > > The WTP Name message element is a variable length byte > UTF-8 encoded > string. The string is not zero terminated. > > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+- > | WTP Name ... > +-+-+-+-+-+-+-+-+- > > > > Calhoun, Editor, et al. Expires November 2, 2006 > [Page 70] > > > Internet-Draft CAPWAP Protocol Specification > May 2006 > > > Type: 42 for WTP Name > > Length: variable > > WTP Name: A non-zero terminated UTF-8 encoded string > containing the > WTP name. > > > As I mentioned above, there are exceptions in the > specification, which I will mention here: > > > 2.4.4.3. Certificate Usage > > Validation of the certificates by the AC and WTP is > required so that > only an AC may perform the functions of an AC and that > only a WTP may > perform the functions of a WTP. This restriction of > functions to the > AC or WTP requires that the certificates used by the AC MUST be > distinguishable from the certificate used by the WTP. To > accomplish > this differentiation, the x.509v3 certificates MUST include the > Extensions field [11] and MUST include the NetscapeComment [15] > extension. > > For an AC, the value of the NetscapeComment extension MUST be the > string "CAPWAP AC Device Certificate". For a WTP, the value of the > NetscapeComment extension MUST be the string "CAPWAP WTP Device > Certificate". > > Part of the CAPWAP certificate validation process includes ensuring > that the proper string is included in the NetscapeComment > extension, > and only allowing the CAPWAP session to be established if the > extension does not represent the same role as the device validating > the certificate. For instance, a WTP MUST NOT accept a certificate > whose NetscapeComment field is set to "CAPWAP WTP Device > Certificate". > > The contents of the certificate will be encoded based > on the rules defined in the X.509 specification. > > 11.10.23. IEEE 802.11 WTP Radio Configuration > > The WTP WLAN radio configuration is used by the AC to configure a > Radio on the WTP, and by the WTP to deliver its radio configuration > to the AC. The message element value contains the > following fields: > > 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Radio ID | Reserved | Num of BSSIDs | > DTIM Period | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BSSID > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BSSID | Beacon Period > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Country Code > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: 1046 for IEEE 802.11 WTP WLAN Radio Configuration > > [...] > > Country Code: This attribute identifies the country in which the > station is operating. The value of this field comes > from the IEEE > 802.11 dot11CountryString MIB element (see [6]). Special > attention is required with use of this field, as implementations > which take action based on this field could violate regulatory > requirements. Some regulatory bodies do permit configuration of > the country code under certain restrictions, such as > the FCC, when > WTPs are certified as Software Defined Radios. > > The WTP and AC may ignore the value of this field, > depending upon > regulatory requirements, for example to avoid > classification as a > Software Defined Radio. When this field is used, the first two > octets of this string is the two character country code as > described in document ISO/IEC 3166- 1, and the third octet MUST > have the value 1, 2 or 3 as defined below. When the > value of the > third octet is 255, the country code field is not used, and MUST > be ignored. > > 1 an ASCII space character, if the regulations under which the > station is operating encompass all environments in > the country, > > 2 an ASCII 'O' character, if the regulations under which the > station is operating are for an outdoor environment only, or > > 3 an ASCII 'I' character, if the regulations under which the > station is operating are for an indoor environment only > > 255 Country Code field is not used; ignore the field. > > It is not appropriate to change the format of this > string as this is defined in the IEEE 802.11 specification. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > 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 Sep 05 12:27:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdlm-0001fC-7m for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:27:26 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKdlk-0001fD-Oh for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:27:26 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id CA8AE431230 for ; Tue, 5 Sep 2006 09:27:20 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1E017430083 for ; Tue, 5 Sep 2006 09:21:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D287C43121E for ; Tue, 5 Sep 2006 09:21:48 -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 15AE2431219 for ; Tue, 5 Sep 2006 09:21:42 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 05 Sep 2006 09:21:43 -0700 X-IronPort-AV: i="4.08,215,1154934000"; d="scan'208"; a="339738899:sNHT31923616" 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.20060308/8.12.11) with ESMTP id k85GLg7f001936 for ; Tue, 5 Sep 2006 09:21:42 -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 k85GLgYr022363 for ; Tue, 5 Sep 2006 09:21:42 -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); Tue, 5 Sep 2006 09:21:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Sep 2006 09:21:41 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2026C4BA4@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 185: WTP Fallback isn't well defined, and should be removed. Thread-Index: AcbCFu+rQUsfZXhIRNeprMoJCmLq7wO8GYWw From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 05 Sep 2006 16:21:41.0944 (UTC) FILETIME=[5F3CE380:01C6D107] 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-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] Issue 185: WTP Fallback isn't well defined, and should be removed. 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: e8a67952aa972b528dd04570d58ad8fe Given the lack of response, I will reject the issue. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, August 17, 2006 9:05 AM > To: Capwap@frascone.com > Subject: [Capwap] Issue 185: WTP Fallback isn't well > defined,and should be removed. > > The issue currently states that because the message element > is not sufficient defined, we need to remove it from the > protocol. I disagree on both counts. I am including the text > from the specification, and would ask for further > clarification from Dave on what he believes is not > sufficiently described. > > 4.4.35. WTP Fallback > > The WTP Fallback message element is sent by the AC to the WTP to > enable or disable automatic CAPWAP fallback in the event that a WTP > detects its preferred AC, and is not currently connected to it. > > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | Mode | > +-+-+-+-+-+-+-+-+ > > Type: 35 for WTP Fallback > > Length: 1 > > Mode: The 8-bit value indicates the status of automatic CAPWAP > fallback on the WTP. A value of zero disables fallback, while a > value of one enables it. When enabled, if the WTP detects that > its primary AC is available, and it is not connected to it, it > SHOULD automatically disconnect from its current AC and > reconnect > to its primary. If disabled, the WTP will only reconnect to its > primary through manual intervention (e.g., through the Reset > Request command). > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > 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 Sep 05 12:29:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdnN-0001xr-VH for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:29:05 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKdnM-0001rO-Gj for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:29:05 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 0A6BF431213 for ; Tue, 5 Sep 2006 09:29:01 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id A63C3430083 for ; Tue, 5 Sep 2006 09:23:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CA9E64311EE for ; Tue, 5 Sep 2006 09:23:22 -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 94AF043121E for ; Tue, 5 Sep 2006 09:23:19 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 05 Sep 2006 09:23:19 -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.20060308/8.12.11) with ESMTP id k85GNJXL004022 for ; Tue, 5 Sep 2006 09:23:19 -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 k85GNIYp023614 for ; Tue, 5 Sep 2006 09:23:18 -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); Tue, 5 Sep 2006 09:23:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Sep 2006 09:23:18 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2026C4BA8@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 165: The Discovery Response is broken Thread-Index: AcbCHKOdjMxCOoKiTcKM+A6KpKSVrwO6uzqg From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 05 Sep 2006 16:23:18.0836 (UTC) FILETIME=[98FD6F40:01C6D107] 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-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] Issue 165: The Discovery Response is broken 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: 4adaf050708fb13be3316a9eee889caa Given the lack of activity on this issue, I am going to reject the issue. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, August 17, 2006 9:46 AM > To: Capwap@frascone.com > Subject: [Capwap] Issue 165: The Discovery Response is broken > > The Discovery Response is broken. The AC SHOULD NOT be > providing any info to a WTP (or something that claims to be a > WTP). Also, the AC should tell the WTP what to do next, with > choices: 1) Ok to try to join, > 2) don't try to join, 3) try discover on a list of returned ACs) > > I don't believe there is an issue with sending the AC's > information to the WTP, but would solicit input from the > list. That said, some of the information in the AC Descriptor > is required, such as the current load on the AC. No point is > trying to join if he AC indicates it's already at max > capacity. I believe if the AC does not return the response, > then it implies (2). Otherwise, it is (1). > (3) is handled during the join or configure > > I therefore propose rejecting this issue. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > 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 Sep 05 12:30:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdou-0002C1-Jz for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:30:40 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKdot-00029B-5I for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:30:40 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id A257543124C for ; Tue, 5 Sep 2006 09:30:35 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A4B02430083 for ; Tue, 5 Sep 2006 09:24:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9610C398035 for ; Tue, 5 Sep 2006 09:24:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id B217039808E for ; Tue, 5 Sep 2006 09:24:22 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 05 Sep 2006 09:24:22 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k85GOM81021369 for ; Tue, 5 Sep 2006 09:24:22 -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 k85GOIQd009246 for ; Tue, 5 Sep 2006 09:24:22 -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); Tue, 5 Sep 2006 09:24:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Sep 2006 09:24:19 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2026C4BAB@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 180: Too many configuration messages need to bespecified here Thread-Index: AcbCIbKeF3joZwJJQXy0gPmWqGWyUwO5gRBQ From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 05 Sep 2006 16:24:20.0501 (UTC) FILETIME=[BDBEC450:01C6D107] 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 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] Issue 180: Too many configuration messages need to bespecified here 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: e1e48a527f609d1be2bc8d8a70eb76cb Given the lack of interest in this issue, I am rejecting the issue Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, August 17, 2006 10:22 AM > To: Capwap@frascone.com > Subject: [Capwap] Issue 180: Too many configuration messages > need to bespecified here > > There seems like an awful lot of additional configuration > message elements that need to be specified here! > > Having built a protocol (and WiFi certified product) > based on this, it's not clear to me what's missing. I think > it would be useful if you provided concrete details on what's > missing. > > I propose rejecting this comment unless I received specific > change requests. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > 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 Sep 05 12:33:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdrq-0003zr-OG for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:33:43 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKdrp-0002Sb-79 for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:33:42 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id B4EFC431247 for ; Tue, 5 Sep 2006 09:33:37 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7D643430083 for ; Tue, 5 Sep 2006 09:25:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 568323980B0 for ; Tue, 5 Sep 2006 09:25:28 -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 AA1EC3980B2 for ; Tue, 5 Sep 2006 09:25:12 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 05 Sep 2006 09:25:13 -0700 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.20060308/8.12.11) with ESMTP id k85GPCd6016184 for ; Tue, 5 Sep 2006 09:25:12 -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 k85GPC1E011939 for ; Tue, 5 Sep 2006 09:25:12 -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); Tue, 5 Sep 2006 09:25:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Sep 2006 09:25:11 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2026C4BAC@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 202: Multiple stations in a single Mobile ConfigRequest Thread-Index: AcbCJq1UWjM/yNsCSB6gq3gYwjKShAO4SV8Q From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 05 Sep 2006 16:25:12.0099 (UTC) FILETIME=[DC7FFF30:01C6D107] 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 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] Issue 202: Multiple stations in a single Mobile ConfigRequest 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: fb6060cb60c0cea16e3f7219e40a0a81 Given no response, I am assuming the group is comfortable with the proposed text. Closing the issue. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, August 17, 2006 10:58 AM > To: Capwap@frascone.com > Subject: [Capwap] Issue 202: Multiple stations in a single > Mobile ConfigRequest > > 59) it doesn't say if one message can be used to update more > than one STA. It should be able. > 60) IEEE 802.11 Mobile. shouldn't the STA MAC address be > included so this message element can be matched with a > (4.4.8)Add Mobile message element? > > Dave was correct that all of the other message elements > had a MAC address field, which would allow for having > multiple mobile state being added within a single Mobile > Config Request message. > > By adding a MAC address to the IEEE 802.11 Mobile message > element, it is now possible for the AC to send a single > message for multiple stations (or whatever we end up wanting > to call them). So I have made the following simple change: > > > x.x IEEE 802.11 Station > [...] > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Radio ID | Association ID | Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MAC Address > | <== > NEW > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MAC Address | Capabilities | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | WLAN ID |Supported Rates| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Note that practically, I'm not sure this feature would be > used very often, as it would also require the AC to cache > requests to combine them at a later date. However, it does > create consistency in ensuring that all of the message > elements have the mac address field. > > comments? > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > 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 Sep 05 12:35:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdtd-0004CT-AY for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:35:33 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKdtb-0002Zy-RY for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:35:33 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 5641D431251 for ; Tue, 5 Sep 2006 09:35:28 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 5C7C1430083 for ; Tue, 5 Sep 2006 09:26:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2BF494311E2 for ; Tue, 5 Sep 2006 09:26:50 -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 94444431229 for ; Tue, 5 Sep 2006 09:26:46 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 05 Sep 2006 09:26:47 -0700 X-IronPort-AV: i="4.08,215,1154934000"; d="scan'208"; a="339740578:sNHT31487800" 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.20060308/8.12.11) with ESMTP id k85GQkZi024625 for ; Tue, 5 Sep 2006 09:26:46 -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 k85GQj1E013135 for ; Tue, 5 Sep 2006 09:26:46 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Sep 2006 09:26:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Sep 2006 09:26:45 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2026C4BAE@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 195: Mobile config request needs more detail Thread-Index: AcbCJrUMKQIrX8DATG2s1/3fukUY1QO4Vc9Q From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 05 Sep 2006 16:26:45.0824 (UTC) FILETIME=[145D4C00:01C6D108] 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: Subject: Re: [Capwap] Issue 195: Mobile config request needs more detail 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: 7aafa0432175920a4b3e118e16c5cb64 Given the lack of interest in this issue, I am rejecting it. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, August 17, 2006 10:58 AM > To: Capwap@frascone.com > Subject: [Capwap] Issue 195: Mobile config request needs more detail > > There are two parts to this issue, and my belief is that they > are completely separate. So I will take comment 59) and 60) > (below) and create a new issue, called "Multiple stations in > a single Mobile Config Request". > > 58) Mobile Config Request. the actual details of how this > works on both splitMAC and especially localMAC are not well > specified. That is, only the figures and text in sections > 11.1.1 and 11.1.2 provide any clue as to events that would > cause an AC to send this message type. Also, there are > restrictions on combinations of parameters that can be > included in the message. > > I wonder whether other folks agree that more details > are required. > I am unsure what "restrictions" you are talking about here, > so I would need further clarification on your comment. > > > 59) it doesn't say if one message can be used to update more > than one STA. It should be able. > 60) IEEE 802.11 Mobile. shouldn't the STA MAC address be > included so this message element can be matched with a > (4.4.8)Add Mobile message element? > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > 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 Sep 05 12:37:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdvL-0004Ru-Kb for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:37:19 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKdvK-0002hF-4y for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:37:19 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id A082A4312AB for ; Tue, 5 Sep 2006 09:37:14 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 5820D430083 for ; Tue, 5 Sep 2006 09:28:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3B0B6431240 for ; Tue, 5 Sep 2006 09:28:03 -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 5932A431122 for ; Tue, 5 Sep 2006 09:27:57 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 05 Sep 2006 09:27:57 -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 k85GRvVl019851 for ; Tue, 5 Sep 2006 09:27:57 -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 k85GRvQV012221 for ; Tue, 5 Sep 2006 09:27:57 -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); Tue, 5 Sep 2006 09:27:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Sep 2006 09:27:56 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2026C4BB1@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 151: Are all specified message elements required? Thread-Index: AcbCKJHsPEBQXbBdS6ulJHUIkPZ7bgO36XNw From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 05 Sep 2006 16:27:57.0307 (UTC) FILETIME=[3EF8BCB0:01C6D108] 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] Issue 151: Are all specified message elements required? 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 Given the lack of interest in this issue, I am marking it as rejected. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, August 17, 2006 11:12 AM > To: Capwap@frascone.com > Subject: [Capwap] Issue 151: Are all specified message > elements required? > > Are all specified message elements required? (The obvious > answer is "yes", but this document doesn't discuss > versioning. For example, what if in a new version of CAPWAP > an additional message element was to be added. Would a new > message type be created and the additional message element > added to it, or the existing type reused?) > > This is a great question. In the Diameter protocol we > dealt with this issue by including a "Mandatory to implement" > bit. If any AVP was received, whose bit was set, yet was not > recognized, then the request had to be rejected. > > We could consider something similar here, but I believe with > the firmware download component of the protocol it may be > less of an issue - although not guaranteed. I would hope (and > expect) that as the CAPWAP protocol extends, the AC would > push new firmware to the WTP. This does require that the > initial part of the state machine be fairly static, and this > could be an area where the "Mandatory to implement" bit could > be useful as it would allow the AC to fall back to older > protocol behavior. > > That said, I know that my company has made significant > improvments to the orignally proposed protocol, and this has > never been an issue. > > Thoughts? Is this a mandatory feature, or a nice to have? I'd > reluctant to add nice to have features at this point. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > 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 Sep 05 12:39:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdxQ-0005UO-5a for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:39:28 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKdxO-0002vO-N9 for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:39:28 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 230984311FC for ; Tue, 5 Sep 2006 09:39:23 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E2E91430083 for ; Tue, 5 Sep 2006 09:28:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D744E39809C for ; Tue, 5 Sep 2006 09:28:43 -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 639E1398092 for ; Tue, 5 Sep 2006 09:28:42 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 05 Sep 2006 09:28:43 -0700 X-IronPort-AV: i="4.08,215,1154934000"; d="scan'208"; a="339741331:sNHT30706722" 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.20060308/8.12.11) with ESMTP id k85GSgqn011223 for ; Tue, 5 Sep 2006 09:28:42 -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 k85GSfYr027909 for ; Tue, 5 Sep 2006 09:28:41 -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); Tue, 5 Sep 2006 09:28:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Sep 2006 09:28:41 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2026C4BB2@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 164: Are the values in WTP Frame Encryption acapabilities bit, or enum Thread-Index: AcbCKRHPUA5NdCLQQ/KKBA4kiIzTVwO30Bkw From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 05 Sep 2006 16:28:41.0749 (UTC) FILETIME=[59760C50:01C6D108] 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: Subject: Re: [Capwap] Issue 164: Are the values in WTP Frame Encryption acapabilities bit, or enum 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: 52e1467c2184c31006318542db5614d5 Given the lack of interest on this issue, marking it as rejected. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, August 17, 2006 11:15 AM > To: Capwap@frascone.com > Subject: [Capwap] Issue 164: Are the values in WTP Frame > Encryption acapabilities bit, or enum > > Are the values in the WTP Frame Encryption a capabilities > bit, or an enum? > > Looks like an enum to me. Not sure what Dave would > prefer the text to read. Propose Rejecting this comment. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > 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 Sep 05 12:41:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdzG-0006MZ-4C for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:41:22 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKdzE-000363-M5 for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:41:22 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id DB32A4311F5 for ; Tue, 5 Sep 2006 09:41:16 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 36DB1430083 for ; Tue, 5 Sep 2006 09:34:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 218D043127A for ; Tue, 5 Sep 2006 09:34:56 -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 39FC2431280 for ; Tue, 5 Sep 2006 09:34:54 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 05 Sep 2006 09:34:55 -0700 X-IronPort-AV: i="4.08,215,1154934000"; d="scan'208"; a="339743624:sNHT35532276" 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.20060308/8.12.11) with ESMTP id k85GYrVX020236 for ; Tue, 5 Sep 2006 09:34:53 -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 k85GYnZR003287 for ; Tue, 5 Sep 2006 09:34:53 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Sep 2006 09:34:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Sep 2006 09:34:52 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2026C4BBC@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcbRCTZk7ep2BkiSSpeFYGmbNXDZEw== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 05 Sep 2006 16:34:53.0114 (UTC) FILETIME=[36CFD9A0:01C6D109] 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-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.9 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, MISSING_SUBJECT, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: [Capwap] (no subject) 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: 79899194edc4f33a41f49410777972f8 Following up on this issue, the proposed change would be to qualify the term data frame to IEEE 802.11 data frame, so the resulting text would end up being: o All IEEE 802.11 client data frames are tunneled between the WTP and the AC. Note that the WTP is responsible for encrypting and decrypting frames, if it was indicated in the Add Station request. Comments? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ 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 Sep 05 12:42:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKe0M-0006XQ-0u for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:42:30 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKe0K-0003B4-IJ for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:42:30 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 11A2D4312BA for ; Tue, 5 Sep 2006 09:42:25 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 66DB3430083 for ; Tue, 5 Sep 2006 09:36:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 590E1398035 for ; Tue, 5 Sep 2006 09:36:52 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id 07116398045 for ; Tue, 5 Sep 2006 09:36:49 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 05 Sep 2006 09:36:49 -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.20060308/8.12.11) with ESMTP id k85Gan38022943 for ; Tue, 5 Sep 2006 09:36:49 -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 k85GanYp005175 for ; Tue, 5 Sep 2006 09:36:49 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Sep 2006 09:36:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Sep 2006 09:36:48 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2026C4BC0@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 213: Make it clearer that MAC management frames are capwap data Thread-Index: AcbRCXvghJ11TmSIQw6MsNRfWm1TQw== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 05 Sep 2006 16:36:49.0597 (UTC) FILETIME=[7C3DBED0:01C6D109] 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: Subject: [Capwap] Issue 213: Make it clearer that MAC management frames are capwap data 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: 9182cfff02fae4f1b6e9349e01d62f32 11.4. Technology Specific Bindings All CAPWAP transports have the following IEEE 802.11 specific bindings: Payload encapsulation: The CAPWAP protocol defines the CAPWAP data frame, which is used to encapsulate a wireless payload. For IEEE 802.11, the IEEE 802.11 header and payload are encapsulated (excluding the IEEE 802.11 FCS checksum). Note that both the 802.11 MAC Management frames, as well as the 802.11 Data frames are included in the CAPWAP payload field. The IEEE 802.11 FCS checksum is handled by the WTP. This allows the WTP to validate a frame prior to sending it to the AC. Similarly, when an AC wishes to transmit a frame towards a station, the WTP computes and adds the FCS checksum. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ 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 Sep 05 12:43:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKe1S-0006kg-1o for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:43:38 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKe1Q-0003ES-9I for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:43:38 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id D46CF431276 for ; Tue, 5 Sep 2006 09:43:32 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 298A5430083 for ; Tue, 5 Sep 2006 09:37:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 093BC4312BA for ; Tue, 5 Sep 2006 09:37: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 4716843129F for ; Tue, 5 Sep 2006 09:37:22 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 05 Sep 2006 09:37:23 -0700 X-IronPort-AV: i="4.08,215,1154934000"; d="scan'208"; a="339744339:sNHT30710016" 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.20060308/8.12.11) with ESMTP id k85GbLk9023639 for ; Tue, 5 Sep 2006 09:37:21 -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 k85GbLYp005622 for ; Tue, 5 Sep 2006 09:37:21 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Sep 2006 09:37:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Sep 2006 09:37:20 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2026C4BC2@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 210: Clarity required on Client Data Frame Thread-Index: AcbRCTZk7ep2BkiSSpeFYGmbNXDZEwAAEsRQ From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 05 Sep 2006 16:37:21.0534 (UTC) FILETIME=[8F46F1E0:01C6D109] 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-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: [Capwap] Issue 210: Clarity required on Client Data Frame 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: 52e1467c2184c31006318542db5614d5 Sorry, forgot to include the subject Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Tuesday, September 05, 2006 9:35 AM > To: Capwap@frascone.com > Subject: > > Following up on this issue, the proposed change would be to > qualify the term data frame to IEEE 802.11 data frame, so the > resulting text would end up being: > > > o All IEEE 802.11 client data frames are tunneled between > the WTP and the AC. > Note that the WTP is responsible for encrypting and decrypting > frames, if it was indicated in the Add Station request. > > Comments? > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > _________________________________________________________________ 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 Sep 05 12:46:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKe4f-0007bX-EF for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:46:57 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKe4e-0003e2-0O for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:46:57 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 685954303F2 for ; Tue, 5 Sep 2006 09:46:52 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 89E9F430083 for ; Tue, 5 Sep 2006 09:40:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4BC0D398035 for ; Tue, 5 Sep 2006 09:40:29 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id F0C0139809C for ; Tue, 5 Sep 2006 09:40:24 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 05 Sep 2006 09:40:24 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k85GeOkg023687 for ; Tue, 5 Sep 2006 09:40:24 -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 k85GeOQV023894 for ; Tue, 5 Sep 2006 09:40:24 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Sep 2006 09:40:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Sep 2006 09:40:23 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2026C4BC6@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 215: Consistency in capwap header references Thread-Index: AcbRCfvNWZUN0wtxRCSObv9jrfJShw== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 05 Sep 2006 16:40:24.0361 (UTC) FILETIME=[FC402190:01C6D109] Authentication-Results: sj-dkim-3.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: Subject: [Capwap] Issue 215: Consistency in capwap header references 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: 08170828343bcf1325e4a0fb4584481c I have made the non-controversial change from "CAPWAP Transport Header" to "CAPWAP Header". The document was inconsistent as it was referenced in both ways across the document. Assuming no issues, I will mark as closed. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ 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 Sep 05 12:48:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKe66-0008Lm-Cd for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:48:26 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKe64-0003lb-Tj for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 12:48:26 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 6CEBA430EC0 for ; Tue, 5 Sep 2006 09:48:21 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 49858430083 for ; Tue, 5 Sep 2006 09:43:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3504E398045 for ; Tue, 5 Sep 2006 09:43:15 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7987C398035 for ; Tue, 5 Sep 2006 09:43:07 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 05 Sep 2006 09:42:51 -0700 X-IronPort-AV: i="4.08,215,1154934000"; d="scan'208"; a="317740830:sNHT6466578560" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k85GgoS9022239 for ; Tue, 5 Sep 2006 09:42:50 -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 k85Ggow7013701 for ; Tue, 5 Sep 2006 09:42:50 -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); Tue, 5 Sep 2006 09:42:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Sep 2006 09:42:42 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2026C4BC9@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 213: Make it clearer that MAC management frames are capwap data Thread-Index: AcbRCXvghJ11TmSIQw6MsNRfWm1TQwAAMRiw From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 05 Sep 2006 16:42:50.0243 (UTC) FILETIME=[5333F530:01C6D10A] Authentication-Results: sj-dkim-5.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: Subject: Re: [Capwap] Issue 213: Make it clearer that MAC management frames are capwap data 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: 769a46790fb42fbb0b0cc700c82f7081 Not sure what's going on with me today. I should have noted that the text below is revised to address this comment. My apologies. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Tuesday, September 05, 2006 9:37 AM > To: Capwap@frascone.com > Subject: Issue 213: Make it clearer that MAC management > frames are capwap data > > 11.4. Technology Specific Bindings > > All CAPWAP transports have the following IEEE 802.11 specific > bindings: > > Payload encapsulation: The CAPWAP protocol defines the CAPWAP data > frame, which is used to encapsulate a wireless payload. > For IEEE > 802.11, the IEEE 802.11 header and payload are encapsulated > (excluding the IEEE 802.11 FCS checksum). Note that both the > 802.11 MAC Management frames, as well as the 802.11 Data frames > are included in the CAPWAP payload field. The IEEE 802.11 FCS > checksum is handled by the WTP. This allows the WTP to > validate a > frame prior to sending it to the AC. Similarly, when > an AC wishes > to transmit a frame towards a station, the WTP computes and adds > the FCS checksum. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > _________________________________________________________________ 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 Sep 05 13:38:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKesO-0001Hq-CG for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 13:38:20 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKelI-0002ky-Q3 for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 13:31:02 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7B9E539809E for ; Tue, 5 Sep 2006 10:30:51 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 62B77430083 for ; Tue, 5 Sep 2006 10:29:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 52410398034 for ; Tue, 5 Sep 2006 10:29:42 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by zoidberg.tigertech.net (Postfix) with ESMTP id 08F5D398024 for ; Tue, 5 Sep 2006 10:29:39 -0700 (PDT) Message-ID: <01a601c6d110$eef45630$626015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Pat Calhoun (pacalhou)" , References: <4FF84B0BC277FF45AA27FE969DD956A2026C45F4@xmb-sjc-235.amer.cisco.com> Date: Tue, 5 Sep 2006 10:30:08 -0700 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=3.076 tagged_above=-999 required=7 tests=MSGID_DOLLARS X-Spam-Level: *** Subject: Re: [Capwap] Next Draft editorship process 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: 21c69d3cfc2dd19218717dbe1d974352 This plan sounds fine to me. I think it will help advance the goal of achieving closure on the documents by next June. jak ----- Original Message ----- From: "Pat Calhoun (pacalhou)" To: Sent: Friday, September 01, 2006 9:01 AM Subject: [Capwap] Next Draft editorship process > All, > > During our editor call this morning, the editors agreed to the following > process. We will continue to address new issues until 9/29. In order to > meet our agreed upon milestones, we believe it is important to balance > issue discussion with timely closure. Therefore, when we propose an > resolution for an issue, we will provide the list with two weeks to > respond, after which we will close the issue based on rough consensus. > No responses to an issue assumes consensus - regardless of the proposed > action. Of course, any contentious issues, for which debates are still > ongoing, have no consensus, and will not fall under this rule. > > As part of this editor cycle, we plan to split up the draft into two; > base and 802.11 binding. The former will be labelled -03 and the latter > -00. Given we have a -00 draft, and we wish to post both drafts at the > same time, we will use the -00 deadlines, which is 10/16. Our plan is to > submit both drafts on 10/13. > > Thanks, > > Pat, Mike and Dorothy > _________________________________________________________________ > 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 Sep 05 18:56:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKjqb-00088J-VG for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 18:56:49 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKjqa-0005Il-2A for capwap-archive@lists.ietf.org; Tue, 05 Sep 2006 18:56:49 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id EB311431868 for ; Tue, 5 Sep 2006 15:56:34 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1C2284300CD for ; Tue, 5 Sep 2006 15:48:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EFCC5431851 for ; Tue, 5 Sep 2006 15:48:53 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by hermes.tigertech.net (Postfix) with ESMTP id EA80D431848 for ; Tue, 5 Sep 2006 15:48:50 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so82261nfb for ; Tue, 05 Sep 2006 15:48:49 -0700 (PDT) Received: by 10.48.242.19 with SMTP id p19mr65522nfh; Tue, 05 Sep 2006 15:48:48 -0700 (PDT) Received: by 10.49.42.3 with HTTP; Tue, 5 Sep 2006 15:48:47 -0700 (PDT) Message-ID: <5bfe7a820609051548t14e6a6e6sf09687d7a740b084@mail.gmail.com> Date: Tue, 5 Sep 2006 15:48:47 -0700 From: "Dorothy Stanley" To: "David T. Perkins" In-Reply-To: MIME-Version: 1.0 References: <5bfe7a820609010735j2a41d20dte688d6d3f90cfe4d@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=1.0 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: Capwap@frascone.com Subject: Re: [Capwap] Issue 161: Ther term "Mobile" is not really accurate 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="===============0935925689==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 --===============0935925689== Content-Type: multipart/alternative; boundary="----=_Part_165594_6106141.1157496527511" ------=_Part_165594_6106141.1157496527511 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi David, all, I am fine with using either - Mobile Unit (MU) - a general term, describing the unit rather than any interfaces, and attributing the quality of mobility to the unit - Wireless End Device - a general term, attributing the characteristic of having a wireless interface of the type of interest to CAPWAP, but not necessarily having the quality of mobility. Could also be Wireless End Unit. True, there may be multiple interfaces on the device. From the perspective of CAPWAP, we are interested in devices that support a wireless interface of interest. Mobile Station - is close to what we have; the term "station" is overloaded with 802.11 usage, potential confusion. Mobile Node - prefer Mobile Unit, as "unit" connotes a device, "node" is more general Mobile Equipment - No particular benefit over Mobile unit User Equipment - applicable to cellular networks, not as applicable to e.g. RFID Dorothy On 9/1/06, David T. Perkins wrote: > > HI, > > All good points. One issue is that we are really talking about > interfaces. A good many number of devices that have a network > interface may have a single network interface, and that interface > can be be used to characterize the device as a Wireless end device. > However, other devices may have other network interfaces that > are not wireless. > > Regards, > /david t. perkins > > On Fri, 1 Sep 2006, Dorothy Stanley wrote: > > > Pat, all, > > > > How about > > > > Wireless End Device (WED)? It captures the essential nature of the end > > device: "wireless", and > > it is not wireless-type specific. > > > > It is better than > > > > Station (an 802.11 term with specific meaning in .11 as Bob points out) > > Mobile - since the end device may be but is not required to be able to > move, > > as noted by David > > Wireless End Point (WEP) - problematic in many ways..... > > Mobile Unit (MU) - again, the endpoint need not move. This would be my > > second choice though, as it is more specific than just "mobile". > > > > Dorothy > > > > On 8/31/06, Pat Calhoun (pacalhou) wrote: > > > > > > Folks, I need a term. > > > > > > I don't care if it's foobar, but need something everyone will agree > to. > > > If station doesn't cut it, as bob insists, then I need something to > work > > > it. > > > > > > Help, > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit > > > Cisco Systems > > > > > > > > > > > > > -----Original Message----- > > > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > > > Sent: Sunday, August 20, 2006 12:03 PM > > > > To: Bob O'Hara (boohara) > > > > Cc: Pat Calhoun (pacalhou); Capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 161: Ther term "Mobile" is not > > > > really accurate > > > > > > > > HI, > > > > > > > > Bob can you suggest an appropriate term to use here. The term > > > > "mobile" has dictionary meaning of moving. However, being > > > > capable of moving is not the fundamental defining attribute > > > > of the interface that differentiates from other technologies. > > > > > > > > Regards, > > > > /david t. perkins > > > > > > > > > > > > On Wed, 16 Aug 2006, Bob O'Hara (boohara) wrote: > > > > > STOP! Put that editor down and step away from the draft! > > > > I think it > > > > > is a big mistake to embed a term that is tied to a single > > > > binding into > > > > > the entirety of the draft. > > > > > > > > > > -Bob > > > > > > > > > > -----Original Message----- > > > > > From: Pat Calhoun (pacalhou) > > > > > Sent: Tuesday, August 15, 2006 6:04 PM > > > > > To: Capwap@frascone.com > > > > > Subject: [Capwap] Issue 161: Ther term "Mobile" is not > > > > really accurate > > > > > > > > > > The term "mobile" is not really accurate when describing wireless > > > > > interfaces, since wireless does not imply mobile. Can we > > > > just use the > > > > > techie term "STA" instead. > > > > > > > > > > In my honest opinion, this is one of those change > > > > requests that > > > > > is really unnecessary. Traditionally, the IETF has used the term > > > > > mobile (e.g., mobile station in Mobile IP). However, given the > > > > > comment, and the fact that the > > > > > 802.11 WG uses the term station, or STA for short, I will > > > > go ahead and > > > > > make the change. Of course, the next binding technology may end up > > > > > using different terminology (including mobile). > > > > > > > > > > This will, of course, touch nearly every section of the > > > > specification > > > > > (read: diffs will be more complex). > > > > > > > > > > Pat Calhoun > > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > _________________________________________________________________ > > > > > 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 > > > > > > > ------=_Part_165594_6106141.1157496527511 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi David, all,

I am fine with using either

- Mobile Unit (MU) - a general term, describing the unit rather than any interfaces, and
attributing the quality of mobility to the unit
- Wireless End Device - a general term, attributing the characteristic of having a
wireless interface of the type of interest to CAPWAP, but not necessarily having the
quality of mobility. Could also be Wireless End Unit.


True, there may be multiple interfaces on the device. From the perspective of
CAPWAP, we are interested in devices that support a wireless interface of interest.

Mobile Station - is close to what we have; the term "station" is overloaded with
802.11 usage, potential confusion.
Mobile Node - prefer Mobile Unit, as "unit" connotes a device, "node" is more general
Mobile Equipment - No particular benefit over Mobile unit
User Equipment - applicable to cellular networks, not as applicable to e.g. RFID

Dorothy

On 9/1/06, David T. Perkins <dperkins@dsperkins.com> wrote:
HI,

All good points. One issue is that we are really talking about
interfaces. A good many number of devices that have a network
interface may have a single network interface, and that interface
can be be used to characterize the device as a Wireless end device.
However, other devices may have other network interfaces that
are not wireless.

Regards,
/david t. perkins

On Fri, 1 Sep 2006, Dorothy Stanley wrote:

> Pat, all,
>
> How about
>
> Wireless End Device (WED)? It captures the essential nature of the end
> device: "wireless", and
> it is not wireless-type specific.
>
> It is better than
>
> Station (an 802.11 term with specific meaning in .11 as Bob points out)
> Mobile - since the end device may be but is not required to be able to move,
> as noted by David
> Wireless End Point (WEP) -  problematic in many ways.....
> Mobile Unit  (MU) - again, the endpoint need not move. This would be my
> second choice though, as it is more specific than just "mobile".
>
> Dorothy
>
> On 8/31/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com> wrote:
> >
> > Folks, I need a term.
> >
> > I don't care if it's foobar, but need something everyone will agree to.
> > If station doesn't cut it, as bob insists, then I need something to work
> > it.
> >
> > Help,
> >
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit
> > Cisco Systems
> >
> >
> >
> > > -----Original Message-----
> > > From: David T. Perkins [mailto:dperkins@dsperkins.com]
> > > Sent: Sunday, August 20, 2006 12:03 PM
> > > To: Bob O'Hara (boohara)
> > > Cc: Pat Calhoun (pacalhou); Capwap@frascone.com
> > > Subject: Re: [Capwap] Issue 161: Ther term "Mobile" is not
> > > really accurate
> > >
> > > HI,
> > >
> > > Bob can you suggest an appropriate term to use here. The term
> > > "mobile" has dictionary meaning of moving. However, being
> > > capable of moving is not the fundamental defining attribute
> > > of the interface that differentiates from other technologies.
> > >
> > > Regards,
> > > /david t. perkins
> > >
> > >
> > > On Wed, 16 Aug 2006, Bob O'Hara (boohara) wrote:
> > > > STOP!  Put that editor down and step away from the draft!
> > > I think it
> > > > is a big mistake to embed a term that is tied to a single
> > > binding into
> > > > the entirety of the draft.
> > > >
> > > >  -Bob
> > > >
> > > > -----Original Message-----
> > > > From: Pat Calhoun (pacalhou)
> > > > Sent: Tuesday, August 15, 2006 6:04 PM
> > > > To: Capwap@frascone.com
> > > > Subject: [Capwap] Issue 161: Ther term "Mobile" is not
> > > really accurate
> > > >
> > > > The term "mobile" is not really accurate when describing wireless
> > > > interfaces, since wireless does not imply mobile. Can we
> > > just use the
> > > > techie term "STA" instead.
> > > >
> > > > <PRC> In my honest opinion, this is one of those change
> > > requests that
> > > > is really unnecessary. Traditionally, the IETF has used the term
> > > > mobile (e.g., mobile station in Mobile IP). However, given the
> > > > comment, and the fact that the
> > > > 802.11 WG uses the term station, or STA for short, I will
> > > go ahead and
> > > > make the change. Of course, the next binding technology may end up
> > > > using different terminology (including mobile).
> > > >
> > > > This will, of course, touch nearly every section of the
> > > specification
> > > > (read: diffs will be more complex).
> > > >
> > > > Pat Calhoun
> > > > CTO, Wireless Networking Business Unit Cisco Systems
> > > > _________________________________________________________________
> > > > 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
> >
>


------=_Part_165594_6106141.1157496527511-- --===============0935925689== 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 --===============0935925689==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Sep 06 16:38:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL4AL-0005as-6u for capwap-archive@lists.ietf.org; Wed, 06 Sep 2006 16:38:33 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL4AI-0008CX-7Q for capwap-archive@lists.ietf.org; Wed, 06 Sep 2006 16:38:33 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0762439808A for ; Wed, 6 Sep 2006 13:38:28 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8AF1843005A for ; Wed, 6 Sep 2006 13:34:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6EA8C144801F for ; Wed, 6 Sep 2006 13:34:53 -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 E060C1448004 for ; Wed, 6 Sep 2006 13:34:45 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so3208337pyu for ; Wed, 06 Sep 2006 13:34:44 -0700 (PDT) Received: by 10.35.78.9 with SMTP id f9mr15445502pyl; Wed, 06 Sep 2006 13:34:44 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Wed, 6 Sep 2006 13:34:44 -0700 (PDT) Message-ID: <26140d940609061334q348cac12h815507717b221724@mail.gmail.com> Date: Wed, 6 Sep 2006 16:34:44 -0400 From: "Michael Montemurro" To: "Dorothy Stanley" In-Reply-To: <5bfe7a820609051548t14e6a6e6sf09687d7a740b084@mail.gmail.com> MIME-Version: 1.0 References: <5bfe7a820609010735j2a41d20dte688d6d3f90cfe4d@mail.gmail.com> <5bfe7a820609051548t14e6a6e6sf09687d7a740b084@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.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: Capwap@frascone.com Subject: Re: [Capwap] Issue 161: Ther term "Mobile" is not really accurate 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="===============0782857022==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 --===============0782857022== Content-Type: multipart/alternative; boundary="----=_Part_15288_11180767.1157574884563" ------=_Part_15288_11180767.1157574884563 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline >From what I remember (and have heard), the term Mobile Unit was used in IEEE 802.11 in the beginnings of the standard to refer to a WLAN device that transitions between AP's. Given that one of the main features of CAPWAP is mobility, it sounds that it would be appropriate to use that term. Then again, that term did not make it into the IEEE 802.11 standard. Wireless End Device sounds cumbersome to me. Cheers, Mike On 9/5/06, Dorothy Stanley wrote: > > Hi David, all, > > I am fine with using either > > - Mobile Unit (MU) - a general term, describing the unit rather than any > interfaces, and > attributing the quality of mobility to the unit > - Wireless End Device - a general term, attributing the characteristic of > having a > wireless interface of the type of interest to CAPWAP, but not necessarily > having the > quality of mobility. Could also be Wireless End Unit. > > > True, there may be multiple interfaces on the device. From the perspective > of > CAPWAP, we are interested in devices that support a wireless interface of > interest. > > Mobile Station - is close to what we have; the term "station" is > overloaded with > 802.11 usage, potential confusion. > Mobile Node - prefer Mobile Unit, as "unit" connotes a device, "node" is > more general > Mobile Equipment - No particular benefit over Mobile unit > User Equipment - applicable to cellular networks, not as applicable to e.g. > RFID > > > Dorothy > > > On 9/1/06, David T. Perkins wrote: > > > > HI, > > > > All good points. One issue is that we are really talking about > > interfaces. A good many number of devices that have a network > > interface may have a single network interface, and that interface > > can be be used to characterize the device as a Wireless end device. > > However, other devices may have other network interfaces that > > are not wireless. > > > > Regards, > > /david t. perkins > > > > On Fri, 1 Sep 2006, Dorothy Stanley wrote: > > > > > Pat, all, > > > > > > How about > > > > > > Wireless End Device (WED)? It captures the essential nature of the end > > > device: "wireless", and > > > it is not wireless-type specific. > > > > > > It is better than > > > > > > Station (an 802.11 term with specific meaning in .11 as Bob points > > out) > > > Mobile - since the end device may be but is not required to be able to > > move, > > > as noted by David > > > Wireless End Point (WEP) - problematic in many ways..... > > > Mobile Unit (MU) - again, the endpoint need not move. This would be > > my > > > second choice though, as it is more specific than just "mobile". > > > > > > Dorothy > > > > > > On 8/31/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com> wrote: > > > > > > > > Folks, I need a term. > > > > > > > > I don't care if it's foobar, but need something everyone will agree > > to. > > > > If station doesn't cut it, as bob insists, then I need something to > > work > > > > it. > > > > > > > > Help, > > > > > > > > Pat Calhoun > > > > CTO, Wireless Networking Business Unit > > > > Cisco Systems > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > > > > Sent: Sunday, August 20, 2006 12:03 PM > > > > > To: Bob O'Hara (boohara) > > > > > Cc: Pat Calhoun (pacalhou); Capwap@frascone.com > > > > > Subject: Re: [Capwap] Issue 161: Ther term "Mobile" is not > > > > > really accurate > > > > > > > > > > HI, > > > > > > > > > > Bob can you suggest an appropriate term to use here. The term > > > > > "mobile" has dictionary meaning of moving. However, being > > > > > capable of moving is not the fundamental defining attribute > > > > > of the interface that differentiates from other technologies. > > > > > > > > > > Regards, > > > > > /david t. perkins > > > > > > > > > > > > > > > On Wed, 16 Aug 2006, Bob O'Hara (boohara) wrote: > > > > > > STOP! Put that editor down and step away from the draft! > > > > > I think it > > > > > > is a big mistake to embed a term that is tied to a single > > > > > binding into > > > > > > the entirety of the draft. > > > > > > > > > > > > -Bob > > > > > > > > > > > > -----Original Message----- > > > > > > From: Pat Calhoun (pacalhou) > > > > > > Sent: Tuesday, August 15, 2006 6:04 PM > > > > > > To: Capwap@frascone.com > > > > > > Subject: [Capwap] Issue 161: Ther term "Mobile" is not > > > > > really accurate > > > > > > > > > > > > The term "mobile" is not really accurate when describing > > wireless > > > > > > interfaces, since wireless does not imply mobile. Can we > > > > > just use the > > > > > > techie term "STA" instead. > > > > > > > > > > > > In my honest opinion, this is one of those change > > > > > requests that > > > > > > is really unnecessary. Traditionally, the IETF has used the term > > > > > > mobile (e.g., mobile station in Mobile IP). However, given the > > > > > > comment, and the fact that the > > > > > > 802.11 WG uses the term station, or STA for short, I will > > > > > go ahead and > > > > > > make the change. Of course, the next binding technology may end > > up > > > > > > using different terminology (including mobile). > > > > > > > > > > > > This will, of course, touch nearly every section of the > > > > > specification > > > > > > (read: diffs will be more complex). > > > > > > > > > > > > Pat Calhoun > > > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > _________________________________________________________________ > > > > > > 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 > > > > > > > > > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_15288_11180767.1157574884563 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
From what I remember (and have heard), the term Mobile Unit was used in IEEE 802.11 in the beginnings of the standard to refer to a WLAN device that transitions between AP's.

Given that one of the main features of CAPWAP is mobility, it sounds that it would be appropriate to use that term.
 
Then again, that term did not make it into the IEEE 802.11 standard.
 
Wireless End Device sounds cumbersome to me.
 
Cheers,
 
Mike
 
On 9/5/06, Dorothy Stanley <dstanley1389@gmail.com> wrote:
Hi David, all,

I am fine with using either

- Mobile Unit (MU) - a general term, describing the unit rather than any interfaces, and
attributing the quality of mobility to the unit
- Wireless End Device - a general term, attributing the characteristic of having a
wireless interface of the type of interest to CAPWAP, but not necessarily having the
quality of mobility. Could also be Wireless End Unit.


True, there may be multiple interfaces on the device. From the perspective of
CAPWAP, we are interested in devices that support a wireless interface of interest.

Mobile Station - is close to what we have; the term "station" is overloaded with
802.11 usage, potential confusion.
Mobile Node - prefer Mobile Unit, as "unit" connotes a device, "node" is more general
Mobile Equipment - No particular benefit over Mobile unit
User Equipment - applicable to cellular networks, not as applicable to e.g. RFID
 

Dorothy


On 9/1/06, David T. Perkins <dperkins@dsperkins.com > wrote:
HI,

All good points. One issue is that we are really talking about
interfaces. A good many number of devices that have a network
interface may have a single network interface, and that interface
can be be used to characterize the device as a Wireless end device.
However, other devices may have other network interfaces that
are not wireless.

Regards,
/david t. perkins

On Fri, 1 Sep 2006, Dorothy Stanley wrote:

> Pat, all,
>
> How about
>
> Wireless End Device (WED)? It captures the essential nature of the end
> device: "wireless", and
> it is not wireless-type specific.
>
> It is better than
>
> Station (an 802.11 term with specific meaning in .11 as Bob points out)
> Mobile - since the end device may be but is not required to be able to move,
> as noted by David
> Wireless End Point (WEP) -  problematic in many ways.....
> Mobile Unit  (MU) - again, the endpoint need not move. This would be my
> second choice though, as it is more specific than just "mobile".
>
> Dorothy
>
> On 8/31/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com> wrote:
> >
> > Folks, I need a term.
> >
> > I don't care if it's foobar, but need something everyone will agree to.
> > If station doesn't cut it, as bob insists, then I need something to work
> > it.
> >
> > Help,
> >
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit
> > Cisco Systems
> >
> >
> >
> > > -----Original Message-----
> > > From: David T. Perkins [mailto:dperkins@dsperkins.com]
> > > Sent: Sunday, August 20, 2006 12:03 PM
> > > To: Bob O'Hara (boohara)
> > > Cc: Pat Calhoun (pacalhou); Capwap@frascone.com
> > > Subject: Re: [Capwap] Issue 161: Ther term "Mobile" is not
> > > really accurate
> > >
> > > HI,
> > >
> > > Bob can you suggest an appropriate term to use here. The term
> > > "mobile" has dictionary meaning of moving. However, being
> > > capable of moving is not the fundamental defining attribute
> > > of the interface that differentiates from other technologies.
> > >
> > > Regards,
> > > /david t. perkins
> > >
> > >
> > > On Wed, 16 Aug 2006, Bob O'Hara (boohara) wrote:
> > > > STOP!  Put that editor down and step away from the draft!
> > > I think it
> > > > is a big mistake to embed a term that is tied to a single
> > > binding into
> > > > the entirety of the draft.
> > > >
> > > >  -Bob
> > > >
> > > > -----Original Message-----
> > > > From: Pat Calhoun (pacalhou)
> > > > Sent: Tuesday, August 15, 2006 6:04 PM
> > > > To: Capwap@frascone.com
> > > > Subject: [Capwap] Issue 161: Ther term "Mobile" is not
> > > really accurate
> > > >
> > > > The term "mobile" is not really accurate when describing wireless
> > > > interfaces, since wireless does not imply mobile. Can we
> > > just use the
> > > > techie term "STA" instead.
> > > >
> > > > <PRC> In my honest opinion, this is one of those change
> > > requests that
> > > > is really unnecessary. Traditionally, the IETF has used the term
> > > > mobile (e.g., mobile station in Mobile IP). However, given the
> > > > comment, and the fact that the
> > > > 802.11 WG uses the term station, or STA for short, I will
> > > go ahead and
> > > > make the change. Of course, the next binding technology may end up
> > > > using different terminology (including mobile).
> > > >
> > > > This will, of course, touch nearly every section of the
> > > specification
> > > > (read: diffs will be more complex).
> > > >
> > > > Pat Calhoun
> > > > CTO, Wireless Networking Business Unit Cisco Systems
> > > > _________________________________________________________________
> > > > 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
> >
>



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

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


------=_Part_15288_11180767.1157574884563-- --===============0782857022== 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 --===============0782857022==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Sep 06 18:57:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL6Kg-0004Kv-Mt for capwap-archive@lists.ietf.org; Wed, 06 Sep 2006 18:57:22 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL6Kd-0005uw-Jn for capwap-archive@lists.ietf.org; Wed, 06 Sep 2006 18:57:22 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 66E881448012 for ; Wed, 6 Sep 2006 15:57:13 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id EFFBB43005A for ; Wed, 6 Sep 2006 15:52:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D345D39800E for ; Wed, 6 Sep 2006 15:52:27 -0700 (PDT) Received: from mgw-ext14.nokia.com (mgw-ext14.nokia.com [131.228.20.173]) by zoidberg.tigertech.net (Postfix) with ESMTP id D2BD6398017 for ; Wed, 6 Sep 2006 15:52:25 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k86MqMZU030993; Thu, 7 Sep 2006 01:52:23 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 01:52:02 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Sep 2006 17:51:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Sep 2006 15:51:42 -0700 Message-ID: <8A76136424391244A5CF016533708537020EEC11@mvebe101.NOE.Nokia.com> In-Reply-To: <26140d940609061334q348cac12h815507717b221724@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 161: Ther term "Mobile" is not really accurate Thread-Index: AcbR9HJXZna0kONmTp2TVqMcGiG51QAEGktw From: To: X-OriginalArrivalTime: 06 Sep 2006 22:51:45.0449 (UTC) FILETIME=[073A1990:01C6D207] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.265 tagged_above=-999 required=7 tests=HTML_40_50, HTML_MESSAGE, NO_REAL_NAME X-Spam-Level: Cc: Capwap@frascone.com Subject: Re: [Capwap] Issue 161: Ther term "Mobile" is not really accurate 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="===============1506257880==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.3 (/) X-Scan-Signature: b4b36b0fb877eeac6f347960137fc10b This is a multi-part message in MIME format. --===============1506257880== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D207.0624A504" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D207.0624A504 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike, =20 Of the terms below, Mobile Node (MN) is the most "standard-ish", and crosses organizational boundaries nicely. It doesn't put any limitations on the type of device...but makes it clear it's a single device... it provides an abstraction without adding additional constraints. =20 The most popular by far is Mobile Device (MD), not on the list below. User Equipment (UE) comes right behind it in terms of frequency of usage in our broad context. End Device (ED) is just after that in popularity, but goes beyond our context a bit. =20 Mobile Unit is most often used in the sense of a group of things moving around together as a unit, not really what we want. Mobile Equipment most commonly connotes something like a vehicle, also not what we want. =20 I'd suggest MN, MD, UE and ED in that order of priority. =20 Best Regards, Michael ________________________________ From: ext Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Wednesday, September 06, 2006 1:35 PM To: Dorothy Stanley Cc: Capwap@frascone.com Subject: Re: [Capwap] Issue 161: Ther term "Mobile" is not really accurate >From what I remember (and have heard), the term Mobile Unit was used in IEEE 802.11 in the beginnings of the standard to refer to a WLAN device that transitions between AP's. Given that one of the main features of CAPWAP is mobility, it sounds that it would be appropriate to use that term. =20 Then again, that term did not make it into the IEEE 802.11 standard. =20 Wireless End Device sounds cumbersome to me. =20 Cheers, =20 Mike =20 On 9/5/06, Dorothy Stanley wrote:=20 Hi David, all, =09 I am fine with using either =09 - Mobile Unit (MU) - a general term, describing the unit rather than any interfaces, and attributing the quality of mobility to the unit - Wireless End Device - a general term, attributing the characteristic of having a=20 wireless interface of the type of interest to CAPWAP, but not necessarily having the quality of mobility. Could also be Wireless End Unit. =09 =09 True, there may be multiple interfaces on the device. From the perspective of=20 CAPWAP, we are interested in devices that support a wireless interface of interest. =09 Mobile Station - is close to what we have; the term "station" is overloaded with=20 802.11 usage, potential confusion.=20 Mobile Node - prefer Mobile Unit, as "unit" connotes a device, "node" is more general Mobile Equipment - No particular benefit over Mobile unit User Equipment - applicable to cellular networks, not as applicable to e.g. RFID=20 =20 =09 Dorothy =09 =09 =09 On 9/1/06, David T. Perkins wrote:=20 HI, =09 All good points. One issue is that we are really talking about interfaces. A good many number of devices that have a network=20 interface may have a single network interface, and that interface can be be used to characterize the device as a Wireless end device.=20 However, other devices may have other network interfaces that are not wireless.=20 =09 Regards, /david t. perkins =09 On Fri, 1 Sep 2006, Dorothy Stanley wrote: =09 > Pat, all, > > How about=20 > > Wireless End Device (WED)? It captures the essential nature of the end=20 > device: "wireless", and > it is not wireless-type specific. > > It is better than > > Station (an 802.11 term with specific meaning in .11 as Bob points out) > Mobile - since the end device may be but is not required to be able to move,=20 > as noted by David > Wireless End Point (WEP) - problematic in many ways.....=20 > Mobile Unit (MU) - again, the endpoint need not move. This would be my > second choice though, as it is more specific than just "mobile".=20 > > Dorothy > > On 8/31/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com> wrote:=20 > > > > Folks, I need a term. > > > > I don't care if it's foobar, but need something everyone will agree to. > > If station doesn't cut it, as bob insists, then I need something to work=20 > > it. > > > > Help, > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > -----Original Message-----=20 > > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > > Sent: Sunday, August 20, 2006 12:03 PM=20 > > > To: Bob O'Hara (boohara) > > > Cc: Pat Calhoun (pacalhou); Capwap@frascone.com=20 > > > Subject: Re: [Capwap] Issue 161: Ther term "Mobile" is not > > > really accurate=20 > > > > > > HI, > > > > > > Bob can you suggest an appropriate term to use here. The term=20 > > > "mobile" has dictionary meaning of moving. However, being=20 > > > capable of moving is not the fundamental defining attribute > > > of the interface that differentiates from other technologies.=20 > > > > > > Regards, > > > /david t. perkins=20 > > > > > > > > > On Wed, 16 Aug 2006, Bob O'Hara (boohara) wrote: > > > > STOP! Put that editor down and step away from the draft!=20 > > > I think it > > > > is a big mistake to embed a term that is tied to a single=20 > > > binding into > > > > the entirety of the draft. > > > > > > > > -Bob=20 > > > > > > > > -----Original Message----- > > > > From: Pat Calhoun (pacalhou)=20 > > > > Sent: Tuesday, August 15, 2006 6:04 PM > > > > To: Capwap@frascone.com > > > > Subject: [Capwap] Issue 161: Ther term "Mobile" is not=20 > > > really accurate > > > > > > > > The term "mobile" is not really accurate when describing wireless=20 > > > > interfaces, since wireless does not imply mobile. Can we=20 > > > just use the > > > > techie term "STA" instead. > > > > > > > > In my honest opinion, this is one of those change=20 > > > requests that=20 > > > > is really unnecessary. Traditionally, the IETF has used the term > > > > mobile (e.g., mobile station in Mobile IP). However, given the > > > > comment, and the fact that the=20 > > > > 802.11 WG uses the term station, or STA for short, I will > > > go ahead and > > > > make the change. Of course, the next binding technology may end up > > > > using different terminology (including mobile).=20 > > > > > > > > This will, of course, touch nearly every section of the > > > specification > > > > (read: diffs will be more complex). > > > > > > > > Pat Calhoun=20 > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > _________________________________________________________________ > > > > To unsubscribe or modify your subscription options, please visit:=20 > > > > http://lists.frascone.com/mailman/listinfo/capwap > > > >=20 > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > _________________________________________________________________=20 > > > > To unsubscribe or modify your subscription options, please visit:=20 > > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit:=20 > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > =09 =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 ------_=_NextPart_001_01C6D207.0624A504 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Mike,
 
Of the terms below, Mobile Node (MN) is = the most=20 "standard-ish", and crosses organizational boundaries nicely. It doesn't = put any=20 limitations on the type of device...but makes it clear it's a single=20 device... it provides an abstraction without adding additional=20 constraints.
 
The=20 most popular by far is Mobile Device (MD), not on the list = below. User=20 Equipment (UE) comes right behind  it in terms of frequency of = usage=20 in our broad context. End Device (ED) is just after that in = popularity, but=20 goes beyond our context a bit.
 
Mobile Unit is most often used in the sense = of a group=20 of things moving around together as a unit, not really what we=20 want.
Mobile Equipment most commonly connotes = something like=20 a vehicle, also not what we want.
 
I'd suggest MN, MD, UE and ED in that order = of=20 priority.
 
Best Regards,
Michael

From: ext Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Wednesday, = September 06,=20 2006 1:35 PM
To: Dorothy Stanley
Cc:=20 Capwap@frascone.com
Subject: Re: [Capwap] Issue 161: Ther term = "Mobile" is not really accurate

From what I remember (and have heard), the term Mobile Unit was = used in=20 IEEE 802.11 in the beginnings of the standard to refer to a WLAN = device=20 that transitions between AP's.

Given that one of the main features of CAPWAP is = mobility, it=20 sounds that it would be appropriate to use that term.
 
Then again, that term did not make it into the IEEE 802.11 = standard.
 
Wireless End Device sounds cumbersome to me.
 
Cheers,
 
Mike
 
On 9/5/06, Dorothy=20 Stanley <dstanley1389@gmail.com>=20 wrote:=20
Hi David, all,

I am fine with using either

- Mobile = Unit=20 (MU) - a general term, describing the unit rather than any interfaces, = and
attributing the quality of mobility to the unit
- Wireless = End=20 Device - a general term, attributing the characteristic of having a=20
wireless interface of the type of interest to CAPWAP, but not = necessarily=20 having the
quality of mobility. Could also be Wireless End=20 Unit.


True, there may be multiple interfaces on the device. = From=20 the perspective of
CAPWAP, we are interested in devices that = support a=20 wireless interface of interest.

Mobile Station - is close to = what we=20 have; the term "station" is overloaded with
802.11 usage, = potential=20 confusion.
Mobile Node - prefer Mobile Unit, as "unit" connotes a = device,=20 "node" is more general
Mobile Equipment - No particular benefit = over Mobile=20 unit
User Equipment - applicable to cellular networks, not as = applicable to=20 e.g. RFID
 

Dorothy


On 9/1/06, David T.=20 Perkins <dperkins@dsperkins.com=20 > wrote:=20
HI,

All=20 good points. One issue is that we are really talking = about
interfaces. A=20 good many number of devices that have a network
interface may = have a=20 single network interface, and that interface
can be be used to=20 characterize the device as a Wireless end device.
However, other = devices=20 may have other network interfaces that
are not wireless.=20

Regards,
/david t. perkins

On Fri, 1 Sep 2006, = Dorothy=20 Stanley wrote:

> Pat, all,
>
> How about=20
>
> Wireless End Device (WED)? It captures the = essential nature=20 of the end
> device: "wireless", and
> it is not = wireless-type=20 specific.
>
> It is better than
>
> Station = (an=20 802.11 term with specific meaning in .11 as Bob points out)
> = Mobile -=20 since the end device may be but is not required to be able to move, =
>=20 as noted by David
> Wireless End Point (WEP) = -  problematic=20 in many ways.....
> Mobile Unit  (MU) - again, the = endpoint=20 need not move. This would be my
> second choice though, as it = is more=20 specific than just "mobile".
>
> = Dorothy
>
> On=20 8/31/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com>=20 wrote:
> >
> > Folks, I need a term.
> = >
>=20 > I don't care if it's foobar, but need something everyone will = agree=20 to.
> > If station doesn't cut it, as bob insists, then I = need=20 something to work
> > it.
> >
> > = Help,
>=20 >
> > Pat Calhoun
> > CTO, Wireless Networking = Business=20 Unit
> > Cisco Systems
> >
> >
>=20 >
> > > -----Original Message-----
> > > = From:=20 David T. Perkins [mailto:dperkins@dsperkins.com]
> > > Sent: = Sunday,=20 August 20, 2006 12:03 PM
> > > To: Bob O'Hara = (boohara)
>=20 > > Cc: Pat Calhoun (pacalhou); Capwap@frascone.com=20
> > > Subject: Re: [Capwap] Issue 161: Ther term = "Mobile" is=20 not
> > > really accurate
> > >
> = > >=20 HI,
> > >
> > > Bob can you suggest an = appropriate=20 term to use here. The term
> > > "mobile" has = dictionary=20 meaning of moving. However, being
> > > capable of = moving is=20 not the fundamental defining attribute
> > > of the = interface=20 that differentiates from other technologies.
> > = >
> >=20 > Regards,
> > > /david t. perkins
> > = >
>=20 > >
> > > On Wed, 16 Aug 2006, Bob O'Hara = (boohara)=20 wrote:
> > > > STOP!  Put that editor down = and step=20 away from the draft!
> > > I think it
> > > = > is=20 a big mistake to embed a term that is tied to a single
> > = >=20 binding into
> > > > the entirety of the = draft.
> >=20 > >
> > > >  -Bob
> > >=20 >
> > > > -----Original Message-----
> > = >=20 > From: Pat Calhoun (pacalhou)
> > > > Sent: = Tuesday,=20 August 15, 2006 6:04 PM
> > > > To: Capwap@frascone.com
> > > > = Subject:=20 [Capwap] Issue 161: Ther term "Mobile" is not
> > > = really=20 accurate
> > > >
> > > > The term = "mobile" is=20 not really accurate when describing wireless
> > > > = interfaces, since wireless does not imply mobile. Can we
> = > >=20 just use the
> > > > techie term "STA" = instead.
> >=20 > >
> > > > <PRC> In my honest opinion, = this is=20 one of those change
> > > requests that
> > = > >=20 is really unnecessary. Traditionally, the IETF has used the = term
>=20 > > > mobile (e.g., mobile station in Mobile IP). However, = given=20 the
> > > > comment, and the fact that the
> = > >=20 > 802.11 WG uses the term station, or STA for short, I = will
> >=20 > go ahead and
> > > > make the change. Of course, = the=20 next binding technology may end up
> > > > using = different=20 terminology (including mobile).
> > > >
> > = >=20 > This will, of course, touch nearly every section of the
> = >=20 > specification
> > > > (read: diffs will be more=20 complex).
> > > >
> > > > Pat Calhoun =
>=20 > > > CTO, Wireless Networking Business Unit Cisco = Systems
>=20 > > >=20 = _________________________________________________________________
>= =20 > > > To unsubscribe or modify your subscription options, = please=20 visit:
> > > > http://lists.frascone.com/mailman/listinfo/capwap
= >=20 > > >
> > > > Archives: http://lists.frascone.com/pipermail/capwap
> = >=20 > > = _________________________________________________________________=20
> > > > To unsubscribe or modify your subscription = options,=20 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:=20
> > http://lists.frascone.com/mailman/listinfo/capwap
= >=20 >
> > Archives: http://lists.frascone.com/pipermail/capwap =
>=20 = >
>



_____________= ____________________________________________________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20


------_=_NextPart_001_01C6D207.0624A504-- --===============1506257880== 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 --===============1506257880==-- From geaclwl@t-dialin.net Thu Sep 07 08:46:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLJHC-00068T-Mp for capwap-archive@ietf.org; Thu, 07 Sep 2006 08:46:38 -0400 Received: from p54b14b9a.dip.t-dialin.net ([84.177.75.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLJGy-0005DX-9T for capwap-archive@ietf.org; Thu, 07 Sep 2006 08:46:38 -0400 Message-ID: <000901c6d27b$98954e90$9a4bb154@tim> From: "SongWeird Yankovic" To: capwap-archive@ietf.org Subject: society youll Date: Thu, 7 Sep 2006 14:46:10 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C6D28C.5C1E1E90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 2.6 (++) X-Scan-Signature: abb8110dde048486ea2be9c769692569 ------=_NextPart_000_0005_01C6D28C.5C1E1E90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C6D28C.5C1E1E90" ------=_NextPart_001_0006_01C6D28C.5C1E1E90 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable but down. alland mean all. Penelope Jones Though once Lunatics orbit = rising star Nelly clone. She however lurrned slurry delivery deploys = appealing sass. Intimate beats strong network hooks take care rest. = PopRap Young Love majors have finally clued groove DFAstyle dance rock = Keyes some truly jams. Filed British Metal Sample Various Confuzed Disco: = Italian Records Made popular discos housey often acidic vocal electro = cheesy cant help but down. alland mean all. Penelope Jones Though once = Lunatics orbit rising star Nelly clone. She however lurrned slurry = delivery deploys appealing sass. Intimate beats strong network hooks = take care rest. PopRap Young Love majors have finally clued groove = DFAstyle dance rock Keyes horse field. indie orthodoxy likely wont = approve majors have finally clued groove DFAstyle dance rock Keyes horse field. = indie orthodoxy likely wont approve croon crew puts good studio side. = J.Period Kanye Fugees shacked Yorks hottest mixtaper obvious why. doesnt = shy away hugely ambitious blends. Its imagine Beatles Thought jamming = Together easy Party ccc Anngies Playlist: Mind Lately listening lot = dubstep other goodness whose synth effects slow heart rate long enough = pace whats around bass line intro denial. sporting arena national cathedral place where gather study = examines way tell stories both fictional considers kinds athletes choose = as heroes lessons values glean from explores intricate telling between = coaches fans black white players immigrant native male female process = shows Americans ourselves people believe be. Chapter chapter portrait = emerges country conflict itself sort has become: that sees Best Possible = Countries land ceaseless To Saying first add comment chance Schuster General states Series Date:May = Pages: in. lbs. related in: Help Security Privacy Shipping Money Back = Guarantee Order Phone Contact Laurels WebEPIC Official RSS Log Copyright = Terms Object MovedThis object may found here. MP music downloads wont approve croon crew puts good studio side. J.Period Kanye Fugees = shacked Yorks hottest mixtaper obvious why. doesnt shy away hugely = ambitious blends. Its imagine Beatles Thought jamming Together easy = Party ccc Anngies Playlist: Mind Lately listening lot dubstep other = goodness whose synth effects slow heart rate long enough pace whats = around bass line intro know within seconds Ill dancing theres nearby. = Heres sampling mind. songs A.I.M. Evil Close Edge Among Bring Pain Random Key Tattoos: An Epilogue Our Readers Are Saying = first add comment chance Schuster General states Series Date:May ------=_NextPart_001_0006_01C6D28C.5C1E1E90 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
but down. alland mean all. Penelope Jones Though once Lunatics = orbit rising star Nelly clone. She however lurrned slurry delivery = deploys appealing sass. Intimate beats strong network hooks take care = rest. PopRap Young Love majors have finally clued groove DFAstyle dance = rock Keyes
some truly jams. Filed British Metal Sample Various Confuzed = Disco: Italian Records Made popular discos housey often acidic vocal = electro cheesy cant help but down. alland mean all. Penelope Jones = Though once Lunatics orbit rising star Nelly clone. She however lurrned = slurry delivery deploys appealing sass. Intimate beats strong network = hooks take care rest. PopRap Young Love majors have finally clued groove = DFAstyle dance rock Keyes horse field. indie orthodoxy likely wont = approve
majors have finally clued groove DFAstyle dance rock Keyes = horse field. indie orthodoxy likely wont approve croon crew puts good = studio side. J.Period Kanye Fugees shacked Yorks hottest mixtaper = obvious why. doesnt shy away hugely ambitious blends. Its imagine = Beatles Thought jamming Together easy Party ccc Anngies Playlist: Mind = Lately listening lot dubstep other goodness whose synth effects slow = heart rate long enough pace whats around bass line intro
denial. sporting arena national cathedral place where gather = study examines way tell stories both fictional considers kinds athletes = choose as heroes lessons values glean from explores intricate telling = between coaches fans black white players immigrant native male female = process shows Americans ourselves people believe be. Chapter chapter = portrait emerges country conflict itself sort has become: that sees Best = Possible Countries land ceaseless To
Saying first add comment chance Schuster General states Series = Date:May Pages: in. lbs. related in: Help Security Privacy Shipping = Money Back Guarantee Order Phone Contact Laurels WebEPIC Official RSS = Log Copyright Terms Object MovedThis object may found here. MP music = downloads
wont approve croon crew puts good studio side. J.Period Kanye = Fugees shacked Yorks hottest mixtaper obvious why. doesnt shy away = hugely ambitious blends. Its imagine Beatles Thought jamming Together = easy Party ccc Anngies Playlist: Mind Lately listening lot dubstep other = goodness whose synth effects slow heart rate long enough pace whats = around bass line intro know within seconds Ill dancing theres nearby. = Heres sampling mind. songs A.I.M. Evil Close Edge
Among Bring Pain Random Key Tattoos: An Epilogue Our Readers = Are Saying first add comment chance Schuster General states Series = Date:May
------=_NextPart_001_0006_01C6D28C.5C1E1E90-- ------=_NextPart_000_0005_01C6D28C.5C1E1E90 Content-Type: image/gif; name="RicoSaint.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c6d27b$98954e90$9a4bb154@tim> R0lGODlhxAH4AYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAATAAAALAAAAADEAfgBBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdIkbuPKnUu3rl2v3e7q3cu3r9+/gAMLHkw4JqjCiBMrXsy4sePHkCNLnky5suXL mDNr3sz54ojOoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHj yJMrX868ufPn0KNLn069uvXr2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr37917LwZ9Pv779 +/jz69/Pv7///wAGKOCABBZo4IEIJqjgggw26OCDBD0BYUSnTGjhhRhmqOGGHHbo4Ycghiji iCSWaKJNcZyo4oostujiizDGKOOMpRFAo2k23lijjjvy6OOPQAYp5JBEFmkkQRocqeSSTDbp 5JNQRinllFRWaeWVWGap5ZZcdunll865AeZfYo7pV5lm8oVmmmzOJUGbcMYp55x01mnnnXjm KWUfevbp55+ABirooIRK90mhiCaq6KKMNuroow7VA6lV9VQ66VSVSnppVJlu6umn/F0D6qik XvhBqaimquqqrLbq6qv/sMYq66y01mrrrbjmquuuvPbqa4Z8/prUNMIWa+yxyCqWV7LMNuvs s099A+201FZr7bXYZqvtttx26+234IYr7rjklmvuueimq+66f7HArlpLvCvvvMGJQu+9+AKK S7789uvvvwAHLPDABBds8MEIJ6zwwo5qw/DDEEcs8cQUV2zxxRhnrPHGHHfs8ccghyzyyCSX bPLJKBN0SMost+xytYoognDMM8t8MM03v6zzzgNWw/PPQAct9NBEF2300XX6g7A/Sh/M9NJI Ry311FRXbfXVWGet9dZcd+3112CHLfbYZJdt9tldZYK2qoas7fbbcMct99x012333Xjnrffe 8Hz37fffgAcueJD3DG744QyugPji7ynB+OOQRy755LEOQ/nlxQGA+eacryZD56CHLvropJfu 1REIo26w6qunfjDrBcNu+uy0xxWAwbcXnHvtvPfu++/Ao7VB8MQXb/zxyKkiHjbIN+/889BH f1sJ0ldv/fXYZ6/99tyvnc1X9nTPbh7k7a4e+QWjT7D64rfv/vuYfw7//PTXb//9+Oev//78 s4aHq1xAWAANNkACHqyABUPgwBTYvwY68IEQpIh8IkhBK82gghj0CTEyyMEOevCDIOyTB0JI QsNJAlHcKKEKV8jCJv2vhTAEkDNimLeAAAAh+QQAEQAAACwAAAAAxAH4AQcI/gD/CRxIsKDB gwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs+ZE MjZz6tzJs6fPn0BhXglKtKjRo0iTKl3KtKnTp1Cj2lwltarVq1izat3KlWO1rmDDih1LtqzZ s2jLoknLtq3bt3Djyp1Lt67du3jz6t3Lt6/fv4ADCx5MuPDAQoYXukvMuLHjx5AjS55MubLl y5gza978eF7IYpxDix4YbbTp06hTq17NWmOq1rBFv45Nu7bt27hzC+6ku7fv38CDCx9OvLjx 48iTK1/OvLnz59CjS59OvXpRS9aza9/Ovbv37+DD/osfT768+fPo06tfz769+/fw48ufT7++ /fv48+vfz7+///8ABijggAQWaOCBCCao4IIMcgVNgxBGKOGEFFZoYVpwXFhehhqOx2GH4X0I 4nciAqbBiE6ViOJ2Kq6YXYsuEtcKRDDGKNyMNvLlBlQ45phdj79p42NFQA45XZFGJqnkkkwi 9EeTUEYp5ZRUVmnllViWFUCWXHbp5ZdghinmmGSWaeaZaGIJRJpstunmm3DGKeecdNZpp11h 3JlaGHnq6eefyfEB6KCEFmrooYgmquiijDbq6KOQRiqphXVMaumlmGaq6aacdurpp6CGKuqo pJZq6ql29YHqqqy26uqr/7DGKuustNZq66245qrrrrz26uuvoUIALFtMDGussaccq+yyzDbr 7LPQRivttNRWa+212Gar7YqbbOvtt+CGK+645JZr7rnopqvuuoXKw+678MYr77z01mvvvfjm q+++/Pbr778AByzwwAQXbPDBCCes8MIMN+zwwxBHLPHEFFdssZxyXIxQxhobxHHHBH0MskAi j1wyyCd3nLLGK4+80BBpIeHyzDQryQPNPNw8s85hZVDzz0AHLXSAWAxt9NFIU4lL0kw37fTT UEcdXSBSV2311VhnrfXWXHft9ddgl5lL2GQ3OUzZaKet9tpst+3223DHLffcdNdt99145633 3v589+3334AHLvjghBdu+OGIJ6744ow37vjjkEcu+eSUV2755ZhnrvnmnHfu+eeghy766KSX bvrpqKeu+uqst+7667DHLvvstNdu++2456777rz3jqrPvgcvfGuvDG/88cgnr/zy1EHC/PML LgL99NRXb72YOPUWyvXcM9eMi5jQjEn4M5Pf/fnop6/+trs0+847sxrS1vvw/0w/0PWvr3+p 5ADd/8//q1kAaUaOAe7vgAhMoITAocAGOvCBEIygBCdIwQpa0FoJuKAGN8jBDnrwgyAMoQhH SMISmvCEKETON1L4rgOw8IUwjOGciiXDGtrwhjjMoQ53yMMe+vCH+gpZAxCHSMQibisgACH5 BAAMAAAALAAAAADEAfgBBwj+AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8eP IEOKHEmypMmTKFOqXMmypUuE417KnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOn UKNKnUq1qtWXipieuMq1q9evYMOKHUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/ gAMLHky4sOHDiBMrXsy4ceNHjiNLnky5suXLmDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevX sGPLnk27tu3buHPr3s27t+/Jen4LXxhluPHjyJMrX868ufPn0KNL71lpuvXr2LNr3869u/fv 4MP+ix9PPqmF3sTKz7TAnr369/Djy59Pv779+/jzz1+jv7Sr/gAGKOCABBZo4IEIJqjgggw2 6OCDEEYo4YQUVmjhhRhmqGFJCWzoXIceNgdiiMuNSGJyJp6o4oostuhiVFe8KFyMMv5GY429 3YjjbjrumFuPPt4GZJC1DUnkkUgmqeSSTDbp5JNQRinllFRWaeWVWGap5ZZcdunll2CGKeaY ZJZp5plopqnmmmy26eabcMYp55x01mnnnXh+VEqefPbp55+ABirooIQWauihiCaq6KKMNorb Vo5GKumklFZq6aWYZqrpppx26umnoA5nSahfjUpqV6aequqqrLbq6qv/sMYq66y01mrrrbjm quuuvPbq66/ABivssMQWa+yxyCarrEcpLuvss5kCAO201FZr7bXYZqvtttx26+234IYr7riZ 2UHuueimq+667Lbr7rvwolVIvPTWa++9+Oar77789ouZAf4GLPDABBds8MEIJ6zwwgw37PDD EEcs8cTfgSDfBAFavLDG686jEcfqepwRCCCfK7LCJyecMsIrH9yywS8XHDPBM1Ns880456zz zjz37PPPQAct9NBEF2300UiPW0fSTDft9NNQRy1ScFJXbfXVWGet9dZcd+311w5WcVAHYJdt 9tlop622S0sw3PbCb69ognFxJ7xE3Wvnrffe/nz37fffgAcu+OCEF2744YgnrvjijDfuOFtU PC755JRXbvnTnlyu+eacd+7557e6U28roJdu+umop6766qHp87cwS+rC+uy012777bg39opO LOTu+++ZTUOvGsDnSkrxyCev/PLMNy8eEs5Hr1wv0ldv/fXYZ6+9RRps7/334Icv/vjhRkD+ +einr2Uu6rfv/vvwxy///PTXnzMo9uev//789+///wAMoAAHSMACGvCACEygAhfIQOykYzMM eBMkGpiZcyDsHBg8WAY1aEEOis8eFAyhCH8XjREqZAoKQ2GVRoEaFSLMhbqpgcNCYcIa2vCG OMyhDgsIhh368IdACQyiEIdIRJQEBAAh+QQAPecAACwAAAAAxAH4AQcI/gD/CRxIsKDBgwgT KlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz 6tzJcoDPAQJ9HgQqlKDQn0iBBkW6NKnSpk//OY0qlanID1g/EMR6UOvWrGD/cS3IdexAs1+z CgQblq1Xsm7fupzBs67doU9/GiRK9SjVgUWrGu0btWhgwUsB/9WIdqxasggby12rFa3YyZfP VsacmTJDy3dDi14Z2CpgxIpRD16dmnVi1YYLL84ombJlzp09w82tW/NX3r6DR8Y9urhxkKWr Fn6N+HBrhIedC46uVPpH0GUvy8Vde/ftyaCB/vcW//u4+fMekys/jTq2U6h/qe/l+1y5dcaY s2s/OzxtXODYhWUbW7yFNx56CCY4kXrrScVcbAklVZB8E/JlmmJ6XZdfZZp5xd12GwLIGYHk mWXggQqmqGKEeQ1GVGqlzVaha6olBiGLGhqkn21i9Secb98tVNaIJPq44pFIukZYjO0tRiFz UN7YJGs33vcZiGvBZWB3vwVZnmfhnbhbeY4Rl+SZODGIoYs0Pufcm7JFWV1edL5mpZBY9qil keKV+WNvfupo5p+dBYrmoTpZ5aRsjEpoX3yLPmnnhVXK2JCAWQrKZ4AdbolpXJtdGmKhgyJq 6qmopqrqqqy26uqr/7DGKuustNZq66245qrrrrz26uuvKyID7LDEFmvsscgmq+yyzDbrLEbg gEOQtANFO6211UarLbYCbUstt9kitO21BVnrrbblUkvuueaem627B3mbLrjghsuuuvLOK2+9 /7QL77vjAqyvugYF3C3B1fbL7sHPnsQtugy/Gy/C9ErL78UEY1tvxeIirPDHBWf8rcchkwty xBBLzG/EJ6dr8rokv9wyx+G6XHPKCa/ccsMiPeyzvR5vLPLORNMstMxIf7yy0THLrPHQClPc 7sRJs1y0xU1bTbPWQUNtcLdEW81zSD7ja/bVVaOd9NROx4xx2EwvpPPbWOdcd8kNbQ203P5Q s6zz2hZHPW3YhI/d0dRsM/x2zSHfazPMjxN+r7/7nn3wv2Izbi/II0edb74dX+u446J/ffLf mit+ud3wom64RojffbrUaS+eutK035554qXrTfXv66qOe0Kg47277KFr/vPluQe/er+SZ/16 RrHPXvzMbncdueLNR1/y0p3rXrv2lg/P0Nx9763Q0X53j7bIgaM/fc8pB8y+2Bzbrnz4+ycP ufHLW5/XvMY43vUPeO+T3v30pj+N6atw8xtJ/QLItcgZUG3tS538XAY+k7kOexWEHtU6mLkD /o946WOg9m7WOO9FECQL7B74IKa/0jWuhrej3LiORrobSo1eof4j3fUsSL6F9a5iQsPZAxP2 PSN+8IVQjKIUp0jFKlrxiljMoha3yMUuevGLYAyjGMdIxjKa8YxoTKMa18jGNrrxjXDUyQri SMdirWCOdcyjr/Coxz7m6o5+DOStACnIQsqKj4ZMpCIXychGOvKRkIykJCdJyUpa8iQJuKQm V6UNbdiqk2QEgChFGRpQCsSUnUylJ/9hylOyMpWnVOVAVLlKWtaSlq+U5Sx1WRBcxlKXttwl LwnSymDmEpbHXCUxfWnMZe7yl6j0ZTIPYsxmtvKLpBwIAO4SzVg6E5ms9OYriTnOWZZznNc8 ZzfN6UxzXhOUxbzlM3spz3mqU5nhbP8nOpWZznW+857nzKc99znPdHYxmwLZ5j9GmU2GbnOU CX0oQhfaUIkqtKIRVQg8+YnPjfJTnP8MKUcDCtCA4tOkJvVkPMVJ0pXa06Wu1OdGC6rSmg7U pt78pz4JylKDbnGiGc0oRilK0YteVKgYHSpQ6fnOjqq0nPU0qFRH2s+RkpSeBmlqSWHaU6e+ 9KRYzalVPerVsPIUIVqFqU+1uFSEklKpEtWmQuVKVKQGlSHgZCk6cwrSW/o1msDEpTX9atab 1pSXXC1pVweaVWZKU5hhhWU1wbpTsmoVjG2d61uNategOrSudWXoQ4aZVr5C1arfpOpJZ/rV wup1pk0d5mL+W6vXxj4zsaRV7W0pa1jFrtVUc7XJROPa2aRqlribpWtRg7sQ1qZUoMhc5153 S912qnW1HX2udH+rWN9mV6Y4bWl4V0re7/b2umEcLmiTG1riEtW4ygWtfG172m9Ctr6mFWt1 aYvb7KZ1rLydrYB12lqXsna74w1vPp171sQeVLQRhWh7kQrh5brXrcFdKnihicrUAja6gQ2x ZMvaTGHGM7CpbS5Hc7vMvHL4r+WlqSwHC84P2xi1hdTwQ3T8Ou66ysd05HFDhGw4IKvKyJtM spKXzOQmO/nJUHYkkeMb5Sd/diJTvutoAQxixMq2ytjMMJaZm5AsR7aerowxO8H+jFkxGxei Et7scePM2YY4V6T7FSibvZjZ4nKWzutFLpnRmtep5nnPYrwyfCeM4UDP185V/WUy0YxogpSj Vo2QSUXh2tn3HvfReC20bvVb6UQTZNN1XrSn6WrmFC9WzTEt9U9P/WnP/vnTjR5qqPu6XwYH eCebkPWRrnxXTjt0zpyGtIxH7GUXC7vNz452RVot7Wpb+9rYzra2t83tbg8rAAGYCbi9fapj H4TaFAG3ug+i7nELpN3hNoi73f0PejfE3vAeyLoJEm9995vcZ2q0Suht73r3e9wE//e7451w h7Tb3xBH+MHlrXCADxvXD20vqqns8IMrvOEN57fHIx7/7n2ze+QLN7jK642QgltcRbmGs3sn DOqFhBziKb95yneu8n27nOcgLznDW17xlyso5qzOcJ3TjXKc97zpQB+5zkXu9HnPe+H//rnR EWRuRw+X2BOZusEfPvWbS9zpBTF7xRkudLRv/ehkRjrHKyJ2qpe96WfnedrxvvacQ/3tCepz p9er5Y7jvOBWd7vaV874vVf94yR3O+DRI3iNG1XgEcn3zh/ub5NTHetW5/zeOa95fY9e8pMf o9b1XpLVpx6Mq3e9R2T/+trb/va4z73udy9sdPN+jV0He5kHPZPHmviyEVmrNI3/+5gAVekM 8f1JHDxVJJuYmqO+avNdImT2/i76+RmPMIXlCuEKC5n6vLX+TguM4+2/RPh+tmtmGzr+Vce/ 5gI+vmsd4lNYq9/9JgF+SWd55zZo7GV/9mdmDlZZlPVltTVbzAeAMPF1tJaAOvZ1MjeAFCZh u/aADDgR/Zd9/yeBI4F5EaZoHFiBtuZ1GCcRC9hbLtiAIvhrJEgS0AdqunaA8aVq3neAS4d9 NKVnyAcR/9VrNFiDJVh+XUdzTKhlnyVwGbhcc8dUBtZszpYQk8Vh+oeEuyJ9XIgRMMBF8PeF ZDgSS1CGaJiGariGbNiGbviGcBiHcjiHdFiHdniHeJiHeriHfNiHfviHgBiI6EEHgliIhniI iHgm/9OQiIzYiI74iJAYiZI4iZRYiZaYLIt4iZq4iZzYiZ74iaAYiqI4iqSoE1bwdvzADwOR igKRiq7Yiq7IirD4igURi7L4D7aoirc4i7QIi7UYi7woi7ZoELkYjKpojASxi7fIisCojMFI jMfYirg4jMu4isc4jAAojNcYjbg4jdbojav4i98IjuNYjsnYi864i+TYjef4jcu4jQcBjL5I jtoYjbrIjdw4jfa4juBIi8yIj9l4j+YokL7ojO04j+qYkPnIiwPJjwZZjv84jurIkAWJj9u4 jw85iwggjQo5ixWZjPO4e/IYkhBJkAjxjiTpkAupjSmpkgqBkijJj/14kf/5KIz9KJMgaZMd 2Y3wOJE4aXu9iJD/KI8+aY0jWYwKSZTw+Iz66I8jaZROeZTYyJL6CI3S6I0EGZTsyIxNWY/3 +I5a+XtPCZP2aJLxaJY7aY5CeZY/mZJkuY4TSZVPeZNYSY81WZAy2Yxh2Za4F5Eh6ZdYCZAH GZNqmZTU2I4JeZAlOZOFmYsCqYzXaJR2WYuSGZevSJSK2XxyWZaTmZGT6ZKZCZe6iJh32Zju yJmg+ZGfWZYmmZge6ZOEaZEteXsxiZTDqAldaZWnqZe8eZmymZtdSZMrOZWyaZukuZujKZHY GI7IGZsWiY4LWYrLIgbSWZ3WeZ3KQgpv+AjYGUH/3Nmdr/OdFmEK4Jkr4lmeDXOe6Oks6rme 7vme23cH8Dmf9Fmf9nmf+Jmf+skQ8rCf/vmfAAqKxPcrzDWgGRF+EihmDmGg2uQRorWEFUZr A8qgZeagBUGhp5ahDWoQ4Wd+Baih53ZtmmWhHFGgIbqhF6oQGBqAKbpjILpQIYqgMDqjF6qg J1ptR0V+RxVnJ3h5MMqB5Tejwhd3HFqkLWpRJ5ikP0qjHcqjCbWh5hehP0p/T3qkQkp+Tyqj StqgIyqFXhptMupmIxqmNEp4YlqlaJqmalqma7p0OVqmyMWlcMqkclqnaupWdGqlbyqnWrqm S5qlGrqiVfZ8Gepmc2qj/38KqGlqojX6oEYaqJC6qIeqqFWacR1aqC86p4kKqXsKqJfXpVa6 qZ3KRaMwGmRqp0uqoFSapU+IomxKpC2aqVcKpTr6Vpg6pUFqqT16qq66ozFqp44KqwbIp4om RqUaGm9qqHz6omQKq5rqqm36qLQ6rWw6qZu6rKOKqJrap8UGqroaqrH6rbEKRsdqF12qrJ5K Zc16q0zqrH6qrZUaqdaKorzqrexKqPRaoSA6pqIqqXB6qoJaReXKE6rqpIoKZ0XVozq6qLbK oTIXpRqGsPT6qXcKpSkIql8qsbUqq9CqdLZKscq1pxs3haSqKgE7ZAR6bQObJFI6bSnYhdk2 Cv8rG6A0W7M2e7ORdLI4K1wcixAYqrPR97IggbER0bIqCq0aMYY4wagUAbSz5qcX4bT6ehJS i7QLWoI9exNEK2UMS39OioKWimFeq7Acm6u4urB/SmcNm6ttVYBeu3FhK7Jb+rKGCrIWlrZA umkO+7bDiqYQ27DpWqlCK4bPOqXLiqp4eqaFW62Km7iFKqyIS3iyqrizariU2q/E17jsarkK FQr9eqOWW62Jiq6YS6fw+lNMW7qku7p5WrHjiqCs27f8GrmTu7nJOq+lC7qwa7ut+7nSyquv y7vKeqlWy1aFu64FK6nmhrGpq7y9irtBernAy7i8a7rCi4J7u6qxW6v/buqu0/u8kTu8lSu6 xtu7yMusuOu3meq95juv5xq+6/u72wq/qDqu1Ou8wDq1r1q98ku/Bzu+Vfs67wu/tSa97jt3 qbu7/jvAuRut6KuqCwy8zdu+uAa+/vq8p3u87brB9lq8VUQG4Bu9B/uxqIZsXSu6Sqi9f9u1 Feylp5vCcitU27q2aiutLIylYVrDCZu9F2y/ECukH9urg+tHAWzDElHEuYLEVLtkRjtmXpi1 xtLEOaHEO1vFVnzFWJzFRUuJNhqlj2vCSgq2D1ugQ7zCc9uyrZq0oAuJHSy48rq99du68Mq+ eaqtVHy1k3i7KarAo3q/l6u+5Iu0RMrA+4up/3m7o2LbpDk6xIX4veK6yGucvnW8EO5KqTHc sZLLpbOLydyaiPh6q5DcriArxnLmrZ8syBm7vsEav6S7v52MiI5sveNLva1cuc1byWm7sT48 w4B7rRT7g4yox/c6qxO8ruHquqi8x9S6xsbcwJa8uLCcr8usvcK7uYAMzXRMyDbczM38zBnc yPsKpBV4yCNLyvVqtGYsyawcqBoLxDRMwnesxfI8z/Rcz/Z8z/icz/q8z/zcz/6sIK3wzwJd aqUy0AZ90Aid0Aq90CyBDgzNEMJwFw790Aky0RQNgAIgADmR0fyc0R6t0RXB0QQh0iMN0hjx 0SR9EByd0hCR0iYtEf8szYkkHdMPwdIeXdIvHdIvTdMCwdM1PdM6HYozbdIfjdMDgdI5XdT/ oNQo3dMaDdJKXdJSvdIiTdVL/dRDHdM33dNOvdVVDdVgLdREHdZXzdVlPdQFgdU3bdVOfdVs bdM7rdZtbdVejdVtPdJlvdR5fdZk/dViHdV+PdVjndZdPdeDjdZ7fdeGfdR2zdZ8rdhmvdJ7 7deO7dOW6NhuXddrPdh4bdaPvdhdvdWMLdijTdeH3dSdLdmIbdqjDYqBndh5XdlJrdJ2Ddqw LdWlfdqfvdsGMda1HdtIndNi3dpATdlgPdu9/duyfdRpHdeT3djKrdyEXdiIDdy4/Ykufdz/ vv3Vv+3ZuI3a2U3TSK3YrL3aos3cxB3V1t3aF93e7v3e8B3fvWIH8j0s/VnfoXHf+G0X+r3f PNHfmzgOVgTg/l3gBn7gCJ7gCi5FMbDgDv7gEB7hEr6JTzzhEIGng7egDAqFMJzIYDzQeouA JZpqlKuDsBvPARriyUXOceejNepomqyBd4riADq2nnZrHOd9jXqDKijiL37QDwponSaAFyiA CRt8mUvjNBvkOXhhZCx+O97jPjhzPW7QTN69MK6uT455Uy5fSr6zXN6ChUfDP97kLBjOCh3m IYvGLi7ln1rKHl7lFj7ndF7ndn7neM6HXy4avoq1GEG8PktFe74T/99sxJH854xcoh4cfYcL tYdu6Efcu8zK4om842/evy4coejM4hoOxS5qv0iytX/eEYMO6VscuIE8bQcq6dKMzI7OuvuK wfKquz08fJ6OxyZ7w2frznqLpGHM6xPswqla6Xj7y78+uJmr675+6Ue+w8LO7JG8tYhqoLAe yihszaD+vb8quNTM7fHr7FhqHhJsptC7yZz77Q/spocKuQaM4T077o67uuYepx7srHTs6NAb ry+M7bVb6PmLrubOyYx+HKd8vrTb7hbswM/sv2+c76A+5tUM6whf67Wr8NAsoSXssOEK5/g+ yFIcqgCbqu+qzJQs7hpct+ysvGm8uOzLvP/lTs0SX7zwbsgpv+6OSvHJ7McXL+sC3/N/nO0s /8lxy6OPfMuFt6XFIcyq+8DY7vIVv/ATP8lRr/MNT8BMH8dOH+05v/P467pE281GrO2PKq40 n8DBG+sEP82TWsDOrMCPZvYuD/DU2s24DMjby/Z0L8cTiumFXO/VK8zVPvaz/rPjjPY6b/aG n/TsvKrFvuvEJsLNzsPCTraTf8a8jvN9y+1y66PLbsYeS77JjraTS7cdrvYKC3aQ/7creoOa PrFzDO6i/yrxHMCljutDS+qB/ugRVPsXV+EYP+qa5qCJfuFlfLRTxPt5nvzKv/xkiMTIT+i1 z/t1r/sh8fyq7ir/zr/qkY7vd4H8zs/IuGy2KQG0oj7wJc/9btvHqZL92390Sxy1777Nic+i 7S8S5a+/1u+ycuapxK7IbWqwAAHgn0AABf8NPFjQIEKBAxcqJJhQYUKHDQ9ehCjx4cSJDBdW pNjRokWNBDtWjIhRY0mMGS+y9EiS4suWD0vKlMkQ4UyXKV/2VGmy4VCRO0VyhCmUps6TNSOe dPlzKVGbT1cuxZpVq9aRQR16DZrT50yeRruONTmVLNqvZN3uDKkyZFepH32KdTsWrk65cfvm bbtXMGC2Umla9TtXrdyUdvkqPrx2b9q3lAePPGv4b2KPEhdvBR1ac2aSbHM+Bsy3NGq9/mU5 F968mi7ryKtRM64bGSxhzbxj15xM+3DRoUZzfzZe3KtsrMpp2959+S9sp6/hnj4tWrvu688h okX683tf5syrdzdfmfvjzIzDl8Xue7pnlAahyxeMM7jpj8v9fm+tvtnKOy6p6KgTbrS6xuMq pvdKa2o7CRWMKz3yohtMtdzSo6s963rb70Lz4igsQOduu6+1+0L8rUCmQKwtubcyjO9ExBLr 8MDgXMQLP9BuvFCyCYcM8kUdB8zPsMY2LDBH61bUbzcP2dsxQ+MwxIzH66L8sDfTtlzvxtlu S21J/6TE7UkQEexORy+fKzI7IkNDssSiqhPrTgeVA+q8r6iy/nGqo2ySjEGUqswOM7sGjcnP 985b8SYDQcqzqun0HI7QPXnCNCr7JlUv0j+VjHDSPicrdU5VV2V1xlZfHVJOOmGltVZbb10P V1135bVXX2H89VZZtxo2WGOPjRVZZZdltllnn4U2WmmnpbZaa6/FNlttt+W2W2+/BTdccccl t1xzz0U3XXVpLVbXdkV7FzlXm1tX0GzjxRbfWvVtUFgIZ50wKoCB7ZdeQfvL9TLiVjVUQn63 y1M87R526tGJMWX43x9jTTWrHicueF+NiQ2YYHgdDjk1eZMskkhRm424pWNfDplij0dOeWAr T4Y451eXpKpi1UrtsafwGARq0KBZ/j6YT4Glu8tALo081SqolG4Oa7Aa05PrjRD2eEFFP3bP Uq/VKm7p+oYGu2isAQV0rrhB2plhGbXUlGksYzzSSb434w1KtNFbEDnKOOyMsyrLHNxI+BSn +VI3AeePvjXv7lvlGfXSz0LLTsQQVqD/prJFF5P0fMcauXsUyErT/u90+WwbfW/TrzzO9din LjbFxaVu0uCtUQ/+dshJ/zJN0tmlL24OG4Y6V/4yol28Ty8nMCy8ageQxqqVxBxF6KvXrSpD p/xd+P2gj7H7MZ8mitPrcRy/8d9kG498lmwmua2oEc8Z55AnHeWhr3NMAhwCzQSsj1UPdrYL m/Lco7jd/oVJZxbamIriVL4Hwmlem9ObB9/UJjL9zH53iRrlwIc9maWOhBo8EpjelEIWJex9 Ijqd4CQIQgceb4cj7FLgikdCHkqJhgR0zf1aqKUX1k1VbvsaazomMKNd72idktmhsFNFp6lo YXnBGAj9RLiyzS1TYxLj9+bmqZqRCmyHMoumIIQwKAYNPG+EY1Ku6LVANc9i9QJkIAU5SEIW 0pCHROS2upBIZ52CkY+EZCQlOUlKVtKSl8RkJjW5SU520pOf9BXZxsU/apEtUdIiZbVm8MR9 HfJpMMLJK3nGqmGhkZYwM5z95pRK9fwIZ/3bpclWpr5W8VJbLxNl5JxlS3I1/9BnKDNhwH7p rgTeknmETNSd6ncmNTZKj227Cp7olkftVUiLi4KdLZGmTTauREzAsx5ikoZOOnozd3F0Dh9h EsE5po1Q63wKPf8Dv3FezZgzU5/uZhgo0hiQhREMDIIcYykhhaWi+FEo7hxXuc/k7XO/++g9 SxS+9E0ucY6TYuZAisYAeUtRIdIhjsDXQRQ9VHgunI+HWFrDnCJQSOZZYAmbGEMlFlWhtZvP zSyYvSAmD6Q2FdcBz1SZ7+GGppzb5htv2L0Zokl+Tu3pVDVKUT7Oj3UVA6tUe2m+dta0mgmC E+0Ymr+kJtVooxygRDs6UzUJM1JbBSaVBhSMKcFQTf7646ZG54WkpUI1ShTlmwDfmk+8LQ6s F+UdEQ+K0BhmCZZ1LazeMntWk9aQhv9LGJiYmjdzYtZKjO1rYIIYPav6MIlBSh0KK+tV2ZpW mMfkovxCiKr+hBaOr1RK1lRHtG7+1GLZ1GcccfdF4oJOYv0sk1nhSsDmBleMX/UNUpQ2NjBK FrwdA2VUedW7kqX3WZt1onsLCV+TyXJj8kWWfTmGR/z217//BXCABTxgAhfYwAdGcIIVvGC8 5su/m6Uvg81lzKmlVpre1Z7WLCwnCPeKssRC728vxt9l6VfCFk4WyKwJROsqU8WiCxYz6/rM 9sY3xieGFN28G921behrZv603sqg0+I1rdGbBAXvkVvHNmdWSLzgJC1dDfrhOBkUVFTTcAKT Zk9Q4q+AheNp5/xGs1hi8at9rKxjaKTS6YI5pu3x7HBDO9Eh/pSJTwJdTHMavw9m0oWAxegA NUvjBK1OhUxV7PDcBOj0WS2Jf4XKWMNMwbbC1amjVSFvbVxJ961QQFuinmNde0aSIfbOnfV0 ZOn6ZSMil2qj5qek8bfl8qG1ebvNzza7qjlPmvKiv36q/t5c6lSf+rDFVvQIGV3LVw+6X0G9 LKV/SFSZ+jWXN0zvn8NqWrW22XSZFbax44rslo10LUeMj515PWTypFXLEsztEnv53dmR289m 9v9fp6zcbc/KErlTvpRAF0PrcycU31G84ykratbXeelTci1uQr/pqIfHc5+kPq7Q+ozjb5Ey woKkMMg5PkibkXiTIRc5jlMwcpa33OUvh3nMZT5zmovmEzXHec7vq52b65y+H2elzrcFtx8n pOchFApHZh1qsY2tbRhLOjHbFfFiRnPTFj9j0S++cUK/mOuBrXHPEonpKyVTYUAk3m1z2SZ1 olhib4XmivWl50CLGKJ2+zquWho2oJdy7bXeK20t+zfrJprt7857CqsqXcoR5+kPF3gq7o7E 7SY3j9RjFJNvSvElK36KzkaeidVrQeVuXvC+K166TwlbCs1qzjiUl5f+v0tnuUg+9qeq/OtT ezgGDjrexiV877GtrmQ2BY8dWjWaUTflx/Pu84l/XG2Dejs2MRouqbD9xt29a2mfkGC+i7eG Mi3pKNu948MsON/HTx2pylji06bgOAv16RfFed7b9T37eksvnBJm1Q6fH676OxHSEOVTN7k5 wKvrFlFaodVbv8FLPbFTGQd8MSDxD7KbNNKKP/Pbvm17wGrbuUkDKvKLJwPsMRcDF19LEwqk PKrDrWlTPnbzkcBiuJZZN3Gzvgq7rQ4MtCYrncXivgA8rctpkgrTrXoxQnwLk/+TrUrZs6qJ ENTTQRoEsgFxQawTlRokp5vIJ4DbuuUSuHz/Yzj0KrOXsiPNIhoOMi/h6rsSEzqXuZY2PKah CyQ5ZDA7TLFJwsML28M39MM/BMRAFMRBJMRCNMRDRMREVMRFZMRGdMRHhMRIlMRJpERGOoFK xMRM1MRjwYZN9MRPBMVQFMVRJMV/sIdSRMVUVMVVZMVWdMVXhMVYlMVZpMVXAYNaxEWXG4AB GLld1ApfnBNgzMWl2MVi5MVeEUbQSMatEMZlDA1gdEYiiUbRMMZmPEZivEaamMZpfIlqPAhn 9EVufMZsXBVv/EZyxMYhAUd0/EV2/CRrREZ3LMdrFEesgEZ5DBZ4VEZ8zIp6TEZe5MZ6ZEZ+ 1I5/PMd9VMd/FMgB/4PHcDzHYjxIiHzIY3RIb7xHbQTIjERHi9TIizDGdPyHe5TIkORIj8xI kjxIkhxJk+zGk1TJiTxJl/xIc7THbIzJiwzHi0zJl0RJidRHnmzJblRJa6TIjxzKgRTJotTJ nJxImMykhoRIqCxKlOxJn6THqQxKqwRJnmRKqmxJnaxKloRKquxKr9zJsITGnZxJl2TJgcTG qcxJuLzKb4xInJzLkDxLs2xLuiTLuwzIobzJuhRMhdzLShpLtWTLrixLrwRLwcxLxpzLxmxK yKTMsbTLwjRLplzGn1xMvdzKvdTMyLxLsRRNzFzHkYxGsJRMoeRKmVRKuQzKx5SkasTKyv8U zbWMzcnMytEEzdtcyd4kzeB0TKP8ybNUTM4szdzsx40szcPsy6hMzucUx8Y0R6L8TdbEy7o0 StvMzYU8pHUETuc0Tpu8zrIET8T0TIwMz+g8TtUkR8IkTMp0TMy8CCcwTu50zuPkzuF8z9jU R/ekxpr0TOJkS/m0pPPcz7Cky/ikTwUd0NE0TwFFT5EkSXx4SeQ0Tb8EyJTE0M0kT/X0SPxM Tuicz/bsS230Tw1FT77cTAFtxhNdzP8kSEJCUMCEyauUTNRkR/PcUR7VTRB1yod8TgdVyPKk SQo1ycR8zSR9zOpsTg11TRLl0PY8zSIN0tYszuwEUQLlz6Tkzf7/8k6EPABxCdNuKVNKOtM/ TFMBHdNwWdNsmVFMitNSbNNhtFNqqdM71dNnydM99VNl6dM/FdRfCdRBNdRX6YVDVdRFZdRG ddRHhdRIldRJpdRKtdRLxdRM1dRN5dRO9VRcHIJPvdRQFVVKJdVSndRTRVVIVdUDC4AAWFXt eNVZPYhZpVVbfdWlwFVY/YdcvQhe/VVc7VVgHdZh9VVhfYlQ3dVaJVZYXdaX8NVaZVZbZdZf DVaaeNZlRdZsRVZjpVVovVVhPVZqxdZt7dZnBdesiFZvzVVu1cR1dVZivVZdbdZ4BVZ5rdZ8 zddxhdZkhVd7tdZ1Ldd7LdZrHVdeFdho/21Xef3XdFVYhMXXdJ3XYoVXrHhYh63XcrXYb51Y gS1YTKxYj/1Yia1Wjo3Yi51XfrVWkqVYhR3ZgQ3YjD1YfdXXhdXYiW3ZlI1YnPXYiqVXno1X ln3ZaWXYe8VXkY3Enj3ZpXXYgmVamlVZpIVaZ3XaoY1ZaW3YY+1Vmv1Ym2XZrDVarr1ZsZXa jpXZjBVap0XboS1bR5xZdBXZrC3ZjQ1WdyXao5XZuUVXaaXYkT1Ye8VbctVWagVbcmVXvE1b dlXXsDXYtSVbiCVZuwXZsI3bp53bvv3ZqRXbl5XbvpVayA1anV1YpW3csfXboG1YrUhd1bVc sBVa0j1dnN3cpP+lXMv9WqqdVrrV3KqV3c41Vqvl299NXcLlWLPlXMf1WpRd3LR1XOMt3d4t Wrhl3ER8hTm52MrV3cv93cyNXd7lWt8NV9Wt2+7t2tYNXaDFWJ3ditVd2c1V3pyFXtNVXtgl MCKolsE1XKTN1sR939GF2OKt2289W8MNXrUl4PcN4L/12gSG3MYlYG+V3btdXgam4IENX+c9 3NmN1Q3m4A724A8G4RAW4REm4RI24VpEWXPN3weGYMWlVwEW1xgm3gXeWhcG1xU+4Hpd4e9V YQCW4NsVXQXe2c/FYRj+WdjdVQbIYME1134FXpiL2mYtX7/NXJ/lWatNWLQ1WSqO3Ab/tmDn VdmxZV8ubuEpDtmdDeDs3drCveHtzd3VHd4BXtm2bbkFPuPnLeB9leKvxeKildgttuKa9eIb nl74xd7dvWKiNd47Xl8fpuLC/V/AVWQ41mI55ls6Zrkc5l4a1t2ypd/X1eKq9WTGReJB/tsJ jl1kiGC1FWS2RWNWNl3NBVzUVVwa7l9TplqtfWIcCwKY/WP/DWNU7lbRzWAe/mO9/V8Lflgm 1uNf1t9CzuJO9mIFvlvEdWXuxVwjTmb4bWX1NdjLxeSR0+SSrV3QOORFtt3uBd0pTt8IjuIu Zl305d8GRmBulmZsluX2bVd9Pl92buZvzuZXdjk7LmdyduJj/45fg8bn4R1fBA7jLB5ceBbm 5j3jiNZee1ZmAGbkiwZojaXkX27a3PXDd1Zoe7Zmii7oWGboNy5kdo5mPB5jiTbmq4Vp3C1p bH5prM3bI6bbj/Zm7TXinEthGTZZFmZiR8bfohbjW3VmjR7gCybnByZiQq7coNbjooZhqW5e G95fnq7iYV7mSNblfz7hsjbrs0brtFbrtWbrtnbrt4brjpXnav7hMZ5hp77rT5Zeo27i9qVr 143q4u1hvR7kuiZqIV5ixOXWvF7avnbbbQ7rpe7XmI5pDP7X+S1sIN7iTT7bmoZafy7jYH5k P+7m49VhMybtXYblxxbpyJbpNd7qyv8u7cuG5n6WX4DN49LmZoL+bEoeavk9XsuO3khGbcmO Zw0+RK2lZ1x259jeauH2ZsBW430e69fm7d++bbLm64WeXoeu5fPl5Hp+7Ua8658G7Wom7OMu 5n+G5JwO6Bpeaotu2Ry2alh2bWX+6+42WsJt7VkWa/9u5MRVxPIm6/Mm37nm7OBebYzWbGbN AfNt55yd6jhG5HiGaMFuaYIt6fC2bZwWaEMk8F3F7Ml2bgF36f2O4Qj3cPhG6tou7q5VcWBW al1VceD17iNO6QKPZUocceim6cc18R6XbtFucJE27g0Hb4SN8GAW784W8Bv36Bw38JmGxB7X bcc27Za27n5flvEKpmolX+VbNuym/u+5fuashur4ZmocP+o0P2fkjus4l/M5p/M6t/M7x/M8 1/M95/M+9/M/B/RAF/RBJ/RCN/RDR/REV/RFZ/RG1zkHcPRIl/RJj+sxoHREtHSzDggAOwAA== ------=_NextPart_000_0005_01C6D28C.5C1E1E90-- From rochee@curtis-ne.com Fri Sep 08 00:41:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLY9f-0001mM-OZ for capwap-archive@ietf.org; Fri, 08 Sep 2006 00:39:51 -0400 Received: from 201-25-163-222.ctame704.dsl.brasiltelecom.net.br ([201.25.163.222] helo=curtis-ne.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GLXwX-0007qo-4P for capwap-archive@ietf.org; Fri, 08 Sep 2006 00:26:21 -0400 Message-ID: <000001c6d2fe$dfa90500$8bfba8c0@pwgvn> Reply-To: "Maurine Dees" From: "Maurine Dees" To: capwap-archive@ietf.org Subject: Re: PHAhdRMACY Date: Thu, 7 Sep 2006 21:25:54 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6D2C4.334A2D00" 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.2 (+++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6D2C4.334A2D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 All y j our P u HAR o MAC b Y dir a ect x ly from the m l anufa s ctu s rer, Your c g han e ce to eco s nomiz g e wit h h us http://www.paliyuihadesun.com ------=_NextPart_000_0001_01C6D2C4.334A2D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
All y j our = P u HAR o MAC b Y dir a ect x ly from the m l anufa s ctu s rer,
Your c g = han e ce to = eco s nomiz g e wit h h us http://www.paliyuihadesun.com<= /DIV> ------=_NextPart_000_0001_01C6D2C4.334A2D00-- From potei@armack.com Fri Sep 08 09:35:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLgVd-00050a-Lk for capwap-archive@ietf.org; Fri, 08 Sep 2006 09:35:05 -0400 Received: from [61.134.104.177] (helo=armack.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GLgVZ-0002go-JM for capwap-archive@ietf.org; Fri, 08 Sep 2006 09:35:05 -0400 Message-ID: <000001c6d34b$906601d0$b037a8c0@vmpunmb> Reply-To: "Wade Doctor" From: "Wade Doctor" To: capwap-archive@ietf.org Subject: Re: PHAzpmRMACY Date: Fri, 8 Sep 2006 06:34:52 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6D310.E40729D0" 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.5 (++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6D310.E40729D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 All yo j ur PH u ARM j AC k Y di w re o ctl v y from the ma i nu j fac k ture h r, Your c z han j ce to e s con c omiz r e up t x o 50 y % wit p h http://www.koudriahi.info ------=_NextPart_000_0001_01C6D310.E40729D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
All yo j ur = PH u ARM j AC k Y di w re o ctl v y from the ma i nu j fac k ture h r,
Your c z = han j ce to = e s con c omiz r e up t x o 50 y % wit p h http://www.koudriahi.info
------=_NextPart_000_0001_01C6D310.E40729D0-- From billtoll@bjm-law.com Fri Sep 08 10:07:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLh0n-000065-Di for capwap-archive@ietf.org; Fri, 08 Sep 2006 10:07:17 -0400 Received: from host219-172-static.106-82-b.business.telecomitalia.it ([82.106.172.219] helo=bjm-law.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GLh0l-0004cG-QR for capwap-archive@ietf.org; Fri, 08 Sep 2006 10:07:17 -0400 Message-ID: <000001c6d350$039a5c10$e7cea8c0@osnp> Reply-To: "Ihintza Rushing" From: "Ihintza Rushing" To: capwap-archive@ietf.org Subject: Re: PHAqjhRMACY Date: Fri, 8 Sep 2006 07:06:43 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6D315.573B8410" 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.7 (+++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6D315.573B8410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 All y v our PH h ARM d AC m Y d c ire y ctl w y from the ma c nu t fact a ur q er, Your ch g an l ce to e h con n omiz v e up x to 5 j 0 % w c ith http://www.hadefunkadestui.com ------=_NextPart_000_0001_01C6D315.573B8410 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
All y v our = PH h ARM d AC m Y d c ire y ctl w y from the ma c nu t fact a ur q er,
Your ch g = an l ce to = e h con n omiz v e up x to 5 j 0 % w c ith http://www.hadefunkadestui.com
------=_NextPart_000_0001_01C6D315.573B8410-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 08 11:04:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLhuV-0000an-84 for capwap-archive@lists.ietf.org; Fri, 08 Sep 2006 11:04:51 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLhuT-0003lt-DG for capwap-archive@lists.ietf.org; Fri, 08 Sep 2006 11:04:51 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 023764315CB for ; Fri, 8 Sep 2006 08:04:46 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4D4F243008C for ; Fri, 8 Sep 2006 08:03:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2C99E430A18 for ; Fri, 8 Sep 2006 08:03:31 -0700 (PDT) X-Greylist-Status: Sender first seen 17 days 05:57:11 ago Received: from mx01.sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by hermes.tigertech.net (Postfix) with ESMTP id 17DC143158C for ; Fri, 8 Sep 2006 08:03:23 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Sep 2006 08:03:23 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Data channel policy negotiation Thread-Index: AcbR9HJXZna0kONmTp2TVqMcGiG51QAEGktwAFNvhnI= References: <8A76136424391244A5CF016533708537020EEC11@mvebe101.NOE.Nokia.com> From: "Hasan Raza" To: 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, HTML_30_40, HTML_MESSAGE X-Spam-Level: Subject: [Capwap] Data channel policy negotiation 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="===============0075935614==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 This is a multi-part message in MIME format. --===============0075935614== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D357.EDBD11AB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D357.EDBD11AB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I feel that there are few ambiguities in the capwap 02 draft related to the tunnel creation and data plane policy negotiation. Forgive me if these points have already been brought up and discussed over this list. 1. Draft -02 does not talk about when the capwap data tunnel is created or deleted. Is it implicitly assumed that data tunnel is created once WTP and AC reach join state? 2. From the draft, WTP can encapsulate and tunnel wireless packets differently for different wlans. That is why, tunnel mode is passed to WTP in dot11 add wlan message element. But how different type of tunneled packets are identified over the data plane? For e.g., bss0 tunnels 802.3 frames whereas, bss1 tunnels 802.11 frame. So when a capwap data packet arrives at AC, how the employed tunnel mode is identified? Capwap transport header does not carry any payload encapsulation type. Moreover, the radio mac address optional field in capwap transport header may need to carry bssid instead of radio address -- there are multiple bss on a radio. 3. Draft does not also talk about how WTP is informed whether DTLS is used over data channel or not. Since it is a modifiable = parameter, administrator can decide to turn on DTLS for say wtp0. But how wtp0 would know that administrator has changed this setting? wtp0 might still be sending plain packets which get discarded by the AC. = Actually AC should inform this change over the capwap control plane to the WTP. But there is no such notification to WTP for this. Is that the data plane policy is supposed to be vendor specific = information, and it is exchanged through vendor specific payload message element? Thanks Hasan ------_=_NextPart_001_01C6D357.EDBD11AB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Data channel policy negotiation

Hi,

I feel that there are few ambiguities in the capwap 02 draft related
to the tunnel creation and data plane policy negotiation. Forgive me
if these points have already been brought up and discussed over this
list.

1. Draft -02 does not talk about when the capwap data tunnel is
   created or deleted. Is it implicitly assumed that data = tunnel is
   created once WTP and AC reach join state?

2. From the draft, WTP can encapsulate and tunnel wireless packets
    differently for different wlans. That is why, tunnel = mode is passed
    to WTP in dot11 add wlan message element.

    But how different type of tunneled packets are = identified over
    the data plane? For e.g., bss0 tunnels 802.3 frames = whereas,
    bss1 tunnels 802.11 frame. So when a capwap data = packet
    arrives at AC, how the employed tunnel mode is = identified?
    Capwap transport header does not carry any = payload
    encapsulation type. Moreover, the radio mac address = optional
    field in capwap transport header may need to carry = bssid instead
    of radio address -- there are multiple bss on a = radio.

3. Draft does not also talk about how WTP is informed whether DTLS
    is used over data channel or not. Since it is a = modifiable parameter,
    administrator can decide to turn on DTLS for say = wtp0. But how wtp0
    would know that administrator has changed this = setting? wtp0 might
    still be sending plain packets which get discarded by = the AC. Actually AC
    should inform this change over the capwap control = plane to the WTP.
    But there is no such notification to WTP for = this.


Is that the data plane policy is supposed to be vendor specific = information,
and it is exchanged through vendor specific payload message element?


Thanks
Hasan

------_=_NextPart_001_01C6D357.EDBD11AB-- --===============0075935614== 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 --===============0075935614==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 08 17:01:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLnTV-00024Q-1Z for capwap-archive@lists.ietf.org; Fri, 08 Sep 2006 17:01:21 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLnTR-0001FK-4r for capwap-archive@lists.ietf.org; Fri, 08 Sep 2006 17:01:20 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id B4021431BD0 for ; Fri, 8 Sep 2006 14:00:56 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7CCA443008C for ; Fri, 8 Sep 2006 14:00:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 46E78431BA1 for ; Fri, 8 Sep 2006 14:00:04 -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 63F46431BA0 for ; Fri, 8 Sep 2006 14:00:01 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 08 Sep 2006 14:00:01 -0700 X-IronPort-AV: i="4.09,134,1157353200"; d="scan'208"; a="442810902:sNHT33460488" 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.20060308/8.12.11) with ESMTP id k88L00oe008005 for ; Fri, 8 Sep 2006 14:00:00 -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 k88L001E009414 for ; Fri, 8 Sep 2006 14:00:00 -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); Fri, 8 Sep 2006 14:00:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Sep 2006 13:59:59 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC01FEA481@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Insufficient description of WTPs during discovery Thread-Index: AcbTib7+aXE/pRhrRT+b/gAI5ZZ9YA== From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 08 Sep 2006 21:00:00.0210 (UTC) FILETIME=[BF6B5320:01C6D389] Authentication-Results: sj-dkim-4.cisco.com; header.From=boohara@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: [Capwap] Insufficient description of WTPs during discovery 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: cd26b070c2577ac175cd3a6d878c6248 Sorry for the long email, but I think this issue requires some background discussion, as well as the proposal to address the issue I am raising. In the Discovery Request there is a WTP Descriptor to provide the AC with information about the WTP. This descriptor provides insufficient information to the AC, if the type of WTP is not know in advance. If the WTP is not supporting 802.11, this descriptor does not provide enough information to the AC for it to make that determination and there is insufficient space in the WTP Radio Information element to make up for this lack. If we are to produce a protocol that is able to support several different types of existing wireless protocols, there needs to be a clearly articulated way to describe the protocols supported on the WTP, during the discovery process. It is quite possible that an AC will not support all wireless protocols, as CAPWAP is applied to these other protocols in the future. The WTP needs to be able to clearly specify what wireless protocol(s) it supports to the AC in the Discovery Request and the AC needs to be able to indicate to the WTP that it does, or does not, support the specified protocols. This could be done in several ways. I propose that the WTP Radio Information element be extended to include a 16-bit protocol ID field that contains a single value from an enumeration (probably eventually managed by IANA) of the protocols for which a binding document has been published by the IETF. Because it is conceivable that a WTP might support more than one wireless protocol (say 802.16 and 802.11), I propose that the protocol ID field be repeated in the descriptor, with a count field preceding it, as often as is needed to list all the protocols in the WTP. I also propose that the protocol ID field be added to the WTP Radio Information element and that this element be repeated in the Discovery Request as needed to provide information about all the radios for each protocol in the WTP. Finally, I propose that the Discovery Response message include a new message element, the Supported Protocols element, to indicate to the WTP which of the WTP's wireless protocols are supported by the AC. This information can be used by the WTP to determine the AC to which it will subsequently send the Join Request. The Supported Protocols message element will include the list of protocol ID supported by the AC. This Supported Protocols element could be constructed by the AC in two different ways. One way would be to construct the list statically, at compile time, and always return this entire list. Constructed in this fashion, the list would always have at least one entry. The WTP would then scan this list on receipt and determine if one or more of the protocols for which it needs support are present. An alternate way to construct this element would be for the AC to put only those protocols indicated by the WTP in the Discovery Request for which the AC provides support into the list. Constructed in this fashion, the list might be empty, if there are not matching protocols shared between the AC and WTP. The WTP would still scan the list on receipt to determine if one or more protocols for which it needs support are present in the list. Regardless of how the AC constructs the list of supported protocols, the WTP still makes the decision as to which AC it will join. In the Join Request, the WTP MUST send only those protocols in the WTP descriptor that have been indicated to be supported by the AC to which the Join Request is sent. In this way, a WTP that supports multiple wireless protocols might be supported by more than one AC. -Bob Bob O'Hara Cisco Systems - WNBU Phone: +1 408 853 5513 Mobile: +1 408 218 4025 _________________________________________________________________ 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 Sep 08 17:32:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLnxF-0000Y8-EH for capwap-archive@lists.ietf.org; Fri, 08 Sep 2006 17:32:05 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLnxC-0005O0-Sa for capwap-archive@lists.ietf.org; Fri, 08 Sep 2006 17:32:05 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 268F8431C66 for ; Fri, 8 Sep 2006 14:31:59 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4D99D43008C for ; Fri, 8 Sep 2006 14:31:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1B6E939806A for ; Fri, 8 Sep 2006 14:31:07 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 27ABB39806C for ; Fri, 8 Sep 2006 14:31:03 -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 k88LV1gr002619; Fri, 8 Sep 2006 14:31:01 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k88LV0tT002612; Fri, 8 Sep 2006 14:31:01 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 8 Sep 2006 14:31:00 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Bob O'Hara (boohara)" In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC01FEA481@xmb-sjc-237.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] Insufficient description of WTPs during discovery 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: 36c793b20164cfe75332aa66ddb21196 HI, Interesting... At a higher level, we need to discuss the discovery process. It's too bad that we didn't do this at any of the IETF meetings. The reason is that it seems that there are two opposing views as to who decides the binding between a WTP and AC, and also two opposing views as to the ammount of information that should be in discovery messages (which are sent "in the clear"). I suggest that we first list the scenarios, and then list the possible aproaches. In doing this, all the assumptions need to be made visible. For example, does an WTP have other management interfaces (such as a CLI) or is CAPWAP the only management interface to WTP? Does a WTP have "field replacable units" so that different technologies for interfaces can be installed, and thus making WTP model type insufficient for determining the interfaces on a WTP? So, there are many items in the below that I fundamentally disagree with, specifically "a WTP still makes the decision as to which AC it will join". I do this because it can result in nondetermanistic behavior, and can be a security risk. Regards, /david t. perkins On Fri, 8 Sep 2006, Bob O'Hara (boohara) wrote: > Sorry for the long email, but I think this issue requires some > background discussion, as well as the proposal to address the issue I am > raising. > > In the Discovery Request there is a WTP Descriptor to provide the AC > with information about the WTP. This descriptor provides insufficient > information to the AC, if the type of WTP is not know in advance. If > the WTP is not supporting 802.11, this descriptor does not provide > enough information to the AC for it to make that determination and there > is insufficient space in the WTP Radio Information element to make up > for this lack. > > If we are to produce a protocol that is able to support several > different types of existing wireless protocols, there needs to be a > clearly articulated way to describe the protocols supported on the WTP, > during the discovery process. It is quite possible that an AC will not > support all wireless protocols, as CAPWAP is applied to these other > protocols in the future. The WTP needs to be able to clearly specify > what wireless protocol(s) it supports to the AC in the Discovery Request > and the AC needs to be able to indicate to the WTP that it does, or does > not, support the specified protocols. > > This could be done in several ways. I propose that the WTP Radio > Information element be extended to include a 16-bit protocol ID field > that contains a single value from an enumeration (probably eventually > managed by IANA) of the protocols for which a binding document has been > published by the IETF. Because it is conceivable that a WTP might > support more than one wireless protocol (say 802.16 and 802.11), I > propose that the protocol ID field be repeated in the descriptor, with a > count field preceding it, as often as is needed to list all the > protocols in the WTP. > > I also propose that the protocol ID field be added to the WTP Radio > Information element and that this element be repeated in the Discovery > Request as needed to provide information about all the radios for each > protocol in the WTP. > > Finally, I propose that the Discovery Response message include a new > message element, the Supported Protocols element, to indicate to the WTP > which of the WTP's wireless protocols are supported by the AC. This > information can be used by the WTP to determine the AC to which it will > subsequently send the Join Request. The Supported Protocols message > element will include the list of protocol ID supported by the AC. > > This Supported Protocols element could be constructed by the AC in two > different ways. One way would be to construct the list statically, at > compile time, and always return this entire list. Constructed in this > fashion, the list would always have at least one entry. The WTP would > then scan this list on receipt and determine if one or more of the > protocols for which it needs support are present. > > An alternate way to construct this element would be for the AC to put > only those protocols indicated by the WTP in the Discovery Request for > which the AC provides support into the list. Constructed in this > fashion, the list might be empty, if there are not matching protocols > shared between the AC and WTP. The WTP would still scan the list on > receipt to determine if one or more protocols for which it needs support > are present in the list. > > Regardless of how the AC constructs the list of supported protocols, the > WTP still makes the decision as to which AC it will join. In the Join > Request, the WTP MUST send only those protocols in the WTP descriptor > that have been indicated to be supported by the AC to which the Join > Request is sent. In this way, a WTP that supports multiple wireless > protocols might be supported by more than one AC. > > -Bob > > Bob O'Hara > Cisco Systems - WNBU > > Phone: +1 408 853 5513 > Mobile: +1 408 218 4025 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 sfpgqnhiu@rima-tde.net Sat Sep 09 07:59:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM1UL-0004St-SF for capwap-archive@ietf.org; Sat, 09 Sep 2006 07:59:09 -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 1GM1UL-0007tj-NV for capwap-archive@ietf.org; Sat, 09 Sep 2006 07:59:09 -0400 Received: from 105.red-83-36-153.dynamicip.rima-tde.net ([83.36.153.105]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GM1UF-0005ZY-UP for capwap-archive@ietf.org; Sat, 09 Sep 2006 07:59:09 -0400 Message-ID: <000d01c6d407$4d3cfd20$69992453@oema2ze9008rv8> From: "zone exSoviet" To: capwap-archive@ietf.org Subject: Builds Date: Sat, 9 Sep 2006 13:58:45 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C6D418.10C5CD20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.9 (+++) X-Scan-Signature: ea36de7a5e28e9b4461c8d685f4e97f1 ------=_NextPart_000_0009_01C6D418.10C5CD20 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01C6D418.10C5CD20" ------=_NextPart_001_000A_01C6D418.10C5CD20 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Reddy Fulton Brunch Saturday travels traction with. generally hateful = gay marriage taxes. froth mouth important do. AMPS. blogged adoption. = holy object giving unwanted children AMI secondary folks. bank retail = handled money. true TAKES STATESby LAST CHANCE TODAYby PHOTO BLOGby comment/ moreCUTE = OVERLOAD DOT COMby DEADLINE MONDAY AMONG TOP DEALS: ROUNDby linkDEREK = POWAZEK INTERVIEW BY moreMEET CANVAS BAGSby BLOGTHE products special OLD = StatesUSA Peoples Republic TheNew Kingdom ffb Negative Slidemm BampWmm = Holga Strobe LCA Fisheye Adaptor Plastic Yasuhara Horizon Camera XPro = Eight Circle No. Five Filter SetHolga Maniac Upgrade quotHolga APS Slave = Flex AlbumLove Edition Erector SetMinox GTS Pinhole Packages Polaroid = TLRSharan Canvas liteSling BagSmall Cup Through Stability PackWide Angle = Panoramic GoldZenit SLR Chest MFZenitar pouvez lutiliser vous vos sites. Avonmdash Based Ajax TopNews :yes = jobmdash Praca draggable offering gateway Mail.app Messinger :Thanks = links... Alex Ronald :Just thought aggreator CRNH.COM publishes industry = jobs software engine specific Robins :I useful additions tools. = bugger... automated PTSD Sony ranks newer firmwares homebrew WebNab = DrNicket :The Bizz FeedLiner different Readers reason why try.mdash = Karel Petrzela :This days ago. Its date. Motahed :Online T.Reader = password Itd GRex :Great Orlando Bloom Takuya Kimura Ralph Fiennes Christian Slater Antonio = Banderas Brad Pitt Johnny Depp Raoul Bova Benicio Toro James Dean = Freddie Prinze Diesel Colin Farrell Affleck Leonardo DiCaprio Actress = Charisma Carpenter eae Holly Marie Combs Claire Forlani Cameron Diaz = Leah Remini Leoni Valance Bridget Fonda Jaime Pressly Milla Jovovich = Crista Nicole Pamela Anderson Virginie Ledoyen Winona Ryder :GRex Spare Part Test: Which :T.Reader General Coal :Moritz Zwar MBEasy Capture photos MBNotepad ATech GroupHTML syntax utlimited etcHTML = Bill: interface JulBuy KBAJ SoftHelp MBD DNA cool cell.D DNABuy Studio = manage GoldSoth Inc.Make MBCustom Pictures maker.Buy MBFlyer Builder = MBfree football sport makerchm editorcss editornc editorogg editorogm = editorsvg Clocks Alarms Cursors Savers Themes Education Graphics = reviews: Synapse .Rating: loved player winamp fantastic perfectly = med...MP Cutter Finnaly wav mp...that searching Tv Pc Elite bought = program channels withdrawn stricken resort leaving future. Federal Agency Peace European = Economic Committee SRI Biosoft GIL.. News.. FTP BIOSCI newsgroup = biology. Moderated postings ------=_NextPart_001_000A_01C6D418.10C5CD20 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
Reddy Fulton Brunch Saturday travels traction with. generally = hateful gay marriage taxes. froth mouth important do. AMPS. blogged = adoption. holy object giving unwanted children AMI secondary folks. bank = retail handled money. true
TAKES STATESby LAST CHANCE TODAYby PHOTO BLOGby comment/ = moreCUTE OVERLOAD DOT COMby DEADLINE MONDAY AMONG TOP DEALS: ROUNDby = linkDEREK POWAZEK INTERVIEW BY moreMEET CANVAS BAGSby BLOGTHE products = special OLD StatesUSA Peoples Republic TheNew Kingdom ffb Negative = Slidemm BampWmm Holga Strobe LCA Fisheye Adaptor Plastic Yasuhara = Horizon Camera XPro Eight Circle No. Five Filter SetHolga Maniac Upgrade = quotHolga APS Slave Flex AlbumLove Edition Erector SetMinox GTS Pinhole = Packages Polaroid TLRSharan Canvas liteSling BagSmall Cup Through = Stability PackWide Angle Panoramic GoldZenit SLR Chest = MFZenitar
pouvez lutiliser vous vos sites. Avonmdash Based Ajax TopNews = :yes jobmdash Praca draggable offering gateway Mail.app Messinger = :Thanks links... Alex Ronald :Just thought aggreator CRNH.COM publishes = industry jobs software engine specific Robins :I useful additions tools. = bugger... automated PTSD Sony ranks newer firmwares homebrew WebNab = DrNicket :The Bizz FeedLiner different Readers reason why try.mdash = Karel Petrzela :This days ago. Its date. Motahed :Online T.Reader = password Itd GRex :Great
Orlando Bloom Takuya Kimura Ralph Fiennes Christian Slater = Antonio Banderas Brad Pitt Johnny Depp Raoul Bova Benicio Toro James = Dean Freddie Prinze Diesel Colin Farrell Affleck Leonardo DiCaprio = Actress Charisma Carpenter eae Holly Marie Combs Claire Forlani Cameron = Diaz Leah Remini Leoni Valance Bridget Fonda Jaime Pressly Milla = Jovovich Crista Nicole Pamela Anderson Virginie Ledoyen Winona = Ryder
:GRex Spare Part Test: Which :T.Reader General Coal :Moritz = Zwar
MBEasy Capture photos MBNotepad ATech GroupHTML syntax = utlimited etcHTML Bill: interface JulBuy KBAJ SoftHelp MBD DNA cool = cell.D DNABuy Studio manage GoldSoth Inc.Make MBCustom Pictures = maker.Buy MBFlyer Builder MBfree football sport makerchm editorcss = editornc editorogg editorogm editorsvg Clocks Alarms Cursors Savers = Themes Education Graphics reviews: Synapse .Rating: loved player winamp = fantastic perfectly med...MP Cutter Finnaly wav mp...that searching Tv = Pc Elite bought program channels
withdrawn stricken resort leaving future. Federal Agency Peace = European Economic Committee SRI Biosoft GIL.. News.. FTP BIOSCI = newsgroup biology. Moderated postings
------=_NextPart_001_000A_01C6D418.10C5CD20-- ------=_NextPart_000_0009_01C6D418.10C5CD20 Content-Type: image/gif; name="credit.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c6d407$4d3cfd20$69992453@oema2ze9008rv8> R0lGODlhvAF4AocAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAALAAAALAAAAAC8AXgCBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu37sE9dvPq3cu3r9+/gAMLHky4sOHDiBMrXsw4KJ7GkCNLnky5suXL mDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH05c9Jbi yJMrX868ufPn0KNLn059853q2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djy59Pv779 +/jz69/Pv7///wAGKOCABBZo4IEIJqjgggw26OCDEEYo4YQUVmjhhRhmqOGGHHbo4Ycghiji iB2WQ+KJKKao4oostujii//0AuOMNNZo44045qjjjjz26OOPQAYp5JAmNUEkdcYcqeSSTDbp 5JNQXkYBehFEaeWVWGap5ZZcdunll2CGKeaYZJZp5plopqnmmmy26eabcMYp55x01mnnnXjm qeeefPbp55+ABirooIQWauibExyaVKKKHsVoX404+WijRE0wKaVCXYrpplDKwKlQnrJoB2eh fgpUqab6hGqqPK3Kqk7/rr6KU6yy2kRrrTTdiuuuvPbq66/ABnvYlMIWa+yxyCar7LLMNuvs s9BGK21+tUwrUrXWgoRtth5tyy1H3n6rUbjilmvuueimq+667Lbr7rvwxivvvPTWa++9+Oar 77789qtXH9014+/ABBds8MEIJ6zwwgw37PDDEH/ngcETUyxmGhFnrPHGHHfs8ccghyzyyCSX zOcxJqf8aiUqAxlDy3NdAPPMNNds880456zzzjz37PPPuSEA9NBEF2300UgnrfTSTDft9NNQ Ry311FRXbfXVxuqC9dZqKsP112CHLfbYZJdt9tlop612Y0l4xwl7bRscd8FzE1z3wHf7m/fa /iFRwfffgAcu+OCEF2744YgnrvjijDfu+ONkn+DdJZBXHtYhlmeu+eacd+7556CHLvropJdu +umjYY766qy33lwRBcMeu8GyE1y7v7fjTrvrVUFwsO+8By/88MQXrzYzUR9n/PLMN+9QHgVD T7D0A1Pvr/X9Ys+v9vtyr6/3+YKPr/jOl2/++einr/767Lfv/vvwxy///PSTjk/9+Oev//7i McD//wAMoAAHSMACGvCACEygAhfIwAY68IEQjKAEQeSKCWpOYBbMoAY3iDRscPCDIAyhCDEE jBGa8IQoTKG08KLCFrrwhTCMoQxnSMMa2vCGOOwOIHLIwx768IdAfZSXE4LYskgx0AtERNve ksjEJmYkF06MohSnSMUqWvGKWMyiFrc4F1lw8YtgDKMYE+I3g5VxTTsQCxXOOMY2uvGNcAwb +eLYFFTQ8Y54zKMe98jHPvrxj4AMpCAHSchCUsoXhkykIhfJyEY68pGQjKQkJ0lJxgiikpj0 TkAAACH5BAAGxgAALAAAAAC8AXgCBwj+AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq 3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzZsF7NnPq3MmzJ0JBQIEWDCqIoFCjRY8i JfqTaNB/SgceZSqV6lKrTp9eZRpVoNCsXbt6hQqW7NCkZc9OzVr14FqtPuPKDRl1LVKvRe+K rZvXbV+zZ9sKBjwYsNimdwMfXmoQrd/AhRv35Yv3L1nHeOdq3pyRMmHDlr9a/ryY9GilqP+G VZ23NOTMikerDf05cW3XqRPDrUzYNeffwF8Lz7y69m3ZpiUP9u3Zd+G9mBOiVW28LXSFuQVH jx45uPfv1Y3+i46t3LZwsHD57q7qlH37x+7Zoh/Ke+x89vARV8ZqGHZ38ABytth1xV1nnnkG HrdecuGV5591yEmFH1QNXpZffs0R96BzAXa404CncWdWgg8iGOJ/JRYY4XknMseYiHqdKN1k oSW1HGse5iggjgyq6GCDntmWXYo1Vmiici5eFd6QJb5W4I06Rglcczz21pqMTT6H5ZAk2tVQ kBAuFCKMxx3oJI/IgSnlmjq9555k6cnnpn5NvkXjgpdhldaPBO45FpJlFYdinvulR6eRbCaq 6KKMNuroo5BGKumklFZq6aWYZqrpppx26umnoIYq6qiklmrqqaimquqqrMoVQAD/BL1akKwJ vWqrQLbC+k+uutKKK665HsQrsLH2Ouyuuu46kK/ABsvss8kiG2yxs97KK6zMVkvrscJGe+2y x/oq67fFTktuudYmO2640TZ7q7Tvwrttu60aNC2y1dbqLbH4Liutv8/mC7C32BLc77vZ8tuv wvcqTK3ADNP7cMD2xituwdReDK6+G3fsccQLrwsxvhov/HG9FZd88sO/HryvxSa3GzC0MWP8 r8ke0+zuyCvrjLPAFGur7tA1h0w0QirjnLDIRittMM1LS4yyyw7/vDLVsx5sdc9Pd/2rsd1+ PK/DCf/sc9kdo5022MRCffTWTZ9ctsVEZ+t2xvSqXe/Y/k4rxC3f1rbtrsTsfquzs/FCfC3g BlfseM5SR5z42oOz3fbbaidt998qMy22zZebG/nebG/uEOMbg5336J6T3DjiaGteeuM8F111 7WbPnrrXICP9dt8pgyv6yK23fvvUi4N+fMv88k2y8MrKjff0a68b++/Wcx428b8/TnvlnhcP etKKf5871iyTrbzxU3O8O+7MY63x0NimH/3l1PcOt+y2Wx01y3rblv3uhr/36e9x/ava/FbH vbj9r33py54EV4ewCjprYg0TnvNc1jDyAZB3B9Rg9iCXQdFNrmjnSmEHIwetDMprfMqrnAxf KELLQfCGOMyhDnfIwx768IdA/gyiEIdIxCIa8YhITKISl8hEHdagBgOBokCeSBAqRvGJWJwi FqVoRS0WpItapOIWxSjFg4yRi2UE4z/UuMU1phGKZ0SIGq9YxTK6sY5RpGMX5zjGMGaRjlds ox/JSMYqDtIgfESjIMEIxz5+0Y5WTOQf4xhHN7aRknb0YiUxKUg5ZvKOgEQILj4SyVIGMpN7 hCQovYjHR7ZylYh8IygTGUtWmlIhnXzlKjtZSjTO8pOMDKUfQ8lISCoyj8GsozEbicc/rnGX y5QlLGHJzFemUpiWVCY0p3nNWBazmAoZpUd6yUpLolKaU6TmOWtJzE+2845znOYvt4lLZ+oy ld2c/yQz45lMbjqzm+X8ZRqp+cheVlOTe1TnKQHJRlU29J0BNecwr/nQiOoyoPEkiDg5Esln zlOhFgXnRUEqz3fmcqQGHWkraclQX87So4R0Z0lBekuSvrSjGU1nHwupx5sa05ZvZOlFAQpQ nV7yoDyFqBmB+dOFbHQjR81nU+V5xoreE53shGdOWWpPc3KVqZt0qUQXmVOvXhWoJxWpL6vZ 1WNqtZmapKlYT3pIryIVnZQMI0LJGtWuuvKvFi1JX1tqTaYO1bBK9aY+M/pVkXoypE2t6WAl ypCi3jKpwuwoPOmZx3QiFK6bVatYZ9rMc+ayqB5NbVIx+9Z6ZpW0IplsVf7x6tCpQrawCaEl PxG7Wpna1apaDWtMP4tI3A4yizXFKBcDyVnPuhKcQVXobLHp3NZSt5xsXOo2K1pWob6EqFO1 rE2pGl7DfvW1QE3vY7EJ3fJClI/GlS5W1cpc1LoTs2KsrzQdy8/SAhaw2a0lRdcZ2NteV7C0 ja9Zx8tJ2pKVvOzdKXJlWcnMEpi42E0wZO1p2YNy9pIrdWRn/7rJ0vLSvUtd7ITXa9fUmljF +AUrjEfbxBrb+MY4zrGOd8zjHvv4x0AOspCHTOQiG/nISE6ykpfM5CY7+clQjrKUp0zlKlv5 yjfmAZa3zOUue/nLYA6zmMdM5jKb+cxoTrOa1/7M5ja7+c1wjrOc50znOtv5znjOs573zOc+ +/nPgA60oAdN6EIb+tCITrSiF83oRjvaI+QgB0QibSlK6wQAmMZ0TjQ9EADYxNIHiTSlQf0P SYta1KWWdEJOrepUn1ogpIa1qVkt64GMmtasnvWrbb1rgrya1KqmtUFAnWteG9sixXY1qpXd 6mPz+ta/bnZBkk3sYEtbJpwWiKdrkulOf/ravrZ2q8dN7lU3e9bhdnW40V3rajs71u5Ota+H LW5by9ve07Z2uu/N74kAu9y1xrezBx7vUJfb0gWnSbb/se1Mc9rhnu42wyO+cIlr2uIN33an s61xjHdb4hPnuMaRDf/uYy+71O8ueb/Z3e5lR9vYBU84vxF+bnrLetwrzzfBdX1rdd9c39L+ d8rnLe9YrxzgBoc5ywOu8JFru+MUf7rUMa7tqT886hMvCNYbbnWpZ/3qXr+I0ffNbqSPnek7 RzmuWd5zpss83mc3+b2XbnO00/zZLW85vM9tdnC3fd9uV7m7ez1wbDs9611H/MWhrnWsfz3j Wp964xUPebBzJO5zb/fQEWJ0ode76Afv+7NRneyf+z3Ymsd8wu8e+LnT3e6iN3fdW8/50J8e JOeoyMLDvniv9973Dkc85XfPcMmH/Pdgh/jhxa7yzBd980nXOcwFDm2Xx77foJe99IGOfen+ H532oH/57GeO9OgDnvzm3jXh0W54gjge+ZVnfPIZf3yDQH3r+E/8R1SP+ptDf/xLN2pJ13nX t3dud34BR24B6H1Ch355h4Cw939Bd20N2H2Fl30QCBMVJ3zwp38dKHIbdxD3R3kk+HjeJnwk pxAIh3fgB4Dfd3sECH0GmIAQuIL+B2wMyHfg93ev930tCHQUqIPsh4FkJ4TcFnxPR3UkqHwb 93H0h4InCHxOCHxJ+IQkt36/BnjVtn7MNno2qHNjJ2yBJ34JyIVZaHJcSH6ER3oAp34lV3pH d3LVV30p54bdB3fNBx7EBxF7SGeYByp/+B196BCDWBPKsGOByCn/ifhojNiIjviIkBiJT1aI GUGJISiJrAJxl/gQhaiJE2GJYScSezeHPdhDrVBkGwiFDDGIqRgRoKiK+xeEWpiHmKiBI0dx HidyHeh+t7iEwUd1IOeJlheLAFh+tWgTewiC+meCk9eMu7h48ReCwwhpsvh/x4iMSMiB8neL INd4SviM7xeOsEiNxXiB17hpkMd7jhdyDXF1ljd/0riNJRGD1niO2MaL6hiPvJiM+Fh/Jfh7 zBiQoliNLWiP93iJyiiQABmF2oiQ0eiB+QcS9FiQBhkTnpiEVXh/EbmPFUd/85eNwpiOsRht MSeGFTkpr3iSUZaSKnkQZ9CSX/aSMNll/zI5k1tWkzZ5ZTg5RCy5ED3ZKHqTI0EZEUNJlKND EDuZidm4iUzJh0j4kzXBLTVkPpSzPN1yMTKjLy7kOyf0QBThMxbhQQaRlErpisu3ir0IlTMh ltUjNc5TlH0jLu5jlfbDEHB5ld3zlXlZEGRZltI4fMH4jk63ge6oi01ohSnBlsBTPu/TlQwk QHPpOjcTQfUzL/dSQcdzmcaCmXTDPwjRl35ZhQH5cIm3e8QHkMj3j2dZEoppOgi0QDZEQ5J5 P9sTOgpEMCJTMqoTm/IDQzfDNBt0lyijiSCYkKU5mIeHmus4jS3Bll75QQa0mJbZMo6ZP5uT LtFpOhvUPLuZnf82E5xHeUMdqY9SWJj2l5ziyI7Hp5Yd4ZwM9Jp10z0e1J2UGTef452DszPe Q5+z6TrDczU7NJ4QqZqnmZbpuYwxIZZzQziY45vQmTX9qT72KaEFNJuWSUHDEj6+OZTCWS8C yoxT2JDn6X6jGXEeGIqJeTQKyqCQM6EuGp8NRD5n853AuZd3s0DZSaFA9KHuCJiIeZjpeJGB aZwqoT236UJYeaELOjkys6SYeZsPip3ycjUExC5t2aJHxp6aEkDhaRJdQBIdChJhamNauqUs 1KUBMqbtiaY52aZu+qZwGqdyGillGiUQYBMRMKcZuZooSogXqRF1ahF3ShAQUKiFqqf/LpGS 7BmoI7oShnqo/zCoAgGpiKoSlMiEGFmCzdiExoepT/mpJXGogyqpA0GplYoSf7qJpAmiy5eK 0CiOgtmPIyGqCWGqp2qpuHigxymCrXqg4MgSj1oQwXqrLVGgDpmLCNGRIdqQnsqns2qoB2Gr xHoSxrqr/tiovqiq69inKHGn0iqt0woS3NioIUqksgqPUsiBocioCzGqkeqthEqq4SoSqcqp hfmjTEmc3Ih/ysqtH/Gokgqw88oZ7LqpNiGvA+sdBVuvNIGwCfuwEBuxEjuxFFuxFuuU3Siu vbqUvNqUKZEPIAuyAyGyIxGyIUusraixHeuvLPux+UAQL/sP/yQrEjM7s4hKmPIYdRn3kRm5 qf26niY4pEp4ETb7siZrtEYrEEertEgbszK7tDDrtCJbs0jLtDBZrY/3qr4YpL2qqlRodQ+p qRZhsyMrtSdLtU8bs1NrtgWBtm6rtk57klirnA4posnIsMNIt+aKEVD7tGX7t1b7toBbtiZr tYELt1eLnuSpjb/okV1rmqA6oHu7ESSLtobrt4J7uZe7toBbuIlLosX5hJBbt+TquPkYuh5L tFG7uWx7uH9ruYPLuYbruS2JsxiZkBxnt137tXkLqzvbsg8Rt5Xbun7rusZ7sqt7vLCbuENa ohyZj5marztrmHTLjsxZEX2btsXLtP/Ia7lnG7dpi7zau7wXuxMF67JjC77l23QZGxfZOxFk u77yO7/0W7/2e7/4m7/6u7/827/++78AHMACPMAEXMAGfMAInMAKvMAM3MAO/MAQHMESPMEU XMEWfMEYnMEavMEc3MEe/MEgHMIiPMIkrBD8wA8AcsIojBInHBctLBcvvGQqvMIMEcMx/BAz TMMuccMNYcMDwcMmrMMJwcMz/A85jMJA/MNCbMRLLBBJDBE5PBJAHMVO3MQU8cQ9vMRYXBFb nBNdTBA2bMVDrMNifBJfXBAvrMJVjMNlrMQGccNhPMZk/MRnPMZgLBJETMZrHBNqrMRtPBF1 PBNpjMRTXMT/LdzHTFzId5zIg+zGh1zFNFzEbyzJkozGipzIe1zJlLzCWHzJe8zEcszJiNzH jczIfjzJi7zJmUzKSHzKoAzGehzFcXzIjczKoDzKVOzHojzItvzKmhzHmsHLn+zGkLzGpUzM sOzIkUzItOzEvizEwJzEomzJzjzNtWzNhBzEqIzMnczI2WzExvzN1+zMyUzNt4zN4ZzG4WzO 7DzL14zOtgzMP+zN56zM61zP4PzKc3HMnuzOw6zP3PzN+AzQx/zJBb3NsEzLpdzM59zFnqzP 3YzJAN3Qy3zPB0HF44zPDE3NhYzLAQ3RAt3M/vzPu2zRDH3SAv3PPsHPWlzR6YzI/yo90gMt 0UfcztM8yTANycy8y2pc0zl90S1dzhO9yPn8zD0Nxxjt0DvNyzy90fS8xSxtzyadzTJNxPM8 1Tqt08Ks0j0R1TYt1UB9x1Wd0haN0Af9zDi90yQNzT/NzsgM0kMc1u/s0ghNzmWd1RMdzWQ9 xwZd0WM90Btt1ais12fN1TB800Mtz4Ht1iEtzosN2F+d2Igt1IoN0YDN1nUtz28s1/CM2K2c 18nsw309z3oN2sRM2HDtzyOd000c2HTtwzcdyHx81G99yoTd2r+My1Q9x8sszb8M1G2t2bkd 25PtzWrd15Vs1+Usy8Qdxrit23yty8PM3GnN28Xs2qnd2P/XDc1hTc9vndu1TWeyTWTjjYl/ XGS5XMLqvd7s3d7u/d7wHd/yPd/0Xd/2fd/4nd/6vd/83d/+/d8AHuABDA7gcN8EnhAEfuAI XuAeoeD/4OAVAeEEIeEkTOETzuAL/hEWbhEWnuAYXsIbLhAKfuAJLuIebuIjXuAqvuIfXuIP fuIp7uIkDuEy/uEDceIm/uIMPuMY7uE73uMrruM3XuMO7uIv/rAhfuRCruRF/uM6zuI5/uBR 3uRKfuQ1LuI5TuEpjuJZvuVU/uVe3uJOPuJRPrBJvuVTDuRdPuRsfuFlPuNsTuVuruVOXuVw vuZ4buVqTuNjbuMRe+Z1zuRADuP/ap7mV57ndy7oJU7naR7ne/7ojh7pQ47jRv7nfu7mdh7o Ei7net7oiB7keJ7oKO7jmV7qYC7pnd7mBpHkxArob67pPV7qoQ7rpg7pqa7qt57oug7qi27r by7lgo7kpH7huz7po/7qbT7sQh7jaK7ool7luQ7qzj7o0X7sT27sZS7g2r7t3N7t3h5mYPDt 4j7u5I4p1FDu6J7u6r7u7L6/bNru8B7v8j7v9F7v9TsA9p4T+G5EfQiV58sTzpoQAc+JA78q ++4omErwHCsRd7unqni93ljwJKF8BS/xkVeJPXTwjfKhBF+Ju6uO+wq8HadwrkgRFq8QJ38q Gr/x4wqN/4cpq0Cru703tCA/vakbhRr58v448jtffDxvfxH/8rhYdUJbdddKnAxZf09ZfHQ2 nsAokrjru/uIoLmrrzdv9EyflhdP9N5moFh/lr3Y9T6rrlqv9WKP9Sfo9WzGsU4vjyLKrG5/ usiZ9r2L8sEIuluf9Xp/9lyfrCTK92hvooBvomZv9IJ/8YXf9C2/jSApulKvrVCYu1+Pr2kP pIcf+H3PhImf95rP+Uzf91yf+FzXqpif8mXW9ot7rnG/kKh7ris7jl+P9rIf9oKfnHjv90n/ +aV/+6HP+3pP+rp/+XOG+icKvay6nHHPe6/fiZUP+MGP876v+0DPkMIv+s9/+f+HL/nTv/nD H5LHOq5Aaq82r4w8urKX+veNb57Ub3F5P/06r/S+b/NZ37w/v/VLH66Lavomof8rUf/06+8A AeDfQIIFDR5EmFDhwoECGT6EGFEhAIoO/1mUmFHjRo4dPX4EGVLkSJIlTZ5EmVLlSpYtXb6E GVPmTJo1bd7EmVPnTp49ff4EGlToUKJFjR5FmpSlQIwxKSpderMpVKpVSVZ8mpDpRIRYp0qc 6nXh164VRzoka1AsxLQum2LN2Nbq3KEYyW7V2rWgXK5q9/ZlaLck34t/HxJW+ZYg4sJ0HSMV HLkx3ItmDTcsjNZy5ayUMRu2THnz4rJZOePFvJWpWYv+iklzXsyatOTNoxt2hn3bduvYplmH Dj25tunHxVNKnp0ZtN7ZaP8Kbnz58+uvrqWjnp7ZeXTe1/263p6aN9/VyV+fD6/8cuT02I2/ P7mWdvTJzFOfV/85rN/lB8MGNw8/1NqjTzfi7ntOQPrc0wu57E5T0DoHHYSvwoQe2IhC1U7D TTcOp9PwwQI169DAsTh0b8LsGIQOrregQ1C/6mQLcEQQ5etuQe5wtLDHkELc0D/70EuQOiGL rA/EE/fzrjsKV+TOxhzz03E9HWFUssD+rsSPPx+/1GjCDVscMssYk/QuSjVtrDHF2NS0rska k2wNOyyjFNNLAo2Ecso7wQT+dCzPZMPLs8q8FHA43/wzdFAS//NNURLzq7NLA+vsjEbhVBPt QBNbfCrORz18E8IFgWMsUFVXlQqmVFmFNVZZB3NqVltvxTVXXXfltVdffwU2WGGHJbZYY49F NtlfXxWR2ZycdVZZtYBj609BJzI0sUpFWqs0Jm/ba0bisn30t3C7XM22cD21K9Rs1233wHLd PVdEacPcNrBFwbrLWpM85VY6KwMc91s0q0y03ir99XNhgaFEmE1wS9Xy3rjKJXVd6qg9tFuK N9UsN1ND7e3SQz/sGGA5CUayUIkfTq/PM51EktKaY47T0pi5pDJaiyMtVTHcMj2Z6LIYBZda okX+mxhop43Oq801bXYu52avNs9OPmeeWuuXK2bSYJf9tdjEaSlWOeTyih6ut7XNTfnNpWec OO6k8x1S60aNrFpPkvkTuz4YCWRvXCK/xlTLnZHzumx8P1ZXbRQh71dusZ52MV6o6b37Y0YB RHBwGcVzM+wjR3fYZJ5F1++7v+c8GOISK3ZcX89PRo9zeG+vW/fe10Y7ZNx1J76twHOUr2lE qWwdUeHJxDpGTPfNWegjAy/64dpt773uG4F/W3ikOxfP8uaCFr/44Y0//XWcFT/94CkhTnP+ HeH0q4M9nacf+zS3r1akJuW8UbGtZJ9DVfoKWDBFsY1juCuTh/T2nfj+uW16y/sT8iwFmwk+ x13qsqDbMAizDQLQhPDx2c6OksITttBH0CqhUWDoQhrW0IY3xGEOdbhDHvbQhz8E4lx8Rqvl gcQXQ/TIDCuoqmghMYjWox22QBhBnR2GglTc3VUQyBWDmS2KX4RXdTLkFcQ0MYgggeKryKa9 6AHGXjGMGBr5h0VRvdGOczxLmDriRCBaz0Wbit8CtZOpqnXoXWn8Y+SEJCkRqm6DTMMYzFBl tkNSMEggc6OpIJQu0jWygB+ynw/TeLs6sueRw+vZCPU2v/9ILUQkTE7j7CXGrqmyb1zLW81Q uaj5uBKOOhzlLPn3yive505kvGQqpzW7DuL/MovzyWBtmNMwgQ0odGzEkpt8GcubnemJV/TT b9LFzIj9MZYekxLPOlnMQYpTU1+coCyv90wLVg9/84rapbTJtV7ikkE/DOaarEbM8SSIfQbt Jhd1CT84xjOOgDtcKNF1zzsqaITbNGZC/wlQPmnwQccbWCrl6Ue5VbObQPIcSgdUR4Ga6WXh 8egbs/lSdSonTxXtoTSTlsVHgq5p7txOJYtEKEkSUoAXlOAWKQlISLXLi0ZFYEw1l0lHvU6Z TNOkpgAQh6Ko44xRydBXa4VTsVroXRHhY1mlKFG1ttWtb4VrXOU6V7rW1a535aHKVphWsmoR ojtRIV6pArSLje9o/ijxnR77alGcmm6tG20oT98X1o+cNY9iJSy/4oWt4ziRrfl86BIDu1iZ 7qt5VmNLZd2C2cyJ7JAJpGRrI/nBENptit4aZCMhCtPgFIpc8rKkBKdIzUzmhpMj6y27cLvJ oZGzU0PDoQDJB9zLhe936lNapeg1u8Cg7aG3JNwt6WfLj55ovFjUztZMWd5hEomXW1pv7V4b PAOCZm4/pS/57Ba3xKZWZlVUD+GkVsLLTQ2ejAUtO2GaUABLD6NoelINM/vB3eRucuuj79PM R8i4RAidVPuvMkmp4M9qTi5NTV1NB9qyB/PWnNHNV397CsHfZVi7N4agXtu3UMOaFsSn/jSp YxP8SwmlmJhttCY/4bvEXTXjKjEGXxH3q0Abm69zf4NaPo880RCvtExQ3BIVyaMnIzOYyw5W svJCDGPwfXLGmuSgifVZW861zXagShsBSzSpzarygN5T3W3D+KlGLdCyz10w6aS7LawKdiU6 flwfKXucXTFie5Du8DcVS2lHd9rTnwZ1qB8yB1GX2tSnRnWqf2ResNrEjKqu0IeLO+RqaW8/ dzmMoLu7TJzJi4xo3SOsY80Rvh62rwd146sjxGTSgnHWwhaiUo37zjHl1pEOLigoM/bnq+G5 tg2O4YuOau3jjuypLy42tImIYAh7sHzOxDY358SwRQbZpEVM/8tMX3Q+JaO02ep+SYG53LBs w5tO13wSvRW8cF63EY/M83dGBwxZgLcqjILssorJDN7V7aaLV6W2yGCX74vTVKUadXbFZ7Li 5qmzmRIbW7+BXEUVrZFFya5gxG2K8nSrfNUra/dO00xjpypJuwZG8o3wlNKFknzZQBepyz/r 84Qo49HSdlRSC85UAkaUZG4e7mho9FzFJbDcGGTkK7FaVaRTHVc9V22wpu52ogiBW7qmCd6Z qFO6O3oTfQc8fP4eeMI/ZvCFR3xVDp94xiNl8Y2HfOQlP3nKV97yl8d85jW/ec533vOfB33o RT960hOlFaVHfepVv3rWt971lkfE6/5lP3va1x4It8f97Wv/eiDs3ve/B37whT984hff+MdH fvKVv3yNJID5m3f+8zMffelfnvrVV5YWvnR97E+e+92P/Pehwg9+2KT8NiR/xdOfEPKTX/wD Wb9J4h9/j9Af/u0/v/1Fcv6DzB//5dc/+/s//vOJASQI/bs/9gNAAmQI/wsJBOQJCCwKCfwH 91sICqw/BnxABqQ/Ddw//DOI9jtADuxAAfTAAuQ/DKzAExxBiVDBjADBoHhBoKDA9Us/EVxB HIzBG1zBHCwIHQRBG9zBBSRAIAzBIuzBHBTBG/Q/DeTBCjzAJJTC+xNCEzzCFnzC/0tAHFTC HxRCH7xCLP/MvypkQigsQyPcwiAcQyPkwiMsQTWEwi6kwjVkwhRkQzJkQaGowTVMQCn8QjUc Q/jrQwckxC+MwzL0wv5bQDEMRBu8Qg7sQyXMP0mcwkosRETswTscxDQMxEQUwyTsxC6swzRs QT9cRE6MxFI0xExcwkZ0xUE8xVEExTwcij2MxFX8QzssRVXUxULcRVJ0w1z8RGBEiBiMw0rc QipMRUk8RVbcRUxERCt0QE8kRSu8xWaExlDMRlNURFgcxlkER0OMRmwMRaWwRW40RTi8xjnU RnJERy20xW2cxjb0QjwMQACMwmW0Rmdcx0sEwlb8xSkcR13sx14kSF8kxnv0xoT/hMeG9EYD nEda1MM8xMV2DENuFEeD/MZxtMRElEeCXMYo3EePLEYSvMhtZEhLfEV9LMJmBMeC3EiLREiV hEiNZMkwFEZqXEVzpEiLREczBEmOxEib5EdMFMRPrEKM1EdBtMaWPEZqvEkfnEZ+pMpYdEed bMSFHMphRMOqvMpfHMifxMaXhMZ3lEgZ1MJ6/Mp/9MlZ5EKApESzhEu17ESAjEgPTEus1MGS DMakNMq0NMA5HMG5NEFjTMrBHErDzEar7MqR9EuXVMyMhMWKREyVm0H2Q4rLLBbNFL287Iiz 3AnO/BXPBL/SNM3TRM3UVM3VZE2FYIfWhM3YlM3ZpE11/2OF2qS8RsDN3eTN3vTN3wTO4BTO 4STO4jTO40TO5KxNaIG7Z2lONkqMSxurWEEmhnq2VmM1Ygs4ZtMy//o5OVqhX/oX7xw28eTO q7OiJNpOKbtOWtNOVpm7dZuVwpERcRun0IEtRhIudqGwpYocd5I4OIEulPGkcTMnsoM5/4Sq XhIqQcvPcbM2Ai3Qr4NQFgGdUfEaoqrP52yJotu5qFkvFRk6YQqp9MKaED0cfsugBtkxkiuy +Eq0dzumlGMZfto6loqxK8EelzkpFlujupATpxNRNIs6WyOzAQszh7o1dgMb64SsmxMw9WKx iUqVJCtSg4MejaOl1nkftZMfof8YrpUBmCidHA0CFQJDHoE70R5dKfeBpU9p0S1a0jJdMoJB J/HRCq1qsTjK0sJ5p3pKUX8KKpDBtKDQN1ga0hSVpdEKuv/ZmqjjUZtpsK0zuo2rN/rogTKr UdByOkm9UhGTnacz0ksFs9WJnao4VABLVCtd1DuKUVBtOYhTVIH6FkpdOivZUi9VOuIKVUut VIwCLil9MIuKVOkZ0h8F0yAdU0+ipyxBUEATO0MDIaQqMhHaLLpBLqeJLatKFHL6qWSqJL7b HY9qNK5ruJLaGO5i1g3lugvlqU7jUPmSiXgtPXr9mYDTO+XU133l13711+BTIrjqOXvFiUJd LbA4z2D/K9gmvdT0pFEZ6on43LSVIzDzRK+8y7ShstiLXU/0KiOzitiNRdiaGDPwBKyMZdL3 XLkD7c9q86n7FKRpPaogqSoMrdBp47C14hKaTS4MNTDamFn/dB2kQhlEA6RNUlAUg6TPWSp2 DTB1lRSMgdmkPSCCbS8JKaSJcyW2WqU1Y1UdFdbsBNvs4bd2YyV3G1Hg8S6de1WzRVuGii8E s6a49aYezZqtpVKMlbdZ1dVPddEpHbob1VSxPVaU49JA0lIeY9vBbbmXEzLmGS+Ogx3I3dMF 2zKKi86skSqNu1WDQ1o7zRx0a44Xkx9ky7g569O6Xdxf29J2sqoMTVfLNbNY/90ooxpQ1h1X ObVbwcUzzOU0f3Ivw/VbXyXSSR25MLOjUgrUXhUcxNU5ElVd4U0y3kVUHpvcYjWTfXJctwXW h123181eqftVLLXTWircvn1U9uqYQIVdl7KwPImwxBW6xsWftJ2nyUVSggteXEXX9e3cK/Xd fECsrxM5N+0WrfItb30mAtatRnOSl7WcUCI7KzW390VTcE2qCp4jtgO7BD46DXZSn/qzvVlX OD3XsWNg/y1Xny0bqx3ZZwnP4LSslHAD8rQ4MM3Xf9XhHebhHvbh6mOMgXXh3y2OIUah79SV j/u3XWPUF3aVn2iK13RiJBZbh70sKk65+DRikp1iKv/e4oDxiSEqto+9YZPdNML4YooFkAJT pN7a1v4cqqjFpAj9z0KaHkRqLvBqIHODLZHbNmd112VC2gEyWpNxMzqGrkS6WT4zrgi1VteC KkHOqpDzYG5bioKC0bOR0f5QIedCqLL13Sg7pvBSUTOLsra7KDK1J0BrVEjlrPIyrfcq5bVF Jb8ZuFyaN7SNX+zE4Bnd1INj2MR9XhZFUpdqpiNrX2cDMzLpIgk25p3FOQaLuENd0fPqZKhz OetFzwAVKfClpkFtHzX9UEHFrcsFVDHpFNRNUnHZN0Cl3FhuVjrdW8T93GfG3aD55Ojp3dJS Z6D7NRrj5eH1Z06GXpBCZuL/hVX7SVR2Yt4zW2ZinqZZRbp+ct78bbqGHWcnnVL2aWbATVj5 vCTwHeiOKuiW6WVH/V8vK9Fjhrpkdui/Yh0QlWj93alO/TF7vmiKrtWNXhJd+uByemLNxeBB OxXqYboGZuAV9mMTrs+XMrsVmaSm3dUxrTCnnaWCKWpGa6BKJup6nt85TpydPbQMtbMR1k8N 3VYotmIuLoo0jg+23jWeAAAkcKEZhs5LNlgYfowhtuu71tsfPhY6AOy5EuzBNuzDBuJASStm wbW4jjuK9aukSON806sxFlkp6+vHfmtUtljGdk+/Bra1BuMrnk6VhezP9l7RNu0lnrTMBSMy RlnQ/+YjNN5s0g5qhf3riE6geOBjRGZhSJKur3njRobgQk7gI7UpQuFPAu6npuLqchPh0K3a i3iAB45koQ7rQaZqO/62EPK2p+XubCVaWevYaaKZPkmfv+rmvH1TTxXlOt1k+8i2HLVlaFbf jD7lXHbft6Hdq7bmEeHaXbo38lUuo/ba0Crv+6XfXwaPPfXpih7fqxLVv+VRXg3fuzXo2dVe 9vbUU62lBw83zhXVdMLoV91euI5o9VLTfU7phflTkIrwZL5nVt45cP4u9m3eq9WoF/c69zGx a54zr/4uSh5wkHvdkNuR0EXy3FbwVsZp+p1m4T5f6RWteqtwJo2pALNO/P/O5mq9aQqeuZ1m qf0l3+41U/gGt8k2r9Rl8PodXltV3hi/H/NlMnLFckUF812VX1kd3+ltaBynVF8GYKy9n4IT XDovX5L9rcaJ5G9uG4xjV3aW6vHgYPTZszzLXnn6arTuF5613UcOKRYWUKy+jrNeclBvakgx V9JldUsfb259K7cubdRuIVn/NMYwAKug7Lz+mRxG7F/nFVMA9mEn9mJ3bOyk0YAF2dAG7WYX bbizV2U/FqtFLY4tUagoWWz66GY/sW1v7fZMrdbF3x17u9s+the2dWSv4iod7ctm9m3mTtiW bOL2Io1p5Ek2njzu7jmu5wF6ZP084QcNb+LeM0v/KnBDUmTxcu5zqzaCDyqZLfhNSgNvm16I x7KWrXHnQmF91wle2h+Z+lQrkmVYBvHRylFBP10TlRJDdx10weS3Den2wtuW52YcjZ3tPfRl I3SVl/GxTW0ipuBqP2mENeeE42yavu9sJvDlmNP7HnqEg/AR9SWUl1wHL1bl9fITp153RyyT lu71odB0FhRvtrd5a2fkdt1VJlKyFmkoLfKn1/Lj4ZGeIfJ/duefdfHDvbCng2f7bXFkPdji VShuZs+/L3tvujm0p7g4N3zgbXqTk9/Er9u9pV7TvVtTznHT7Xm/33rWHs82h+ihjlU5x5uQ n6yV5lOZb3wREyOqpxSW/g5noP5and7gm5/ztR/wtifz1yd9Z8drZqpjUH9WSad4wEm70c1T F99uSKf041/eMsfPp+90sB5QQltjiwfki+cUE4f45Haq5l80dFVqvXa1YWEh1wZ30HPrdAfS 1T4LvGN/Y5f/+af/+rd/tYr/+1dsG9b/e1Xt/geIfwIHEixo8CDChAoXMmwoEABEAP8iDqQ4 8aLEhw8tRsxo0SHIkCJHkixp8iTKlCpXsmzp8uXKjBc1EpQIkabHmjRnwuzp8yfQoEKHEi1q 9KDMpAVtVuQpc6bSo1KnUq1q9SrWolGhUkz6tONNnhOfZi1r9izatGpbbmWqUelWnUvX0q1r /vcuXqptnfKFKpes37yCBxMubHjuTo9dm+L8OHZs3MOSJ1OunLeb5cyaN3Pu7Pkz6NCiR5Mu bfo06tSqV7Nu7fo17NiyZ9Oubfs27ty6d/Pu7fs38ODChxMvbvw48uTKlzNv7vw59OjSp1Ov bv069uzat3Pv7v07+PDix5Mvb/48+vTqh/Ja7/49/PjyU3+ob//DwPv3Cdrnrx9hfQcFmF9/ BP4nkH4FGrQfgQL+M2BBDELI34MJ4uefgwZeiOCGD2JY4XyqTTjghAuO2GGJFXaoIocfntji Qi+yGCGIAm6oYH41JoQjgjDCCKGCJK4YImkyptggkCgOyWOBRirp/uOOT6q4In5H6shgjlZq SKOONSZ544VaEvmZk1FeSSWVV4KYYoBlKsRmlTP2aCWQcnoo5p0jdtnilw3uOaZoSWqIZZtg RpgmiXwuWaWhHCZ4qIkeyskogDc6mqWFXAb5p5BrUgoloIEeCKqfXqKpaZyeRvpoqZWuauCc Q/oIZph/cjnjpy5SWmirRMYzWqe9Dhpsr42qCimxtn6IoZJx0mkprLkC6J+ziyp6rLKhdiYo qXvyKqyxyRLL7ZtSovltpD1SK22GW3b5Ja2yaiuqrjYiKyWF9r4bprnyLuulieyWuqjAt8K6 L7UHdzsvZyUW+qjDjGJp8L8TRzzlxOvm/nvvgRLaa2Ga6TpqbcX+MnwyyimrvDLLLbtsmAJm mfIyzS3FXDPOm92cM8+T7dwz0EELPTTRRRt9NNJJH7SP0k07/TTUUUs9NdVVW3011llrvTXX XXv9NdhhO82P2GWbfTZ2qcB0CNttC9S22//AzfZAcx/y9tx150033nLfXbffdNvtd98EDa43 3HgnHjjfhv/9tuJxH6435Y3LHXnjeRNeuOOLW/445nd/LrrmiMcduul8T96525mTnvjkqoPO uOWcby47Wqmo/dLomxPuuu+/P94754JnbjvwwfuOe+Wzf17Q6aQ7TrlBzEcfvPGG3z479q8D Xv3woGePUPK9/psfPvjQo197+X+zj77p1DNf1u5riy9938CfT33x6x/fvfycdz8Avk97nQMc 8ZSXv/ANj4DiE95BztfA9CEPfxEc4P6ax78NLs+C/StcAfm3uO3Zziq6+0kGIbjA6SXvg/m7 XQVZR8EVanB6CcGfB1soQwS6z4Hgq90GBQfDGaZwhiqkIRKBqEQcClCEpwui+6IYvxJSpX4+ SeH4jii8Ebrwdy8E4BRtiMQtSo6LkPNiAoEYOOi9sIiKuyEGv6i+1LWudDEsovHMiDoVDm51 eiTe/EaoRqOcMCgSLKPnMOjBLgrRi2Dk4B0VqRD2tXGAVGScAYXoRkxekIVyFOMm/qHoQw0O cokkZCH31AhIKYqyKlYEyiZNWcMQdvByb3zkJfG4SEt+b41p5N4RGThKyGVRjI5cIxElST5l jnF8qgRm9JqovGeiMnbAJE0sU8nMX1YOcTE0phMjyUYOCpObFFSdN/F4SmM2EplzFOcyA4jK eVLxmfALJyRr+cgEjuZwslRfIkF5P8lV8565tKM/NWfHM4IQodBcnw2tWUZI+hOcXSTj+7go 0YmSs3TRhB0v7RlNgVoUbSY9KUpTqtKVsrSlLn0pTGPKNY8ulHa8rOXqSqrAPOYQp3tbaEL1 CEVB1nSadQQpHBP5R1YmtHlCzWn3lso6an6vqQwt5U1f/vdEzjyPnx1t3yV3CNADbq+BLdRh J78J0HsGUptGRGsywYk7LFrwn6M760DZqk2zKpOja/UmMQ26ma7e9Kv+y6dYdxhQd9ZVrwvR oUhF6dV/6hOOrZQnXSuLz8hdlqgUPV4G/SrW63k1M5SlakM5i9jUsvGnIIQhXld7UVnOT4u0 7Ow1N7tT0Waxt251YW2tx8qdwravtqRtD9FZWtMu9qARjaIApUpcZFqvkpuFqmaRC88Snlaw cf1scBtr0wtqlKmWFO5TrRtAnqYVnWgsrGeKidpTlneSw+0l/NyrSceGVbfaHaZR3+rdd+LS v+ItJj3lCUbhKvCM+30ue8/Z/8P36pQyzGyw6/oo3mXm9KGvfWNs+zvb6Lq2htz97UXTWuAR +9S5HdRwQZGK4XSe96h73RuNKzyZC6M2tPcl8DTbO2Ff8rfBJO1ogttqRLUO0sAqzixcwWri 8Gr2qvItMjtFl2MRW5ioQs3ugYFaWA/DDsK/fGpeuzvePa41wi/eagW/fNePUjnLDvSsiYO8 3ifClYAxzq1MAy3oQRO60IY+NKITrehFMxqWE8RlUOscP6jS1IxzXm6j+wnd/tGSsBZdrqed GGIjZ7olBUCL7IZraYPmEMUYfuCZi9zkUn9Guaw1p52BPN9vMjjFtNa0myW9RErDF3O8Nm99 f20akHdK2delxXSC6SvF2ypbNMyGLk2DuGJQR5unMp51ta2N5VFf7tnF5nGrKwvucGuG3JBt rlH7TDs6bned7L43vvOt733zu9/+/jfAAy7wgWcnBAQ/OMITrvCFM7zf9Wg4xCMu8YlTvOIW vzjGM05oQGu84x7/uEECAgAh+QQADgAAACwAAAAAvAF4AgcI/gD/CRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtKnTp1CjJmUmtarVq1izat3KtavXr2DDih1LtqzZs2jTql3Ltq3b t3Djyp1Lt67du3jz6t3Lt29KCn4DCx5MuLDhw4gTK17MuLHjx5AjS55MubLke5Yza97MubPn z6BDix5NurTp06hTq17NurXr17Bjy56dtQTt27hz697Nu/fWAL6DCx9OvLjx48iTK1/OvLnz 59CjS59Ovbr169iza9/Ovbv37+DD/osfT768+fPo06tfz769+/fw48ufT7++/fv48+vfz7+/ //8ABijggAQW2BoIBia40xMKYqVFg8Y9COGEFFZo4YUYZqjhhhx26OGHIIb4WRoilmjiiSim qOKKLLbo4oswxijjjDTWaOONOOao44489ujjj0AGKeSQRBZpYzNGMoZkkootyeSTUEYp5ZRU VpnYJ1ZmqeWWXHbp5ZdghinmmGSWaeaZaKap5ppsbmdHm3DGKeecdNZp552rnYPnnnz26eef gAYq6KCEFmrooYgmquiijDbq6KOQRirppJRWaumlmGaq6YutbBpUp57+BGqoPY1K6k6mnppT qqrexGqr/zW9CutMss4aU6225qrrrrz26mtF3/wqbH2lDGvsscgmq+yyzDbr7LPQRivttNRW a+212Gar7bbcduvtt+COZk64S6VA7rnopqvuuuy26+678MYr77z01mvvvfjmq+++/Pbr778A O5WBvQPXWzC9B8+bsLwLx9twwBBHLPHEFFds8cUYT7tFxp4l4XES+ILM8cgkl2zyySinrDJ7 gKzs8p+CvCzzzDTXbPPNOOes884VcRIvJ0AHzfPQROe1QdFIJ6300kw37fTTUEct9dQ6jUP1 1QgBh3VkxWzdX9dSJuD12GSX7dkU+KJ9r9pmt+22WTy8LffcdNdt99145633Tf5K3Nu3vX/X Gzi9g89buLyHx5v43ow37vjjkEcu+eSUV2755ZhnzhY9mnfu+eeghy766KSXbvrpqMdLQOqs t+7667DHLvvstNdu++2456777rz37vvvwAcv/PDEF288X9Ycr/zyzDfv/PPQRy/99NRXb/31 2GevPehiGNnD9uCHPzQU4pdv/tZFnK/++uy37/778Mcv//z018/8NPbnr//+/Pfv///C+gUA B7g9GWyFEQRMoAIXyMAG5kcaDoygBOOnigla8IIYzKAGN8jBDnrwg/LJA1r4AMISmvAk8bBX ClXIwhbSa4UvvBcM5zXDE9rwhjhEmjByyMMe+vAmJ2z4oRCHSMQiGlEi+TiiEpfIRKi0rIlQ jKIUp0jFKlrxiliUSDByMogsevGL30IEZBwBxjKa8YxoTKMa18jGNrrxjXDkDA3iSMc62vGO eMyjHvfIxz76UTLw+KMgB0nIQhrykIhMpCIXyUggBQQAOw== ------=_NextPart_000_0009_01C6D418.10C5CD20-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Sep 11 02:16:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMf5k-000058-Qo for capwap-archive@lists.ietf.org; Mon, 11 Sep 2006 02:16:24 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMf5g-0006Yk-US for capwap-archive@lists.ietf.org; Mon, 11 Sep 2006 02:16:22 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id D434C1448048 for ; Sun, 10 Sep 2006 23:16:06 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 763F9430076 for ; Sun, 10 Sep 2006 23:15:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 53420144801E for ; Sun, 10 Sep 2006 23:15:22 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by hermes.tigertech.net (Postfix) with ESMTP id 26D601448006 for ; Sun, 10 Sep 2006 23:15:18 -0700 (PDT) Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9825F4F0218 for ; Mon, 11 Sep 2006 08:15:08 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 08:15:08 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 08:15:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Sep 2006 08:15:07 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WTP and AC version number? thread-index: AcbVaaEqh3KN8Q36SAe2O4iY7vBcew== From: "Peter Nilsson J (LI/EAB)" To: X-OriginalArrivalTime: 11 Sep 2006 06:15:08.0531 (UTC) FILETIME=[A18D4430:01C6D569] X-Brightmail-Tracker: AAAAAA== 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=HTML_40_50, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] WTP and AC version number? 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="===============0408159649==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 This is a multi-part message in MIME format. --===============0408159649== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D569.A0EC048A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D569.A0EC048A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was reading the about the state transistions chapter 2.3.1 in draft -02. In transintion (g) "Join to Configure" and (i) "Configure to Image Data" it is said that the WTP determines that its version number is same or different than the version number advertised by the AC. First of all I assume that the version number meant here is the software or firmware version. What is not clear to me is how the WTP get to know the version number advertised by the AC. The only software version I have seen that the AC sends to the WTP is the AC's Software version in AC Descriptor message element sent in the Discovery Response. But the AC's own software version would not be much help to determine if the WTP needs to update its firmware or not. Can some one explain how this is meant to work? Peter Nilsson Ericsson AB ------_=_NextPart_001_01C6D569.A0EC048A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WTP and AC version number?

I was reading the about the state = transistions chapter 2.3.1 in draft -02.
In transintion (g) "Join to = Configure" and (i) "Configure to Image Data" it is said = that the WTP determines that its version number is same or different = than the version number advertised by the AC.

First of all I assume that the version = number meant here is the software or firmware version.
What is not clear to me is how the WTP = get to know the version number advertised by the AC. The only software = version I have seen that the AC sends to the WTP is the AC's Software = version in AC Descriptor message element sent in the Discovery Response. = But the AC's own software version would not be much help to determine if = the WTP needs to update its firmware or not.

Can some one explain how this is meant = to work?

Peter Nilsson
Ericsson AB

------_=_NextPart_001_01C6D569.A0EC048A-- --===============0408159649== 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 --===============0408159649==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Sep 11 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 1GMo3O-0000t7-7v for capwap-archive@lists.ietf.org; Mon, 11 Sep 2006 11:50:34 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMo3M-0008O9-Qi for capwap-archive@lists.ietf.org; Mon, 11 Sep 2006 11:50:34 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id B7BFC3980AB for ; Mon, 11 Sep 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 6E668430085 for ; Mon, 11 Sep 2006 08:49:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1EC09398075 for ; Mon, 11 Sep 2006 08:49:36 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2AF09398045 for ; Mon, 11 Sep 2006 08:49:28 -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 k8BFnJBU004009; Mon, 11 Sep 2006 08:49:19 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k8BFnJL3004004; Mon, 11 Sep 2006 08:49:19 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Mon, 11 Sep 2006 08:49:19 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Peter Nilsson J (LI/EAB)" 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] WTP and AC version number? 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 HI, The current speci is broken in several ways in addition to what you noticed. These problems have been pointed out in previous emails. They just haven't been solved, and a process has not been put in place to solve them. On Mon, 11 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > I was reading the about the state transistions chapter 2.3.1 in draft > -02. > In transintion (g) "Join to Configure" and (i) "Configure to Image Data" > it is said that the WTP determines that its version number is same or > different than the version number advertised by the AC. > First of all I assume that the version number meant here is the software > or firmware version. > What is not clear to me is how the WTP get to know the version number > advertised by the AC. The only software version I have seen that the AC > sends to the WTP is the AC's Software version in AC Descriptor message > element sent in the Discovery Response. But the AC's own software > version would not be much help to determine if the WTP needs to update > its firmware or not. > Can some one explain how this is meant to work? > > Peter Nilsson > Ericsson AB > 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 Sep 11 21:42:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMxIP-0003Zw-PD for capwap-archive@lists.ietf.org; Mon, 11 Sep 2006 21:42:41 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMxII-0000tb-QQ for capwap-archive@lists.ietf.org; Mon, 11 Sep 2006 21:42:41 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id F0D7339807C for ; Mon, 11 Sep 2006 18:42:15 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id C8F38430085 for ; Mon, 11 Sep 2006 18:41:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B74C139808C for ; Mon, 11 Sep 2006 18:41:23 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by zoidberg.tigertech.net (Postfix) with ESMTP id 283F239800C for ; Mon, 11 Sep 2006 18:41:21 -0700 (PDT) Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Mon, 11 Sep 2006 18:41:06 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 955132AF; Mon, 11 Sep 2006 18:41:06 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 6AF7A2AE; Mon, 11 Sep 2006 18:41:06 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EEW08320; Mon, 11 Sep 2006 18:41:05 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id C967720501; Mon, 11 Sep 2006 18:41:05 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Sep 2006 18:39:58 -0700 Message-ID: <8954613CA6BB3242A1531D916A527A4101C5605D@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2026C4B93@xmb-sjc-235.amer.cisco.com> Thread-Topic: Comments on -02 version of capwap spec Thread-Index: Aca/uwxBHUIaBgYPTZ28fYPCQF6LQALDJVmwAAI/69AAAH0LAAACcGRwAGcectAAN0YZEAIqbiBA From: "Puneet Agarwal" To: "Pat Calhoun (pacalhou)" , dstanley1389@gmail.com, capwap@frascone.com X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006091111; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230332E34353036304538452E303031442D412D; ENG=IBF; TS=20060912014108; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006091111_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6918CFB83CC6389243-01-01 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.096 tagged_above=-999 required=7 tests=HTML_50_60, HTML_MESSAGE X-Spam-Level: Subject: Re: [Capwap] Comments on -02 version of capwap spec 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="===============0381789475==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: a3e5bce76cb320ccc764f9fd0d0fae2f This is a multi-part message in MIME format. --===============0381789475== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D60C.83082E64" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D60C.83082E64 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Pat, Thanks for your reply. Pl see my comments. >=20 > 10) What is the recommendation for 802.1P and DSCP values for > 802.11 Data > Frames? Do you honor the .11 QoS semantics between WTP and AC or=20 > are all > .11 Data Frames sent at the same priority in CAPWAP? That's an implementation issue. [Puneet]: I am fine with that. However, in that case, CAPWAP should define a CAPWAP control message for the AC and WTP to exchange their .11 Data Frame mapping capabilities and for the AC to then instruct the WTP to apply a particular mapping. Without this I am not sure how one can ensure a consistent QoS in the network. =20 > 12) It seems that within CAPWAP Data channel, there are=20 > multiple 802.11 control channels (it seems that different QoS=20 > levels are an implicit attempt at this > - refer to section 11.5). > General question to the group: Would it be beneficial to=20 > transport these > .11 control channels as "raw" data channels in CAPWAP Control=20 > messages allowing the network to honor the 8 .1p priorities=20 > for 802.11 Data frames in the CAPWAP DATA message. I do not believe so. I think this would unnecessarily complicate the protocol. Furthermore, if you went down this path, you'd have to put the 802.1X/EAPOL protocol in that channel... what about IAPP? etc. The current model keeps the separation of wireless binding to control best. [Puneet]: My main concern is the way 802.11 Management traffic is handled today. It wasn't clear to me why we (the group) specified to carry them in CAPWAP Data frames. I would have thought that they would be carried in CAPWAP Control Frames as they would most likely be handled by the CAPWAP Control entity (and not necessarily the CAPWAP Data entity). Hence sending such packets to the CAPWAP Data entity seems like a waste and it would eventually need to be sent to the CAPWAP control entity. >=20 > 16) Section 4.1: Description of RID field is unclear especially: >=20 > " WTPs with multiple radios but a single MAC Address range > use this field to indicate which radio is associated with the > packet." >=20 > It would be great if this could be clarified - it seems to be=20 > implying that this is used to support the case where=20 > multiple radios share the same Radio MAC address but is not=20 > very clear - is this the case? The point is that the BSSID is not sufficient since some WTP vendors re-use the BSSID across their a/bg radios. Since you guessed it, I suppose it is good enough? Any recommended changes? [Puneet]: It would be really nice to have a little blurb to this effect in the spec. >=20 > 27) How does multicast handle the case when the number of=20 > WLANIDs is greater than 16 - how does AC indicate that to the=20 > WTP? It seems you run out of bits in the CAPWAP data packets. The protocol already states that 16 is the hard limit. [Puneet]: If one wants to support (N > 16) WLANIDs (since the spec allows for 256 WLAN IDs), then the AC should at least have the capability to send N unicast copies of the packets to the WTP but indicate a different WLANID. It wasn't clear how this would be achieved for "802.3 Frame Tunnel Mode". Thanks. -Puneet=20 ************************************************************************ ********************** -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Tuesday, September 05, 2006 9:15 AM To: Puneet Agarwal; dstanley1389@gmail.com; capwap@frascone.com Subject: RE: Comments on -02 version of capwap spec Finally got to completing my response to your list of issues. > 1) Section 11.1.1 Split MAC > " All client data frames are tunneled between the WTP and the AC." >=20 > It is unclear what is meant by Client Data Frames - is it only > 802.11 data Frames or does it include 802.11 Management/Control=20 > Frames also? The rest of this section discusses which of the management frames are sent to the AC. So this specific bullet item is about IEEE 802.11 Data Frames being tunneled. Would you be satisfied with a changes from "Client Data Frames" to "Client IEEE 802.11 Data Frames"? Being tracked as issue 210. >=20 > 2) In Split MAC, are 802.11 Management Frames sent in CAPWAP data=20 > frames? Yes >=20 > 3) If (2) is true (ignore otherwise), then what is the CAPWAP priority > of these frames? >From the draft: 11.6 Quality of Service for Control Messages It is recommended that IEEE 802.11 MAC management frames be sent by both the AC and the WTP with appropriate Quality of Service values, ensuring that congestion in the network minimizes occurrences of packet loss. Therefore, a Quality of Service enabled CAPWAP device should use: 802.1P: The precedence value of 6 SHOULD be used for all IEEE 802.11 MAC management frames, except for Probe Requests which SHOULD use 4. DSCP: The DSCP tag value of 46 SHOULD be used for all IEEE 802.11 MAC management frames, except for Probe Requests which SHOULD use 34. >=20 > 4) In Fig 5, "Split MAC Message Flow", why is the "Probe Request" from > the Client sent to the AC also - even though all the processing was=20 > done at the WTP for this message? In order for the AC to know the client is probing. >=20 > 5) In Fig 5, what is the semantics of the notation: > "Add Mobile (Clear Text, 802.1X)"? > I could not find the 2 parameters implied by "Clear Text" and "802.1X" > in the > description of Add Mobile in section 4.4.8 or in section > 11.9.9 (IEEE 802.11 Mobile). Ah, this is a bug. The -02 document changed to utilizing the RSN info, but the section you discuss did not include the necessary changes. Created issue 211 to track this one. >=20 > 6) Section 11.9.9: "If the QoS field is set," - which field > (where) are you checking for the presence or absence of the Qos Field? Another good catch of a change that is missing as a result of splitting up message elements. Created issue 212 to track this one. >=20 > 7) Radio ID, WLAN ID, BSSID - is there an implied relationship between > these various configured element ie many radios to one WLAN ID etc. A BSSID is assigned to a WLAN ID - so there is a 1:1 corelation there. A WLAN can exist on one or more radios on the WTP. >=20 > 8) Assoc ID vs MAC Addr for id (which takes precedence or do you need=20 > to do both checks) Assoc ID is only used for power save - and is defined in the 802.11 protocol. When a packet is queued on the MAC for a domant station, its association ID is included in beacons to notify it of packets sitting on the queue. The station is identified via its MAC address, not the association ID. >=20 > 9) Section 11.5: Please state clearly that even though these are=20 > 802.11 Control Messages, they are still sent in CAPWAP DATA messages=20 > (at least for now). Actually, these are for MAC management messages, not control messages, so the header is incorrect. Further, your request, while valid, needs to be handled in another section of the document. I will make this clearer. Created issue 213 to track this issue >=20 > 10) What is the recommendation for 802.1P and DSCP values for > 802.11 Data > Frames? Do you honor the .11 QoS semantics between WTP and AC or=20 > are all > .11 Data Frames sent at the same priority in CAPWAP? That's an implementation issue. >=20 > 11) Should 802.1X frames be sent with different QoS than=20 > regular 802.11 Data Frames? What is our QoS Philosophy for=20 > such control traffic? One would think so, and we should possibly consider this. Created issue 214 to track this issue. >=20 > 12) It seems that within CAPWAP Data channel, there are=20 > multiple 802.11 control channels (it seems that different QoS=20 > levels are an implicit attempt at this > - refer to section 11.5). > General question to the group: Would it be beneficial to=20 > transport these > .11 control channels as "raw" data channels in CAPWAP Control=20 > messages allowing the network to honor the 8 .1p priorities=20 > for 802.11 Data frames in the CAPWAP DATA message. I do not believe so. I think this would unnecessarily complicate the protocol. Furthermore, if you went down this path, you'd have to put the 802.1X/EAPOL protocol in that channel... what about IAPP? etc. The current model keeps the separation of wireless binding to control best. >=20 > 13) Section 11.1.2 Local MAC: The spec defines capability to=20 > tunnel Client data frames as 802.3 frames between the WTP and=20 > the AC. It would seem that the CAPWAP Data tunnel (as=20 > currently defined) would need to carry both > 802.3 > payload (for client data frames) and 802.11 payload (for RSNA=20 > Key Mgmnt frames). Is this capability really desired? You are correct that 802.11 MAC management frames may be sent, but normal user frames would be in 802.3 format, as you had earlier requested on the list. Figure 7 on page 101 makes this clear. >=20 > 14) Section 4.1 CAPWAP Transport Header - It seems that this=20 > section should be renamed "CAPWAP Header" or all references=20 > in section 4 and other places should be updated to be "CAPWAP=20 > Transport Header". Correct, for consistency sake we should make this change. Created issue 215 to track this one. >=20 > 15) Section 4.1: The RID field here is 5 bits while in all=20 > control messages it seems to be 8 bits - this needs to be reconciled DUP issue, and already taken care of. >=20 > 16) Section 4.1: Description of RID field is unclear especially: >=20 > " WTPs with multiple radios but a single MAC Address range > use this field to indicate which radio is associated with the > packet." >=20 > It would be great if this could be clarified - it seems to be=20 > implying that this is used to support the case where=20 > multiple radios share the same Radio MAC address but is not=20 > very clear - is this the case? The point is that the BSSID is not sufficient since some WTP vendors re-use the BSSID across their a/bg radios. Since you guessed it, I suppose it is good enough? Any recommended changes? >=20 > 17) Section 4.1: I assume that implementations MUST support=20 > 802.3 frames as well as "Native" frames in the same CAPWAP=20 > Data Tunnel. Is this true and is that what we really want? That was the agreement in a previous thread. >=20 > 18) Section 4.1: M bit. You mention in the text that "this=20 > field MUST NOT be set to one in pkts sent by the AC to the WTP". >=20 > However, when you are transporting 802.3 frames, won't the AC=20 > need to indicate to the WTP what BSSID to use when sending=20 > the frame (or is it assumed that the BSSID is derived from=20 > the dest Client's MAC Addr for unicast)? good catch. Will fix this. Created issue 216 to track this one. >=20 > 19) Section 11.9.1: For Tunnel Mode =3D=3D "802.3 tunnel" in=20 > Local MAC mode, how are RSNA frames converted to 802.3 as=20 > they seem to be required for Local Mac They are not. see above comment >=20 > 20) In Local MAC with 802.3 tunnel, how are 4 MAC 802.11 converted to > 802.3 > without loss of info? Ie do we need to define TX-MAC element=20 > also (in CAPWAP data frames from WTP to AC)? They are not. If you need 4 address, use 802.11 frame formats. I think there's a point where it makes hacking the protocol to support every possible frame format become more complex. As an aside, TGs is now working on a 6 address format - what will we do for that one? That said, most applications use 3 address format, so 802.3 covers a broad range of applications. >=20 > 21) In Split MAC Mode: when the WTP does=20 > encryption/decryption, please specify the exact fields that=20 > are valid when WTP sends such frames to the AC (as they are=20 > now pseudo-802.11 frames after potential 802.11 reassembly in=20 > the WTP). will do. Create issue 217 to track this one. >=20 > 22) Can the same WLAN ID be assigned to different radios with=20 > the same BSSID? Yes. >=20 > 23) Can the same WLAN ID be assigned to different radios with=20 > different BSSID? Yes. >=20 > 24) For multicast pkts, does AC need to send multiple copies=20 > of the packet to send to each radio on the WTP that is part=20 > of the same WLAN ID or is the packet replicated by the WTP to=20 > all radios that are part of the same WLAN ID? The purpose for the bitmap field is to avoid the need to replicate packets to the same WTP. Note that if the packets are centrally encrypted, then the packet needs to be replicated, and encrypted using the right GTK. So from a performance point of view, multicast/broadcast along with centralized encryption is the worst case. Of course, this is equally true if DTLS is applied on the data plane. If the packet is encrypted on the WTP, then only a single copy needs to be sent, with the right bitmap. >=20 > 25) Local MAC with local bridge is the default mode - this=20 > implies that all implementations must support this config=20 > (which has the most complex s/w for the AP) - is that the=20 > correct default and why was it chosen - should this be changed? It was discussed during a thread. We needed to pick one. >=20 > 26) Why is the MAC mode and Tunnel Mode part of the WLANID=20 > config? What is the practical reason for allowing this per WLANID? Some vendors want the behavior to be different across WLANs. Sometimes tunnel, and sometimes don't. The MAC Mode probably should be done on a per WTP, IMHO. >=20 > 27) How does multicast handle the case when the number of=20 > WLANIDs is greater than 16 - how does AC indicate that to the=20 > WTP? It seems you run out of bits in the CAPWAP data packets. The protocol already states that 16 is the hard limit. PatC ------_=_NextPart_001_01C6D60C.83082E64 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable RE: Comments on -02 version of capwap spec

Hi = Pat,

Thanks for = your reply. Pl see my comments.

<stuff = deleted>
> =
> 10) What is = the recommendation for 802.1P and DSCP values for
> 802.11 = Data
>     Frames? Do you honor the .11 = QoS semantics between WTP and AC or
> are = all
>     .11 Data Frames sent at the = same priority in CAPWAP?
That's an = implementation issue.
[Puneet]: I am = fine with that. However, in that case, CAPWAP should define a CAPWAP = control message for the AC and WTP to exchange their .11 Data Frame = mapping capabilities and for the AC to then instruct the WTP to apply a = particular mapping. Without this I am not sure how one can ensure a = consistent QoS in the network.

 
<stuff = deleted>
> 12) It seems = that within CAPWAP Data channel, there are
> multiple = 802.11 control channels (it seems that different QoS
> levels are = an implicit attempt at this
> - refer to = section 11.5).
> General = question to the group: Would it be beneficial to
> transport = these
> .11 control = channels as "raw" data channels in CAPWAP Control =
> messages = allowing the network to honor the 8 .1p priorities
> for 802.11 = Data frames in the CAPWAP DATA message.

I do not believe = so. I think this would unnecessarily complicate the
protocol. = Furthermore, if you went down this path, you'd have to put = the
802.1X/EAPOL = protocol in that channel... what about IAPP? etc. The
current model = keeps the separation of wireless binding to control best.

[Puneet]: My main = concern is the way 802.11 Management traffic is handled today. It wasn't = clear to me why we (the group) specified to carry them in CAPWAP Data = frames. I would have thought that they would be carried in CAPWAP = Control Frames as they would most likely be handled by the CAPWAP = Control entity (and not necessarily the CAPWAP Data entity). Hence = sending such packets to the CAPWAP Data entity seems like a waste and it = would eventually need to be sent to the CAPWAP control = entity.

<stuff = deleted>
> =
> 16) Section = 4.1: Description of RID field is unclear especially:
> =
> " WTPs = with multiple radios but a single MAC Address range
>       use this field = to indicate which radio is associated with the
>       = packet."
> =
> It would be = great if this could be clarified - it seems to be
> implying = that this is  used to support the case where
> multiple = radios share the same Radio MAC address but is not
> very clear - = is this the case?
The point is that = the BSSID is not sufficient since some WTP vendors
re-use the BSSID = across their a/bg radios. Since you guessed it, I
suppose it is = good enough? Any recommended changes?

[Puneet]: It would = be really nice to have a little blurb to this effect in the = spec.

<stuff = deleted>
> =
> 27) How does = multicast handle the case when the number of
> WLANIDs is = greater than 16 - how does AC indicate that to the
> WTP? It = seems you run out of bits in the CAPWAP data packets.

The protocol = already states that 16 is the hard limit.

[Puneet]: If one = wants to support (N > 16) WLANIDs (since the spec allows for 256 WLAN = IDs), then the AC should at least have the capability to send N unicast = copies of the packets to the WTP but indicate a different WLANID. It = wasn't clear how this would be achieved for "802.3 Frame Tunnel = Mode".

Thanks.

-Puneet =

**********************************************************= ************************************
-----Original = Message-----
From: Pat Calhoun = (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Tuesday, = September 05, 2006 9:15 AM
To: Puneet = Agarwal; dstanley1389@gmail.com; capwap@frascone.com
Subject: RE: = Comments on -02 version of capwap spec

Finally got to = completing my response to your list of issues.

> 1) Section = 11.1.1 Split MAC
>   = " All client data frames are tunneled between the WTP and the = AC."
> =
>   = It is unclear what is meant by Client Data Frames - is it = only
>   = 802.11 data Frames or does it include 802.11 Management/Control =
> Frames = also?

The rest of this = section discusses which of the management frames are sent to the AC. So = this specific bullet item is about IEEE 802.11 Data Frames being = tunneled. Would you be satisfied with a changes from "Client Data = Frames" to "Client IEEE 802.11 Data = Frames"?

Being tracked as = issue 210.

> =
> 2) In Split = MAC, are 802.11 Management Frames sent in CAPWAP data
> = frames?
Yes

> =
> 3) If (2) is = true (ignore otherwise), then what is the CAPWAP priority
> of these = frames?
From the = draft:
11.6 Quality of = Service for Control Messages

   It is = recommended that IEEE 802.11 MAC management frames be sent = by
   both = the AC and the WTP with appropriate Quality of Service = values,
   = ensuring that congestion in the network minimizes occurrences = of
   = packet loss.  Therefore, a Quality of Service enabled CAPWAP = device
   = should use:

   = 802.1P:   The precedence value of 6 SHOULD be used for all = IEEE
      802.11 MAC management = frames, except for Probe Requests which
      SHOULD use = 4.

   = DSCP:   The DSCP tag value of 46 SHOULD be used for all IEEE = 802.11
      MAC management frames, = except for Probe Requests which SHOULD use
      34.

> =
> 4) In Fig 5, = "Split MAC Message Flow", why is the "Probe Request" = from
> the Client = sent to the AC also - even though all the processing was
> done at the = WTP for this message?
In order for the = AC to know the client is probing.

> =
> 5) In Fig 5, = what is the semantics of the notation:
> "Add = Mobile (Clear Text, 802.1X)"?
> I could not = find the 2 parameters implied by "Clear Text" and = "802.1X"
> in = the
> description = of Add Mobile in section 4.4.8 or in section
> 11.9.9 (IEEE = 802.11 Mobile).
Ah, this is a = bug. The -02 document changed to utilizing the RSN info, but the section = you discuss did not include the necessary changes.

Created issue 211 = to track this one.

> =
> 6) Section = 11.9.9: "If the QoS field is set," - which field
> (where) are = you checking for the presence or absence of the Qos Field?

Another good catch = of a change that is missing as a result of splitting up message = elements.

Created issue 212 = to track this one.

> =
> 7) Radio ID, = WLAN ID, BSSID - is there an implied relationship between
> these = various configured element ie many radios to one WLAN ID = etc.

A BSSID is = assigned to a WLAN ID - so there is a 1:1 corelation there. A WLAN can = exist on one or more radios on the WTP.

> =
> 8) Assoc ID = vs MAC Addr for id (which takes precedence or do you need
> to do both = checks)
Assoc ID is only = used for power save - and is defined in the 802.11 protocol. When a = packet is queued on the MAC for a domant station, its association ID is = included in beacons to notify it of packets sitting on the = queue.

The station is = identified via its MAC address, not the association ID.

> =
> 9) Section = 11.5: Please state clearly that even though these are
> 802.11 = Control Messages, they are still sent in CAPWAP DATA messages =
> (at least = for now).

Actually, these = are for MAC management messages, not control messages, so the header is = incorrect. Further, your request, while valid, needs to be handled in = another section of the document. I will make this = clearer.

Created issue 213 = to track this issue

> =
> 10) What is = the recommendation for 802.1P and DSCP values for
> 802.11 = Data
>     Frames? Do you honor the .11 = QoS semantics between WTP and AC or
> are = all
>     .11 Data Frames sent at the = same priority in CAPWAP?
That's an = implementation issue.

> =
> 11) Should = 802.1X frames be sent with different QoS than
> regular = 802.11 Data Frames? What is our QoS Philosophy for
> such control = traffic?
One would think = so, and we should possibly consider this.

Created issue 214 = to track this issue.
> =
> 12) It seems = that within CAPWAP Data channel, there are
> multiple = 802.11 control channels (it seems that different QoS
> levels are = an implicit attempt at this
> - refer to = section 11.5).
> General = question to the group: Would it be beneficial to
> transport = these
> .11 control = channels as "raw" data channels in CAPWAP Control =
> messages = allowing the network to honor the 8 .1p priorities
> for 802.11 = Data frames in the CAPWAP DATA message.

I do not believe = so. I think this would unnecessarily complicate the
protocol. = Furthermore, if you went down this path, you'd have to put = the
802.1X/EAPOL = protocol in that channel... what about IAPP? etc. The
current model = keeps the separation of wireless binding to control best.

> =
> 13) Section = 11.1.2 Local MAC: The spec defines capability to
> tunnel = Client data frames as 802.3 frames between the WTP and
> the AC. It = would seem that the CAPWAP Data tunnel (as
> currently = defined) would need to carry both
> = 802.3
> payload (for = client data frames) and 802.11 payload (for RSNA
> Key Mgmnt = frames). Is this capability really desired?

You are correct = that 802.11 MAC management frames may be sent, but
normal user = frames would be in 802.3 format, as you had earlier
requested on the = list. Figure 7 on page 101 makes this clear.

> =
> 14) Section = 4.1 CAPWAP Transport Header - It seems that this
> section = should be renamed "CAPWAP Header" or all references =
> in section 4 = and other places should be updated to be "CAPWAP
> Transport = Header".

Correct, for = consistency sake we should make this change.

Created issue 215 = to track this one.
> =
> 15) Section = 4.1: The RID field here is 5 bits while in all
> control = messages it seems to be 8 bits - this needs to be = reconciled
DUP issue, and = already taken care of.

> =
> 16) Section = 4.1: Description of RID field is unclear especially:
> =
> " WTPs = with multiple radios but a single MAC Address range
>       use this field = to indicate which radio is associated with the
>       = packet."
> =
> It would be = great if this could be clarified - it seems to be
> implying = that this is  used to support the case where
> multiple = radios share the same Radio MAC address but is not
> very clear - = is this the case?
The point is that = the BSSID is not sufficient since some WTP vendors
re-use the BSSID = across their a/bg radios. Since you guessed it, I
suppose it is = good enough? Any recommended changes?

> =
> 17) Section = 4.1:  I assume that implementations MUST support
> 802.3 frames = as well as "Native" frames in the same CAPWAP
> Data Tunnel. = Is this true and is that what we really want?
That was the = agreement in a previous thread.

> =
> 18) Section = 4.1: M bit. You mention in the text that "this
> field MUST = NOT be set to one in pkts sent by the AC to the WTP".
> =
> However, = when you are transporting 802.3 frames, won't the AC
> need to = indicate  to the WTP what BSSID to use when sending
> the frame = (or is it assumed that  the BSSID is derived from
> the dest = Client's MAC Addr for unicast)?
good catch. Will = fix this.

Created issue 216 = to track this one.
> =
> 19) Section = 11.9.1: For Tunnel Mode =3D=3D "802.3 tunnel" in =
> Local MAC = mode, how are RSNA frames converted to 802.3 as
> they seem to = be required for Local Mac
They are not. see = above comment

> =
> 20) In Local = MAC with 802.3 tunnel, how are 4 MAC 802.11 converted to
> = 802.3
> without loss = of info? Ie do we need to define TX-MAC element
> also (in = CAPWAP data frames from WTP to AC)?
They are not. If = you need 4 address, use 802.11 frame formats. I think
there's a point = where it makes hacking the protocol to support every
possible frame = format become more complex. As an aside, TGs is now
working on a 6 = address format - what will we do for that one?

That said, most = applications use 3 address format, so 802.3 covers a
broad range of = applications.

> =
> 21) In Split = MAC Mode: when the WTP does
> = encryption/decryption, please specify the exact fields that =
> are valid = when WTP sends such frames to the AC (as they are
> now = pseudo-802.11 frames after potential 802.11 reassembly in
> the = WTP).

will = do.

Create issue 217 = to track this one.

> =
> 22) Can the = same WLAN ID be assigned to different radios with
> the same = BSSID?
Yes.

> =
> 23) Can the = same WLAN ID be assigned to different radios with
> different = BSSID?
Yes.

> =
> 24) For = multicast pkts, does AC need to send multiple copies
> of the = packet to send to each radio on the WTP that is part
> of the same = WLAN ID or is the packet replicated by the WTP to
> all radios = that are part of the same WLAN ID?
The purpose for = the bitmap field is to avoid the need to replicate
packets to the = same WTP. Note that if the packets are centrally
encrypted, then = the packet needs to be replicated, and encrypted using
the right GTK. So = from a performance point of view, multicast/broadcast
along with = centralized encryption is the worst case. Of course, this = is
equally true if = DTLS is applied on the data plane. If the packet is
encrypted on the = WTP, then only a single copy needs to be sent, with the
right = bitmap.

> =
> 25) Local = MAC with local bridge is the default mode - this
> implies that = all implementations must support this config
> (which has = the most complex s/w for the AP) - is that the
> correct = default and why was it chosen - should this be changed?
It was discussed = during a thread. We needed to pick one.

> =
> 26) Why is = the MAC mode and Tunnel Mode part of the WLANID
> config? What = is the practical reason for allowing this per WLANID?
Some vendors want = the behavior to be different across WLANs. Sometimes
tunnel, and = sometimes don't. The MAC Mode probably should be done on a
per WTP, = IMHO.

> =
> 27) How does = multicast handle the case when the number of
> WLANIDs is = greater than 16 - how does AC indicate that to the
> WTP? It = seems you run out of bits in the CAPWAP data packets.

The protocol = already states that 16 is the hard limit.

PatC

------_=_NextPart_001_01C6D60C.83082E64-- --===============0381789475== 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 --===============0381789475==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Sep 12 14:21:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNCsi-0003BE-Hv for capwap-archive@lists.ietf.org; Tue, 12 Sep 2006 14:21:12 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNCsf-0002zM-U5 for capwap-archive@lists.ietf.org; Tue, 12 Sep 2006 14:21:12 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 6155E144803D for ; Tue, 12 Sep 2006 11:20:55 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D09774300D2 for ; Tue, 12 Sep 2006 11:19:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B687839812C for ; Tue, 12 Sep 2006 11:19:13 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id F1AAC3980F4 for ; Tue, 12 Sep 2006 11:16:36 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 12 Sep 2006 11:16:36 -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 k8CIGas3014250 for ; Tue, 12 Sep 2006 11:16:36 -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 k8CIGa1E013285 for ; Tue, 12 Sep 2006 11:16:36 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Sep 2006 11:16:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Sep 2006 11:16:35 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A2634@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Insufficient description of WTPs during discovery Thread-Index: AcbTib7+aXE/pRhrRT+b/gAI5ZZ9YADDcNLg From: "Pat Calhoun (pacalhou)" To: "Bob O'Hara (boohara)" , X-OriginalArrivalTime: 12 Sep 2006 18:16:36.0146 (UTC) FILETIME=[9564E120:01C6D697] 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: Subject: Re: [Capwap] Insufficient description of WTPs during discovery 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: 287c806b254c6353fcb09ee0e53bbc5e Created issue 219. Overall, I agree with the concern that the WTP has no way to communicate its complete capabilities. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Bob O'Hara (boohara) > Sent: Friday, September 08, 2006 2:00 PM > To: Capwap@frascone.com > Subject: [Capwap] Insufficient description of WTPs during discovery > > Sorry for the long email, but I think this issue requires > some background discussion, as well as the proposal to > address the issue I am raising. > > In the Discovery Request there is a WTP Descriptor to provide > the AC with information about the WTP. This descriptor > provides insufficient information to the AC, if the type of > WTP is not know in advance. If the WTP is not supporting > 802.11, this descriptor does not provide enough information > to the AC for it to make that determination and there is > insufficient space in the WTP Radio Information element to > make up for this lack. > > If we are to produce a protocol that is able to support > several different types of existing wireless protocols, there > needs to be a clearly articulated way to describe the > protocols supported on the WTP, during the discovery process. > It is quite possible that an AC will not support all > wireless protocols, as CAPWAP is applied to these other > protocols in the future. The WTP needs to be able to clearly > specify what wireless protocol(s) it supports to the AC in > the Discovery Request and the AC needs to be able to indicate > to the WTP that it does, or does not, support the specified protocols. > > This could be done in several ways. I propose that the WTP > Radio Information element be extended to include a 16-bit > protocol ID field that contains a single value from an > enumeration (probably eventually managed by IANA) of the > protocols for which a binding document has been published by > the IETF. Because it is conceivable that a WTP might support > more than one wireless protocol (say 802.16 and 802.11), I > propose that the protocol ID field be repeated in the > descriptor, with a count field preceding it, as often as is > needed to list all the protocols in the WTP. > > I also propose that the protocol ID field be added to the WTP > Radio Information element and that this element be repeated > in the Discovery Request as needed to provide information > about all the radios for each protocol in the WTP. > > Finally, I propose that the Discovery Response message > include a new message element, the Supported Protocols > element, to indicate to the WTP which of the WTP's wireless > protocols are supported by the AC. This information can be > used by the WTP to determine the AC to which it will > subsequently send the Join Request. The Supported Protocols > message element will include the list of protocol ID > supported by the AC. > > This Supported Protocols element could be constructed by the > AC in two different ways. One way would be to construct the > list statically, at compile time, and always return this > entire list. Constructed in this fashion, the list would > always have at least one entry. The WTP would then scan this > list on receipt and determine if one or more of the protocols > for which it needs support are present. > > An alternate way to construct this element would be for the > AC to put only those protocols indicated by the WTP in the > Discovery Request for which the AC provides support into the > list. Constructed in this fashion, the list might be empty, > if there are not matching protocols shared between the AC and > WTP. The WTP would still scan the list on receipt to > determine if one or more protocols for which it needs support > are present in the list. > > Regardless of how the AC constructs the list of supported > protocols, the WTP still makes the decision as to which AC it > will join. In the Join Request, the WTP MUST send only those > protocols in the WTP descriptor that have been indicated to > be supported by the AC to which the Join Request is sent. In > this way, a WTP that supports multiple wireless protocols > might be supported by more than one AC. > > -Bob > > Bob O'Hara > Cisco Systems - WNBU > > Phone: +1 408 853 5513 > Mobile: +1 408 218 4025 > > _________________________________________________________________ > 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 Sep 12 14:22:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNCtv-0003SK-Fe for capwap-archive@lists.ietf.org; Tue, 12 Sep 2006 14:22:27 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNCtt-0003Eq-Ue for capwap-archive@lists.ietf.org; Tue, 12 Sep 2006 14:22:27 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 912591448058 for ; Tue, 12 Sep 2006 11:22:22 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8190F4300D1 for ; Tue, 12 Sep 2006 11:21:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 71DE11448033 for ; Tue, 12 Sep 2006 11:21:37 -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 ED29A1448029 for ; Tue, 12 Sep 2006 11:21:34 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 12 Sep 2006 11:21:34 -0700 X-IronPort-AV: i="4.09,155,1157353200"; d="scan'208"; a="1853195532:sNHT32548712" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8CILYIv006926; Tue, 12 Sep 2006 11:21:34 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k8CILWwN000302; Tue, 12 Sep 2006 11:21:34 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Sep 2006 11:21:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Sep 2006 11:21:22 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A263D@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Insufficient description of WTPs during discovery Thread-Index: AcbTjkA4VOwfyO4dRki4ZZj1F5n07wDCVjZg From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" , "Bob O'Hara (boohara)" X-OriginalArrivalTime: 12 Sep 2006 18:21:23.0482 (UTC) FILETIME=[40A8DFA0:01C6D698] Authentication-Results: sj-dkim-7.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] Insufficient description of WTPs during discovery 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: 7baded97d9887f7a0c7e8a33c2e3ea1b > The reason is that it seems that there are two opposing views > as to who decides the binding between a WTP and AC, and also > two opposing views as to the ammount of information that > should be in discovery messages (which are sent "in the clear"). We discussed this during the DTLS adoption threads, and the comments by both Scott and Charles stated this would be ok. If you feel this is still an issue, and we made an incorrect decision, could you start a new thread? > > I suggest that we first list the scenarios, and then list the > possible aproaches. In doing this, all the assumptions need > to be made visible. For example, does an WTP have other > management interfaces (such as a CLI) or is CAPWAP the only > management interface to WTP? Does a WTP have "field > replacable units" so that different technologies for > interfaces can be installed, and thus making WTP model type > insufficient for determining the interfaces on a WTP? 1. We have to assume a CAPWAP interface. We cannot assume any other interface, but also cannot forbid it. 2. As an AC vendor, I can't keep track of what a WTP model means. I don't plan to have that close of a relationship with all of the WTP vendors. That said, the model number is useful to present to the end user that uses the AC to monitor their network. > > So, there are many items in the below that I fundamentally > disagree with, specifically "a WTP still makes the decision > as to which AC it will join". I do this because it can result > in nondetermanistic behavior, and can be a security risk. WTP must make the decision, but the AC helps provide guidance. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ 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 Sep 12 15:32:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNE06-0002Cf-4B for capwap-archive@lists.ietf.org; Tue, 12 Sep 2006 15:32:54 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNE04-0007UU-MF for capwap-archive@lists.ietf.org; Tue, 12 Sep 2006 15:32:54 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 980B83981AF for ; Tue, 12 Sep 2006 12:32:51 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 6FCB243008C for ; Tue, 12 Sep 2006 12:32:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 496A41448079 for ; Tue, 12 Sep 2006 12:32:18 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 00B3B1448047 for ; Tue, 12 Sep 2006 12:32:16 -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 k8CJWFud030768; Tue, 12 Sep 2006 12:32:16 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k8CJWFtT030765; Tue, 12 Sep 2006 12:32:15 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 12 Sep 2006 12:32:15 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2027A263D@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] Insufficient description of WTPs during discovery 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: c0bedb65cce30976f0bf60a0a39edea4 HI, It appears that you might have misunderstood the first point, and I was hoping for a lot more on the second point. The first is not which entity establishes the DTLS sessionn (but if you wish, we can revisit that discussion). The point is how an WTP decides which AC to establish that session. And yes, as long as a WTP establishes the session, it must ultimately decide. The issue is how it decides. The CAPWAP-02 has the WTP deciding based on some AC utilization info. I believe where there is a split in the WP is whether or not AC utilization is appropriate factor in a WTP's decision, and whether or not providing AC utlitzation and WTP capabilities in the clear durring discovery is appropriate. For the second point, I was hope that you would list scenarios like initial enrolement, reboot after saved config, referal by another AC, recover after redeployment, etc. On Tue, 12 Sep 2006, Pat Calhoun (pacalhou) wrote: > > The reason is that it seems that there are two opposing views > > as to who decides the binding between a WTP and AC, and also > > two opposing views as to the ammount of information that > > should be in discovery messages (which are sent "in the clear"). > We discussed this during the DTLS adoption threads, and the comments by > both Scott and Charles stated this would be ok. If you feel this is > still an issue, and we made an incorrect decision, could you start a new > thread? > > > > > I suggest that we first list the scenarios, and then list the > > possible aproaches. In doing this, all the assumptions need > > to be made visible. For example, does an WTP have other > > management interfaces (such as a CLI) or is CAPWAP the only > > management interface to WTP? Does a WTP have "field > > replacable units" so that different technologies for > > interfaces can be installed, and thus making WTP model type > > insufficient for determining the interfaces on a WTP? > 1. We have to assume a CAPWAP interface. We cannot assume any other > interface, but also cannot forbid it. > 2. As an AC vendor, I can't keep track of what a WTP model means. I > don't plan to have that close of a relationship with all of the WTP > vendors. That said, the model number is useful to present to the end > user that uses the AC to monitor their network. > > > > > So, there are many items in the below that I fundamentally > > disagree with, specifically "a WTP still makes the decision > > as to which AC it will join". I do this because it can result > > in nondetermanistic behavior, and can be a security risk. > WTP must make the decision, but the AC helps provide guidance. > > 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 Tue Sep 12 15:45:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNEBs-0006Xl-4e for capwap-archive@lists.ietf.org; Tue, 12 Sep 2006 15:45:04 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNEBp-0001Ty-Lx for capwap-archive@lists.ietf.org; Tue, 12 Sep 2006 15:45:04 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 22DA1398061 for ; Tue, 12 Sep 2006 12:45:01 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6F95E43008C for ; Tue, 12 Sep 2006 12:44:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 560553980CF for ; Tue, 12 Sep 2006 12:44:29 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id BEDA239809B for ; Tue, 12 Sep 2006 12:43:21 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 12 Sep 2006 12:43:21 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8CJhLJQ006456; Tue, 12 Sep 2006 12:43:21 -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 k8CJhIYp000827; Tue, 12 Sep 2006 12:43:18 -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); Tue, 12 Sep 2006 12:43:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Sep 2006 12:43:17 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A26B1@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Insufficient description of WTPs during discovery Thread-Index: AcbWoio/ndoAe/wYRAmxy8EAGTBYlQAATUDA From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" X-OriginalArrivalTime: 12 Sep 2006 19:43:18.0126 (UTC) FILETIME=[B20408E0:01C6D6A3] 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 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] Insufficient description of WTPs during discovery 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: 69a74e02bbee44ab4f8eafdbcedd94a1 > It appears that you might have misunderstood the first point, > and I was hoping for a lot more on the second point. > > The first is not which entity establishes the DTLS sessionn > (but if you wish, we can revisit that discussion). The point > is how an WTP decides which AC to establish that session. > And yes, as long as a WTP establishes the session, it must > ultimately decide. The issue is how it decides. > > The CAPWAP-02 has the WTP deciding based on some AC > utilization info. I believe where there is a split in the WP > is whether or not AC utilization is appropriate factor in a > WTP's decision, and whether or not providing AC utlitzation > and WTP capabilities in the clear durring discovery is appropriate. Not really. The decision was based on pre-configuration, DHCP, broadcast/mcast discovery, DNS, etc. Once the WTP had a list of ACs to connect to, it would then use the pre-configured priority list, and assuming none, it would make use of AC utilization. > > For the second point, I was hope that you would list > scenarios like initial enrolement, reboot after saved config, > referal by another AC, recover after redeployment, etc. So the above is the general rule. Are you stating this is missing? That's a separate topic that we could certainly look deeper into. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ 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 Sep 12 16:41:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNF4M-0005OE-Fu for capwap-archive@lists.ietf.org; Tue, 12 Sep 2006 16:41:22 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNF4K-00016V-I5 for capwap-archive@lists.ietf.org; Tue, 12 Sep 2006 16:41:22 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 69EF31448052 for ; Tue, 12 Sep 2006 13:41:08 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id BD3D343008C for ; Tue, 12 Sep 2006 13:40:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A8106398065 for ; Tue, 12 Sep 2006 13:40:19 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4E733398095 for ; Tue, 12 Sep 2006 13:40:14 -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 k8CKeBVO012188; Tue, 12 Sep 2006 13:40:11 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k8CKe9MQ012179; Tue, 12 Sep 2006 13:40:09 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 12 Sep 2006 13:40:09 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2027A26B1@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] Insufficient description of WTPs during discovery 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: d8ae4fd88fcaf47c1a71c804d04f413d HI, On Tue, 12 Sep 2006, Pat Calhoun (pacalhou) wrote: > > It appears that you might have misunderstood the first point, > > and I was hoping for a lot more on the second point. > > > > The first is not which entity establishes the DTLS sessionn > > (but if you wish, we can revisit that discussion). The point > > is how an WTP decides which AC to establish that session. > > And yes, as long as a WTP establishes the session, it must > > ultimately decide. The issue is how it decides. > > > > The CAPWAP-02 has the WTP deciding based on some AC > > utilization info. I believe where there is a split in the WP > > is whether or not AC utilization is appropriate factor in a > > WTP's decision, and whether or not providing AC utlitzation > > and WTP capabilities in the clear durring discovery is appropriate. > > Not really. > > The decision was based on pre-configuration, DHCP, broadcast/mcast > discovery, DNS, etc. Once the WTP had a list of ACs to connect to, it > would then use the pre-configured priority list, and assuming none, it > would make use of AC utilization. You are decribing process that that has very skippy details in the CAPWAP-02 doc. There are concerns about latency, non-determination, recovery during short term network problems, and longer term problems that are not there. That is always having the WTP sending discovery requests, building a list, comparing the list with existing configuration, trying the establish is NOT the appropriate behavior in all situations. > > For the second point, I was hope that you would list > > scenarios like initial enrolement, reboot after saved config, > > referal by another AC, recover after redeployment, etc. > > So the above is the general rule. Are you stating this is missing? > That's a separate topic that we could certainly look deeper into. The scenarios affect the desired outcomes. We need the scenarios so that we can verify that the process yields the desired outcomes. I hope you have heard the term "ladder climb". This is a visual reminder of the cost of having to "touch a WTP". With network gear in a wiring closet, a "truck roll" is expensive, but a "ladder climb" can be quite a bit more. Because of the cost in touching a box to put it in a known state so that recover can happen, it is VERY important that we go through the scenarios and make sure the procedure for all is appropriate. Having a procedure that broadcasts AC and WTP information in the clear is not desirable. Having a proprietary way (such as via a CLI) to tell an AC the mapping between WTP model number and capabilities is not an unreasonable cost. (It's done by a a vendor at compile time for their products. Extending this to support config time is not that much. Been there, done that.) > 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 Wed Sep 13 13:16:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNYLa-0002Sk-VI for capwap-archive@lists.ietf.org; Wed, 13 Sep 2006 13:16:26 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNYLY-0001n0-EN for capwap-archive@lists.ietf.org; Wed, 13 Sep 2006 13:16:26 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 4FFBC1448046 for ; Wed, 13 Sep 2006 10:16:18 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 9253B430064 for ; Wed, 13 Sep 2006 10:15:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7E81539809E for ; Wed, 13 Sep 2006 10:15:29 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id C9C6E39800D for ; Wed, 13 Sep 2006 10:09:46 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 13 Sep 2006 10:09:46 -0700 X-IronPort-AV: i="4.09,160,1157353200"; d="scan'208"; a="320816028:sNHT34993748" 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.20060308/8.12.11) with ESMTP id k8DH9k5p008580; Wed, 13 Sep 2006 10:09:46 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k8DH9kw7018814; Wed, 13 Sep 2006 10:09:46 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Sep 2006 10:09:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Sep 2006 10:09:47 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A29B2@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Insufficient description of WTPs during discovery Thread-Index: AcbWq6xH+MixUPp6RBmPjuqXyNsElgAkKvcw From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" X-OriginalArrivalTime: 13 Sep 2006 17:09:45.0891 (UTC) FILETIME=[69824730:01C6D757] 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 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] Insufficient description of WTPs during discovery 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: 082a9cbf4d599f360ac7f815372a6a15 > You are decribing process that that has very skippy details > in the CAPWAP-02 doc. There are concerns about latency, > non-determination, recovery during short term network > problems, and longer term problems that are not there. That > is always having the WTP sending discovery requests, building > a list, comparing the list with existing configuration, > trying the establish is NOT the appropriate behavior in all > situations. I disagree. I don't believe that it is the IETF's place to dictate device behavior. We are here to provide a standards specification that ensures interoperability. However, the issues you list are how vendors differentiate, and implementations issues. We provide the tools - vendors create systems out of them. > The scenarios affect the desired outcomes. We need the > scenarios so that we can verify that the process yields the > desired outcomes. > > I hope you have heard the term "ladder climb". This is a > visual reminder of the cost of having to "touch a WTP". With > network gear in a wiring closet, a "truck roll" is expensive, > but a "ladder climb" can be quite a bit more. Because of the > cost in touching a box to put it in a known state so that > recover can happen, it is VERY important that we go through > the scenarios and make sure the procedure for all is appropriate. I have multiple products that implement a derivative of CAPWAP, and none of my customers require a truck roll/ladder climb. So I don't believe the issue you describe exists. > > Having a procedure that broadcasts AC and WTP information in > the clear is not desirable. Again disagree. The "in the clear" information allows the WTP to connect to the AC, in an authenticated fashion, at which time the same data that caused the connection to exist to be exchanged as an authenticated confirmation. Yes, one could spoof Discovery Responses, but the data will again be confirmed post authentication. > Having a proprietary way (such as via a CLI) to tell an AC > the mapping between WTP model number and capabilities is not > an unreasonable cost. (It's done by a a vendor at compile > time for their products. Extending this to support config > time is not that much. Been there, done that.) I don't understand how a vendor can compile what AC to connect to. The developer has no idea what IP addresses, or devices, are available at the customer site. Again, CLI can be an option, but MUST NOT be made mandatory. CAPWAP is *the* management interface. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ 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 Sep 13 15:10:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNa7d-000751-U4 for capwap-archive@lists.ietf.org; Wed, 13 Sep 2006 15:10:09 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNa7c-0007Ms-FB for capwap-archive@lists.ietf.org; Wed, 13 Sep 2006 15:10:09 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id B7E11398027 for ; Wed, 13 Sep 2006 12:10:07 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D76E1430076 for ; Wed, 13 Sep 2006 12:09:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id BD4EB398035 for ; Wed, 13 Sep 2006 12:09:31 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2B189398076 for ; Wed, 13 Sep 2006 12:07:56 -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 k8DJ7uDj003940; Wed, 13 Sep 2006 12:07:56 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k8DJ7ujE003932; Wed, 13 Sep 2006 12:07:56 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 13 Sep 2006 12:07:55 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2027A29B2@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] Insufficient description of WTPs during discovery X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 73734d43604d52d23b3eba644a169745 HI, Your response appears to confirm the staring point that I made in this discussion, which is there is a fundamental disagreement between the approaches, and there is not an effective way to resolve it. I don't know how to constructively respond to the following: "I don't believe that it is the IETF's place to dictate device behavior. We are here to provide a standards specification that ensures interoperability." since IETF specifications are essentially definitions of behaviors. By the way, I've read some release notes from updates of shipping products. And there have been problems with some of the approaches that were specified in the earlier versions of the CAPWAP proto, which have resulted in fixes. So, I would say to use the gained operational experience to "do it a better way" in the IETF CAPWAP doc instead of repeating past undesirable results. On Wed, 13 Sep 2006, Pat Calhoun (pacalhou) wrote: > > You are decribing process that that has very skippy details > > in the CAPWAP-02 doc. There are concerns about latency, > > non-determination, recovery during short term network > > problems, and longer term problems that are not there. That > > is always having the WTP sending discovery requests, building > > a list, comparing the list with existing configuration, > > trying the establish is NOT the appropriate behavior in all > > situations. > > I disagree. I don't believe that it is the IETF's place to dictate > device behavior. We are here to provide a standards specification > that ensures interoperability. However, the issues you list are > how vendors differentiate, and implementations issues. We provide > the tools - vendors create systems out of them. > > > The scenarios affect the desired outcomes. We need the > > scenarios so that we can verify that the process yields the > > desired outcomes. > > > > I hope you have heard the term "ladder climb". This is a > > visual reminder of the cost of having to "touch a WTP". With > > network gear in a wiring closet, a "truck roll" is expensive, > > but a "ladder climb" can be quite a bit more. Because of the > > cost in touching a box to put it in a known state so that > > recover can happen, it is VERY important that we go through > > the scenarios and make sure the procedure for all is appropriate. > > I have multiple products that implement a derivative of CAPWAP, > and none of my customers require a truck roll/ladder climb. So I > don't believe the issue you describe exists. > > > > > Having a procedure that broadcasts AC and WTP information in > > the clear is not desirable. > > Again disagree. The "in the clear" information allows the WTP to > connect to the AC, in an authenticated fashion, at which time the > same data that caused the connection to exist to be exchanged as an > authenticated confirmation. Yes, one could spoof Discovery Responses, > but the data will again be confirmed post authentication. > > > Having a proprietary way (such as via a CLI) to tell an AC > > the mapping between WTP model number and capabilities is not > > an unreasonable cost. (It's done by a a vendor at compile > > time for their products. Extending this to support config > > time is not that much. Been there, done that.) > > I don't understand how a vendor can compile what AC to connect to. The > developer has no idea what IP addresses, or devices, are available > at the customer site. Again, CLI can be an option, but MUST NOT be > made mandatory. CAPWAP is *the* management interface. > > 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 Wed Sep 13 15:57:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNarp-0004nl-C8 for capwap-archive@lists.ietf.org; Wed, 13 Sep 2006 15:57:53 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNari-00050U-FM for capwap-archive@lists.ietf.org; Wed, 13 Sep 2006 15:57:53 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 80FA53980BE for ; Wed, 13 Sep 2006 12:57:45 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 29612430076 for ; Wed, 13 Sep 2006 12:57:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 14B87431565 for ; Wed, 13 Sep 2006 12:57:07 -0700 (PDT) Received: from IS1.enterasys.com (is1.enterasys.com [63.160.138.52]) by hermes.tigertech.net (Postfix) with ESMTP id 8DD3B4316B4 for ; Wed, 13 Sep 2006 12:57:01 -0700 (PDT) Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Sep 2006 15:56:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Sep 2006 15:56:44 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021943F@MABOSEVS2.ets.enterasys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Insufficient description of WTPs during discovery Thread-Index: AcbXaEBMsjxQYIb6QduGW1fpNgPU3gABbTng From: "Nelson, David" To: X-OriginalArrivalTime: 13 Sep 2006 19:56:43.0877 (UTC) FILETIME=[BCB1A150:01C6D76E] X-imss-version: 2.042 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.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.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: Re: [Capwap] Insufficient description of WTPs during discovery X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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 David T. Perkins writes... > I don't know how to constructively respond to the following: > "I don't believe that it is the IETF's place to dictate > device behavior. We are here to provide a standards > specification that ensures interoperability." > since IETF specifications are essentially definitions > of behaviors. I think you know that the IETF standardizes on-the-wire protocols, and sometimes APIs (or ASIs). Product behavior goes way beyond this scope. It is true that certain "differentiators" that vendors add to their products impact the on-the-wire protocol. This class of features is generally at tension with multi-vendor interoperability. There is another class of features that do not impact on-the-wire protocol specifications, and these are where vendors can truly add differentiation without breaking interoperability. _________________________________________________________________ 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 Sep 13 17:54:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNch7-0005RT-T6 for capwap-archive@lists.ietf.org; Wed, 13 Sep 2006 17:54:57 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNch5-0005AV-EE for capwap-archive@lists.ietf.org; Wed, 13 Sep 2006 17:54:57 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id C5FB2398027 for ; Wed, 13 Sep 2006 14:54:54 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 11073430076 for ; Wed, 13 Sep 2006 14:54:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E3D591448010 for ; Wed, 13 Sep 2006 14:54:29 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id C67F74302F0 for ; Wed, 13 Sep 2006 14:54:28 -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 k8DLsLHn008585; Wed, 13 Sep 2006 14:54:21 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k8DLsLOt008579; Wed, 13 Sep 2006 14:54:21 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 13 Sep 2006 14:54:21 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Nelson, David" In-Reply-To: <3CFB564E055A594B82C4FE89D215656021943F@MABOSEVS2.ets.enterasys.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] Insufficient description of WTPs during discovery X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 3e15cc4fdc61d7bce84032741d11c8e5 HI, David - yes I know the IETF process quite well. Let me provide a small example related to this issue (discovery) in CAPWAP..... At time t(x) in the past, an WTP established a session with an AC and transitioned to the run state. Due to a short term network problem, the session between the WTP and AC is lost (terminated). The CAPWAP-02 does not factor this history into the discovery process. This results in an increase in latency of the WTP reconnecting to the AC, and the possibility of the WTP connecting to a different AC, plus the WTP and AC leaking information. I believe that the current behavior is inapropriate, and a much better behavior that is derived from considering appropriate scenarios should be specified in the CAPWAP protocol specification. I was hoping that the WG would be using a process that would work through these technical issues to make sure all understood the situations and how the protocol addressed each situation. It feels like gamesmanship to keep the situations from being made visible and understood. Without this, I can't see how WG members can judge the CAPWAP spec and support it going forward. On Wed, 13 Sep 2006, Nelson, David wrote: > David T. Perkins writes... > > I don't know how to constructively respond to the following: > > "I don't believe that it is the IETF's place to dictate > > device behavior. We are here to provide a standards > > specification that ensures interoperability." > > since IETF specifications are essentially definitions > > of behaviors. > > I think you know that the IETF standardizes on-the-wire protocols, and > sometimes APIs (or ASIs). Product behavior goes way beyond this scope. > > It is true that certain "differentiators" that vendors add to their > products impact the on-the-wire protocol. This class of features is > generally at tension with multi-vendor interoperability. There is > another class of features that do not impact on-the-wire protocol > specifications, and these are where vendors can truly add > differentiation without breaking interoperability. > 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 Wed Sep 13 18:07:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNcta-0002by-SW for capwap-archive@lists.ietf.org; Wed, 13 Sep 2006 18:07:50 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNctY-0007Da-CE for capwap-archive@lists.ietf.org; Wed, 13 Sep 2006 18:07:50 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id F40C539804D for ; Wed, 13 Sep 2006 15:07:47 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 47349430076 for ; Wed, 13 Sep 2006 15:07:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 292241448025 for ; Wed, 13 Sep 2006 15:07:15 -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 77A4E1448006 for ; Wed, 13 Sep 2006 15:07:13 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 13 Sep 2006 15:07:13 -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 k8DM7Cel032324; Wed, 13 Sep 2006 15:07:12 -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 k8DM7B1I024925; Wed, 13 Sep 2006 15:07:12 -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, 13 Sep 2006 15:07:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Sep 2006 15:07:11 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A2B6D@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Insufficient description of WTPs during discovery Thread-Index: AcbXf0MmRZTWwUN9RZahPoA9CFEa+AAAU1nA From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" , "Nelson, David" X-OriginalArrivalTime: 13 Sep 2006 22:07:11.0524 (UTC) FILETIME=[F655C640:01C6D780] Authentication-Results: sj-dkim-3.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] Insufficient description of WTPs during discovery X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 0bc60ec82efc80c84b8d02f4b0e4de22 > At time t(x) in the past, an WTP established a session with > an AC and transitioned to the run state. Due to a short term > network problem, the session between the WTP and AC is lost > (terminated). The CAPWAP-02 does not factor this history into > the discovery process. Actually, the protocol supports this event quite well. The protocol makes all of the tools available, including a very comprehensive state machine. > This results in an increase in latency > of the WTP reconnecting to the AC, and the possibility of the > WTP connecting to a different AC, plus the WTP and AC leaking > information. How the WTP decides to reconnect is an implementation issue. We are not here to define the failover algorithms. The protocol provides the tools, vendors are the crafters. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ 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 Sep 13 18:35:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNdK9-0004Sl-5r for capwap-archive@lists.ietf.org; Wed, 13 Sep 2006 18:35:17 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNdK7-0003As-Ou for capwap-archive@lists.ietf.org; Wed, 13 Sep 2006 18:35:17 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id AFA4E144804F for ; Wed, 13 Sep 2006 15:35:11 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9F5ED430076 for ; Wed, 13 Sep 2006 15:34:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 87A101448030 for ; Wed, 13 Sep 2006 15:34:11 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id C80001448006 for ; Wed, 13 Sep 2006 15:34:09 -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 k8DMY80l017277; Wed, 13 Sep 2006 15:34:08 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k8DMY7eu017274; Wed, 13 Sep 2006 15:34:07 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 13 Sep 2006 15:34:07 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2027A2B6D@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] Insufficient description of WTPs during discovery X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 8b30eb7682a596edff707698f4a80f7d HI, Well, why don't you provide a timing diagram with references to section numbers in the spec to show your point. On Wed, 13 Sep 2006, Pat Calhoun (pacalhou) wrote: > > At time t(x) in the past, an WTP established a session with > > an AC and transitioned to the run state. Due to a short term > > network problem, the session between the WTP and AC is lost > > (terminated). The CAPWAP-02 does not factor this history into > > the discovery process. > > Actually, the protocol supports this event quite well. The protocol > makes all of the tools available, including a very comprehensive state > machine. > > > This results in an increase in latency > > of the WTP reconnecting to the AC, and the possibility of the > > WTP connecting to a different AC, plus the WTP and AC leaking > > information. > > How the WTP decides to reconnect is an implementation issue. We are > not here to define the failover algorithms. The protocol provides the > tools, vendors are the crafters. > > > 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 Wed Sep 13 19:46:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNeQd-0000e4-5q for capwap-archive@lists.ietf.org; Wed, 13 Sep 2006 19:46:03 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNeQa-00050Q-LQ for capwap-archive@lists.ietf.org; Wed, 13 Sep 2006 19:46:03 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 713A13980BE for ; Wed, 13 Sep 2006 16:45:51 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 624FF430076 for ; Wed, 13 Sep 2006 16:45:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 493D039800B for ; Wed, 13 Sep 2006 16:45:17 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id D80F6398053 for ; Wed, 13 Sep 2006 16:45:09 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 13 Sep 2006 16:45:09 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8DNj9aZ025814; Wed, 13 Sep 2006 16:45:09 -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 k8DNj9QV014423; Wed, 13 Sep 2006 16:45:09 -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); Wed, 13 Sep 2006 16:45:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Sep 2006 16:45:06 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A2C14@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Insufficient description of WTPs during discovery Thread-Index: AcbXhLpvL/VclL5SQaq1wahfC7LYvwACH63A From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" X-OriginalArrivalTime: 13 Sep 2006 23:45:09.0008 (UTC) FILETIME=[A596A900:01C6D78E] Authentication-Results: sj-dkim-3.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] Insufficient description of WTPs during discovery X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 0fa76816851382eb71b0a882ccdc29ac State Machine (section 2.3.1), state transition o, discusses how the connection is terminated. This can done done through a timeout, or an explicit disconnect. The control protocol defines an explicit req/resp scheme, which ensures that the connection is tested bi-directionally. This is defined in section 4.3.1. Timers are defined in section 4.5 and 4.6. As the e-mail with proposed text I sent last week also shows, we've stepped up this section sigificantly. When the WTP comes up, it decides which AC to connect to, defined in section 3.2, which is communicated to the AC through the Discovery Type message element (setion 4.4.18). The AC can also configure Acs, and associated priorities, on the WTP through the "AC Name with Index" message element (section 4.4.5). Finally, when the WTP has a prioritized order of ACs configured, but its primary AC goes down, it connects to an alternate. When connected, the WTP uses the Primary Discovery Request (section 5.3) to detect the presence of the primary. The WTP Fallback (section 4.4.34) defines the WTP's behavior when the primary AC goes back online. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Wednesday, September 13, 2006 3:34 PM > To: Pat Calhoun (pacalhou) > Cc: Nelson, David; Capwap@frascone.com > Subject: RE: [Capwap] Insufficient description of WTPs during > discovery > > HI, > > Well, why don't you provide a timing diagram with references > to section numbers in the spec to show your point. > > On Wed, 13 Sep 2006, Pat Calhoun (pacalhou) wrote: > > > > At time t(x) in the past, an WTP established a session with an AC > > > and transitioned to the run state. Due to a short term network > > > problem, the session between the WTP and AC is lost (terminated). > > > The CAPWAP-02 does not factor this history into the discovery > > > process. > > > > Actually, the protocol supports this event quite well. The protocol > > makes all of the tools available, including a very > comprehensive state > > machine. > > > > > This results in an increase in latency of the WTP reconnecting to > > > the AC, and the possibility of the WTP connecting to a > different AC, > > > plus the WTP and AC leaking information. > > > > How the WTP decides to reconnect is an implementation issue. We are > > not here to define the failover algorithms. The protocol > provides the > > tools, vendors are the crafters. > > > > > > 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 Thu Sep 14 12:22:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNtz5-0003uz-72 for capwap-archive@lists.ietf.org; Thu, 14 Sep 2006 12:22:39 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNtz3-0004gE-Ns for capwap-archive@lists.ietf.org; Thu, 14 Sep 2006 12:22:39 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id E1D7B398043 for ; Thu, 14 Sep 2006 09:22:34 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B3C5B430054 for ; Thu, 14 Sep 2006 09:21:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9B4FF1448032 for ; Thu, 14 Sep 2006 09:21:51 -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 CC0F51448035 for ; Thu, 14 Sep 2006 09:21:47 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 14 Sep 2006 09:21:47 -0700 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.20060308/8.12.11) with ESMTP id k8EGLl6T016076 for ; Thu, 14 Sep 2006 09:21:47 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8EGLl1E024479 for ; Thu, 14 Sep 2006 09:21:47 -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); Thu, 14 Sep 2006 09:21:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Sep 2006 09:21:46 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC0203EC0C@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ambiguities with DTLS Thread-Index: AcbYGd+Xyouhs8AQQc6CeoGBOGcrdQ== From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 14 Sep 2006 16:21:47.0195 (UTC) FILETIME=[E015E0B0:01C6D819] Authentication-Results: sj-dkim-1.cisco.com; header.From=boohara@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: [Capwap] Ambiguities with DTLS X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: e1e48a527f609d1be2bc8d8a70eb76cb The current draft seems to be ambiguous with respect to two DTLS items. The draft says in the section describing the stat machine transitions: Idle to Init (Z): This transition indicates the beginning of a DTLS session. WTP: The state transition is triggered by receipt of the DTLSStart command from the CAPWAP state machine, and causes the WTP to send a DTLS ClientHello to the AC. AC: The state transition is triggered by receipt of the DTLSStart command from the CAPWAP state machine. The AC starts the WaitJoin timer and awaits reception of a DTLS ClientHello message. In the description of transition aa, the draft says: AC: Upon receipt of a ClientHello message containing a valid cookie, the AC sets the WaitJoin timer. These two transitions seem to require "starting" or "setting" the Waitjoin timer in the AC both before and after the receipt of the ClientHello message. I believe the text in transition z is correct and should either be reflected in the description of transition aa, or removed from it to avoid conflict. The draft also says, in the description of transition o, that the WTP should send DTLSReset to the state machine. Should this be DTLSShutdown? -Bob Bob O'Hara Cisco Systems - WNBU Phone: +1 408 853 5513 Mobile: +1 408 218 4025 _________________________________________________________________ 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 Sep 14 12:51:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNuRC-0001lJ-BO for capwap-archive@lists.ietf.org; Thu, 14 Sep 2006 12:51:42 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNuR9-0008Mk-SF for capwap-archive@lists.ietf.org; Thu, 14 Sep 2006 12:51:42 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 09554144803D for ; Thu, 14 Sep 2006 09:51:36 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 23F55430054 for ; Thu, 14 Sep 2006 09:50:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 13F87398009 for ; Thu, 14 Sep 2006 09:50:24 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5DD71398036 for ; Thu, 14 Sep 2006 09:50:21 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 14 Sep 2006 09:50:22 -0700 X-IronPort-AV: i="4.09,165,1157353200"; d="scan'208"; a="321287240:sNHT33989148" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8EGoK8w018117 for ; Thu, 14 Sep 2006 09:50:20 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k8EGoKw7000426 for ; Thu, 14 Sep 2006 09:50:20 -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, 14 Sep 2006 09:50:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Sep 2006 09:50:19 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A2E36@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Ambiguities with DTLS Thread-Index: AcbYGd+Xyouhs8AQQc6CeoGBOGcrdQAA/Xjg From: "Pat Calhoun (pacalhou)" To: "Bob O'Hara (boohara)" , X-OriginalArrivalTime: 14 Sep 2006 16:50:20.0756 (UTC) FILETIME=[DD728940:01C6D81D] Authentication-Results: sj-dkim-5.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: Subject: Re: [Capwap] Ambiguities with DTLS X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: e8a67952aa972b528dd04570d58ad8fe Tracker issue 220 created. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Bob O'Hara (boohara) > Sent: Thursday, September 14, 2006 9:22 AM > To: Capwap@frascone.com > Subject: [Capwap] Ambiguities with DTLS > > The current draft seems to be ambiguous with respect to two > DTLS items. > > The draft says in the section describing the stat machine transitions: > Idle to Init (Z): This transition indicates the beginning of > a DTLS session. > > WTP: The state transition is triggered by receipt of the > DTLSStart command from the CAPWAP state machine, and causes > the WTP to send a DTLS ClientHello to the AC. > > AC: The state transition is triggered by receipt of the > DTLSStart command from the CAPWAP state machine. The AC > starts the WaitJoin timer and awaits reception of a DTLS > ClientHello message. > > In the description of transition aa, the draft says: > AC: Upon receipt of a ClientHello message containing a valid > cookie, the AC sets the WaitJoin timer. > > These two transitions seem to require "starting" or "setting" > the Waitjoin timer in the AC both before and after the > receipt of the ClientHello message. I believe the text in > transition z is correct and should either be reflected in the > description of transition aa, or removed from it to avoid conflict. > > The draft also says, in the description of transition o, that > the WTP should send DTLSReset to the state machine. Should > this be DTLSShutdown? > > -Bob > > Bob O'Hara > Cisco Systems - WNBU > > Phone: +1 408 853 5513 > Mobile: +1 408 218 4025 > > _________________________________________________________________ > 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 Sep 14 12:59:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNuZD-00053L-10 for capwap-archive@lists.ietf.org; Thu, 14 Sep 2006 12:59:59 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNuZB-0000CL-Fk for capwap-archive@lists.ietf.org; Thu, 14 Sep 2006 12:59:59 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id DC60F1448091 for ; Thu, 14 Sep 2006 09:59:53 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3EBBD430054 for ; Thu, 14 Sep 2006 09:58:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1F7ED1448058 for ; Thu, 14 Sep 2006 09:58:38 -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 9E2FF144808C for ; Thu, 14 Sep 2006 09:58:28 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 14 Sep 2006 09:58:28 -0700 X-IronPort-AV: i="4.09,165,1157353200"; d="scan'208"; a="341431147:sNHT32371752" 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 k8EGwRnC021695; Thu, 14 Sep 2006 09:58:27 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8EGwRQV006990; Thu, 14 Sep 2006 09:58:27 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Sep 2006 09:58:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Sep 2006 09:58:26 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A2E49@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Data channel policy negotiation Thread-Index: AcbR9HJXZna0kONmTp2TVqMcGiG51QAEGktwAFNvhnIBMtSAUA== From: "Pat Calhoun (pacalhou)" To: "Hasan Raza" , X-OriginalArrivalTime: 14 Sep 2006 16:58:27.0261 (UTC) FILETIME=[FF6D4ED0:01C6D81E] 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] Data channel policy negotiation X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 386e0819b1192672467565a524848168 I feel that there are few ambiguities in the capwap 02 draft related to the tunnel creation and data plane policy negotiation. Forgive me if these points have already been brought up and discussed over this list. 1. Draft -02 does not talk about when the capwap data tunnel is created or deleted. Is it implicitly assumed that data tunnel is created once WTP and AC reach join state? Yes, that is correct. 2. From the draft, WTP can encapsulate and tunnel wireless packets differently for different wlans. That is why, tunnel mode is passed to WTP in dot11 add wlan message element. Both MAC mode and Tunnel mode are present. Tunnel mode is not about having different encapsulation schemes across WLANs, but more about allowing a WTP to provide local MAC with some SSIDs, and split MAC with others. In all cases, the encapsulation is the same. I do wonder whether including MAC Mode on a WLAN basis makes sense, though. But how different type of tunneled packets are identified over the data plane? For e.g., bss0 tunnels 802.3 frames whereas, bss1 tunnels 802.11 frame. So when a capwap data packet arrives at AC, how the employed tunnel mode is identified? Based on the BSSID. Capwap transport header does not carry any payload encapsulation type. Moreover, the radio mac address optional field in capwap transport header may need to carry bssid instead of radio address -- there are multiple bss on a radio. Correct. I disagree with this decision, but if AC vendors can figure out a way to provide service, I guess it's up to them. 3. Draft does not also talk about how WTP is informed whether DTLS is used over data channel or not. Since it is a modifiable parameter, administrator can decide to turn on DTLS for say wtp0. But how wtp0 would know that administrator has changed this setting? wtp0 might still be sending plain packets which get discarded by the AC. Actually AC should inform this change over the capwap control plane to the WTP. But there is no such notification to WTP for this. I don't believe it can be changed "mid-stream". However, a clear way to signal the need for DTLS over the data channel is required. I've created issue 221 to track this. Is that the data plane policy is supposed to be vendor specific information, and it is exchanged through vendor specific payload message element? Sorry, I don't understand what you mean. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Hasan Raza [mailto:Hasan@sinett.com] Sent: Friday, September 08, 2006 8:03 AM To: Capwap@frascone.com Subject: [Capwap] Data channel policy negotiation Hi, Thanks Hasan _________________________________________________________________ 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 Sep 15 01:34:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO6LA-0007jT-SH for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 01:34:16 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO6L6-0003w4-Bh for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 01:34:16 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id A8AD51448069 for ; Thu, 14 Sep 2006 22:34:06 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9D789430054 for ; Thu, 14 Sep 2006 22:33:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 70579144805C for ; Thu, 14 Sep 2006 22:33:21 -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 7C442144804C for ; Thu, 14 Sep 2006 22:33:18 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 14 Sep 2006 22:33:18 -0700 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8F5XGl5005846 for ; Thu, 14 Sep 2006 22:33:17 -0700 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8F5W1Qt013484 for ; Fri, 15 Sep 2006 05:33:13 GMT Received: from xmb-blr-417.apac.cisco.com ([64.104.140.146]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 11:03:00 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 11:03:01 +0530 Message-ID: <6499201801FBC6419ED8C910302F67AC01CCF08F@xmb-blr-417.apac.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: mtu discovery? Thread-Index: AcbYiGisbShmgeeWR4iKFgMsv9g7Ig== From: "Smitha Smitha (ssmitha)" To: X-OriginalArrivalTime: 15 Sep 2006 05:33:00.0345 (UTC) FILETIME=[6849B290:01C6D888] Authentication-Results: sj-dkim-4.cisco.com; header.From=ssmitha@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_60_70, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] mtu discovery? X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1511111566==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. --===============1511111566== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D888.688C94C8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D888.688C94C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CAPWAP spec talks about fragmentation and reassembly, so we would need a way to determine the MTU. The spec does not mention any way to figure out the MTU, there is an "MTU Discovery Padding" message element mentioned, but details on when this gets sent etc are missing. =20 Thanks smitha =20 ------_=_NextPart_001_01C6D888.688C94C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
CAPWAP = spec talks=20 about fragmentation and reassembly, so we would need a way to determine = the MTU.=20 The spec does not mention any way to figure out the MTU, there is an = "MTU Discovery Padding" message element mentioned, but details = on when=20 this gets sent etc are missing.
 
Thanks
smitha
 
------_=_NextPart_001_01C6D888.688C94C8-- --===============1511111566== 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 --===============1511111566==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 15 05:06:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO9eQ-0006oN-TT for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 05:06:22 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO9eO-0000ya-8P for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 05:06:22 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 380D639808F for ; Fri, 15 Sep 2006 02:06:17 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1EE09430054 for ; Fri, 15 Sep 2006 02:04:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id ED5864306C3 for ; Fri, 15 Sep 2006 02:04:22 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 26D2043065C for ; Fri, 15 Sep 2006 02:04:18 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id k8F94Fac012476 for ; Fri, 15 Sep 2006 18:04:15 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k8F94I003787 for ; Fri, 15 Sep 2006 18:04:18 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with SMTP id k8F94I805677 for ; Fri, 15 Sep 2006 18:04:18 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 17:03:29 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD01277562@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbYpca9Lm62SFqASTm8sIMHPzAOswAAAh2w From: "Saravanan Govindan" To: 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.6 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_90_100, HTML_MESSAGE X-Spam-Level: Subject: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1277498999==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 241ffbb3f9799c962f0fd21d66e67867 This is a multi-part message in MIME format. --===============1277498999== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D8A5.CF8F42B1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D8A5.CF8F42B1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I wanted to give a more detailed explanation for the IEEE 802.11i Considerations requirement. This note describes how CAPWAP can be updated to satisfy this requirement =20 I would like to use this to highlight the proposal being put forward.=20 =20 =20 =20 >From RFC 4564, Section 5.1.10 IEEE 802.11i Considerations =20 Protocol Requirement: =20 The CAPWAP protocol MUST determine the exact structure of the centralized WLAN architecture in which authentication needs to be supported, i.e., the location of major authentication components. This may be achieved during WTP initialization where major capabilities are distinguished. =20 The protocol MUST allow for the exchange of key information when authenticator and encryption roles are located in distinct entities. =20 =20 Following the requirement, CAPWAP needs; =20 1. to incorporate authentication & encryption locations in=20 capabilities exchange =20 2. to exchange key information when authentication and crypt are located in different network entities =20 =20 Basic case: =20 AC does both IEEE 802.11i authentication and cryptography. For 4-way exchange, AC tracks the KeyRSC, which it then uses for Message-3, i.e., AC calculates KeyMIC and updates EAPoL frame. =20 =20 - 802.11i Authentication=20 - 802.11i Crypto=20 (KeyRSC maintained here) =20 +----------+ +-----+ +------+ | Terminal | | WTP | | AC | +----------+ +-----+ +------+ | | | | 802.1x Authentication | = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D>| | | | PMK | PMK | | | Generate | Generate SNonce | ANonce | | | | | | | Message-1 | |<-------------------------|<---------------------------| | EAPoL Packet | CAPWAP Packet | Receive | | ANonce | | Generate | | PTK | | | | | | Message-2 | |------------------------->|--------------------------->| | EAPoL Packet | CAPWAP Packet | | | Receive | | SNonce | | | | | Generate | | PTK | | GTK | Message-3 | |<-------------------------|<---------------------------| | EAPoL Packet | CAPWAP Packet | | | | | =20 | | | +-----------------------+ | | \|- EAPoL Frame | Receive | +-----------------------+ GTK | | | | | | | | | Message-4 | |------------------------->|--------------------------->| | EAPoL Packet | CAPWAP Packet | | | | =20 =20 =20 =20 Case specified by RFC 4564: =20 The 802.11i Considerations requirement considers the case where 802.11i authentication is at AC and 802.11i crypto is at WTP. So now, the WTP maintains the KeyRSC while the AC requires this information to generate the EAPoL frame for Message-3 of the 4-way handshake.=20 =20 The diagram below shows this; =20 - 802.11i Crypto =20 (KeyRSC maintained here) - 802.11i Authentication =20 +----------+ +-----+ +------+ | Terminal | | WTP | | AC | +----------+ +-----+ +------+ | | | | 802.1x Authentication | = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D>| | | | PMK | PMK | | | Generate | Generate SNonce | ANonce | | | =20 =20 In this case, the EAPoL frame generated by the AC will not be based on the prevailing value of the KeyRSC, as this counter is maintained by=20 the WTP.=20 =20 This problem is currently not solved in the CAPWAP specifications.=20 =20 =20 Proposal: =20 The proposal is to include a CAPWAP Key Configuration message that can transport the EAPoL frame between AC and WTP before being sent to the=20 client (terminal).=20 =20 Key Configuration is a control message sent by the AC to the WTP. The=20 message contains Message-3 of the 4-way handshake - including the=20 EAPoL-frame. However, the EAPoL frame has its KeyMIC field unassigned as the AC cannot accurately calculate this. =20 So on receiving the Key Configuration - containing EAPoL frame with unassigned KeyMIC field, the WTP retrieves the value of the KeyRSC it maintains and computes the corresponding KeyMIC.=20 =20 The EAPoL frame is then updated and Message-3 of the 4-way handshake is reconstructed before being sent over the wireless link to the client.=20 =20 =20 The diagram below illustrates this; =20 =20 - 802.11i Crypto =20 (KeyRSC maintained here) - 802.11i Authentication =20 +----------+ +-----+ +------+ | Terminal | | WTP | | AC | +----------+ +-----+ +------+ | | | | 802.1x Authentication | = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D>| | | | PMK | PMK | | | Generate | Generate SNonce | ANonce | | | | | | | Message 1 | |<-------------------------|<---------------------------| | EAPoL Packet | CAPWAP Packet | Receive | | ANonce | | Generate | | PTK | | | | | | Message 2 | |------------------------->|--------------------------->| | EAPoL Packet | CAPWAP Packet | | | Receive | | SNonce | | | | | Generate | | PTK | | GTK | | Message 3 | | = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D| | | CAPWAP Packet | | | (Key Configuration) | | | | +-----------------------+ | | \|- GTK-Flag | | -Retrieve KeyRSC |- Encryption-Data(PTK) | | -Update KeyMIC |- Encryption-Data(GTK) | | -Reconstruct |- EAP-Frame | | Message-3 +-----------------------+ | | | |<-------------------------| | | EAPoL Packet | | Receive | | GTK | |=20 | Message 4 | |------------------------->|--------------------------->| | EAPoL Packet | CAPWAP Packet | | | | =20 =20 =20 This proposal very simply solves the problem while directly addressing=20 the requirement for IEEE 802.11i Considerations. =20 =20 Cheers, =20 Saravanan ------_=_NextPart_001_01C6D8A5.CF8F42B1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,


I wanted to give a more detailed explanation for the IEEE 802.11i Considerations requirement. This note describes how CAPWAP can be = updated to satisfy this requirement

 

I would like to use this to = highlight the proposal being put forward.

 

 

 

From RFC 4564, Section 5.1.10 IEEE = 802.11i Considerations

 

   Protocol = Requirement:

 

   The CAPWAP protocol = MUST determine the exact structure of the

   centralized WLAN = architecture in which authentication needs to be

   supported, i.e., the = location of major authentication components.

   This may be achieved = during WTP initialization where major

   capabilities are distinguished.

 

   The protocol MUST = allow for the exchange of key information when

   authenticator and = encryption roles are located in distinct entities.

 

 

Following the requirement, CAPWAP = needs;

 

1. to incorporate authentication = & encryption locations in

   capabilities = exchange

 

2. to exchange key information when authentication and crypt are

   located in different = network entities

 

 

Basic = case:

 

AC does both IEEE 802.11i = authentication and cryptography. For 4-way

exchange, AC tracks the KeyRSC, = which it then uses for Message-3,

i.e., AC calculates KeyMIC and = updates EAPoL frame.

          &nb= sp;           &nbs= p;            = ;      

          &nb= sp;           &nbs= p;              &= nbsp;           

                  &= nbsp;           &n= bsp;           &nb= sp;       - 802.11i Authentication

          &nb= sp;           &nbs= p;            = ;            =    - 802.11i Crypto

          &nb= sp;           &nbs= p;            = ;            =       (KeyRSC maintained here)

                       &= nbsp;           &n= bsp;       

   +----------+          &= nbsp;      +-----+           =           +------+

   | Terminal |            =      | WTP |            =          |  AC  |

   +----------+          &= nbsp;      +-----+           =           +------+

        |                   &= nbsp;      |     &= nbsp;           &n= bsp;          |

        |            =         802.1x Authentication          = ;    |

        |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D>|

        |            =             &= nbsp; |            =             &= nbsp;   |

       PMK           &nbs= p;            = ; |            =             &= nbsp;  PMK

        |            =             &= nbsp; |            =             &= nbsp;   |

      Generate           = ;          |            =             Generate

       SNonce           &= nbsp;          |            =              ANonce

        |            =             &= nbsp; |            =             &= nbsp;   |

        |            =             &= nbsp; |            =             &= nbsp;   |

        |            =           Message-1          &nbs= p;            = ; |

        |<-------------------------|<---------------------------|

        |       EAPoL Packet       |        CAPWAP Packet       = |

      Receive           =            |            =             &= nbsp;   |

       ANonce           &= nbsp;          |            =                 |

      Generate           = ;          |            =             &= nbsp;   |

       PTK           &nbs= p;            = ; |            =             &= nbsp;   |

        |            =             &= nbsp; |            =             &= nbsp;   |

        |            =           Message-2                      &= nbsp; |

        |------------------------->|--------------------------->|

        |       EAPoL Packet       |        CAPWAP Packet       = |

        |            =             &= nbsp; |            =             Receive

        |            =             &= nbsp; |    =             &= nbsp;       SNonce

        |            =             &= nbsp; |            =             &= nbsp;   |

        |            =             &= nbsp; |            =            Generate

        |            =             &= nbsp; |            =             &= nbsp; PTK

        |            =               |      =             &= nbsp;       GTK

        |            =           Message-3          &nbs= p;            = ; |

        |<-------------------------|<---------------------------|

        |       EAPoL Packet       |   CAPWAP Packet            = |

        |                        &= nbsp; |      |   =             &= nbsp;     | 

        |            =             &= nbsp; |      | = +-----------------------+

        |            =             &= nbsp; |       \|- EAPoL = Frame          |

      Receive           =            |        = +-----------------------+

       GTK                     &= nbsp;   |                    &= nbsp;       |=

        |            =             &= nbsp; |        =             &= nbsp;       |=

        |            =             &= nbsp; |            =             &= nbsp;   |

        |            =           Message-4          &nbs= p;            = ; |

        |------------------------->|--------------------------->|

        |       EAPoL Packet       |         CAPWAP Packet      |

        |            =             &= nbsp; |            =             &= nbsp;   |

 

 

 

 

Case specified by RFC = 4564:

 

The 802.11i Considerations = requirement considers the case where 802.11i

authentication is at AC and 802.11i = crypto is at WTP. So now, the WTP

maintains the KeyRSC while the AC = requires this information to generate

the EAPoL frame for Message-3 of = the 4-way handshake.

 

The diagram below shows = this;

                  &= nbsp;           &n= bsp;           &nb= sp;        

          &nb= sp;           &nbs= p;     - 802.11i = Crypto           =

          &nb= sp;           &nbs= p;  (KeyRSC maintained here)      - 802.11i = Authentication

          &nb= sp;           &nbs= p;            = ;       

   +----------+          &= nbsp;      +-----+           =           +------+

   | Terminal |            =      | WTP |            =          |  AC  |

   +----------+          &= nbsp;      +-----+           =           +------+

        |            =             &= nbsp; |            =                 |

        |            =         802.1x Authentication          = ;    |

        |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D>|

        |            =             &= nbsp; |            =             &= nbsp;   |

       PMK           &nbs= p;            = ; |            =               &= nbsp;PMK

        |            =             &= nbsp; |            =             &= nbsp;   |

      Generate           = ;          |            =             Generate

       = SNonce           &= nbsp;          |            =              ANonce

        |            =             &= nbsp; |            =             &= nbsp;   |

 

 

In this case, the EAPoL frame = generated by the AC will not be based on

the prevailing value of the KeyRSC, = as this counter is maintained by

the WTP. =

 

This problem is currently not = solved in the CAPWAP specifications.

 

 

Proposal:

 

The proposal is to include a CAPWAP = Key Configuration message that can

transport the EAPoL frame between = AC and WTP before being sent to the

client (terminal). =

 

Key Configuration is a control = message sent by the AC to the WTP. The

message contains Message-3 of the = 4-way handshake - including the

EAPoL-frame. However, the EAPoL = frame has its KeyMIC field unassigned as

the AC cannot accurately calculate = this.

 

So on receiving the Key = Configuration - containing EAPoL frame with

unassigned KeyMIC field, the WTP = retrieves the value of the KeyRSC it

maintains and computes the = corresponding KeyMIC.

 

The EAPoL frame is then updated and Message-3 of the 4-way handshake is

reconstructed before being sent = over the wireless link to the client.

 

 

The diagram below illustrates = this;

 

 

          &nb= sp;           &nbs= p;     - 802.11i = Crypto           =

          &nb= sp;           &nbs= p;  (KeyRSC maintained here)      - 802.11i = Authentication

 

   +----------+          &= nbsp;      +-----+           =           +------+

   | Terminal |            =      | WTP |            =          |  AC  |

   +----------+          &= nbsp;      +-----+           =           +------+

        |            =             &= nbsp; |            =             &= nbsp;  |

        |            =         802.1x Authentication          = ;    |

        |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D>|

        |            =             &= nbsp; |            =             &= nbsp;   |

       PMK           &nbs= p;            = ; |                 &= nbsp;         PMK=

        |            =             &= nbsp; |            =             &= nbsp;   |

      Generate           = ;          |            =             Generate

       SNonce           &= nbsp;          |            =              ANonce

        |            =               |    =             &= nbsp;           |

        |            =             &= nbsp; |            =             &= nbsp;   |

        |            =           Message 1            =             |

        |<-------------------------|<---------------------------|

        |       EAPoL Packet       |        CAPWAP Packet       = |

      Receive           =            |            =             &= nbsp;   |

       ANonce           &= nbsp;          |            =             &= nbsp;   |

      Generate           = ;          |            =             &= nbsp;   |

       PTK             &= nbsp;           |&= nbsp;           &n= bsp;           &nb= sp;   |

        |            =             &= nbsp; |            =             &= nbsp;   |

        |            =           Message 2            =             |

        |------------------------->|--------------------------->|

        |       EAPoL Packet       |        CAPWAP Packet       = |

        |            =             &= nbsp; |            =             Receive

        |            =             &= nbsp; |            =             SNonce

        |            =             &= nbsp; |            =                 |=

        |            =             &= nbsp; |            =            Generate

        |            =             &= nbsp; |            =             &= nbsp; PTK

        |            =             &= nbsp; |            =             &= nbsp; GTK

        |            =             &= nbsp; |          Message 3         = |

        |            =             &= nbsp; |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D|

        |            =             &= nbsp; |        CAPWAP = Packet       |

        |            =             &= nbsp; |      (Key Configuration)   = |

        |            =             &= nbsp; |      | = +-----------------------+

        |            =             &= nbsp; |       \|- = GTK-Flag           = ;  |

        |            =      -Retrieve KeyRSC  |- Encryption-Data(PTK) = |

        |            =      -Update KeyMIC    |- Encryption-Data(GTK) = |

        |                &= nbsp;-Reconstruct      |- = EAP-Frame          &nbs= p; |

        |            =          Message-3     = +-----------------------+

        |            =             &= nbsp; |            =             &= nbsp;   |

        |<-------------------------|       =             &= nbsp;        |

        |       EAPoL Packet       |            =             &= nbsp;   |

     Receive           =             |            =             &= nbsp;   |

      GTK           &nbs= p;            = ;  |            =             &= nbsp;   |

        |            =           Message 4            =             |<= /span>

        |------------------------->|--------------------------->|

        |       EAPoL Packet       |        CAPWAP Packet       = |

        |            =             &= nbsp; |            =             &= nbsp;   |

 

 

 

This proposal very simply solves = the problem while directly addressing

the requirement for IEEE 802.11i Considerations.

 

 

Cheers,

 

Saravanan

------_=_NextPart_001_01C6D8A5.CF8F42B1-- --===============1277498999== 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 --===============1277498999==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 15 11:10:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFKw-0007Vj-Nm for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 11:10:38 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOFKq-0000T6-1N for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 11:10:38 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 00807144807B for ; Fri, 15 Sep 2006 08:10:23 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id ABD8E430094 for ; Fri, 15 Sep 2006 08:08:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 785E13980DE for ; Fri, 15 Sep 2006 08:08:04 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id BCEDD398090 for ; Fri, 15 Sep 2006 08:01:50 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 15 Sep 2006 08:01:37 -0700 X-IronPort-AV: i="4.09,171,1157353200"; d="scan'208,217"; a="321683430:sNHT5100548362" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8FF1bEB016703; Fri, 15 Sep 2006 08:01:37 -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 k8FF1TwT022074; Fri, 15 Sep 2006 08:01:36 -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); Fri, 15 Sep 2006 08:01:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 08:01:32 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A3224@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbYpca9Lm62SFqASTm8sIMHPzAOswAAAh2wAAxv6TA= From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , X-OriginalArrivalTime: 15 Sep 2006 15:01:34.0273 (UTC) FILETIME=[D5C60310:01C6D8D7] Authentication-Results: sj-dkim-7.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 52 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.562 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_90_100, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1574893995==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: cc67f9dd11fa845f47ce5aea949d5800 This is a multi-part message in MIME format. --===============1574893995== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D8D7.D5A79C53" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D8D7.D5A79C53 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I understand the proposal, but stand firm on my belief that this additional mode of operation is unnecessary. While it is possible to implement, as everything is in a protocol, I believe the WG needs to focus on fixing the protocol in the areas where it is broken, as opposed to adding more optional modes that really do not change the outcome of the functions. =20 Perhaps what would be more useful is not to describe the method, but the reason why this is being proposed. I still fail to understand why you believe this mode of operation is necessary. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Friday, September 15, 2006 2:03 AM To: capwap@frascone.com Subject: [Capwap] Issue 43 - Explanation for 802.11i Considerations =09 =09 All, =09 I wanted to give a more detailed explanation for the IEEE 802.11i Considerations requirement. This note describes how CAPWAP can be updated to satisfy this requirement =20 I would like to use this to highlight the proposal being put forward.=20 =20 =20 =20 From RFC 4564, Section 5.1.10 IEEE 802.11i Considerations =20 Protocol Requirement: =20 The CAPWAP protocol MUST determine the exact structure of the centralized WLAN architecture in which authentication needs to be supported, i.e., the location of major authentication components. This may be achieved during WTP initialization where major capabilities are distinguished. =20 The protocol MUST allow for the exchange of key information when authenticator and encryption roles are located in distinct entities. =20 =20 Following the requirement, CAPWAP needs; =20 1. to incorporate authentication & encryption locations in=20 capabilities exchange =20 2. to exchange key information when authentication and crypt are located in different network entities =20 =20 Basic case: =20 AC does both IEEE 802.11i authentication and cryptography. For 4-way exchange, AC tracks the KeyRSC, which it then uses for Message-3, i.e., AC calculates KeyMIC and updates EAPoL frame. =20 =20 - 802.11i Authentication=20 - 802.11i Crypto=20 (KeyRSC maintained here) =20 +----------+ +-----+ +------+ | Terminal | | WTP | | AC | +----------+ +-----+ +------+ | | | | 802.1x Authentication | =09 |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D>| | | | PMK | PMK | | | Generate | Generate SNonce | ANonce | | | | | | | Message-1 | =09 |<-------------------------|<---------------------------| | EAPoL Packet | CAPWAP Packet | Receive | | ANonce | | Generate | | PTK | | | | | | Message-2 | =09 |------------------------->|--------------------------->| | EAPoL Packet | CAPWAP Packet | | | Receive | | SNonce | | | | | Generate | | PTK | | GTK | Message-3 | =09 |<-------------------------|<---------------------------| | EAPoL Packet | CAPWAP Packet | | | | | =20 | | | +-----------------------+ | | \|- EAPoL Frame | Receive | +-----------------------+ GTK | | | | | | | | | Message-4 | =09 |------------------------->|--------------------------->| | EAPoL Packet | CAPWAP Packet | | | | =20 =20 =20 =20 Case specified by RFC 4564: =20 The 802.11i Considerations requirement considers the case where 802.11i authentication is at AC and 802.11i crypto is at WTP. So now, the WTP maintains the KeyRSC while the AC requires this information to generate the EAPoL frame for Message-3 of the 4-way handshake.=20 =20 The diagram below shows this; =20 - 802.11i Crypto =20 (KeyRSC maintained here) - 802.11i Authentication =20 +----------+ +-----+ +------+ | Terminal | | WTP | | AC | +----------+ +-----+ +------+ | | | | 802.1x Authentication | =09 |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D>| | | | PMK | PMK | | | Generate | Generate SNonce | ANonce | | | =20 =20 In this case, the EAPoL frame generated by the AC will not be based on the prevailing value of the KeyRSC, as this counter is maintained by=20 the WTP.=20 =20 This problem is currently not solved in the CAPWAP specifications.=20 =20 =20 Proposal: =20 The proposal is to include a CAPWAP Key Configuration message that can transport the EAPoL frame between AC and WTP before being sent to the=20 client (terminal).=20 =20 Key Configuration is a control message sent by the AC to the WTP. The=20 message contains Message-3 of the 4-way handshake - including the=20 EAPoL-frame. However, the EAPoL frame has its KeyMIC field unassigned as the AC cannot accurately calculate this. =20 So on receiving the Key Configuration - containing EAPoL frame with unassigned KeyMIC field, the WTP retrieves the value of the KeyRSC it maintains and computes the corresponding KeyMIC.=20 =20 The EAPoL frame is then updated and Message-3 of the 4-way handshake is reconstructed before being sent over the wireless link to the client.=20 =20 =20 The diagram below illustrates this; =20 =20 - 802.11i Crypto =20 (KeyRSC maintained here) - 802.11i Authentication =20 +----------+ +-----+ +------+ | Terminal | | WTP | | AC | +----------+ +-----+ +------+ | | | | 802.1x Authentication | =09 |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D>| | | | PMK | PMK | | | Generate | Generate SNonce | ANonce | | | | | | | Message 1 | =09 |<-------------------------|<---------------------------| | EAPoL Packet | CAPWAP Packet | Receive | | ANonce | | Generate | | PTK | | | | | | Message 2 | =09 |------------------------->|--------------------------->| | EAPoL Packet | CAPWAP Packet | | | Receive | | SNonce | | | | | Generate | | PTK | | GTK | | Message 3 | | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D| | | CAPWAP Packet | | | (Key Configuration) | | | | +-----------------------+ | | \|- GTK-Flag | | -Retrieve KeyRSC |- Encryption-Data(PTK) | | -Update KeyMIC |- Encryption-Data(GTK) | | -Reconstruct |- EAP-Frame | | Message-3 +-----------------------+ | | | |<-------------------------| | | EAPoL Packet | | Receive | | GTK | |=20 | Message 4 | =09 |------------------------->|--------------------------->| | EAPoL Packet | CAPWAP Packet | | | | =20 =20 =20 This proposal very simply solves the problem while directly addressing=20 the requirement for IEEE 802.11i Considerations. =20 =20 Cheers, =20 Saravanan ------_=_NextPart_001_01C6D8D7.D5A79C53 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 understand the proposal, but stand firm on my belief that this = additional mode=20 of operation is unnecessary. While it is possible to implement, as = everything is=20 in a protocol, I believe the WG needs to focus on fixing the protocol in = the=20 areas where it is broken, as opposed to adding more optional modes that = really=20 do not change the outcome of the functions.
 
Perhaps what would be more useful is not to describe the = method, but the=20 reason why this is being proposed. I still fail to understand why you = believe=20 this mode of operation is necessary.
 

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

 

From: Saravanan Govindan=20 [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Friday,=20 September 15, 2006 2:03 AM
To:=20 capwap@frascone.com
Subject: [Capwap] Issue 43 - Explanation = for=20 802.11i Considerations

All,


I wanted = to give a=20 more detailed explanation for the IEEE 802.11i Considerations = requirement.=20 This note describes how CAPWAP can be updated to satisfy this=20 requirement

 

I would like = to use=20 this to highlight the proposal being put forward.=20

 

 

 

From RFC = 4564, Section=20 5.1.10 IEEE 802.11i Considerations

 

   = Protocol=20 Requirement:

 

   = The CAPWAP=20 protocol MUST determine the exact structure of=20 the

  =20 centralized WLAN architecture in which authentication needs to=20 be

   = supported,=20 i.e., the location of major authentication=20 components.

   = This may=20 be achieved during WTP initialization where = major

  =20 capabilities are distinguished.

 

   = The=20 protocol MUST allow for the exchange of key information=20 when

  =20 authenticator and encryption roles are located in distinct=20 entities.

 

 

Following the = requirement, CAPWAP needs;

 

1. to = incorporate=20 authentication & encryption locations in =

  =20 capabilities exchange

 

2. to = exchange key=20 information when authentication and crypt = are

   = located in=20 different network entities

 

 

Basic=20 case:

 

AC does both = IEEE=20 802.11i authentication and cryptography. For=20 4-way

exchange, AC = tracks the=20 KeyRSC, which it then uses for Message-3,

i.e., AC = calculates=20 KeyMIC and updates EAPoL frame.

          &nb= sp;           &nbs= p;            = ;      =20

          &nb= sp;           &nbs= p; =20 =             &= nbsp;           

     =20 =             &= nbsp;           &n= bsp;           &nb= sp;      =20 - 802.11i Authentication

          &nb= sp;           &nbs= p;            = ;            =   =20 - 802.11i Crypto

          &nb= sp;           &nbs= p;            = ;            =      =20 (KeyRSC maintained here)

          =20 =             &= nbsp;           &n= bsp;       

  =20 = +----------+          &= nbsp;     =20 = +-----+           =          =20 +------+

   = | Terminal=20 = |            =     =20 | WTP=20 = |            =         =20 |  AC  |

  =20 = +----------+          &= nbsp;     =20 = +-----+           =          =20 +------+

       =20 |      =20 =             &= nbsp;      |     &= nbsp;           &n= bsp;         =20 |

       =20 = |            =        =20 802.1x=20 = Authentication          = ;   =20 |

       =20 = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D>|

       =20 = |            =             &= nbsp;=20 = |            =             &= nbsp;  =20 |

      =20 = PMK           &nbs= p;            = ;=20 = |            =             &= nbsp; =20 PMK

       =20 = |            =             &= nbsp;=20 = |            =             &= nbsp;  =20 |

     =20 = Generate           = ;         =20 = |            =            =20 Generate

      =20 = SNonce           &= nbsp;         =20 = |            =              = ANonce

       =20 = |            =             &= nbsp;=20 = |            =             &= nbsp;  =20 |

       =20 = |            =             &= nbsp;=20 = |            =             &= nbsp;  =20 |

       =20 = |            =          =20 = Message-1          &nbs= p;            = ;=20 |

       =20 = |<-------------------------|<---------------------------|

       =20 |       EAPoL=20 Packet      =20 |        CAPWAP=20 Packet       = |

     =20 = Receive           =           =20 = |            =             &= nbsp;  =20 |

      =20 = ANonce           &= nbsp;         =20 = |            =          =20       |

     =20 = Generate           = ;         =20 = |            =             &= nbsp;  =20 |

      =20 = PTK           &nbs= p;            = ;=20 = |            =             &= nbsp;  =20 |

       =20 = |            =             &= nbsp;=20 = |            =             &= nbsp;  =20 |

       =20 = |            =          =20 Message-2         =20 =             &= nbsp; |

       =20 = |------------------------->|--------------------------->|

       =20 |       EAPoL=20 Packet      =20 |        CAPWAP=20 Packet       = |

       =20 = |            =             &= nbsp;=20 = |            =            =20 Receive

       =20 = |            =             &= nbsp;=20 |   =20 =             &= nbsp;       SNonce

       =20 = |            =             &= nbsp;=20 = |            =             &= nbsp;  =20 |

       =20 = |            =             &= nbsp;=20 = |            =           =20 Generate

       =20 = |            =             &= nbsp;=20 = |            =             &= nbsp;=20 PTK

       =20 = |            =        =20 =       |      =             &= nbsp;      =20 GTK

       =20 = |            =          =20 = Message-3          &nbs= p;            = ;=20 |

       =20 = |<-------------------------|<---------------------------|

       =20 |       EAPoL=20 Packet       |   CAPWAP=20 = Packet            = |

       =20 |           =20 =             &= nbsp; |     =20 |  =20 =             &= nbsp;     | =20

       =20 = |            =             &= nbsp;=20 |      |=20 +-----------------------+

       =20 = |            =             &= nbsp;=20 |       \|- EAPoL=20 Frame         =20 |

     =20 = Receive           =           =20 |       =20 +-----------------------+

      =20 GTK        =20 =             &= nbsp;   |       =20 =             &= nbsp;       |=

       =20 = |            =             &= nbsp;=20 |       =20 =             &= nbsp;       |=

       =20 = |            =             &= nbsp;=20 = |            =             &= nbsp;  =20 |

       =20 = |            =          =20 = Message-4          &nbs= p;            = ;=20 |

       =20 = |------------------------->|--------------------------->|

       =20 |       EAPoL=20 Packet      =20 |         CAPWAP=20 Packet      |

       =20 = |            =             &= nbsp;=20 = |            =             &= nbsp;  =20 |

 

 

 

 

Case = specified by RFC=20 4564:

 

The 802.11i=20 Considerations requirement considers the case where=20 802.11i

authentication is at AC=20 and 802.11i crypto is at WTP. So now, the = WTP

maintains the = KeyRSC=20 while the AC requires this information to=20 generate

the EAPoL = frame for=20 Message-3 of the 4-way handshake.

 

The diagram = below shows=20 this;

     =20 =             &= nbsp;           &n= bsp;           &nb= sp;        =20

          &nb= sp;           &nbs= p;    =20 - 802.11i = Crypto          =20

          &nb= sp;           &nbs= p; =20 (KeyRSC maintained here)      - 802.11i=20 Authentication

          &nb= sp;           &nbs= p;            = ;       =20

  =20 = +----------+          &= nbsp;     =20 = +-----+           =          =20 +------+

   = | Terminal=20 = |            =     =20 | WTP=20 = |            =         =20 |  AC  |

  =20 = +----------+          &= nbsp;     =20 = +-----+           =          =20 +------+

       =20 = |            =             &= nbsp;=20 = |            =          =20       |

       =20 = |            =        =20 802.1x=20 = Authentication          = ;   =20 |

       =20 = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D>|

       =20 = |            =             &= nbsp;=20 = |            =             &= nbsp;  =20 |

      =20 = PMK           &nbs= p;            = ;=20 = |            =  =20 =             &= nbsp;PMK

       =20 = |            =             &= nbsp;=20 = |            =             &= nbsp;  =20 |

     =20 = Generate           = ;         =20 = |            =            =20 Generate

      =20 = SNonce           &= nbsp;         =20 = |            =              = ANonce

       =20 = |            =             &= nbsp;=20 = |            =             &= nbsp;  =20 |

 

 

In this case, = the EAPoL=20 frame generated by the AC will not be based = on

the = prevailing value of=20 the KeyRSC, as this counter is maintained by =

the WTP.=20

 

This problem = is=20 currently not solved in the CAPWAP specifications.=20

 

 

Proposal:

 

The proposal = is to=20 include a CAPWAP Key Configuration message that=20 can

transport the = EAPoL=20 frame between AC and WTP before being sent to the=20

client = (terminal).=20

 

Key = Configuration is a=20 control message sent by the AC to the WTP. The =

message = contains=20 Message-3 of the 4-way handshake - including the =

EAPoL-frame. = However,=20 the EAPoL frame has its KeyMIC field unassigned=20 as

the AC cannot = accurately calculate this.

 

So on = receiving the Key=20 Configuration - containing EAPoL frame = with

unassigned = KeyMIC=20 field, the WTP retrieves the value of the KeyRSC=20 it

maintains and = computes=20 the corresponding KeyMIC.

 

The EAPoL = frame is then=20 updated and Message-3 of the 4-way handshake = is

reconstructed = before=20 being sent over the wireless link to the client. =

 

 

The diagram = below=20 illustrates this;

 

 

          &nb= sp;           &nbs= p;    =20 - 802.11i = Crypto          =20

          &nb= sp;           &nbs= p; =20 (KeyRSC maintained here)      - 802.11i=20 Authentication

 

  =20 = +----------+          &= nbsp;     =20 = +-----+           =          =20 +------+

   = | Terminal=20 = |            =     =20 | WTP=20 = |            =         =20 |  AC  |

  =20 = +----------+          &= nbsp;     =20 = +-----+           =          =20 +------+

       =20 = |            =             &= nbsp;=20 = |            = =20 =             &= nbsp;  |

       =20 = |            =        =20 802.1x=20 = Authentication          = ;   =20 |

       =20 = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D>|

       =20 = |            =             &= nbsp;=20 = |            =             &= nbsp;  =20 |

      =20 = PMK           &nbs= p;            = ;=20 |    =20 =             &= nbsp;         PMK=

       =20 = |            =             &= nbsp;=20 = |            =             &= nbsp;  =20 |

     =20 = Generate           = ;         =20 = |            =            =20 Generate

      =20 = SNonce           &= nbsp;         =20 = |            =              = ANonce

       =20 = |            =      =20 =         |    =             &= nbsp;          =20 |

       =20 = |            =             &= nbsp;=20 = |            =             &= nbsp;  =20 |

       =20 = |            =          =20 Message=20 = 1            =            =20 |

       =20 = |<-------------------------|<---------------------------|

       =20 |       EAPoL=20 Packet      =20 |        CAPWAP=20 Packet       = |

     =20 = Receive           =           =20 = |            =             &= nbsp;  =20 |

      =20 = ANonce           &= nbsp;         =20 = |            =             &= nbsp;  =20 |

     =20 = Generate           = ;         =20 = |            =             &= nbsp;  =20 |

      =20 PTK=20 =             &= nbsp;           |&= nbsp;           &n= bsp;           &nb= sp;  =20 |

       =20 = |            =             &= nbsp;=20 = |            =             &= nbsp;  =20 |

       =20 = |            =          =20 Message=20 = 2            =            =20 |

       =20 = |------------------------->|--------------------------->|

       =20 |       EAPoL=20 Packet      =20 |        CAPWAP=20 Packet       = |

       =20 = |            =             &= nbsp;=20 = |            =            =20 Receive

       =20 = |            =             &= nbsp;=20 = |            =            =20 SNonce

       =20 = |            =             &= nbsp;=20 = |            =       =20 =          |=

       =20 = |            =             &= nbsp;=20 = |            =           =20 Generate

       =20 = |            =             &= nbsp;=20 = |            =             &= nbsp;=20 PTK

       =20 = |            =             &= nbsp;=20 = |            =             &= nbsp;=20 GTK

       =20 = |            =             &= nbsp;=20 |          Message=20 3        =20 |

       =20 = |            =             &= nbsp;=20 = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D|

       =20 = |            =             &= nbsp;=20 |        CAPWAP=20 Packet       = |

       =20 = |            =             &= nbsp;=20 |      (Key Configuration)  =20 |

       =20 = |            =             &= nbsp;=20 |      |=20 +-----------------------+

       =20 = |            =             &= nbsp;=20 |       \|-=20 = GTK-Flag           = ; =20 |

       =20 = |            =     =20 -Retrieve KeyRSC  |- Encryption-Data(PTK) = |

       =20 = |            =     =20 -Update KeyMIC    |- Encryption-Data(GTK)=20 |

       =20 |   =20 =             &= nbsp;-Reconstruct     =20 |- = EAP-Frame          &nbs= p;=20 |

       =20 = |            =         =20 Message-3    =20 +-----------------------+

       =20 = |            =             &= nbsp;=20 = |            =             &= nbsp;  =20 |

       =20 = |<-------------------------|       =             &= nbsp;      =20  |

       =20 |       EAPoL=20 Packet      =20 = |            =             &= nbsp;  =20 |

    =20 = Receive           =            =20 = |            =             &= nbsp;  =20 |

     =20 = GTK           &nbs= p;            = ; =20 = |            =             &= nbsp;  =20 |

       =20 = |            =          =20 Message=20 = 4            =  =20 =           |<= /SPAN>

       =20 = |------------------------->|--------------------------->|

       =20 |       EAPoL=20 Packet      =20 |        CAPWAP=20 Packet       = |

       =20 = |            =             &= nbsp;=20 = |            =             &= nbsp;  =20 |

 

 

 

This proposal = very=20 simply solves the problem while directly addressing=20

the = requirement for=20 IEEE 802.11i Considerations.

 

 

Cheers,

 

Saravanan

------_=_NextPart_001_01C6D8D7.D5A79C53-- --===============1574893995== 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 --===============1574893995==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 15 12:09:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOGGC-0001BH-R6 for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 12:09:48 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOGGA-0005U2-S6 for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 12:09:48 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id E92FC1448030 for ; Fri, 15 Sep 2006 09:09:42 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 257AF430094 for ; Fri, 15 Sep 2006 09:08:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1858A39829F for ; Fri, 15 Sep 2006 09:08:17 -0700 (PDT) Received: from bay0-omc3-s33.bay0.hotmail.com (bay0-omc3-s33.bay0.hotmail.com [65.54.246.233]) by zoidberg.tigertech.net (Postfix) with ESMTP id 218233980F5 for ; Fri, 15 Sep 2006 09:00:05 -0700 (PDT) Received: from hotmail.com ([207.46.8.226]) by bay0-omc3-s33.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 09:00:04 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 15 Sep 2006 09:00:04 -0700 Message-ID: Received: from 207.46.8.251 by by118fd.bay118.hotmail.msn.com with HTTP; Fri, 15 Sep 2006 16:00:02 GMT X-Originating-IP: [202.156.10.12] X-Originating-Email: [saravanang@hotmail.com] X-Sender: saravanang@hotmail.com In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2027A3224@xmb-sjc-235.amer.cisco.com> From: "Saravanan Govindan" To: pcalhoun@cisco.com, capwap@frascone.com Date: Sat, 16 Sep 2006 00:00:02 +0800 Mime-Version: 1.0 X-OriginalArrivalTime: 15 Sep 2006 16:00:04.0043 (UTC) FILETIME=[01C269B0:01C6D8E0] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.748 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 08156cf414e01129f6a937203576bf20 I want to emphasize that this is not an "additional" feature - it is a mandatory requirement from RFC 4564. The protocol currently does not meet the requirement. Saravanan ----Original Message Follows---- From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations Date: Fri, 15 Sep 2006 08:01:32 -0700 I understand the proposal, but stand firm on my belief that this additional mode of operation is unnecessary. While it is possible to implement, as everything is in a protocol, I believe the WG needs to focus on fixing the protocol in the areas where it is broken, as opposed to adding more optional modes that really do not change the outcome of the functions. Perhaps what would be more useful is not to describe the method, but the reason why this is being proposed. I still fail to understand why you believe this mode of operation is necessary. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Friday, September 15, 2006 2:03 AM To: capwap@frascone.com Subject: [Capwap] Issue 43 - Explanation for 802.11i Considerations All, I wanted to give a more detailed explanation for the IEEE 802.11i Considerations requirement. This note describes how CAPWAP can be updated to satisfy this requirement I would like to use this to highlight the proposal being put forward. From RFC 4564, Section 5.1.10 IEEE 802.11i Considerations Protocol Requirement: The CAPWAP protocol MUST determine the exact structure of the centralized WLAN architecture in which authentication needs to be supported, i.e., the location of major authentication components. This may be achieved during WTP initialization where major capabilities are distinguished. The protocol MUST allow for the exchange of key information when authenticator and encryption roles are located in distinct entities. Following the requirement, CAPWAP needs; 1. to incorporate authentication & encryption locations in capabilities exchange 2. to exchange key information when authentication and crypt are located in different network entities Basic case: AC does both IEEE 802.11i authentication and cryptography. For 4-way exchange, AC tracks the KeyRSC, which it then uses for Message-3, i.e., AC calculates KeyMIC and updates EAPoL frame. - 802.11i Authentication - 802.11i Crypto (KeyRSC maintained here) +----------+ +-----+ +------+ | Terminal | | WTP | | AC | +----------+ +-----+ +------+ | | | | 802.1x Authentication | |<=====================================================>| | | | PMK | PMK | | | Generate | Generate SNonce | ANonce | | | | | | | Message-1 | |<-------------------------|<---------------------------| | EAPoL Packet | CAPWAP Packet | Receive | | ANonce | | Generate | | PTK | | | | | | Message-2 | |------------------------->|--------------------------->| | EAPoL Packet | CAPWAP Packet | | | Receive | | SNonce | | | | | Generate | | PTK | | GTK | Message-3 | |<-------------------------|<---------------------------| | EAPoL Packet | CAPWAP Packet | | | | | | | | +-----------------------+ | | \|- EAPoL Frame | Receive | +-----------------------+ GTK | | | | | | | | | Message-4 | |------------------------->|--------------------------->| | EAPoL Packet | CAPWAP Packet | | | | Case specified by RFC 4564: The 802.11i Considerations requirement considers the case where 802.11i authentication is at AC and 802.11i crypto is at WTP. So now, the WTP maintains the KeyRSC while the AC requires this information to generate the EAPoL frame for Message-3 of the 4-way handshake. The diagram below shows this; - 802.11i Crypto (KeyRSC maintained here) - 802.11i Authentication +----------+ +-----+ +------+ | Terminal | | WTP | | AC | +----------+ +-----+ +------+ | | | | 802.1x Authentication | |<=====================================================>| | | | PMK | PMK | | | Generate | Generate SNonce | ANonce | | | In this case, the EAPoL frame generated by the AC will not be based on the prevailing value of the KeyRSC, as this counter is maintained by the WTP. This problem is currently not solved in the CAPWAP specifications. Proposal: The proposal is to include a CAPWAP Key Configuration message that can transport the EAPoL frame between AC and WTP before being sent to the client (terminal). Key Configuration is a control message sent by the AC to the WTP. The message contains Message-3 of the 4-way handshake - including the EAPoL-frame. However, the EAPoL frame has its KeyMIC field unassigned as the AC cannot accurately calculate this. So on receiving the Key Configuration - containing EAPoL frame with unassigned KeyMIC field, the WTP retrieves the value of the KeyRSC it maintains and computes the corresponding KeyMIC. The EAPoL frame is then updated and Message-3 of the 4-way handshake is reconstructed before being sent over the wireless link to the client. The diagram below illustrates this; - 802.11i Crypto (KeyRSC maintained here) - 802.11i Authentication +----------+ +-----+ +------+ | Terminal | | WTP | | AC | +----------+ +-----+ +------+ | | | | 802.1x Authentication | |<=====================================================>| | | | PMK | PMK | | | Generate | Generate SNonce | ANonce | | | | | | | Message 1 | |<-------------------------|<---------------------------| | EAPoL Packet | CAPWAP Packet | Receive | | ANonce | | Generate | | PTK | | | | | | Message 2 | |------------------------->|--------------------------->| | EAPoL Packet | CAPWAP Packet | | | Receive | | SNonce | | | | | Generate | | PTK | | GTK | | Message 3 | | |<===========================| | | CAPWAP Packet | | | (Key Configuration) | | | | +-----------------------+ | | \|- GTK-Flag | | -Retrieve KeyRSC |- Encryption-Data(PTK) | | -Update KeyMIC |- Encryption-Data(GTK) | | -Reconstruct |- EAP-Frame | | Message-3 +-----------------------+ | | | |<-------------------------| | | EAPoL Packet | | Receive | | GTK | | | Message 4 | |------------------------->|--------------------------->| | EAPoL Packet | CAPWAP Packet | | | | This proposal very simply solves the problem while directly addressing the requirement for IEEE 802.11i Considerations. Cheers, Saravanan _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ _________________________________________________________________ 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 Sep 15 13:37:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOHcs-00054c-KX for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 13:37:18 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOHcn-0002aE-Sd for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 13:37:18 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id D396B3982EA for ; Fri, 15 Sep 2006 10:37:08 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EA214430094 for ; Fri, 15 Sep 2006 10:36:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CDF4B1448026 for ; Fri, 15 Sep 2006 10:36:02 -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 A57A11448023 for ; Fri, 15 Sep 2006 10:35:58 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 15 Sep 2006 10:35:55 -0700 X-IronPort-AV: i="4.09,171,1157353200"; d="scan'208"; a="443393472:sNHT40406434" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8FHZsd1000332; Fri, 15 Sep 2006 10:35:54 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8FHZiR5029708; Fri, 15 Sep 2006 10:35:54 -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); Fri, 15 Sep 2006 10:35:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 10:35:53 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A32DD@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbY4CMB7agq4TySSwi0SsMRMuBTQgADSCsA From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , X-OriginalArrivalTime: 15 Sep 2006 17:35:54.0317 (UTC) FILETIME=[653097D0:01C6D8ED] Authentication-Results: sj-dkim-3.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] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: b4b36b0fb877eeac6f347960137fc10b The "protocol" performs the function of 802.1X/802.11i without any issues in both the SplitMAC and LocalMAC operation. Are you stating this is required because RFC4564 states that flexibility is required, or because there is an actual need for this feature? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Saravanan Govindan [mailto:saravanang@hotmail.com] > Sent: Friday, September 15, 2006 9:00 AM > To: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > I want to emphasize that this is not an "additional" feature > - it is a mandatory requirement from RFC 4564. The protocol > currently does not meet the requirement. > > Saravanan > > > > ----Original Message Follows---- > From: "Pat Calhoun (pacalhou)" > To: "Saravanan Govindan" > , > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > Date: Fri, 15 Sep 2006 08:01:32 -0700 > > I understand the proposal, but stand firm on my belief that > this additional mode of operation is unnecessary. While it is > possible to implement, as everything is in a protocol, I > believe the WG needs to focus on fixing the protocol in the > areas where it is broken, as opposed to adding more optional > modes that really do not change the outcome of the functions. > > Perhaps what would be more useful is not to describe the > method, but the reason why this is being proposed. I still > fail to understand why you believe this mode of operation is > necessary. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > ________________________________ > > From: Saravanan Govindan > [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Friday, September 15, 2006 2:03 AM > To: capwap@frascone.com > Subject: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > All, > > > I wanted to give a more detailed explanation for the > IEEE 802.11i Considerations requirement. This note describes > how CAPWAP can be updated to satisfy this requirement > > > > I would like to use this to highlight the proposal > being put forward. > > > > > > > > From RFC 4564, Section 5.1.10 IEEE 802.11i Considerations > > > > Protocol Requirement: > > > > The CAPWAP protocol MUST determine the exact structure of the > > centralized WLAN architecture in which > authentication needs to be > > supported, i.e., the location of major > authentication components. > > This may be achieved during WTP initialization where major > > capabilities are distinguished. > > > > The protocol MUST allow for the exchange of key > information when > > authenticator and encryption roles are located in > distinct entities. > > > > > > Following the requirement, CAPWAP needs; > > > > 1. to incorporate authentication & encryption locations in > > capabilities exchange > > > > 2. to exchange key information when authentication and crypt are > > located in different network entities > > > > > > Basic case: > > > > AC does both IEEE 802.11i authentication and > cryptography. For 4-way > > exchange, AC tracks the KeyRSC, which it then uses for > Message-3, > > i.e., AC calculates KeyMIC and updates EAPoL frame. > > > > > > - > 802.11i Authentication > > - > 802.11i Crypto > > > (KeyRSC maintained here) > > > > +----------+ +-----+ > +------+ > > | Terminal | | WTP | | > AC | > > +----------+ +-----+ > +------+ > > | | > | > > | 802.1x Authentication > | > > > |<=====================================================>| > > | | > | > > PMK | > PMK > > | | > | > > Generate | > Generate > > SNonce | > ANonce > > | | > | > > | | > | > > | Message-1 > | > > > |<-------------------------|<---------------------------| > > | EAPoL Packet | CAPWAP Packet > | > > Receive | > | > > ANonce | > | > > Generate | > | > > PTK | > | > > | | > | > > | Message-2 > | > > > |------------------------->|--------------------------->| > > | EAPoL Packet | CAPWAP Packet > | > > | | > Receive > > | | > SNonce > > | | > | > > | | > Generate > > | | > PTK > > | | > GTK > > | Message-3 > | > > > |<-------------------------|<---------------------------| > > | EAPoL Packet | CAPWAP Packet > | > > | | | > | > > | | | > +-----------------------+ > > | | \|- EAPoL Frame > | > > Receive | > +-----------------------+ > > GTK | > | > > | | > | > > | | > | > > | Message-4 > | > > > |------------------------->|--------------------------->| > > | EAPoL Packet | CAPWAP Packet > | > > | | > | > > > > > > > > > > Case specified by RFC 4564: > > > > The 802.11i Considerations requirement considers the > case where 802.11i > > authentication is at AC and 802.11i crypto is at WTP. > So now, the WTP > > maintains the KeyRSC while the AC requires this > information to generate > > the EAPoL frame for Message-3 of the 4-way handshake. > > > > The diagram below shows this; > > > > - 802.11i Crypto > > (KeyRSC maintained here) - 802.11i > Authentication > > > > +----------+ +-----+ > +------+ > > | Terminal | | WTP | | > AC | > > +----------+ +-----+ > +------+ > > | | > | > > | 802.1x Authentication > | > > > |<=====================================================>| > > | | > | > > PMK | > PMK > > | | > | > > Generate | > Generate > > SNonce | > ANonce > > | | > | > > > > > > In this case, the EAPoL frame generated by the AC will > not be based on > > the prevailing value of the KeyRSC, as this counter is > maintained by > > the WTP. > > > > This problem is currently not solved in the CAPWAP > specifications. > > > > > > Proposal: > > > > The proposal is to include a CAPWAP Key Configuration > message that can > > transport the EAPoL frame between AC and WTP before > being sent to the > > client (terminal). > > > > Key Configuration is a control message sent by the AC > to the WTP. The > > message contains Message-3 of the 4-way handshake - > including the > > EAPoL-frame. However, the EAPoL frame has its KeyMIC > field unassigned as > > the AC cannot accurately calculate this. > > > > So on receiving the Key Configuration - containing > EAPoL frame with > > unassigned KeyMIC field, the WTP retrieves the value of > the KeyRSC it > > maintains and computes the corresponding KeyMIC. > > > > The EAPoL frame is then updated and Message-3 of the > 4-way handshake is > > reconstructed before being sent over the wireless link > to the client. > > > > > > The diagram below illustrates this; > > > > > > - 802.11i Crypto > > (KeyRSC maintained here) - 802.11i > Authentication > > > > +----------+ +-----+ > +------+ > > | Terminal | | WTP | | > AC | > > +----------+ +-----+ > +------+ > > | | > | > > | 802.1x Authentication > | > > > |<=====================================================>| > > | | > | > > PMK | > PMK > > | | > | > > Generate | > Generate > > SNonce | > ANonce > > | | > | > > | | > | > > | Message 1 > | > > > |<-------------------------|<---------------------------| > > | EAPoL Packet | CAPWAP Packet > | > > Receive | > | > > ANonce | > | > > Generate | > | > > PTK | > | > > | | > | > > | Message 2 > | > > > |------------------------->|--------------------------->| > > | EAPoL Packet | CAPWAP Packet > | > > | | > Receive > > | | > SNonce > > | | > | > > | | > Generate > > | | > PTK > > | | > GTK > > | | Message 3 > | > > | > |<===========================| > > | | CAPWAP Packet > | > > | | (Key Configuration) > | > > | | | > +-----------------------+ > > | | \|- GTK-Flag > | > > | -Retrieve KeyRSC |- > Encryption-Data(PTK) | > > | -Update KeyMIC |- > Encryption-Data(GTK) | > > | -Reconstruct |- EAP-Frame > | > > | Message-3 > +-----------------------+ > > | | > | > > |<-------------------------| > | > > | EAPoL Packet | > | > > Receive | > | > > GTK | > | > > | Message 4 > | > > > |------------------------->|--------------------------->| > > | EAPoL Packet | CAPWAP Packet > | > > | | > | > > > > > > > > This proposal very simply solves the problem while > directly addressing > > the requirement for IEEE 802.11i Considerations. > > > > > > Cheers, > > > > Saravanan > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > _________________________________________________________________ > Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > _________________________________________________________________ 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 Sep 15 14:16:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIEu-0005Gy-AX for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:16:36 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOIEs-0002e1-Rs for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:16:36 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id EB4603980C3 for ; Fri, 15 Sep 2006 11:16:31 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 12D31430094 for ; Fri, 15 Sep 2006 11:15:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CC082144804C for ; Fri, 15 Sep 2006 11:15:53 -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 A8CE21448029 for ; Fri, 15 Sep 2006 11:15:51 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 15 Sep 2006 11:15:49 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8FIFnCN024586; Fri, 15 Sep 2006 11:15:49 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8FIFmQV005157; Fri, 15 Sep 2006 11:15:48 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Sep 2006 11:15:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 11:15:47 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A3325@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] WTP and AC version number? Thread-Index: AcbVaaEqh3KN8Q36SAe2O4iY7vBcewDiOuyw From: "Pat Calhoun (pacalhou)" To: "Peter Nilsson J (LI/EAB)" , X-OriginalArrivalTime: 15 Sep 2006 18:15:48.0244 (UTC) FILETIME=[F814DD40:01C6D8F2] 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-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] WTP and AC version number? X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: c1c65599517f9ac32519d043c37c5336 Correct, Peter. This is broken. There is already an issue to fix this. Issue 126. We do need proposed text. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Peter Nilsson J (LI/EAB) [mailto:peter.j.nilsson@ericsson.com] Sent: Sunday, September 10, 2006 11:15 PM To: Capwap@frascone.com Subject: [Capwap] WTP and AC version number? I was reading the about the state transistions chapter 2.3.1 in draft -02. In transintion (g) "Join to Configure" and (i) "Configure to Image Data" it is said that the WTP determines that its version number is same or different than the version number advertised by the AC. First of all I assume that the version number meant here is the software or firmware version. What is not clear to me is how the WTP get to know the version number advertised by the AC. The only software version I have seen that the AC sends to the WTP is the AC's Software version in AC Descriptor message element sent in the Discovery Response. But the AC's own software version would not be much help to determine if the WTP needs to update its firmware or not. Can some one explain how this is meant to work? Peter Nilsson Ericsson AB _________________________________________________________________ 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 Sep 15 14:32:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIU1-0002JT-Vq for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:32:13 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOISj-0005sV-Vi for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:30:55 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8A3D439804D for ; Fri, 15 Sep 2006 11:30:53 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B3667430094 for ; Fri, 15 Sep 2006 11:29:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A6F5039824A for ; Fri, 15 Sep 2006 11:29:58 -0700 (PDT) Received: from mgw-ext14.nokia.com (mgw-ext14.nokia.com [131.228.20.173]) by zoidberg.tigertech.net (Postfix) with ESMTP id 859CD398095 for ; Fri, 15 Sep 2006 11:19:02 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k8FIIxn1014694; Fri, 15 Sep 2006 21:18:59 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 21:18:59 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 13:18:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 11:18:55 -0700 Message-ID: <893AE265F4ADF94AB7FB26D31A788E41029E0CCC@mvebe101.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus call on Split CAPWAP draft by 9/29. Thread-Index: AcbY82fx0AwmEjxkSO+bTrWL20FI8g== From: To: X-OriginalArrivalTime: 15 Sep 2006 18:18:56.0172 (UTC) FILETIME=[681866C0:01C6D8F3] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.265 tagged_above=-999 required=7 tests=HTML_40_50, HTML_MESSAGE, NO_REAL_NAME X-Spam-Level: Cc: margaret@thingmagic.com, Dorothy.Gellert@nokia.com Subject: [Capwap] Consensus call on Split CAPWAP draft by 9/29. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0017337569==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db This is a multi-part message in MIME format. --===============0017337569== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D8F3.6837C5F3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D8F3.6837C5F3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, The editors feel that there is WG support to split the current CAPWAP protocol draft into 2 drafts, a base draft and then a 802.11 binding draft. The chairs would like to verify consensus with the WG that there is sufficient interest to split the draft before making this change. This issue has been discussed at the last CAPWAP WG meeting during IETF 66 in Montreal where there was no opposition to this request, and limited support on the list. =20 The chairs would like establish consensus on the issue of splitting binding specific details from the base CAPWAP specification.=20 Please submit your opinions on this topic to the WG list by Sept 29th, for a final consensus call on this feature. Best Regards, Dorothy, Mani and Margaret ------_=_NextPart_001_01C6D8F3.6837C5F3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Consensus call on Split CAPWAP draft by 9/29.

Hi All,

The editors feel that there is WG = support to split the current CAPWAP protocol draft into 2 drafts, a base = draft and then a 802.11 binding draft.  The chairs would like to = verify consensus with the WG that there is sufficient interest to split = the draft before making this change.

This issue has been discussed at = the last CAPWAP WG meeting during IETF 66 in Montreal where there was no = opposition to this request, and limited support on the list.  =

The chairs would like establish = consensus on the issue of splitting binding specific details from the = base CAPWAP specification.

Please submit your opinions on = this topic to the WG list by Sept 29th, for a final consensus call on = this feature.

Best Regards,
Dorothy, Mani and = Margaret

------_=_NextPart_001_01C6D8F3.6837C5F3-- --===============0017337569== 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 --===============0017337569==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 15 14:32:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIU2-0002Jr-Ll for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:32:14 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOISQ-0005o0-VP for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:30:36 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9F6C5398041 for ; Fri, 15 Sep 2006 11:30:32 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D3A04430094 for ; Fri, 15 Sep 2006 11:29:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C35A11448035 for ; Fri, 15 Sep 2006 11:29:28 -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 E32A41448022 for ; Fri, 15 Sep 2006 11:29:27 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 15 Sep 2006 11:29:27 -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 k8FITRss007786 for ; Fri, 15 Sep 2006 11:29:27 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8FITR1E020114 for ; Fri, 15 Sep 2006 11:29:27 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Sep 2006 11:29:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 11:29:26 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A333F@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 158: Many of the configuration items, and status items are not listed in Thread-Index: AcbNRly52KBpf/caSRyGFZwI0bPsRQLrm/bA From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 15 Sep 2006 18:29:27.0499 (UTC) FILETIME=[E06541B0:01C6D8F4] Authentication-Results: sj-dkim-3.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] Issue 158: Many of the configuration items, and status items are not listed in X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 926f893f9bbbfa169f045f85f0cdb955 Given the lack of responses, I will assume the proposed text is acceptable and will close this issue. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, August 31, 2006 2:43 PM > To: capwap@frascone.com > Subject: [Capwap] Issue 158: Many of the configuration > items,and status items are not listed in > > All, > > The issue states: > 9) Many of the configuration items, and status items are > not listed in > one section with definitions. (Well make it two sections - one for > CAPWAP and the other which is "binding" specific.) For > example, not all > of the time period lengths are identified and specified in > section 4.5. > > The issue is really discussing the fact that many message > elements include variables for which the protocol does not > provide default values. There were also mentions in the spec > of information that the WTP needs to save, which was also not > clear. I've created new sections to discuss this topic (well, > the first section already existed, but includes new items). > I've made several additional changes to the spec, but mostly > in adding references to these new sections. > > > Comments welcomed! > > 4.6. CAPWAP Protocol Variables <== EXISTING SECTION. New Items > > A WTP or AC that implements CAPWAP discovery MUST allow for the > following variables to be configured by system management; default > values are specified so as to make it unnecessary to > configure any of > these variables in many cases. Note that the default values MAY be > explicitely overriden by the AC by sending them via a message > element. The WTP is expected to save the overriden values sent by > the WTP. > > 4.6.1. AdminState > > The default Administrative State value is enabled (1). > > [...] > > 4.6.3. IdleTimeout > > The default Idle Timeout is 300 seconds (5 minutes). > > [...] > > 4.6.6. ReportInterval > > The default Report Interval is 120 seconds (2 minutes). > > [...] > > 4.6.8. StatisticsTimer > > The default Statistics Interval is 120 seconds (2 minutes). > > 4.6.9. WTPFallBack > > The default WTP Fallback value is enabled (1). > > 4.7. WTP Saved Variables <== NEW SECTIONS > > Certain values SHOULD be saved on the WTP. In addition to > the values > defined in section , the following values SHOULD be saved on the > WTP's permanent storage. Note that CAPWAP wireless bindings may > define additional values to store on the WTP. > > 4.7.1. AdminRebootCount > > The number of times the WTP has rebooted administratively, as > expressed in section Section 4.4.43. > > 4.7.2. FrameEncapType > > For WTPs that support multiple Frame Encapsulation Types, it is > necessary to save the value configured by the AC. The Frame > Encapsulation Type is expressed in section Section 4.4.38. > > 4.7.3. LastRebootReason > > The reason why the WTP last rebooted, as expressed in section > Section 4.4.43. > > 4.7.4. MacType > > For WTPs that support multiple MAC Types, it is necessary > to save the > value configured by the AC. The MAC Type is expressed in section > Section 4.4.40. > > 4.7.5. PreferredACs > > The preferred ACs, with the index, as expressed in section > Section 4.4.5. > > 4.7.6. RebootCount > > The number of times the WTP has rebooted, as expressed in section > Section 4.4.43. > > 4.7.7. Static ACL Table > > The static ACL table saved on the WTP , as configured by > the message > element described in section Section 4.4.9. > > 4.7.8. Static IP Address > > The static IP Address assigned to the WTP , as configured by the > message element described in section Section 4.4.44. > > 4.7.9. WTPLinkFailureCount > > The number of times the link to the AC has failed, as expressed in > section Section 4.4.43. > > 4.7.10. WTPLocation > > The WTP Location, as expressed in section Section 4.4.27. > > 4.7.11. WTPName > > The WTP Name, as expressed in section Section 4.4.42. > > [...] > > 11.11. WTP IEEE 802.11 Binding Saved Variables <== NEW SECTION > > This section contains the IEEE 802.11 binding specific > variables that > SHOULD be saved on the WTP. > > 11.11.1. IEEE80211AntennaInfo > > The WTP's per radio antenna configuration details as expressed in > section Section 11.10.2. > > 11.11.2. IEEE80211DSControl > > The WTP's per radio Direct Sequence Control configuration > details as > expressed in section Section 11.10.5. > > 11.11.3. IEEE80211MACOperation > > The WTP's per radio MAC Operation configuration details as > expressed > in section Section 11.10.7. > > 11.11.4. IEEE80211OFDMControl > > The WTP's per radio MAC Operation configuration details as > expressed > in section Section 11.10.10. > > 11.11.5. IEEE80211Rateset > > The WTP's per radio Basic Rate Set configuration details > expressed in > section Section 11.10.11. > > 11.11.6. IEEE80211TxPower > > The WTP's per radio Transmit Power configuration details > expressed in > section Section 11.10.17. > > 11.11.7. IEEE80211QoS > > The WTP's per radio Quality of Service configuration details > expressed in section Section 11.10.21. > > 11.11.8. IEEE80211RadioConfig > > The WTP's per radio Radio Configuration details expressed > in section > Section 11.10.23. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > 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 Sep 15 14:32:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIU5-0002NT-Sr for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:32:18 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOIQn-0005Sw-Ek for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:28:54 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 17BC8398246 for ; Fri, 15 Sep 2006 11:28:53 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9FDCF430094 for ; Fri, 15 Sep 2006 11:28:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8D1F71448023 for ; Fri, 15 Sep 2006 11:28:13 -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 B9AFE1448035 for ; Fri, 15 Sep 2006 11:28:11 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 15 Sep 2006 11:28:11 -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 k8FISBq0009600 for ; Fri, 15 Sep 2006 11:28:11 -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 k8FISB1E019071 for ; Fri, 15 Sep 2006 11:28:11 -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); Fri, 15 Sep 2006 11:28:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 11:28:10 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A333D@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 176: The WTP Static IPv4 Address should not have theStatic bit Thread-Index: AcbNCAurxbIDp/HBSyKOkw/ZKNC3EwL7I9iA From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 15 Sep 2006 18:28:11.0314 (UTC) FILETIME=[B2FC5920:01C6D8F4] 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-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] Issue 176: The WTP Static IPv4 Address should not have theStatic bit X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: e1e48a527f609d1be2bc8d8a70eb76cb Given the lack of responses, I will assume there is no interest in fixing this issue and will reject this issue. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, August 31, 2006 7:16 AM > To: capwap@frascone.com > Subject: [Capwap] Issue 176: The WTP Static IPv4 Address > should not have theStatic bit > > 28) The WTP Static IPv4 Address should not have the Static > bit, but instead state that 0.0.0.0 means a static address is > not to be used. > > Same comment as previous. I would like to solicit from > the WG on whether addressing this comment would really change > the quality of the specification. If it's a change for the > sake of changing, I would prefer to reject the comment. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > 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 Sep 15 14:32:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIU7-0002Nw-JO for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:32:19 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOIPc-0004tc-8J for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:27:41 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id DCD9A398191 for ; Fri, 15 Sep 2006 11:27:39 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EEF59430094 for ; Fri, 15 Sep 2006 11:26:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DEE6C1448023 for ; Fri, 15 Sep 2006 11:26:52 -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 D717C1448035 for ; Fri, 15 Sep 2006 11:26:51 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 15 Sep 2006 11:26:51 -0700 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.20060308/8.12.11) with ESMTP id k8FIQpPV021091 for ; Fri, 15 Sep 2006 11:26:51 -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 k8FIQp1E017984 for ; Fri, 15 Sep 2006 11:26:51 -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); Fri, 15 Sep 2006 11:26:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 11:26:50 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A333B@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 184: Should Idle Timeout be per radio, or per WTP, and should the value Thread-Index: AcbNB626laXwPNCWQhGIRabqVcPwmQL7MNVg From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 15 Sep 2006 18:26:51.0154 (UTC) FILETIME=[8334E720:01C6D8F4] 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] Issue 184: Should Idle Timeout be per radio, or per WTP, and should the value X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Given the lack of responses, I will assume the proposed text is acceptable and will close this issue. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, August 31, 2006 7:14 AM > To: capwap@frascone.com > Subject: [Capwap] Issue 184: Should Idle Timeout be per > radio, or per WTP,and should the value > > 35) Should Idle Timeout be per radio, or per WTP, and should > the value be defined in section 4.5 or 11. > > Per WTP. > > Here is the proposed text: > > 4.4.21. Idle Timeout > > The Idle Timeout message element is sent by the AC to the WTP to > provide it with the idle timeout that it should enforce on > its active > STA entries. The value applies for all radios on the WTP. > The default > value for this message element can be found in Section 4.7 [...] > > 4.7. CAPWAP Message Element Default Values > > The WTP and AC MUST support the following default values. These > values may be overriden via explicit notification within a message > element. > > 4.7.1. IdleTimeout > > The default Idle Timeout is 18000 seconds (5 minutes). > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > 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 Sep 15 14:32:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIU9-0002Qg-DQ for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:32:21 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOIOM-0004fw-0p for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:26:24 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id A6A0B398208 for ; Fri, 15 Sep 2006 11:26:21 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C7340430094 for ; Fri, 15 Sep 2006 11:25:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B6DD31448023 for ; Fri, 15 Sep 2006 11:25:45 -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 AF2341448022 for ; Fri, 15 Sep 2006 11:25:43 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 15 Sep 2006 11:25:43 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8FIPhed024038 for ; Fri, 15 Sep 2006 11:25:43 -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 k8FIPhYp027759 for ; Fri, 15 Sep 2006 11:25:43 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Sep 2006 11:25:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 11:25:42 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A3337@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 197: Issues with WLAN config request Thread-Index: AcbNBYmowOcjNzhWQri1t2wpPYNTywL7rdNw From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 15 Sep 2006 18:25:42.0705 (UTC) FILETIME=[5A686A10:01C6D8F4] 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: Subject: Re: [Capwap] Issue 197: Issues with WLAN config request X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 4d87d2aa806f79fed918a62e834505ca Given the lack of responses, I will assume there is no interest in fixing this issue and will reject this issue. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, August 31, 2006 6:58 AM > To: capwap@frascone.com > Subject: [Capwap] Issue 197: Issues with WLAN config request > > 62) IEEE 802.11 WLAN Config Request. why is a new message type that is > 802.11 specific needed to modify 802.11 WLANs? It seems like > the existing "(8.4)Configuration Update Request" message > could be used. > > The reason for the WLAN Config Request was in order to > be more specific on the type of request. Would folks prefer > to see this message removed, in lieu of the Configuration > Update Request, and is this a change that MUST be made vs. > COULD be made? Does it increase the quality of the protocol? > > > 63) note here there are information elements to create, > delete, and modify WLANs. However, for message type > "(10.1)Mobile Config Request", there is only add and delete > (and the "add" used to modify). > > Correct. The protocol requires the AC to resend a new > add with a different policy. No specific reason, but before > we change it, I'd like to ask the same question as above. Is > this a necessary change to increase the quality of the protocol? > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > 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 Sep 15 14:32:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIUf-0002kO-MC for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:32:53 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOIUe-0006Vo-76 for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:32:53 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 986DA3982A7 for ; Fri, 15 Sep 2006 11:32:51 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 76B62430094 for ; Fri, 15 Sep 2006 11:32:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6B1613981B9 for ; Fri, 15 Sep 2006 11:32:09 -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 15D12398139 for ; Fri, 15 Sep 2006 11:20:20 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 15 Sep 2006 11:20:20 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8FIKJ4s016295 for ; Fri, 15 Sep 2006 11:20:19 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8FIKJQV008986 for ; Fri, 15 Sep 2006 11:20:19 -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); Fri, 15 Sep 2006 11:20:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 11:20:18 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A332D@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 209: Dealing with Reserved Bits Thread-Index: AcbNAr1wZmwmIMKzR3uY3qSBf9X9yQL8LO8g From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 15 Sep 2006 18:20:19.0331 (UTC) FILETIME=[99A97530:01C6D8F3] 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 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] Issue 209: Dealing with Reserved Bits X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: cab78e1e39c4b328567edb48482b6a69 Given the lack of responses, I will assume the proposed text is acceptable and will close this issue. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, August 31, 2006 6:39 AM > To: capwap@frascone.com > Subject: [Capwap] Issue 209: Dealing with Reserved Bits > > Here is the proposed new text: > > 4.1. CAPWAP Transport Header > [...] > Flags: A set of reserved bits for future flags in the > CAPWAP header. > All implementations complying with version zero of this protocol > MUST set these bits to zero. Receivers MUST ignore all bits not > defined for the version of the protocol they support [...] > Reserved: The 3-bit Reserved field is reserved and set to > 0 in this > version of the CAPWAP protocol. Receivers MUST ignore all bits > not defined for the version of the protocol they support > > Comments? > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > 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 Sep 15 14:35:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIX9-0003Vl-4i for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:35:27 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOIX6-0007Ji-LW for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:35:27 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 495703982A6 for ; Fri, 15 Sep 2006 11:35:24 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D8B69430094 for ; Fri, 15 Sep 2006 11:34:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id BF4C03981C1 for ; Fri, 15 Sep 2006 11:34:51 -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 A05F63980C1 for ; Fri, 15 Sep 2006 11:22:30 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 15 Sep 2006 11:22:30 -0700 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.20060308/8.12.11) with ESMTP id k8FIMUBh015107 for ; Fri, 15 Sep 2006 11:22:30 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8FIMU1E014351 for ; Fri, 15 Sep 2006 11:22:30 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Sep 2006 11:22:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 11:22:28 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A3332@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 215: Consistency in capwap header references Thread-Index: AcbY8+brAqiY9VgzQ/qu2+68py3g8Q== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 15 Sep 2006 18:22:29.0848 (UTC) FILETIME=[E774C580:01C6D8F3] 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 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: [Capwap] Issue 215: Consistency in capwap header references X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Given the lack of responses on a simple change to ensure consistency in the references to the capwap header, I will accept the proposed text and will mark the issue as closed. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ 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 Sep 15 14:36:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIYP-0003qY-Ip for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:36:45 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOIYO-0007RJ-3S for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:36:45 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id A9F23398118 for ; Fri, 15 Sep 2006 11:36:43 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 12B1C430094 for ; Fri, 15 Sep 2006 11:35:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 06F88398086 for ; Fri, 15 Sep 2006 11:35:57 -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 14CF9398053 for ; Fri, 15 Sep 2006 11:24:01 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 15 Sep 2006 11:23:50 -0700 X-IronPort-AV: i="4.09,171,1157353200"; d="scan'208"; a="341644732:sNHT3445653748" 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 k8FINngW016837; Fri, 15 Sep 2006 11:23:49 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8FINnQV012076; Fri, 15 Sep 2006 11:23:49 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Sep 2006 11:23:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 11:23:47 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A3334@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 208: Dealing with Reserved Bits Thread-Index: AcbNAr1wZmwmIMKzR3uY3qSBf9X9yQAPogmwAACi1RAC7A4ggA== From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , "Nelson, David" , X-OriginalArrivalTime: 15 Sep 2006 18:23:48.0847 (UTC) FILETIME=[168B0FF0:01C6D8F4] 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 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] Issue 208: Dealing with Reserved Bits X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 25620135586de10c627e3628c432b04a Given the lack of responses, I will assume the modified proposed text is acceptable and will close this issue. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, August 31, 2006 2:24 PM > To: Nelson, David; capwap@frascone.com > Subject: Re: [Capwap] Issue 209: Dealing with Reserved Bits > > I'm ok with this as well. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Nelson, David [mailto:dnelson@enterasys.com] > > Sent: Thursday, August 31, 2006 2:17 PM > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > Subject: RE: [Capwap] Issue 209: Dealing with Reserved Bits > > > > For the sake of symmetry, may I suggest a different revision to the > > text: > > > > OLD (Pat C. as of 8/31/06): > > > > 4.1. CAPWAP Transport Header > > [...] > > Flags: A set of reserved bits for future flags in the CAPWAP > > header. > > All implementations complying with version zero of > this protocol > > MUST set these bits to zero. Receivers MUST ignore > all bits not > > defined for the version of the protocol they support [...] > > > > NEW: > > > > 4.1. CAPWAP Transport Header > > [...] > > Flags: A set of reserved bits for future flags in the CAPWAP > > header. > > All implementations complying with this protocol MUST set to > > zero > > any bits that are reserved in the version of the protocol > > supported > > by that implementation. Receivers MUST ignore all bits not > > defined > > for the version of the protocol they support [...] > > > > This places a symmetric requirement on senders to zero, and > receivers > > to ignore, any bits that are still reserved in the version of the > > protocol supported in that implementation. > > > _________________________________________________________________ > 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 Sep 15 14:38:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIZx-000492-7g for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:38:21 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOIZv-0007Xs-PC for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:38:21 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6139E3982C4 for ; Fri, 15 Sep 2006 11:38:19 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id CF63A430094 for ; Fri, 15 Sep 2006 11:37:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 867751448050 for ; Fri, 15 Sep 2006 11:37:34 -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 F422A1448039 for ; Fri, 15 Sep 2006 11:37:31 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 15 Sep 2006 11:37:31 -0700 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 k8FIbVU0017838 for ; Fri, 15 Sep 2006 11:37:31 -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 k8FIbVYr007249 for ; Fri, 15 Sep 2006 11:37:31 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Sep 2006 11:37:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 11:37:30 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A3350@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 178: WTP Radio Configuration message element's BSSIDshould be an array Thread-Index: AcbNTH+bnTazrY+DQ0C9F0OyziMVcALqXkwg From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 15 Sep 2006 18:37:31.0180 (UTC) FILETIME=[00B11EC0:01C6D8F6] Authentication-Results: sj-dkim-3.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] Issue 178: WTP Radio Configuration message element's BSSIDshould be an array X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: a7d6aff76b15f3f56fcb94490e1052e4 Given the lack of responses, I will assume there is no interest in fixing this issue and will reject this issue. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, August 31, 2006 3:26 PM > To: capwap@frascone.com > Subject: [Capwap] Issue 178: WTP Radio Configuration message > element's BSSIDshould be an array > > The IEEE 802.11 WTP Radio Configuration message element's > BSSID field should be an array. > > We've gone down this path a few times, and I still > disagree. When manufacturing WTPs, one uses a contiguous > block of MAC Addresses. There is no point in making this > change, as it is consistent with current manufacturing processes. > > Propose rejecting unless I hear otherwise. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > 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 Sep 15 14:39:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIb5-0005BI-8B for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:39:31 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOIb3-0007g3-Px for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:39:31 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5C44039819D for ; Fri, 15 Sep 2006 11:39:29 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id BDC0D430094 for ; Fri, 15 Sep 2006 11:38:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DF2A11448018 for ; Fri, 15 Sep 2006 11:38:47 -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 F0B571448047 for ; Fri, 15 Sep 2006 11:38:42 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-1.cisco.com with ESMTP; 15 Sep 2006 11:38:42 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8FIcgOT022242 for ; Fri, 15 Sep 2006 11:38:42 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k8FIcfw7021666 for ; Fri, 15 Sep 2006 11:38:42 -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, 15 Sep 2006 11:38:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 11:38:41 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A3352@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 171: AC IPv4/IPv6 Addr discusses clustering, which is unnecessary. Thread-Index: AcbNTSEMfy9zKlSWRnyZuM5uzHLxnwLqPNWQ From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 15 Sep 2006 18:38:41.0646 (UTC) FILETIME=[2AB160E0:01C6D8F6] Authentication-Results: sj-dkim-5.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] Issue 171: AC IPv4/IPv6 Addr discusses clustering, which is unnecessary. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: e1e48a527f609d1be2bc8d8a70eb76cb Given the lack of responses, I will assume the proposed text is acceptable and will close this issue. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, August 31, 2006 3:31 PM > To: capwap@frascone.com > Subject: [Capwap] Issue 171: AC IPv4/IPv6 Addr discusses > clustering,which is unnecessary. > > 23) AC IPv4/IPv6 Addr discusses clustering, which is unnecessary. > > I agree. I have changed the text to now read: > > The AC IPv4 List message element is used to configure a > WTP with the > latest list of ACs available for the WTP to join. > > Comments? > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > 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 Sep 15 14:45:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIh7-0000EU-MK for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:45:45 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOIh6-0000Fo-6q for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:45:45 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id BA1F6398218 for ; Fri, 15 Sep 2006 11:45:43 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 8D0EF430094 for ; Fri, 15 Sep 2006 11:44:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7A30239826F for ; Fri, 15 Sep 2006 11:44:25 -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 CB1C53981B8 for ; Fri, 15 Sep 2006 11:32:07 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 15 Sep 2006 11:32:08 -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.20060308/8.12.11) with ESMTP id k8FIW7hP014990 for ; Fri, 15 Sep 2006 11:32:07 -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 k8FIW7Yp003467 for ; Fri, 15 Sep 2006 11:32:07 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Sep 2006 11:32:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 11:32:06 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A3346@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 162: The WTP Descriptor message element contains toomuch information Thread-Index: AcbNS88x8pW7z8lpRwKGPyy9mBM0VgLqTF0Q From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 15 Sep 2006 18:32:06.0841 (UTC) FILETIME=[3F5EEA90:01C6D8F5] 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: Subject: Re: [Capwap] Issue 162: The WTP Descriptor message element contains toomuch information X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 8b431ad66d60be2d47c7bfeb879db82c Given the lack of interest in this issue, my proposal of rejecting points 1 and 2 (due to lack of data), and accepting point 3 stands. I will mark the issue tracker accordingly. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, August 31, 2006 3:22 PM > To: capwap@frascone.com > Subject: [Capwap] Issue 162: The WTP Descriptor message > element contains toomuch information > > 13) The WTP Descriptor message element contains too much > information, lacks clarity on the WTP encryption field and > includes version numbers, which should be in string form. > > There are three points raised here: > 1. Too much information. I disagree. I think there is value > in knowing everything about the WTP. The AC vendors can > expose whatever information they want, but I don't believe > anything is unnecessary. > > 2. WTP Encryption lacks clarity. Well, I would need more > information on what you feel is not sufficiently defined, but > I would first like to address issue 138, which really > discusses whether this is required or not since we have > another mechanism to encrypt the data plane. > > 3. To the last point, I have made a change to require that > the data be encoded in the UTF-8 format. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > 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 Sep 15 14:45:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIhA-0000Fe-E0 for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:45:48 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOIh8-0000Ft-FD for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:45:48 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id B11093982CD for ; Fri, 15 Sep 2006 11:45:45 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3BEE4430094 for ; Fri, 15 Sep 2006 11:44:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 28BDA1448018 for ; Fri, 15 Sep 2006 11:44:01 -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 2D294144804C for ; Fri, 15 Sep 2006 11:43:57 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 15 Sep 2006 11:43:56 -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 k8FIhunA024063; Fri, 15 Sep 2006 11:43:56 -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 k8FIhu1E000782; Fri, 15 Sep 2006 11:43:56 -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); Fri, 15 Sep 2006 11:43:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 11:43:55 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A335B@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbY4CMB7agq4TySSwi0SsMRMuBTQgADSCsAAAJiyNA= From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , "Saravanan Govindan" , X-OriginalArrivalTime: 15 Sep 2006 18:43:56.0621 (UTC) FILETIME=[E66EBFD0:01C6D8F6] Authentication-Results: sj-dkim-3.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] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 8949cc4fd406a34204d26327803246d1 As an aside, issue 43 was closed. Issue 199 was opened some time ago and was being used to track this issue. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Friday, September 15, 2006 10:36 AM > To: Saravanan Govindan; capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > The "protocol" performs the function of 802.1X/802.11i > without any issues in both the SplitMAC and LocalMAC operation. > > Are you stating this is required because RFC4564 states that > flexibility is required, or because there is an actual need > for this feature? > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Saravanan Govindan [mailto:saravanang@hotmail.com] > > Sent: Friday, September 15, 2006 9:00 AM > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > I want to emphasize that this is not an "additional" feature > > - it is a mandatory requirement from RFC 4564. The protocol > currently > > does not meet the requirement. > > > > Saravanan > > > > > > > > ----Original Message Follows---- > > From: "Pat Calhoun (pacalhou)" > > To: "Saravanan Govindan" > > , > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > Date: Fri, 15 Sep 2006 08:01:32 -0700 > > > > I understand the proposal, but stand firm on my belief that this > > additional mode of operation is unnecessary. While it is > possible to > > implement, as everything is in a protocol, I believe the WG > needs to > > focus on fixing the protocol in the areas where it is broken, as > > opposed to adding more optional modes that really do not change the > > outcome of the functions. > > > > Perhaps what would be more useful is not to describe the > method, but > > the reason why this is being proposed. I still fail to > understand why > > you believe this mode of operation is necessary. > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > > ________________________________ > > > > From: Saravanan Govindan > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > Sent: Friday, September 15, 2006 2:03 AM > > To: capwap@frascone.com > > Subject: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > > > > > All, > > > > > > I wanted to give a more detailed explanation for the > > IEEE 802.11i Considerations requirement. This note describes > > how CAPWAP can be updated to satisfy this requirement > > > > > > > > I would like to use this to highlight the proposal > > being put forward. > > > > > > > > > > > > > > > > From RFC 4564, Section 5.1.10 IEEE 802.11i Considerations > > > > > > > > Protocol Requirement: > > > > > > > > The CAPWAP protocol MUST determine the exact structure of the > > > > centralized WLAN architecture in which > > authentication needs to be > > > > supported, i.e., the location of major > > authentication components. > > > > This may be achieved during WTP initialization where major > > > > capabilities are distinguished. > > > > > > > > The protocol MUST allow for the exchange of key > > information when > > > > authenticator and encryption roles are located in > > distinct entities. > > > > > > > > > > > > Following the requirement, CAPWAP needs; > > > > > > > > 1. to incorporate authentication & encryption locations in > > > > capabilities exchange > > > > > > > > 2. to exchange key information when authentication and crypt are > > > > located in different network entities > > > > > > > > > > > > Basic case: > > > > > > > > AC does both IEEE 802.11i authentication and > > cryptography. For 4-way > > > > exchange, AC tracks the KeyRSC, which it then uses for > > Message-3, > > > > i.e., AC calculates KeyMIC and updates EAPoL frame. > > > > > > > > > > > > - > > 802.11i Authentication > > > > - > > 802.11i Crypto > > > > > > (KeyRSC maintained here) > > > > > > > > +----------+ +-----+ > > +------+ > > > > | Terminal | | WTP | | > > AC | > > > > +----------+ +-----+ > > +------+ > > > > | | > > | > > > > | 802.1x Authentication > > | > > > > > > |<=====================================================>| > > > > | | > > | > > > > PMK | > > PMK > > > > | | > > | > > > > Generate | > > Generate > > > > SNonce | > > ANonce > > > > | | > > | > > > > | | > > | > > > > | Message-1 > > | > > > > > > |<-------------------------|<---------------------------| > > > > | EAPoL Packet | CAPWAP Packet > > | > > > > Receive | > > | > > > > ANonce | > > | > > > > Generate | > > | > > > > PTK | > > | > > > > | | > > | > > > > | Message-2 > > | > > > > > > |------------------------->|--------------------------->| > > > > | EAPoL Packet | CAPWAP Packet > > | > > > > | | > > Receive > > > > | | > > SNonce > > > > | | > > | > > > > | | > > Generate > > > > | | > > PTK > > > > | | > > GTK > > > > | Message-3 > > | > > > > > > |<-------------------------|<---------------------------| > > > > | EAPoL Packet | CAPWAP Packet > > | > > > > | | | > > | > > > > | | | > > +-----------------------+ > > > > | | \|- EAPoL Frame > > | > > > > Receive | > > +-----------------------+ > > > > GTK | > > | > > > > | | > > | > > > > | | > > | > > > > | Message-4 > > | > > > > > > |------------------------->|--------------------------->| > > > > | EAPoL Packet | CAPWAP Packet > > | > > > > | | > > | > > > > > > > > > > > > > > > > > > > > Case specified by RFC 4564: > > > > > > > > The 802.11i Considerations requirement considers the > > case where 802.11i > > > > authentication is at AC and 802.11i crypto is at WTP. > > So now, the WTP > > > > maintains the KeyRSC while the AC requires this > > information to generate > > > > the EAPoL frame for Message-3 of the 4-way handshake. > > > > > > > > The diagram below shows this; > > > > > > > > - 802.11i Crypto > > > > (KeyRSC maintained here) - 802.11i > > Authentication > > > > > > > > +----------+ +-----+ > > +------+ > > > > | Terminal | | WTP | | > > AC | > > > > +----------+ +-----+ > > +------+ > > > > | | > > | > > > > | 802.1x Authentication > > | > > > > > > |<=====================================================>| > > > > | | > > | > > > > PMK | > > PMK > > > > | | > > | > > > > Generate | > > Generate > > > > SNonce | > > ANonce > > > > | | > > | > > > > > > > > > > > > In this case, the EAPoL frame generated by the AC will > > not be based on > > > > the prevailing value of the KeyRSC, as this counter is > > maintained by > > > > the WTP. > > > > > > > > This problem is currently not solved in the CAPWAP > > specifications. > > > > > > > > > > > > Proposal: > > > > > > > > The proposal is to include a CAPWAP Key Configuration > > message that can > > > > transport the EAPoL frame between AC and WTP before > > being sent to the > > > > client (terminal). > > > > > > > > Key Configuration is a control message sent by the AC > > to the WTP. The > > > > message contains Message-3 of the 4-way handshake - > > including the > > > > EAPoL-frame. However, the EAPoL frame has its KeyMIC > > field unassigned as > > > > the AC cannot accurately calculate this. > > > > > > > > So on receiving the Key Configuration - containing > > EAPoL frame with > > > > unassigned KeyMIC field, the WTP retrieves the value of > > the KeyRSC it > > > > maintains and computes the corresponding KeyMIC. > > > > > > > > The EAPoL frame is then updated and Message-3 of the > > 4-way handshake is > > > > reconstructed before being sent over the wireless link > > to the client. > > > > > > > > > > > > The diagram below illustrates this; > > > > > > > > > > > > - 802.11i Crypto > > > > (KeyRSC maintained here) - 802.11i > > Authentication > > > > > > > > +----------+ +-----+ > > +------+ > > > > | Terminal | | WTP | | > > AC | > > > > +----------+ +-----+ > > +------+ > > > > | | > > | > > > > | 802.1x Authentication > > | > > > > > > |<=====================================================>| > > > > | | > > | > > > > PMK | > > PMK > > > > | | > > | > > > > Generate | > > Generate > > > > SNonce | > > ANonce > > > > | | > > | > > > > | | > > | > > > > | Message 1 > > | > > > > > > |<-------------------------|<---------------------------| > > > > | EAPoL Packet | CAPWAP Packet > > | > > > > Receive | > > | > > > > ANonce | > > | > > > > Generate | > > | > > > > PTK | > > | > > > > | | > > | > > > > | Message 2 > > | > > > > > > |------------------------->|--------------------------->| > > > > | EAPoL Packet | CAPWAP Packet > > | > > > > | | > > Receive > > > > | | > > SNonce > > > > | | > > | > > > > | | > > Generate > > > > | | > > PTK > > > > | | > > GTK > > > > | | Message 3 > > | > > > > | > > |<===========================| > > > > | | CAPWAP Packet > > | > > > > | | (Key Configuration) > > | > > > > | | | > > +-----------------------+ > > > > | | \|- GTK-Flag > > | > > > > | -Retrieve KeyRSC |- > > Encryption-Data(PTK) | > > > > | -Update KeyMIC |- > > Encryption-Data(GTK) | > > > > | -Reconstruct |- EAP-Frame > > | > > > > | Message-3 > > +-----------------------+ > > > > | | > > | > > > > |<-------------------------| > > | > > > > | EAPoL Packet | > > | > > > > Receive | > > | > > > > GTK | > > | > > > > | Message 4 > > | > > > > > > |------------------------->|--------------------------->| > > > > | EAPoL Packet | CAPWAP Packet > > | > > > > | | > > | > > > > > > > > > > > > > > > > This proposal very simply solves the problem while > > directly addressing > > > > the requirement for IEEE 802.11i Considerations. > > > > > > > > > > > > Cheers, > > > > > > > > Saravanan > > > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > _________________________________________________________________ > > Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > _________________________________________________________________ > 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 Sep 15 14:47:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIiz-000178-FD for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:47:41 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOIiy-0000LC-03 for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:47:41 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 573173981DE for ; Fri, 15 Sep 2006 11:47:39 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 24952430094 for ; Fri, 15 Sep 2006 11:46:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0FDE9398312 for ; Fri, 15 Sep 2006 11:46:43 -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 4D1E739817A for ; Fri, 15 Sep 2006 11:34:17 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 15 Sep 2006 11:34:17 -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 k8FIYHaA030751 for ; Fri, 15 Sep 2006 11:34:17 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8FIYGQV021558 for ; Fri, 15 Sep 2006 11:34:17 -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); Fri, 15 Sep 2006 11:34:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 11:34:16 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A334B@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 179: WTP Radio Configuration message element'sCountry code is not clear Thread-Index: AcbNTDranuK1/vVwRAGX3omkjvRKigLqTRHg From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 15 Sep 2006 18:34:16.0757 (UTC) FILETIME=[8CCE8650:01C6D8F5] 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 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] Issue 179: WTP Radio Configuration message element'sCountry code is not clear X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: a7d6aff76b15f3f56fcb94490e1052e4 Given the lack of responses, I will assume there is no interest in fixing this issue and will reject this issue. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, August 31, 2006 3:25 PM > To: capwap@frascone.com > Subject: [Capwap] Issue 179: WTP Radio Configuration message > element'sCountry code is not clear > > 30) The IEEE 802.11 WTP Radio Configuration message > element's Country Code is not clear enough. > > The text points to the actual MIB element in the > 802.11-1999 standard, which very clearly defines the contents > of the field. I don't think there's value in replicating the > format of this field in the CAPWAP standard. > > I propose rejecting this issue unless anyone provides more details. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > 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 Sep 15 14:48:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIjn-0001Q5-8z for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:48:31 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOIjl-0000NA-SF for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:48:31 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 761A1398324 for ; Fri, 15 Sep 2006 11:48:29 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E4DF3430094 for ; Fri, 15 Sep 2006 11:47:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D46B31448018 for ; Fri, 15 Sep 2006 11:47:44 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by hermes.tigertech.net (Postfix) with ESMTP id E1F541448022 for ; Fri, 15 Sep 2006 11:47:43 -0700 (PDT) Message-ID: <36c501c6d8f7$927216b0$586015ac@dcml.docomolabsusa.com> From: "James Kempf" To: , References: <893AE265F4ADF94AB7FB26D31A788E41029E0CCC@mvebe101.NOE.Nokia.com> Date: Fri, 15 Sep 2006 11:48:44 -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: *** Cc: margaret@thingmagic.com, Dorothy.Gellert@nokia.com Subject: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 50a516d93fd399dc60588708fd9a3002 I'm in favor of splitting the drafts. jak ----- Original Message ----- From: To: Cc: ; Sent: Friday, September 15, 2006 11:18 AM Subject: [Capwap] Consensus call on Split CAPWAP draft by 9/29. Hi All, The editors feel that there is WG support to split the current CAPWAP protocol draft into 2 drafts, a base draft and then a 802.11 binding draft. The chairs would like to verify consensus with the WG that there is sufficient interest to split the draft before making this change. This issue has been discussed at the last CAPWAP WG meeting during IETF 66 in Montreal where there was no opposition to this request, and limited support on the list. The chairs would like establish consensus on the issue of splitting binding specific details from the base CAPWAP specification. Please submit your opinions on this topic to the WG list by Sept 29th, for a final consensus call on this feature. Best Regards, Dorothy, Mani and Margaret -------------------------------------------------------------------------------- > _________________________________________________________________ > 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 Sep 15 14:52:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIo6-0003Le-9t for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:52:58 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOIo4-0000xZ-9S for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:52:57 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id CBDB73982C2 for ; Fri, 15 Sep 2006 11:52:55 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id DC314430094 for ; Fri, 15 Sep 2006 11:52:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D0DFE3980F9 for ; Fri, 15 Sep 2006 11:52:15 -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 8CF92398039 for ; Fri, 15 Sep 2006 11:40:24 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 15 Sep 2006 11:40:25 -0700 X-IronPort-AV: i="4.09,171,1157353200"; d="scan'208"; a="341650345:sNHT31345948" 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 k8FIeOdp005176 for ; Fri, 15 Sep 2006 11:40:24 -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 k8FIeOYp009478 for ; Fri, 15 Sep 2006 11:40:24 -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); Fri, 15 Sep 2006 11:40:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 11:40:23 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A3355@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 171: AC IPv4/IPv6 Addr discusses clustering, which is unnecessary. Thread-Index: AcbNTSEMfy9zKlSWRnyZuM5uzHLxnwLqUTKQ From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 15 Sep 2006 18:40:23.0922 (UTC) FILETIME=[67A77520:01C6D8F6] 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 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] Issue 171: AC IPv4/IPv6 Addr discusses clustering, which is unnecessary. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Given the lack of activity on this proposed text, I will assume acceptance of my proposed approach. I will mark the issue as closed. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, August 31, 2006 3:31 PM > To: capwap@frascone.com > Subject: [Capwap] Issue 171: AC IPv4/IPv6 Addr discusses > clustering,which is unnecessary. > > 23) AC IPv4/IPv6 Addr discusses clustering, which is unnecessary. > > I agree. I have changed the text to now read: > > The AC IPv4 List message element is used to configure a > WTP with the > latest list of ACs available for the WTP to join. > > Comments? > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > 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 Sep 15 14:53:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIou-0003X7-P6 for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:53:48 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOIot-0001Ap-8H for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:53:48 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id C443C398039 for ; Fri, 15 Sep 2006 11:53:46 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2D605430094 for ; Fri, 15 Sep 2006 11:53:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1A4233982FF for ; Fri, 15 Sep 2006 11:53:05 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8BCDC398208 for ; Fri, 15 Sep 2006 11:41:37 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 15 Sep 2006 11:41:37 -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 k8FIfb9q025543 for ; Fri, 15 Sep 2006 11:41:37 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8FIfa1E029399 for ; Fri, 15 Sep 2006 11:41:37 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Sep 2006 11:41:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 11:41:36 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A3357@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 141: Inconsistent usage of Radio ID and WLAN ID Thread-Index: AcbNToDbl22myQsMTR6hBeC8cb1VIgLqAO1g From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 15 Sep 2006 18:41:36.0755 (UTC) FILETIME=[9310E430:01C6D8F6] 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: Subject: Re: [Capwap] Issue 141: Inconsistent usage of Radio ID and WLAN ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: d185fa790257f526fedfd5d01ed9c976 Just send the following reply to Issue 171, when it should have been sent on this issue. Given the lack of activity on this proposed text, I will assume acceptance of my proposed approach. I will mark the issue as closed. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, August 31, 2006 3:41 PM > To: capwap@frascone.com > Subject: [Capwap] Issue 141: Inconsistent usage of Radio ID > and WLAN ID > > > I've seen several places where the range of the Radio ID and > WLAN ID is inconsistant. > > In section 4.1, in the transport header, the RID is > 5 bits (a range of 0-31), but in section 4.4.34, the max > radios and radios in use is a 8 bits (range of 0-255). Also, > in sections 4.4.8, 4.4.11, 4.4.14, 4.4.15, 4.4.17, 4.4.28, > 4.4.39, 11.10.1, 11.10.2, 11.10.5, 11.10.6, 11.10.8, 11.10.9, > 11.10.10, 11.10.11, 11.10.13, 11.10.14, 11.10.15, 11.10.16, > 11.10.17, 11.10.18, 11.10.19, 11.10.20, 11.10.21, 11.10.22, > 11.10.23, and 11.10.24 the radio ID field is 8 bits. > > > ok, well this is done in order to be more efficient on the > CAPWAP header. I see no need to increase the Radio ID to > greater than 5 bits at this time. So I can make the change in > one of two ways. > > The first is to make an actual change to the figures, which > honestly to me seems overly complex. The new diagrams would > now look like: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PAD | Radio ID| MAC Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Where everytime the PAD would be defined as MUST BE ZERO. An > alternative is simply to be more prescriptive in the > definition of the Radio ID fields, such as: > > Radio ID: > An 8-bit value representing the radio. Note the supported values > are between 0 and 31. > > Any preferences? I would opt for the second approach > > In section 11.4, WLAN is a bit map of length 16 (thus a range > of 0-15). However, in the following sections, WLAN ID is 8 > bits (a range of 0-255): > 11.10.1, 11.10.9, 11.10.10, and 11.10.11. > And in sections 11.10.5 and 11.10.21 the WLAN ID is 16 bits (0-65535) > > Actually, section 11.4 is a bitmap, and not the WLAN > ID. However, I have made the change to be clearer. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > 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 Sep 15 14:57:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIsg-0004LR-C4 for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:57:42 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOIsd-0001rf-T5 for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:57:42 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 740353982B9 for ; Fri, 15 Sep 2006 11:57:39 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E5D8E430094 for ; Fri, 15 Sep 2006 11:56:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id DA01839812E for ; Fri, 15 Sep 2006 11:56:59 -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 8FA723982C7 for ; Fri, 15 Sep 2006 11:45:33 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 15 Sep 2006 11:45:33 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8FIjXIl029177 for ; Fri, 15 Sep 2006 11:45:33 -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 k8FIjWQb028601 for ; Fri, 15 Sep 2006 11:45:33 -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, 15 Sep 2006 11:45:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 11:45:31 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A335D@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 210: Clarity required on Client Data Frame Thread-Index: AcbRCTZk7ep2BkiSSpeFYGmbNXDZEwAAEsRQAftf7XA= From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 15 Sep 2006 18:45:32.0500 (UTC) FILETIME=[1F94B940:01C6D8F7] 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: Subject: Re: [Capwap] Issue 210: Clarity required on Client Data Frame X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 0a7aa2e6e558383d84476dc338324fab Given the lack of responses, I will assume the proposed text is acceptable and will close this issue. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Tuesday, September 05, 2006 9:37 AM > To: Capwap@frascone.com > Subject: [Capwap] Issue 210: Clarity required on Client Data Frame > > Sorry, forgot to include the subject > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) > > Sent: Tuesday, September 05, 2006 9:35 AM > > To: Capwap@frascone.com > > Subject: > > > > Following up on this issue, the proposed change would be to qualify > > the term data frame to IEEE 802.11 data frame, so the > resulting text > > would end up being: > > > > > > o All IEEE 802.11 client data frames are tunneled > between the WTP > > and the AC. > > Note that the WTP is responsible for encrypting and decrypting > > frames, if it was indicated in the Add Station request. > > > > Comments? > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > _________________________________________________________________ > 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 Sep 15 14:58:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOItb-0004mI-V8 for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:58:39 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOIta-0001wC-GA for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 14:58:39 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0F31B3980F3 for ; Fri, 15 Sep 2006 11:58:38 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 701BC430094 for ; Fri, 15 Sep 2006 11:57:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5B266398309 for ; Fri, 15 Sep 2006 11:57:26 -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 49F0339830E for ; Fri, 15 Sep 2006 11:46:05 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 15 Sep 2006 11:46:05 -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 k8FIk4v9010548 for ; Fri, 15 Sep 2006 11:46:04 -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 k8FIk4Yp013266 for ; Fri, 15 Sep 2006 11:46:04 -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, 15 Sep 2006 11:46:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 11:46:03 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A335E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 213: Make it clearer that MAC management framesare capwap data Thread-Index: AcbRCXvghJ11TmSIQw6MsNRfWm1TQwAAMRiwAfs7oGA= From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 15 Sep 2006 18:46:04.0827 (UTC) FILETIME=[32D96EB0:01C6D8F7] 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 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] Issue 213: Make it clearer that MAC management framesare capwap data X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 25620135586de10c627e3628c432b04a Given the lack of responses, I will assume the proposed text is acceptable and will close this issue. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Tuesday, September 05, 2006 9:43 AM > To: Capwap@frascone.com > Subject: Re: [Capwap] Issue 213: Make it clearer that MAC > management framesare capwap data > > Not sure what's going on with me today. I should have noted > that the text below is revised to address this comment. > > My apologies. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) > > Sent: Tuesday, September 05, 2006 9:37 AM > > To: Capwap@frascone.com > > Subject: Issue 213: Make it clearer that MAC management frames are > > capwap data > > > > 11.4. Technology Specific Bindings > > > > All CAPWAP transports have the following IEEE 802.11 specific > > bindings: > > > > Payload encapsulation: The CAPWAP protocol defines the > CAPWAP data > > frame, which is used to encapsulate a wireless payload. > > For IEEE > > 802.11, the IEEE 802.11 header and payload are encapsulated > > (excluding the IEEE 802.11 FCS checksum). Note that both the > > 802.11 MAC Management frames, as well as the 802.11 > Data frames > > are included in the CAPWAP payload field. The IEEE 802.11 FCS > > checksum is handled by the WTP. This allows the WTP > to validate > > a > > frame prior to sending it to the AC. Similarly, when an AC > > wishes > > to transmit a frame towards a station, the WTP > computes and adds > > the FCS checksum. > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > _________________________________________________________________ > 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 Sep 15 15:00:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIvf-00065P-PY for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 15:00:47 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOIve-00025E-Ad for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 15:00:47 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id D2B30398385 for ; Fri, 15 Sep 2006 12:00:45 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id EFA90430094 for ; Fri, 15 Sep 2006 12:00:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E1AEF398086 for ; Fri, 15 Sep 2006 12:00:13 -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 3446E3980CF for ; Fri, 15 Sep 2006 11:48:30 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 15 Sep 2006 11:48:30 -0700 X-IronPort-AV: i="4.09,171,1157353200"; d="scan'208"; a="341652573:sNHT32458080" 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.20060308/8.12.11) with ESMTP id k8FImTdV032186; Fri, 15 Sep 2006 11:48: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 k8FImTYp014757; Fri, 15 Sep 2006 11:48:29 -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); Fri, 15 Sep 2006 11:48:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 11:48:28 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2027A3364@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Consensus call on Split CAPWAP draft by 9/29. Thread-Index: AcbY82fx0AwmEjxkSO+bTrWL20FI8gAA/acA From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 15 Sep 2006 18:48:29.0614 (UTC) FILETIME=[89262CE0:01C6D8F7] 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: margaret@thingmagic.com Subject: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 0ddefe323dd869ab027dbfff7eff0465 I strongly support this. The WG has made a decision to create a flexible protocol that allows for supporting various wireless technologies. Any other group that references the capwap protocol must have a document they can add as a normative reference without excluding specific sections of the document. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] Sent: Friday, September 15, 2006 11:19 AM To: Capwap@frascone.com Cc: margaret@thingmagic.com; Dorothy.Gellert@nokia.com Subject: [Capwap] Consensus call on Split CAPWAP draft by 9/29. Hi All, The editors feel that there is WG support to split the current CAPWAP protocol draft into 2 drafts, a base draft and then a 802.11 binding draft. The chairs would like to verify consensus with the WG that there is sufficient interest to split the draft before making this change. This issue has been discussed at the last CAPWAP WG meeting during IETF 66 in Montreal where there was no opposition to this request, and limited support on the list. The chairs would like establish consensus on the issue of splitting binding specific details from the base CAPWAP specification. Please submit your opinions on this topic to the WG list by Sept 29th, for a final consensus call on this feature. Best Regards, Dorothy, Mani and 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 Fri Sep 15 15:15:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOJ9S-00032N-8s for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 15:15:02 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOJ9Q-0004Mp-Gg for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 15:15:02 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 243E73982EB for ; Fri, 15 Sep 2006 12:15:00 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 390D2430094 for ; Fri, 15 Sep 2006 12:14:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2DA3839828A for ; Fri, 15 Sep 2006 12:14:23 -0700 (PDT) Received: from sacmta01.flextronics.com (sacmta01.flextronics.com [205.173.129.14]) by zoidberg.tigertech.net (Postfix) with ESMTP id 162503982D3 for ; Fri, 15 Sep 2006 11:52:29 -0700 (PDT) Received: from AMSAC502.americas.ad.flextronics.com (amsac502.americas.ad.flextronics.com [10.10.9.195]) by sacmta01.flextronics.com (Symantec Mail Security) with ESMTP id B0CCBA24; Fri, 15 Sep 2006 11:52:29 -0700 (PDT) Received: from AMSACEX1.americas.ad.flextronics.com ([10.10.9.185]) by AMSAC502.americas.ad.flextronics.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 11:52:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 11:52:28 -0700 Message-ID: <7D18BEC883BA014EA4FEBF35727E3602A3DB35@AMSACEX1.americas.ad.flextronics.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Consensus call on Split CAPWAP draft by 9/29. Thread-Index: AcbY82fx0AwmEjxkSO+bTrWL20FI8gABIyxg From: "T Sridhar" To: , X-OriginalArrivalTime: 15 Sep 2006 18:52:29.0595 (UTC) FILETIME=[18305EB0:01C6D8F8] X-Brightmail-Tracker: AAAAAA== 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: margaret@thingmagic.com Subject: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0633196189==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 This is a multi-part message in MIME format. --===============0633196189== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D8F8.17D7A1A1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D8F8.17D7A1A1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am in favour of splitting the draft.=0D=0A =0D=0A =0D=0A =0D=0A Thanks,=0D=0A =0D=0A Sridhar=0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A ________________________________=0D=0A =0D=0A From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] =0D=0A Sent: Friday, September 15, 2006 11:19 AM=0D=0A To: Capwap@frascone.com=0D=0A Cc: margaret@thingmagic.com; Dorothy.Gellert@nokia.com=0D=0A Subject: [Capwap] Consensus call on Split CAPWAP draft by 9/29.=0D=0A =0D=0A =0D=0A =0D=0A Hi All, =0D=0A =0D=0A The editors feel that there is WG support to split the current CAPWAP=0D=0A protocol draft into 2 drafts, a base draft and then a 802.11 binding=0D=0A draft. The chairs would like to verify consensus with the WG that there=0D= =0A is sufficient interest to split the draft before making this change.=0D=0A =0D=0A This issue has been discussed at the last CAPWAP WG meeting during IETF=0D= =0A 66 in Montreal where there was no opposition to this request, and=0D=0A limited support on the list. =0D=0A =0D=0A The chairs would like establish consensus on the issue of splitting=0D=0A binding specific details from the base CAPWAP specification. =0D=0A =0D=0A Please submit your opinions on this topic to the WG list by Sept 29th,=0D= =0A for a final consensus call on this feature. =0D=0A =0D=0A Best Regards, =0D=0A Dorothy, Mani and Margaret =0D=0A =0D=0A =0D=0A Legal Disclaimer:=0A The information contained in this message may be privileged and confident= ial. It is intended to be read only by the individual or entity to whom i= t is addressed or by their designee. If the reader of this message is not= the intended recipient, you are on notice that any distribution of this = message, in any form, is strictly prohibited. If you have received this m= essage in error, please immediately notify the sender and delete or destr= oy any copy of this message=0D=0A ------_=_NextPart_001_01C6D8F8.17D7A1A1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A =0D=0A =0D=0A =0D=0A =0D= =0A =0D=0A Consensus call on Split CAPWAP draft by 9/29.=0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A
=0D=0A =0D=0A

I am in favour of splitting the dra= ft.

=0D=0A =0D=0A

 

= =0D=0A =0D=0A

Thanks,=0D=0A =0D=0A

Sridhar=0D=0A =0D=0A

 

= =0D=0A =0D=0A

 

= =0D=0A =0D=0A
=0D=0A =0D=0A
=0D=0A =0D=0A
=0D=0A =0D=0A
=0D=0A =0D=0A

From:=0D=0A Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com]
=0D=0A Sent: Friday, September 15= , 2006=0D=0A 11:19 AM
=0D=0A To: Capwap@frascone.com=0D=0A Cc: margaret@thingmagic.co= m;=0D=0A Dorothy.Gellert@nokia.com
=0D=0A Subject: [Capwap] Consensu= s call=0D=0A on Split CAPWAP draft by 9/29.

=0D=0A =0D=0A
=0D=0A =0D=0A

 

=0D=0A =0D=0A

Hi=0D=0A All,

=0D=0A =0D=0A

The editors feel that there is WG support to split the cur= rent=0D=0A CAPWAP protocol draft into 2 drafts, a base draft and then a 802.11 bindi= ng=0D=0A draft.  The chairs would like to verify consensus with the WG that t= here=0D=0A is sufficient interest to split the draft before making this change.

=0D=0A =0D=0A

This issue has been discussed at the last CAPWAP WG meetin= g=0D=0A during IETF 66 in Montreal=0D=0A where there was no opposition to this request, and limited support on the= =0D=0A list. 

=0D=0A =0D=0A

The chairs would like establish consensus on the issue of=0D= =0A splitting binding specific details from the base CAPWAP specification.

=0D=0A =0D=0A

Please submit your opinions on this topic to the WG list b= y Sept=0D=0A 29th, for a final consensus call on this feature.

=0D=0A =0D=0A

Best Regards,
=0D=0A Dorothy,=0D=0A Mani and Margaret

=0D=0A =0D=0A
=0D=0A =0D=0A Legal Disclaimer:=0A The information contained in this message may be privileged and confident= ial. It is intended to be read only by the individual or entity to whom i= t is addressed or by their designee. If the reader of this message is not= the intended recipient, you are on notice that any distribution of this = message, in any form, is strictly prohibited. If you have received this m= essage in error, please immediately notify the sender and delete or destr= oy any copy of this message=0D=0A =0D=0A =0D=0A ------_=_NextPart_001_01C6D8F8.17D7A1A1-- --===============0633196189== 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 --===============0633196189==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 15 16:25:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOKFE-0001yE-Ah for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 16:25:04 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOKFB-0008L9-IG for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 16:25:04 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 592571448083 for ; Fri, 15 Sep 2006 13:24:47 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id CFE33430094 for ; Fri, 15 Sep 2006 13:23:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AFCB41448050 for ; Fri, 15 Sep 2006 13:23:54 -0700 (PDT) Received: from mgw-ext11.nokia.com (mgw-ext11.nokia.com [131.228.20.170]) by hermes.tigertech.net (Postfix) with ESMTP id 075F51448035 for ; Fri, 15 Sep 2006 13:23:51 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k8FKNjCl026639; Fri, 15 Sep 2006 23:23:46 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 23:23:45 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 15:23:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 13:23:40 -0700 Message-ID: <8A76136424391244A5CF0165337085370216834A@mvebe101.NOE.Nokia.com> In-Reply-To: <7D18BEC883BA014EA4FEBF35727E3602A3DB35@AMSACEX1.americas.ad.flextronics.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Consensus call on Split CAPWAP draft by 9/29. Thread-Index: AcbY82fx0AwmEjxkSO+bTrWL20FI8gABIyxgAAKiglA= From: To: , , X-OriginalArrivalTime: 15 Sep 2006 20:23:42.0374 (UTC) FILETIME=[D6382C60:01C6D904] 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=HTML_MESSAGE, NO_REAL_NAME X-Spam-Level: Cc: margaret@thingmagic.com Subject: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1403090827==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c This is a multi-part message in MIME format. --===============1403090827== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D904.D633A353" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D904.D633A353 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm OK with splitting it out. It should help in the future should we branch to other 802's. =20 Best Regards, Michael ________________________________ From: ext T Sridhar [mailto:T.Sridhar@flextronics.com]=20 Sent: Friday, September 15, 2006 11:52 AM To: Gellert Dorothy (Nokia-ES/MtView); Capwap@frascone.com Cc: margaret@thingmagic.com Subject: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. I am in favour of splitting the draft. =20 Thanks, Sridhar =20 =20 ________________________________ From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com]=20 Sent: Friday, September 15, 2006 11:19 AM To: Capwap@frascone.com Cc: margaret@thingmagic.com; Dorothy.Gellert@nokia.com Subject: [Capwap] Consensus call on Split CAPWAP draft by 9/29. =20 Hi All,=20 The editors feel that there is WG support to split the current CAPWAP protocol draft into 2 drafts, a base draft and then a 802.11 binding draft. The chairs would like to verify consensus with the WG that there is sufficient interest to split the draft before making this change. This issue has been discussed at the last CAPWAP WG meeting during IETF 66 in Montreal where there was no opposition to this request, and limited support on the list. =20 The chairs would like establish consensus on the issue of splitting binding specific details from the base CAPWAP specification.=20 Please submit your opinions on this topic to the WG list by Sept 29th, for a final consensus call on this feature.=20 Best Regards,=20 Dorothy, Mani and Margaret=20 Legal Disclaimer: The information contained in this message may be privileged and confidential. It is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete or destroy any copy of this message=20 ------_=_NextPart_001_01C6D904.D633A353 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Consensus call = on Split CAPWAP draft by 9/29.
I'm OK with splitting it out. It should help = in the=20 future should we branch to other 802's.
 
Best Regards,
Michael

From: ext T Sridhar=20 [mailto:T.Sridhar@flextronics.com]
Sent: Friday, September = 15, 2006=20 11:52 AM
To: Gellert Dorothy (Nokia-ES/MtView);=20 Capwap@frascone.com
Cc: = margaret@thingmagic.com
Subject: Re:=20 [Capwap] Consensus call on Split CAPWAP draft by = 9/29.

I am in = favour of=20 splitting the draft.

 

Thanks,

Sridhar

 

 

From:=20 Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] =
Sent: Friday, September 15, 2006 = 11:19=20 AM
To:=20 Capwap@frascone.com
Cc:=20 margaret@thingmagic.com; Dorothy.Gellert@nokia.com
Subject: [Capwap] Consensus call = on Split=20 CAPWAP draft by 9/29.

 

Hi=20 All,

The editors feel = that there=20 is WG support to split the current CAPWAP protocol draft into 2 drafts, = a base=20 draft and then a 802.11 binding draft.  The chairs would like to = verify=20 consensus with the WG that there is sufficient interest to split the = draft=20 before making this change.

This issue has = been=20 discussed at the last CAPWAP WG meeting during IETF 66 in Montreal where = there was=20 no opposition to this request, and limited support on the list. =20

The chairs would = like=20 establish consensus on the issue of splitting binding specific details = from the=20 base CAPWAP specification.

Please submit your = opinions=20 on this topic to the WG list by Sept 29th, for a final consensus call on = this=20 feature.

Best = Regards,=20
Dorothy, Mani and=20 Margaret

Legal Disclaimer: The = information=20 contained in this message may be privileged and confidential. It is = intended to=20 be read only by the individual or entity to whom it is addressed or by = their=20 designee. If the reader of this message is not the intended recipient, = you are=20 on notice that any distribution of this message, in any form, is = strictly=20 prohibited. If you have received this message in error, please = immediately=20 notify the sender and delete or destroy any copy of this message = ------_=_NextPart_001_01C6D904.D633A353-- --===============1403090827== 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 --===============1403090827==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 15 16:51:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOKex-0003LU-Jt for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 16:51:39 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOKev-0005qj-5I for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 16:51:39 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 910C0144807D for ; Fri, 15 Sep 2006 13:51:33 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 658D0430094 for ; Fri, 15 Sep 2006 13:50:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4A827398034 for ; Fri, 15 Sep 2006 13:50:06 -0700 (PDT) Received: from alnrmhc11.comcast.net (alnrmhc11.comcast.net [204.127.225.91]) by zoidberg.tigertech.net (Postfix) with ESMTP id 26F44398026 for ; Fri, 15 Sep 2006 13:50:00 -0700 (PDT) Received: from [192.168.0.5] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (alnrmhc11) with ESMTP id <20060915205000b1100aj57be>; Fri, 15 Sep 2006 20:50:00 +0000 Message-ID: <450B11F8.9050108@cs.umd.edu> Date: Fri, 15 Sep 2006 16:50:00 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Capwap@frascone.com References: <893AE265F4ADF94AB7FB26D31A788E41029E0CCC@mvebe101.NOE.Nokia.com> In-Reply-To: <893AE265F4ADF94AB7FB26D31A788E41029E0CCC@mvebe101.NOE.Nokia.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Subject: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 8b30eb7682a596edff707698f4a80f7d Support. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Dorothy.Gellert@nokia.com wrote: > Hi All, > > The editors feel that there is WG support to split the current CAPWAP > protocol draft into 2 drafts, a base draft and then a 802.11 binding > draft. The chairs would like to verify consensus with the WG that there > is sufficient interest to split the draft before making this change. > > This issue has been discussed at the last CAPWAP WG meeting during IETF > 66 in Montreal where there was no opposition to this request, and > limited support on the list. > > The chairs would like establish consensus on the issue of splitting > binding specific details from the base CAPWAP specification. > > Please submit your opinions on this topic to the WG list by Sept 29th, > for a final consensus call on this feature. > > Best Regards, > Dorothy, Mani and Margaret > > > ------------------------------------------------------------------------ > > _________________________________________________________________ > 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 Sep 15 22:22:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOPp1-0002EO-Eg for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 22:22:23 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOPoz-0005XO-Pc for capwap-archive@lists.ietf.org; Fri, 15 Sep 2006 22:22:23 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6F1D3398018 for ; Fri, 15 Sep 2006 19:22:18 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 0E6BD430094 for ; Fri, 15 Sep 2006 19:20:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E6D8E1448047 for ; Fri, 15 Sep 2006 19:20:16 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by hermes.tigertech.net (Postfix) with ESMTP id 3D11C1448002 for ; Fri, 15 Sep 2006 19:20:13 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so2409742nfb for ; Fri, 15 Sep 2006 19:20:12 -0700 (PDT) Received: by 10.48.202.19 with SMTP id z19mr14087112nff; Fri, 15 Sep 2006 19:20:12 -0700 (PDT) Received: by 10.49.42.3 with HTTP; Fri, 15 Sep 2006 19:20:12 -0700 (PDT) Message-ID: <5bfe7a820609151920t267edd3do318c44b4119d05e9@mail.gmail.com> Date: Fri, 15 Sep 2006 19:20:12 -0700 From: "Dorothy Stanley" To: "Charles Clancy" In-Reply-To: <450B11F8.9050108@cs.umd.edu> MIME-Version: 1.0 References: <893AE265F4ADF94AB7FB26D31A788E41029E0CCC@mvebe101.NOE.Nokia.com> <450B11F8.9050108@cs.umd.edu> 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.0 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: Capwap@frascone.com Subject: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0951306956==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --===============0951306956== Content-Type: multipart/alternative; boundary="----=_Part_34409_8883900.1158373212595" ------=_Part_34409_8883900.1158373212595 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I strongly support splitting the draft - -to provide a single capwap protocol document for users to reference, independent of application - to increase the group's focus on developing a protocol that can and will be used by applications in addition to WLAN - to increase the group's focus on the essentials of the base CAPWAP protocol versus binding features Dorothy Stanley On 9/15/06, Charles Clancy wrote: > > Support. > > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > Dorothy.Gellert@nokia.com wrote: > > Hi All, > > > > The editors feel that there is WG support to split the current CAPWAP > > protocol draft into 2 drafts, a base draft and then a 802.11 binding > > draft. The chairs would like to verify consensus with the WG that there > > is sufficient interest to split the draft before making this change. > > > > This issue has been discussed at the last CAPWAP WG meeting during IETF > > 66 in Montreal where there was no opposition to this request, and > > limited support on the list. > > > > The chairs would like establish consensus on the issue of splitting > > binding specific details from the base CAPWAP specification. > > > > Please submit your opinions on this topic to the WG list by Sept 29th, > > for a final consensus call on this feature. > > > > Best Regards, > > Dorothy, Mani and Margaret > > > > > > ------------------------------------------------------------------------ > > > > _________________________________________________________________ > > 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_34409_8883900.1158373212595 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I strongly support splitting the draft -
-to provide a single capwap protocol document for users to reference, independent of application
- to increase the group's focus on developing a protocol that can and will be used by
applications in addition to WLAN
- to increase the group's focus on the essentials of the base CAPWAP protocol versus binding features
 
Dorothy Stanley

 
On 9/15/06, Charles Clancy <clancy@cs.umd.edu> wrote:
Support.

--
t. charles clancy, ph.d.  |  tcc@umd.edu  |   www.cs.umd.edu/~clancy

Dorothy.Gellert@nokia.com wrote:
> Hi All,
>
> The editors feel that there is WG support to split the current CAPWAP
> protocol draft into 2 drafts, a base draft and then a 802.11 binding
> draft.  The chairs would like to verify consensus with the WG that there
> is sufficient interest to split the draft before making this change.
>
> This issue has been discussed at the last CAPWAP WG meeting during IETF
> 66 in Montreal where there was no opposition to this request, and
> limited support on the list.
>
> The chairs would like establish consensus on the issue of splitting
> binding specific details from the base CAPWAP specification.
>
> Please submit your opinions on this topic to the WG list by Sept 29th,
> for a final consensus call on this feature.
>
> Best Regards,
> Dorothy, Mani and Margaret
>
>
> ------------------------------------------------------------------------
>
> _________________________________________________________________
> 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_34409_8883900.1158373212595-- --===============0951306956== 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 --===============0951306956==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Sep 16 00:07:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GORSc-00073R-Vu for capwap-archive@lists.ietf.org; Sat, 16 Sep 2006 00:07:22 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GORSb-00068b-Ez for capwap-archive@lists.ietf.org; Sat, 16 Sep 2006 00:07:22 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 39DED1448087 for ; Fri, 15 Sep 2006 21:07:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1C2DB430094 for ; Fri, 15 Sep 2006 21:06:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EC73F144804F for ; Fri, 15 Sep 2006 21:06:25 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by hermes.tigertech.net (Postfix) with ESMTP id EB8F21448029 for ; Fri, 15 Sep 2006 21:06:24 -0700 (PDT) Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 15 Sep 2006 21:06:18 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 9031F2AF; Fri, 15 Sep 2006 21:06:18 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 6BB082AE; Fri, 15 Sep 2006 21:06:18 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EFE36572; Fri, 15 Sep 2006 21:06:14 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 7854520501; Fri, 15 Sep 2006 21:06:14 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Sep 2006 21:06:13 -0700 Message-ID: <8954613CA6BB3242A1531D916A527A4101DBE9EB@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <893AE265F4ADF94AB7FB26D31A788E41029E0CCC@mvebe101.NOE.Nokia.com> Thread-Topic: [Capwap] Consensus call on Split CAPWAP draft by 9/29. Thread-Index: AcbY82fx0AwmEjxkSO+bTrWL20FI8gAUfhyg From: "Puneet Agarwal" To: Dorothy.Gellert@nokia.com, Capwap@frascone.com X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006091601; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230352E34353042373637382E303033322D412D; ENG=IBF; TS=20060916040620; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006091601_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6915A7B03CC7291591-01-01 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=HTML_50_60, HTML_MESSAGE X-Spam-Level: Cc: margaret@thingmagic.com Subject: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0488477391==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c This is a multi-part message in MIME format. --===============0488477391== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D945.7391DF46" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D945.7391DF46 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I support the split into 2 drafts. =20 Thanks. =20 -Puneet ________________________________ From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com]=20 Sent: Friday, September 15, 2006 11:19 AM To: Capwap@frascone.com Cc: margaret@thingmagic.com; Dorothy.Gellert@nokia.com Subject: [Capwap] Consensus call on Split CAPWAP draft by 9/29. Hi All,=20 The editors feel that there is WG support to split the current CAPWAP protocol draft into 2 drafts, a base draft and then a 802.11 binding draft. The chairs would like to verify consensus with the WG that there is sufficient interest to split the draft before making this change. This issue has been discussed at the last CAPWAP WG meeting during IETF 66 in Montreal where there was no opposition to this request, and limited support on the list. =20 The chairs would like establish consensus on the issue of splitting binding specific details from the base CAPWAP specification.=20 Please submit your opinions on this topic to the WG list by Sept 29th, for a final consensus call on this feature.=20 Best Regards,=20 Dorothy, Mani and Margaret=20 ------_=_NextPart_001_01C6D945.7391DF46 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable Consensus call on Split CAPWAP draft by 9/29.
I support the split into 2 = drafts.
 
Thanks.
 
-Puneet

From: Dorothy.Gellert@nokia.com=20 [mailto:Dorothy.Gellert@nokia.com]
Sent: Friday, September = 15, 2006=20 11:19 AM
To: Capwap@frascone.com
Cc:=20 margaret@thingmagic.com; Dorothy.Gellert@nokia.com
Subject: = [Capwap]=20 Consensus call on Split CAPWAP draft by 9/29.

Hi All,

The editors feel that there is WG = support to=20 split the current CAPWAP protocol draft into 2 drafts, a base draft and = then a=20 802.11 binding draft.  The chairs would like to verify consensus = with the=20 WG that there is sufficient interest to split the draft before making = this=20 change.

This issue has been discussed at = the last=20 CAPWAP WG meeting during IETF 66 in Montreal where there was no = opposition to=20 this request, and limited support on the list. 

The chairs would like establish = consensus on=20 the issue of splitting binding specific details from the base CAPWAP=20 specification.

Please submit your opinions on = this topic to=20 the WG list by Sept 29th, for a final consensus call on this = feature.=20

Best Regards,
Dorothy, Mani and Margaret =

------_=_NextPart_001_01C6D945.7391DF46-- --===============0488477391== 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 --===============0488477391==-- From rechvsls@terra.cl Sat Sep 16 19:04:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOjDI-0006sB-Ne for capwap-archive@ietf.org; Sat, 16 Sep 2006 19:04:44 -0400 Received: from 130-26-112.adsl.terra.cl ([200.112.26.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOjCM-0002EZ-HR for capwap-archive@ietf.org; Sat, 16 Sep 2006 19:04:44 -0400 Message-ID: <000701c6d9b2$05fd4bd0$821a70c8@desktop> From: "on" To: capwap-archive@ietf.org Subject: with search. Date: Sat, 16 Sep 2006 19:03:25 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C6D9C2.C9861BD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.9 (+++) X-Scan-Signature: bb7a33d18683bf5063a44e640cf125f1 ------=_NextPart_000_0003_01C6D9C2.C9861BD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C6D9C2.C9861BD0" ------=_NextPart_001_0004_01C6D9C2.C9861BD0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable e Google Groups Home Help Sign in Web Images VideoNew News Maps more = raquo Advanced Search Members: users: Join Alerts Create new group About = Searched all groups Your search did not match any Make sure words are = spelled Try different keywords. general fewer your on can try Answers = for expert help with search. Get the latest messages emailed to Alerts. = Terms of Web Images VideoNew News Maps more raquo Advanced Search Members: users: = Join Alerts Create new group About Searched all groups Your search did = not match any Make sure words are spelled Try different keywords. = general fewer your on can try Answers for expert help with search. Get = the latest messages emailed to Alerts. Terms Web Images VideoNew News Maps more raquo Advanced Search Members: users: = Join Alerts Create new group About Searched all groups Your search did = not match any Make sure words are spelled Try different keywords. = general fewer your on can try Answers for expert help with search. Get = the latest messages emailed to Alerts. Terms of Google Groups Home Help Sign in Web Images VideoNew News Maps more raquo = Advanced Search Members: users: Join Alerts Create new group About = Searched all groups Your search did not match any Make sure words are = spelled Try different keywords. general fewer your on can try Answers = for expert help with search. Get the latest messages emailed to Alerts. = Terms of Service Privacy Policy raquo Advanced Search Members: users: Join Alerts Create new group About = Searched all groups Your search did not match any Make sure words are = spelled Try different keywords. general fewer your on can try Answers = for expert help with search. Get the latest Join Alerts Create new group About Searched all groups Your search did = not match any Make sure words are spelled Try different keywords. = general fewer your on can try Answers for expert help with search. Get = the latest messages emailed to Alerts. sure words are spelled Try different keywords. general fewer your on can = try Answers for expert help with search. Get the latest messages emailed = to Alerts. Terms of ------=_NextPart_001_0004_01C6D9C2.C9861BD0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
e Google Groups Home Help Sign in Web Images VideoNew News Maps = more raquo Advanced Search Members: users: Join Alerts Create new group = About Searched all groups Your search did not match any Make sure words = are spelled Try different keywords. general fewer your on can try = Answers for expert help with search. Get the latest messages emailed to = Alerts. Terms of
Web Images VideoNew News Maps more raquo Advanced Search = Members: users: Join Alerts Create new group About Searched all groups = Your search did not match any Make sure words are spelled Try different = keywords. general fewer your on can try Answers for expert help with = search. Get the latest messages emailed to Alerts. Terms
Web Images VideoNew News Maps more raquo Advanced Search = Members: users: Join Alerts Create new group About Searched all groups = Your search did not match any Make sure words are spelled Try different = keywords. general fewer your on can try Answers for expert help with = search. Get the latest messages emailed to Alerts. Terms of
Google Groups Home Help Sign in Web Images VideoNew News Maps = more raquo Advanced Search Members: users: Join Alerts Create new group = About Searched all groups Your search did not match any Make sure words = are spelled Try different keywords. general fewer your on can try = Answers for expert help with search. Get the latest messages emailed to = Alerts. Terms of Service Privacy Policy
raquo Advanced Search Members: users: Join Alerts Create new = group About Searched all groups Your search did not match any Make sure = words are spelled Try different keywords. general fewer your on can try = Answers for expert help with search. Get the latest
Join Alerts Create new group About Searched all groups Your = search did not match any Make sure words are spelled Try different = keywords. general fewer your on can try Answers for expert help with = search. Get the latest messages emailed to Alerts.
sure words are spelled Try different keywords. general fewer = your on can try Answers for expert help with search. Get the latest = messages emailed to Alerts. Terms of
------=_NextPart_001_0004_01C6D9C2.C9861BD0-- ------=_NextPart_000_0003_01C6D9C2.C9861BD0 Content-Type: image/gif; name="keywords..gif" Content-Transfer-Encoding: base64 Content-ID: <000201c6d9b2$05fadad0$821a70c8@desktop> R0lGODlhoAJQAocAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwKemquvp7UAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78AAA QICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAUAAAALAAAAACgAlACBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suWW 5C5r3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s277Z7ewIMLH068uPHj yJMrX868ufPn0KNLn069uvXr2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djy59P37uD +vjz69/Pv79/j0ww8d+ArwlIIGtzHKjgggw26OCDEEYo4YQUVmjhhRhmqOGGHHbo4Ycghiji iCSWaOKJKKao4oosdiVFizDGKOOMNNZo44045qjjjjz26OOPQAYp5JBEFmnkkUgmqeSSTDbp 5JNQRinllFRWaeWVWGapZWc1bOnll2CGKeaYZJZp5plopqnmmmy26eabcMYp55x01mnnnXjm qeeefOomTp+ABirooIQWauihiCaq6KJP0sLoo3kSAOmklFZq6aWYZqrpppwSdkCnoIa6Fxai lmrqqaimqmpeSqzq6qv/sMYq66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMNuvs s9BGK+201FZr7bXYZqvttkg5w+234IYr7rjklmvuuU1lgO667Lbr7rvwxitvW47O+1y99jaH b7789uvvvwAHLPDABBds8MFnKYDwwgw37PDDEEcs8cQUV2zxxRhnrPHGHHfs8ccghyzyyHiq SzJpJp88Wsoqg8Zyy569DDNnMs+8Wc02W4ZzzpTtzPPPQAct9NBEF2300UgnrfTSTDft9NNQ u/Zb1FRXbfXVWGet9dZcd+3112CHLfbYZJdt9tlop62216JASM3acL0Nt1tyz81W3XarhXfe /mjtzbdZfv81xN+EF2744YgnrvjijDfu+OOQRy755JRXbvnlmGeuuXuzbO7556CHLvropJdu +umop656Yhas7vrrsMcu++y012777bjnrvvuvPfu++/ABy/88MQXb/zxyCev/PLMN+/889BH L/301Fdv/fXYZw/vF9p3X1Ym3ocv/vjkl2/++einr/767Lfv/vvwxy///PTXb//9+Oev//78 9+///wAMoAAHSMACGvCACEygAhG1hgU68IEQ/Nw7IvKNCFrwghjMoAY3yEFrvaiDIAyhCEdI whKa8IQoTCHFSEUgdtjPhSqcXZdiSMMa2vCGOMyhDnfIw488oIdA/gyiEIdIxCIa8YhITKIS CYaNtXxqiVCMohSnSMUqWlGEO7iiFhnVie4ZY4tgDKMYx0jGMkLxEYJhRP3USD82IuuJ8nGj /OQYPzrCz47vw6P79GjGPvrxj4AMpCAHeZw3EPJiFTikIhfJyEY68pGQjKQkJ0nJSlYpFvfD pP00WT9O0s+T1UNDRkApP1LGLxamtKQqV8nKVrrylUC5Bixn+Rdd2M+Wt/zIMqaHS1r68pfA DKYwh0nMYhrzmMhMpjKXyUyaoKOZ0IymNKdJzWpa85rYzKY2t8nNbnrzm+AMpzjHSc5ymvOc 6Ezne66gzna6UzC+eKc856mpUZSrEfTMM6c+0TeJkixgnwDVjiUCStCCDrMPCE1oHwzK0IY6 9KEQjahEd1WMiVr0ohjNqEY3SpOAAAAh+QQAHAAAACwAAAAAoAJQAgcI/gD/CRxIsKDBgwgT KlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz 6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jT ql3Ltq3bt3Djyp1Lt67du2e74d3Lt6/fv4ADCx5MuLDhw4gTK17MuLHjx5AjS55MubLly5gz a97MubPnz6BDix5NurTp06jh7krNurXr17Bjy55Nu7bt27hzm2aju7fv38CDCx9OvLjx48iT K1/OvLnz59CjS59Ovbr169izOx6mvbv3j9y//osfXzE8+fPoF5o/Ki29e83r38ufT7++/fv4 8+vfz7+///8ABijggGvZQuCBCCao4IIMNggSHA5GKOGEFFZo4YUYZqjhhhx26OGHICbISYgk lmjiiSimqOKKLLbook+RvCjjjDTWaOONOOao44489ujjj0AGKeSQRBZp5JFv6YXkkkwiBUST sVkA5ZRUVmnllVhmqeWWXHbp5ZdgljVBmGSWaeaZaKap5ppstunmm3DGKeecdPp2RZ145qnn nnz26eefgAYq6KCEFmrooYgmquiijDbq6KOQRirppJRWaumlmGaq6aacIhRKp6CGKuqopJZq 6qmopqrqqqy26uqr/7DGKuustNZq66245qrrrrz26uuvwAb7YjrCFmvsscgmq+yyzJ4WTrPQ RivttNRWa+212Gar7bbcduvtt+CGK+645JZr7rnopqvuuuy26+678MYr77z0+rdAvfjmq+++ /Pbr778Aa1pAwAQXbPDBCBsFRcIMN+zwwxBHLPHEFFds8cUYZ6zxomJs7PHHIG9mTsgkl2zy ySinrPLKLLfscp/OvCzzzDTXLJ0hNqN2SM489+zzzyzPA/TQRBdt9NFIJ6300kwTeELTUEct 9dRUV2311VhnrfXW5G3C9df0WgL22GSXbfbZaKet9tpst+12Tuy8LffcdNdt991456333v58 9+3334AHLvjghBdu+OGIJ6744oyHqUfjkEcu+eSUV2755ZhnrvnmnHfu+eeghy766KSXzvMY pqeu+uqst+766yPdO+41sNdu++2456777rz37vvvwAcv/MQNDJ9S8cafhHzyJS3P/EjOPx9S 9NJXb/312Gev/fbcd+/99+CHLz7QxQBlwOjlqwkJnumPH1H77j8Ef/wNze/qEPSzikr+/Pfv //8A1FwCAkjAAhrwgAhMoAIXyMAGOvCBEIygBCdINhZQ8IIYzKAGN8jBDnrwgyAMoQhHSMIS mvCEKHzXGlLIwha68IUwjKEMZ0jDGtrwhjjMoQ53yMMe+vCHQP4MohCHSMQiGlFA9mBgEhe4 xCM60S1gaGAUpejAKTLQigvE4hO3yMUuevGLYAyjGMdIRtZUo4xoTKMa18jGNrrxjXCMoxzn iK0ZHCkA4zoFfvDYQD4y0I8LBKQCAyBIOhrykIhMpCIXychGOvKRkIykJPe1sEla8pKYZAoZ GrhJBnZygZ9UYChrQ4eMjRKBpzxgKg24yky68pWwjKUsZxm6DNDylrjMpS53ycte+vKXwAym MIdJzGKG6BfGTKYyl/m2PDDzmdCMpjSnSc1qWvOa2MymNrfJzW5685vgDKc4x0nOcprznOiE Dj3Syc52uvOd8IynPCk0jXnS6hsMxDFnPve5QH0q0J//5GdA+2nPghqUSk1UYEIVetCGOvSh EI2oRCdK0Ypa9KIYzahG8RQQACH5BAAdAAAALAAAAACgAlACBwj+AP8JHEiwoMGDCBMqXMiw ocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmz p8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2 rdu3cOPKnUu3rt27ePPq3cu3r9+/gAML7qhusOHDiBMrXsy4sePHkCNLnky5suXLmDNr3sy5 s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHjyJMrX868 ufPn0KNbhSa9uvXr2LNrx05su/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djy59Pv779+/hLx8rP v7///wAGKOCABBZo4IEIJqjgggwmBUuDEEYo4YQUVmjhhRhmqOGGHNr2RYcghijiiHklQuKJ bpmI4opqqcjii2W5COOMYMlI441b2YjjjlbpyOOPUfkI5JBEFmnkkUgmqeSSTDbp5JNQRinl lFRWaeWVWGappUKWbOnll2CGKeaYZJZp5pkIfYPmmgupyeabBrkJ55z/yBmUMnRWaGeea36z J5+ABirooIQmmE2hiCaq6KKMNuroo5BGKumklFZq6aWYZqrpppx26umnoIYq6mCGjAoTnqam quqqrLbq6qv/sMYq66y01mrrrbjmquuuvPbq66/ABivssMQC20axyCar7LLMNuvss9BGK+20 1FZr7bXYZqvtttDJw+234IYr7rjklmvuueimq+667Lbr7rvwxivvrhbMa++9+Oar77789uvv vwAHLPDABBdsMLRPHKzwwgw37PDDEEcs8cQUV2zxxRhnrPHGHHfs8ccghyzyyCSXbPLJKKes 8sost+zyyzDHLPPMNNds8804C1dDzqPtzLNoPv8MWtBCF2300UgnrfTSTDft9NNQRy311FRX bfXVWGet9dZcd+3112CHLfbYZJdt9tlop6322my37fbbcMct99x012333Q4divfe/nz37fff gAcu+OCEF2744Yhjt0rijDfu+OOQR+6cMZJXRXnlUl2OeVSab+5U5543BXro0HVA+umop676 6qy37nrhGLwu++y012777bjnrvvuyYbD++/ACy5N8EKxQ/zxyCev/PLMN+88z888L32A9Exv /XhoXK/99tx37/334If/uCDil2/++einT58q6rfv/vvwxy///PTXb796ANxvkij6FwhG/wAM oAAHiJ16EfCACEygAheIlOEx8IEQjKAEJ0jBClrwghjMoAY3yMEOevCDIAyhCEdIwhKa8FmZ IM0dTsjCFrpmEy6MoQxnSMMa2vCGOIRfGCTSnRz68IdA/gyiEIdIxCIa8Vv/O6ISl8jEIe6g iVCcUx0YWIcpKrCKVIyiFrfIRdr9IYJffGAYxQjGMkJwjAxE4wLVqEA2dvGNcIyjHBlTiTna 8Y54zKMe98jHPvrxj4AMpCAHSchCGvKQiEykIhfJyEY68pGQjKQkJ0nJSlrykpjMZNXYEEFO PtCTDARlKCEoSgWWUpOoTKUqV8nKVrrylbCMpSxnScta2vKWZ9oHLnd5ohlsJxK8DKYwh4k2 chDzmMhMpjJ/AoxlOvOZ0IymNKdJzWpa8yU3iGA2r3klZnDzm+AMpzjHSc5yHq8FCGyBOtdp zna6853wjKc850nPetrznvjMNKc+98nPfvrzmzH4J2jUINCCGvSgdCoHQhfK0IY69KFaMh5E J0rRilr0ohjNqEY3ylFBBgQAIfkEAAfgAAAsAAAAAKACUAIHCP4A/wkcSLCgwYMIEypcyLCh w4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rcybOn z58FCQglMHCo0aNGDSIViJQoU6H/iCZN+hRq1aJWh0Z9CrSr169gw4odm9Iq1q1RnUp1qlSt 26Jc08ZFG9esVqZ135Ldy7ev37+Ab5qdK/fswax6DeMtzLZwXcZzEweeTLmy5cuYCQ52zHmz YcR0Pctt3FktV7ekRWdezbq169crNw+eTRrr3bR2a+NO3Tjradu9YQsfTry4cYeyeytHCHq0 Ys1roUsPnZyt7uPYs2vfztdu6el0Gf5L5vzZ+vLwvglzX88+57j27EHTnj5fPFzHiXNHpq9X Nfz/AAYo4EZNUWXgUlXd1RRwCe7G4FX3rWXegBRWaOGFGGao4YYcdujhhyCGKOKIJJZo4oko pqjiiiy26OKLMMYo44wlxULjjTjmqOOOPPbo449AwgTBQBAUOaRARh5pkJH/DJkkkUU22WSU SFLJpJJQOjlllE9WSeWWWzppZZJkcskkkVmSmWaaZZa55JlXIqSkmwR1GWaYbbJ55p0Ftfmk n2J+uaaXe+YpaJCIviTooYdCWeWjkI45Z6RYTkmpo5dmKiWSkVoK6adHWllnpVx22mimpy4a 6pyrYiplq/+bbiqqp41+KSaatN7aJ6y5uqprosC2pOquck7aK6668kqqsbbyeuysxPqKZa2V fmrtsAcVmYqnsY7q7bGaTlutq9yWa66lrD7KqLigOntusPCS9Ou6xS5rLbJagpktvZpya2a+ 0baLJr8BX8vuvv+ksueS/sKKra3fIkwuveIebGbBY2Ja6r3xdhzSvPbWm+67rbKaaqF0Yovu xhjT+WrIBZercsB21tkwyt9CTG7LERPaMpwwgyvptB4XLZKdBNeLapxe7jquvs0a7KiW46rc bNI7z3xquQpTGzW4QvfMc9YAN31v0hlfSrTRbHM0MsQ6c7q0xjlnrfHbB/fb89f+I3Psr8x5 WyxQ133e3W/a3W4NuNi1Nkzz4o6/2/bkGeGtrrNp8x1qzu5m3jfiek/8tugSX0w65KDH6rnh oIrNuLt/W855uMpOqjjluC90JaB+2gz01auuHSjDvwdqcrWp+3ynocU73Tufefo8/KjGu6z8 oNdTv6zXzLscPZ94Hr977uSXb/756Kev/vrst+/++/DHL//89Ndv//3456///I7s7///AAxg oj4wkA8Y8IAFPKABDaLABCrwgQ9kYAQb2ECBQHCBFkRgQTSowX9U0IMIvCAGHdjBApJwhAQh YAY/uMEOunCEJfygDGEowoOoEIQqLCEOPYhDES7Qhz7+TGEQezhEId7whQIMEQoxSMMMSrCF PAShBaVowxwSEIYbdGIUmXjDBJpQi02cIhVROMYuLtGKUPQiFYWoxR2K0YFwBOMRsVjGNLax i3Vc4xWtiEYeYvGFfeSiCQWZxh/2MYkeOqMaw6jGRq7xkWyUIhMTokhH6rGNedziIeUYyTua 8ZOYfOQkJ2nEOFZyj2JkpCiPaMdNZrKScXQjIclIyEgaMpSIzBAqPcnLTmISloVEJR7tuMon ztGWrMwkJ6fIyD8eE5KndCIeKahMUv6wl34E5TB1eM1lFnOO15wlGp9JxjrWMpca2qUeD0nL aYLSkidc4TB9CUxpOrKWfJz/Jwuz2UhnkrCKtrRnCiVZzRwKtJnfrCINFwpMGRKUi4AE5zzX aUZ0cmiGi3ymJRs60XZCkp7vJOYpk3lLKJ6xmRL1YjmjucIshnOTpJSlRvdZzlISFJcJZeYV 8yjIY9a0p8m0KIbISdSNspKjXwzlOUHqy3u+k44lZSMdX2lQTq70qU3dYyCxmtFFOtWGXW3q L6cp02V69KfjnKhQK1TUdeISqEztoVI1mlVXGhWbWw3mG8WZVL7q9Y3Q9CY+kXnHrz7xlR8t JjPNmledvjWtOF0rgEJYRAhKcIgVDOIMDdnOznaUm6CFqFb/aVkgwrGGOpRrS5O6Q86mdLU6 3axq/veZzXxesIWiLa1Wb0tE3X4SovCUrHCHS9ziGve4yE2ucpfL3OY697nQja50p0vd6lr3 utjNrna3y93ueve74A2veMdL3vKa97zoTa9618ve9rr3vfCNr3znS9/62ve++M2vfvfL3/76 978ADrCAB0zgAhvYLwBI8D8A0JIEM1ggDj7JACY8AINQ+MIDubCGN5wQCv+jwhn2sEBEPOIN exjDJk6xiglyYhZzuMQg/vCEP3yQGGPYwjOmyI1l/GIe09jFOeaxinccYhSfmMgH7oiCF/xg lkQYwikJckFyTOIKg5jKMu7wlW285SJ7OctZDrKVSzxiMNOYyl02M5l9/lzmNUu5zWCWcpol guY2YznOMQ7xlMccZzW7mMxiznCSPbJkKDeYyYaOyBoq8mY9n/nKf3Y0jlm8ZjeLuc5htnGk K23pSue5z3eW8545HWg/O0TOeUY1pUe9aTU3utN3FvSgN1JogjzZwQrONa4HcutdM5nBtX5w riG8ZFwDu8lPRvSpP+3oLqf62Qh5taqF/GhYa1rStJgxly3NbDcDmtOsdrWVj3zpLZNY3K2W 9pxJDe0aO5vPrZ61RWpNbGXrGtH3vje+hQ3sgvB7wfuud76PXe9lRxvSYU53t02N7mqPG8aY /jG7y/1pJPc54Qz3dLvrrO2HY5zdCnc3uKcN/+4io7nRryZfCERE74AHfOC8LjbB8e3vmCNb 5i/3dURSHutzkzzcIXc4nsPd7m8DmtnnvjibU27maXN83CJGedEbrmWg/zzeHQe6vCvScn3D 3Ov2nrmybW1rYYc95xYptbclTfWpsx3LUV9304OuZ7W/OdZDP/jb05z1uyN96lefdJl/rnY/ RzzjW49IoQmO868z/t+LbzKvy+5yxxu65VVvOOA3XvFr5/3HmPa7rEE+eL7LHe+XHr3mt53p i6t75J2Xdeg9Tvobi17jic+Iznv9eGPb3PfJlvyvyf5r4B/7+DFftoZN7nOTQzzp1AYylx+e 4j2j+uTVb3HSTbxqiP4L3vvMh/rSoR9950u/7kMG/4p3bOSsuygU98M8Q4S/v4Wzx/65P4n8 E9JvAeJfO/+XfyShcw2xfwJ4gAiYgAq4gAzYgA74gBAYgRKIKBFGfwqRbAZRgRCBgRlogAdH cUPGdBOoXjiXaBdogWe3gSiYfHQWe3yHeCNIgsg2efOHgouneCtYcDsXe3sXg/KFgbsWfI0X bER4fEHIb5F3czrIELdHej4IX7v3eDQ3hf4mhACHdpaXgg3RhFT3hFA4hC5HbPvXa1doeTA3 dhDBhYEnWdvghfrHglkocMKnhDpohlKIhg8RaITneW54XiVohnJYhXWohHaYgh4Yae5Xe/8B 2IfdhXxiOHwFV4HBBok0KInFN3a8J3YLEYLq12OMmH85+ImiaBL9N4qmqBKHeIqquIqs2Iqu +IqwGIuyaFEBMIv1ZWxdd3OhiBAayIEfEQDAOBDAWIsEMYzBaIzEaIvcdYOCyIIqGIm7eBG1 OI3/cIzJWI3GiI3DqIyNGI3O6BCTiIceQY3TWI4HcY3VyI3dWIa4iIRI+IhEeBAyp4uPuIQK sY0CYY3nWBDoqI7XFYUAV4hUaI+BmG+V543amI/maBDo2I/+WF3DNohhSIZzaIGO544IyY/6 GIwMyY8PqV30FnmVh4n0h3lnaIkUQY7YuJIeWYwfCZIVmXxxaJL/M4iFIymOCKGSG5mMDfmS 2BWFuhaUQlmTHTiPjiiEdNgQ+JiQLJmOLumT9JWRJ+GQUAlgpViVH5mKWLmVXNmVXvmVYBmW FsEJYumK+VCW4kWANqeCuNgS+fCWA/GWcImWPzmGGflvV3gRUvkPZ9mXAiGXdPmTNTgRWgmO EuGXfhmY2aWWYviOw5eLZYeRxQcASZCJOHkQgPmXmamY1OV7lHeSV+mMXod8oEmQCZGZcjmX nAmRMZmEAiePFYmXA0eGE7GZfHmWq2ldpDlzYid/k1iCkBiSe4mYBYGbuQldEfmZd3iZIvmH zSib3kiccGmcx/lcvtiYRkiUkamLbemZ/0h5mZg5l7ZZnea1l7DJmBdBneSZXqFJEZJnnut5 X4VZg/MZn/ZZEWVwn/q5n/zZn/75nwAaoAI6oARaoAZ6oAiaoAq6oAzaoA76oBAaoRJ6EeIw oRZ6oRiaoRq6oRzaoR76oSAaoiI6oiRaoiYqEJVwoiq6oizaoi76ojAaozI6ozRaozZ6ozia ozq6oyrCDxDBD0DaEEHKoz+CAToxpA+BpAqhpDmyBETKE0zKEFH6pMzlo0MKpFg6EFkqEEGa pV36pT76D1s6pVSaP1YapmJ6pmm6pmzapWsapl8qplyKpmXqP1iKpnE6p3C6p3K6pW9KpsaV DC2Kp3x6pW1KqP9aeqV7SqfIJaiDmqhz+qeHCql9WqiTGqgu6qV3CqZpuqlIuqh6eqeUSlyO WqcHwajUVaqmShBWil2quqqjWl2vCqvbNau0ml22equ6uqu8KiMn0KsAcgLC+qvDahHF+qsf MazFChHLihDNyqzCOhDPCqzHEa0CgawUYa3W+g/YqhHa2q0Nsa3OCq7hyq3miqziSq3Fsa3k Cq3S+q4c8a0Rka4GQa8MQazmKq3tqq7Coa3X+q3KGq3i+qwBq6zcCrDsarD6+q8HS6wO67D6 mrDYCrANe7AW+6/gaq/82q/4arHyCrG/mgAEobAXK7Amy7Anm64Bu7AfO7IgC7Ee+7L/HlsQ BKuxG+saAoux8oqy44quPouyP5uyGfuzMcuzLPuwHyuzOUuzA7uvN4uzEzu0LluvC1uyQXu1 GFuvRHuyDDu1XHu0Vnux79qxXfu0xJGw11q2Ylu1O5u0QJuvB9G2MLu2ReuvdYu1I3uu+eq0 ZssaTeuzA0u1zVqwgJu1hNutBeuyg0uzYrusBju4cxuxktu3fSEPJcG33rqyE4G5HsG5lNse ZBsSiCsRofu5QGKzHUGy7mq6rIs+V9C6sBu7sju7tBssx2oSqusSjzutFZu1tcuxapu6TOut GYG2cYu4nvu7gRG4ICG1xVu8UTuuU6u8UKu1L3u4vau5qmuy/8cqtFGLtNm7u0RbtVYbvQ2b vNTrF/bKtTnLvWG7s2yrtHe7tzIbsx2rsonLvvWbvquxvjBrvNr7v84rtOcqvmArt3yLtvpb tPzbv+26wF2Lv2E7vQQcueHLwBKbEAoswAzcwJnBrm/buFsbwhKMwSPMwRDMwdM7vyzswR9c s4R7vr7bvQ8bsQacwb1bsY5Lw+Qrwwbsw7nrwkI8xERcxEZ8xEicxEq8xNWFvkycErdrvQqR uDXBu1r7vFMssdjaBE+sEvA7vFkcvDFhs+NbESqbt/eLul1MEiB8vAvxxTJBxvGasWist2v8 EtMKub5LwYU7wwgrwN07uZorw+EbwP+Aa7xofMiTS8h3vBIKu8Bfq7MHjK+QjMJKi7UVvLX1 C8GJ3MOFrMaNLBKQe7V5DMhfW8nve71ue8pya8J0y7SIvMivHMojYb6WLL1fvMFvu8oWnMlp 28qo7KzxW8d0TMsnwcskDMbsO7OojMx268spvMkqDK8T/MsFDLfGfLk5fLg1rLg1rMd+rMre W8g6LL7c+8M8/LdAjLx9nM3q48TuHM/yvKqNMM/2fM/4nM/6vM/83M/+/M8AHdACPdAEXdAj mAIGndAKvdAM3dAO/dAQHdESPdEUXdEWfdEYndEavdEc3dEe/dEgHdIiPdIkXdIQXQEoXQED kdIs3dIsbRD/Li0QLt3S/zDTKU0QKi3TN43TKF3TPG3TPQ3UPf3TPr3SO13TNy3UM43USm3U Sp3TL63TKp3TUu3TT03VUp3UNM3UVJ3UXK3VMDrURl3UQz3VWM3TOp3WMo3UK63WRc3WY43W cL3WcG3WcS3WWF3WXQ3Ve93Wc23Xa83Xbt3Vag3Yen3XfV3XhH3Ych3Ugv3Xj43Xc92iYu3W k13Zjf3YcU3WZ23ZmC3ZMJ3XiY3Zm63Ziu3Xn33Wkd3Zcl3Yq43Tnm3Zp53Zs83YdJ3aYa3a ot3aBcHYQd3YaZ3XkN3bpM3beC3YnX3Unq3ZyD3Wuu3cCFHZvm3am43Wo/3cbD3d/7Id3NXN orhd3cXN1T+923st3cNN3OEt3TEt3qF93LR920cd1VWd1dEt2uq93ZPt1OXN2lst37ON3sL9 ot+93PU93OQN3frd3U59EPft2m/d3gT+19w94QTO2pcN2LUN1uL928Gd3M/t3vlN4Q/u3Yu9 26Vt3YlN3Lz91rY91Qp+4Ygd3TE+45yt4q2N4QxO3tdN47bd4aGt4iBe3OEt4Mht4g4+46AN 44GN5IbN30be4u/936At2VRe5H5t3K995Bne1j2e39o92GA+5CTa1Oy91PQt1KUN1F8d02bt 5Hrt2GrO5ak953x91VcN4Ge+3uyd4GtO0/H953Au31G91P9irtGFbtIgcuiI7iHKveiO/ug4 Qg+QPumUTtHw+RCX/o28mIuxWYVmB3ZsqYl6iZIYYYCXfp0f8Z31uOrEpxHFxhGeiekhEetK ZpHoiT+ZTmi8uBDaqZ142HUmKOuX5+qVKOz8N+ukOHkzWJM5mOsZSJjzR4Oo+OzBTmu7Xu3Q jjvteWjyaOw1R3bLTu3mWZLE/u0FyOvInhKluO6mGZCwnu0XKO3qTu15qWTXXu9clztXOZpn d5RGOIV0SJsBGZT0bu7KfvD2BmXz+JoG7+7QOPBr2eoKH/FCKZGdbpD1aJJw2H/8vm8E/+zh boIWie+8l/H9NmwYf4kmT+6X13v/k0mFQLjujintSSnwjRec+J6XAd+bQ/jqbGN2cBiJDF+G RP9yRQ/0SC/vpgnsDs/sw87s7dmcR8/xRU95rwn1w97075n1KD/xOZ/0AO/1sqn0CO/wJC/u xf7plcjxSH/ywQ70JL97WT/1TS+IVP/1wSf2RN/2dB+bTp/wWJ/zRkOAf3/0NF/sU9/2Pg/3 BS/xe59oYM/uVf/tit/y+nbtaj/37qjzVs/19c6Y9Gj47Aj3jE98IX/2nt7rrQ72on/3iI/6 nl/1Sa/xA+/zpv97JLnwk7/7pH9rZU/62r76r8/6RBn5rW/u247tqO/6xv/3Nvj0sd/5lO/1 si/yZL/4/9Qv+LHf/HNv9sJP/XNo8Iy/9dFv/OII/BJP/Jwv++Hv/V8P+R34+dHf/dUv/IXv 7DhC/gm//+h/97O//QDx7x8AgQMNFkR4MKFCgQQbFnR40OFEhRQZRrRIMONDgxY5SnyI8eNG kRA5kgz5seNJliA3moxocmVKlTFrsqRY0uNLjQtbMrz4s2fLoTZz/pQJcmZRpTxVViR6VKhP qlWtXsWaVetWrl29fh0IYKLYkCLJhh07Fq1YtmHdstWoFm1SiG3Lnq2bkSxcvm3t+sX4d29c vg3TJoRrOO5cxmfxFlasGLBbw4hj9l28dq3dp5sjf+acF3Rg0Y0xTw5NOXVfhP6JRxaG3HEw ZdqM3x6uLFlw5Me9aWc2LdcmWOLFjR9Hntzq8OHKvzZ3Hl36dOrVqUK3nr3kdOzZvXvt/l38 ePLVmZdfjl79evbHw7cnvj36e/jk6dfHn9976NTq8eoHMEDx/hOwuP6QI7DA8Q5UsEEHH4Qw QgknpLBCCy/EMEMNN+SwQw8/BDFEEUcksUQTT0QxRRVXZLFFF1+EMUYZZ6SxRhs9XOBGAWNj DTDCfOztMseC5G0wIY1icC7mdkpwoR8Dwy2xyYp0rUr+jNzsybz8wso144xajsjP6qrqwCSV u6+1JYeq78z0ePSpSc3kBO8/IH3USkzwTNxOp6T8HP7JydYQGzRQQgsF6s/mwEz0UKhuelS+ PqGS71GlLAX0OrrSu07IMmEC1VBO4/zUwC8dpTM+sNJEdVNBX720y6vOa6qzURvditUKJ221 M14PpVXUYG1F1FZGZRW20GAf2/RYWDP91dVi87wVV0LNkok+7LY91dRmpdNV2qyiJRVWccst dVpnu6y0q3An5PXXnf4kdVFE2x3WXDVhIgzZZOm999J5pwVY3mwJVletIblFWFBsU0rVWoVH q4zL3KbcjTRInRyyqcxm2+0t205i08yAQebXUZp+i9IxX1W2tt7XKgaZ2RF55O8izrxslE01 vcQ3TujsrTVmuuA8Ot6Krv7c1+GZlrYz5zCjQkpfbSlNOWaGRS66Y6awJnmpjQO+TSKnuv5a UbHNBbrilZsWWaqzXV2XVbmJoqldDy9DyueB+UZXZXIlDvxnvP0NKnFlD87022ufbtwjo+/6 u9r35n1Y63R5+uvgxkJFW3KiuzaUc5drK1hzuqkuNScgw9YXqHVnzbvzpWbfe3GnV1cc5qMB brjnx0k33GJIAdd96XNn7zh1aftdTXbPNQ0+2cyhPx3duUsvGnKc+h6eeEBfSrpXn9l+FSXq pXrKU4Lr7vTY7MvS+dwNAUfe2ZJ/Jzb/393H1fgORzv+4W96/iPTykaHQEvFqlV6qRrMusO+ /f7pjX/cI55LpiJA8mFQfGcDYfsYZ6z3HQ6Bdwthsc6nPwIOsHLEuh9kWJM0KQUJZ2uiUpZ0 aCWOHek080tfbDQjmRySrIYLG5qi+qUb28VPY7JJIJKglBvdjGlnqZphDmejGiwZaTF4UtKT CHSlw6Asaltc2MjC+MVK4YaJnrFhkVhGpp3tUE9ZjJ/aDmiziOmoQO9a1YsACcPn+NE8OzKk e+yXSAANMpAscuTkcsVI7vyRkoUk5CU1aSM3bRI9nfTkcbgQSlKW0pSnDOUoUblKVrbSlShS 5StlOUta1tJBsbRlLnW5S15SB5e9BGYwhTnMhfySmNTp46qSCa7m0f8tkqXZ5DKdI80E5umZ F6Im3D75rmumi5fdBFa1kjOwFnoLnPg5Z+y+gzt1irNDl3OX/dLZzgUdc5GPLCea6Fm9SYpo nvxEpu8Kh7gPwZMrFsykItvzTwWNsSdeK00XjecbTzHJbWUL2Rox+tCJRXSMZiPi+cp2sR9R zGIa24tHe2jSsHltiRBdTUe5RrMocrRlyqtJMzsn0zraBjNqJClIp7hRqFGRjFYsShnFVDI3 3qakr5sSFDeqpZSOaaZprClDP9m+r6VUgELVIOrM2FIT5g2DVZWLB+lo1plG0WNT4WLcyHq3 EbY0qWV9q+jmSsWL5VWBbutgrSA4MT89jJz+ukPrQz1HWLNKTmBgfey9FOtA8eG1r90brAO9 GsG0KYcH64neECn4PZxMNJxmS+EU5RcVIDYOb9sLVJUOeFbQvI1nJ3ShCW3XpN02kFK7VRpq RTin047We7A1HOm+yr45Ee16tU3U+IAYVuoyN1K5dYlzReswrfpnuIzaHxQLS7bFVla55qva aqPLuuxiDr1wpStzR3ddzFo2p4j968kEF974nva7pK0uX0WKV+M6BXnV3GCoMpe6wIo3ZWZZ YXnza9HFMQ/BGnJsCINL2vCWN7Wvha996Ytf8HKMrdCirYHZCmAQfjiD5+XqiVnM4f+uTcUz Pk8SK7vcxq44wSv+Ful4KavZGpPNvSCWno13193yAK15qLHTa9i4JdWyETZpsdIWWSbDpgan eEcM47VQiiUvQzlLU+arUdNoRh/GVaOWubJnssbFJZZZjO7zzRprptShzuxnR9zzn81M0iUh 9XXGwl5z0+df8I2sbW+E06Brg0d7ksgh8QgPk+Gj6XjyCXiSxBCn91NpXRIkHkYTNWgDlGpV N/pm7yT1Lt0ESmxm0zq0zlBU+cRqZPI61r8GdrCFPWxiF9vYx0Z2spW9bGY329nPhna0pT3t XuqYn752j61NfNDnXI6h2mZXuLnDW2/3OaZC45kyRX3FPgOVXeCemrvu6NB6fgnb7Mn/dK7T jMmAJlR4BN2nQL058ExejXqbA5tve9WtUf/VtYtEqMAPTi2HfxqRA/W0OyUUcYr3W5LzJbjE Ay7y5+Vz4iQf1HNRPZ+tqpy3Jge4xseVcMdefOTw+iLNPqbUqx71zWjk6JZQR2fTXDRuOnmi maE0VKYGkWJFjGhRnSpFo+47sU/3qHM/9ubwVXDoi7XpRRfYUaDrvM4pB92BvSxBhd2Ua66r qfCeC5y4uxSwLkUZTjOKvXsrFK2xhe9kDTh3sopNr5GF4L7UxxTOrU1tnVVyWDO8V9iVePHK 6mp6ReW8w6Ld4TUnotHbvl6/Sv6yAaS5BDd/WeHo9ugnTuLc/g/fetWIHvZyNS/HHZRC4dK3 s7jFspTbS/VINTFbOxUM3S9v5CEeXy9alt3gZ6tN5EfZiMJP3rJEPFuVLzrElGW6bl/ofe+p a/X8yt7zbyyb6f64/FH/vsFCZ0TkTogFvM+861VY1xKD9N/jfxnpMSDWgx3mi70BcqttK7Dn ybwFMq/pY76EIy+v6x/yQy4Xy7+3AZ4OK7IDjMD+o8CSA7z8wq6vwhQkC6wFsxD8qy/qqrAN LKsBLEHOQkHTE6yDoysFq8EkU5/I4j8fMywE9MHyO7IXrLgK9K/tyb8b0ytaCUG1G8IgrL3c A5uaG63ueyv/I5/+ssG5GbCNuzIo/3sqMXIqy4Cm+gmOl1oTHiI6lQozJsKyQFO8moEzRWvD SVszNUwrn+qRNRzD0CM0MxQ0mxE0Q4OmI0mu5BspPIyz5hIiPzREd8Mqoau6PMvDMgxEKotE oJKS32jDjPmpPds5K9Ik3fMWULMkfyO1vrO5VOSQfNm0UrynU2RFhqtFRrpF/chFmduVmxsQ T8K1+IC3/AjGYRpGEDnG/UjGNjkjZqS2Z4TGaJTGaaTGarTGa8TGauwArHiBbPTGbzS2bgTH cSSmXewlcXxFq1LHN9m6WzNHbWKmproTMhPEddoWHBqQRdHHr5M3e3OkPuqPiLsPNOOmPhw3 DHtHYWwgU/9Mnk7DOFRUqI4Dl/PjPV/kRZHrP35rJ2tjNFXxyEjKN7/Zw3qkuH8UwpNrmFRL p25MyEJiJ10BvZlDSVVEEG7zON5xnIe0SZk8uWfaGoHTsWsyyZp8k67TFJikScvhyY2st+QQ x5bcEyiMscSDu6IjPkX0RLgBNK9auk/Ex6Z7PXXESpwcLpnROZr6Mql6O9JARKuER6zcOzN0 I6pMqtGjn2bKOsWrJpjiuuixIJHMwqrMmHwCy7wsuhgLKdjYsp0byatDmReoyriCSqHYR7lc wgmLMN9rNMYrPM58sczKLMcbMbJMMqExPB2ULMnzzI8qvoZEPATkKRqbNNRcPrX/AqzbG8Kq UzjNyjkYg6yeFLwktC8U6swuTK8lzDmXSTxXfMniikEJm77wKx4ZI67eCz4Eez76G7qHyxd2 8hi5Ca2igrCq4sHpOcPXhK4RnL/1kk7XsT7wo5z0bLCVGJw2IrAJIyTLCy1oaa2/M52uOp10 w8Dfaj9dfMSevE8i7MDhLEA+EsT6I8ALxC3fgZ/1uUHUQ7Kn8S0AJDLNjBWXo07P0zDtCUC/ gSsNBZUZ8sMBHNGTND8UjU7YbFDXCtAIStArRDliBErn9M0UpK0PtS3nZNHNlM3aHM2bqNDj 8cHJy1DPLE/Ne9IHTD3jfJbnVBwr7LElFcDSnCAeXb/5/3QcyHuhDpIvIcWvDv0wKZxM7mIW ARXFH9JDPEQqOPwzO0ur5BvFRHzTJ0uQsbQjc3tEUbwvywy+RpSztYupqJnTMytEPPWigBzE Qv3KZtSyUCTE5MI8+xSNR/0hO4suIoG+TKSz2wKjUmU6jKE6JFI6S1zGWUo6hCPHVuLIU3pV HIxVfLrUhbtVU1rT+9lLWN1VeeuylQrWUmpVXJzEPCrWZWXWZnXWZ4XWaJXWaaXWarXWa8XW bNVWfYs2M/mnVmVNcZtFiNTIbRvXibS3dyPWmUMjhZwmg5wVSu3DoSlGYU03ct0TYQRUfLww bfHJXq0kDEXXpdRJW+0ndMKmmf8kr93kFKFkue4Rp4pcWHSNyYb6Hg4cHH9xWEiCOaIkWIs8 v4u0j4Qt2B21yY0dWH/rTpNtSgoBk2h5OJ5EWUtL1s8ZM7VMVAXCuzsFTPKsLeGQ17frV+DA uznFM3obqbJTQ0WjsLgEo5SUy8qjH7esQ8ghrHazGpwqoRctHK50s1FtzDmUVKWlo7ZzOz1t y4VMUSSxqp3CzqK9y958IgihUcojOyAFK6RDQfDKTKFlUqEKzqYB0CP8qNljvdDswuS8UWcy TcvcseNLHMaCLMhjO9EkvZxsXNpbzc98UNNbzsPN0gnt3I1pR9R8PLxV0LwKXLo1z9m0zsQ0 1wArPvL/BMH3ojvOi8+TaaInFDN086AtxN3X3a4hQ0IJ+9K+YdEA1TUEZT8L49pP4aBDgxq1 C0L3xFL3a74jhZhmMa2Uc8DmHR4eE6x6bbUhq1EJVUCacAUA1NS/3UL16sEHkl8S9LMZxC4P vUz9Utja7VHOWj4r7FIjjJ0khV4P29p/KxiUolDuQ5iYnaz/y8lwtS7THVCArdIn5cIc7F/N bN+yNFL85c0Q5V0RRSyqDLEWZcGffNE0hU4YY0KltFy+IeBJ0Vwq/b35VdJP/bEb1rwH1j4R cl8f+xcWxld8S1ZF5FSgvUo5DBkbWjrokyhKmzo67NM50ih2c+I1xFmvNNs4//MiN+upOs3d Tb0zS+W50bAyNgzjQ6TDQeTDJ24z0YsqVRUwUCWzJi5cPrNitK1anxIrh7pXifq6tnRUKrZg YstFWFyoZ8O2Wu3Ym9xWQULYHP1FRvYu3XzkSLYl8n3XtDViaONkf1xH39XkUjblU0blVFbl VWblVnblV4blWJblWY61QwY4ajpWZTokfTVNOsnlsk3KCZLXMPzYxo2QW8Rlu+m2dDWPI05i dyNJXUYQPTnPX35YiGuTg224oBTZcyVehjNeVRxIbQYQTZgmwsxkfQLnhw2aF+vmmIvK9zvB B/HOpITkd/ZYCw05hdXna8bcjwNoiSyRfLu2dYrIlP8NwH/eZ4c0FZht3WYOMz7drMNsK0wk 2zjqU+VUKVKVTKzK6C5z0ESUui/WU8bpzebLuwMuy6IkZabq4qr1Wp2KwzSr2Z3dY1NdK8Oc syyuaEEGS5/92brbMpgO13++x+zEOreyY7s8xAsKum2WsdBcPOm7PeKM3NuU2tHVaNGsW4gF Tcgtz9Ra3cIjzXp+6K/Oav67vAwOXxLrK7a+HeFUauoE6sYb3OS1sc11HpUuTTMN3QrDUSGe wisd7F2uS7guVO4Fz/TzT6apq9wcMZF8TwAmU6rOzTh6XAxe4Octk4C07M4jRJKQ3q703h4y mE7MVA6MQvTLX8sz6RrFzuv/Q63b1d6VhVrPw9mcBdHrRLs26t5bE1rMC+dP++DGk5ge7LzI 7p293r7zhUC9PNPPFULbviepdO4The4LTWhre08YpF7SlWv11M3Jo10NBOAi9RXRLWuWJUGg xrEfPMrdTO6A5SAvpV9yalEilV18AV4N7moybdLVQ2wA49H/UT0RrLEF/K8aZmvyzuG7Os0N fu7qLXDzhGsrfWHmRtIDTzEdNNzuixz6xEmG7Jaj5bukfWIxNvHEbMxLhMuX1eM84+NIZTc5 enFMVVVLdTRDnVc2li2d9tQbZ+PptWIugzPPpimiTTqedWzPXnIyZM0qI7ql2lMlJlYyelos RlpT/51bFj9DAPLxOSPFbLZnj+M0W77kIg6RhFxTEp82NNfYSVZzhvYjN7e0VWsQO6flOjHH UD4oay4oQN8VQe+2Nif0PUf0RFf0RWf0Rnd0GOGHR5f0Saf0Srf0S8f0bAWDTOf0Tvf0Twf1 UBf1USf1Ujf1U0d1YmOGVGf1Vnf1V4f1WJd1U2eAWbf1W8f1XNf1Xef1Xvf1X8/WUAD2YR8m YSf2Y+8lY0f2ZbclZffGCoD2f4D2aJ/2aZd2axeIal8Ibb/2CpB2hOD2bq/2cQ/3bI92Zv81 ZxcQYGilcz/3b3/3ePf2a9/2eXf3eS+Idzf3b6d3eMf3fdd3dLcndb/Ge//P9n1HeH0PeIM/ eHD/935H+IgH+IcX+GMieGukdmqPeIaX+H7H9npPCIX/94DPd4qveE0ChVLOeG+3d3KX+IXH 93LveJF3eJ8g+ZPHeerQeJbf+Jav+Z8v+YeHeaCHeHDP+aP3Do6X95cXensv+ZCP+aKn+YZH +qq3DqWP+azveI/3+Z/PeKJn+Ju3+kqbgmkMe2sPd5kXd39venLHdm53+60f+7mn+7q3+7vH +7zX+73n+773+78HfBoxgsAnfEXnhsJH/N0TojrpbJKr8U3sY0zd5T9fqV30c8r/ZHfM3FzJ 5aLeN3Vz2YI8qq7EE2H2x0Jj3TLHyJ3k3b9caJD+XOcuz+edNOhFXmjarx4VLtkc3Vg4D+gI 9MSM3f1bUeThn/yDBlncVu1ZDR7YP8W+Hid8qn18w2eNC+DdV2Z4pnN4+VgVBF5x/si6Fugm wz4qzmmKmkPCwUKBdTq366Ks8kqtlUqqtUsmvlq+lTrHPTq2RHEm72U/AwgAAP4NLDiQ4EGB CQX+a9iQIUKCDhkenFgwIkKDBjNKhEhR48OKCh0+lIhR4cWKFjGe1LhwIceEKyOK9KiSJEea MD2G7PkSp0iTOE0GJbqxptGdH2MSFVqyZcufOodSrWrVIs+nMmkabQqT5M6qF0sWnSjWKtKt asOqNVuUYlOnN592hXv+UiveunTpwt06NKvdjj29ki3sFOzRuDzbKgarNeXgx4b9LmZsOe5K mWsP392M+evSsWwnU317WbBezij3Oi48Vm/YvJpdt3YrufHtuVd3A82LezbZkWVll+YrVKVu 1rUtjzz+mLJzxVmVRz/9OyRg3W859yZuuDFy4cm9N0eK3TNQwNGNd0Ru9vvp1RC7A2e8PCP0 6u/Xtg0//75+XpXn23sFdifYa/3ZRtxXqLEm1XYBcscbhTdFqOB363kHoIPD/YXWfgTqZ1+C eNl3WInXkfcgYgcCB+KGKb6oWnIYQufXXv9dNlyEdxl3oYgskbfdgBlKmF99JtZWnG870qf+ nIVPDqajkvAFJ5dogZEWYI/jUXhVlCt2SBiLmFU5pplLuicmkrihmSSKIbIZH5subvmXdTKS BueHZLZJp5wvrukne2+uiCN4UraIWptNVmljmuypR6ibBkpqZ6DOldXooAuC5qiPX4raHFaI oXSUfDWReupG50mV06lCsmpqTK3aBNJHoeWKnU6x0lpqrVzpKN6Uu9JK7HxR3sqrq+extKys uuInHqqZ/eeqrqROO6tPu2qbarEW5urtUo4l+1N5yyLr0rozXbtqtLGq2yqzv8bJl7zs5tTk sNfW2pd58NokKsEFG3wwwgcmvDDDDcPoMMQTRnzWxBVbfPHDXkr+jLHBGmvMMcghL8nbXB+L fHLDJqO8coUsf6nyxDC7PPPFHvZJc8u7yYwzzyQTHGbPQQs9dMLaCm000Ukr/bK/6e2sNNJL S12vzk1PfTXWWWu9Nddde/012GGLPTbZZZt9Ntppq7022227/Tbcccs9N91123033nnrvTff ffv9N+CBp+zx0zEXPrLDVtPNKr1Vv9az4hBHfvDkQs5cOdeYo6w5yZw/zTnNHwO9OZgUc1xR I2EfLqbOMx0t8uqYtp44wrFbynDhtlese6S7Zy26wid7WWPIvPPM++imUxc67JLfzmTKtdMe ce5QT9+81HadqxlIsDbe4rqjzQtauen+0uhTZk4X6z1U/jGrfbfxmy9s5Mq6vrz5m52L/r+L JkX1VOiXlgDOb1+wOk7J1ueSZxnLXQl6HPzqRS31lYuB3dseARVoLQe2B0IPfF75UgItDAaL febZGM5iIxorVQdRmTLNlgD1JghKJkutWSFXYrgmGSXGR4CKoPKElSPoKaUrjOIfjx6lIR+W 6FNH5BO+jmiuGu5JRPoz4gabaMXcUApSicLilKRDJtgEKYw5vA6ceChF48XMLcS6X6MmxCfK nBCBN8rUrwTlv9Voyln3upSb4lOkyoVpgSDEI5Im5cIBJctSQGLhjMB1M+69630meiOU1OMh DLVnZFQKjpb+7Hgv/kDJjdkpEHNcCMgLYZJKjyyS9YzUGTl95ixAvKO7YsSlG56pZI/r4x+H WKdhGqh+T9JOb175I10WMoqbxKOhHHQ+AP3SU1GcZjPHmM0UhWpRQenUF18YpG8qLDBeJJ4u I7W/aOKQjdSz5g/3o0pQ1XKNzIQmGosZQ2qWSU9iVJEMoadEfs5pn8AUJ5pyWUsgJQlRRGKR dbooJT3yckwn+ucK6aTRcaaxlwOtUZ4YtE+GlvFokkxXtfZlqwRiCV3jClj4vNc4xvWKhFEp 5qsig9KpzPSN47vdqqSFJ/cFC2BYkSR3GBfUBI5we7eiF7TAJ9RS0ZR9KhVXvqb+RVVUvapf bnTdOpG6LXZVMqwN3OlLm7ZSD5KPrTKtadTcxlLBCQ9u1Wtj2mz2NXfiDnJ0ZR7i/ooxvsby ZxYj7PGe5zXESs9lwhEsy+IK2cGCbrGeI6xkVVfZpWV2ZZ093WYnK9rRkra0pj0talOr2tWy trWufS1sYyvb2dK2tra9LW5z+9pj6La3vu3bdMDE2PvhqWPJs1ztQgs75fquNJ+z3WZBh7nh /ra6pSvYzqi7PFrmbHYLm6dfkVtYw/Y1sDd7mXXTy9mOYRd7MJKZyXSn3e8qlmh3pa95g+cz 9fJ3VE0V48CMFWDw3bSCbe2fNz8Yns6ERrw2xI80A9j/vp326jOxsWoef0qu9olXwgGe6gfp J09x8e+MGGZkieF1VT7atL+0pWiDfVhQeerwo9YMFGQslyccEniNv1wMF1soPwBTyqPrOSeP 01NjI44mNVC8YoNE6uQca/OLSXaxbAclQ0EGd0Rafo5stKNJR6bTgFK+6DdhGcdUngnCYKXl Qy3p5km6uUuXnA4jxczJQj62ojAGJiW/h+UsE5RErCuThS+Fy8jks5+gouSQuHtQQNazo9Ic jzkL1cOIEvGPnBolv/zMQu5uE5JCliVzB703YLx3l0weJtDS6EV7InKJIVVnm9ME5ErD2cZP FKY/5bLKku46kWc+FLCNjNCN/nrUflJUdZZVxasG92ulAFSqwFzaSACOFa5OAxdK3ZcvXLnH rBfUMFfBXccVv69H3YaKuWCKqwKvFVt8NJW6v9Wg8WVr2hj06bahzd/5nne/e60vCvl2XIMD F+EChzbB9fuwg2834Xqb66gAp9eHC/yzhhNdxGtWv1TXzePA8pvJOa7ylbO85S5/OcxjLvOZ 07zmNr85znOu853zvOc+/3nnlvqtb/vLaEI/qqqQdu9/e5Xp97bgUbc6b6BTveqm2xTiwKnj JGqazKjk0NfDHkyuH7niVj/7zrH+oeQ5+9m9xl+fAj5XuaPF3fQEL9rzjnO1lzt4bb9yPXUd 98B//z2ON2apnfWueJ4/vfHC9Ho7467vSk50iSOK+jFLSZuNL77zMccR6IfuSYOKWtKIH3XY gx2iRdqGm55/vcxBf95n8vKilUJnRZ9FZ51mjPXrczjsgw9xsV9an7Iju9ofr6EkIl9NYI+1 8KP/eaemSttKz07ST67UoUr7ORNUMbckiO/dm1365j8/+tOv/vWzv/3ufz/84y//+dO//va/ P/7zr//987///v8/AAagAA4gARagAR4gAiagAi4gAzagAz4gBEagBE4gBVbg3QiDBb4fLGQg B3agB34gCIagCI4gCZagCZ4gCqagCq4gC7agC/bXH7ygDNJcDM6gDcJcDf8KFj/sID84BA/+ IBD+4FAIoRD6IE7w4D/0oA/uIEkUYUMoYRIC4RJK4RMGIRVGoRUiYRYyYRMiYRUyoRdiYRJi YQ86IRFu4RU6IVVAYRhu4RBqoRVO4RieIReKIR0a4ReiYRa+YA5CVh1W4RhG4RMK4hqyIRQS IiAi4hfK4RJ2YSIi4iGCYSKy4SRCohJyYR1ioiHiISFqYiM64iRS4h8q4ht2ISV24iE+oieG oiqm4ioGIiRWYiaiYgv2oR+6YiTmYlVkoi5+IiwuIjA+oiUKIygSYzEOIy0q4iteYiS24hFu IimO4ig+YxN2ojMW4yr+ITP6Iiv+4jRqIy4a4wn/2qIOhiM3TuM1zqEhpuIUlmEs8uInSiI1 cuM8XmM29uIskmI62qM7EiM6DmI+yiM8YuM26iMyOqIWGqE06iI0/iMJkmM51qMysmMetuFE fqMglqEoQiMqfmMvFqIpFqEagqMqimMchqQXmqE5rmEsZuQ+kmFKFuQzXmEjJiRAriQZtuMN TtZCHuM/DmROzuQRuiQvAqUnsiNJ7uJHHiVHJmMgaiIYNiUyymM0UmQecmJM0uNA3mNU0iNR wqIaTiRYauRORuRN+uQp2mM8aqUYWmM3OqVEOmRS0iJQOqVMLuNKvmJJ5uMgVmI8SuVW3qVg gmRLiqVWkmVZ0hVToqUw/27lX/pjNzbkYPZlY1qlYSZjYPqiZL5kZp5lRsrkWFImZiLlZkam VL5lU84lYnZlYvaNHl4lTBalRkohEbalHEYlbbphRcombM4kM+Jmbq4jLi4kVM6mcMamHu7h Ip7kTYZlTipnUNIhaYaiccLma9Ik3CxBa27n1Vgmd35nbnkneI4neZaneZ4neqaneq4ne7an e74nfL5gcuqkHZoiIwalHcLhb4Zhb0qnbGInch5nIfZjb1bjbiplUd5nQjLnfL6mfeYibyZn cKJhO1IoftrkcgYodookVcbmbjajUFanhI6keIKgQF4iKOqlbZamXaYoiwYkjEKmW6qoXYKm Yf96ZCum5T1ipSy+qIs+Zkm+oyiiJh5i4mgC6ZF6Zk/CZZKG5o9O5Ua+pAnO5ZP+ojr2ZVJm 4zzq5TIqqZReZlUW6UfeKE4aqZEqozieI4vWI2h2aZgaKI0yZpM+JYguqZ2mpWkSZmPyI5va 6JSO6V9a5Ta26SZiaJ4iKYq65EHKqT8u6V6u6Y0Cop8qailq5qC+YZnepaTWZJ9aqZoeqkRy 6ltSp1KyYjPWpaVuKp+qIJVaKkYqqmrOppWmIT6e4qUu6qd6pUpioyWiY5aqqq/yJ1pSoXNe aK2KKW8qqLCqaZZSZLAma596JDhqI65+aH9yZIl+YKs2qisyYqzO4az/FmSzFqm3niaY/iSX CuhnVqpftmWwemplPqZlZiWiqiqliqWgMmRpnuFVUiVrHqNtSmqhhqRXQqmTFiYKbqtbRmOV kmmlpmuQHqtJjqk0IunCLmZcJuqoFmyuMilWEmrE4qSQXgVJdmaNNqo+nmmYoiqkrmqquqDC 7qiBuuzGnuxBauycAiyN4mWQ5myLviydcmLHuilqTmbQeuaVrqtoxqvNduYsqqjMAunTAu1k Pq3RniCHEqc7Cit/Quh0VmVYhm1MniqAFih+ViPXtiFw3qFv3qc3jq3YFqeGUmvaau2Hjihz Wqd+qqTdzq2s9mvAPmeDqq3c4q3CxqfX6IKq/zkk4lKg4kIb4zYuBD6uwC2r5F4u5mau5m4u 53au534u6IYuewYhppLmOtJngLqtcmKooQ4u6dYnpqojcM4s4d4mclbof64tsUoidPJt157o g+rnx75ufUon6hougsouTQpncTroinbo70Ir4RIv7UJliPqt7s4n7mathdpnMEZubUFsyvKl li7s84or+u6pNTqtn0YtlVokqNaqrc6vQt7qmfJskt7px4oplqYvyiJkj5YqrGrsuIprR+4v 2CprjvLvm/Zs/B7w+m7k6Tbpan4ta4IvbZksw94vxTprgv4sXzKq+8blPtJtolKrQUZw/zKw ZjJq/tLvkwLquXJmpv8CbAvrqsQy7Wqqr7KCbNJerWqy6f/WJXGW68bu7KBOaniuacUOsAvr ZAUHoxSzq8EGbsEaZUsCbylasL1y8Fh6sJxyZah+JoEiZscSZKi+b76CMdoyMT4Cq3fWpvja L7bia+wCcNHi8XO+sJPiqNJi8GxpcBNrMdMOJe8K5rTmK0ripR/7pkXG6KQ6pxcPbIGKbRjX LYgipL82sEHmLScf7tlusLrmKh2TLFH6cCk/qh4T7LX+LitfaQVPL+pG68z+liB3KzCqMUse MrcKJRVrcOC+a47qaJx2aLuqbWiargtjrPd6Ku9+cQ2zq6MWcgqr7nAWajRPsNzW7w+/cS7/ Y2vakuxRXjFDcnMU02VNsvG/Zmsgu/FQWmzMuqsBHzMbrypg1rPKqqzHprA+63L1LnMSI7BV EK0/dyqvFnQmv6+8ZnOVViy9/iqiErAM97HIUrPsHmpPCvO/qtccIyUaczIDy2zUirD/NnLV riXVOnA/dzA3g2nTlrQ6E7POwvCbbvS4wnNC+68Of/QgVy2ejrBFP7Aw7yVGayoSC2ya3hb1 mm3Aem3bBm/q/u1Fl26/xqFUP7V/Zm8tc+/0di1B0mZTYzIUH7K5ijH3YvXebu9Z3279OnV+ ki7cWqvQxi0Zq6tXE29ah/JUO6/e7mH2wq1VJ/L3srPoFrZhHzZiWye2Yi82Yze2Yz82ZEe2 ZCtNNEy2ZdNMZV+2ZqNMZm+2Z3NMZ3+2aE9MaI82B8aAaae2aot2P6y2a782bEefCcQ2bde2 bd82bue2bu82b/e2b/82cAe3cNNfQAAAOw== ------=_NextPart_000_0003_01C6D9C2.C9861BD0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Sep 16 20:58:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOkz8-0004pr-HK for capwap-archive@lists.ietf.org; Sat, 16 Sep 2006 20:58:14 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOkz2-0001Fq-Gi for capwap-archive@lists.ietf.org; Sat, 16 Sep 2006 20:58:14 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 133511448043 for ; Sat, 16 Sep 2006 17:57:54 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1F15C430018 for ; Sat, 16 Sep 2006 17:57:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id ADEFB144801F for ; Sat, 16 Sep 2006 17:57:08 -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 9A3761448016 for ; Sat, 16 Sep 2006 17:57:06 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-6.cisco.com with ESMTP; 16 Sep 2006 17:57:06 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8H0v6TU009128; Sat, 16 Sep 2006 17:57:06 -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 k8H0v56W017695; Sat, 16 Sep 2006 17:57:06 -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); Sat, 16 Sep 2006 17:57:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 16 Sep 2006 17:57:05 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202801899@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on -02 version of capwap spec Thread-Index: Aca/uwxBHUIaBgYPTZ28fYPCQF6LQALDJVmwAAI/69AAAH0LAAACcGRwAGcectAAN0YZEAIqbiBAAOoGDfA= From: "Pat Calhoun (pacalhou)" To: "Puneet Agarwal" , , X-OriginalArrivalTime: 17 Sep 2006 00:57:05.0807 (UTC) FILETIME=[31D729F0:01C6D9F4] Authentication-Results: sj-dkim-7.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] Comments on -02 version of capwap spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: de672dd48bf7248e70d446cd2da63266 > > 10) What is the recommendation for 802.1P and DSCP values for > 802.11 Data > Frames? Do you honor the .11 QoS semantics between WTP and AC or > are all > .11 Data Frames sent at the same priority in CAPWAP? That's an implementation issue. [Puneet]: I am fine with that. However, in that case, CAPWAP should define a CAPWAP control message for the AC and WTP to exchange their .11 Data Frame mapping capabilities and for the AC to then instruct the WTP to apply a particular mapping. Without this I am not sure how one can ensure a consistent QoS in the network. So if I understand correctly, you believe that providing guidance on the use of QoS is not sufficient, and that the AC must "negotiate" with the WTP on what values to use for control, binding management and binding data? This would be considered a new feature. > 12) It seems that within CAPWAP Data channel, there are > multiple 802.11 control channels (it seems that different QoS > levels are an implicit attempt at this > - refer to section 11.5). > General question to the group: Would it be beneficial to > transport these > .11 control channels as "raw" data channels in CAPWAP Control > messages allowing the network to honor the 8 .1p priorities > for 802.11 Data frames in the CAPWAP DATA message. I do not believe so. I think this would unnecessarily complicate the protocol. Furthermore, if you went down this path, you'd have to put the 802.1X/EAPOL protocol in that channel... what about IAPP? etc. The current model keeps the separation of wireless binding to control best. [Puneet]: My main concern is the way 802.11 Management traffic is handled today. It wasn't clear to me why we (the group) specified to carry them in CAPWAP Data frames. I would have thought that they would be carried in CAPWAP Control Frames as they would most likely be handled by the CAPWAP Control entity (and not necessarily the CAPWAP Data entity). Hence sending such packets to the CAPWAP Data entity seems like a waste and it would eventually need to be sent to the CAPWAP control entity. I think architecturally, I disagree. I believe that the CAPWAP Control entity handles the base spec - maintaining that connection and configuration with the peer. The CAPWAP Data entity, on the other hand, is the one that actually understands the subtleties of 802.11 (or whatever wireless binding). It handles the user associations, the 802.1x state machine, etc. Further, as I noted above, it becomes complex to decide what's management and what's not. Clearly, an 802.11 MAC management frame would be a candidate, but what about EAPOL? What about IAPP? This would require use to do an extensive protocol survey and list the proper destination for each. > 16) Section 4.1: Description of RID field is unclear especially: > > " WTPs with multiple radios but a single MAC Address range > use this field to indicate which radio is associated with the > packet." > > It would be great if this could be clarified - it seems to be > implying that this is used to support the case where > multiple radios share the same Radio MAC address but is not > very clear - is this the case? The point is that the BSSID is not sufficient since some WTP vendors re-use the BSSID across their a/bg radios. Since you guessed it, I suppose it is good enough? Any recommended changes? [Puneet]: It would be really nice to have a little blurb to this effect in the spec. Fair enough. Will create a tracker issue next time I have 'net access. > 27) How does multicast handle the case when the number of > WLANIDs is greater than 16 - how does AC indicate that to the > WTP? It seems you run out of bits in the CAPWAP data packets. The protocol already states that 16 is the hard limit. [Puneet]: If one wants to support (N > 16) WLANIDs (since the spec allows for 256 WLAN IDs), then the AC should at least have the capability to send N unicast copies of the packets to the WTP but indicate a different WLANID. It wasn't clear how this would be achieved for "802.3 Frame Tunnel Mode". Spec says 16, not 256. Don't understand the change request/comment. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Puneet Agarwal [mailto:pagarwal@broadcom.com] Sent: Monday, September 11, 2006 6:40 PM To: Pat Calhoun (pacalhou); dstanley1389@gmail.com; capwap@frascone.com Subject: RE: Comments on -02 version of capwap spec Hi Pat, Thanks for your reply. Pl see my comments. > > Thanks. -Puneet ************************************************************************ ********************** -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com ] Sent: Tuesday, September 05, 2006 9:15 AM To: Puneet Agarwal; dstanley1389@gmail.com; capwap@frascone.com Subject: RE: Comments on -02 version of capwap spec Finally got to completing my response to your list of issues. > 1) Section 11.1.1 Split MAC > " All client data frames are tunneled between the WTP and the AC." > > It is unclear what is meant by Client Data Frames - is it only > 802.11 data Frames or does it include 802.11 Management/Control > Frames also? The rest of this section discusses which of the management frames are sent to the AC. So this specific bullet item is about IEEE 802.11 Data Frames being tunneled. Would you be satisfied with a changes from "Client Data Frames" to "Client IEEE 802.11 Data Frames"? Being tracked as issue 210. > > 2) In Split MAC, are 802.11 Management Frames sent in CAPWAP data > frames? Yes > > 3) If (2) is true (ignore otherwise), then what is the CAPWAP priority > of these frames? From the draft: 11.6 Quality of Service for Control Messages It is recommended that IEEE 802.11 MAC management frames be sent by both the AC and the WTP with appropriate Quality of Service values, ensuring that congestion in the network minimizes occurrences of packet loss. Therefore, a Quality of Service enabled CAPWAP device should use: 802.1P: The precedence value of 6 SHOULD be used for all IEEE 802.11 MAC management frames, except for Probe Requests which SHOULD use 4. DSCP: The DSCP tag value of 46 SHOULD be used for all IEEE 802.11 MAC management frames, except for Probe Requests which SHOULD use 34. > > 4) In Fig 5, "Split MAC Message Flow", why is the "Probe Request" from > the Client sent to the AC also - even though all the processing was > done at the WTP for this message? In order for the AC to know the client is probing. > > 5) In Fig 5, what is the semantics of the notation: > "Add Mobile (Clear Text, 802.1X)"? > I could not find the 2 parameters implied by "Clear Text" and "802.1X" > in the > description of Add Mobile in section 4.4.8 or in section > 11.9.9 (IEEE 802.11 Mobile). Ah, this is a bug. The -02 document changed to utilizing the RSN info, but the section you discuss did not include the necessary changes. Created issue 211 to track this one. > > 6) Section 11.9.9: "If the QoS field is set," - which field > (where) are you checking for the presence or absence of the Qos Field? Another good catch of a change that is missing as a result of splitting up message elements. Created issue 212 to track this one. > > 7) Radio ID, WLAN ID, BSSID - is there an implied relationship between > these various configured element ie many radios to one WLAN ID etc. A BSSID is assigned to a WLAN ID - so there is a 1:1 corelation there. A WLAN can exist on one or more radios on the WTP. > > 8) Assoc ID vs MAC Addr for id (which takes precedence or do you need > to do both checks) Assoc ID is only used for power save - and is defined in the 802.11 protocol. When a packet is queued on the MAC for a domant station, its association ID is included in beacons to notify it of packets sitting on the queue. The station is identified via its MAC address, not the association ID. > > 9) Section 11.5: Please state clearly that even though these are > 802.11 Control Messages, they are still sent in CAPWAP DATA messages > (at least for now). Actually, these are for MAC management messages, not control messages, so the header is incorrect. Further, your request, while valid, needs to be handled in another section of the document. I will make this clearer. Created issue 213 to track this issue > > 10) What is the recommendation for 802.1P and DSCP values for > 802.11 Data > Frames? Do you honor the .11 QoS semantics between WTP and AC or > are all > .11 Data Frames sent at the same priority in CAPWAP? That's an implementation issue. > > 11) Should 802.1X frames be sent with different QoS than > regular 802.11 Data Frames? What is our QoS Philosophy for > such control traffic? One would think so, and we should possibly consider this. Created issue 214 to track this issue. > > 12) It seems that within CAPWAP Data channel, there are > multiple 802.11 control channels (it seems that different QoS > levels are an implicit attempt at this > - refer to section 11.5). > General question to the group: Would it be beneficial to > transport these > .11 control channels as "raw" data channels in CAPWAP Control > messages allowing the network to honor the 8 .1p priorities > for 802.11 Data frames in the CAPWAP DATA message. I do not believe so. I think this would unnecessarily complicate the protocol. Furthermore, if you went down this path, you'd have to put the 802.1X/EAPOL protocol in that channel... what about IAPP? etc. The current model keeps the separation of wireless binding to control best. > > 13) Section 11.1.2 Local MAC: The spec defines capability to > tunnel Client data frames as 802.3 frames between the WTP and > the AC. It would seem that the CAPWAP Data tunnel (as > currently defined) would need to carry both > 802.3 > payload (for client data frames) and 802.11 payload (for RSNA > Key Mgmnt frames). Is this capability really desired? You are correct that 802.11 MAC management frames may be sent, but normal user frames would be in 802.3 format, as you had earlier requested on the list. Figure 7 on page 101 makes this clear. > > 14) Section 4.1 CAPWAP Transport Header - It seems that this > section should be renamed "CAPWAP Header" or all references > in section 4 and other places should be updated to be "CAPWAP > Transport Header". Correct, for consistency sake we should make this change. Created issue 215 to track this one. > > 15) Section 4.1: The RID field here is 5 bits while in all > control messages it seems to be 8 bits - this needs to be reconciled DUP issue, and already taken care of. > > 16) Section 4.1: Description of RID field is unclear especially: > > " WTPs with multiple radios but a single MAC Address range > use this field to indicate which radio is associated with the > packet." > > It would be great if this could be clarified - it seems to be > implying that this is used to support the case where > multiple radios share the same Radio MAC address but is not > very clear - is this the case? The point is that the BSSID is not sufficient since some WTP vendors re-use the BSSID across their a/bg radios. Since you guessed it, I suppose it is good enough? Any recommended changes? > > 17) Section 4.1: I assume that implementations MUST support > 802.3 frames as well as "Native" frames in the same CAPWAP > Data Tunnel. Is this true and is that what we really want? That was the agreement in a previous thread. > > 18) Section 4.1: M bit. You mention in the text that "this > field MUST NOT be set to one in pkts sent by the AC to the WTP". > > However, when you are transporting 802.3 frames, won't the AC > need to indicate to the WTP what BSSID to use when sending > the frame (or is it assumed that the BSSID is derived from > the dest Client's MAC Addr for unicast)? good catch. Will fix this. Created issue 216 to track this one. > > 19) Section 11.9.1: For Tunnel Mode == "802.3 tunnel" in > Local MAC mode, how are RSNA frames converted to 802.3 as > they seem to be required for Local Mac They are not. see above comment > > 20) In Local MAC with 802.3 tunnel, how are 4 MAC 802.11 converted to > 802.3 > without loss of info? Ie do we need to define TX-MAC element > also (in CAPWAP data frames from WTP to AC)? They are not. If you need 4 address, use 802.11 frame formats. I think there's a point where it makes hacking the protocol to support every possible frame format become more complex. As an aside, TGs is now working on a 6 address format - what will we do for that one? That said, most applications use 3 address format, so 802.3 covers a broad range of applications. > > 21) In Split MAC Mode: when the WTP does > encryption/decryption, please specify the exact fields that > are valid when WTP sends such frames to the AC (as they are > now pseudo-802.11 frames after potential 802.11 reassembly in > the WTP). will do. Create issue 217 to track this one. > > 22) Can the same WLAN ID be assigned to different radios with > the same BSSID? Yes. > > 23) Can the same WLAN ID be assigned to different radios with > different BSSID? Yes. > > 24) For multicast pkts, does AC need to send multiple copies > of the packet to send to each radio on the WTP that is part > of the same WLAN ID or is the packet replicated by the WTP to > all radios that are part of the same WLAN ID? The purpose for the bitmap field is to avoid the need to replicate packets to the same WTP. Note that if the packets are centrally encrypted, then the packet needs to be replicated, and encrypted using the right GTK. So from a performance point of view, multicast/broadcast along with centralized encryption is the worst case. Of course, this is equally true if DTLS is applied on the data plane. If the packet is encrypted on the WTP, then only a single copy needs to be sent, with the right bitmap. > > 25) Local MAC with local bridge is the default mode - this > implies that all implementations must support this config > (which has the most complex s/w for the AP) - is that the > correct default and why was it chosen - should this be changed? It was discussed during a thread. We needed to pick one. > > 26) Why is the MAC mode and Tunnel Mode part of the WLANID > config? What is the practical reason for allowing this per WLANID? Some vendors want the behavior to be different across WLANs. Sometimes tunnel, and sometimes don't. The MAC Mode probably should be done on a per WTP, IMHO. > > 27) How does multicast handle the case when the number of > WLANIDs is greater than 16 - how does AC indicate that to the > WTP? It seems you run out of bits in the CAPWAP data packets. The protocol already states that 16 is the hard limit. PatC _________________________________________________________________ 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 Sep 16 20:58:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOkzd-00050t-0k for capwap-archive@lists.ietf.org; Sat, 16 Sep 2006 20:58:45 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOkzb-0001LE-IQ for capwap-archive@lists.ietf.org; Sat, 16 Sep 2006 20:58:45 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 208F3144805E for ; Sat, 16 Sep 2006 17:58:40 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 20097430018 for ; Sat, 16 Sep 2006 17:57:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0B1E31448029 for ; Sat, 16 Sep 2006 17:57:11 -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 D90A11448022 for ; Sat, 16 Sep 2006 17:57:07 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 16 Sep 2006 17:57:07 -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.20060308/8.12.11) with ESMTP id k8H0v7oZ032014 for ; Sat, 16 Sep 2006 17:57:07 -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 k8H0v7Yp017982 for ; Sat, 16 Sep 2006 17:57:07 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 16 Sep 2006 17:57:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 16 Sep 2006 17:57:06 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20280189A@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 161: Ther term "Mobile" is not really accurate Thread-Index: AcbAz9IJJQbXmUm3QLyFamlwrGJF9AY2uPaw From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 17 Sep 2006 00:57:07.0064 (UTC) FILETIME=[3296F780:01C6D9F4] 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-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] Issue 161: Ther term "Mobile" is not really accurate X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f All, We've had many suggested terms to replace "mobile", but none of them appeared to have concensus. I'd like to restart the discussion, but include a comprehensive list of all terms and see what folks think. It would be useful if folks did express an opinion on this one to help gauge consensus. First, the options that seemed to have the most traction: Mobile Node (In addition to the above issue, this term implies support for Mobile IP's client side support) Mobile Unit (one more variant of the same) Second, the list of "others": Station (some feel this is too 802.11 centric) Mobile (a wireless device is not necessarily mobile) Mobile Device (has the mobile issue, but no references to Mobile IP) Mobile Host (similar to Mobile Device) Accessor (A device that is accessing the network infrastructure) Wireless End Device (captures the essential nature of the end device) Mobile Station (Same as Mobile Host, IMHO) Mobile Equipment (Same as Mobile Device, IMHO) User Equipment End Device What is your preference? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From matho@joeross.com Sun Sep 17 03:20:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOqwa-0007Sa-L9 for capwap-archive@ietf.org; Sun, 17 Sep 2006 03:20:00 -0400 Received: from lns-bzn-61-82-250-72-113.adsl.proxad.net ([82.250.72.113] helo=joeross.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GOqwV-0006Fl-R7 for capwap-archive@ietf.org; Sun, 17 Sep 2006 03:20:00 -0400 Message-ID: <01c6da29$aab60e10$0100a8c0@belles3ge2hz6i> Reply-To: "Candela Norrell" From: "Candela Norrell" To: capwap-archive@ietf.org Subject: Re: my PHdfwARMA Date: Sun, 17 Sep 2006 00:17:34 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01C6DA3A.6E3EDE10" 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.3 (+++) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C6DA3A.6E3EDE10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 Q e UIT OV a ERPA h YI a NG FOR Y m OUR P j HARM h AC v Y =20 S z AV s E up j to 6 b 0 % w d ith http://www.zlesouylet.info =20 ------=_NextPart_000_0031_01C6DA3A.6E3EDE10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
Q a = ERPA h = YI a NG = FOR Y m OUR = P j HARM h AC v Y
 
S s = E up j to = 6 b 0 % w d ith http://www.zlesouylet.info
------=_NextPart_000_0031_01C6DA3A.6E3EDE10-- From zhohv@ewomennetwork.com Sun Sep 17 07:35:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOuw4-0003bo-6D for capwap-archive@ietf.org; Sun, 17 Sep 2006 07:35: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 1GOuw4-0003Lc-1t for capwap-archive@ietf.org; Sun, 17 Sep 2006 07:35:44 -0400 Received: from [202.110.106.114] (helo=[202.110.106.114]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GOuvx-000826-G6 for capwap-archive@ietf.org; Sun, 17 Sep 2006 07:35:39 -0400 Message-ID: <000701c6da4d$02b96800$726a6eca@AMOIC6FDF92A4C> From: "German courtroom" To: capwap-archive@ietf.org Subject: Blogma: Judgment Date: Sun, 17 Sep 2006 19:32:51 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C6DA90.10DCA800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 876202f9cbc0933cffbc58102e40f8f2 ------=_NextPart_000_0003_01C6DA90.10DCA800 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C6DA90.10DCA800" ------=_NextPart_001_0004_01C6DA90.10DCA800 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable sales hold ground price cuts analysts keep market afloat. revenue = decline. Oracle watched further growth Investors await earnings database = looking signs advances against industry leader SAP. Police blotter: When = cops run this weeks appeals court police need check license revenue decline. Oracle watched further growth Investors await earnings = database looking signs advances against industry leader SAP. Police = blotter: When cops run this weeks appeals court police need check = license plates Briefly: Plus: ExPalm boss joins firm... Adobe income = falls... Accenture buddy server seeks Solaris badge... This headlines gt = Daily Spotlight Featured CEDIA Expo: where theater Top reviews Injury = risk prompts recall Segways Canons block Simpsons Nintendo Wii set Nov. = launch U.S. EU scuffle police need check license plates Briefly: Plus: ExPalm boss joins = firm... Adobe income falls... Accenture buddy server seeks Solaris = badge... This headlines gt Daily Spotlight Featured CEDIA Expo: where = theater hybrid AMD chips Los Alamos labs system augmented brains. Hackers crack = music codes arms race continues find two leading digital rights music. = giants lure goes services providers their hosted computing Let there = optical cables included Sunlight Direct piping daylight into buildings = through fiber cables. Read PCWorld Chatbot George human friends Ca. gov. = limiting while driving Press iPhone clues iTunes Red Herring when = Gamings addictive highlevel executive leaving after also involving Grid project. Heres = good health searches Healia engine lets narrow based gender other = personal factors. videos: Apple harvest unloaded whole gunnysack stuff are spelled Try different keywords. general fewer your on can try = Answers for expert help with search. Terms of Service Privacy Policy = copy CNET News.com news and business reports Log Why join Password: = Remember Forgot password View my profile Today amp TVMy NewsMost Options = bf Last updated: Sep PM PT Weekend Edition comes to mobile phones Yahoo = slew startups tools that let cell content. is just WiFi away width reviews Injury risk prompts recall Segways Canons block Simpsons = Nintendo Wii set Nov. launch U.S. EU scuffle Vista Plotting Turning = corner Itanium What really about Has FBI ever heard How Media Broadband = Dell bc News.coms blog:s memory IBM change ideas thats been bounced ------=_NextPart_001_0004_01C6DA90.10DCA800 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
sales hold ground price cuts analysts keep market afloat. = revenue decline. Oracle watched further growth Investors await earnings = database looking signs advances against industry leader SAP. Police = blotter: When cops run this weeks appeals court police need check = license
revenue decline. Oracle watched further growth Investors await = earnings database looking signs advances against industry leader SAP. = Police blotter: When cops run this weeks appeals court police need check = license plates Briefly: Plus: ExPalm boss joins firm... Adobe income = falls... Accenture buddy server seeks Solaris badge... This headlines gt = Daily Spotlight Featured CEDIA Expo: where theater Top reviews Injury = risk prompts recall Segways Canons block Simpsons Nintendo Wii set Nov. = launch U.S. EU scuffle
police need check license plates Briefly: Plus: ExPalm boss = joins firm... Adobe income falls... Accenture buddy server seeks Solaris = badge... This headlines gt Daily Spotlight Featured CEDIA Expo: where = theater
hybrid AMD chips Los Alamos labs system augmented brains. = Hackers crack music codes arms race continues find two leading digital = rights music. giants lure goes services providers their hosted computing = Let there optical cables included Sunlight Direct piping daylight into = buildings through fiber cables. Read PCWorld Chatbot George human = friends Ca. gov. limiting while driving Press iPhone clues iTunes Red = Herring when Gamings addictive
highlevel executive leaving after also involving Grid project. = Heres good health searches Healia engine lets narrow based gender other = personal factors. videos: Apple harvest unloaded whole gunnysack = stuff
are spelled Try different keywords. general fewer your on can = try Answers for expert help with search. Terms of Service Privacy Policy = copy CNET News.com news and business reports Log Why join Password: = Remember Forgot password View my profile Today amp TVMy NewsMost Options = bf Last updated: Sep PM PT Weekend Edition comes to mobile phones Yahoo = slew startups tools that let cell content. is just WiFi away = width
reviews Injury risk prompts recall Segways Canons block = Simpsons Nintendo Wii set Nov. launch U.S. EU scuffle Vista Plotting = Turning corner Itanium What really about Has FBI ever heard How Media = Broadband Dell bc News.coms blog:s memory IBM change ideas thats been = bounced
------=_NextPart_001_0004_01C6DA90.10DCA800-- ------=_NextPart_000_0003_01C6DA90.10DCA800 Content-Type: image/gif; name="should.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c6da4d$02b96800$726a6eca@AMOIC6FDF92A4C> R0lGODlhoAJQAocAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAANAAAALAAAAACgAlACBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSCWuS8q0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrnrltseOdpx5Lnky5suXL mDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s17YrDewIMLH068uPHT LY4rX868ufPn0KNLn069uvXr2LNr3869u/fv4MP+Q4UlPpL48+gnmk/Pvr3C9e7jx4cvvz56 +vbzf8evv/9281P4J2B2/A2Y3xbWFWjgggw26OCDEEYo4YQUVmjhhRhmqOGGHHbo4Ycghiji iCSWaOKJKKao4oojlsHiizA+RESMNNZo44045qjjjjz26GNtQfwo5JBEFmnkkUgmqeSSTDbp 5I4qPCnllFRWaeWVWGap5ZZcdunll2CGKeaYZJZp5plopqnmmmy2SeRSbsYp55x01mnnnXjm qeeefPbp55+ABirooIQWauihiCaq6KKMNuroo5BGKumklFaqqB6WZqrpppx26umnoIYq6qik jvZIqaimquqqrLbq6qv/sMYq66y01mrrrbjmquuuvPbq66/ABissUukMu2KxxqqIbLInLsts ic4+S2K00oZIbbXYZqvtttx26+234IYr7rjklmvuueimq+662vLD7pRFvCvvvPTWa++9+Oar 77789uvvvwAHLPDABBds8MEIJ6zwwgw3PKYxDi+6ScRmhkLxxRgz+EnGHHfscX4lfCzyyCSX bPLJKKes8sost+zyyzDHLPPMNNds880456zzzjz37PPPQAct9NBEF2300UgnrfTSTDft9NNQ Ry311FRXbfXVWGet9db6WsP112CHfXQqYpdt9tlop6322my37fbbcMetJynLYSL33Xjnrffe /nr/8uETfAcu+OCEF2744YgnrvjijDfu+OOQRy755JRXbvnlmGeu+eacd+7556CHLvropJdu +umop05QNaq37nXrsMcu++y012777bjnrvvuvPfu++/ABy/88MRj10nxNR2P/EzKLx9T885H L/301Fdv/fXYZ6/99tx37/334Ie/GB/ie8QH+eVvdH76HKHP/vvwxy///PTXb//9+Oev//78 9+///wAMoAAHSMACGvCACEygAhfIwAY68IEQjKAEJ0jBClrwghjMoAY3mBkmcPCDIAyhCEdI whKa8IQoTKEKV8jCFrrwhTCMoQxnSMMa2vCGOMyhDncILGzw8IdA/gyiEIdIxCIa8YhITKIS l8hEMsmgiVCMohTdE5kpWvGKWMyiFrfIxS4+yF1eDKMYx0jGOz1DgWfMUBfElUY1hquNGFrj AuWoQDoi0I53LKO3dKHHOcGhj4AMpCAHSchCGvKQiEykIhfJSIewg0SMaGTAKJFASlDygJZE YCY1Kcmk3MGAdwhlKAcoyk920pCIOKUqV8nKVrrylbCMpSxnScta2vKWuOzQIAwiiALucoG/ VGAwEzhMBBbzgMc0YDJ9ucxcOvOZ0IymNKdJzWpa85rYzKY2txkxUHDzm+AMp9W0IU4xkaGc 6EynOtfZEUuw853wjKc851mZYtDznvjMQqc+98nPfvrznwANqEAHWhNhEPSgCI0IDBLK0IY6 9KEQjahEJ0rRilr0ohjdGgoyytGOevSjIA2pSFviQwWWVDIBAQAh+QQA1OMAACwAAAAAoAJQ AgcI/gD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJ sqXLlzBjypxJs6bNmzhz6tzJs6fPnwUJCCUwcKjRo0YNIhWIlChTof+IJk36FGrVolaHRn0K tKvXr2DDih2b0irWrVGdSnWqVK3bolzTxkUb16xWpnXfkt3Lt6/fv4Bvmp0r9+zBrHoN4y3M tnBdxnMTB55MubLly5gJDnbMebNhxHQ9y23cWS1Xt6RFZ17NurXr1ys3D55NGuvdtHZr407d OOtp271hCx9OvLhxh7J7K0cIerRizWuhSw+dnK3u49iza9/O127p6XQZ/kvm/Nn68vC+CXNf z769e5ygaU+XLx6u48S5I8/Xq/q9//8ABmhRU1QVuFRVdzUFHIK7LXiVfWuZJ+CEFFZo4YUY Zqjhhhx26OGHIIYo4ogklmjiiSimqOKKLLbo4oswxijjjDTWaOONOOao44489qgSBANBICSQ Ag1JpEFD/gOkkUEKqaSSThYZZZJHNrkklE4yKWWUWGK55JRGhpllkkFaGaaZZoopJpJkUonQ kWsSpKWXXqqZJpl0FqQmk3t+ySWaW+Jp558+FtrSn4QS2qSUjDYKJpyOVgllpItSaumTRTo6 aaOcEjmlnJJmqamilpKKqKdwolrpk6piiumn/5sqyuWXZcZKq56t2rrqrYb2utKpuL4Jqa61 3pprqMPOmiuxsAa7a5WySsrptMAeBGatzpYK7bGgJlTttJt2myqjiW7b6bLh+qpuSbyWKyyy 4GY6KarSbpnttc92We+3s6brL7jf/htpvZkqeymxrgpMrbnigsrwmNkifO2461Y8Urvwvkux qeQCiquyZ6ZrsJtsOjwnr/H6GzCp4c4pZ8snPzxsygt3a3LEIbtbqcF5ymvxzx7FHLG1+D56 pb0Ov3tuzR0fjTPFPaesM9MlJ/3xxsvimzDLIjO8KLJQAyzzzk4nDPTZF2FdZr/YFr2xzWG7 qrXWXdPMr6erCtzvyv4zx5q33K3SPbfNRBOusrQY31s3zDSjXZA5jkOk9rxZBz752IdfyrPO LN/tc8BkL36w23qGzvjpWxOc+b97m2763MdCynXF5kAeuUNU9rnny20K2ju0BcvaJZ0xRyv1 737yifzVdubZPPHDW1lnyB4HejOb5Ua7++6B+g6y98rfbvvt5Jdv4/jmp68+i+iv7/778Mcv //z012///fjnr//+/Pfv//8ADKAA+/KBgXzggAg0IAIPaJAFKnCBEIRgAyXoQAcKJIIMvGAC C7LBDf7Dgh9MIAYz+EAPGrCEJCRIATUIQg568IUkNCEIZxjDER5khSFcoQlz+MEcjpCBP/78 oQqF6EMiDhGHMBwgiFKYwRpqcIIu7GEILzjFG+qwgDHk4BOl2EQcKvCEW3QiFauYQjJ6kYlX jOIXqzjELfJwjA+MYxiRmEUzqtGNXrQjG7F4xTT2MIsw9GMXTzhINQLRjzQKh/rQuEYxrvGR bIxkG6fYxIQwEpJ7dKMeuYjIOU4Sj2cMpSYjWclKHlGOl+TjGB1JSiTesZObvKQc31jIMhZy koccpUW8oETjqBKUwPykJmVpSFXm8Y6thCIdcenKTXqSio4E5DIlmcon5rGCzjQlEIP5R1Ee c4fbfGYy6bjNWqZxmmW04y17qaFf7hGRtrymKDGJQhYeU5jEtP8mJG/Zx3u2sJuPlGYJrYhL faqQktnUoUGjOU4r1vChxJwhQrsYSHLe851nZCeHaNjIaWIyoheNpyTxOU9kprKZuYwiGqNp 0S+ms5os1GI5O2lKWnr0n+k8JUJ12VBoYlGPg1xmToPaTI1iCJ1I/agrQQrGUa6TpMLc5zzr mNI21jGWCvXkS6caVT4KkqsdbaRUbxjWqA7zmjZ9pkiHes6LGrVCSX2nLokKVR861aNdhaVS ufnVYsLRnE0FrF/hSE1x8pOZeBwrFGM50mRCU6199elc28rTtwJIhEaM4ASJaEEh0vCQ8Qxt SMFJWop6daCaDWIcbbhDu8a0qTwEbUv+X+vTz7r2n93sJwZdaNrUenW3RfRtKClKT8sa97jI Ta5yl8vc5jr3udCNrnSnS93qWve62M2udrfL3e5697vgDa94x0ve8pr3vOhNr3rXy972uve9 8I2vfOdL3/ra9774za9+98vf/vr3vwAOsIAHTOACG/jACE6wgp0LgAb/AwAtaTCEBSLhkwzg wgMwCIY3PJANe/jDCcHwPzLcYRELxMQn/rCIOaziFruYICuGMYhTTOIRX3jEB6kxhzV8Y4rs 2MYzBjKOZdxjILv4xyVm8YqRvOCPOPjBE2ZJhSmckiIXpMcozjCJsWzjEG9Zx19Ospi73OUi aznFJyYzjrH+HGY1o1nIaX6zleNMZiu3WSJsjjOX61zjEl/5zHV2s4zRbOYONxkkT6ZyhKGs aAv3edBr3jKk38xjGFOaz2Bu840L7edOdzrPdJZzoN38aFBT+s4QsXOfVW3pP7va04L+tJYl 3epDcyTRBJmyhB3M610PRNe+hjKEcT1hXlP4ybsedpSnzGiHzPnThJ50rC8NazZvms+E1rG0 ry3nLz8a2mWm9qRZrWQzW5vV1V71t7G9bXUjJM/clratMYLrYze714zGN77zXexhF6TfD+a3 vfWtbHs7e92jjjepEf7shaf52ue+s7uTnOlSoxjc3G74qScO71lje+KXRver5yz/8mkb2dvf 1vi8J1JvgQuc4L9GdsHz/e+YL1vmLw92RDS+ZziHnOHrRrfHPS5oTv98yGVOOclpDWeVmxvS HT+5uEte8hxbvN3vvvrSV66Rlu8b5l+/98ybnetcF1vsObeI0Ud9dE+DHOuR1vTVQ131TWub 2j1nt9XT3e2kvxrubfeyoal+d7yjWuVcj0iiC45zsDMe4IuP8q/N7nLHK7rlgnc40jXf93HL 2tDs3jrdQU50UIue9IXX/NP9vueGm9rwoDc90du+Y9GrGfGJh4jOgf34ZNvc98yWvLDLLmzg K/v4MT+4hyl+8YrTmMlG/rO5h65i6as74iCO8cVPbmci/ivd+963+6xRbvWlmx/M3F9+9NMv fucrOfcwwTxDhP8/hE8GCBixP/wbMoaMyD8h/qZE+gcY+FcRA7h/JKFzDfF/iVeAFQIFCBiB EjiBFFiBFniBGJiBGriBNVFh9KcQzGYQHqh7DBiCyldxR4Z7HPheONdoIPiBaEeCC8GAmedn mmZyKyhfizd58weDOyiDLzgRtsd5OWhfIehrwdd4xLaEx4eE/RZ5N2dwDTGEVVeE9LV7j0dz WvhvSRhwaWd5MTiFcxd4VnhfwJZ2vweAjTdwWQhzZJdqY0iEZaiDyfeFkrdvPEh2kWeHlQeD C1FohAd6c8iCAMeHkCd8LaiH/224iAZHg1A3e6p3gINIXsh3bJUodpcYcCb4hPyGh7w3dn94 ZM/3fNs3ifDnh6aYiikRgKrYilKGiq4Yi7I4i7RYi7Z4i7iYi9AVALrIX8nmdTcHiwgxgib4 EQFwjANxjLxIEMqIjM24jL04Xj9IeXUIhIkIEryYjf/gjNC4jc3ojcoYjZQojNT4EMQmhdi4 jerIjQfRjeroEa0gjm9lbMUXbPYoc6CIefhoc5ZYjQsRjgLBjgbhju4oj96FhZrIiGtYjpQH dn34EAApkAVBkAYpXvSoiC43fFuIjslHcE/oiAgRjhLJjBNZkeFVb3sYdnvIhQfhhh5IjiG5 jt44k/8lSZImCV4oGYVg+IbVeIg0F3Y8mRDamI1ESZPvmIz1FQOTiIW91pROuWzD+IkamYRR 6BAACY4BCY0UeZO+eBMFmYH4YIqsyJVkGZRleZZomZZquZZs2ZZu+ZYYkQ9wmV4KyI/m+Isw +RH5sJcDsZd8OZffVYz+OH+N6H8SIZeIKRB+CZiB2YMsl5cLeJj/kJhyCSNxwJiuUZeWyInD B4xm95FNWIlO6BCLqZiliZnb5XsNmYUb2ZMz15RoeI0LUZp++ZeoyV05qYiQ15KI2IIeKZsP cZqTWZm3iZud+ZoYyZtll4hnyJCkOZnQSRDEWZzWdZEdyZpmiZG+yZJeCJz/CEGZwxmd1Bkj CjAZglmP6OmCabiZxsd7/AiSplmZwjme7QWZaqiZFzGd9AlfY1kRd7ifIWEPhLgR+AmgwmEG f0EJBrqgDNqgDvqgCcYMEGocMjChFnqhGJqhf1EDGtqhHvqhIBqiIvpekjiiJvozEnCiFZii k5gOD8qiKjqBMBqjETijNLp/NnqjzBUFOhqBPNqjE3ILt/OjQJp7UUCkRcp1SJqk87akTHpo R/qkSiqlVFqlVnqlWJqlWrqlgHkIXPqlYBqmYjqmZFqmZqou/AAR/LCmDcGmZ5pdbvoQcaoQ c/qm1VWnDIGndjoWqoCm/+CmaxqoAyGoAsGmgmqo/4iapn8KqIq6p8uVpnGKqIs6qZRqqJOq qJKKqY3qqMkVqI0qqYXKqKH6p4v6qZCqp5yKXKY6qoBaqasaqpoKq6naXK+aqac6qrh6q5fq qrN6XIfqqYlaqsD6qbIqrIRKqb1qWbOQEZuarO4Fqc4aX6gardRardZ6rdiardo6FiewrRdy AuDareFqEeParR8RruMKEemKEOuqruA6EO3qrQnhBsbxrgJhrhRhr/b6D/iqEfrarw2xr+wK sAHLrwZrrgIrr+yxrwTrrvD6sBzxrxGRsAZBsQwhrgYLrw2rsNuhr/f6r+j6rgLbriGLrvwK sgxrshr7sScrri7rshqbsv/4CrIte7I2+7EAa7Ec27EYa7MSC7MEq7I3K7JEy7JFm7Ahu7I/ SxBHC7M+C7RAWxAkq7M7ix0ii7MSa7QDi7Bca7Rd27RS27VPq7VK+7I/C7U+W7Eju7FVa7Uz m7P9SrFvy7JD67RFW7NhS7d3e7Nly7deW7d+e7AZS7dtux4pe6+EG7iAu7h3e7QJkbV7i7Ro m7FgO7ZMK7gIW7jtsbZcO7IVi7ctq7LpWq4lG7dJG7MMK7V8O7qkO7dyK7OayyFsuxElm68p MbviRQW02LMiEbcSwbux+zNU2xFC67DBe7zIm7zKu7zM27zOWq4mUbwuYbLSC7rx6rxum7jE m7f/GYG7DnG4B7G22MuzlwsScOuv3Tu34Wu646sdrwu1pfuyWNu57Ju0pGu9RJu/84u3kruy +Iu17ZsdFtu4GKu/Z6u9B3y1YPu1diu/You695vA3msZZRDA/pu3WVu3rLu4/rvAoSu/fwu5 w3u4BGy5FlwcA9zAHXy+Gay3aOu0MRvCD3y9F1y5lXvCKDyzf7u6YsvACOzDjHuwPgy5HEy4 Njy5OJzDnFu7okuzrQvBBvy2nRvDrKu/iUu9Txy6H5zEXNzFXvzFYBzGYjzGZFzGcDnBZlwT 0Ku2s1u7ajy82mu7CrGu1ZvGMtHCTIu7eBwTVPvAFYG0l9uzNGzHfKzD/+u7EHsME30csTkb yIJLyDkRr3Q8xdxLszh7yVuMsjBcxTJLyaWLyaeruA0MuwAMyTbRxIC7t6U8tgqswiW8wEP8 wj08uSWsuuAbw1tsyqdMyvnbv5rMw6nsyvArwTw8y5arymysvnnMvrp8xx0czANbxCQcyzIc uLCMuCJ8zDD8uS7syI3czIVczcdcyXabtq8szOPMyrLczeeMwCvszWkLznyMv58syU88ybgc wfbrwE7cy2b7z1Z8z6ZrtqDLv3Asz++DxgZqDNr6AAj90BAd0RI90RRd0RZ90Rid0Rq90Rzd 0R790SAd0iI90iRd0iZ90ihthXyQ0izd0i790v8wHdMyPdM0XdM2fdM4ndM6vdM83dM+/dNA HdRCbSIVUNQVMBBGndRKndQGsdQCsdRK/Q9QbdQEcdRPTdVVXdRSndVTrdVdrdVcvdVIjdVS TdVfDdVlfdZjfdZWzdRXfdRW/dZbzdZx/dZmHdVpHddmndd3badgPdZiDdZwXddZfdWG/dRl jdSHLdaJDdiF3diI3diD7dh/XdeCrddtjdmKDdmTjdiZvdh6fdidfdmUrdmSHdqk/dhe/dmc zdqVDdlm+teLDduyrdqs7diBTdizXduv3dSWbdq1jdu3fdqbzduE7dq6/diijdxVvduzTdy2 Dd2pHdnG7dfH/dvKXRD/qe3Vqm3Ylt3a2h3c2V3Zn63bZL3bt13egH3d640Qsr3dw43bhQ3c 7J3Y8P3c3i3fZVrd8i3eec3V2I3Z7w3e4e3f7+3U/+3b5B3d1E3Wbi3Xdu3ev33g+A3bay3g yY3XDw7dBf7db8rf6C3h4B3g7X3h+r3WB0Hhy83YCh7inJ3fMB7iyU3bnS3dff3f3O3d5s3e C27hMc7i+43a2C3c823a4Z3djD3dcH3iNF7a7u3kUJ7bR67cNZ7iAU7fUT7dOu7bR97j4u3f H17eQ77iUN7bTe7ZZT7aGT7mSs7gHN7brx3nYr7Z483cZG7jiq3V0ADiZN7jUu7ZMw6map3g /2gd4V8t3F3N10492Gt+2aud6Hlu3JKe2XRN1x1u6Aie4Cau6FHt4J7+6A/u1mgN5kFN6kON IqZ+6kSd6qre6q7+6rAe67KuPvYpEbUugsJYjJuYk2cHlHeJh/T2kl2HirfejyVBlXZp7DVH oGfH7OcJgCGhmh6hjwW6P8WOaMM4g3nohdzOkV6naNSgezx47cveneao7dh+7JMHlVDZ7SLY Ebee69uOEvTX7tOe7epJEeR+I/3pEj547i1Zc+z+7u7uEPXedQQfmSAY7SrBig7Pket+ayxH mPluEgdf8YYZ8BiveLczll/3mv52hqPZ7Jgohcin6/i+nBF/b1S2j/+t6e4Ov5tQWO4tb5dO afL9KewX2ZzlvpAfz4aw+e4D74IfmPMuL/I/yXjrOZXffnm9h547v4Tc7vJ5WJVMX4fGpmsF b+9KaPNNuPGGQvIsP/Y7X/PdqfTNnvaXN+9m2fQB2O5qD/f9npLmroVvj+sdOfWFae6FuPZn r4lmf/Fpf/eA//d6H/BDD/MED/d8P+5vP/iFj4iN1pvB5/d1n/Xqifl1/5mM3+uBP3BOD/OV b/gPP/aOo4CM7/dcP+6qj2ybqfrQrvGsT/JqX/iXj++Dn/uguPhmv/kfefjoGPecn/Baf/tT yfoan/iSz4XT2O2p//yfT3z2TvSwf/i9XvT/LV/80p+GUMiZYr/5lm+PK+/7kfOfk3/+5I/+ wm/8VV/wbJ/50W/8pf/9yE/49C9/65/+5r/1te/xsd//APHvHwCBBAkOLCgw4UGFCR0iZMjw 4cSDEi0qrPgwI0KOACQ6jNiQI0iNIzdG/JgxpciOGFl6HNlSpsuYM1cupBmS5U6ePX3+BBpU 6FCiRY0KvVjw5MmSEEm2ZCoz5MeGVCeapCkV59OkWqOqpJhzq02SOrmW3Xrx69moY8VOzVoz JlOwZ+0a5LmxZlK9eNleras3K920Wg3fPFyX7FHGjR0/hhx5qMeKMCFOrZxZ6UDKnTl/9mxZ tGW5nhdSFom6I8zO/q1Rq36NcrRB2q03c04Jm3VtpZVv4yatOzRtjLmruv4MHLjqq8t7F9ec evbv4NOXI99tHLd0073NYu/Oe3fx4yiTM69u+/z455uDJ98eX7Rk+vXt38ef+mV+xlb5/wcw QAGJ8m9A/My6r0ADF/RJQQYfhDDCoqhycMEKJcQwQw0v1HDCuOrjsMMAQxSxRBNBJC0+DFM8 sUUXDyTxxbxYlIxGGUe08UYdd+SxRx9/BDJIIYckskgjj0QySSWXZLJJJ5+EMkopp6SySiuv xDJLLbfksksvv/wPETDHJLNMM18Kz7bYalszvfLaky87FedUbka/jtMox6qca0848WS7/s47 QaHbDjz01ASqO8cQ2+lQQPG0s1E96YsRPkIrzY85D9WTy9LyiItM0zbXROpRozD18Tuxmlqs tD1fZZVC/ZrLs9FZHVQ1LKx2jRUrBHnta7BV8/qwpwJT1BOusX61lVhnG0P1Q/PsQ7VaYRts dqZEf5L1MAJhPSraHXOFlVlyX+2211mLXZdWRrFV96lyz93L2GvJTTfbyeBldz9ltbX32f0W fawrWgvuL2FWBS42RFwHlpZAZr99Mld847XqTnDpdTVgNF2Sk9ty4/pVWZ1KfjZYdQ2G+Db2 NG23U39BpnlSmVdbzTfQWCOv0Oh4pg7cN0EDCdTxdHOPTt9M/t0YZOIwi/nO6vqcr+OI9+1r 6aPfc5JTRTVOE1lbM/a6YUkZvuvgdssm2WKTRLUoY6e+g1vsBr9qS9+b9/zXaH4hBhrvpNuS enB5Oz35aZfTxlmwt51C/NOc/NK4Z6IDs8tsoUnE3FuVm+QrrNAP96/0kZs7Vm9CDROZZF3R fWvYq/mGfNfR1eYbNtlb3lvewifu1/aiq5aK+MKLF0xuxk/mSndPm6p87YGXglelNotW/V3O 03Ke8neVvJ12zVnutytzPd7c273kNDj56QcDvl7pfhOe3T9XQszxqFv3lebTeLsZ8wDGPMLV j3KvWxbj1McoFhHwb90ijLMUIz/6/lkNMJGa1wWBFrSuwe5arjsX8MwHQkjJTIBr2Zbr5gI9 Fc6lb9ka4cL0JyzqAWx/Afud//bWvlWhECq+MyDrWLg8FBbxgmiJ3PgyF8TO5W2F2hNaywpY v94NCTmBattwZOM1GgnHZ1q83vPq5hrTKCgzY4SOZtDjneycMWWXSo96zHgop/UsN49CVhnd BKd1oOlr7DOaGrc2yDg97Yqro5ohLyO50TwHZqRij/zG2EZQ1Sk28JnaGg2FyENi8HHDWuPz znQjcXkoS+IqZcxGWaMWpfJM8VuliVxJMSuVcpZVjOWpXHRLMMEyl78cE8yAuSGbDdOYx0Sm lqQQITAk/9OZz4RmNKU5TWpW05rXxGY2tblNbnbTm98EZzjFOU5yeqmY/TlnghoZxXQmqp3m 5GWpTsW5ePbonSV80D1xB5l6vvJAuOvn5/4GrX0CqZ/B+8/3VMe/JVUoRrA8KEIFFNFcBjQo FlXlQnUJuoRCSKG8SyGTHGrKHQKIohetpXEC+TatsemTRCNP1pK2szjBUZE8a2TcouO/2eCF QpXMqRd3dkCXSW2dQ0Ma9YJa08s1cGkxxdPUmvozo2aROvN5Kpx2SkY6FbVxq9saS6+qU616 z5F7rOqcALnWP9WRpqOCqVrTCjc4GclxgTMcESFn1qj6FHtG3OsQ8WopAUa1MP5xtWPxgLie y/31hyusndZwtkDHQvapOkusUhPY2AEiMas4jd1hJ6ZZziYmsJ0D5VdbVSuiQnB5pAOsYokK VScGNkmPHJRiIgiV11xtKYAFVP6aR7wherC1qHOa8YqLt93W6XWxLWL3yLZb4ZaRg4m5q6Bu Qt0E+tCPaTshErWrvBfKB7nDPe/x1EtB6JaFvJb010kZlF1JCm+DE0TZY4ErXsEe8V7vmyxv gyVcKkawucrr72K860LjbpaGa1uvbbebPq+ENsC1uxV4e8jfn2a4uyVJVxPj66vfVS68m5Up 7L43rSPRdy1uC+3xNrzfCitYgcWdsYchddzFhvfFh/4Vb3Rfqz4NA0bEj62xi0X7lyC7ynSU PTHmUAtEk+nwv7XtbH3XVUAfH5HH4pOvgcJWVEPe7pJxDG6Zh8PGnmJyi0hTmnXOCslInsaO IfPimdmkZ8tZLs+Ky+PLBPlTNe05d3cGYCGH+serzpmQX0TkS9ls6JBNmqZk/piKCs21+em5 zofLMl8CTTcwYkaR9OtkOSsm0TBLqNX7ilIIofTqjqpam76k9T8KYaET5TqfsvO1mJEUbFtT SZjcMdCuxaxP/hy7oZ+uGLFRVGxqP0jZ1cZ2trXdpWtv29vfBjeTuh1ucpfb3Dsa97nVvW52 Qyjd7YY3uZ8cxYzqyNkSI/8pvrmFqXfPT53uzJSNiumoSIsy1eFiNsJNVbd5JvxuDeekU4Vd MGl7lKEGrWC4ao1LBA8UpOgLqcd7d6HU8SuHCwNcqAb0wsLW+4MXhzn/Ts6rXaIt1jG3p0RR 2mydJxHnPS8ovT/+sJC7fGYo/rnCeF1egSfd5iD/FtPt/XQhHc09gj5rXP846KsPboti5Dpj zQPURmf9vgSPLASpalNkp72ld+RgF/kKZ7A2/dL3G5sOfVryy+bUXXdunM7a2NXI0hzuXdWO oAV/XKluUHyFryTglzrVq1v9k3THe9VnOuAe+9Wy/RPtAac8xRpCVb+n/yp9OYu/Iiu5tILP sIH+0cVj11vNh6Zj+Qyde9+uu1a1TRTo42Xs5YYJboGABj6xcq8r2J9npqi3Oo19SUoF/izH kGWhG8VqPaeqzLq30p0eIy/707l09r8dv7+bTHPCYlVUk8vahM9L2WaxvHzLXWKegKtcE4J4 douNL/7TPu76PgCDPGkRwA1bGfTKmQXDOCL7MuNroSkzrSTyPlXKLjMTsi1zCzADNefLNN1C uc3rQP8jMgD8L9DjwA87GN87wSE7shIEFvaTv/4jMNebub8zwcJTQBubwdYDtX/RPAhkneay MBg7MOZLMN+TsiVDshWcLSeMwSJbLejTlioTotWKMCFssvICqQu8Qvr/m8LoEUEEccERqiHp Az39KUO9M6407DEoGzIMM6hNI6Q1A484i7S4SSQAkjs5WjyyWg+guqI8fKS26j7lWCc6qrsy o5qhuY7IYyNF1D5Mw6dILD6h0jROkyuqOrX2K7Tx4pTSEL9GPJs4k6pF8iqfGSpE+5St2iNG wqRBfEQyuqlLosWg65LpIxhdrDlfLKeK6zXqG7aPc7Vf4kWCAsZhXEZxEkZZmrpiNLr5GqZ7 oxSHExFrLDZsfDZ748YOYbgM+cZ4I8dyNMdzRMd0VMd1ZMd2dMd3hMd4lMd5pMdresZ6pJa6 0kdseRmTusdMC7id+iItOsWJOhZCW7aC7Ct+/7IlbBy4LkIoDjk1TOGqcQTIqvtHijM8oNsd WNOoV9ueTBnB2DJGWiq6G4qWkjPGJ3MlVGrGafS8VVTInXPJLKS6eRuRf7IrCppGA8y3egNJ k8xHDLwhjRJKkfs/pVvJp9O9n3RKpcw74VM+U2rJngwgqksQnSwSsGGYwaqaQMoqU2Sq9Umj QCFExcu48JM8Nzs83CpKtamqpII7nBq7RhPEpLpEocK8TtMq7IEpuayjoxLL52s8vyIVfRy+ x/vLxVFFvByotBLLvSyhUtu7srQOiZMsr3Sz52ulWrnI3qPCsIxDIWrC37PCMEy9yorClps/ //oY0eOpLYPNxcSszv/zoNQ6wbAkP7uRMM8qv9eEvimazBEcIMXxnMkpKcOqPZIszc86zbui PeQLPRnJL95RwxPDTTxCtiMLjeEZHj7soa/Exd8kSgqrvz5pwBUslORKTDCExNE0rwe7C+Ja lq/8nxhyrVIMopnhmPzaL+zUG+6rwfgzstlEP+T5Tg8zIlNrSnAcRZwUQ6TTMvprHj8zshvz N+68SNa0IJ6MPd+EoS48nezUsTj8hbyRut7Uj/8M0Y7hylaJnrmRIz96vwgFUOuUQR9EUb+c RbJ8QQX8sQ7MyIuD0OvswdHcUQyTvxf1riB1UvJsGihSodlizS4rDP/cneUsiF8gTTc8TSj/ ZDL8fJ8Y5MKYJE7feq0bRclQA1IlZJkkfEEjdcJx2T3nMjtb3LSsc0Uy2zo/xDM8wsVEZEWu ykWkGrVKcxSGGzwG67Q2C8VJTCTEpKtNtLQ08lPKzBdCXbO2U9SzJEh3gUhNgzA1w9NLRayy +sQ9HcQ+VTTMc9TaZEVMfLRCzTYWU8khDScuNSYITSZb9Rhc3TZffSN8hCZgvS0LHVZihTjC e09l3VVjBR858yRnpdZqtdZrxdZs1dZt5dZu9dZvBddwFddxnRJoXaVjs0j100ih+0yJNKmH Y9d3Xde7QUikuDtoiaeKdKhAk9UcURR1GsWXPEqJWbg/VFeOS6V0/825/tPKk7TKEd05cBzC kpQhjvxAjQOR/EMbkoTYrLQhYgSL4eOYkKrKKyE6j41YrGxRe83GiX1YhoW1kkXZoMsXD7VY lQsS1qvYiyVZnJ01aTWvaaHLglPLWnRVBnO8oLXEO7UJlRJaU+VMoJ08rPNTSmzaR/wfxOvK 1qKLtavXuarMfUwfFtOcpNycyjyqnoJVPvQTq9W6ldLLr+XXnZXRDJ1byKwpTbopz+SRKnUs 0lrNv0XOJNsuEzO9KLQdQLtQCWtDTwncyWo+3mPc1ZvDDvvMtwrNqBVc02xQlcoy8wQoODwt KTzbK53OHVuc0etIEMQ+v/HADHpcHhQc0P/CJYkNwtGRLmizmwhLTyxlL/dq0a5tIPbcwfY0 uATMHCT0zvS0yftrsONcot1FT7d9zPssT7M9Oq8II5Z609gU0PnjvLJMwRWlwd7SIAT73teN 0MtQ2I2bIft0QLlbv5bz3Rvk2yWEWcNlQfbCXRL9Qeh1Ii4UuiXNXBuCX42dlAnjVSnlx+sD 3wAdXNZ9YBX0ufflQR3LH/vFPfytsVTJ0jAF4TYtLO563hRE3CgrzjmdOZ3FXdG9wAWt3KuE YBs90idNsuq1LRICXVWJ3OdETflUQlKkMiCjIpxIzP8lYvua4PVFXFKS1j/DRFptVahN27AZ z1a0xdcMRd3dTEj/S9Q3I7SwbczL3DM+21Q5C2PifRNKwtMpNkU2DsRMhCPHzVNURSPCHE+1 RTU3OUw4w63pyGO5PTxRFVRL7TA+kyIy3mJJJFeBDQpe8MiblVd1CzZhdbqhbGQuuceaXZF2 q2RkveRMtiZtxBFBXBFzNRNShhGBNJb2FeVXhuVYluVZpuVatuVbxuVc1uVd5uVeRiZUjuSM g1dXiyhUEjhG7rNrlGCH3UM4ZlardGWeE0d6GliAWxSK0sSBPMxhxtcaiUWiReWPkuSZDWVW YlgzCubWwajnbdB4ded3lkaQO9mNU0adPJ8fVVmWRZiYjKHa7WR3fkaHmTgcQkqjPE9y//ZQ kuO4dO4gHIa6hoXKjL1e1yzoat6Ul+PQgBvUQPS8o3VayWoqy/xasVq0hWzFsRzMuONUkl7U unsL49w9mC5bip5KSdGtoBLUoa1iSJU4PSzpVOzjukxpVWTLM2tUxfWqkX5aoj5EVq5Zcc5d l85QtszbQTbDmgmz3ZStMA0dLMQr1U1Nv7Rc2ANrNkXNyxpcBdarE+bMDhXn2wxP2VWyHm7O IDxr7jFdAB5Q1OVO/dUs0qpQrkU9HGtNm2Wy0f08rHJDNhQoqPFnZfQexT4+yQUr5g0u6+0z EWS/AnMh3mRsFO1q3PSz7gnhI3VraBYm6R1h9fOx7f26Q+OOi//pzvMz3o20Xo7VbPNLnhY+ 0FA1YBwdYPK1s0G5FC+NbFlpT/N97IQZrAhu0ilNYuM7yPkt2/DVQbNmbOoGVS2TQNN+6p4k HxDkXbJhInZyXsJKObeoQRqkWxO7UZieIAPWaiEe35k27HqhGwtUQQqkndE606G00ja9YBil wrtGsuATb+99LuIz8NxGUzkFMAZKaHrr3g4OvsCQPRuOzeuTbNpzMBSsMgIuUQ0VYSCsb9F5 ywA3UBXz0iI2zOoe540CTzqbyDeTHEZtW7qL1D9dW1oM5O9CRUJ147iFRLXV104M5E/dxAJU tDemYlM+u0jSYzr+V7ETY6DGrAdlZUr/dbRPI1C0RKtB0qN9zOZNsuOeDmqyFcU9vMQldytO st3lFklHtugvScabg8YXuXNyBGZa2uQYf8pgAnTwYcZflHNfnpBoRqd+uoS2GyVVlhJIN0hz lXREB6ZGt/RM1/RN5/RO9/RPB/VQF/VRJ/VSN3VwW4NTV/VVZ/VWd/VXh/VYl/VZp/Vat/Vb x/Vc1/Vd5/Ve9/VfB/ZgF/ZhJ/ZiN/ZjR/ZkV/ZlZ/ZmN3ZCcPZol/Zpp/ZsqoBr/4drx3Zt 1/Zs73aB4HaWCHdvr4Bsb4hxJ3duV3d0B3dsr/Z3HxB3d3dzn/d6L3dvF/d7l/d7V4h5b3dz x3d65/d/93d4/zf4+9h3cP/3hff3gk94hT/3gQ/4had4gpf4g8d4ydj2baf4h6/4gP/2fBeJ hh/4gu/3i8/4lG+MjS93fV/3ind4fmf3jyf5iN8Jk1f5nDcKjm/5jnd5mwf6k5f4mA/6iT93 nUd6x/B4e4f5odf3kx95mTf6mof4pLd6xlh6mdf6jwf5nwf6jS/6h8f5qyf7m/f6cEf3mU93 gXf6df/2cXd7ri/7uaf7urf7u8f7vNf7vef7vvf7vwf8wBf8wSd8Tz84fZtJXIlFtANyR5dm xC9uB201RZenhCJvf650ay4+b+7zNr+oreNeL+ZmhbPcaDz0eA3JA/xwdlXJiP5JNf732UCf 82N86I2i2NbPZ3gu2c7X/fT21ZE16JDj5Nx/fH6q6AZefV4NHltCGOxtftufKHE8fn02OtwP fmiO/R9RaA4U8c0m/vpLWnelfUDF3M0TatCs6QGH2emJ7KQ+Oz11zB5tQb8LvN5bxL0rXJJu VK+rS7SkauAEiH8A/hEEMFDgwIQICx402NAgwYgQFx6kGJGhwIUIE0Ls2FGjx40YGVYsmBGk w4wlMU5EufHhQ5ENJcasmFLjRZo1d5p0CTOnzZM5TwYlylHoR5EUQ6ZUqBLoyJBKb0odavUq 1pc9ifb8WNNkzItfrTp9uvWsWKw2nc40ypIr0rgW25Zcuf6VZ9iBVeh2fSv0rsK2QyeONUsY LGLDV5nCPcy3cVq3bOtGhVz5sOWZgv2y9StWc9fHbpcqnpvYrlzMfOl2Bkp1scSnRb16fty5 7N/Squ9Wzuo7q2jbiVU2jR15s/GgRdFGJps8NObG0cvajp6bd2aJVTK/xtkcNPDncWcP19rS uXTBLR2yJrt7eWrvy6n3NVr1+On637XG11999WfnGQdXduzVZ9dKqI1nFmTKiTdZbJSJFc5U D4p33W8Z5kZegxHuh99188mF4YCDWbjhc8H115qEHh7o34so0gRVXwoOqCKHuCGoIIAEtlbi ecLBxyFIN66o34wghsVVdwxiR/5kjz0y92GO5VnWHFrqLdnhcJrpOBluup3oo4Zllngkky7S pySN9FWJ3llvqihmlzUi2V92C+0Vo3Aypknibgu+CN6PbeYXX58SStkiodgxmOihFibInGMw 4hmlnaXROJqQfJq4KXJDZvrohaKFKF2MnJpZ5k06BWigR02t1Sp7VdVKkqsvHaVTqzIxlVes S/3K0U+xGhggsr7OVZesUQWLbLPrQUUYtbNWuytKW0ZLLKy/ztgrSd3q+mqt6xHrK7NSVesa t+c2m5a5uFK17ra6eussuxGmK66yQQqolJ/WDvusf/7+K6tXa+EK1parOvwwxBH7ZqPEFVts McUXP/6cscafdvwxyCH/Bh+cIl+cMccmq7yyxxkiyDLMMZMoM80Op1zzzCrfjDPPJpPccs8T jxw00R/v7GfRSSu9NMTgJu0001FL7fK/+U7NatVXXw21e0dr/TXYYYs9Ntllm3022mmrvTbb bbv9doYKwD033XXbfTfeeeu9N999+/034IELPjjhhRt+OOKJK764d+4VnTWrIUPed7nYTpzU 017brPnlI3Pe8eRmh17z6BpyXbLpn8vM8aSkh4e65G2rnqfQIyk9u+ka/wx7071jbPTGUuN+ Z+xgs77p6q8DXfzawyMNG5aPw+z8iMpX/Lnz1E85dNTZJ781hAsfNS9Pjv5v+9WuCDubPrUh Foa5+DuVDz/5nLGEV/vLUjypwtHnmlT5fCIvfyVnXZ8RIK0Cw74l9eo1/TsO+t6FLtfU5ks+ Mte5oIUtDE5lVqThFHU2GMGfWMR2qFGXAknIQWV1ECm7e5r9FvUk5EiqgIeCVJ1KeKDA2O5P 70NVimwIQBy2h4bRo81fTijE8LHoR4rKD8lU46be3CZSgNHUDatIpwfxsHGMcRCBdghFT0Gq PQfUjRYlcyUKqpGMN0xNF40IQ4bdJ0hPOlMQL/VAF6oHTf/LoQmbBKZQUSlVierO6FrHLf+h qY8VWqP4cBLFMa0JPOFq3B2PVUAhSdB9MmSTcv5a1MNQwo+PMmINDUlpxkZap5ArkqAd5dTK pYHxjJUsFWwAiEtmeSqHm+kUpcIExtYB6USO7BOQ9mcoJcLLmLxBpjALVj0/3tJJOwKVldR0 RfdlaVBn+mSRBtNHUXKphmF8JvIwhylAUZJ48SKVD7cnvTHmaTZyJJOlWGRIPxaomFvk55/q ScReQi+PxDymGOlUS2/CM0k4MqcWD2pFheLHVP3sZkD1qaRGldGN5yxSRxkqx0DJKZ7wbFTO iHYrA9YLYOz7VLoG2C6Hnq+DlqucsFaYrWQuLEk2Jc1N30UvaVmtXyc02ACXxStYdg2nPdVX /AR2yXc6LVj3Qdex5v7VUwHh1FgeHNZWY8own1K1k10t17T6p76o5hRqC2TrTn9aP6+WDm4v Y9z38MY57ckzbS8sG1+vN0+84oyYhGVZYIVnM+a97a9kS2zEIHu5MB0WsXWtrO4ue7bTiVNy mhUbZ8cW2tV9FnSlxSxqU6va1bK2ta59LWxjK9vZ0ra2tr0tbnOr293ytre+/S1wgyvc4ept lo5b2eRKy9XOYuy003MuyHikOej2MHVmKp1kiatdtSz2utOr3dFSNrx7qrS6U9vr7xi5vNpt 92HP4NkGcjvdVWUXj4aKHPckVl/B9vV2weOvfddrvfaW6b3DrV8J5ze+/NFPgUkl6lAzSP9T FyYxff3CpGFg0sVvqXWRLSwOhXWoVavNFawoJM5iRHi/BbsIgfZM0Pu+xMBKiRjCGBwxwHxr YOFaEi9U7KUdQRqaTI0zTkMOnzPtR0GUlpLGeZnh/dComF/60kgm1eVxE1IKVYUTiWNBqRiR LFLObLjHXCoUgXXLKIIespXkCXJ6EkpiQLI5V6BM1TMFeUc+vedVZ7xUHh+pSWxmFZdMEqRj jgpO6ESznGZeTSfTvNs10w6H3ywVQovs04ueMp905POF0OlKfDK5PDZSp6PGR9CCNprUVoLm EzN6X4x+spILNa+kbWtm7gD5Tm8eskn/CcxOu/pUAfV1qT095nj+Uvmk/iwpoJLN5WSv06PE 1mitBaVN8uZatiusV1BPnGN73WqsWL3RwdDqVXaJi3wxXalVKVPWDJaYxWeVJIw92EIkOTV/ UF2fTHaKQg2jld3nIyC+ZQrWCco0rintdnD3yzvuos2xEm8e8nKXOMdCvOP9FdnOLs48ZR72 rt7deIA97vHRGi2RIgd5cqn7N5bb+XA0VznOc67znfO85z7/OdCDLvShE73oRj860pOu9KUz vemWTeCg811Vrt54qUvd0TsZnlSFI9ylUJ/gy50u9o6LyMjpZC5ZPzQiw4qKUv6cJqVTHeqx 073ucjeRYVE0TJhaeXkMxOMD/wphvu//2e6GH3vZ5Z1x/mlz1kRyu6ZM7kS3W7TYDz885oUe 9Qaa/dL/ZLSf/bfoTPKK76n00Joyr3qkN3tfR1ymO/mN0TtDXtbGRvOCUr/63Q+92ViaZEVj H0YeEV6SHgs8xcP5HW3xvvma77s13973tq/992qvnu6pn0TpT9P53u851OFdrHIni4T88XrB Q+/ScMX7xQ0k6iWxmfLv07/+9r8//vOv//3zv//+71kQ/J8ADiABFqABHiACJqACLiADNqAD PiAERqAETiAFVqAFXiAGZqAGbiAHdqAHfiAIhqAIjiAJlqAJniBu5QAKriALtqALviAMxqAM ziAN8g0X1CAO/+agDu4gD/agD/4gQegBEA4hERahEeIcPyQhP0SEEjahEzbhUEAhFDJhTijh PywhEybhRUwhQWDhFTphFoJhFz6hGH4hGVrhGWrhFlrhGGohG5rhFZrhEnKhFKZhGXKhVXjh G6ZhFKIhGYZhHNahGsKhIFJhG9rhGR7hYQ3iGMbhF3bhI+ahHnphJDZiJbYhIGbhGlpiJVKi G1qiHoJiJ2KhGg5iKU6iIUbiKWriJoJiKDLiJfbhGoaiKlIiJ66iK96iLeKiI3aiKJpiLSoi XsEiIxajLbLiJRpjKmIiM3LiKDpjK0JjND5jMCYjKdJiMepiFaJiLBLjMU7jHJKiNv9GIy5m IzWyYilOozN6ozQKo+GwIzLGIjICoynCYhjOoS/WIzri4zaqIzhyYzl64jUaoj2e4zh+IjQW JCQC4yMOZEICpEP2ozS6IUIG4i4KZC/yojsiDjyu4zfK4R5aoz2Go0VSoT664khi5FUYoxji oTL6ojyCpDe25B5eJFaQJCQ25DjeIxtqJE+mJCGapE3eI1Fu5OJ0pDWuJDfKYR/uok7W40kG 4zG+pCSS40BGZTU64ilSZDxSY0Ui5TYyJBwapFc6ZB125VNm5Bt6pFrGpFEODj2q5C1aZU6q YleGo1nuo15WJVrG40lyJVvC5F8u5UEOZUnWZVv2YlZ2ZED/7mVM8iJhUmUjKuRbBs4qSqZG /uVeEmMuJiZk0mJg8mVhjuZcdiZWlqVQTmZEemYr+iRqmiZhOmZkyiVOAmZlWqYdHuIh1iRF gqEUjiUg9qYg/uFuQuU1FuQUDmch6uYsXuRW4uUkCici5iYmEudCliFRJiJzDqcs1iJ0bmdu YudtjudvfSR5nqdtmadrkQJ6tqd7vid8xqd8zid91qd93id+5qd+ts10FiUazmImMmV1+uFx rqWAMuUT/qSByqRxKiU/MmcV/qSDRmeA/qd19icihqVi0iGBTqd0aieDEieHPmhQemhYHueG 0iR2TuUnKmd/9uUMImQ6bqZzpuJn/5ZmZy4mNjKkT+ZlVsrmaialPH4maDZmXeblYC7jjZ5j ROJkIObojl4nlDapWb5ikBopjdroUC5pXO5kDkqmbEbojL5kOUpkZjaplGplbIZmN0apX6ok UqbjmHpiO76pY0qkmramm95ljopmNWbmOj6koMJklnZnoL7mPAZpDYIpSq7kZIZmbyrmn8Ip Nj4qWbLpTOJpPkKkps5pnsriR1LlZTZlp6KpTlpqokqqnU6qn2oip+ppqFbphl4qai6la9Ig o47iSFqqqOKlpN4hpRIkr66pkE5kTZKjrn4jmQ6rJCokSybngh4ome5og1ZotIpksBpqcxYl nuIhhB7oYf8+ZoJKq63yYK5m6hZmYq8+6ZauJmQe6ZKWqj8yY6/qI1Cio7oqK4n+o16aZ09m a56iolyeqrbaZkAC5lkKLItq6Cba67a2Y5LaKmh+6cDia0LqKb8OqayGaYp66apebJ/OqFQu rMX2KYxCqqLCa2DyqGHOJWUmZZJOqaDea2warFOaLGmm6g+e68Yq6aveqcwyKWJiqab+aNCK JdFC6SaKg2BOLMriqI7uJJp2aUM6rZBy6atSLTz2aM8+aFRSqcuCrQ5C60zio4GupUDSrHOe LdtuZbqOa1OubR4CJ4R26HI+LN2mbYG2bYGGKNrSLbgKqIcOrtwiKNx6K9kmIm//mm3Z+i13 gueHZujJ7ucAvizlXu7eWC7mbq7dXCvnfi7ohq7oji7plq7pni7qCs4ypO4iimfgAufiKiiF ym51BmdzKq6IViSAfqdLWiuFQufiBm/k/ivjHq7w7q5H8i7SXmiLdii3Em6sFu+KSqjjAuvv Aujz8qbsKmu+1ijw4i703q6KUif2wq568taZGmuR+qjImu/GEi2SZq2iYilmLq/S7uOeTu1V imLUsmqb4ijL5iT9tuypymmsMmti5mL8NuPPMnDMwq7JiqqZ6i+9imNczi79Gu3I1qlvPXA3 2mWxiisGm6pYZqz//iqdGmQ2eipBHvBhkrBhDuy03u/W/4ojWmKmx8Zpxc6jP87wqtbmofru yoIwVkowsv6vCtdoBUfw/F5lypZnA3NmAcuwvjZvo5avn8bstSJnuQZwyuou/36lDYuxvmbs wRZt1XotEkNszbZsrgLuxXrwsk5xVvxm+gas1MIsqTYskPKxbtamrDawAj9xB0fxzcooFc+t FScr3pYqTXJrX15o037qiXbn/qKqS7KtGfNtuvbjf6bpx4ovAdfvTWry20YnyYYxP74sSQJy ayLwpvpxJddtJuNtK3tntb6uLqYwccnxzY4lKUfhU14pusorExOw1IbkEoOqJVtrW7JoIvcr NC/jo3qtKbPxXbrxDjPsQ9qrNv/Da5WuMOMO8TIz8rzmawLzq5W+cCC7ahlXLTUHly9H6J2e KzD7KAiLK13mM1geZMlqsFu2bzBrqQlvsMrWsamGMBdnc2p+LC/j8CAbM8By5r+S89GGMkGv cUFb5PsSsz7Dc5rd8a7qbD9/qpEm7dOeMA975T9/LdQKdDSzszpiLWzypf0ytAC3sWpuMsb6 ZaFaNKLmdM5m601j82J+tMvW9FG75mUSMvq6rrfmbSMHrh+GKEcLZRX3reLCMeR+r1d3clcL Ly8nq4U+6ywbbvFGcjgLLiejNSrn7nP+LdoSr1UT796a47cS4nfSMp0a715Hta9W7yyHp1fb 9R/OtdtPcjDrLjZjN7ZjPzZkR7ZkTzZlV7ZlXzZmZ7ZmbzZnd7ZnfzZoh7ZojzZpl7ZpnzZq p7ZqrzZrt7ZrvzZsx7ZszzZt17Zt3zZu57Zu91ZAAAAh+QQAGwAAACwAAAAAoAJQAgcI/gD/ CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhHHknJsqXLlzBj ypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat2KUgfXr2DD ih1LtqzZs2jTql3Ltq3bt3Djyp1Lt67du3jz6t3Lt6/fv4ADCx5MWCSywogTK17MuLHjx5Aj S55MubLly5gza97MubPnz6BDix5NurTp06hTq15dMwXr17Bjy55Nu7bt27hz697Nu7fv38CD Cx9OvLjx48iTK1/OvLnz59CjS59Ovbr169iza9/Ovbv37+DD/ouvaWY8cHPm06tPiH69e/ft 38sfby7+/Pv48+u36me///8ABijggKaVQ+CBCCao4IIMNujggxBGKOGEFFZo4YUYZqjhhhx2 6OGHIIYo4ogklmjiiSimCBQtKra4F4suxmgXjDLWGBeNNuao44489ujjj0AGKeSQRBZp5JFI Jqnkkkw26eSTUEYp5ZRUVmnllVhmqeWWXHbp5ZdghgmgIGKWaeaZaKap5ppstunmm3DGKeec dNZp55145qnnnnz26eefgAYq6KCEFmooZDscquiijDZq0ymORirppJRWaumlmGaq6aacdurp p6CGKmqRqIxq6qmopqrqqqy26uqr/7DGKuustNZq66245qrrrrz26uuvwAYr7LDEFmvssche yU2yzDY7lS3ORivttNRWa+212GaLLCzaduvtt+CGK+645JZr7rnopqvuuuy26+678MYr77z0 1mvvlxHcq+++/MIVT78AByzwwAQXbPDBCCes8MIMN+zwwxBHLPHEFFds8cUYZ6zxxhx37PHH IIcs8sgkl2xyi4ycrPLKLLfs8ssc4wPzzDTXnGcWNues88489+zzz0AHLfTQRBdt9NFIJ630 0kw3bZEDTkct9dRUV2311VhnrfXWXHft9ddghy322GSXbfbZaKet9tpst+3223DHLffcdLPa SN1456333v589+3334AHLvjghBdu+OGIJw6WJYo37jhzbTwu+eSU581L5Zhn7pAWmnfuGRye hy766KSXbvrpqKeu+uqst+7667DHLvvstNdu+2cL3K777rz37vvvwAcv/PDr5UD88drGgvxH yi/fUfPObwR99BlNT/312Gev/fbcd+/99+CHL/745EemTfnoeyjExku0nz5D7S/x/kLxz6+Q /Pbnr//+/I+WTf8ATE4gAkjAAhpwLb84oAIXyMAGOvCBEIygBCdIQd41g4AXDGAGAbjB/nWQ fx/cXwj1N8L8lbCCKEyhClfIwha68IUwjKEMZ0jDGtrwhjjMoQ53yMMe+vCHQP4MohCHSMQi GvGISEyiEpfIxCY68YlQjKIUp0jFKlrxiljMoha36CNScPGLYPRJIcJIxjKa8YxoTKMa18hG JYHAdV5s42eGIcc62vGOeGycO/LIR+zdo4+ADKQgB0nIQhrykIhMpCIXychGOvKRkIykJBOk jfNNUpA4A2Am+7fJS3ryk6AMpShHScp6YaGUqEylKlfJyla68pWwjKUsZ0nLWtLtE7bMpS53 ycte+vKXwAymMBmliGEa85jITKYyl8nMZjrzmdCMpjSnSc2fbCE3cajmdtKhTbdRgHiY6KY4 x0nOcprznOg80yPSyc52uvOd8IynPIHDggDW0574BCLgPfu3T/71c3//nKdAB0rQgnIvmwaF GLcSytCGOvShYgoIADs= ------=_NextPart_000_0003_01C6DA90.10DCA800-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Sep 17 07:55:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOvFM-0001BB-50 for capwap-archive@lists.ietf.org; Sun, 17 Sep 2006 07:55:40 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOvFK-0006lg-EC for capwap-archive@lists.ietf.org; Sun, 17 Sep 2006 07:55:40 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 578A33980AE for ; Sun, 17 Sep 2006 04:55:27 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id A4C5E43005F for ; Sun, 17 Sep 2006 04:54:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7AB3F430C5B for ; Sun, 17 Sep 2006 04:54:59 -0700 (PDT) X-Greylist-Status: Sender first seen 00:01:01 ago Received: from mx01.sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by hermes.tigertech.net (Postfix) with ESMTP id 99195430C4C for ; Sun, 17 Sep 2006 04:54:55 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 17 Sep 2006 04:51:01 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on -02 version of capwap spec Thread-Index: Aca/uwxBHUIaBgYPTZ28fYPCQF6LQALDJVmwAAI/69AAAH0LAAACcGRwAGcectAAN0YZEAIqbiBAAOoGDfAAKfSNpg== References: <4FF84B0BC277FF45AA27FE969DD956A202801899@xmb-sjc-235.amer.cisco.com> From: "Abhijit Choudhury" To: "Pat Calhoun (pacalhou)" , "Puneet Agarwal" , , 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, HTML_MESSAGE X-Spam-Level: Subject: Re: [Capwap] Comments on -02 version of capwap spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0465808610==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 This is a multi-part message in MIME format. --===============0465808610== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DA4F.F2FCAA05" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DA4F.F2FCAA05 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Puneet]: My main concern is the way 802.11 Management = traffic is handled today. It wasn't clear to me why we (the group) = specified to carry them in CAPWAP Data frames. I would have thought that = they would be carried in CAPWAP Control Frames as they would most = likely be handled by the CAPWAP Control entity (and not necessarily the CAPWAP = Data entity). Hence sending such packets to the CAPWAP Data = entity seems like a waste and it would eventually need to be sent to the = CAPWAP control entity. I think architecturally, I disagree. I believe that the = CAPWAP Control entity handles the base spec - maintaining that = connection and configuration with the peer. The CAPWAP Data entity, on = the other hand, is the one that actually understands the subtleties of = 802.11 (or whatever wireless binding). It handles the user = associations, the 802.1x state machine, etc. Further, as I noted above, it becomes = complex to decide what's management and what's not. Clearly, an = 802.11 MAC management frame would be a candidate, but what about = EAPOL? What about IAPP? This would require use to do an extensive protocol = survey and list the proper destination for each. =20 I agree with Pat here. The current architecture hands it=20 cleanly. Sending 802.11 management traffic on the control channel would cause lots of problems unless the 802.1X and 4-way handshake were also carried on the control channel. Since the latter are carried in 802.11 data packets, they definitely belong on the data channel. =20 I think the real problem is that the 802.3 tunneling mode has not been fully specified. It's not clear how the=20 802.11 management frames will be carried in the data channel in 802.3 tunneling mode. =20 =20 Thanks, Abhijit =20 ------_=_NextPart_001_01C6DA4F.F2FCAA05 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Capwap] Comments on -02 version of capwap spec=0A= =0A= =0A=
=0A=
=0A=
            [Puneet]: My main = concern is =0A= the way 802.11 Management traffic
       &nbs= p;    =0A= is handled today. It wasn't clear to me why we (the group) = specified =0A= to
       &nbs= p;    =0A= carry them in CAPWAP Data frames. I would have thought that they =0A= would
       &nbs= p;    =0A= be carried in CAPWAP Control Frames as they would most likely be =0A= handled
       &nbs= p;    =0A= by the CAPWAP Control entity (and not necessarily the CAPWAP =0A= Data
       &nbs= p;    =0A= entity). Hence sending such packets to the CAPWAP Data entity = seems =0A= like
       &nbs= p;    =0A= a waste and it would eventually need to be sent to the CAPWAP =0A= control
       &nbs= p;    =0A= entity.

        =0A= <PRC> I think architecturally, I disagree. I believe that = the =0A= CAPWAP
       &nbs= p;      Control =0A= entity handles the base spec - maintaining that connection and
       &nbs= p;      configuration =0A= with the peer. The CAPWAP Data entity, on the other hand,
       &nbs= p;      =0A= is the one that actually understands the subtleties of 802.11 =0A= (or
       &nbs= p;      whatever =0A= wireless binding). It handles the user associations, the 802.1x
       &nbs= p;      state =0A= machine, etc. Further, as I noted above, it becomes complex to
       &nbs= p;      decide =0A= what's management and what's not. Clearly, an 802.11 MAC
       &nbs= p;      management =0A= frame would be a candidate, but what about EAPOL? What about
       &nbs= p;      IAPP? =0A= This would require use to do an extensive protocol survey and = list
       &nbs= p;      the =0A= proper destination for each.
=0A=

 
=0A=
I agree with Pat here. The current architecture hands it =0A=
=0A=
cleanly. Sending 802.11 management traffic on the =0A= control
=0A=
channel =0A= would cause lots of problems unless the 802.1X
=0A=
and 4-way =0A= handshake were also carried on the control =0A= channel.
=0A=
Since = the latter =0A= are carried in 802.11 data packets, they
=0A=
definitely belong =0A= on the data channel.
=0A=
 
=0A=
I think the real problem is that the 802.3 = tunneling =0A= mode
=0A=
has not been fully specified.  It's not = clear how =0A= the
=0A=
802.11 management frames will be carried in = the data =0A= channel
=0A=
in 802.3 tunneling mode.  =
=0A=
 
=0A=
Thanks,
=0A=
   =0A= Abhijit
=0A=

 
=0A= =0A= =0A= ------_=_NextPart_001_01C6DA4F.F2FCAA05-- --===============0465808610== 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 --===============0465808610==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Sep 17 12:28:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzVc-0007Z6-5w for capwap-archive@lists.ietf.org; Sun, 17 Sep 2006 12:28:44 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOzVX-0005p3-NH for capwap-archive@lists.ietf.org; Sun, 17 Sep 2006 12:28:44 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 8295A43190C for ; Sun, 17 Sep 2006 09:28:25 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4B10C430054 for ; Sun, 17 Sep 2006 09:27:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2BA3043190F for ; Sun, 17 Sep 2006 09:27:45 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 512DF43190E for ; Sun, 17 Sep 2006 09:27:42 -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 k8HGRgKb024591; Sun, 17 Sep 2006 09:27:42 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k8HGRgee024587; Sun, 17 Sep 2006 09:27:42 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Sun, 17 Sep 2006 09:27:41 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Abhijit Choudhury 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: [Capwap] Data and Control paths, was: Re: Comments on -02 version of capwap spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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, Several of the proposals for the base capwap document specified that 802.11 control messages and 802.1X messages were encapsulated in CAPWAP control messages. So, some believed (and maybe implemented) such approaches. It would be extremely useful to show the actual packet flows to compare and contrast "stand-alone AP", "local-MAC WTP with AC", and "split-MAC WTP with AC". I'm not sure this is well understood by the WG, nor explained well in the CAPWAP spec. Regards, /david t. perkins On Sun, 17 Sep 2006, Abhijit Choudhury wrote: > [Puneet]: My main concern is the way 802.11 Management traffic > is handled today. It wasn't clear to me why we (the group) specified to > carry them in CAPWAP Data frames. I would have thought that they would > be carried in CAPWAP Control Frames as they would most likely be handled > by the CAPWAP Control entity (and not necessarily the CAPWAP Data > entity). Hence sending such packets to the CAPWAP Data entity seems like > a waste and it would eventually need to be sent to the CAPWAP control > entity. > > I think architecturally, I disagree. I believe that the CAPWAP > Control entity handles the base spec - maintaining that connection and > configuration with the peer. The CAPWAP Data entity, on the other hand, > is the one that actually understands the subtleties of 802.11 (or > whatever wireless binding). It handles the user associations, the 802.1x > state machine, etc. Further, as I noted above, it becomes complex to > decide what's management and what's not. Clearly, an 802.11 MAC > management frame would be a candidate, but what about EAPOL? What about > IAPP? This would require use to do an extensive protocol survey and list > the proper destination for each. > > > I agree with Pat here. The current architecture hands it > cleanly. Sending 802.11 management traffic on the control > channel would cause lots of problems unless the 802.1X > and 4-way handshake were also carried on the control channel. > Since the latter are carried in 802.11 data packets, they > definitely belong on the data channel. > > I think the real problem is that the 802.3 tunneling mode > has not been fully specified. It's not clear how the > 802.11 management frames will be carried in the data channel > in 802.3 tunneling mode. > > Thanks, > Abhijit > > > _________________________________________________________________ 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 Sep 17 12:35:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOzcZ-0001wW-Fd for capwap-archive@lists.ietf.org; Sun, 17 Sep 2006 12:35:55 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOzcX-0007q4-SL for capwap-archive@lists.ietf.org; Sun, 17 Sep 2006 12:35:55 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 3580C4317DD for ; Sun, 17 Sep 2006 09:35:50 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1E9C5430054 for ; Sun, 17 Sep 2006 09:32:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 12A8E39802A for ; Sun, 17 Sep 2006 09:32:39 -0700 (PDT) Received: from web60316.mail.yahoo.com (web60316.mail.yahoo.com [209.73.178.124]) by zoidberg.tigertech.net (Postfix) with SMTP id 6D90639801B for ; Sun, 17 Sep 2006 09:32:36 -0700 (PDT) Received: (qmail 86421 invoked by uid 60001); 17 Sep 2006 16:32:35 -0000 Message-ID: <20060917163235.86419.qmail@web60316.mail.yahoo.com> Received: from [67.166.240.5] by web60316.mail.yahoo.com via HTTP; Sun, 17 Sep 2006 09:32:35 PDT Date: Sun, 17 Sep 2006 09:32:35 -0700 (PDT) From: Behcet Sarikaya To: Dorothy.Gellert@nokia.com In-Reply-To: <893AE265F4ADF94AB7FB26D31A788E41029E0CCC@mvebe101.NOE.Nokia.com> MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=2.329 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, HTML_40_50, HTML_MESSAGE X-Spam-Level: ** Cc: capwap@frascone.com Subject: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0676390765==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d --===============0676390765== Content-Type: multipart/alternative; boundary="0-29101783-1158510755=:86091" --0-29101783-1158510755=:86091 Content-Type: text/plain; charset=us-ascii I support the split. --behcet ----- Original Message ---- From: Dorothy.Gellert@nokia.com To: Capwap@frascone.com Cc: margaret@thingmagic.com; Dorothy.Gellert@nokia.com Sent: Friday, September 15, 2006 1:18:55 PM Subject: [Capwap] Consensus call on Split CAPWAP draft by 9/29. Consensus call on Split CAPWAP draft by 9/29. Hi All, The editors feel that there is WG support to split the current CAPWAP protocol draft into 2 drafts, a base draft and then a 802.11 binding draft. The chairs would like to verify consensus with the WG that there is sufficient interest to split the draft before making this change. This issue has been discussed at the last CAPWAP WG meeting during IETF 66 in Montreal where there was no opposition to this request, and limited support on the list. The chairs would like establish consensus on the issue of splitting binding specific details from the base CAPWAP specification. Please submit your opinions on this topic to the WG list by Sept 29th, for a final consensus call on this feature. Best Regards, Dorothy, Mani and Margaret _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --0-29101783-1158510755=:86091 Content-Type: text/html; charset=us-ascii
I support the split.

--behcet

----- Original Message ----
From: Dorothy.Gellert@nokia.com
To: Capwap@frascone.com
Cc: margaret@thingmagic.com; Dorothy.Gellert@nokia.com
Sent: Friday, September 15, 2006 1:18:55 PM
Subject: [Capwap] Consensus call on Split CAPWAP draft by 9/29.

Consensus call on Split CAPWAP draft by 9/29.

Hi All,

The editors feel that there is WG support to split the current CAPWAP protocol draft into 2 drafts, a base draft and then a 802.11 binding draft.  The chairs would like to verify consensus with the WG that there is sufficient interest to split the draft before making this change.

This issue has been discussed at the last CAPWAP WG meeting during IETF 66 in Montreal where there was no opposition to this request, and limited support on the list. 

The chairs would like establish consensus on the issue of splitting binding specific details from the base CAPWAP specification.

Please submit your opinions on this topic to the WG list by Sept 29th, for a final consensus call on this feature.

Best Regards,
Dorothy, Mani and Margaret

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

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

--0-29101783-1158510755=:86091-- --===============0676390765== 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 --===============0676390765==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Sep 17 16:11:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP2zO-00034l-8I for capwap-archive@lists.ietf.org; Sun, 17 Sep 2006 16:11:42 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP2zM-000459-PA for capwap-archive@lists.ietf.org; Sun, 17 Sep 2006 16:11:42 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 874FD3980CD for ; Sun, 17 Sep 2006 13:11:35 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2E50B430054 for ; Sun, 17 Sep 2006 13:11:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0AD55431B8A for ; Sun, 17 Sep 2006 13:11:05 -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 21E7F431B89 for ; Sun, 17 Sep 2006 13:11:02 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 17 Sep 2006 13:11:02 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8HKB2Be011516; Sun, 17 Sep 2006 13:11:02 -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 k8HKAvQl018751; Sun, 17 Sep 2006 13:11:02 -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); Sun, 17 Sep 2006 13:10:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 17 Sep 2006 13:10:52 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2028018EF@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Comments on -02 version of capwap spec Thread-Index: Aca/uwxBHUIaBgYPTZ28fYPCQF6LQALDJVmwAAI/69AAAH0LAAACcGRwAGcectAAN0YZEAIqbiBAAOoGDfAAKfSNpgARWxzg From: "Pat Calhoun (pacalhou)" To: "Abhijit Choudhury" , "Puneet Agarwal" , , X-OriginalArrivalTime: 17 Sep 2006 20:10:54.0628 (UTC) FILETIME=[616EEE40:01C6DA95] 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: Subject: Re: [Capwap] Comments on -02 version of capwap spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: ea4ac80f790299f943f0a53be7e1a21a > I agree with Pat here. The current architecture hands it > cleanly. Sending 802.11 management traffic on the control > channel would cause lots of problems unless the 802.1X > and 4-way handshake were also carried on the control channel. > Since the latter are carried in 802.11 data packets, they > definitely belong on the data channel. > I think the real problem is that the 802.3 tunneling mode > has not been fully specified. It's not clear how the > 802.11 management frames will be carried in the data channel > in 802.3 tunneling mode. Abhijit, The -03 spec includes specific language about tunneling 802.11 MAC Management frames within 802.3. However, data frames are not encapsulated, which means that you lose the concept of the BSSID. However, you can request this information via the optional Radio MAC Address header. I would be interested in knowing whether you believe the latest spec addresses this sufficiently (once it is made available, of course). Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ 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 Sep 17 16:22:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP39z-0006x5-Pe for capwap-archive@lists.ietf.org; Sun, 17 Sep 2006 16:22:39 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP39y-0007Bw-88 for capwap-archive@lists.ietf.org; Sun, 17 Sep 2006 16:22:39 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id D5C403980D3 for ; Sun, 17 Sep 2006 13:22:37 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 49D16430054 for ; Sun, 17 Sep 2006 13:21:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 33E7F3980AE for ; Sun, 17 Sep 2006 13:21:50 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3D55A3980AC for ; Sun, 17 Sep 2006 13:21:48 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 17 Sep 2006 13:21:48 -0700 X-IronPort-AV: i="4.09,177,1157353200"; d="scan'208"; a="322159313:sNHT36895108" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8HKLlaL005154; Sun, 17 Sep 2006 13:21:47 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k8HKLkwB002914; Sun, 17 Sep 2006 13:21:47 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 17 Sep 2006 13:21:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 17 Sep 2006 13:21:45 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2028018F2@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Data and Control paths, was: Re: [Capwap] Comments on -02 version of capwap spec Thread-Index: AcbadjPTFA9uuIAySzG9WzxAIu5/CQAH+9FA From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" , "Abhijit Choudhury" X-OriginalArrivalTime: 17 Sep 2006 20:21:47.0376 (UTC) FILETIME=[E6805F00:01C6DA96] Authentication-Results: sj-dkim-7.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] Data and Control paths, was: Re: Comments on -02 version of capwap spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Dave, I will make an additional change in figures 5 and 7 (with associated text) to cover your request. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Sunday, September 17, 2006 9:28 AM > To: Abhijit Choudhury > Cc: Pat Calhoun (pacalhou); Puneet Agarwal; > dstanley1389@gmail.com; capwap@frascone.com > Subject: Data and Control paths, was: Re: [Capwap] Comments > on -02 version of capwap spec > > HI, > > Several of the proposals for the base capwap document specified that > 802.11 control messages and 802.1X messages were encapsulated > in CAPWAP control messages. So, some believed (and maybe > implemented) such approaches. > > It would be extremely useful to show the actual packet flows > to compare and contrast "stand-alone AP", "local-MAC WTP with > AC", and "split-MAC WTP with AC". I'm not sure this is well > understood by the WG, nor explained well in the CAPWAP spec. > > Regards, > /david t. perkins > > On Sun, 17 Sep 2006, Abhijit Choudhury wrote: > > [Puneet]: My main concern is the way 802.11 > Management traffic > > is handled today. It wasn't clear to me why we > (the group) specified to > > carry them in CAPWAP Data frames. I would have > thought that they would > > be carried in CAPWAP Control Frames as they > would most likely be handled > > by the CAPWAP Control entity (and not > necessarily the CAPWAP Data > > entity). Hence sending such packets to the > CAPWAP Data entity seems like > > a waste and it would eventually need to be sent > to the CAPWAP control > > entity. > > > > I think architecturally, I disagree. I > believe that the CAPWAP > > Control entity handles the base spec - > maintaining that connection and > > configuration with the peer. The CAPWAP Data > entity, on the other hand, > > is the one that actually understands the > subtleties of 802.11 (or > > whatever wireless binding). It handles the > user associations, the 802.1x > > state machine, etc. Further, as I noted > above, it becomes complex to > > decide what's management and what's not. > Clearly, an 802.11 MAC > > management frame would be a candidate, but > what about EAPOL? What about > > IAPP? This would require use to do an > extensive protocol survey and list > > the proper destination for each. > > > > > > I agree with Pat here. The current architecture hands it cleanly. > > Sending 802.11 management traffic on the control channel > would cause > > lots of problems unless the 802.1X and 4-way handshake were also > > carried on the control channel. > > Since the latter are carried in 802.11 data packets, they > definitely > > belong on the data channel. > > > > I think the real problem is that the 802.3 tunneling mode > has not been > > fully specified. It's not clear how the > > 802.11 management frames will be carried in the data > channel in 802.3 > > tunneling mode. > > > > Thanks, > > Abhijit > > > > > > > _________________________________________________________________ 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 Sep 17 16:25:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP3CP-000852-Fc for capwap-archive@lists.ietf.org; Sun, 17 Sep 2006 16:25:09 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP3CN-00085t-SW for capwap-archive@lists.ietf.org; Sun, 17 Sep 2006 16:25:09 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 763EB3980B4 for ; Sun, 17 Sep 2006 13:25:07 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id BB51D430054 for ; Sun, 17 Sep 2006 13:24:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AA522431B99 for ; Sun, 17 Sep 2006 13:24:33 -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 E0FA0431BB0 for ; Sun, 17 Sep 2006 13:24:31 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 17 Sep 2006 13:24:31 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8HKOVoZ018162; Sun, 17 Sep 2006 13:24:31 -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 k8HKNGZR013368; Sun, 17 Sep 2006 13:24:31 -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); Sun, 17 Sep 2006 13:24:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 17 Sep 2006 13:24:26 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2028018F3@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Data and Control paths, was: Re: [Capwap] Comments on -02 version of capwap spec Thread-Index: AcbadjPTFA9uuIAySzG9WzxAIu5/CQAH+9FAAABHPoA= From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , "David T. Perkins" , "Abhijit Choudhury" X-OriginalArrivalTime: 17 Sep 2006 20:24:28.0331 (UTC) FILETIME=[467027B0:01C6DA97] 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] Data and Control paths, was: Re: Comments on -02 version of capwap spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 36c793b20164cfe75332aa66ddb21196 Oh, and I created issue 222 for this. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Sunday, September 17, 2006 1:22 PM > To: 'David T. Perkins'; Abhijit Choudhury > Cc: Puneet Agarwal; dstanley1389@gmail.com; capwap@frascone.com > Subject: RE: Data and Control paths, was: Re: [Capwap] > Comments on -02 version of capwap spec > > Dave, I will make an additional change in figures 5 and 7 > (with associated text) to cover your request. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > Sent: Sunday, September 17, 2006 9:28 AM > > To: Abhijit Choudhury > > Cc: Pat Calhoun (pacalhou); Puneet Agarwal; dstanley1389@gmail.com; > > capwap@frascone.com > > Subject: Data and Control paths, was: Re: [Capwap] Comments on -02 > > version of capwap spec > > > > HI, > > > > Several of the proposals for the base capwap document specified that > > 802.11 control messages and 802.1X messages were encapsulated in > > CAPWAP control messages. So, some believed (and maybe > > implemented) such approaches. > > > > It would be extremely useful to show the actual packet flows to > > compare and contrast "stand-alone AP", "local-MAC WTP with AC", and > > "split-MAC WTP with AC". I'm not sure this is well > understood by the > > WG, nor explained well in the CAPWAP spec. > > > > Regards, > > /david t. perkins > > > > On Sun, 17 Sep 2006, Abhijit Choudhury wrote: > > > [Puneet]: My main concern is the way 802.11 > > Management traffic > > > is handled today. It wasn't clear to me why we > > (the group) specified to > > > carry them in CAPWAP Data frames. I would have > > thought that they would > > > be carried in CAPWAP Control Frames as they > > would most likely be handled > > > by the CAPWAP Control entity (and not > > necessarily the CAPWAP Data > > > entity). Hence sending such packets to the > > CAPWAP Data entity seems like > > > a waste and it would eventually need to be sent > > to the CAPWAP control > > > entity. > > > > > > I think architecturally, I disagree. I > > believe that the CAPWAP > > > Control entity handles the base spec - > > maintaining that connection and > > > configuration with the peer. The CAPWAP Data > > entity, on the other hand, > > > is the one that actually understands the > > subtleties of 802.11 (or > > > whatever wireless binding). It handles the > > user associations, the 802.1x > > > state machine, etc. Further, as I noted > > above, it becomes complex to > > > decide what's management and what's not. > > Clearly, an 802.11 MAC > > > management frame would be a candidate, but > > what about EAPOL? What about > > > IAPP? This would require use to do an > > extensive protocol survey and list > > > the proper destination for each. > > > > > > > > > I agree with Pat here. The current architecture hands it cleanly. > > > Sending 802.11 management traffic on the control channel > > would cause > > > lots of problems unless the 802.1X and 4-way handshake were also > > > carried on the control channel. > > > Since the latter are carried in 802.11 data packets, they > > definitely > > > belong on the data channel. > > > > > > I think the real problem is that the 802.3 tunneling mode > > has not been > > > fully specified. It's not clear how the > > > 802.11 management frames will be carried in the data > > channel in 802.3 > > > tunneling mode. > > > > > > Thanks, > > > Abhijit > > > > > > > > > > > _________________________________________________________________ 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 Sep 17 18:55:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP5XW-0008KG-7I for capwap-archive@lists.ietf.org; Sun, 17 Sep 2006 18:55:06 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP5XU-0003wO-LX for capwap-archive@lists.ietf.org; Sun, 17 Sep 2006 18:55:06 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6A6553980DA for ; Sun, 17 Sep 2006 15:54:55 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id AD0EF430054 for ; Sun, 17 Sep 2006 15:54:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9B94B144800B for ; Sun, 17 Sep 2006 15:54:24 -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 BCD2D1448003 for ; Sun, 17 Sep 2006 15:54:22 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 17 Sep 2006 15:54:22 -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 k8HMsMQC032124; Sun, 17 Sep 2006 15:54:22 -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 k8HMsLYp020970; Sun, 17 Sep 2006 15:54:21 -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); Sun, 17 Sep 2006 15:54:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 17 Sep 2006 15:54:21 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC0208B4A8@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Consensus call on Split CAPWAP draft by 9/29. Thread-Index: AcbY82fx0AwmEjxkSO+bTrWL20FI8gBuMilw From: "Bob O'Hara (boohara)" To: , X-OriginalArrivalTime: 17 Sep 2006 22:54:21.0580 (UTC) FILETIME=[36D50CC0:01C6DAAC] 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.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_40_50, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: margaret@thingmagic.com Subject: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1374313076==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede This is a multi-part message in MIME format. --===============1374313076== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DAAC.36A79505" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DAAC.36A79505 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support splitting the draft. -Bob =20 =20 ________________________________ From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com]=20 Sent: Friday, September 15, 2006 11:19 AM To: Capwap@frascone.com Cc: margaret@thingmagic.com; Dorothy.Gellert@nokia.com Subject: [Capwap] Consensus call on Split CAPWAP draft by 9/29. Hi All,=20 The editors feel that there is WG support to split the current CAPWAP protocol draft into 2 drafts, a base draft and then a 802.11 binding draft. The chairs would like to verify consensus with the WG that there is sufficient interest to split the draft before making this change. This issue has been discussed at the last CAPWAP WG meeting during IETF 66 in Montreal where there was no opposition to this request, and limited support on the list. =20 The chairs would like establish consensus on the issue of splitting binding specific details from the base CAPWAP specification.=20 Please submit your opinions on this topic to the WG list by Sept 29th, for a final consensus call on this feature.=20 Best Regards,=20 Dorothy, Mani and Margaret=20 ------_=_NextPart_001_01C6DAAC.36A79505 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Consensus call on Split CAPWAP draft by 9/29.
I support splitting the = draft.

 -Bob
 

 

From: Dorothy.Gellert@nokia.com=20 [mailto:Dorothy.Gellert@nokia.com]
Sent: Friday, September = 15, 2006=20 11:19 AM
To: Capwap@frascone.com
Cc:=20 margaret@thingmagic.com; Dorothy.Gellert@nokia.com
Subject: = [Capwap]=20 Consensus call on Split CAPWAP draft by 9/29.

Hi All,

The editors feel that there is WG = support to=20 split the current CAPWAP protocol draft into 2 drafts, a base draft and = then a=20 802.11 binding draft.  The chairs would like to verify consensus = with the=20 WG that there is sufficient interest to split the draft before making = this=20 change.

This issue has been discussed at = the last=20 CAPWAP WG meeting during IETF 66 in Montreal where there was no = opposition to=20 this request, and limited support on the list. 

The chairs would like establish = consensus on=20 the issue of splitting binding specific details from the base CAPWAP=20 specification.

Please submit your opinions on = this topic to=20 the WG list by Sept 29th, for a final consensus call on this = feature.=20

Best Regards,
Dorothy, Mani and Margaret =

------_=_NextPart_001_01C6DAAC.36A79505-- --===============1374313076== 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 --===============1374313076==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Sep 17 22:26:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP8qB-0002pr-QX for capwap-archive@lists.ietf.org; Sun, 17 Sep 2006 22:26:35 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP8q6-00018R-Vt for capwap-archive@lists.ietf.org; Sun, 17 Sep 2006 22:26:35 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 31954398125 for ; Sun, 17 Sep 2006 19:26:28 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id BC7154300EE for ; Sun, 17 Sep 2006 19:25:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A96BF3980E3 for ; Sun, 17 Sep 2006 19:25:20 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 340F83980EB for ; Sun, 17 Sep 2006 19:25:16 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k8I2PDPS019299; Mon, 18 Sep 2006 11:25:13 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k8I2PEX20238; Mon, 18 Sep 2006 11:25:14 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with SMTP id k8I2PDF15352; Mon, 18 Sep 2006 11:25:13 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Sep 2006 10:24:19 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012775EA@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbY4CMB7agq4TySSwi0SsMRMuBTQgADSCsAAHay+HA= From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: c343632e7d969f32683dd165d9d1aa55 Pat, The issue here is about how 802.11i exchanges are done when authenticator is at the AC and crypto elements are at the WTP. This is the requirement. The proposal is a way to realize this requirement. Let's not confuse between actual need and stated requirements. We achieved consensus on the mandatory requirement because there is indeed a need for it. Given that this topic has been discussed for a while, I would really like to understand your concerns. What are your thoughts on realizing this requirement? Saravanan -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Saturday, September 16, 2006 1:36 AM To: Saravanan Govindan; capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations The "protocol" performs the function of 802.1X/802.11i without any issues in both the SplitMAC and LocalMAC operation. Are you stating this is required because RFC4564 states that flexibility is required, or because there is an actual need for this feature? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Saravanan Govindan [mailto:saravanang@hotmail.com] > Sent: Friday, September 15, 2006 9:00 AM > To: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > I want to emphasize that this is not an "additional" feature > - it is a mandatory requirement from RFC 4564. The protocol > currently does not meet the requirement. > > Saravanan > > > > ----Original Message Follows---- > From: "Pat Calhoun (pacalhou)" > To: "Saravanan Govindan" > , > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > Date: Fri, 15 Sep 2006 08:01:32 -0700 > > I understand the proposal, but stand firm on my belief that > this additional mode of operation is unnecessary. While it is > possible to implement, as everything is in a protocol, I > believe the WG needs to focus on fixing the protocol in the > areas where it is broken, as opposed to adding more optional > modes that really do not change the outcome of the functions. > > Perhaps what would be more useful is not to describe the > method, but the reason why this is being proposed. I still > fail to understand why you believe this mode of operation is > necessary. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > ________________________________ > > From: Saravanan Govindan > [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Friday, September 15, 2006 2:03 AM > To: capwap@frascone.com > Subject: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > All, > > > I wanted to give a more detailed explanation for the > IEEE 802.11i Considerations requirement. This note describes > how CAPWAP can be updated to satisfy this requirement > > > > I would like to use this to highlight the proposal > being put forward. > > > > > > > > From RFC 4564, Section 5.1.10 IEEE 802.11i Considerations > > > > Protocol Requirement: > > > > The CAPWAP protocol MUST determine the exact structure of the > > centralized WLAN architecture in which > authentication needs to be > > supported, i.e., the location of major > authentication components. > > This may be achieved during WTP initialization where major > > capabilities are distinguished. > > > > The protocol MUST allow for the exchange of key > information when > > authenticator and encryption roles are located in > distinct entities. > > > > > > Following the requirement, CAPWAP needs; > > > > 1. to incorporate authentication & encryption locations in > > capabilities exchange > > > > 2. to exchange key information when authentication and crypt are > > located in different network entities > > > > > > Basic case: > > > > AC does both IEEE 802.11i authentication and > cryptography. For 4-way > > exchange, AC tracks the KeyRSC, which it then uses for > Message-3, > > i.e., AC calculates KeyMIC and updates EAPoL frame. > > > > > > - > 802.11i Authentication > > - > 802.11i Crypto > > > (KeyRSC maintained here) > > > > +----------+ +-----+ > +------+ > > | Terminal | | WTP | | > AC | > > +----------+ +-----+ > +------+ > > | | > | > > | 802.1x Authentication > | > > > |<=====================================================>| > > | | > | > > PMK | > PMK > > | | > | > > Generate | > Generate > > SNonce | > ANonce > > | | > | > > | | > | > > | Message-1 > | > > > |<-------------------------|<---------------------------| > > | EAPoL Packet | CAPWAP Packet > | > > Receive | > | > > ANonce | > | > > Generate | > | > > PTK | > | > > | | > | > > | Message-2 > | > > > |------------------------->|--------------------------->| > > | EAPoL Packet | CAPWAP Packet > | > > | | > Receive > > | | > SNonce > > | | > | > > | | > Generate > > | | > PTK > > | | > GTK > > | Message-3 > | > > > |<-------------------------|<---------------------------| > > | EAPoL Packet | CAPWAP Packet > | > > | | | > | > > | | | > +-----------------------+ > > | | \|- EAPoL Frame > | > > Receive | > +-----------------------+ > > GTK | > | > > | | > | > > | | > | > > | Message-4 > | > > > |------------------------->|--------------------------->| > > | EAPoL Packet | CAPWAP Packet > | > > | | > | > > > > > > > > > > Case specified by RFC 4564: > > > > The 802.11i Considerations requirement considers the > case where 802.11i > > authentication is at AC and 802.11i crypto is at WTP. > So now, the WTP > > maintains the KeyRSC while the AC requires this > information to generate > > the EAPoL frame for Message-3 of the 4-way handshake. > > > > The diagram below shows this; > > > > - 802.11i Crypto > > (KeyRSC maintained here) - 802.11i > Authentication > > > > +----------+ +-----+ > +------+ > > | Terminal | | WTP | | > AC | > > +----------+ +-----+ > +------+ > > | | > | > > | 802.1x Authentication > | > > > |<=====================================================>| > > | | > | > > PMK | > PMK > > | | > | > > Generate | > Generate > > SNonce | > ANonce > > | | > | > > > > > > In this case, the EAPoL frame generated by the AC will > not be based on > > the prevailing value of the KeyRSC, as this counter is > maintained by > > the WTP. > > > > This problem is currently not solved in the CAPWAP > specifications. > > > > > > Proposal: > > > > The proposal is to include a CAPWAP Key Configuration > message that can > > transport the EAPoL frame between AC and WTP before > being sent to the > > client (terminal). > > > > Key Configuration is a control message sent by the AC > to the WTP. The > > message contains Message-3 of the 4-way handshake - > including the > > EAPoL-frame. However, the EAPoL frame has its KeyMIC > field unassigned as > > the AC cannot accurately calculate this. > > > > So on receiving the Key Configuration - containing > EAPoL frame with > > unassigned KeyMIC field, the WTP retrieves the value of > the KeyRSC it > > maintains and computes the corresponding KeyMIC. > > > > The EAPoL frame is then updated and Message-3 of the > 4-way handshake is > > reconstructed before being sent over the wireless link > to the client. > > > > > > The diagram below illustrates this; > > > > > > - 802.11i Crypto > > (KeyRSC maintained here) - 802.11i > Authentication > > > > +----------+ +-----+ > +------+ > > | Terminal | | WTP | | > AC | > > +----------+ +-----+ > +------+ > > | | > | > > | 802.1x Authentication > | > > > |<=====================================================>| > > | | > | > > PMK | > PMK > > | | > | > > Generate | > Generate > > SNonce | > ANonce > > | | > | > > | | > | > > | Message 1 > | > > > |<-------------------------|<---------------------------| > > | EAPoL Packet | CAPWAP Packet > | > > Receive | > | > > ANonce | > | > > Generate | > | > > PTK | > | > > | | > | > > | Message 2 > | > > > |------------------------->|--------------------------->| > > | EAPoL Packet | CAPWAP Packet > | > > | | > Receive > > | | > SNonce > > | | > | > > | | > Generate > > | | > PTK > > | | > GTK > > | | Message 3 > | > > | > |<===========================| > > | | CAPWAP Packet > | > > | | (Key Configuration) > | > > | | | > +-----------------------+ > > | | \|- GTK-Flag > | > > | -Retrieve KeyRSC |- > Encryption-Data(PTK) | > > | -Update KeyMIC |- > Encryption-Data(GTK) | > > | -Reconstruct |- EAP-Frame > | > > | Message-3 > +-----------------------+ > > | | > | > > |<-------------------------| > | > > | EAPoL Packet | > | > > Receive | > | > > GTK | > | > > | Message 4 > | > > > |------------------------->|--------------------------->| > > | EAPoL Packet | CAPWAP Packet > | > > | | > | > > > > > > > > This proposal very simply solves the problem while > directly addressing > > the requirement for IEEE 802.11i Considerations. > > > > > > Cheers, > > > > Saravanan > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > _________________________________________________________________ > Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > _________________________________________________________________ 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 Sep 18 00:08:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPAQk-0001jm-0p for capwap-archive@lists.ietf.org; Mon, 18 Sep 2006 00:08:26 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPAQf-0007JM-2z for capwap-archive@lists.ietf.org; Mon, 18 Sep 2006 00:08:26 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 22C8039802A for ; Sun, 17 Sep 2006 21:08:20 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 02DA24300EE for ; Sun, 17 Sep 2006 21:06:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C9F301448022 for ; Sun, 17 Sep 2006 21:06:34 -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 8640D1448009 for ; Sun, 17 Sep 2006 21:06:33 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 17 Sep 2006 21:06:33 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8I46WIh000609; Sun, 17 Sep 2006 21:06:32 -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 k8I46WQV021508; Sun, 17 Sep 2006 21:06:32 -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); Sun, 17 Sep 2006 21:06:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 17 Sep 2006 21:06:30 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20280192F@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbY4CMB7agq4TySSwi0SsMRMuBTQgADSCsAAHay+HAAA82qYA== From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , X-OriginalArrivalTime: 18 Sep 2006 04:06:32.0474 (UTC) FILETIME=[D350A7A0:01C6DAD7] 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: Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 8b55e50be03ae25e9a8d86e86275fb10 My thoughts is that the protocol, as defined today, can provide complete support for 802.11i in both Local and Split MAC. So while we may have agreed on a requirement, my objective is to try to keep the protocol as simple as possible. I do not see making this change as necessary, because there is nothing the protocol is unable to do today. Furthermore, I do not see making this change as necessary, because it would introduce additional optional features in the protocol - and consequently increase complexity. So I disagree with your comment of not confusing between need and stated requirement. When we agreed on requirements, I'm not sure we all understood how they could be interpreted. I believe we have a very flexible approach today. so my thought is that if we believe we need to interpret the requirement in the way you have, this requirement is not required. If we interpret the requirement the way I have (see above), then we have already. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Sunday, September 17, 2006 7:24 PM > To: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Pat, > > The issue here is about how 802.11i exchanges are done when > authenticator is at the AC and crypto elements are at the > WTP. This is the requirement. > > The proposal is a way to realize this requirement. > > Let's not confuse between actual need and stated > requirements. We achieved consensus on the mandatory > requirement because there is indeed a need for it. > > Given that this topic has been discussed for a while, I would > really like to understand your concerns. What are your > thoughts on realizing this requirement? > > Saravanan > > > > > > > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Saturday, September 16, 2006 1:36 AM > To: Saravanan Govindan; capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > The "protocol" performs the function of 802.1X/802.11i > without any issues in both the SplitMAC and LocalMAC operation. > > Are you stating this is required because RFC4564 states that > flexibility is required, or because there is an actual need > for this feature? > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Saravanan Govindan [mailto:saravanang@hotmail.com] > > Sent: Friday, September 15, 2006 9:00 AM > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > I want to emphasize that this is not an "additional" feature > > - it is a mandatory requirement from RFC 4564. The protocol > currently > > does not meet the requirement. > > > > Saravanan > > > > > > > > ----Original Message Follows---- > > From: "Pat Calhoun (pacalhou)" > > To: "Saravanan Govindan" > > , > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > Date: Fri, 15 Sep 2006 08:01:32 -0700 > > > > I understand the proposal, but stand firm on my belief that this > > additional mode of operation is unnecessary. While it is > possible to > > implement, as everything is in a protocol, I believe the WG > needs to > > focus on fixing the protocol in the areas where it is broken, as > > opposed to adding more optional modes that really do not change the > > outcome of the functions. > > > > Perhaps what would be more useful is not to describe the > method, but > > the reason why this is being proposed. I still fail to > understand why > > you believe this mode of operation is necessary. > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > > ________________________________ > > > > From: Saravanan Govindan > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > Sent: Friday, September 15, 2006 2:03 AM > > To: capwap@frascone.com > > Subject: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > > > > > All, > > > > > > I wanted to give a more detailed explanation for the > > IEEE 802.11i Considerations requirement. This note describes > > how CAPWAP can be updated to satisfy this requirement > > > > > > > > I would like to use this to highlight the proposal > > being put forward. > > > > > > > > > > > > > > > > From RFC 4564, Section 5.1.10 IEEE 802.11i Considerations > > > > > > > > Protocol Requirement: > > > > > > > > The CAPWAP protocol MUST determine the exact structure of the > > > > centralized WLAN architecture in which > > authentication needs to be > > > > supported, i.e., the location of major > > authentication components. > > > > This may be achieved during WTP initialization where major > > > > capabilities are distinguished. > > > > > > > > The protocol MUST allow for the exchange of key > > information when > > > > authenticator and encryption roles are located in > > distinct entities. > > > > > > > > > > > > Following the requirement, CAPWAP needs; > > > > > > > > 1. to incorporate authentication & encryption locations in > > > > capabilities exchange > > > > > > > > 2. to exchange key information when authentication and crypt are > > > > located in different network entities > > > > > > > > > > > > Basic case: > > > > > > > > AC does both IEEE 802.11i authentication and > > cryptography. For 4-way > > > > exchange, AC tracks the KeyRSC, which it then uses for > > Message-3, > > > > i.e., AC calculates KeyMIC and updates EAPoL frame. > > > > > > > > > > > > - > > 802.11i Authentication > > > > - > > 802.11i Crypto > > > > > > (KeyRSC maintained here) > > > > > > > > +----------+ +-----+ > > +------+ > > > > | Terminal | | WTP | | > > AC | > > > > +----------+ +-----+ > > +------+ > > > > | | > > | > > > > | 802.1x Authentication > > | > > > > > > |<=====================================================>| > > > > | | > > | > > > > PMK | > > PMK > > > > | | > > | > > > > Generate | > > Generate > > > > SNonce | > > ANonce > > > > | | > > | > > > > | | > > | > > > > | Message-1 > > | > > > > > > |<-------------------------|<---------------------------| > > > > | EAPoL Packet | CAPWAP Packet > > | > > > > Receive | > > | > > > > ANonce | > > | > > > > Generate | > > | > > > > PTK | > > | > > > > | | > > | > > > > | Message-2 > > | > > > > > > |------------------------->|--------------------------->| > > > > | EAPoL Packet | CAPWAP Packet > > | > > > > | | > > Receive > > > > | | > > SNonce > > > > | | > > | > > > > | | > > Generate > > > > | | > > PTK > > > > | | > > GTK > > > > | Message-3 > > | > > > > > > |<-------------------------|<---------------------------| > > > > | EAPoL Packet | CAPWAP Packet > > | > > > > | | | > > | > > > > | | | > > +-----------------------+ > > > > | | \|- EAPoL Frame > > | > > > > Receive | > > +-----------------------+ > > > > GTK | > > | > > > > | | > > | > > > > | | > > | > > > > | Message-4 > > | > > > > > > |------------------------->|--------------------------->| > > > > | EAPoL Packet | CAPWAP Packet > > | > > > > | | > > | > > > > > > > > > > > > > > > > > > > > Case specified by RFC 4564: > > > > > > > > The 802.11i Considerations requirement considers the > > case where 802.11i > > > > authentication is at AC and 802.11i crypto is at WTP. > > So now, the WTP > > > > maintains the KeyRSC while the AC requires this > > information to generate > > > > the EAPoL frame for Message-3 of the 4-way handshake. > > > > > > > > The diagram below shows this; > > > > > > > > - 802.11i Crypto > > > > (KeyRSC maintained here) - 802.11i > > Authentication > > > > > > > > +----------+ +-----+ > > +------+ > > > > | Terminal | | WTP | | > > AC | > > > > +----------+ +-----+ > > +------+ > > > > | | > > | > > > > | 802.1x Authentication > > | > > > > > > |<=====================================================>| > > > > | | > > | > > > > PMK | > > PMK > > > > | | > > | > > > > Generate | > > Generate > > > > SNonce | > > ANonce > > > > | | > > | > > > > > > > > > > > > In this case, the EAPoL frame generated by the AC will > > not be based on > > > > the prevailing value of the KeyRSC, as this counter is > > maintained by > > > > the WTP. > > > > > > > > This problem is currently not solved in the CAPWAP > > specifications. > > > > > > > > > > > > Proposal: > > > > > > > > The proposal is to include a CAPWAP Key Configuration > > message that can > > > > transport the EAPoL frame between AC and WTP before > > being sent to the > > > > client (terminal). > > > > > > > > Key Configuration is a control message sent by the AC > > to the WTP. The > > > > message contains Message-3 of the 4-way handshake - > > including the > > > > EAPoL-frame. However, the EAPoL frame has its KeyMIC > > field unassigned as > > > > the AC cannot accurately calculate this. > > > > > > > > So on receiving the Key Configuration - containing > > EAPoL frame with > > > > unassigned KeyMIC field, the WTP retrieves the value of > > the KeyRSC it > > > > maintains and computes the corresponding KeyMIC. > > > > > > > > The EAPoL frame is then updated and Message-3 of the > > 4-way handshake is > > > > reconstructed before being sent over the wireless link > > to the client. > > > > > > > > > > > > The diagram below illustrates this; > > > > > > > > > > > > - 802.11i Crypto > > > > (KeyRSC maintained here) - 802.11i > > Authentication > > > > > > > > +----------+ +-----+ > > +------+ > > > > | Terminal | | WTP | | > > AC | > > > > +----------+ +-----+ > > +------+ > > > > | | > > | > > > > | 802.1x Authentication > > | > > > > > > |<=====================================================>| > > > > | | > > | > > > > PMK | > > PMK > > > > | | > > | > > > > Generate | > > Generate > > > > SNonce | > > ANonce > > > > | | > > | > > > > | | > > | > > > > | Message 1 > > | > > > > > > |<-------------------------|<---------------------------| > > > > | EAPoL Packet | CAPWAP Packet > > | > > > > Receive | > > | > > > > ANonce | > > | > > > > Generate | > > | > > > > PTK | > > | > > > > | | > > | > > > > | Message 2 > > | > > > > > > |------------------------->|--------------------------->| > > > > | EAPoL Packet | CAPWAP Packet > > | > > > > | | > > Receive > > > > | | > > SNonce > > > > | | > > | > > > > | | > > Generate > > > > | | > > PTK > > > > | | > > GTK > > > > | | Message 3 > > | > > > > | > > |<===========================| > > > > | | CAPWAP Packet > > | > > > > | | (Key Configuration) > > | > > > > | | | > > +-----------------------+ > > > > | | \|- GTK-Flag > > | > > > > | -Retrieve KeyRSC |- > > Encryption-Data(PTK) | > > > > | -Update KeyMIC |- > > Encryption-Data(GTK) | > > > > | -Reconstruct |- EAP-Frame > > | > > > > | Message-3 > > +-----------------------+ > > > > | | > > | > > > > |<-------------------------| > > | > > > > | EAPoL Packet | > > | > > > > Receive | > > | > > > > GTK | > > | > > > > | Message 4 > > | > > > > > > |------------------------->|--------------------------->| > > > > | EAPoL Packet | CAPWAP Packet > > | > > > > | | > > | > > > > > > > > > > > > > > > > This proposal very simply solves the problem while > > directly addressing > > > > the requirement for IEEE 802.11i Considerations. > > > > > > > > > > > > Cheers, > > > > > > > > Saravanan > > > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > _________________________________________________________________ > > Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > _________________________________________________________________ > 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 Sep 18 04:10:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPECi-00039k-SB for capwap-archive@lists.ietf.org; Mon, 18 Sep 2006 04:10:12 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPECg-0005Mc-Tf for capwap-archive@lists.ietf.org; Mon, 18 Sep 2006 04:10:12 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id E057039806D for ; Mon, 18 Sep 2006 01:10:05 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id F20E64300EE for ; Mon, 18 Sep 2006 01:09:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D0D51430760 for ; Mon, 18 Sep 2006 01:09:17 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 529A7430752 for ; Mon, 18 Sep 2006 01:09:14 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id k8I89BGT012059; Mon, 18 Sep 2006 17:09:11 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k8I89Cu01433; Mon, 18 Sep 2006 17:09:12 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with SMTP id k8I89CO29142; Mon, 18 Sep 2006 17:09:12 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Sep 2006 16:08:17 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012776B3@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbY4CMB7agq4TySSwi0SsMRMuBTQgADSCsAAHay+HAAA82qYAACoK9Q From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , 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] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 320ddee61cb2d39f489e9191ae3fdc8c Pat, The requirement goes beyond distinguishing local / split MAC support. It is explicit in the need to support authenticator and cyrpto elements located at AC and WTP, respectively. I find it difficult to interpret it in another way. I do not think it is right to arbitrarily dismiss a compulsory requirement. The fundamental goal of RFC4564 was to put forth key requirements that the protocol has to satisfy. It is a "MUST" - I do not see why we are having this extensive discussion. Saravanan -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Monday, September 18, 2006 12:07 PM To: Saravanan Govindan; capwap@frascone.com Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations My thoughts is that the protocol, as defined today, can provide complete support for 802.11i in both Local and Split MAC. So while we may have agreed on a requirement, my objective is to try to keep the protocol as simple as possible. I do not see making this change as necessary, because there is nothing the protocol is unable to do today. Furthermore, I do not see making this change as necessary, because it would introduce additional optional features in the protocol - and consequently increase complexity. So I disagree with your comment of not confusing between need and stated requirement. When we agreed on requirements, I'm not sure we all understood how they could be interpreted. I believe we have a very flexible approach today. so my thought is that if we believe we need to interpret the requirement in the way you have, this requirement is not required. If we interpret the requirement the way I have (see above), then we have already. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Sunday, September 17, 2006 7:24 PM > To: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Pat, > > The issue here is about how 802.11i exchanges are done when > authenticator is at the AC and crypto elements are at the > WTP. This is the requirement. > > The proposal is a way to realize this requirement. > > Let's not confuse between actual need and stated > requirements. We achieved consensus on the mandatory > requirement because there is indeed a need for it. > > Given that this topic has been discussed for a while, I would > really like to understand your concerns. What are your > thoughts on realizing this requirement? > > Saravanan > > > > > > > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Saturday, September 16, 2006 1:36 AM > To: Saravanan Govindan; capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > The "protocol" performs the function of 802.1X/802.11i > without any issues in both the SplitMAC and LocalMAC operation. > > Are you stating this is required because RFC4564 states that > flexibility is required, or because there is an actual need > for this feature? > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Saravanan Govindan [mailto:saravanang@hotmail.com] > > Sent: Friday, September 15, 2006 9:00 AM > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > I want to emphasize that this is not an "additional" feature > > - it is a mandatory requirement from RFC 4564. The protocol > currently > > does not meet the requirement. > > > > Saravanan > > > > > > > > ----Original Message Follows---- > > From: "Pat Calhoun (pacalhou)" > > To: "Saravanan Govindan" > > , > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > Date: Fri, 15 Sep 2006 08:01:32 -0700 > > > > I understand the proposal, but stand firm on my belief that this > > additional mode of operation is unnecessary. While it is > possible to > > implement, as everything is in a protocol, I believe the WG > needs to > > focus on fixing the protocol in the areas where it is broken, as > > opposed to adding more optional modes that really do not change the > > outcome of the functions. > > > > Perhaps what would be more useful is not to describe the > method, but > > the reason why this is being proposed. I still fail to > understand why > > you believe this mode of operation is necessary. > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > > ________________________________ > > > > From: Saravanan Govindan > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > Sent: Friday, September 15, 2006 2:03 AM > > To: capwap@frascone.com > > Subject: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > > > > > All, > > > > > > I wanted to give a more detailed explanation for the > > IEEE 802.11i Considerations requirement. This note describes > > how CAPWAP can be updated to satisfy this requirement > > > > > > > > I would like to use this to highlight the proposal > > being put forward. > > > > > > > > > > > > > > > > From RFC 4564, Section 5.1.10 IEEE 802.11i Considerations > > > > > > > > Protocol Requirement: > > > > > > > > The CAPWAP protocol MUST determine the exact structure of the > > > > centralized WLAN architecture in which > > authentication needs to be > > > > supported, i.e., the location of major > > authentication components. > > > > This may be achieved during WTP initialization where major > > > > capabilities are distinguished. > > > > > > > > The protocol MUST allow for the exchange of key > > information when > > > > authenticator and encryption roles are located in > > distinct entities. > > > > > > > > > > > > Following the requirement, CAPWAP needs; > > > > > > > > 1. to incorporate authentication & encryption locations in > > > > capabilities exchange > > > > > > > > 2. to exchange key information when authentication and crypt are > > > > located in different network entities > > > > > > > > > > > > Basic case: > > > > > > > > AC does both IEEE 802.11i authentication and > > cryptography. For 4-way > > > > exchange, AC tracks the KeyRSC, which it then uses for > > Message-3, > > > > i.e., AC calculates KeyMIC and updates EAPoL frame. > > > > > > > > > > > > - > > 802.11i Authentication > > > > - > > 802.11i Crypto > > > > > > (KeyRSC maintained here) > > > > > > > > +----------+ +-----+ > > +------+ > > > > | Terminal | | WTP | | > > AC | > > > > +----------+ +-----+ > > +------+ > > > > | | > > | > > > > | 802.1x Authentication > > | > > > > > > |<=====================================================>| > > > > | | > > | > > > > PMK | > > PMK > > > > | | > > | > > > > Generate | > > Generate > > > > SNonce | > > ANonce > > > > | | > > | > > > > | | > > | > > > > | Message-1 > > | > > > > > > |<-------------------------|<---------------------------| > > > > | EAPoL Packet | CAPWAP Packet > > | > > > > Receive | > > | > > > > ANonce | > > | > > > > Generate | > > | > > > > PTK | > > | > > > > | | > > | > > > > | Message-2 > > | > > > > > > |------------------------->|--------------------------->| > > > > | EAPoL Packet | CAPWAP Packet > > | > > > > | | > > Receive > > > > | | > > SNonce > > > > | | > > | > > > > | | > > Generate > > > > | | > > PTK > > > > | | > > GTK > > > > | Message-3 > > | > > > > > > |<-------------------------|<---------------------------| > > > > | EAPoL Packet | CAPWAP Packet > > | > > > > | | | > > | > > > > | | | > > +-----------------------+ > > > > | | \|- EAPoL Frame > > | > > > > Receive | > > +-----------------------+ > > > > GTK | > > | > > > > | | > > | > > > > | | > > | > > > > | Message-4 > > | > > > > > > |------------------------->|--------------------------->| > > > > | EAPoL Packet | CAPWAP Packet > > | > > > > | | > > | > > > > > > > > > > > > > > > > > > > > Case specified by RFC 4564: > > > > > > > > The 802.11i Considerations requirement considers the > > case where 802.11i > > > > authentication is at AC and 802.11i crypto is at WTP. > > So now, the WTP > > > > maintains the KeyRSC while the AC requires this > > information to generate > > > > the EAPoL frame for Message-3 of the 4-way handshake. > > > > > > > > The diagram below shows this; > > > > > > > > - 802.11i Crypto > > > > (KeyRSC maintained here) - 802.11i > > Authentication > > > > > > > > +----------+ +-----+ > > +------+ > > > > | Terminal | | WTP | | > > AC | > > > > +----------+ +-----+ > > +------+ > > > > | | > > | > > > > | 802.1x Authentication > > | > > > > > > |<=====================================================>| > > > > | | > > | > > > > PMK | > > PMK > > > > | | > > | > > > > Generate | > > Generate > > > > SNonce | > > ANonce > > > > | | > > | > > > > > > > > > > > > In this case, the EAPoL frame generated by the AC will > > not be based on > > > > the prevailing value of the KeyRSC, as this counter is > > maintained by > > > > the WTP. > > > > > > > > This problem is currently not solved in the CAPWAP > > specifications. > > > > > > > > > > > > Proposal: > > > > > > > > The proposal is to include a CAPWAP Key Configuration > > message that can > > > > transport the EAPoL frame between AC and WTP before > > being sent to the > > > > client (terminal). > > > > > > > > Key Configuration is a control message sent by the AC > > to the WTP. The > > > > message contains Message-3 of the 4-way handshake - > > including the > > > > EAPoL-frame. However, the EAPoL frame has its KeyMIC > > field unassigned as > > > > the AC cannot accurately calculate this. > > > > > > > > So on receiving the Key Configuration - containing > > EAPoL frame with > > > > unassigned KeyMIC field, the WTP retrieves the value of > > the KeyRSC it > > > > maintains and computes the corresponding KeyMIC. > > > > > > > > The EAPoL frame is then updated and Message-3 of the > > 4-way handshake is > > > > reconstructed before being sent over the wireless link > > to the client. > > > > > > > > > > > > The diagram below illustrates this; > > > > > > > > > > > > - 802.11i Crypto > > > > (KeyRSC maintained here) - 802.11i > > Authentication > > > > > > > > +----------+ +-----+ > > +------+ > > > > | Terminal | | WTP | | > > AC | > > > > +----------+ +-----+ > > +------+ > > > > | | > > | > > > > | 802.1x Authentication > > | > > > > > > |<=====================================================>| > > > > | | > > | > > > > PMK | > > PMK > > > > | | > > | > > > > Generate | > > Generate > > > > SNonce | > > ANonce > > > > | | > > | > > > > | | > > | > > > > | Message 1 > > | > > > > > > |<-------------------------|<---------------------------| > > > > | EAPoL Packet | CAPWAP Packet > > | > > > > Receive | > > | > > > > ANonce | > > | > > > > Generate | > > | > > > > PTK | > > | > > > > | | > > | > > > > | Message 2 > > | > > > > > > |------------------------->|--------------------------->| > > > > | EAPoL Packet | CAPWAP Packet > > | > > > > | | > > Receive > > > > | | > > SNonce > > > > | | > > | > > > > | | > > Generate > > > > | | > > PTK > > > > | | > > GTK > > > > | | Message 3 > > | > > > > | > > |<===========================| > > > > | | CAPWAP Packet > > | > > > > | | (Key Configuration) > > | > > > > | | | > > +-----------------------+ > > > > | | \|- GTK-Flag > > | > > > > | -Retrieve KeyRSC |- > > Encryption-Data(PTK) | > > > > | -Update KeyMIC |- > > Encryption-Data(GTK) | > > > > | -Reconstruct |- EAP-Frame > > | > > > > | Message-3 > > +-----------------------+ > > > > | | > > | > > > > |<-------------------------| > > | > > > > | EAPoL Packet | > > | > > > > Receive | > > | > > > > GTK | > > | > > > > | Message 4 > > | > > > > > > |------------------------->|--------------------------->| > > > > | EAPoL Packet | CAPWAP Packet > > | > > > > | | > > | > > > > > > > > > > > > > > > > This proposal very simply solves the problem while > > directly addressing > > > > the requirement for IEEE 802.11i Considerations. > > > > > > > > > > > > Cheers, > > > > > > > > Saravanan > > > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > _________________________________________________________________ > > Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > _________________________________________________________________ > 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 Sep 18 04:16:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPEIV-0006BJ-NP for capwap-archive@lists.ietf.org; Mon, 18 Sep 2006 04:16:11 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPEIU-0006Xq-1U for capwap-archive@lists.ietf.org; Mon, 18 Sep 2006 04:16:11 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id A79D1398043 for ; Mon, 18 Sep 2006 01:16:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id BEED04300EE for ; Mon, 18 Sep 2006 01:15:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A3421430784 for ; Mon, 18 Sep 2006 01:15:37 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 6DEB3430776 for ; Mon, 18 Sep 2006 01:15:35 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id k8I8FXhB001058; Mon, 18 Sep 2006 17:15:33 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k8I8FYX08192; Mon, 18 Sep 2006 17:15:34 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with SMTP id k8I8FY825933; Mon, 18 Sep 2006 17:15:34 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Sep 2006 16:14:41 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012776BA@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Consensus call on Split CAPWAP draft by 9/29. Thread-Index: AcbY82fx0AwmEjxkSO+bTrWL20FI8gCB3ZDw From: "Saravanan Govindan" To: , 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: margaret@thingmagic.com Subject: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0309016871==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca This is a multi-part message in MIME format. --===============0309016871== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DAFA.7E20047C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DAFA.7E20047C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 I think the CAPWAP specifications should be completed before being split. My concern is that splitting the draft now may complicate consensus on technical content.=20 =20 Saravanan =20 =20 =20 =20 ________________________________ From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com]=20 Sent: Saturday, September 16, 2006 2:19 AM To: Capwap@frascone.com Cc: margaret@thingmagic.com; Dorothy.Gellert@nokia.com Subject: [Capwap] Consensus call on Split CAPWAP draft by 9/29. =20 Hi All,=20 The editors feel that there is WG support to split the current CAPWAP protocol draft into 2 drafts, a base draft and then a 802.11 binding draft. The chairs would like to verify consensus with the WG that there is sufficient interest to split the draft before making this change. This issue has been discussed at the last CAPWAP WG meeting during IETF 66 in Montreal where there was no opposition to this request, and limited support on the list. =20 The chairs would like establish consensus on the issue of splitting binding specific details from the base CAPWAP specification.=20 Please submit your opinions on this topic to the WG list by Sept 29th, for a final consensus call on this feature.=20 Best Regards,=20 Dorothy, Mani and Margaret=20 ------_=_NextPart_001_01C6DAFA.7E20047C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Consensus call on Split CAPWAP draft by 9/29.

All,

 

I think the CAPWAP specifications = should be completed before being split. My concern is that splitting the draft = now may complicate consensus on technical content.

 

Saravanan

 

 

 

 

From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com]
Sent: Saturday, September = 16, 2006 2:19 AM
To: = Capwap@frascone.com
Cc: = margaret@thingmagic.com; Dorothy.Gellert@nokia.com
Subject: [Capwap] = Consensus call on Split CAPWAP draft by 9/29.

 

Hi All,

The editors feel that there is WG support to split the = current CAPWAP protocol draft into 2 drafts, a base draft and then a 802.11 = binding draft.  The chairs would like to verify consensus with the WG that = there is sufficient interest to split the draft before making this = change.

This issue has been discussed at the last CAPWAP WG = meeting during IETF 66 in Montreal where there was no opposition to this request, and limited support on = the list. 

The chairs would like establish consensus on the issue of splitting binding specific details from the base CAPWAP specification. =

Please submit your opinions on this topic to the WG list = by Sept 29th, for a final consensus call on this feature. =

Best Regards,
Dorothy, Mani and Margaret

------_=_NextPart_001_01C6DAFA.7E20047C-- --===============0309016871== 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 --===============0309016871==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Sep 18 10:05:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPJl1-0006Yf-6t for capwap-archive@lists.ietf.org; Mon, 18 Sep 2006 10:05:59 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPJkt-0003m7-NX for capwap-archive@lists.ietf.org; Mon, 18 Sep 2006 10:05:59 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 81FE84310CB for ; Mon, 18 Sep 2006 07:05:37 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id AA85B43005F for ; Mon, 18 Sep 2006 07:04:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4AE04398094 for ; Mon, 18 Sep 2006 07:04:44 -0700 (PDT) Received: from IS1.enterasys.com (is1.enterasys.com [63.160.138.52]) by zoidberg.tigertech.net (Postfix) with ESMTP id 42F4939809E for ; Mon, 18 Sep 2006 07:03:00 -0700 (PDT) Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 10:02:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Sep 2006 10:02:44 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565605A48EF@MABOSEVS2.ets.enterasys.com> In-Reply-To: <893AE265F4ADF94AB7FB26D31A788E41029E0CCC@mvebe101.NOE.Nokia.co m> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Consensus call on Split CAPWAP draft by 9/29. Thread-Index: AcbY82fx0AwmEjxkSO+bTrWL20FI8gCN5kzQ From: "Nelson, David" To: X-OriginalArrivalTime: 18 Sep 2006 14:02:44.0923 (UTC) FILETIME=[1D5B30B0:01C6DB2B] X-imss-version: 2.042 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com 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] Consensus call on Split CAPWAP draft by 9/29. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 I support splitting the draft. Regards, =A0 Dave =A0 David B. Nelson Enterasys Networks, Inc. 50 Minuteman Road Andover, MA 01810-1008 Phone: (978) 684-1330=A0 = E-mail: dnelson@enterasys.com =A0 ________________________________________ From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] = Sent: Friday, September 15, 2006 2:19 PM To: Capwap@frascone.com Cc: margaret@thingmagic.com; Dorothy.Gellert@nokia.com Subject: [Capwap] Consensus call on Split CAPWAP draft by 9/29. Hi All, = The editors feel that there is WG support to split the current CAPWAP proto= col draft into 2 drafts, a base draft and then a 802.11 binding draft.=A0 T= he chairs would like to verify consensus with the WG that there is sufficie= nt interest to split the draft before making this change. This issue has been discussed at the last CAPWAP WG meeting during IETF 66 = in Montreal where there was no opposition to this request, and limited supp= ort on the list.=A0 = The chairs would like establish consensus on the issue of splitting binding= specific details from the base CAPWAP specification. = Please submit your opinions on this topic to the WG list by Sept 29th, for = a final consensus call on this feature. = Best Regards, = Dorothy, Mani and 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 Mon Sep 18 13:30:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPMwg-0000pq-Qg for capwap-archive@lists.ietf.org; Mon, 18 Sep 2006 13:30:14 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPMij-0005L2-HA for capwap-archive@lists.ietf.org; Mon, 18 Sep 2006 13:15:55 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 55D7C3980EF for ; Mon, 18 Sep 2006 10:15:36 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 5381C43005F for ; Mon, 18 Sep 2006 10:14:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 43AB739805D for ; Mon, 18 Sep 2006 10:14:49 -0700 (PDT) Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by zoidberg.tigertech.net (Postfix) with ESMTP id 02F7A398026 for ; Mon, 18 Sep 2006 10:14:44 -0700 (PDT) Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id E5E001BC8 for ; Mon, 18 Sep 2006 17:14:43 +0000 (GMT) Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.31J) with ESMTP id 077kiRRor0485Mo2; Mon, 18 Sep 2006 17:14:43 GMT Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.31J) with ESMTP id 073kiRRop0432Mo2; Mon, 18 Sep 2006 17:14:41 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.32F); Mon, 18 Sep 2006 17:14:41 GMT X-USANET-Source: 165.212.116.254 IN skh@nexthop.com GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID885kiRRop5915Xo2 Received: from VS4.EXCHPROD.USA.NET ([10.116.208.142]) by GW1.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 11:14:40 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Sep 2006 11:14:38 -0600 Message-ID: <6F44D7F6B24A8F4DA0AB46C9BE924F0206F8E9A3@VS4.EXCHPROD.USA.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. Thread-Index: AcbbRet0t8Pd9sbVSqKvRycJjdrdYA== From: "Susan Hares" To: X-OriginalArrivalTime: 18 Sep 2006 17:14:40.0121 (UTC) FILETIME=[ECF2F690:01C6DB45] 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: Subject: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0064268640==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c This is a multi-part message in MIME format. --===============0064268640== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DB45.ECEF5ED0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DB45.ECEF5ED0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support splitting the draft. =20 Susan Hares=20 shares@nexthop.com ------_=_NextPart_001_01C6DB45.ECEF5ED0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support splitting the draft.

 

Susan = Hares =

shares@nexthop.com

------_=_NextPart_001_01C6DB45.ECEF5ED0-- --===============0064268640== 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 --===============0064268640==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Sep 18 13:41:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPN7C-0005D1-Ny for capwap-archive@lists.ietf.org; Mon, 18 Sep 2006 13:41:06 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPN76-0000le-2R for capwap-archive@lists.ietf.org; Mon, 18 Sep 2006 13:41:06 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 858B5431576 for ; Mon, 18 Sep 2006 10:40:56 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id DDCE14300CD for ; Mon, 18 Sep 2006 10:39:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D21F339803B for ; Mon, 18 Sep 2006 10:39:58 -0700 (PDT) Received: from ccerelbas03.cce.hp.com (ccerelbas03.cce.hp.com [161.114.21.106]) by zoidberg.tigertech.net (Postfix) with ESMTP id C594439802E for ; Mon, 18 Sep 2006 10:39:52 -0700 (PDT) Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.81.1.59]) by ccerelbas03.cce.hp.com (Postfix) with ESMTP id BECC93400E; Mon, 18 Sep 2006 12:39:47 -0500 (CDT) Received: from G3W0072.americas.hpqcorp.net ([16.232.1.11]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 12:39:46 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Sep 2006 12:39:43 -0500 Message-ID: <08CA2245AFCF444DB3AC415E47CC40AF1896E5@G3W0072.americas.hpqcorp.net> In-Reply-To: <893AE265F4ADF94AB7FB26D31A788E41029E0CCC@mvebe101.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Consensus call on Split CAPWAP draft by 9/29. Thread-Index: AcbY82fx0AwmEjxkSO+bTrWL20FI8gANp8Mg From: "Chiu, Ran-Fun" To: , X-OriginalArrivalTime: 18 Sep 2006 17:39:46.0046 (UTC) FILETIME=[6E8CE1E0:01C6DB49] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.001 tagged_above=-999 required=7 tests=HTML_MESSAGE X-Spam-Level: Cc: margaret@thingmagic.com Subject: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1741490231==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba This is a multi-part message in MIME format. --===============1741490231== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DB49.6E33B992" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DB49.6E33B992 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support to split the current CAPWAP protocol draft into two. =20 Ran-Fun Chiu HP Labs =20 ________________________________ From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com]=20 Sent: Friday, September 15, 2006 11:19 AM To: Capwap@frascone.com Cc: margaret@thingmagic.com; Dorothy.Gellert@nokia.com Subject: [Capwap] Consensus call on Split CAPWAP draft by 9/29. =20 Hi All,=20 The editors feel that there is WG support to split the current CAPWAP protocol draft into 2 drafts, a base draft and then a 802.11 binding draft. The chairs would like to verify consensus with the WG that there is sufficient interest to split the draft before making this change. This issue has been discussed at the last CAPWAP WG meeting during IETF 66 in Montreal where there was no opposition to this request, and limited support on the list. =20 The chairs would like establish consensus on the issue of splitting binding specific details from the base CAPWAP specification.=20 Please submit your opinions on this topic to the WG list by Sept 29th, for a final consensus call on this feature.=20 Best Regards,=20 Dorothy, Mani and Margaret=20 ------_=_NextPart_001_01C6DB49.6E33B992 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Consensus call on Split CAPWAP draft by 9/29.

I support to split the current = CAPWAP protocol draft into two.

 

Ran-Fun Chiu

HP Labs

 

From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com]
Sent: Friday, September = 15, 2006 11:19 AM
To: = Capwap@frascone.com
Cc: = margaret@thingmagic.com; Dorothy.Gellert@nokia.com
Subject: [Capwap] = Consensus call on Split CAPWAP draft by 9/29.

 

Hi All,

The editors feel that there is WG support to split the = current CAPWAP protocol draft into 2 drafts, a base draft and then a 802.11 = binding draft.  The chairs would like to verify consensus with the WG that = there is sufficient interest to split the draft before making this = change.

This issue has been discussed at the last CAPWAP WG = meeting during IETF 66 in Montreal where there was no opposition to this = request, and limited support on the list. 

The chairs would like establish consensus on the issue of splitting binding specific details from the base CAPWAP specification. =

Please submit your opinions on this topic to the WG list = by Sept 29th, for a final consensus call on this feature.

Best Regards,
Dorothy, Mani and Margaret

------_=_NextPart_001_01C6DB49.6E33B992-- --===============1741490231== 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 --===============1741490231==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Sep 18 16:20:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPPbg-00035u-AK for capwap-archive@lists.ietf.org; Mon, 18 Sep 2006 16:20:44 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPPbc-0001Bw-7B for capwap-archive@lists.ietf.org; Mon, 18 Sep 2006 16:20:44 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id A405D431DE7 for ; Mon, 18 Sep 2006 13:20:27 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 31D1543005F for ; Mon, 18 Sep 2006 13:15:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0CFB339807E for ; Mon, 18 Sep 2006 13:15:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id C972D398048 for ; Mon, 18 Sep 2006 13:15:19 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-6.cisco.com with ESMTP; 18 Sep 2006 13:15:19 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8IKFJia016191; Mon, 18 Sep 2006 13:15:19 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k8IKFGwB025312; Mon, 18 Sep 2006 13:15:18 -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); Mon, 18 Sep 2006 13:15:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Sep 2006 13:15:11 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202801B5F@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbY4CMB7agq4TySSwi0SsMRMuBTQgADSCsAAHay+HAAA82qYAACoK9QAB9Gv7A= From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , X-OriginalArrivalTime: 18 Sep 2006 20:15:17.0396 (UTC) FILETIME=[2877E540:01C6DB5F] Authentication-Results: sj-dkim-7.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: Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 72be645574b2b4b84446d27f730bf563 The current specification allows the authenticator to reside in the AC, while the data packet crypto elements in the WTP. This feature is already in the specification. The only thing that is not there is the ability to move various pieces of the authenticator function across both the WTP and the AC, which I feel is unnecessary because it doesn't add any features. It just adds modes of operations to the protocol that creates further interoperability issues between the two devices. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Monday, September 18, 2006 1:08 AM > To: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Pat, > > The requirement goes beyond distinguishing local / split MAC > support. It is explicit in the need to support authenticator > and cyrpto elements located at AC and WTP, respectively. > > I find it difficult to interpret it in another way. > > I do not think it is right to arbitrarily dismiss a > compulsory requirement. > > The fundamental goal of RFC4564 was to put forth key > requirements that the protocol has to satisfy. It is a "MUST" > - I do not see why we are having this extensive discussion. > > Saravanan > > > > > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Monday, September 18, 2006 12:07 PM > To: Saravanan Govindan; capwap@frascone.com > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > My thoughts is that the protocol, as defined today, can > provide complete support for 802.11i in both Local and Split > MAC. So while we may have agreed on a requirement, my > objective is to try to keep the protocol as simple as > possible. I do not see making this change as necessary, > because there is nothing the protocol is unable to do today. > Furthermore, I do not see making this change as necessary, > because it would introduce additional optional features in > the protocol - and consequently increase complexity. > > So I disagree with your comment of not confusing between need > and stated requirement. When we agreed on requirements, I'm > not sure we all understood how they could be interpreted. I > believe we have a very flexible approach today. > > so my thought is that if we believe we need to interpret the > requirement in the way you have, this requirement is not > required. If we interpret the requirement the way I have (see > above), then we have already. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Saravanan Govindan > [mailto:Saravanan.Govindan@sg.panasonic.com] > > Sent: Sunday, September 17, 2006 7:24 PM > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > Pat, > > > > The issue here is about how 802.11i exchanges are done when > > authenticator is at the AC and crypto elements are at the > WTP. This is > > the requirement. > > > > The proposal is a way to realize this requirement. > > > > Let's not confuse between actual need and stated requirements. We > > achieved consensus on the mandatory requirement because there is > > indeed a need for it. > > > > Given that this topic has been discussed for a while, I > would really > > like to understand your concerns. What are your thoughts on > realizing > > this requirement? > > > > Saravanan > > > > > > > > > > > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Saturday, September 16, 2006 1:36 AM > > To: Saravanan Govindan; capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > The "protocol" performs the function of 802.1X/802.11i without any > > issues in both the SplitMAC and LocalMAC operation. > > > > Are you stating this is required because RFC4564 states that > > flexibility is required, or because there is an actual need > for this > > feature? > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Saravanan Govindan [mailto:saravanang@hotmail.com] > > > Sent: Friday, September 15, 2006 9:00 AM > > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > I want to emphasize that this is not an "additional" feature > > > - it is a mandatory requirement from RFC 4564. The protocol > > currently > > > does not meet the requirement. > > > > > > Saravanan > > > > > > > > > > > > ----Original Message Follows---- > > > From: "Pat Calhoun (pacalhou)" > > > To: "Saravanan Govindan" > > > , > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > Date: Fri, 15 Sep 2006 08:01:32 -0700 > > > > > > I understand the proposal, but stand firm on my belief that this > > > additional mode of operation is unnecessary. While it is > > possible to > > > implement, as everything is in a protocol, I believe the WG > > needs to > > > focus on fixing the protocol in the areas where it is broken, as > > > opposed to adding more optional modes that really do not > change the > > > outcome of the functions. > > > > > > Perhaps what would be more useful is not to describe the > > method, but > > > the reason why this is being proposed. I still fail to > > understand why > > > you believe this mode of operation is necessary. > > > > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > > > ________________________________ > > > > > > From: Saravanan Govindan > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > Sent: Friday, September 15, 2006 2:03 AM > > > To: capwap@frascone.com > > > Subject: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > > > > > > > > > All, > > > > > > > > > I wanted to give a more detailed explanation for the > > > IEEE 802.11i Considerations requirement. This note describes > > > how CAPWAP can be updated to satisfy this requirement > > > > > > > > > > > > I would like to use this to highlight the proposal > > > being put forward. > > > > > > > > > > > > > > > > > > > > > > > > From RFC 4564, Section 5.1.10 IEEE 802.11i Considerations > > > > > > > > > > > > Protocol Requirement: > > > > > > > > > > > > The CAPWAP protocol MUST determine the exact structure of the > > > > > > centralized WLAN architecture in which > > > authentication needs to be > > > > > > supported, i.e., the location of major > > > authentication components. > > > > > > This may be achieved during WTP initialization where major > > > > > > capabilities are distinguished. > > > > > > > > > > > > The protocol MUST allow for the exchange of key > > > information when > > > > > > authenticator and encryption roles are located in > > > distinct entities. > > > > > > > > > > > > > > > > > > Following the requirement, CAPWAP needs; > > > > > > > > > > > > 1. to incorporate authentication & encryption locations in > > > > > > capabilities exchange > > > > > > > > > > > > 2. to exchange key information when authentication and crypt are > > > > > > located in different network entities > > > > > > > > > > > > > > > > > > Basic case: > > > > > > > > > > > > AC does both IEEE 802.11i authentication and > > > cryptography. For 4-way > > > > > > exchange, AC tracks the KeyRSC, which it then uses for > > > Message-3, > > > > > > i.e., AC calculates KeyMIC and updates EAPoL frame. > > > > > > > > > > > > > > > > > > - > > > 802.11i Authentication > > > > > > - > > > 802.11i Crypto > > > > > > > > > (KeyRSC maintained here) > > > > > > > > > > > > +----------+ +-----+ > > > +------+ > > > > > > | Terminal | | WTP | | > > > AC | > > > > > > +----------+ +-----+ > > > +------+ > > > > > > | | > > > | > > > > > > | 802.1x Authentication > > > | > > > > > > > > > |<=====================================================>| > > > > > > | | > > > | > > > > > > PMK | > > > PMK > > > > > > | | > > > | > > > > > > Generate | > > > Generate > > > > > > SNonce | > > > ANonce > > > > > > | | > > > | > > > > > > | | > > > | > > > > > > | Message-1 > > > | > > > > > > > > > |<-------------------------|<---------------------------| > > > > > > | EAPoL Packet | CAPWAP Packet > > > | > > > > > > Receive | > > > | > > > > > > ANonce | > > > | > > > > > > Generate | > > > | > > > > > > PTK | > > > | > > > > > > | | > > > | > > > > > > | Message-2 > > > | > > > > > > > > > |------------------------->|--------------------------->| > > > > > > | EAPoL Packet | CAPWAP Packet > > > | > > > > > > | | > > > Receive > > > > > > | | > > > SNonce > > > > > > | | > > > | > > > > > > | | > > > Generate > > > > > > | | > > > PTK > > > > > > | | > > > GTK > > > > > > | Message-3 > > > | > > > > > > > > > |<-------------------------|<---------------------------| > > > > > > | EAPoL Packet | CAPWAP Packet > > > | > > > > > > | | | > > > | > > > > > > | | | > > > +-----------------------+ > > > > > > | | \|- EAPoL Frame > > > | > > > > > > Receive | > > > +-----------------------+ > > > > > > GTK | > > > | > > > > > > | | > > > | > > > > > > | | > > > | > > > > > > | Message-4 > > > | > > > > > > > > > |------------------------->|--------------------------->| > > > > > > | EAPoL Packet | CAPWAP Packet > > > | > > > > > > | | > > > | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Case specified by RFC 4564: > > > > > > > > > > > > The 802.11i Considerations requirement considers the > > > case where 802.11i > > > > > > authentication is at AC and 802.11i crypto is at WTP. > > > So now, the WTP > > > > > > maintains the KeyRSC while the AC requires this > > > information to generate > > > > > > the EAPoL frame for Message-3 of the 4-way handshake. > > > > > > > > > > > > The diagram below shows this; > > > > > > > > > > > > - 802.11i Crypto > > > > > > (KeyRSC maintained here) - 802.11i > > > Authentication > > > > > > > > > > > > +----------+ +-----+ > > > +------+ > > > > > > | Terminal | | WTP | | > > > AC | > > > > > > +----------+ +-----+ > > > +------+ > > > > > > | | > > > | > > > > > > | 802.1x Authentication > > > | > > > > > > > > > |<=====================================================>| > > > > > > | | > > > | > > > > > > PMK | > > > PMK > > > > > > | | > > > | > > > > > > Generate | > > > Generate > > > > > > SNonce | > > > ANonce > > > > > > | | > > > | > > > > > > > > > > > > > > > > > > In this case, the EAPoL frame generated by the AC will > > > not be based on > > > > > > the prevailing value of the KeyRSC, as this counter is > > > maintained by > > > > > > the WTP. > > > > > > > > > > > > This problem is currently not solved in the CAPWAP > > > specifications. > > > > > > > > > > > > > > > > > > Proposal: > > > > > > > > > > > > The proposal is to include a CAPWAP Key Configuration > > > message that can > > > > > > transport the EAPoL frame between AC and WTP before > > > being sent to the > > > > > > client (terminal). > > > > > > > > > > > > Key Configuration is a control message sent by the AC > > > to the WTP. The > > > > > > message contains Message-3 of the 4-way handshake - > > > including the > > > > > > EAPoL-frame. However, the EAPoL frame has its KeyMIC > > > field unassigned as > > > > > > the AC cannot accurately calculate this. > > > > > > > > > > > > So on receiving the Key Configuration - containing > > > EAPoL frame with > > > > > > unassigned KeyMIC field, the WTP retrieves the value of > > > the KeyRSC it > > > > > > maintains and computes the corresponding KeyMIC. > > > > > > > > > > > > The EAPoL frame is then updated and Message-3 of the > > > 4-way handshake is > > > > > > reconstructed before being sent over the wireless link > > > to the client. > > > > > > > > > > > > > > > > > > The diagram below illustrates this; > > > > > > > > > > > > > > > > > > - 802.11i Crypto > > > > > > (KeyRSC maintained here) - 802.11i > > > Authentication > > > > > > > > > > > > +----------+ +-----+ > > > +------+ > > > > > > | Terminal | | WTP | | > > > AC | > > > > > > +----------+ +-----+ > > > +------+ > > > > > > | | > > > | > > > > > > | 802.1x Authentication > > > | > > > > > > > > > |<=====================================================>| > > > > > > | | > > > | > > > > > > PMK | > > > PMK > > > > > > | | > > > | > > > > > > Generate | > > > Generate > > > > > > SNonce | > > > ANonce > > > > > > | | > > > | > > > > > > | | > > > | > > > > > > | Message 1 > > > | > > > > > > > > > |<-------------------------|<---------------------------| > > > > > > | EAPoL Packet | CAPWAP Packet > > > | > > > > > > Receive | > > > | > > > > > > ANonce | > > > | > > > > > > Generate | > > > | > > > > > > PTK | > > > | > > > > > > | | > > > | > > > > > > | Message 2 > > > | > > > > > > > > > |------------------------->|--------------------------->| > > > > > > | EAPoL Packet | CAPWAP Packet > > > | > > > > > > | | > > > Receive > > > > > > | | > > > SNonce > > > > > > | | > > > | > > > > > > | | > > > Generate > > > > > > | | > > > PTK > > > > > > | | > > > GTK > > > > > > | | Message 3 > > > | > > > > > > | > > > |<===========================| > > > > > > | | CAPWAP Packet > > > | > > > > > > | | (Key Configuration) > > > | > > > > > > | | | > > > +-----------------------+ > > > > > > | | \|- GTK-Flag > > > | > > > > > > | -Retrieve KeyRSC |- > > > Encryption-Data(PTK) | > > > > > > | -Update KeyMIC |- > > > Encryption-Data(GTK) | > > > > > > | -Reconstruct |- EAP-Frame > > > | > > > > > > | Message-3 > > > +-----------------------+ > > > > > > | | > > > | > > > > > > |<-------------------------| > > > | > > > > > > | EAPoL Packet | > > > | > > > > > > Receive | > > > | > > > > > > GTK | > > > | > > > > > > | Message 4 > > > | > > > > > > > > > |------------------------->|--------------------------->| > > > > > > | EAPoL Packet | CAPWAP Packet > > > | > > > > > > | | > > > | > > > > > > > > > > > > > > > > > > > > > > > > This proposal very simply solves the problem while > > > directly addressing > > > > > > the requirement for IEEE 802.11i Considerations. > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Saravanan > > > > > > > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > _________________________________________________________________ > > > Get cheap fares online with MSN Travel > http://www.msn.com.sg/travel/ > > > > > _________________________________________________________________ > > 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 Sep 18 17:05:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPQJD-0004Se-QP for capwap-archive@lists.ietf.org; Mon, 18 Sep 2006 17:05:43 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPQJC-0003rh-Gz for capwap-archive@lists.ietf.org; Mon, 18 Sep 2006 17:05:43 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id CE39C431EC9 for ; Mon, 18 Sep 2006 14:05:38 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 82A5643005F for ; Mon, 18 Sep 2006 14:04:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 656B1431EA5 for ; Mon, 18 Sep 2006 14:04:55 -0700 (PDT) X-Greylist-Status: Sender first seen 00:15:03 ago Received: from colubris.com (ipn36373-e09096.cidr.lightship.net [216.204.238.168]) by hermes.tigertech.net (Postfix) with ESMTP id 5FF47431EAD for ; Mon, 18 Sep 2006 14:04:51 -0700 (PDT) Received: from ([192.168.32.20]) by mail.colubris.com with ESMTP id 4321277.808743; Mon, 18 Sep 2006 16:49:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Sep 2006 16:49:28 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. Thread-Index: AcbbY+9Bkxh1POyVRJyGiifCb5UaZg== From: "Oleg Volinsky" To: 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=FORGED_RCVD_HELO, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 30ac594df0e66ffa5a93eb4c48bcb014 I support splitting the draft. Oleg Volinsky _________________________________________________________________ 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 Sep 18 20:03:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPT5O-0008Qg-MN for capwap-archive@lists.ietf.org; Mon, 18 Sep 2006 20:03:38 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPT5N-0004DJ-8w for capwap-archive@lists.ietf.org; Mon, 18 Sep 2006 20:03:38 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 2A7D9144801D for ; Mon, 18 Sep 2006 17:03:25 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3C5CD43005F for ; Mon, 18 Sep 2006 17:02:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1D95D398049 for ; Mon, 18 Sep 2006 17:02:46 -0700 (PDT) X-Greylist-Status: Sender first seen 1 day 12:08:48 ago Received: from mx01.sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2286139801B for ; Mon, 18 Sep 2006 17:02:43 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Sep 2006 17:02:17 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. Thread-Index: AcbbY+9Bkxh1POyVRJyGiifCb5UaZgAGu9cE References: From: "Abhijit Choudhury" To: X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.051 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO, HTML_MESSAGE X-Spam-Level: Subject: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0197578291==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 This is a multi-part message in MIME format. --===============0197578291== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DB7E.EDC5DDC6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DB7E.EDC5DDC6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I support splitting the draft. =20 Abhijit Choudhury =20 ------_=_NextPart_001_01C6DB7E.EDC5DDC6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29.=0A= =0A= =0A=
=0A=
I support = splitting the =0A= draft.
=0A=
 
=0A=
Abhijit = Choudhury
=0A=
 
=0A= =0A= =0A= ------_=_NextPart_001_01C6DB7E.EDC5DDC6-- --===============0197578291== 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 --===============0197578291==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Sep 19 01:01:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPXjh-0005fd-Aj for capwap-archive@lists.ietf.org; Tue, 19 Sep 2006 01:01:33 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPXje-0007g3-8e for capwap-archive@lists.ietf.org; Tue, 19 Sep 2006 01:01:33 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 720A8398066 for ; Mon, 18 Sep 2006 22:01:20 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 707B943005F for ; Mon, 18 Sep 2006 21:56:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3E0231448049 for ; Mon, 18 Sep 2006 21:56:28 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 94D0D1448039 for ; Mon, 18 Sep 2006 21:56:25 -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 k8J4uOxR012422; Mon, 18 Sep 2006 21:56:24 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k8J4uOXY012418; Mon, 18 Sep 2006 21:56:24 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Mon, 18 Sep 2006 21:56:24 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A202801B5F@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: Saravanan Govindan , capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 935fcc3d6c448ae30077dce3cfc94471 HI, I totally agree with Pat's technical assessment on this issue. Regards, /david t. perkins On Mon, 18 Sep 2006, Pat Calhoun (pacalhou) wrote: > The current specification allows the authenticator to reside in the AC, > while the data packet crypto elements in the WTP. This feature is > already in the specification. The only thing that is not there is the > ability to move various pieces of the authenticator function across both > the WTP and the AC, which I feel is unnecessary because it doesn't add > any features. It just adds modes of operations to the protocol that > creates further interoperability issues between the two devices. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > > Sent: Monday, September 18, 2006 1:08 AM > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > Pat, > > > > The requirement goes beyond distinguishing local / split MAC > > support. It is explicit in the need to support authenticator > > and cyrpto elements located at AC and WTP, respectively. > > > > I find it difficult to interpret it in another way. > > > > I do not think it is right to arbitrarily dismiss a > > compulsory requirement. > > > > The fundamental goal of RFC4564 was to put forth key > > requirements that the protocol has to satisfy. It is a "MUST" > > - I do not see why we are having this extensive discussion. > > > > Saravanan > > > > > > > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Monday, September 18, 2006 12:07 PM > > To: Saravanan Govindan; capwap@frascone.com > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > My thoughts is that the protocol, as defined today, can > > provide complete support for 802.11i in both Local and Split > > MAC. So while we may have agreed on a requirement, my > > objective is to try to keep the protocol as simple as > > possible. I do not see making this change as necessary, > > because there is nothing the protocol is unable to do today. > > Furthermore, I do not see making this change as necessary, > > because it would introduce additional optional features in > > the protocol - and consequently increase complexity. > > > > So I disagree with your comment of not confusing between need > > and stated requirement. When we agreed on requirements, I'm > > not sure we all understood how they could be interpreted. I > > believe we have a very flexible approach today. > > > > so my thought is that if we believe we need to interpret the > > requirement in the way you have, this requirement is not > > required. If we interpret the requirement the way I have (see > > above), then we have already. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Saravanan Govindan > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > Sent: Sunday, September 17, 2006 7:24 PM > > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > Pat, > > > > > > The issue here is about how 802.11i exchanges are done when > > > authenticator is at the AC and crypto elements are at the > > WTP. This is > > > the requirement. > > > > > > The proposal is a way to realize this requirement. > > > > > > Let's not confuse between actual need and stated requirements. We > > > achieved consensus on the mandatory requirement because there is > > > indeed a need for it. > > > > > > Given that this topic has been discussed for a while, I > > would really > > > like to understand your concerns. What are your thoughts on > > realizing > > > this requirement? > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > > Sent: Saturday, September 16, 2006 1:36 AM > > > To: Saravanan Govindan; capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > The "protocol" performs the function of 802.1X/802.11i without any > > > issues in both the SplitMAC and LocalMAC operation. > > > > > > Are you stating this is required because RFC4564 states that > > > flexibility is required, or because there is an actual need > > for this > > > feature? > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > -----Original Message----- > > > > From: Saravanan Govindan [mailto:saravanang@hotmail.com] > > > > Sent: Friday, September 15, 2006 9:00 AM > > > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > Considerations > > > > > > > > I want to emphasize that this is not an "additional" feature > > > > - it is a mandatory requirement from RFC 4564. The protocol > > > currently > > > > does not meet the requirement. > > > > > > > > Saravanan > > > > > > > > > > > > > > > > ----Original Message Follows---- > > > > From: "Pat Calhoun (pacalhou)" > > > > To: "Saravanan Govindan" > > > > , > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > Considerations > > > > Date: Fri, 15 Sep 2006 08:01:32 -0700 > > > > > > > > I understand the proposal, but stand firm on my belief that this > > > > additional mode of operation is unnecessary. While it is > > > possible to > > > > implement, as everything is in a protocol, I believe the WG > > > needs to > > > > focus on fixing the protocol in the areas where it is broken, as > > > > opposed to adding more optional modes that really do not > > change the > > > > outcome of the functions. > > > > > > > > Perhaps what would be more useful is not to describe the > > > method, but > > > > the reason why this is being proposed. I still fail to > > > understand why > > > > you believe this mode of operation is necessary. > > > > > > > > > > > > Pat Calhoun > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: Saravanan Govindan > > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > Sent: Friday, September 15, 2006 2:03 AM > > > > To: capwap@frascone.com > > > > Subject: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > I wanted to give a more detailed explanation for the > > > > IEEE 802.11i Considerations requirement. This note describes > > > > how CAPWAP can be updated to satisfy this requirement > > > > > > > > > > > > > > > > I would like to use this to highlight the proposal > > > > being put forward. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From RFC 4564, Section 5.1.10 IEEE 802.11i Considerations > > > > > > > > > > > > > > > > Protocol Requirement: > > > > > > > > > > > > > > > > The CAPWAP protocol MUST determine the exact structure of the > > > > > > > > centralized WLAN architecture in which > > > > authentication needs to be > > > > > > > > supported, i.e., the location of major > > > > authentication components. > > > > > > > > This may be achieved during WTP initialization where major > > > > > > > > capabilities are distinguished. > > > > > > > > > > > > > > > > The protocol MUST allow for the exchange of key > > > > information when > > > > > > > > authenticator and encryption roles are located in > > > > distinct entities. > > > > > > > > > > > > > > > > > > > > > > > > Following the requirement, CAPWAP needs; > > > > > > > > > > > > > > > > 1. to incorporate authentication & encryption locations in > > > > > > > > capabilities exchange > > > > > > > > > > > > > > > > 2. to exchange key information when authentication and crypt are > > > > > > > > located in different network entities > > > > > > > > > > > > > > > > > > > > > > > > Basic case: > > > > > > > > > > > > > > > > AC does both IEEE 802.11i authentication and > > > > cryptography. For 4-way > > > > > > > > exchange, AC tracks the KeyRSC, which it then uses for > > > > Message-3, > > > > > > > > i.e., AC calculates KeyMIC and updates EAPoL frame. > > > > > > > > > > > > > > > > > > > > > > > > - > > > > 802.11i Authentication > > > > > > > > - > > > > 802.11i Crypto > > > > > > > > > > > > (KeyRSC maintained here) > > > > > > > > > > > > > > > > +----------+ +-----+ > > > > +------+ > > > > > > > > | Terminal | | WTP | | > > > > AC | > > > > > > > > +----------+ +-----+ > > > > +------+ > > > > > > > > | | > > > > | > > > > > > > > | 802.1x Authentication > > > > | > > > > > > > > > > > > |<=====================================================>| > > > > > > > > | | > > > > | > > > > > > > > PMK | > > > > PMK > > > > > > > > | | > > > > | > > > > > > > > Generate | > > > > Generate > > > > > > > > SNonce | > > > > ANonce > > > > > > > > | | > > > > | > > > > > > > > | | > > > > | > > > > > > > > | Message-1 > > > > | > > > > > > > > > > > > |<-------------------------|<---------------------------| > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > | > > > > > > > > Receive | > > > > | > > > > > > > > ANonce | > > > > | > > > > > > > > Generate | > > > > | > > > > > > > > PTK | > > > > | > > > > > > > > | | > > > > | > > > > > > > > | Message-2 > > > > | > > > > > > > > > > > > |------------------------->|--------------------------->| > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > | > > > > > > > > | | > > > > Receive > > > > > > > > | | > > > > SNonce > > > > > > > > | | > > > > | > > > > > > > > | | > > > > Generate > > > > > > > > | | > > > > PTK > > > > > > > > | | > > > > GTK > > > > > > > > | Message-3 > > > > | > > > > > > > > > > > > |<-------------------------|<---------------------------| > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > | > > > > > > > > | | | > > > > | > > > > > > > > | | | > > > > +-----------------------+ > > > > > > > > | | \|- EAPoL Frame > > > > | > > > > > > > > Receive | > > > > +-----------------------+ > > > > > > > > GTK | > > > > | > > > > > > > > | | > > > > | > > > > > > > > | | > > > > | > > > > > > > > | Message-4 > > > > | > > > > > > > > > > > > |------------------------->|--------------------------->| > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > | > > > > > > > > | | > > > > | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Case specified by RFC 4564: > > > > > > > > > > > > > > > > The 802.11i Considerations requirement considers the > > > > case where 802.11i > > > > > > > > authentication is at AC and 802.11i crypto is at WTP. > > > > So now, the WTP > > > > > > > > maintains the KeyRSC while the AC requires this > > > > information to generate > > > > > > > > the EAPoL frame for Message-3 of the 4-way handshake. > > > > > > > > > > > > > > > > The diagram below shows this; > > > > > > > > > > > > > > > > - 802.11i Crypto > > > > > > > > (KeyRSC maintained here) - 802.11i > > > > Authentication > > > > > > > > > > > > > > > > +----------+ +-----+ > > > > +------+ > > > > > > > > | Terminal | | WTP | | > > > > AC | > > > > > > > > +----------+ +-----+ > > > > +------+ > > > > > > > > | | > > > > | > > > > > > > > | 802.1x Authentication > > > > | > > > > > > > > > > > > |<=====================================================>| > > > > > > > > | | > > > > | > > > > > > > > PMK | > > > > PMK > > > > > > > > | | > > > > | > > > > > > > > Generate | > > > > Generate > > > > > > > > SNonce | > > > > ANonce > > > > > > > > | | > > > > | > > > > > > > > > > > > > > > > > > > > > > > > In this case, the EAPoL frame generated by the AC will > > > > not be based on > > > > > > > > the prevailing value of the KeyRSC, as this counter is > > > > maintained by > > > > > > > > the WTP. > > > > > > > > > > > > > > > > This problem is currently not solved in the CAPWAP > > > > specifications. > > > > > > > > > > > > > > > > > > > > > > > > Proposal: > > > > > > > > > > > > > > > > The proposal is to include a CAPWAP Key Configuration > > > > message that can > > > > > > > > transport the EAPoL frame between AC and WTP before > > > > being sent to the > > > > > > > > client (terminal). > > > > > > > > > > > > > > > > Key Configuration is a control message sent by the AC > > > > to the WTP. The > > > > > > > > message contains Message-3 of the 4-way handshake - > > > > including the > > > > > > > > EAPoL-frame. However, the EAPoL frame has its KeyMIC > > > > field unassigned as > > > > > > > > the AC cannot accurately calculate this. > > > > > > > > > > > > > > > > So on receiving the Key Configuration - containing > > > > EAPoL frame with > > > > > > > > unassigned KeyMIC field, the WTP retrieves the value of > > > > the KeyRSC it > > > > > > > > maintains and computes the corresponding KeyMIC. > > > > > > > > > > > > > > > > The EAPoL frame is then updated and Message-3 of the > > > > 4-way handshake is > > > > > > > > reconstructed before being sent over the wireless link > > > > to the client. > > > > > > > > > > > > > > > > > > > > > > > > The diagram below illustrates this; > > > > > > > > > > > > > > > > > > > > > > > > - 802.11i Crypto > > > > > > > > (KeyRSC maintained here) - 802.11i > > > > Authentication > > > > > > > > > > > > > > > > +----------+ +-----+ > > > > +------+ > > > > > > > > | Terminal | | WTP | | > > > > AC | > > > > > > > > +----------+ +-----+ > > > > +------+ > > > > > > > > | | > > > > | > > > > > > > > | 802.1x Authentication > > > > | > > > > > > > > > > > > |<=====================================================>| > > > > > > > > | | > > > > | > > > > > > > > PMK | > > > > PMK > > > > > > > > | | > > > > | > > > > > > > > Generate | > > > > Generate > > > > > > > > SNonce | > > > > ANonce > > > > > > > > | | > > > > | > > > > > > > > | | > > > > | > > > > > > > > | Message 1 > > > > | > > > > > > > > > > > > |<-------------------------|<---------------------------| > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > | > > > > > > > > Receive | > > > > | > > > > > > > > ANonce | > > > > | > > > > > > > > Generate | > > > > | > > > > > > > > PTK | > > > > | > > > > > > > > | | > > > > | > > > > > > > > | Message 2 > > > > | > > > > > > > > > > > > |------------------------->|--------------------------->| > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > | > > > > > > > > | | > > > > Receive > > > > > > > > | | > > > > SNonce > > > > > > > > | | > > > > | > > > > > > > > | | > > > > Generate > > > > > > > > | | > > > > PTK > > > > > > > > | | > > > > GTK > > > > > > > > | | Message 3 > > > > | > > > > > > > > | > > > > |<===========================| > > > > > > > > | | CAPWAP Packet > > > > | > > > > > > > > | | (Key Configuration) > > > > | > > > > > > > > | | | > > > > +-----------------------+ > > > > > > > > | | \|- GTK-Flag > > > > | > > > > > > > > | -Retrieve KeyRSC |- > > > > Encryption-Data(PTK) | > > > > > > > > | -Update KeyMIC |- > > > > Encryption-Data(GTK) | > > > > > > > > | -Reconstruct |- EAP-Frame > > > > | > > > > > > > > | Message-3 > > > > +-----------------------+ > > > > > > > > | | > > > > | > > > > > > > > |<-------------------------| > > > > | > > > > > > > > | EAPoL Packet | > > > > | > > > > > > > > Receive | > > > > | > > > > > > > > GTK | > > > > | > > > > > > > > | Message 4 > > > > | > > > > > > > > > > > > |------------------------->|--------------------------->| > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > | > > > > > > > > | | > > > > | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This proposal very simply solves the problem while > > > > directly addressing > > > > > > > > the requirement for IEEE 802.11i Considerations. > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > Saravanan > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > To unsubscribe or modify your subscription options, please visit: > > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > _________________________________________________________________ > > > > Get cheap fares online with MSN Travel > > http://www.msn.com.sg/travel/ > > > > > > > _________________________________________________________________ > > > 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 Tue Sep 19 01:06:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPXo2-0001Gs-I5 for capwap-archive@lists.ietf.org; Tue, 19 Sep 2006 01:06:02 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPXo1-0000Um-5p for capwap-archive@lists.ietf.org; Tue, 19 Sep 2006 01:06:02 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id BD4D53980AB for ; Mon, 18 Sep 2006 22:06:00 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4DE6643005F for ; Mon, 18 Sep 2006 22:03:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6E6AA39807A for ; Mon, 18 Sep 2006 22:03:41 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 40A4C39806D for ; Mon, 18 Sep 2006 22:03:39 -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 k8J53cSO013944; Mon, 18 Sep 2006 22:03:38 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k8J53cvG013940; Mon, 18 Sep 2006 22:03:38 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Mon, 18 Sep 2006 22:03:38 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Dorothy.Gellert@nokia.com In-Reply-To: <893AE265F4ADF94AB7FB26D31A788E41029E0CCC@mvebe101.NOE.Nokia.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] Consensus call on Split CAPWAP draft by 9/29. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 1ac7cc0a4cd376402b85bc1961a86ac2 HI, I support the splitting. I believe that it will result it increasing the rate of convergence of a solid interoperable implementations. Best 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 outromance@mainediscount.com Tue Sep 19 06:40:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPd1j-0007C4-Kr for capwap-archive@ietf.org; Tue, 19 Sep 2006 06:40:31 -0400 Received: from [219.128.211.38] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GPd0g-0002zr-5w for capwap-archive@ietf.org; Tue, 19 Sep 2006 06:40:31 -0400 Message-ID: <000001c6dbd7$1695b780$0100007f@localhost> From: "Marie-jeanne Fong" To: Subject: Medical Insurance Summary, HM0 Letter #33945 Date: Tue, 19 Sep 2006 18:39:00 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C6DBD7.1695B780" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 1.5 (+) X-Scan-Signature: ba9cd4f9acda58dbe142afff7265daff This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6DBD7.1695B780 Content-Type: multipart/mixed; boundary="----=_NextPart_001_000E_01C6DBD7.1695B780" ------=_NextPart_001_000E_01C6DBD7.1695B780 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Past Due Invoice Attached. ------=_NextPart_000_0001_01C6DBD7.1695B780 Content-Type: application/msword; name="Letter33945.doc" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Letter33945.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAKgAAAAAA AAAAEAAALAAAAAEAAAD+////AAAAACkAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAcWAJBAAA+BK/AAAAAAAAEAAAAAAABgAA 2AgAAA4AYmpianFQcVAAAAAAAAAAAAAAAAAAAAAAAAAJBBYALhAAABM6AQATOgEA2AAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAKQAAAAAAJIEAAAAAAAAkgQAAJIEAAAAAAAAkgQAAAAAAACSBAAA AAAAAJIEAAAAAAAAkgQAABQAAAAAAAAAAAAAAMwEAAC0AAAACAcAAAAAAAAIBwAAAAAAAAgH AAAAAAAACAcAAAwAAAAUBwAADAAAAIAFAAAAAAAAegkAAOwAAAAsBwAAFgAAAEIHAAAAAAAA QgcAAAAAAABCBwAAAAAAAEIHAAAAAAAAHQgAAAAAAAAdCAAAAAAAAB0IAAAAAAAA+QgAAAIA AAD7CAAAAAAAAPsIAAAAAAAA+wgAAAAAAAD7CAAAAAAAAPsIAAAAAAAA+wgAACQAAABmCgAA aAIAAM4MAACGAAAAHwkAABUAAAAAAAAAAAAAAAAAAAAAAAAAkgQAAAAAAAAdCAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAdCAAAAAAAAB0IAAAAAAAAHQgAAAAAAAAdCAAAAAAAAB8JAAAAAAAA AAAAAAAAAACSBAAAAAAAAJIEAAAAAAAAQgcAAAAAAAAAAAAAAAAAAEIHAADbAAAANAkAABYA AABpCAAAAAAAAGkIAAAAAAAAaQgAAAAAAAAdCAAAEAAAAJIEAAAAAAAAQgcAAAAAAACSBAAA AAAAAEIHAAAAAAAA+QgAAAAAAAAAAAAAAAAAAGkIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHQgAAAAAAAD5CAAAAAAAAAAAAAAAAAAA aQgAAAAAAAAAAAAAAAAAAGkIAAAAAAAAkgQAAAAAAACSBAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaQgAAAAAAABCBwAA AAAAACAHAAAMAAAAEMujlT/AxgEAAAAAAAAAAAgHAAAAAAAALQgAABYAAABpCAAAAAAAAAAA AAAAAAAA7QgAAAwAAABKCQAAMAAAAHoJAAAAAAAAaQgAAAAAAABUDQAAAAAAAEMIAAAcAAAA VA0AAAAAAABpCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFQNAAAAAAAAAAAAAAAAAACSBAAA AAAAAGkIAACEAAAAHQgAAAAAAAAdCAAAAAAAAGkIAAAAAAAAHQgAAAAAAAAdCAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHQgAAAAAAAAdCAAAAAAAAB0IAAAAAAAA HwkAAAAAAAAfCQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXwgAAAoA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0IAAAAAAAAHQgAAAAAAAAdCAAA AAAAAHoJAAAAAAAAHQgAAAAAAAAdCAAAAAAAAB0IAAAAAAAAHQgAAAAAAAAAAAAAAAAAAIAF AAAAAAAAgAUAAAAAAACABQAAZAEAAOQGAAAkAAAAgAUAAAAAAACABQAAAAAAAIAFAAAAAAAA 5AYAAAAAAACmBAAAFAAAALoEAAAOAAAAyAQAAAQAAACSBAAAAAAAAJIEAAAAAAAAkgQAAAAA AACSBAAAAAAAAJIEAAAAAAAAkgQAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhvdCBTdW1tZXIgU3BlY2lhbHMhDQ1WaWFncmEgPSAk MyBwZXIgcGlsbCAoMTAwbWcpDQ1WaWFncmEgU29mdCA9ICQzLjY2IHBlciBwaWxsICgxMDBt ZykNDUNpYWxpcyA9ICQzLjc1IHBlciBwaWxsICgyMG1nKQ0NTGV2aXRyYSA9ICQ0LjkwIHBl ciBwaWxsICgyMG1nKQ0NE0hZUEVSTElOSyAiaHR0cDovL21lZHZlZHJ4LmNvbSIBFENsaWNr IEhlcmUgZm9yIG1vcmUgaW5mbyEVDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAADII AAAzCAAAmggAAJsIAACcCAAAuwgAALwIAAC9CAAA1ggAANcIAADYCAAA8+fz28q+qsqcyr4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGxVoBzlWABZoBzlWADBKEQA1 CIFDSjAAYUowACYCCIEDagAAAAAGCAEVaAc5VgAWaGEXEQA1CIFDSjAAVQgBYUowAAAXFWgH OVYAFmgHOVYANQiBQ0owAGFKMAAgA2oAAAAAFWgHOVYAFmgHOVYANQiBQ0owAFUIAWFKMAAA FxVoBzlWABZoBzlWADUIgUNKJABhSiQAFxVoBzlWABZoCCCoADUIgUNKKABhSigAFxVoBzlW ABZoBzlWADUIgUNKKABhSigAAAsABgAAFQgAABYIAAAzCAAANAgAAFkIAABaCAAAeQgAAHoI AACaCAAAmwgAANgIAADyAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADt AAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAA AAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABAAAZ2QHOVYADQAAJmQMAQABUMYIAAAA/wwBAQBnZAc5VgAACwAGAADYCAAA /QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABAQAAQEBLAAxkGgBH7DQLyCw4D0hsAgHIrAIByOQoAUkkKAFJbAAABew 0AIYsNACDJDQAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACbAAAARAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAADQyep5+brOEYyCAKoAS6kLAgAAAAMAAADgyep5+brOEYyCAKoAS6kLKgAAAGgAdAB0 AHAAOgAvAC8AbQBlAGQAdgBlAGQAcgB4AC4AYwBvAG0ALwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhgISABIAAQCcAA8ABAAAAAAA AAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAQPH/AgBAAAwEAAAAAAAA AAAGAE4AbwByAG0AYQBsAAAAAgAAABgAQ0oYAF9IAQRhShgAbUgJBHNICQR0SAkEAAAAAAAA AAAAAAAAAAAAAAAARABBQPL/oQBEAAwFAAAAAAAAAAAWAEQAZQBmAGEAdQBsAHQAIABQAGEA cgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAFIAaQDz/7MAUgAMBQAAAAAAAAAADABUAGEA YgBsAGUAIABOAG8AcgBtAGEAbAAAABwAF/YDAAA01gYAAQoDbAA01gYAAQUDAABh9gMAAAIA CwAAACgAawD0/8EAKAAABQAAAAAAAAAABwBOAG8AIABMAGkAcwB0AAAAAgAAAAAAAABqAJoA swDzAGoADAQAAN43PwAAAAoAVABhAGIAbABlACAARwByAGkAZAAAADcAOlYPABPWMAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAACAA8AAABIAJkA AQACAUgADAUAAAAzjQAAAAwAQgBhAGwAbABvAG8AbgAgAFQAZQB4AHQAAAACABAAFABDShAA T0oDAFFKAwBeSgMAYUoQADYAVUCiABEBNgAMBAAAgBWBAAAACQBIAHkAcABlAHIAbABpAG4A awAAAAwAPioBQioCcGgAAP8AAAAAANgAAAAGAAAQAAAFAP////8BAAAABCEAAP//AQCgepkA AAAAAAAAAADYAAAAAAAAAAAAAAAAAAAAAAAVAAAAFgAAADMAAAA0AAAAWQAAAFoAAAB5AAAA egAAAJoAAACbAAAA2gAAAAT/AADAIQAA8fAEAAABAADAIQAA63QEAAABAADAIQAA63QEAAAB AADAIQAA63QEAAABAADAIQAA63QEAAABAADAIQAA63QEAAABAADAIQAA63QEAAABAADAIQAA 63QEAAABAADAIQAA63QEAAABAADAIQAA1AIEAAABAADAIQAAGlkFAAAAAAAVAAAAFgAAADMA AAA0AAAAWQAAAFoAAAB5AAAAegAAAJoAAACbAAAA2gAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJhAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmEAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAAAAAANoAAABLiAAwABAAAAAAAAABAAAAAAAAAAAAAAAEDp8H AAYAANgIAAAFAAAAAAYAANgIAAAGAAAAAAYAANgIAAAHAAAAmwAAALwAAADWAAAA2AAAABNY FP8VhA8AAPA4AAAAAAAG8BgAAAACCAAAAgAAAAEAAAABAAAAAQAAAAIAAABAAB7xEAAAAP// AAAAAP8AgICAAPcAABAADwAC8JIAAAAQAAjwCAAAAAEAAAABBAAADwAD8DAAAAAPAATwKAAA AAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATwQgAAABIACvAI AAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAE AAAAAQAAAAAAAADXAAAA2gAAAAQAAwAAAAAAwwAAAMcAAADaAAAABwA6AAcAAAAAADQAAAC9 AAAA1wAAANoAAAAFAAcABQAHAAAAAADaAAAABwAbAAAABAAAAAgAAADlAAAAAAAAABoAAABZ NgAArHABAGEXEQDyNCoAmHYvAFJ5OgDRXjwA3jc/AAc5VgCyPlcAvx5mAMRHZwDBW24AfRNy ALcscwAREnoAgBWBAERFgwAAM40ACCCoAOxOvAAnL8IACxXgAB4b4AA1fOwAwVH6AERG/gAA AAAA2gAAAAAAAAD/QAOAAQDXAAAA1wAAAJAkiAVdAV0B1wAAAAAAAADXAAAAAAAAAAIQAAAA AAAAANgAAABgAAAQAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA //8BAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAEAAAARxaQAQAAAgIGAwUEBQIDBId6 ACAAAACACAAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAA NRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAA MyaQAQAAAgsGBAICAgICBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAADUm kAEAAAILBgQDBQQEAgSHegBhAAAAgAgAAAAAAAAA/wEBAAAAAABUAGEAaABvAG0AYQAAACIA BAAxCIgYAPDQAgAAaAEAAAAAMXioRjN4qEaCFaOGBQACAAAAIAAAALgAAAABAAEAAAAEAAMQ AQAAACAAAAC4AAAAAQABAAAAAQAAAAAAAAAhAwDwEAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAIB6AFtAC0AIGBPjQAABEAGQBkAAAAGQAAANcAAADXAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAgAAAAAAAAAAAAkzgxEA8BAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA SFgAAAAAKfD/DwEAAT8AAOQEAAD///9/////f////3////9/////f////3////9/3jc/AAAA AAAyAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAAAAAAEgBTAEEAVgBFACAAWQBPAFUAUgAgAEIA VQBTAEkATgBFAFMAUwAAAAAAAAAOAFcAaQBsAGwAaQBhAG0AIABFAHMAdABoAGUAcgAOAFcA aQBsAGwAaQBhAG0AIABFAHMAdABoAGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEA AADghZ/y+U9oEKuRCAArJ7PZMAAAAJwBAAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAAC8AAAA BAAAAMgAAAAFAAAA4AAAAAYAAADsAAAABwAAAPgAAAAIAAAACAEAAAkAAAAgAQAAEgAAACwB AAAKAAAATAEAAAsAAABYAQAADAAAAGQBAAANAAAAcAEAAA4AAAB8AQAADwAAAIQBAAAQAAAA jAEAABMAAACUAQAAAgAAAOQEAAAeAAAAFAAAAFNBVkUgWU9VUiBCVVNJTkVTUwAAHgAAAAQA AAAAAAAAHgAAABAAAABXaWxsaWFtIEVzdGhlcgAAHgAAAAQAAAAAAAAAHgAAAAQAAAAAAAAA HgAAAAgAAABOb3JtYWwAAB4AAAAQAAAAV2lsbGlhbSBFc3RoZXIAAB4AAAAEAAAANQAAAB4A AAAYAAAATWljcm9zb2Z0IE9mZmljZSBXb3JkAAAAQAAAAACMhkcAAAAAQAAAAACUeJp/PsYB QAAAAAD+A0U/wMYBQAAAAACKiow/wMYBAwAAAAEAAAADAAAAIAAAAAMAAAC4AAAAAwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1Zwu GxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuXAEAABgBAAAMAAAAAQAAAGgAAAAPAAAA cAAAAAUAAACYAAAABgAAAKAAAAARAAAAqAAAABcAAACwAAAACwAAALgAAAAQAAAAwAAAABMA AADIAAAAFgAAANAAAAANAAAA2AAAAAwAAAD3AAAAAgAAAOQEAAAeAAAAIAAAAFBob2VuaXgg TWFuYWdlbWVudCBDb3Jwb3JhdGlvbgAAAwAAAAEAAAADAAAAAQAAAAMAAADXAAAAAwAAAOYV CwALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAAEwAAAFNBVkUgWU9V UiBCVVNJTkVTUwAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAACsAAAAAwAAAAAA AAAgAAAAAQAAADgAAAACAAAAQAAAAAEAAAACAAAADAAAAF9QSURfSExJTktTAAIAAADkBAAA QQAAAGQAAAAGAAAAAwAAAAgAWwADAAAAAAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAFQAAAGgA dAB0AHAAOgAvAC8AbQBlAGQAdgBlAGQAcgB4AC4AYwBvAG0ALwAAAAAAHwAAAAEAAAAAABIA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAD+////CgAAAAsA AAAMAAAADQAAAA4AAAAPAAAAEAAAAP7///8SAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAA /v///xoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAD+////IgAAACMAAAAkAAAAJQAAACYA AAAnAAAAKAAAAP7////9////KwAAAP7////+/////v////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////9SAG8AbwB0ACAARQBuAHQA cgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf// ////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAAAQPKaVP8DGAS0AAACAAAAA AAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAACQAAAAAQAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAABgAAAP////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAAABAAAAAAAABXAG8AcgBkAEQA bwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GgACAQIAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAuEAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAGQAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0A bQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhAAAAABAAAAAAAAABAEMA bwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7///////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGHwAAAE1pY3Jvc29mdCBPZmZp Y2UgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9Dmy cQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------=_NextPart_000_0001_01C6DBD7.1695B780-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Sep 19 07:12:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPdWP-0007pq-Pt for capwap-archive@lists.ietf.org; Tue, 19 Sep 2006 07:12:13 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPdWO-000378-7J for capwap-archive@lists.ietf.org; Tue, 19 Sep 2006 07:12:13 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9F2DC3980AA for ; Tue, 19 Sep 2006 04:12:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D0EDC4300F1 for ; Tue, 19 Sep 2006 04:11:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A3992430D4E for ; Tue, 19 Sep 2006 04:11:01 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [61.144.161.53]) by hermes.tigertech.net (Postfix) with ESMTP id 9EFBD430D49 for ; Tue, 19 Sep 2006 04:10:57 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5U005OF78ABG@szxga01-in.huawei.com> for Capwap@frascone.com; Tue, 19 Sep 2006 19:14:34 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5U009FC789QW@szxga01-in.huawei.com> for Capwap@frascone.com; Tue, 19 Sep 2006 19:14:34 +0800 (CST) Received: from dell60 ([10.18.23.153]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J5U0012H7N3JZ@szxml04-in.huawei.com> for Capwap@frascone.com; Tue, 19 Sep 2006 19:23:32 +0800 (CST) Date: Tue, 19 Sep 2006 16:40:38 +0530 From: sujay In-reply-to: <893AE265F4ADF94AB7FB26D31A788E41029E0CCC@mvebe101.NOE.Nokia.com> To: Dorothy.Gellert@nokia.com, Capwap@frascone.com Message-id: <003901c6dbdc$3dc16390$9917120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcbY82fx0AwmEjxkSO+bTrWL20FI8gC6LvCg 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=HTML_40_50, HTML_MESSAGE X-Spam-Level: Cc: margaret@thingmagic.com Subject: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1822303968==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b This is a multi-part message in MIME format. --===============1822303968== Content-type: multipart/alternative; boundary="Boundary_(ID_o2seWxtdYihs0qP4KGePMQ)" This is a multi-part message in MIME format. --Boundary_(ID_o2seWxtdYihs0qP4KGePMQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I would support for the Split. Regds, Sujay G My Location; http://maps.google.com/maps?ll=14.626109,76.959229 &spn=4.724852,7.525085&t=h&hl=en This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] Sent: Friday, September 15, 2006 11:49 PM To: Capwap@frascone.com Cc: margaret@thingmagic.com; Dorothy.Gellert@nokia.com Subject: [Capwap] Consensus call on Split CAPWAP draft by 9/29. Hi All, The editors feel that there is WG support to split the current CAPWAP protocol draft into 2 drafts, a base draft and then a 802.11 binding draft. The chairs would like to verify consensus with the WG that there is sufficient interest to split the draft before making this change. This issue has been discussed at the last CAPWAP WG meeting during IETF 66 in Montreal where there was no opposition to this request, and limited support on the list. The chairs would like establish consensus on the issue of splitting binding specific details from the base CAPWAP specification. Please submit your opinions on this topic to the WG list by Sept 29th, for a final consensus call on this feature. Best Regards, Dorothy, Mani and Margaret --Boundary_(ID_o2seWxtdYihs0qP4KGePMQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Consensus call on Split CAPWAP draft by 9/29.
I would support for the Split.

Regds,
Sujay G
My Location;
http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=h&hl=en


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

 

From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com]
Sent: Friday, September 15, 2006 11:49 PM
To: Capwap@frascone.com
Cc: margaret@thingmagic.com; Dorothy.Gellert@nokia.com
Subject: [Capwap] Consensus call on Split CAPWAP draft by 9/29.

Hi All,

The editors feel that there is WG support to split the current CAPWAP protocol draft into 2 drafts, a base draft and then a 802.11 binding draft.  The chairs would like to verify consensus with the WG that there is sufficient interest to split the draft before making this change.

This issue has been discussed at the last CAPWAP WG meeting during IETF 66 in Montreal where there was no opposition to this request, and limited support on the list. 

The chairs would like establish consensus on the issue of splitting binding specific details from the base CAPWAP specification.

Please submit your opinions on this topic to the WG list by Sept 29th, for a final consensus call on this feature.

Best Regards,
Dorothy, Mani and Margaret

--Boundary_(ID_o2seWxtdYihs0qP4KGePMQ)-- --===============1822303968== 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 --===============1822303968==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Sep 19 09:22:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPfYx-0005Cw-Tv for capwap-archive@lists.ietf.org; Tue, 19 Sep 2006 09:22:59 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPfYu-0001XT-Ue for capwap-archive@lists.ietf.org; Tue, 19 Sep 2006 09:22:59 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id AD071431791 for ; Tue, 19 Sep 2006 06:22:50 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id A903D43009A for ; Tue, 19 Sep 2006 06:17:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 81940431789 for ; Tue, 19 Sep 2006 06:17:15 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by hermes.tigertech.net (Postfix) with ESMTP id E293B431788 for ; Tue, 19 Sep 2006 06:17:10 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so4812559pyu for ; Tue, 19 Sep 2006 06:17:10 -0700 (PDT) Received: by 10.35.35.17 with SMTP id n17mr11494899pyj; Tue, 19 Sep 2006 06:17:10 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Tue, 19 Sep 2006 06:17:09 -0700 (PDT) Message-ID: <26140d940609190617p7880b5d9kb8a7184705bffca1@mail.gmail.com> Date: Tue, 19 Sep 2006 09:17:09 -0400 From: "Michael Montemurro" To: "David T. Perkins" In-Reply-To: MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A202801B5F@xmb-sjc-235.amer.cisco.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, HTML_60_70, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: Saravanan Govindan , capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1213099322==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b0ea7984e9e2d84601de65ae5960f32c --===============1213099322== Content-Type: multipart/alternative; boundary="----=_Part_5969_31488871.1158671829900" ------=_Part_5969_31488871.1158671829900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I support Pat assessment of this issue. I think what we have in the draft today provides adequate flexibility for centralized security. Mike On 9/19/06, David T. Perkins wrote: > > HI, > > I totally agree with Pat's technical assessment on this issue. > > Regards, > /david t. perkins > > On Mon, 18 Sep 2006, Pat Calhoun (pacalhou) wrote: > > > The current specification allows the authenticator to reside in the AC, > > while the data packet crypto elements in the WTP. This feature is > > already in the specification. The only thing that is not there is the > > ability to move various pieces of the authenticator function across both > > the WTP and the AC, which I feel is unnecessary because it doesn't add > > any features. It just adds modes of operations to the protocol that > > creates further interoperability issues between the two devices. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > > > Sent: Monday, September 18, 2006 1:08 AM > > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > Pat, > > > > > > The requirement goes beyond distinguishing local / split MAC > > > support. It is explicit in the need to support authenticator > > > and cyrpto elements located at AC and WTP, respectively. > > > > > > I find it difficult to interpret it in another way. > > > > > > I do not think it is right to arbitrarily dismiss a > > > compulsory requirement. > > > > > > The fundamental goal of RFC4564 was to put forth key > > > requirements that the protocol has to satisfy. It is a "MUST" > > > - I do not see why we are having this extensive discussion. > > > > > > Saravanan > > > > > > > > > > > > > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > > Sent: Monday, September 18, 2006 12:07 PM > > > To: Saravanan Govindan; capwap@frascone.com > > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > My thoughts is that the protocol, as defined today, can > > > provide complete support for 802.11i in both Local and Split > > > MAC. So while we may have agreed on a requirement, my > > > objective is to try to keep the protocol as simple as > > > possible. I do not see making this change as necessary, > > > because there is nothing the protocol is unable to do today. > > > Furthermore, I do not see making this change as necessary, > > > because it would introduce additional optional features in > > > the protocol - and consequently increase complexity. > > > > > > So I disagree with your comment of not confusing between need > > > and stated requirement. When we agreed on requirements, I'm > > > not sure we all understood how they could be interpreted. I > > > believe we have a very flexible approach today. > > > > > > so my thought is that if we believe we need to interpret the > > > requirement in the way you have, this requirement is not > > > required. If we interpret the requirement the way I have (see > > > above), then we have already. > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit > > > Cisco Systems > > > > > > > > > > > > > -----Original Message----- > > > > From: Saravanan Govindan > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > Sent: Sunday, September 17, 2006 7:24 PM > > > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > > > > Considerations > > > > > > > > Pat, > > > > > > > > The issue here is about how 802.11i exchanges are done when > > > > authenticator is at the AC and crypto elements are at the > > > WTP. This is > > > > the requirement. > > > > > > > > The proposal is a way to realize this requirement. > > > > > > > > Let's not confuse between actual need and stated requirements. We > > > > achieved consensus on the mandatory requirement because there is > > > > indeed a need for it. > > > > > > > > Given that this topic has been discussed for a while, I > > > would really > > > > like to understand your concerns. What are your thoughts on > > > realizing > > > > this requirement? > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > > > Sent: Saturday, September 16, 2006 1:36 AM > > > > To: Saravanan Govindan; capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > Considerations > > > > > > > > The "protocol" performs the function of 802.1X/802.11i without any > > > > issues in both the SplitMAC and LocalMAC operation. > > > > > > > > Are you stating this is required because RFC4564 states that > > > > flexibility is required, or because there is an actual need > > > for this > > > > feature? > > > > > > > > Pat Calhoun > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Saravanan Govindan [mailto:saravanang@hotmail.com] > > > > > Sent: Friday, September 15, 2006 9:00 AM > > > > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > > Considerations > > > > > > > > > > I want to emphasize that this is not an "additional" feature > > > > > - it is a mandatory requirement from RFC 4564. The protocol > > > > currently > > > > > does not meet the requirement. > > > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > ----Original Message Follows---- > > > > > From: "Pat Calhoun (pacalhou)" > > > > > To: "Saravanan Govindan" > > > > > , > > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > > Considerations > > > > > Date: Fri, 15 Sep 2006 08:01:32 -0700 > > > > > > > > > > I understand the proposal, but stand firm on my belief that this > > > > > additional mode of operation is unnecessary. While it is > > > > possible to > > > > > implement, as everything is in a protocol, I believe the WG > > > > needs to > > > > > focus on fixing the protocol in the areas where it is broken, as > > > > > opposed to adding more optional modes that really do not > > > change the > > > > > outcome of the functions. > > > > > > > > > > Perhaps what would be more useful is not to describe the > > > > method, but > > > > > the reason why this is being proposed. I still fail to > > > > understand why > > > > > you believe this mode of operation is necessary. > > > > > > > > > > > > > > > Pat Calhoun > > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > From: Saravanan Govindan > > > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > > Sent: Friday, September 15, 2006 2:03 AM > > > > > To: capwap@frascone.com > > > > > Subject: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > I wanted to give a more detailed explanation for the > > > > > IEEE 802.11i Considerations requirement. This note describes > > > > > how CAPWAP can be updated to satisfy this requirement > > > > > > > > > > > > > > > > > > > > I would like to use this to highlight the proposal > > > > > being put forward. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From RFC 4564, Section 5.1.10 IEEE 802.11i Considerations > > > > > > > > > > > > > > > > > > > > Protocol Requirement: > > > > > > > > > > > > > > > > > > > > The CAPWAP protocol MUST determine the exact structure > of the > > > > > > > > > > centralized WLAN architecture in which > > > > > authentication needs to be > > > > > > > > > > supported, i.e., the location of major > > > > > authentication components. > > > > > > > > > > This may be achieved during WTP initialization where > major > > > > > > > > > > capabilities are distinguished. > > > > > > > > > > > > > > > > > > > > The protocol MUST allow for the exchange of key > > > > > information when > > > > > > > > > > authenticator and encryption roles are located in > > > > > distinct entities. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Following the requirement, CAPWAP needs; > > > > > > > > > > > > > > > > > > > > 1. to incorporate authentication & encryption locations in > > > > > > > > > > capabilities exchange > > > > > > > > > > > > > > > > > > > > 2. to exchange key information when authentication and > crypt are > > > > > > > > > > located in different network entities > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Basic case: > > > > > > > > > > > > > > > > > > > > AC does both IEEE 802.11i authentication and > > > > > cryptography. For 4-way > > > > > > > > > > exchange, AC tracks the KeyRSC, which it then uses for > > > > > Message-3, > > > > > > > > > > i.e., AC calculates KeyMIC and updates EAPoL frame. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > 802.11i Authentication > > > > > > > > > > - > > > > > 802.11i Crypto > > > > > > > > > > > > > > > (KeyRSC maintained here) > > > > > > > > > > > > > > > > > > > > +----------+ +-----+ > > > > > +------+ > > > > > > > > > > | Terminal | | WTP > | | > > > > > AC | > > > > > > > > > > +----------+ +-----+ > > > > > +------+ > > > > > > > > > > | | > > > > > | > > > > > > > > > > | 802.1x Authentication > > > > > | > > > > > > > > > > > > > > > |<=====================================================>| > > > > > > > > > > | | > > > > > | > > > > > > > > > > PMK | > > > > > PMK > > > > > > > > > > | | > > > > > | > > > > > > > > > > Generate | > > > > > Generate > > > > > > > > > > SNonce | > > > > > ANonce > > > > > > > > > > | | > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > | Message-1 > > > > > | > > > > > > > > > > > > > > > |<-------------------------|<---------------------------| > > > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > > | > > > > > > > > > > Receive | > > > > > | > > > > > > > > > > ANonce | > > > > > | > > > > > > > > > > Generate | > > > > > | > > > > > > > > > > PTK | > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > | Message-2 > > > > > | > > > > > > > > > > > > > > > |------------------------->|--------------------------->| > > > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > > | > > > > > > > > > > | | > > > > > Receive > > > > > > > > > > | | > > > > > SNonce > > > > > > > > > > | | > > > > > | > > > > > > > > > > | | > > > > > Generate > > > > > > > > > > | | > > > > > PTK > > > > > > > > > > | | > > > > > GTK > > > > > > > > > > | Message-3 > > > > > | > > > > > > > > > > > > > > > |<-------------------------|<---------------------------| > > > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > > | > > > > > > > > > > | | | > > > > > | > > > > > > > > > > | | | > > > > > +-----------------------+ > > > > > > > > > > | | \|- EAPoL Frame > > > > > | > > > > > > > > > > Receive | > > > > > +-----------------------+ > > > > > > > > > > GTK | > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > | Message-4 > > > > > | > > > > > > > > > > > > > > > |------------------------->|--------------------------->| > > > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Case specified by RFC 4564: > > > > > > > > > > > > > > > > > > > > The 802.11i Considerations requirement considers the > > > > > case where 802.11i > > > > > > > > > > authentication is at AC and 802.11i crypto is at WTP. > > > > > So now, the WTP > > > > > > > > > > maintains the KeyRSC while the AC requires this > > > > > information to generate > > > > > > > > > > the EAPoL frame for Message-3 of the 4-way handshake. > > > > > > > > > > > > > > > > > > > > The diagram below shows this; > > > > > > > > > > > > > > > > > > > > - 802.11i Crypto > > > > > > > > > > (KeyRSC maintained here) - > 802.11i > > > > > Authentication > > > > > > > > > > > > > > > > > > > > +----------+ +-----+ > > > > > +------+ > > > > > > > > > > | Terminal | | WTP > | | > > > > > AC | > > > > > > > > > > +----------+ +-----+ > > > > > +------+ > > > > > > > > > > | | > > > > > | > > > > > > > > > > | 802.1x Authentication > > > > > | > > > > > > > > > > > > > > > |<=====================================================>| > > > > > > > > > > | | > > > > > | > > > > > > > > > > PMK | > > > > > PMK > > > > > > > > > > | | > > > > > | > > > > > > > > > > Generate | > > > > > Generate > > > > > > > > > > SNonce | > > > > > ANonce > > > > > > > > > > | | > > > > > | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In this case, the EAPoL frame generated by the AC will > > > > > not be based on > > > > > > > > > > the prevailing value of the KeyRSC, as this counter is > > > > > maintained by > > > > > > > > > > the WTP. > > > > > > > > > > > > > > > > > > > > This problem is currently not solved in the CAPWAP > > > > > specifications. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Proposal: > > > > > > > > > > > > > > > > > > > > The proposal is to include a CAPWAP Key Configuration > > > > > message that can > > > > > > > > > > transport the EAPoL frame between AC and WTP before > > > > > being sent to the > > > > > > > > > > client (terminal). > > > > > > > > > > > > > > > > > > > > Key Configuration is a control message sent by the AC > > > > > to the WTP. The > > > > > > > > > > message contains Message-3 of the 4-way handshake - > > > > > including the > > > > > > > > > > EAPoL-frame. However, the EAPoL frame has its KeyMIC > > > > > field unassigned as > > > > > > > > > > the AC cannot accurately calculate this. > > > > > > > > > > > > > > > > > > > > So on receiving the Key Configuration - containing > > > > > EAPoL frame with > > > > > > > > > > unassigned KeyMIC field, the WTP retrieves the value of > > > > > the KeyRSC it > > > > > > > > > > maintains and computes the corresponding KeyMIC. > > > > > > > > > > > > > > > > > > > > The EAPoL frame is then updated and Message-3 of the > > > > > 4-way handshake is > > > > > > > > > > reconstructed before being sent over the wireless link > > > > > to the client. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The diagram below illustrates this; > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - 802.11i Crypto > > > > > > > > > > (KeyRSC maintained here) - > 802.11i > > > > > Authentication > > > > > > > > > > > > > > > > > > > > +----------+ +-----+ > > > > > +------+ > > > > > > > > > > | Terminal | | WTP > | | > > > > > AC | > > > > > > > > > > +----------+ +-----+ > > > > > +------+ > > > > > > > > > > | | > > > > > | > > > > > > > > > > | 802.1x Authentication > > > > > | > > > > > > > > > > > > > > > |<=====================================================>| > > > > > > > > > > | | > > > > > | > > > > > > > > > > PMK | > > > > > PMK > > > > > > > > > > | | > > > > > | > > > > > > > > > > Generate | > > > > > Generate > > > > > > > > > > SNonce | > > > > > ANonce > > > > > > > > > > | | > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > | Message 1 > > > > > | > > > > > > > > > > > > > > > |<-------------------------|<---------------------------| > > > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > > | > > > > > > > > > > Receive | > > > > > | > > > > > > > > > > ANonce | > > > > > | > > > > > > > > > > Generate | > > > > > | > > > > > > > > > > PTK | > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > | Message 2 > > > > > | > > > > > > > > > > > > > > > |------------------------->|--------------------------->| > > > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > > | > > > > > > > > > > | | > > > > > Receive > > > > > > > > > > | | > > > > > SNonce > > > > > > > > > > | | > > > > > | > > > > > > > > > > | | > > > > > Generate > > > > > > > > > > | | > > > > > PTK > > > > > > > > > > | | > > > > > GTK > > > > > > > > > > | | Message 3 > > > > > | > > > > > > > > > > | > > > > > |<===========================| > > > > > > > > > > | | CAPWAP Packet > > > > > | > > > > > > > > > > | | (Key > Configuration) > > > > > | > > > > > > > > > > | | | > > > > > +-----------------------+ > > > > > > > > > > | | \|- GTK-Flag > > > > > | > > > > > > > > > > | -Retrieve KeyRSC |- > > > > > Encryption-Data(PTK) | > > > > > > > > > > | -Update KeyMIC |- > > > > > Encryption-Data(GTK) | > > > > > > > > > > | -Reconstruct |- EAP-Frame > > > > > | > > > > > > > > > > | Message-3 > > > > > +-----------------------+ > > > > > > > > > > | | > > > > > | > > > > > > > > > > |<-------------------------| > > > > > | > > > > > > > > > > | EAPoL Packet | > > > > > | > > > > > > > > > > Receive | > > > > > | > > > > > > > > > > GTK | > > > > > | > > > > > > > > > > | Message 4 > > > > > | > > > > > > > > > > > > > > > |------------------------->|--------------------------->| > > > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This proposal very simply solves the problem while > > > > > directly addressing > > > > > > > > > > the requirement for IEEE 802.11i Considerations. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > To unsubscribe or modify your subscription options, please visit: > > > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > > _________________________________________________________________ > > > > > Get cheap fares online with MSN Travel > > > http://www.msn.com.sg/travel/ > > > > > > > > > _________________________________________________________________ > > > > 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 > ------=_Part_5969_31488871.1158671829900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I support Pat assessment of this issue. I think what we have in the draft today provides adequate flexibility for centralized security.
 
Mike


 
On 9/19/06, David T. Perkins <dperkins@dsperkins.com> wrote:
HI,

I totally agree with Pat's technical assessment on this issue.

Regards,
/david t. perkins

On Mon, 18 Sep 2006, Pat Calhoun (pacalhou) wrote:

> The current specification allows the authenticator to reside in the AC,
> while the data packet crypto elements in the WTP. This feature is
> already in the specification. The only thing that is not there is the
> ability to move various pieces of the authenticator function across both
> the WTP and the AC, which I feel is unnecessary because it doesn't add
> any features. It just adds modes of operations to the protocol that
> creates further interoperability issues between the two devices.
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
>
> > -----Original Message-----
> > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
> > Sent: Monday, September 18, 2006 1:08 AM
> > To: Pat Calhoun (pacalhou); capwap@frascone.com
> > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i
> > Considerations
> >
> > Pat,
> >
> > The requirement goes beyond distinguishing local / split MAC
> > support. It is explicit in the need to support authenticator
> > and cyrpto elements located at AC and WTP, respectively.
> >
> > I find it difficult to interpret it in another way.
> >
> > I do not think it is right to arbitrarily dismiss a
> > compulsory requirement.
> >
> > The fundamental goal of RFC4564 was to put forth key
> > requirements that the protocol has to satisfy. It is a "MUST"
> > - I do not see why we are having this extensive discussion.
> >
> > Saravanan
> >
> >
> >
> >
> > -----Original Message-----
> > From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com]
> > Sent: Monday, September 18, 2006 12:07 PM
> > To: Saravanan Govindan; capwap@frascone.com
> > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i
> > Considerations
> >
> > My thoughts is that the protocol, as defined today, can
> > provide complete support for 802.11i in both Local and Split
> > MAC. So while we may have agreed on a requirement, my
> > objective is to try to keep the protocol as simple as
> > possible. I do not see making this change as necessary,
> > because there is nothing the protocol is unable to do today.
> > Furthermore, I do not see making this change as necessary,
> > because it would introduce additional optional features in
> > the protocol - and consequently increase complexity.
> >
> > So I disagree with your comment of not confusing between need
> > and stated requirement. When we agreed on requirements, I'm
> > not sure we all understood how they could be interpreted. I
> > believe we have a very flexible approach today.
> >
> > so my thought is that if we believe we need to interpret the
> > requirement in the way you have, this requirement is not
> > required. If we interpret the requirement the way I have (see
> > above), then we have already.
> >
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit
> > Cisco Systems
> >
> >
> >
> > > -----Original Message-----
> > > From: Saravanan Govindan
> > [mailto:Saravanan.Govindan@sg.panasonic.com]
> > > Sent: Sunday, September 17, 2006 7:24 PM
> > > To: Pat Calhoun (pacalhou); capwap@frascone.com
> > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i
> > > Considerations
> > >
> > > Pat,
> > >
> > > The issue here is about how 802.11i exchanges are done when
> > > authenticator is at the AC and crypto elements are at the
> > WTP. This is
> > > the requirement.
> > >
> > > The proposal is a way to realize this requirement.
> > >
> > > Let's not confuse between actual need and stated requirements. We
> > > achieved consensus on the mandatory requirement because there is
> > > indeed a need for it.
> > >
> > > Given that this topic has been discussed for a while, I
> > would really
> > > like to understand your concerns. What are your thoughts on
> > realizing
> > > this requirement?
> > >
> > > Saravanan
> > >
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
> > > Sent: Saturday, September 16, 2006 1:36 AM
> > > To: Saravanan Govindan; capwap@frascone.com
> > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > > Considerations
> > >
> > > The "protocol" performs the function of 802.1X /802.11i without any
> > > issues in both the SplitMAC and LocalMAC operation.
> > >
> > > Are you stating this is required because RFC4564 states that
> > > flexibility is required, or because there is an actual need
> > for this
> > > feature?
> > >
> > > Pat Calhoun
> > > CTO, Wireless Networking Business Unit Cisco Systems
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Saravanan Govindan [mailto:saravanang@hotmail.com]
> > > > Sent: Friday, September 15, 2006 9:00 AM
> > > > To: Pat Calhoun (pacalhou); capwap@frascone.com
> > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > > > Considerations
> > > >
> > > > I want to emphasize that this is not an "additional" feature
> > > > - it is a mandatory requirement from RFC 4564. The protocol
> > > currently
> > > > does not meet the requirement.
> > > >
> > > > Saravanan
> > > >
> > > >
> > > >
> > > > ----Original Message Follows----
> > > > From: "Pat Calhoun (pacalhou)" <pcalhoun@cisco.com>
> > > > To: "Saravanan Govindan"
> > > > < Saravanan.Govindan@sg.panasonic.com>,<capwap@frascone.com>
> > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > > > Considerations
> > > > Date: Fri, 15 Sep 2006 08:01:32 -0700
> > > >
> > > > I understand the proposal, but stand firm on my belief that this
> > > > additional mode of operation is unnecessary. While it is
> > > possible to
> > > > implement, as everything is in a protocol, I believe the WG
> > > needs to
> > > > focus on fixing the protocol in the areas where it is broken, as
> > > > opposed to adding more optional modes that really do not
> > change the
> > > > outcome of the functions.
> > > >
> > > > Perhaps what would be more useful is not to describe the
> > > method, but
> > > > the reason why this is being proposed. I still fail to
> > > understand why
> > > > you believe this mode of operation is necessary.
> > > >
> > > >
> > > > Pat Calhoun
> > > > CTO, Wireless Networking Business Unit Cisco Systems
> > > >
> > > >
> > > >
> > > >
> > > > ________________________________
> > > >
> > > >         From: Saravanan Govindan
> > > > [mailto:Saravanan.Govindan@sg.panasonic.com ]
> > > >         Sent: Friday, September 15, 2006 2:03 AM
> > > >         To: capwap@frascone.com
> > > >         Subject: [Capwap] Issue 43 - Explanation for 802.11i
> > Considerations
> > > >
> > > >
> > > >
> > > >         All,
> > > >
> > > >
> > > >         I wanted to give a more detailed explanation for the
> > > > IEEE 802.11i Considerations requirement. This note describes
> > > > how CAPWAP can be updated to satisfy this requirement
> > > >
> > > >
> > > >
> > > >         I would like to use this to highlight the proposal
> > > > being put forward.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >         From RFC 4564, Section 5.1.10 IEEE 802.11i Considerations
> > > >
> > > >
> > > >
> > > >            Protocol Requirement:
> > > >
> > > >
> > > >
> > > >            The CAPWAP protocol MUST determine the exact structure of the
> > > >
> > > >            centralized WLAN architecture in which
> > > > authentication needs to be
> > > >
> > > >            supported, i.e., the location of major
> > > > authentication components.
> > > >
> > > >            This may be achieved during WTP initialization where major
> > > >
> > > >            capabilities are distinguished.
> > > >
> > > >
> > > >
> > > >            The protocol MUST allow for the exchange of key
> > > > information when
> > > >
> > > >            authenticator and encryption roles are located in
> > > > distinct entities.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >         Following the requirement, CAPWAP needs;
> > > >
> > > >
> > > >
> > > >         1. to incorporate authentication & encryption locations in
> > > >
> > > >            capabilities exchange
> > > >
> > > >
> > > >
> > > >         2. to exchange key information when authentication and crypt are
> > > >
> > > >            located in different network entities
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >         Basic case:
> > > >
> > > >
> > > >
> > > >         AC does both IEEE 802.11i authentication and
> > > > cryptography. For 4-way
> > > >
> > > >         exchange, AC tracks the KeyRSC, which it then uses for
> > > > Message-3,
> > > >
> > > >         i.e., AC calculates KeyMIC and updates EAPoL frame.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >                                                           -
> > > > 802.11i Authentication
> > > >
> > > >                                                           -
> > > > 802.11i Crypto
> > > >
> > > >
> > > > (KeyRSC maintained here)
> > > >
> > > >
> > > >
> > > >            +----------+                 +-----+
> > > > +------+
> > > >
> > > >            | Terminal |                 | WTP |                     |
> > > > AC  |
> > > >
> > > >            +----------+                 +-----+
> > > > +------+
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >                 |                     802.1x Authentication
> > > > |
> > > >
> > > >
> > > > |<=====================================================>|
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >                PMK                         |
> > > > PMK
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >               Generate                     |
> > > > Generate
> > > >
> > > >                SNonce                      |
> > > > ANonce
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >                 |                      Message-1
> > > > |
> > > >
> > > >
> > > > |<-------------------------|<---------------------------|
> > > >
> > > >                 |       EAPoL Packet       |        CAPWAP Packet
> > > > |
> > > >
> > > >               Receive                      |
> > > > |
> > > >
> > > >                ANonce                      |
> > > > |
> > > >
> > > >               Generate                     |
> > > > |
> > > >
> > > >                PTK                         |
> > > > |
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >                 |                      Message-2
> > > > |
> > > >
> > > >
> > > > |------------------------->|--------------------------->|
> > > >
> > > >                 |       EAPoL Packet       |        CAPWAP Packet
> > > > |
> > > >
> > > >                 |                          |
> > > > Receive
> > > >
> > > >                 |                          |
> > > > SNonce
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >                 |                          |
> > > > Generate
> > > >
> > > >                 |                          |
> > > > PTK
> > > >
> > > >                 |                          |
> > > > GTK
> > > >
> > > >                 |                      Message-3
> > > > |
> > > >
> > > >
> > > > |<-------------------------|<---------------------------|
> > > >
> > > >                 |       EAPoL Packet       |   CAPWAP Packet
> > > > |
> > > >
> > > >                 |                          |      |
> > > > |
> > > >
> > > >                 |                          |      |
> > > > +-----------------------+
> > > >
> > > >                 |                          |       \|- EAPoL Frame
> > > > |
> > > >
> > > >               Receive                      |
> > > > +-----------------------+
> > > >
> > > >                GTK                         |
> > > > |
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >                 |                      Message-4
> > > > |
> > > >
> > > >
> > > > |------------------------->|--------------------------->|
> > > >
> > > >                 |       EAPoL Packet       |         CAPWAP Packet
> > > > |
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >         Case specified by RFC 4564:
> > > >
> > > >
> > > >
> > > >         The 802.11i Considerations requirement considers the
> > > > case where 802.11i
> > > >
> > > >         authentication is at AC and 802.11i crypto is at WTP.
> > > > So now, the WTP
> > > >
> > > >         maintains the KeyRSC while the AC requires this
> > > > information to generate
> > > >
> > > >         the EAPoL frame for Message-3 of the 4-way handshake.
> > > >
> > > >
> > > >
> > > >         The diagram below shows this;
> > > >
> > > >
> > > >
> > > >                                     - 802.11i Crypto
> > > >
> > > >                                  (KeyRSC maintained here)      - 802.11i
> > > > Authentication
> > > >
> > > >
> > > >
> > > >            +----------+                 +-----+
> > > > +------+
> > > >
> > > >            | Terminal |                 | WTP |                     |
> > > > AC  |
> > > >
> > > >            +----------+                 +-----+
> > > > +------+
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >                 |                     802.1x Authentication
> > > > |
> > > >
> > > >
> > > > |<=====================================================>|
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >                PMK                         |
> > > > PMK
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >               Generate                     |
> > > > Generate
> > > >
> > > >                SNonce                      |
> > > > ANonce
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >         In this case, the EAPoL frame generated by the AC will
> > > > not be based on
> > > >
> > > >         the prevailing value of the KeyRSC, as this counter is
> > > > maintained by
> > > >
> > > >         the WTP.
> > > >
> > > >
> > > >
> > > >         This problem is currently not solved in the CAPWAP
> > > > specifications.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >         Proposal:
> > > >
> > > >
> > > >
> > > >         The proposal is to include a CAPWAP Key Configuration
> > > > message that can
> > > >
> > > >         transport the EAPoL frame between AC and WTP before
> > > > being sent to the
> > > >
> > > >         client (terminal).
> > > >
> > > >
> > > >
> > > >         Key Configuration is a control message sent by the AC
> > > > to the WTP. The
> > > >
> > > >         message contains Message-3 of the 4-way handshake -
> > > > including the
> > > >
> > > >         EAPoL-frame. However, the EAPoL frame has its KeyMIC
> > > > field unassigned as
> > > >
> > > >         the AC cannot accurately calculate this.
> > > >
> > > >
> > > >
> > > >         So on receiving the Key Configuration - containing
> > > > EAPoL frame with
> > > >
> > > >         unassigned KeyMIC field, the WTP retrieves the value of
> > > > the KeyRSC it
> > > >
> > > >         maintains and computes the corresponding KeyMIC.
> > > >
> > > >
> > > >
> > > >         The EAPoL frame is then updated and Message-3 of the
> > > > 4-way handshake is
> > > >
> > > >         reconstructed before being sent over the wireless link
> > > > to the client.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >         The diagram below illustrates this;
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >                                     - 802.11i Crypto
> > > >
> > > >                                  (KeyRSC maintained here)      - 802.11i
> > > > Authentication
> > > >
> > > >
> > > >
> > > >            +----------+                 +-----+
> > > > +------+
> > > >
> > > >            | Terminal |                 | WTP |                     |
> > > > AC  |
> > > >
> > > >            +----------+                 +-----+
> > > > +------+
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >                 |                    802.1x Authentication
> > > > |
> > > >
> > > >
> > > > |<=====================================================>|
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >                PMK                         |
> > > > PMK
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >               Generate                     |
> > > > Generate
> > > >
> > > >                SNonce                      |
> > > > ANonce
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >                 |                      Message 1
> > > > |
> > > >
> > > >
> > > > |<-------------------------|<---------------------------|
> > > >
> > > >                 |       EAPoL Packet       |        CAPWAP Packet
> > > > |
> > > >
> > > >               Receive                      |
> > > > |
> > > >
> > > >                ANonce                      |
> > > > |
> > > >
> > > >               Generate                     |
> > > > |
> > > >
> > > >                PTK                         |
> > > > |
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >                 |                      Message 2
> > > > |
> > > >
> > > >
> > > > |------------------------->|--------------------------->|
> > > >
> > > >                 |       EAPoL Packet       |        CAPWAP Packet
> > > > |
> > > >
> > > >                 |                          |
> > > > Receive
> > > >
> > > >                 |                          |
> > > > SNonce
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >                 |                          |
> > > > Generate
> > > >
> > > >                 |                          |
> > > > PTK
> > > >
> > > >                 |                          |
> > > > GTK
> > > >
> > > >                 |                          |          Message 3
> > > > |
> > > >
> > > >                 |
> > > > |<===========================|
> > > >
> > > >                 |                          |        CAPWAP Packet
> > > > |
> > > >
> > > >                 |                          |      (Key Configuration)
> > > > |
> > > >
> > > >                 |                          |      |
> > > > +-----------------------+
> > > >
> > > >                 |                          |       \|- GTK-Flag
> > > > |
> > > >
> > > >                 |                 -Retrieve KeyRSC  |-
> > > > Encryption-Data(PTK) |
> > > >
> > > >                 |                 -Update KeyMIC    |-
> > > > Encryption-Data(GTK) |
> > > >
> > > >                 |                 -Reconstruct      |- EAP-Frame
> > > > |
> > > >
> > > >                 |                     Message-3
> > > > +-----------------------+
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >                 |<-------------------------|
> > > > |
> > > >
> > > >                 |       EAPoL Packet       |
> > > > |
> > > >
> > > >              Receive                       |
> > > > |
> > > >
> > > >               GTK                          |
> > > > |
> > > >
> > > >                 |                      Message 4
> > > > |
> > > >
> > > >
> > > > |------------------------->|--------------------------->|
> > > >
> > > >                 |       EAPoL Packet       |        CAPWAP Packet
> > > > |
> > > >
> > > >                 |                          |
> > > > |
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >         This proposal very simply solves the problem while
> > > > directly addressing
> > > >
> > > >         the requirement for IEEE 802.11i Considerations.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >         Cheers,
> > > >
> > > >
> > > >
> > > >         Saravanan
> > > >
> > > >
> > > >
> > > > _________________________________________________________________
> > > > To unsubscribe or modify your subscription options, please visit:
> > > > http://lists.frascone.com/mailman/listinfo/capwap
> > > >
> > > > Archives: http://lists.frascone.com/pipermail/capwap
> > > >
> > > > _________________________________________________________________
> > > > Get cheap fares online with MSN Travel
> > http://www.msn.com.sg/travel/
> > > >
> > > _________________________________________________________________
> > > 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

------=_Part_5969_31488871.1158671829900-- --===============1213099322== 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 --===============1213099322==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Sep 19 11:49:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhqm-0004gZ-Bv for capwap-archive@lists.ietf.org; Tue, 19 Sep 2006 11:49:32 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPhqh-0003sU-Sw for capwap-archive@lists.ietf.org; Tue, 19 Sep 2006 11:49:32 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 69D8C39805F for ; Tue, 19 Sep 2006 08:49:12 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4302743009A for ; Tue, 19 Sep 2006 08:45:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 313CA398016 for ; Tue, 19 Sep 2006 08:45:12 -0700 (PDT) Received: from huawei-3com.com (h3cml02-in.huawei-3com.com [210.21.230.97]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0101539809B for ; Tue, 19 Sep 2006 08:45:06 -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 <0J5U009EIK95BU@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Tue, 19 Sep 2006 23:55:53 +0800 (CST) Received: from htipl20293 ([10.18.23.103]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J5U00CYIK8VTW@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Tue, 19 Sep 2006 23:55:53 +0800 (CST) Date: Tue, 19 Sep 2006 21:14:54 +0530 From: zhang zhifei In-reply-to: To: capwap@frascone.com Message-id: <000901c6dc02$8d7c80b0$6717120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcbbYupAcLdvdXezR+KGRdXF9yF/bgAn3uwg X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Subject: Re: [Capwap] Capwap Digest, Vol 11, Issue 30 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="iso-2022-jp" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 28aa4dc616a7f0ac0889ef522e9e39ef It$B!G(Bs better to split the CAPWAP to two drafts, one is for the tunnel while the other is for 11MAC binding. -----Original Message----- From: capwap-request@frascone.com [mailto:capwap-request@frascone.com] Sent: 2006$BG/(B9$B7n(B19$BF|(B 1:46 To: capwap@frascone.com Subject: Capwap Digest, Vol 11, Issue 30 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: Consensus call on Split CAPWAP draft by 9/29. (Nelson, David) 2. Re: Consensus call on Split CAPWAP draft by 9/29. (Susan Hares) 3. Re: Consensus call on Split CAPWAP draft by 9/29. (Chiu, Ran-Fun) 4. Re: Issue 43 - Explanation for 802.11i Considerations (Pat Calhoun (pacalhou)) ---------------------------------------------------------------------- Message: 1 Date: Mon, 18 Sep 2006 10:02:44 -0400 From: "Nelson, David" Subject: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. To: Message-ID: <3CFB564E055A594B82C4FE89D21565605A48EF@MABOSEVS2.ets.enterasys.com> Content-Type: text/plain; charset=iso-8859-1 I support splitting the draft. Regards, ? Dave ? David B. Nelson Enterasys Networks, Inc. 50 Minuteman Road Andover, MA 01810-1008 Phone: (978) 684-1330? E-mail: dnelson@enterasys.com ? ________________________________________ From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] Sent: Friday, September 15, 2006 2:19 PM To: Capwap@frascone.com Cc: margaret@thingmagic.com; Dorothy.Gellert@nokia.com Subject: [Capwap] Consensus call on Split CAPWAP draft by 9/29. Hi All, The editors feel that there is WG support to split the current CAPWAP protocol draft into 2 drafts, a base draft and then a 802.11 binding draft.? The chairs would like to verify consensus with the WG that there is sufficient interest to split the draft before making this change. This issue has been discussed at the last CAPWAP WG meeting during IETF 66 in Montreal where there was no opposition to this request, and limited support on the list.? The chairs would like establish consensus on the issue of splitting binding specific details from the base CAPWAP specification. Please submit your opinions on this topic to the WG list by Sept 29th, for a final consensus call on this feature. Best Regards, Dorothy, Mani and Margaret ------------------------------ Message: 2 Date: Mon, 18 Sep 2006 11:14:38 -0600 From: "Susan Hares" Subject: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. To: Message-ID: <6F44D7F6B24A8F4DA0AB46C9BE924F0206F8E9A3@VS4.EXCHPROD.USA.NET> Content-Type: text/plain; charset="us-ascii" I support splitting the draft. Susan Hares shares@nexthop.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.frascone.com/pipermail/capwap/attachments/20060918/c41d4f98/att achment.htm ------------------------------ Message: 3 Date: Mon, 18 Sep 2006 12:39:43 -0500 From: "Chiu, Ran-Fun" Subject: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. To: , Cc: margaret@thingmagic.com Message-ID: <08CA2245AFCF444DB3AC415E47CC40AF1896E5@G3W0072.americas.hpqcorp.net> Content-Type: text/plain; charset="us-ascii" I support to split the current CAPWAP protocol draft into two. Ran-Fun Chiu HP Labs ________________________________ From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] Sent: Friday, September 15, 2006 11:19 AM To: Capwap@frascone.com Cc: margaret@thingmagic.com; Dorothy.Gellert@nokia.com Subject: [Capwap] Consensus call on Split CAPWAP draft by 9/29. Hi All, The editors feel that there is WG support to split the current CAPWAP protocol draft into 2 drafts, a base draft and then a 802.11 binding draft. The chairs would like to verify consensus with the WG that there is sufficient interest to split the draft before making this change. This issue has been discussed at the last CAPWAP WG meeting during IETF 66 in Montreal where there was no opposition to this request, and limited support on the list. The chairs would like establish consensus on the issue of splitting binding specific details from the base CAPWAP specification. Please submit your opinions on this topic to the WG list by Sept 29th, for a final consensus call on this feature. Best Regards, Dorothy, Mani and Margaret -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.frascone.com/pipermail/capwap/attachments/20060918/4a01a52c/att achment.htm ------------------------------ Message: 4 Date: Mon, 18 Sep 2006 13:15:11 -0700 From: "Pat Calhoun (pacalhou)" Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations To: "Saravanan Govindan" , Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202801B5F@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset="us-ascii" The current specification allows the authenticator to reside in the AC, while the data packet crypto elements in the WTP. This feature is already in the specification. The only thing that is not there is the ability to move various pieces of the authenticator function across both the WTP and the AC, which I feel is unnecessary because it doesn't add any features. It just adds modes of operations to the protocol that creates further interoperability issues between the two devices. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Monday, September 18, 2006 1:08 AM > To: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Pat, > > The requirement goes beyond distinguishing local / split MAC > support. It is explicit in the need to support authenticator > and cyrpto elements located at AC and WTP, respectively. > > I find it difficult to interpret it in another way. > > I do not think it is right to arbitrarily dismiss a > compulsory requirement. > > The fundamental goal of RFC4564 was to put forth key > requirements that the protocol has to satisfy. It is a "MUST" > - I do not see why we are having this extensive discussion. > > Saravanan > > > > > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Monday, September 18, 2006 12:07 PM > To: Saravanan Govindan; capwap@frascone.com > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > My thoughts is that the protocol, as defined today, can > provide complete support for 802.11i in both Local and Split > MAC. So while we may have agreed on a requirement, my > objective is to try to keep the protocol as simple as > possible. I do not see making this change as necessary, > because there is nothing the protocol is unable to do today. > Furthermore, I do not see making this change as necessary, > because it would introduce additional optional features in > the protocol - and consequently increase complexity. > > So I disagree with your comment of not confusing between need > and stated requirement. When we agreed on requirements, I'm > not sure we all understood how they could be interpreted. I > believe we have a very flexible approach today. > > so my thought is that if we believe we need to interpret the > requirement in the way you have, this requirement is not > required. If we interpret the requirement the way I have (see > above), then we have already. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Saravanan Govindan > [mailto:Saravanan.Govindan@sg.panasonic.com] > > Sent: Sunday, September 17, 2006 7:24 PM > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > Pat, > > > > The issue here is about how 802.11i exchanges are done when > > authenticator is at the AC and crypto elements are at the > WTP. This is > > the requirement. > > > > The proposal is a way to realize this requirement. > > > > Let's not confuse between actual need and stated requirements. We > > achieved consensus on the mandatory requirement because there is > > indeed a need for it. > > > > Given that this topic has been discussed for a while, I > would really > > like to understand your concerns. What are your thoughts on > realizing > > this requirement? > > > > Saravanan > > > > > > > > > > > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Saturday, September 16, 2006 1:36 AM > > To: Saravanan Govindan; capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > The "protocol" performs the function of 802.1X/802.11i without any > > issues in both the SplitMAC and LocalMAC operation. > > > > Are you stating this is required because RFC4564 states that > > flexibility is required, or because there is an actual need > for this > > feature? > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Saravanan Govindan [mailto:saravanang@hotmail.com] > > > Sent: Friday, September 15, 2006 9:00 AM > > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > I want to emphasize that this is not an "additional" feature > > > - it is a mandatory requirement from RFC 4564. The protocol > > currently > > > does not meet the requirement. > > > > > > Saravanan > > > > > > > > > > > > ----Original Message Follows---- > > > From: "Pat Calhoun (pacalhou)" > > > To: "Saravanan Govindan" > > > , > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > Date: Fri, 15 Sep 2006 08:01:32 -0700 > > > > > > I understand the proposal, but stand firm on my belief that this > > > additional mode of operation is unnecessary. While it is > > possible to > > > implement, as everything is in a protocol, I believe the WG > > needs to > > > focus on fixing the protocol in the areas where it is broken, as > > > opposed to adding more optional modes that really do not > change the > > > outcome of the functions. > > > > > > Perhaps what would be more useful is not to describe the > > method, but > > > the reason why this is being proposed. I still fail to > > understand why > > > you believe this mode of operation is necessary. > > > > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > > > ________________________________ > > > > > > From: Saravanan Govindan > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > Sent: Friday, September 15, 2006 2:03 AM > > > To: capwap@frascone.com > > > Subject: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > > > > > > > > > All, > > > > > > > > > I wanted to give a more detailed explanation for the > > > IEEE 802.11i Considerations requirement. This note describes > > > how CAPWAP can be updated to satisfy this requirement > > > > > > > > > > > > I would like to use this to highlight the proposal > > > being put forward. > > > > > > > > > > > > > > > > > > > > > > > > From RFC 4564, Section 5.1.10 IEEE 802.11i Considerations > > > > > > > > > > > > Protocol Requirement: > > > > > > > > > > > > The CAPWAP protocol MUST determine the exact structure of the > > > > > > centralized WLAN architecture in which > > > authentication needs to be > > > > > > supported, i.e., the location of major > > > authentication components. > > > > > > This may be achieved during WTP initialization where major > > > > > > capabilities are distinguished. > > > > > > > > > > > > The protocol MUST allow for the exchange of key > > > information when > > > > > > authenticator and encryption roles are located in > > > distinct entities. > > > > > > > > > > > > > > > > > > Following the requirement, CAPWAP needs; > > > > > > > > > > > > 1. to incorporate authentication & encryption locations in > > > > > > capabilities exchange > > > > > > > > > > > > 2. to exchange key information when authentication and crypt are > > > > > > located in different network entities > > > > > > > > > > > > > > > > > > Basic case: > > > > > > > > > > > > AC does both IEEE 802.11i authentication and > > > cryptography. For 4-way > > > > > > exchange, AC tracks the KeyRSC, which it then uses for > > > Message-3, > > > > > > i.e., AC calculates KeyMIC and updates EAPoL frame. > > > > > > > > > > > > > > > > > > - > > > 802.11i Authentication > > > > > > - > > > 802.11i Crypto > > > > > > > > > (KeyRSC maintained here) > > > > > > > > > > > > +----------+ +-----+ > > > +------+ > > > > > > | Terminal | | WTP | | > > > AC | > > > > > > +----------+ +-----+ > > > +------+ > > > > > > | | > > > | > > > > > > | 802.1x Authentication > > > | > > > > > > > > > |<=====================================================>| > > > > > > | | > > > | > > > > > > PMK | > > > PMK > > > > > > | | > > > | > > > > > > Generate | > > > Generate > > > > > > SNonce | > > > ANonce > > > > > > | | > > > | > > > > > > | | > > > | > > > > > > | Message-1 > > > | > > > > > > > > > |<-------------------------|<---------------------------| > > > > > > | EAPoL Packet | CAPWAP Packet > > > | > > > > > > Receive | > > > | > > > > > > ANonce | > > > | > > > > > > Generate | > > > | > > > > > > PTK | > > > | > > > > > > | | > > > | > > > > > > | Message-2 > > > | > > > > > > > > > |------------------------->|--------------------------->| > > > > > > | EAPoL Packet | CAPWAP Packet > > > | > > > > > > | | > > > Receive > > > > > > | | > > > SNonce > > > > > > | | > > > | > > > > > > | | > > > Generate > > > > > > | | > > > PTK > > > > > > | | > > > GTK > > > > > > | Message-3 > > > | > > > > > > > > > |<-------------------------|<---------------------------| > > > > > > | EAPoL Packet | CAPWAP Packet > > > | > > > > > > | | | > > > | > > > > > > | | | > > > +-----------------------+ > > > > > > | | \|- EAPoL Frame > > > | > > > > > > Receive | > > > +-----------------------+ > > > > > > GTK | > > > | > > > > > > | | > > > | > > > > > > | | > > > | > > > > > > | Message-4 > > > | > > > > > > > > > |------------------------->|--------------------------->| > > > > > > | EAPoL Packet | CAPWAP Packet > > > | > > > > > > | | > > > | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Case specified by RFC 4564: > > > > > > > > > > > > The 802.11i Considerations requirement considers the > > > case where 802.11i > > > > > > authentication is at AC and 802.11i crypto is at WTP. > > > So now, the WTP > > > > > > maintains the KeyRSC while the AC requires this > > > information to generate > > > > > > the EAPoL frame for Message-3 of the 4-way handshake. > > > > > > > > > > > > The diagram below shows this; > > > > > > > > > > > > - 802.11i Crypto > > > > > > (KeyRSC maintained here) - 802.11i > > > Authentication > > > > > > > > > > > > +----------+ +-----+ > > > +------+ > > > > > > | Terminal | | WTP | | > > > AC | > > > > > > +----------+ +-----+ > > > +------+ > > > > > > | | > > > | > > > > > > | 802.1x Authentication > > > | > > > > > > > > > |<=====================================================>| > > > > > > | | > > > | > > > > > > PMK | > > > PMK > > > > > > | | > > > | > > > > > > Generate | > > > Generate > > > > > > SNonce | > > > ANonce > > > > > > | | > > > | > > > > > > > > > > > > > > > > > > In this case, the EAPoL frame generated by the AC will > > > not be based on > > > > > > the prevailing value of the KeyRSC, as this counter is > > > maintained by > > > > > > the WTP. > > > > > > > > > > > > This problem is currently not solved in the CAPWAP > > > specifications. > > > > > > > > > > > > > > > > > > Proposal: > > > > > > > > > > > > The proposal is to include a CAPWAP Key Configuration > > > message that can > > > > > > transport the EAPoL frame between AC and WTP before > > > being sent to the > > > > > > client (terminal). > > > > > > > > > > > > Key Configuration is a control message sent by the AC > > > to the WTP. The > > > > > > message contains Message-3 of the 4-way handshake - > > > including the > > > > > > EAPoL-frame. However, the EAPoL frame has its KeyMIC > > > field unassigned as > > > > > > the AC cannot accurately calculate this. > > > > > > > > > > > > So on receiving the Key Configuration - containing > > > EAPoL frame with > > > > > > unassigned KeyMIC field, the WTP retrieves the value of > > > the KeyRSC it > > > > > > maintains and computes the corresponding KeyMIC. > > > > > > > > > > > > The EAPoL frame is then updated and Message-3 of the > > > 4-way handshake is > > > > > > reconstructed before being sent over the wireless link > > > to the client. > > > > > > > > > > > > > > > > > > The diagram below illustrates this; > > > > > > > > > > > > > > > > > > - 802.11i Crypto > > > > > > (KeyRSC maintained here) - 802.11i > > > Authentication > > > > > > > > > > > > +----------+ +-----+ > > > +------+ > > > > > > | Terminal | | WTP | | > > > AC | > > > > > > +----------+ +-----+ > > > +------+ > > > > > > | | > > > | > > > > > > | 802.1x Authentication > > > | > > > > > > > > > |<=====================================================>| > > > > > > | | > > > | > > > > > > PMK | > > > PMK > > > > > > | | > > > | > > > > > > Generate | > > > Generate > > > > > > SNonce | > > > ANonce > > > > > > | | > > > | > > > > > > | | > > > | > > > > > > | Message 1 > > > | > > > > > > > > > |<-------------------------|<---------------------------| > > > > > > | EAPoL Packet | CAPWAP Packet > > > | > > > > > > Receive | > > > | > > > > > > ANonce | > > > | > > > > > > Generate | > > > | > > > > > > PTK | > > > | > > > > > > | | > > > | > > > > > > | Message 2 > > > | > > > > > > > > > |------------------------->|--------------------------->| > > > > > > | EAPoL Packet | CAPWAP Packet > > > | > > > > > > | | > > > Receive > > > > > > | | > > > SNonce > > > > > > | | > > > | > > > > > > | | > > > Generate > > > > > > | | > > > PTK > > > > > > | | > > > GTK > > > > > > | | Message 3 > > > | > > > > > > | > > > |<===========================| > > > > > > | | CAPWAP Packet > > > | > > > > > > | | (Key Configuration) > > > | > > > > > > | | | > > > +-----------------------+ > > > > > > | | \|- GTK-Flag > > > | > > > > > > | -Retrieve KeyRSC |- > > > Encryption-Data(PTK) | > > > > > > | -Update KeyMIC |- > > > Encryption-Data(GTK) | > > > > > > | -Reconstruct |- EAP-Frame > > > | > > > > > > | Message-3 > > > +-----------------------+ > > > > > > | | > > > | > > > > > > |<-------------------------| > > > | > > > > > > | EAPoL Packet | > > > | > > > > > > Receive | > > > | > > > > > > GTK | > > > | > > > > > > | Message 4 > > > | > > > > > > > > > |------------------------->|--------------------------->| > > > > > > | EAPoL Packet | CAPWAP Packet > > > | > > > > > > | | > > > | > > > > > > > > > > > > > > > > > > > > > > > > This proposal very simply solves the problem while > > > directly addressing > > > > > > the requirement for IEEE 802.11i Considerations. > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Saravanan > > > > > > > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > _________________________________________________________________ > > > Get cheap fares online with MSN Travel > http://www.msn.com.sg/travel/ > > > > > _________________________________________________________________ > > 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 End of Capwap Digest, Vol 11, Issue 30 ************************************** _________________________________________________________________ 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 Sep 19 11:52:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhtb-00077t-V9 for capwap-archive@lists.ietf.org; Tue, 19 Sep 2006 11:52:27 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPhtZ-0004GA-Ia for capwap-archive@lists.ietf.org; Tue, 19 Sep 2006 11:52:27 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0B1CF3980C6 for ; Tue, 19 Sep 2006 08:52:25 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9646D43009A for ; Tue, 19 Sep 2006 08:46:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 87D0D431766 for ; Tue, 19 Sep 2006 08:46:16 -0700 (PDT) Received: from huawei-3com.com (h3cml02-in.huawei-3com.com [210.21.230.97]) by hermes.tigertech.net (Postfix) with ESMTP id 5E352430BC2 for ; Tue, 19 Sep 2006 08:46:12 -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 <0J5U009G7KAYBU@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Tue, 19 Sep 2006 23:56:58 +0800 (CST) Received: from htipl20293 ([10.18.23.103]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J5U00CZ7KAUTW@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Tue, 19 Sep 2006 23:56:58 +0800 (CST) Date: Tue, 19 Sep 2006 21:16:05 +0530 From: zhang zhifei In-reply-to: To: capwap@frascone.com Message-id: <000a01c6dc02$b7e855e0$6717120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acbb8bBqI40tGYxnR2mvGBozqFDuAgAEPOog 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: Subject: Re: [Capwap] Capwap Digest, Vol 11, Issue 32 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="iso-2022-jp" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cc6ce33a3e165c84359672fc0328059 I would support the split. -----Original Message----- From: capwap-request@frascone.com [mailto:capwap-request@frascone.com] Sent: 2006$BG/(B9$B7n(B19$BF|(B 18:47 To: capwap@frascone.com Subject: Capwap Digest, Vol 11, Issue 32 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: Consensus call on Split CAPWAP draft by 9/29. (sujay) 2. Re: Issue 43 - Explanation for 802.11i Considerations (Michael Montemurro) ---------------------------------------------------------------------- Message: 1 Date: Tue, 19 Sep 2006 16:40:38 +0530 From: sujay Subject: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29. To: Dorothy.Gellert@nokia.com, Capwap@frascone.com Cc: margaret@thingmagic.com Message-ID: <003901c6dbdc$3dc16390$9917120a@china.huawei.com> Content-Type: text/plain; charset="us-ascii" I would support for the Split. Regds, Sujay G My Location; http://maps.google.com/maps?ll=14.626109,76.959229 &spn=4.724852,7.525085&t=h&hl=en This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] Sent: Friday, September 15, 2006 11:49 PM To: Capwap@frascone.com Cc: margaret@thingmagic.com; Dorothy.Gellert@nokia.com Subject: [Capwap] Consensus call on Split CAPWAP draft by 9/29. Hi All, The editors feel that there is WG support to split the current CAPWAP protocol draft into 2 drafts, a base draft and then a 802.11 binding draft. The chairs would like to verify consensus with the WG that there is sufficient interest to split the draft before making this change. This issue has been discussed at the last CAPWAP WG meeting during IETF 66 in Montreal where there was no opposition to this request, and limited support on the list. The chairs would like establish consensus on the issue of splitting binding specific details from the base CAPWAP specification. Please submit your opinions on this topic to the WG list by Sept 29th, for a final consensus call on this feature. Best Regards, Dorothy, Mani and Margaret -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.frascone.com/pipermail/capwap/attachments/20060919/f67c8fd7/att achment.htm ------------------------------ Message: 2 Date: Tue, 19 Sep 2006 09:17:09 -0400 From: "Michael Montemurro" Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations To: "David T. Perkins" Cc: Saravanan Govindan , capwap@frascone.com Message-ID: <26140d940609190617p7880b5d9kb8a7184705bffca1@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" I support Pat assessment of this issue. I think what we have in the draft today provides adequate flexibility for centralized security. Mike On 9/19/06, David T. Perkins wrote: > > HI, > > I totally agree with Pat's technical assessment on this issue. > > Regards, > /david t. perkins > > On Mon, 18 Sep 2006, Pat Calhoun (pacalhou) wrote: > > > The current specification allows the authenticator to reside in the AC, > > while the data packet crypto elements in the WTP. This feature is > > already in the specification. The only thing that is not there is the > > ability to move various pieces of the authenticator function across both > > the WTP and the AC, which I feel is unnecessary because it doesn't add > > any features. It just adds modes of operations to the protocol that > > creates further interoperability issues between the two devices. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > > > Sent: Monday, September 18, 2006 1:08 AM > > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > Pat, > > > > > > The requirement goes beyond distinguishing local / split MAC > > > support. It is explicit in the need to support authenticator > > > and cyrpto elements located at AC and WTP, respectively. > > > > > > I find it difficult to interpret it in another way. > > > > > > I do not think it is right to arbitrarily dismiss a > > > compulsory requirement. > > > > > > The fundamental goal of RFC4564 was to put forth key > > > requirements that the protocol has to satisfy. It is a "MUST" > > > - I do not see why we are having this extensive discussion. > > > > > > Saravanan > > > > > > > > > > > > > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > > Sent: Monday, September 18, 2006 12:07 PM > > > To: Saravanan Govindan; capwap@frascone.com > > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > My thoughts is that the protocol, as defined today, can > > > provide complete support for 802.11i in both Local and Split > > > MAC. So while we may have agreed on a requirement, my > > > objective is to try to keep the protocol as simple as > > > possible. I do not see making this change as necessary, > > > because there is nothing the protocol is unable to do today. > > > Furthermore, I do not see making this change as necessary, > > > because it would introduce additional optional features in > > > the protocol - and consequently increase complexity. > > > > > > So I disagree with your comment of not confusing between need > > > and stated requirement. When we agreed on requirements, I'm > > > not sure we all understood how they could be interpreted. I > > > believe we have a very flexible approach today. > > > > > > so my thought is that if we believe we need to interpret the > > > requirement in the way you have, this requirement is not > > > required. If we interpret the requirement the way I have (see > > > above), then we have already. > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit > > > Cisco Systems > > > > > > > > > > > > > -----Original Message----- > > > > From: Saravanan Govindan > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > Sent: Sunday, September 17, 2006 7:24 PM > > > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > > > > Considerations > > > > > > > > Pat, > > > > > > > > The issue here is about how 802.11i exchanges are done when > > > > authenticator is at the AC and crypto elements are at the > > > WTP. This is > > > > the requirement. > > > > > > > > The proposal is a way to realize this requirement. > > > > > > > > Let's not confuse between actual need and stated requirements. We > > > > achieved consensus on the mandatory requirement because there is > > > > indeed a need for it. > > > > > > > > Given that this topic has been discussed for a while, I > > > would really > > > > like to understand your concerns. What are your thoughts on > > > realizing > > > > this requirement? > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > > > Sent: Saturday, September 16, 2006 1:36 AM > > > > To: Saravanan Govindan; capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > Considerations > > > > > > > > The "protocol" performs the function of 802.1X/802.11i without any > > > > issues in both the SplitMAC and LocalMAC operation. > > > > > > > > Are you stating this is required because RFC4564 states that > > > > flexibility is required, or because there is an actual need > > > for this > > > > feature? > > > > > > > > Pat Calhoun > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Saravanan Govindan [mailto:saravanang@hotmail.com] > > > > > Sent: Friday, September 15, 2006 9:00 AM > > > > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > > Considerations > > > > > > > > > > I want to emphasize that this is not an "additional" feature > > > > > - it is a mandatory requirement from RFC 4564. The protocol > > > > currently > > > > > does not meet the requirement. > > > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > ----Original Message Follows---- > > > > > From: "Pat Calhoun (pacalhou)" > > > > > To: "Saravanan Govindan" > > > > > , > > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > > Considerations > > > > > Date: Fri, 15 Sep 2006 08:01:32 -0700 > > > > > > > > > > I understand the proposal, but stand firm on my belief that this > > > > > additional mode of operation is unnecessary. While it is > > > > possible to > > > > > implement, as everything is in a protocol, I believe the WG > > > > needs to > > > > > focus on fixing the protocol in the areas where it is broken, as > > > > > opposed to adding more optional modes that really do not > > > change the > > > > > outcome of the functions. > > > > > > > > > > Perhaps what would be more useful is not to describe the > > > > method, but > > > > > the reason why this is being proposed. I still fail to > > > > understand why > > > > > you believe this mode of operation is necessary. > > > > > > > > > > > > > > > Pat Calhoun > > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > From: Saravanan Govindan > > > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > > Sent: Friday, September 15, 2006 2:03 AM > > > > > To: capwap@frascone.com > > > > > Subject: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > I wanted to give a more detailed explanation for the > > > > > IEEE 802.11i Considerations requirement. This note describes > > > > > how CAPWAP can be updated to satisfy this requirement > > > > > > > > > > > > > > > > > > > > I would like to use this to highlight the proposal > > > > > being put forward. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From RFC 4564, Section 5.1.10 IEEE 802.11i Considerations > > > > > > > > > > > > > > > > > > > > Protocol Requirement: > > > > > > > > > > > > > > > > > > > > The CAPWAP protocol MUST determine the exact structure > of the > > > > > > > > > > centralized WLAN architecture in which > > > > > authentication needs to be > > > > > > > > > > supported, i.e., the location of major > > > > > authentication components. > > > > > > > > > > This may be achieved during WTP initialization where > major > > > > > > > > > > capabilities are distinguished. > > > > > > > > > > > > > > > > > > > > The protocol MUST allow for the exchange of key > > > > > information when > > > > > > > > > > authenticator and encryption roles are located in > > > > > distinct entities. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Following the requirement, CAPWAP needs; > > > > > > > > > > > > > > > > > > > > 1. to incorporate authentication & encryption locations in > > > > > > > > > > capabilities exchange > > > > > > > > > > > > > > > > > > > > 2. to exchange key information when authentication and > crypt are > > > > > > > > > > located in different network entities > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Basic case: > > > > > > > > > > > > > > > > > > > > AC does both IEEE 802.11i authentication and > > > > > cryptography. For 4-way > > > > > > > > > > exchange, AC tracks the KeyRSC, which it then uses for > > > > > Message-3, > > > > > > > > > > i.e., AC calculates KeyMIC and updates EAPoL frame. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > 802.11i Authentication > > > > > > > > > > - > > > > > 802.11i Crypto > > > > > > > > > > > > > > > (KeyRSC maintained here) > > > > > > > > > > > > > > > > > > > > +----------+ +-----+ > > > > > +------+ > > > > > > > > > > | Terminal | | WTP > | | > > > > > AC | > > > > > > > > > > +----------+ +-----+ > > > > > +------+ > > > > > > > > > > | | > > > > > | > > > > > > > > > > | 802.1x Authentication > > > > > | > > > > > > > > > > > > > > > |<=====================================================>| > > > > > > > > > > | | > > > > > | > > > > > > > > > > PMK | > > > > > PMK > > > > > > > > > > | | > > > > > | > > > > > > > > > > Generate | > > > > > Generate > > > > > > > > > > SNonce | > > > > > ANonce > > > > > > > > > > | | > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > | Message-1 > > > > > | > > > > > > > > > > > > > > > |<-------------------------|<---------------------------| > > > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > > | > > > > > > > > > > Receive | > > > > > | > > > > > > > > > > ANonce | > > > > > | > > > > > > > > > > Generate | > > > > > | > > > > > > > > > > PTK | > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > | Message-2 > > > > > | > > > > > > > > > > > > > > > |------------------------->|--------------------------->| > > > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > > | > > > > > > > > > > | | > > > > > Receive > > > > > > > > > > | | > > > > > SNonce > > > > > > > > > > | | > > > > > | > > > > > > > > > > | | > > > > > Generate > > > > > > > > > > | | > > > > > PTK > > > > > > > > > > | | > > > > > GTK > > > > > > > > > > | Message-3 > > > > > | > > > > > > > > > > > > > > > |<-------------------------|<---------------------------| > > > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > > | > > > > > > > > > > | | | > > > > > | > > > > > > > > > > | | | > > > > > +-----------------------+ > > > > > > > > > > | | \|- EAPoL Frame > > > > > | > > > > > > > > > > Receive | > > > > > +-----------------------+ > > > > > > > > > > GTK | > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > | Message-4 > > > > > | > > > > > > > > > > > > > > > |------------------------->|--------------------------->| > > > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Case specified by RFC 4564: > > > > > > > > > > > > > > > > > > > > The 802.11i Considerations requirement considers the > > > > > case where 802.11i > > > > > > > > > > authentication is at AC and 802.11i crypto is at WTP. > > > > > So now, the WTP > > > > > > > > > > maintains the KeyRSC while the AC requires this > > > > > information to generate > > > > > > > > > > the EAPoL frame for Message-3 of the 4-way handshake. > > > > > > > > > > > > > > > > > > > > The diagram below shows this; > > > > > > > > > > > > > > > > > > > > - 802.11i Crypto > > > > > > > > > > (KeyRSC maintained here) - > 802.11i > > > > > Authentication > > > > > > > > > > > > > > > > > > > > +----------+ +-----+ > > > > > +------+ > > > > > > > > > > | Terminal | | WTP > | | > > > > > AC | > > > > > > > > > > +----------+ +-----+ > > > > > +------+ > > > > > > > > > > | | > > > > > | > > > > > > > > > > | 802.1x Authentication > > > > > | > > > > > > > > > > > > > > > |<=====================================================>| > > > > > > > > > > | | > > > > > | > > > > > > > > > > PMK | > > > > > PMK > > > > > > > > > > | | > > > > > | > > > > > > > > > > Generate | > > > > > Generate > > > > > > > > > > SNonce | > > > > > ANonce > > > > > > > > > > | | > > > > > | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In this case, the EAPoL frame generated by the AC will > > > > > not be based on > > > > > > > > > > the prevailing value of the KeyRSC, as this counter is > > > > > maintained by > > > > > > > > > > the WTP. > > > > > > > > > > > > > > > > > > > > This problem is currently not solved in the CAPWAP > > > > > specifications. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Proposal: > > > > > > > > > > > > > > > > > > > > The proposal is to include a CAPWAP Key Configuration > > > > > message that can > > > > > > > > > > transport the EAPoL frame between AC and WTP before > > > > > being sent to the > > > > > > > > > > client (terminal). > > > > > > > > > > > > > > > > > > > > Key Configuration is a control message sent by the AC > > > > > to the WTP. The > > > > > > > > > > message contains Message-3 of the 4-way handshake - > > > > > including the > > > > > > > > > > EAPoL-frame. However, the EAPoL frame has its KeyMIC > > > > > field unassigned as > > > > > > > > > > the AC cannot accurately calculate this. > > > > > > > > > > > > > > > > > > > > So on receiving the Key Configuration - containing > > > > > EAPoL frame with > > > > > > > > > > unassigned KeyMIC field, the WTP retrieves the value of > > > > > the KeyRSC it > > > > > > > > > > maintains and computes the corresponding KeyMIC. > > > > > > > > > > > > > > > > > > > > The EAPoL frame is then updated and Message-3 of the > > > > > 4-way handshake is > > > > > > > > > > reconstructed before being sent over the wireless link > > > > > to the client. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The diagram below illustrates this; > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - 802.11i Crypto > > > > > > > > > > (KeyRSC maintained here) - > 802.11i > > > > > Authentication > > > > > > > > > > > > > > > > > > > > +----------+ +-----+ > > > > > +------+ > > > > > > > > > > | Terminal | | WTP > | | > > > > > AC | > > > > > > > > > > +----------+ +-----+ > > > > > +------+ > > > > > > > > > > | | > > > > > | > > > > > > > > > > | 802.1x Authentication > > > > > | > > > > > > > > > > > > > > > |<=====================================================>| > > > > > > > > > > | | > > > > > | > > > > > > > > > > PMK | > > > > > PMK > > > > > > > > > > | | > > > > > | > > > > > > > > > > Generate | > > > > > Generate > > > > > > > > > > SNonce | > > > > > ANonce > > > > > > > > > > | | > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > | Message 1 > > > > > | > > > > > > > > > > > > > > > |<-------------------------|<---------------------------| > > > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > > | > > > > > > > > > > Receive | > > > > > | > > > > > > > > > > ANonce | > > > > > | > > > > > > > > > > Generate | > > > > > | > > > > > > > > > > PTK | > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > | Message 2 > > > > > | > > > > > > > > > > > > > > > |------------------------->|--------------------------->| > > > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > > | > > > > > > > > > > | | > > > > > Receive > > > > > > > > > > | | > > > > > SNonce > > > > > > > > > > | | > > > > > | > > > > > > > > > > | | > > > > > Generate > > > > > > > > > > | | > > > > > PTK > > > > > > > > > > | | > > > > > GTK > > > > > > > > > > | | Message 3 > > > > > | > > > > > > > > > > | > > > > > |<===========================| > > > > > > > > > > | | CAPWAP Packet > > > > > | > > > > > > > > > > | | (Key > Configuration) > > > > > | > > > > > > > > > > | | | > > > > > +-----------------------+ > > > > > > > > > > | | \|- GTK-Flag > > > > > | > > > > > > > > > > | -Retrieve KeyRSC |- > > > > > Encryption-Data(PTK) | > > > > > > > > > > | -Update KeyMIC |- > > > > > Encryption-Data(GTK) | > > > > > > > > > > | -Reconstruct |- EAP-Frame > > > > > | > > > > > > > > > > | Message-3 > > > > > +-----------------------+ > > > > > > > > > > | | > > > > > | > > > > > > > > > > |<-------------------------| > > > > > | > > > > > > > > > > | EAPoL Packet | > > > > > | > > > > > > > > > > Receive | > > > > > | > > > > > > > > > > GTK | > > > > > | > > > > > > > > > > | Message 4 > > > > > | > > > > > > > > > > > > > > > |------------------------->|--------------------------->| > > > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This proposal very simply solves the problem while > > > > > directly addressing > > > > > > > > > > the requirement for IEEE 802.11i Considerations. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > To unsubscribe or modify your subscription options, please visit: > > > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > > _________________________________________________________________ > > > > > Get cheap fares online with MSN Travel > > > http://www.msn.com.sg/travel/ > > > > > > > > > _________________________________________________________________ > > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.frascone.com/pipermail/capwap/attachments/20060919/9f9d0a4a/att achment.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 11, Issue 32 ************************************** _________________________________________________________________ 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 Sep 19 14:10:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPk3V-0007gh-Qu for capwap-archive@lists.ietf.org; Tue, 19 Sep 2006 14:10:49 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPk3N-0001Vl-NY for capwap-archive@lists.ietf.org; Tue, 19 Sep 2006 14:10:49 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id D6E4F144804A for ; Tue, 19 Sep 2006 11:10:28 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4844343009A for ; Tue, 19 Sep 2006 11:06:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 30C413980B6 for ; Tue, 19 Sep 2006 11:06:50 -0700 (PDT) Received: from ccerelbas04.cce.hp.com (ccerelbas04.cce.hp.com [161.114.21.107]) by zoidberg.tigertech.net (Postfix) with ESMTP id 48A5C39805F for ; Tue, 19 Sep 2006 11:06:42 -0700 (PDT) Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.81.1.38]) by ccerelbas04.cce.hp.com (Postfix) with ESMTP id 437E2344C7; Tue, 19 Sep 2006 13:06:37 -0500 (CDT) Received: from G3W0072.americas.hpqcorp.net ([16.232.1.11]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Sep 2006 13:06:28 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Sep 2006 13:06:27 -0500 Message-ID: <08CA2245AFCF444DB3AC415E47CC40AF189A3F@G3W0072.americas.hpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: Acbbq24qEpjQuDzlTd24UK44+r7AAAAar8rw From: "Chiu, Ran-Fun" To: "David T. Perkins" , "Pat Calhoun (pacalhou)" X-OriginalArrivalTime: 19 Sep 2006 18:06:28.0304 (UTC) FILETIME=[53FBCD00:01C6DC16] 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: Saravanan Govindan , capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 3f5efd9d415d254aec2f521f63a5384c I second. Ran-Fun Chiu HP Labs > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Monday, September 18, 2006 9:56 PM > To: Pat Calhoun (pacalhou) > Cc: Saravanan Govindan; capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > HI, > > I totally agree with Pat's technical assessment on this issue. > > Regards, > /david t. perkins > > On Mon, 18 Sep 2006, Pat Calhoun (pacalhou) wrote: > > > The current specification allows the authenticator to reside in the AC, > > while the data packet crypto elements in the WTP. This feature is > > already in the specification. The only thing that is not there is the > > ability to move various pieces of the authenticator function across both > > the WTP and the AC, which I feel is unnecessary because it doesn't add > > any features. It just adds modes of operations to the protocol that > > creates further interoperability issues between the two devices. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > > > Sent: Monday, September 18, 2006 1:08 AM > > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > Pat, > > > > > > The requirement goes beyond distinguishing local / split MAC > > > support. It is explicit in the need to support authenticator > > > and cyrpto elements located at AC and WTP, respectively. > > > > > > I find it difficult to interpret it in another way. > > > > > > I do not think it is right to arbitrarily dismiss a > > > compulsory requirement. > > > > > > The fundamental goal of RFC4564 was to put forth key > > > requirements that the protocol has to satisfy. It is a "MUST" > > > - I do not see why we are having this extensive discussion. > > > > > > Saravanan > > > > > > > > > > > > > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > > Sent: Monday, September 18, 2006 12:07 PM > > > To: Saravanan Govindan; capwap@frascone.com > > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > My thoughts is that the protocol, as defined today, can > > > provide complete support for 802.11i in both Local and Split > > > MAC. So while we may have agreed on a requirement, my > > > objective is to try to keep the protocol as simple as > > > possible. I do not see making this change as necessary, > > > because there is nothing the protocol is unable to do today. > > > Furthermore, I do not see making this change as necessary, > > > because it would introduce additional optional features in > > > the protocol - and consequently increase complexity. > > > > > > So I disagree with your comment of not confusing between need > > > and stated requirement. When we agreed on requirements, I'm > > > not sure we all understood how they could be interpreted. I > > > believe we have a very flexible approach today. > > > > > > so my thought is that if we believe we need to interpret the > > > requirement in the way you have, this requirement is not > > > required. If we interpret the requirement the way I have (see > > > above), then we have already. > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit > > > Cisco Systems > > > > > > > > > > > > > -----Original Message----- > > > > From: Saravanan Govindan > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > Sent: Sunday, September 17, 2006 7:24 PM > > > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > > > > Considerations > > > > > > > > Pat, > > > > > > > > The issue here is about how 802.11i exchanges are done when > > > > authenticator is at the AC and crypto elements are at the > > > WTP. This is > > > > the requirement. > > > > > > > > The proposal is a way to realize this requirement. > > > > > > > > Let's not confuse between actual need and stated requirements. We > > > > achieved consensus on the mandatory requirement because there is > > > > indeed a need for it. > > > > > > > > Given that this topic has been discussed for a while, I > > > would really > > > > like to understand your concerns. What are your thoughts on > > > realizing > > > > this requirement? > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > > > Sent: Saturday, September 16, 2006 1:36 AM > > > > To: Saravanan Govindan; capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > Considerations > > > > > > > > The "protocol" performs the function of 802.1X/802.11i without any > > > > issues in both the SplitMAC and LocalMAC operation. > > > > > > > > Are you stating this is required because RFC4564 states that > > > > flexibility is required, or because there is an actual need > > > for this > > > > feature? > > > > > > > > Pat Calhoun > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Saravanan Govindan [mailto:saravanang@hotmail.com] > > > > > Sent: Friday, September 15, 2006 9:00 AM > > > > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > > Considerations > > > > > > > > > > I want to emphasize that this is not an "additional" feature > > > > > - it is a mandatory requirement from RFC 4564. The protocol > > > > currently > > > > > does not meet the requirement. > > > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > ----Original Message Follows---- > > > > > From: "Pat Calhoun (pacalhou)" > > > > > To: "Saravanan Govindan" > > > > > , > > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > > Considerations > > > > > Date: Fri, 15 Sep 2006 08:01:32 -0700 > > > > > > > > > > I understand the proposal, but stand firm on my belief that this > > > > > additional mode of operation is unnecessary. While it is > > > > possible to > > > > > implement, as everything is in a protocol, I believe the WG > > > > needs to > > > > > focus on fixing the protocol in the areas where it is broken, as > > > > > opposed to adding more optional modes that really do not > > > change the > > > > > outcome of the functions. > > > > > > > > > > Perhaps what would be more useful is not to describe the > > > > method, but > > > > > the reason why this is being proposed. I still fail to > > > > understand why > > > > > you believe this mode of operation is necessary. > > > > > > > > > > > > > > > Pat Calhoun > > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > From: Saravanan Govindan > > > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > > Sent: Friday, September 15, 2006 2:03 AM > > > > > To: capwap@frascone.com > > > > > Subject: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > I wanted to give a more detailed explanation for the > > > > > IEEE 802.11i Considerations requirement. This note describes > > > > > how CAPWAP can be updated to satisfy this requirement > > > > > > > > > > > > > > > > > > > > I would like to use this to highlight the proposal > > > > > being put forward. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From RFC 4564, Section 5.1.10 IEEE 802.11i Considerations > > > > > > > > > > > > > > > > > > > > Protocol Requirement: > > > > > > > > > > > > > > > > > > > > The CAPWAP protocol MUST determine the exact structure of > the > > > > > > > > > > centralized WLAN architecture in which > > > > > authentication needs to be > > > > > > > > > > supported, i.e., the location of major > > > > > authentication components. > > > > > > > > > > This may be achieved during WTP initialization where major > > > > > > > > > > capabilities are distinguished. > > > > > > > > > > > > > > > > > > > > The protocol MUST allow for the exchange of key > > > > > information when > > > > > > > > > > authenticator and encryption roles are located in > > > > > distinct entities. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Following the requirement, CAPWAP needs; > > > > > > > > > > > > > > > > > > > > 1. to incorporate authentication & encryption locations in > > > > > > > > > > capabilities exchange > > > > > > > > > > > > > > > > > > > > 2. to exchange key information when authentication and crypt > are > > > > > > > > > > located in different network entities > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Basic case: > > > > > > > > > > > > > > > > > > > > AC does both IEEE 802.11i authentication and > > > > > cryptography. For 4-way > > > > > > > > > > exchange, AC tracks the KeyRSC, which it then uses for > > > > > Message-3, > > > > > > > > > > i.e., AC calculates KeyMIC and updates EAPoL frame. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > 802.11i Authentication > > > > > > > > > > - > > > > > 802.11i Crypto > > > > > > > > > > > > > > > (KeyRSC maintained here) > > > > > > > > > > > > > > > > > > > > +----------+ +-----+ > > > > > +------+ > > > > > > > > > > | Terminal | | WTP | | > > > > > AC | > > > > > > > > > > +----------+ +-----+ > > > > > +------+ > > > > > > > > > > | | > > > > > | > > > > > > > > > > | 802.1x Authentication > > > > > | > > > > > > > > > > > > > > > |<=====================================================>| > > > > > > > > > > | | > > > > > | > > > > > > > > > > PMK | > > > > > PMK > > > > > > > > > > | | > > > > > | > > > > > > > > > > Generate | > > > > > Generate > > > > > > > > > > SNonce | > > > > > ANonce > > > > > > > > > > | | > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > | Message-1 > > > > > | > > > > > > > > > > > > > > > |<-------------------------|<---------------------------| > > > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > > | > > > > > > > > > > Receive | > > > > > | > > > > > > > > > > ANonce | > > > > > | > > > > > > > > > > Generate | > > > > > | > > > > > > > > > > PTK | > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > | Message-2 > > > > > | > > > > > > > > > > > > > > > |------------------------->|--------------------------->| > > > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > > | > > > > > > > > > > | | > > > > > Receive > > > > > > > > > > | | > > > > > SNonce > > > > > > > > > > | | > > > > > | > > > > > > > > > > | | > > > > > Generate > > > > > > > > > > | | > > > > > PTK > > > > > > > > > > | | > > > > > GTK > > > > > > > > > > | Message-3 > > > > > | > > > > > > > > > > > > > > > |<-------------------------|<---------------------------| > > > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > > | > > > > > > > > > > | | | > > > > > | > > > > > > > > > > | | | > > > > > +-----------------------+ > > > > > > > > > > | | \|- EAPoL Frame > > > > > | > > > > > > > > > > Receive | > > > > > +-----------------------+ > > > > > > > > > > GTK | > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > | Message-4 > > > > > | > > > > > > > > > > > > > > > |------------------------->|--------------------------->| > > > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Case specified by RFC 4564: > > > > > > > > > > > > > > > > > > > > The 802.11i Considerations requirement considers the > > > > > case where 802.11i > > > > > > > > > > authentication is at AC and 802.11i crypto is at WTP. > > > > > So now, the WTP > > > > > > > > > > maintains the KeyRSC while the AC requires this > > > > > information to generate > > > > > > > > > > the EAPoL frame for Message-3 of the 4-way handshake. > > > > > > > > > > > > > > > > > > > > The diagram below shows this; > > > > > > > > > > > > > > > > > > > > - 802.11i Crypto > > > > > > > > > > (KeyRSC maintained here) - > 802.11i > > > > > Authentication > > > > > > > > > > > > > > > > > > > > +----------+ +-----+ > > > > > +------+ > > > > > > > > > > | Terminal | | WTP | | > > > > > AC | > > > > > > > > > > +----------+ +-----+ > > > > > +------+ > > > > > > > > > > | | > > > > > | > > > > > > > > > > | 802.1x Authentication > > > > > | > > > > > > > > > > > > > > > |<=====================================================>| > > > > > > > > > > | | > > > > > | > > > > > > > > > > PMK | > > > > > PMK > > > > > > > > > > | | > > > > > | > > > > > > > > > > Generate | > > > > > Generate > > > > > > > > > > SNonce | > > > > > ANonce > > > > > > > > > > | | > > > > > | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In this case, the EAPoL frame generated by the AC will > > > > > not be based on > > > > > > > > > > the prevailing value of the KeyRSC, as this counter is > > > > > maintained by > > > > > > > > > > the WTP. > > > > > > > > > > > > > > > > > > > > This problem is currently not solved in the CAPWAP > > > > > specifications. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Proposal: > > > > > > > > > > > > > > > > > > > > The proposal is to include a CAPWAP Key Configuration > > > > > message that can > > > > > > > > > > transport the EAPoL frame between AC and WTP before > > > > > being sent to the > > > > > > > > > > client (terminal). > > > > > > > > > > > > > > > > > > > > Key Configuration is a control message sent by the AC > > > > > to the WTP. The > > > > > > > > > > message contains Message-3 of the 4-way handshake - > > > > > including the > > > > > > > > > > EAPoL-frame. However, the EAPoL frame has its KeyMIC > > > > > field unassigned as > > > > > > > > > > the AC cannot accurately calculate this. > > > > > > > > > > > > > > > > > > > > So on receiving the Key Configuration - containing > > > > > EAPoL frame with > > > > > > > > > > unassigned KeyMIC field, the WTP retrieves the value of > > > > > the KeyRSC it > > > > > > > > > > maintains and computes the corresponding KeyMIC. > > > > > > > > > > > > > > > > > > > > The EAPoL frame is then updated and Message-3 of the > > > > > 4-way handshake is > > > > > > > > > > reconstructed before being sent over the wireless link > > > > > to the client. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The diagram below illustrates this; > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - 802.11i Crypto > > > > > > > > > > (KeyRSC maintained here) - > 802.11i > > > > > Authentication > > > > > > > > > > > > > > > > > > > > +----------+ +-----+ > > > > > +------+ > > > > > > > > > > | Terminal | | WTP | | > > > > > AC | > > > > > > > > > > +----------+ +-----+ > > > > > +------+ > > > > > > > > > > | | > > > > > | > > > > > > > > > > | 802.1x Authentication > > > > > | > > > > > > > > > > > > > > > |<=====================================================>| > > > > > > > > > > | | > > > > > | > > > > > > > > > > PMK | > > > > > PMK > > > > > > > > > > | | > > > > > | > > > > > > > > > > Generate | > > > > > Generate > > > > > > > > > > SNonce | > > > > > ANonce > > > > > > > > > > | | > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > | Message 1 > > > > > | > > > > > > > > > > > > > > > |<-------------------------|<---------------------------| > > > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > > | > > > > > > > > > > Receive | > > > > > | > > > > > > > > > > ANonce | > > > > > | > > > > > > > > > > Generate | > > > > > | > > > > > > > > > > PTK | > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > | Message 2 > > > > > | > > > > > > > > > > > > > > > |------------------------->|--------------------------->| > > > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > > | > > > > > > > > > > | | > > > > > Receive > > > > > > > > > > | | > > > > > SNonce > > > > > > > > > > | | > > > > > | > > > > > > > > > > | | > > > > > Generate > > > > > > > > > > | | > > > > > PTK > > > > > > > > > > | | > > > > > GTK > > > > > > > > > > | | Message 3 > > > > > | > > > > > > > > > > | > > > > > |<===========================| > > > > > > > > > > | | CAPWAP Packet > > > > > | > > > > > > > > > > | | (Key Configuration) > > > > > | > > > > > > > > > > | | | > > > > > +-----------------------+ > > > > > > > > > > | | \|- GTK-Flag > > > > > | > > > > > > > > > > | -Retrieve KeyRSC |- > > > > > Encryption-Data(PTK) | > > > > > > > > > > | -Update KeyMIC |- > > > > > Encryption-Data(GTK) | > > > > > > > > > > | -Reconstruct |- EAP-Frame > > > > > | > > > > > > > > > > | Message-3 > > > > > +-----------------------+ > > > > > > > > > > | | > > > > > | > > > > > > > > > > |<-------------------------| > > > > > | > > > > > > > > > > | EAPoL Packet | > > > > > | > > > > > > > > > > Receive | > > > > > | > > > > > > > > > > GTK | > > > > > | > > > > > > > > > > | Message 4 > > > > > | > > > > > > > > > > > > > > > |------------------------->|--------------------------->| > > > > > > > > > > | EAPoL Packet | CAPWAP Packet > > > > > | > > > > > > > > > > | | > > > > > | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This proposal very simply solves the problem while > > > > > directly addressing > > > > > > > > > > the requirement for IEEE 802.11i Considerations. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > To unsubscribe or modify your subscription options, please visit: > > > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > > _________________________________________________________________ > > > > > Get cheap fares online with MSN Travel > > > http://www.msn.com.sg/travel/ > > > > > > > > > _________________________________________________________________ > > > > 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 _________________________________________________________________ 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 Sep 20 15:19:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ7bF-0003uR-GC for capwap-archive@lists.ietf.org; Wed, 20 Sep 2006 15:19:13 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ7bD-0005Sr-Rr for capwap-archive@lists.ietf.org; Wed, 20 Sep 2006 15:19:13 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1763A3980E8 for ; Wed, 20 Sep 2006 12:19:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4F221430018 for ; Wed, 20 Sep 2006 12:18:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2D6101448005 for ; Wed, 20 Sep 2006 12:18:32 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by hermes.tigertech.net (Postfix) with ESMTP id 472AA144802A for ; Wed, 20 Sep 2006 12:18:29 -0700 (PDT) Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 20 Sep 2006 12:18:17 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 2980B2AF; Wed, 20 Sep 2006 12:18:17 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 04FEB2AE; Wed, 20 Sep 2006 12:18:17 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EFN36138; Wed, 20 Sep 2006 12:18:16 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 74E2D20501; Wed, 20 Sep 2006 12:18:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Sep 2006 12:18:13 -0700 Message-ID: <8954613CA6BB3242A1531D916A527A4101DBEEA1@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A202801899@xmb-sjc-235.amer.cisco.com> Thread-Topic: Comments on -02 version of capwap spec Thread-Index: Aca/uwxBHUIaBgYPTZ28fYPCQF6LQALDJVmwAAI/69AAAH0LAAACcGRwAGcectAAN0YZEAIqbiBAAOoGDfAAz4lUEA== From: "Puneet Agarwal" To: "Pat Calhoun (pacalhou)" , dstanley1389@gmail.com, capwap@frascone.com X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006092007; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230342E34353131393231302E303030332D412D; ENG=IBF; TS=20060920191819; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006092007_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 690F4C733888379324-01-01 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: Re: [Capwap] Comments on -02 version of capwap spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 3971661e40967acfc35f708dd5f33760 Hi Pat, Please see comments inline - tagged with [Puneet-9-20-06]. Thanks. -Puneet -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Saturday, September 16, 2006 5:57 PM To: Puneet Agarwal; dstanley1389@gmail.com; capwap@frascone.com Subject: RE: Comments on -02 version of capwap spec > > 10) What is the recommendation for 802.1P and DSCP values for > 802.11 Data > Frames? Do you honor the .11 QoS semantics between WTP and AC or > are all > .11 Data Frames sent at the same priority in CAPWAP? That's an implementation issue. [Puneet]: I am fine with that. However, in that case, CAPWAP should define a CAPWAP control message for the AC and WTP to exchange their .11 Data Frame mapping capabilities and for the AC to then instruct the WTP to apply a particular mapping. Without this I am not sure how one can ensure a consistent QoS in the network. So if I understand correctly, you believe that providing guidance on the use of QoS is not sufficient, and that the AC must "negotiate" with the WTP on what values to use for control, binding management and binding data? This would be considered a new feature. [Puneet-9-20-06]: I think the spec does an adequate job of calling out the mapping for CAPWAP control and .11 management information mapping to .1p etc values in the CAPWAP transport. However, my issue was how the 8 priorities in the .11 Data frames are mapped to the CAPWAP DATA .1p transport - I have not seen how this mapping is done consistently across all the WTPs. For example, assume voice traffic has .11 DATA priority 7 WTP A maps .11 DATA priority 7 to CAPWAP DATA priority 4 WTP A maps .11 DATA priority !7 to CAPWAP DATA priority 0 WTP B maps all .11 DATA priority to CAPWAP DATA priority 0 Where both WTPs (A & B) are CAPWAP compliant but maybe from different vendors. In this case, I am not sure how one can have a consistent QoS policy in the network as there is no mechanism in the current spec that instructs the WTPs on mapping of .11 DATA frame QoS to CAPWAP DATA Transport QoS - hence my earlier comment. *********** > 12) It seems that within CAPWAP Data channel, there are > multiple 802.11 control channels (it seems that different QoS > levels are an implicit attempt at this > - refer to section 11.5). > General question to the group: Would it be beneficial to > transport these > .11 control channels as "raw" data channels in CAPWAP Control > messages allowing the network to honor the 8 .1p priorities > for 802.11 Data frames in the CAPWAP DATA message. I do not believe so. I think this would unnecessarily complicate the protocol. Furthermore, if you went down this path, you'd have to put the 802.1X/EAPOL protocol in that channel... what about IAPP? etc. The current model keeps the separation of wireless binding to control best. [Puneet]: My main concern is the way 802.11 Management traffic is handled today. It wasn't clear to me why we (the group) specified to carry them in CAPWAP Data frames. I would have thought that they would be carried in CAPWAP Control Frames as they would most likely be handled by the CAPWAP Control entity (and not necessarily the CAPWAP Data entity). Hence sending such packets to the CAPWAP Data entity seems like a waste and it would eventually need to be sent to the CAPWAP control entity. I think architecturally, I disagree. I believe that the CAPWAP Control entity handles the base spec - maintaining that connection and configuration with the peer. The CAPWAP Data entity, on the other hand, is the one that actually understands the subtleties of 802.11 (or whatever wireless binding). It handles the user associations, the 802.1x state machine, etc. Further, as I noted above, it becomes complex to decide what's management and what's not. Clearly, an 802.11 MAC management frame would be a candidate, but what about EAPOL? What about IAPP? This would require use to do an extensive protocol survey and list the proper destination for each. [Puneet-9-20-06]: For .11 what you say may be the right choice. However (and this may be more of a discussion for the base protocol spec), the base protocol should provide a channel to carry the wireless protocols native control/management frames inside CAPWAP control. *********** > 16) Section 4.1: Description of RID field is unclear especially: > > " WTPs with multiple radios but a single MAC Address range > use this field to indicate which radio is associated with the > packet." > > It would be great if this could be clarified - it seems to be > implying that this is used to support the case where > multiple radios share the same Radio MAC address but is not > very clear - is this the case? The point is that the BSSID is not sufficient since some WTP vendors re-use the BSSID across their a/bg radios. Since you guessed it, I suppose it is good enough? Any recommended changes? [Puneet]: It would be really nice to have a little blurb to this effect in the spec. Fair enough. Will create a tracker issue next time I have 'net access. > 27) How does multicast handle the case when the number of > WLANIDs is greater than 16 - how does AC indicate that to the > WTP? It seems you run out of bits in the CAPWAP data packets. The protocol already states that 16 is the hard limit. [Puneet]: If one wants to support (N > 16) WLANIDs (since the spec allows for 256 WLAN IDs), then the AC should at least have the capability to send N unicast copies of the packets to the WTP but indicate a different WLANID. It wasn't clear how this would be achieved for "802.3 Frame Tunnel Mode". Spec says 16, not 256. Don't understand the change request/comment. [Puneet-9-20-06]: The specs defines a 8 bit WLANID in all the CAPWAP messages - hence I assume that one can presumably support 256 WLANIDs. If we can only support 16 WLANIDs per WTP (regardless of multicast), then that should be called out specifically in the spec. If it is already called out, then I would appreciate if you could point me to the section #. *********** _________________________________________________________________ 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 Sep 20 18:09:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQAGL-0006MQ-Av for capwap-archive@lists.ietf.org; Wed, 20 Sep 2006 18:09:49 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQAGI-0007om-Jl for capwap-archive@lists.ietf.org; Wed, 20 Sep 2006 18:09:49 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0F5F03980D0 for ; Wed, 20 Sep 2006 15:09:38 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 90B8A430018 for ; Wed, 20 Sep 2006 15:08:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C89171448032 for ; Wed, 20 Sep 2006 15:08:56 -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 2044A1448030 for ; Wed, 20 Sep 2006 15:08:54 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 20 Sep 2006 15:08:53 -0700 X-IronPort-AV: i="4.09,193,1157353200"; d="scan'208"; a="323436234:sNHT36217516" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8KM8rMQ017625; Wed, 20 Sep 2006 15:08:53 -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 k8KM8nMn011320; Wed, 20 Sep 2006 15:08:53 -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, 20 Sep 2006 15:08:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Sep 2006 15:08:50 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202802547@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on -02 version of capwap spec Thread-Index: Aca/uwxBHUIaBgYPTZ28fYPCQF6LQALDJVmwAAI/69AAAH0LAAACcGRwAGcectAAN0YZEAIqbiBAAOoGDfAAz4lUEAAGnIUQ From: "Pat Calhoun (pacalhou)" To: "Puneet Agarwal" , , X-OriginalArrivalTime: 20 Sep 2006 22:08:52.0859 (UTC) FILETIME=[5BA084B0:01C6DD01] Authentication-Results: sj-dkim-7.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] Comments on -02 version of capwap spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: a87a9cdae4ac5d3fbeee75cd0026d632 > So if I understand correctly, you believe that > providing guidance on the use of QoS is not sufficient, and > that the AC must "negotiate" > with the WTP on what values to use for control, binding > management and binding data? This would be considered a new feature. > > [Puneet-9-20-06]: I think the spec does an adequate job of > calling out the mapping for CAPWAP control and .11 > management information mapping to .1p etc values in the > CAPWAP transport. However, my issue was how the > 8 priorities in the .11 Data frames are mapped to the CAPWAP > DATA .1p transport - I have not seen how this mapping is done > consistently across all the WTPs. > For example, assume voice traffic has .11 DATA priority 7 > > WTP A maps .11 DATA priority 7 to CAPWAP DATA priority 4 WTP > A maps .11 DATA priority !7 to CAPWAP DATA priority 0 > > WTP B maps all .11 DATA priority to CAPWAP DATA priority 0 > > Where both WTPs (A & B) are CAPWAP compliant but maybe from > different vendors. > > In this case, I am not sure how one can have a consistent QoS > policy in the network as there is no mechanism in the current > spec that instructs the WTPs on mapping of .11 DATA frame QoS > to CAPWAP DATA Transport QoS - hence my earlier comment. I believe that this is adequately covered in 802.11e, and more importantly, WMM. The process of tagging 802.1p frames, based on the 802.11e UP field is well defined, and I believe, outside the scope of CAPWAP. > > I think architecturally, I disagree. I believe that the > CAPWAP Control entity handles the base spec - maintaining > that connection and configuration with the peer. The CAPWAP > Data entity, on the other hand, is the one that actually > understands the subtleties of 802.11 (or whatever wireless > binding). It handles the user associations, the 802.1x state > machine, etc. Further, as I noted above, it becomes complex > to decide what's management and what's not. Clearly, an > 802.11 MAC management frame would be a candidate, but what > about EAPOL? What about IAPP? This would require use to do an > extensive protocol survey and list the proper destination for each. > > [Puneet-9-20-06]: For .11 what you say may be the right > choice. However (and this may be more of a discussion for the > base protocol spec), the base protocol should provide a > channel to carry the wireless protocols native > control/management frames inside CAPWAP control. I believe we need to have a consistent approach here, and complete separation of the wireless binding of control vs. data is necessary. > > *********** > > 16) Section 4.1: Description of RID field is unclear > especially: > > > > " WTPs with multiple radios but a single MAC Address range > > use this field to indicate which radio is associated > with the > > packet." > > [...] > Fair enough. Will create a tracker issue next time I > have 'net access. I've created issue 223. > Spec says 16, not 256. Don't understand the change > request/comment. > > [Puneet-9-20-06]: The specs defines a 8 bit WLANID in all the > CAPWAP messages - hence I assume that one can presumably > support 256 WLANIDs. > If we can only support 16 WLANIDs per WTP (regardless of > multicast), then that should be called out specifically in > the spec. If it is already called out, then I would > appreciate if you could point me to the section #. > *********** The IEEE 802.11 WTP Radio Configuration specifically states: BSSID This attribute contains the maximum number of BSSIDs supported by the WTP. This value restricts the number of logical networks supported by the WTP, and is between 1 and 16. Given the correlation between BSSIDs and SSIDs (or WLANs), the maximum WLANIDs would be 16. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ 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 Sep 21 04:43:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQK9P-00085v-Qe for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 04:43:19 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQK9L-0000W7-9X for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 04:43:19 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id ACA31430863 for ; Thu, 21 Sep 2006 01:43:08 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6992C430059 for ; Thu, 21 Sep 2006 01:41:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1AE95398009 for ; Thu, 21 Sep 2006 01:41:20 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [12.129.211.51]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5215F39801D for ; Thu, 21 Sep 2006 01:41:17 -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 <0J5X00GXBPBJ23@usaga01-in.huawei.com> for Capwap@frascone.com; Thu, 21 Sep 2006 01:38:07 -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 <0J5X000EBPBH1Q@usaga01-in.huawei.com> for Capwap@frascone.com; Thu, 21 Sep 2006 01:38:07 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.18.23.62]) by szxmc01-in.huawei.com (mshttpd); Thu, 21 Sep 2006 13:41:12 +0500 Date: Thu, 21 Sep 2006 13:41:12 +0500 From: zhaoyujin 31390 To: Dorothy.Gellert@nokia.com Message-id: <23e05f723e103f.23e103f23e05f7@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_D5eueo9dK1sOnXeBxidwRQ)" 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.372 tagged_above=-999 required=7 tests=HTML_40_50, HTML_MESSAGE, MIME_HTML_MOSTLY X-Spam-Level: Cc: margaret@thingmagic.com, Capwap@frascone.com Subject: [Capwap] =?gb2312?B?u9i4tA==?=: Consensus call on Split CAPWAP draft by 9/29. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.4 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e This is a multi-part message in MIME format. --Boundary_(ID_D5eueo9dK1sOnXeBxidwRQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Dear all: I support CAPWAP to split two draft. This will be help for stablilty and future feature extensible. Thanks Michael This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! --Boundary_(ID_D5eueo9dK1sOnXeBxidwRQ) Content-type: multipart/alternative; boundary="Boundary_(ID_O0KAlnSJEKJAp+h1e1L0/w)" Content-class: urn:content-classes:message --Boundary_(ID_O0KAlnSJEKJAp+h1e1L0/w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi All, The editors feel that there is WG support to split the current CAPWAP protocol draft into 2 drafts, a base draft and then a 802.11 binding draft. The chairs would like to verify consensus with the WG that there is sufficient interest to split the draft before making this change. This issue has been discussed at the last CAPWAP WG meeting during IETF 66 in Montreal where there was no opposition to this request, and limited support on the list. The chairs would like establish consensus on the issue of splitting binding specific details from the base CAPWAP specification. Please submit your opinions on this topic to the WG list by Sept 29th, for a final consensus call on this feature. Best Regards, Dorothy, Mani and Margaret --Boundary_(ID_O0KAlnSJEKJAp+h1e1L0/w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Consensus call on Split CAPWAP draft by 9/29.

Hi All,

The editors feel that there is WG support to split the current CAPWAP protocol draft into 2 drafts, a base draft and then a 802.11 binding draft.  The chairs would like to verify consensus with the WG that there is sufficient interest to split the draft before making this change.

This issue has been discussed at the last CAPWAP WG meeting during IETF 66 in Montreal where there was no opposition to this request, and limited support on the list. 

The chairs would like establish consensus on the issue of splitting binding specific details from the base CAPWAP specification.

Please submit your opinions on this topic to the WG list by Sept 29th, for a final consensus call on this feature.

Best Regards,
Dorothy, Mani and Margaret

--Boundary_(ID_O0KAlnSJEKJAp+h1e1L0/w)-- --Boundary_(ID_D5eueo9dK1sOnXeBxidwRQ) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii 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 --Boundary_(ID_D5eueo9dK1sOnXeBxidwRQ) 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 --Boundary_(ID_D5eueo9dK1sOnXeBxidwRQ)-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Sep 21 05:00:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQKPY-00011S-M8 for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 05:00:00 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQKPP-0001rn-Lm for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 05:00:00 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id ADA8D398094 for ; Thu, 21 Sep 2006 01:59:50 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id AC2A2430059 for ; Thu, 21 Sep 2006 01:57:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 879C04308B0 for ; Thu, 21 Sep 2006 01:57:49 -0700 (PDT) X-Greylist-Status: Sender first seen 00:10:38 ago Received: from thingmagic.com (unknown [204.9.221.19]) by hermes.tigertech.net (Postfix) with ESMTP id D1B4C430872 for ; Thu, 21 Sep 2006 01:57:45 -0700 (PDT) Received: from [217.194.72.170] (account margaret HELO [10.10.97.237]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1306768; Thu, 21 Sep 2006 04:57:44 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: Margaret Wasserman Date: Thu, 21 Sep 2006 04:55:59 -0400 To: David T.Perkins X-Mailer: Apple Mail (2.752.2) 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: Saravanan Govindan , capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 966811b049c4d80323826ee01e1b1ce9 Me, too. Margaret On Sep 19, 2006, at 12:56 AM, David T. Perkins wrote: > HI, > > I totally agree with Pat's technical assessment on this issue. > > Regards, > /david t. perkins > > On Mon, 18 Sep 2006, Pat Calhoun (pacalhou) wrote: > >> The current specification allows the authenticator to reside in >> the AC, >> while the data packet crypto elements in the WTP. This feature is >> already in the specification. The only thing that is not there is the >> ability to move various pieces of the authenticator function >> across both >> the WTP and the AC, which I feel is unnecessary because it doesn't >> add >> any features. It just adds modes of operations to the protocol that >> creates further interoperability issues between the two devices. >> >> Pat Calhoun >> CTO, Wireless Networking Business Unit >> Cisco Systems >> >> >> >>> -----Original Message----- >>> From: Saravanan Govindan >>> [mailto:Saravanan.Govindan@sg.panasonic.com] >>> Sent: Monday, September 18, 2006 1:08 AM >>> To: Pat Calhoun (pacalhou); capwap@frascone.com >>> Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i >>> Considerations >>> >>> Pat, >>> >>> The requirement goes beyond distinguishing local / split MAC >>> support. It is explicit in the need to support authenticator >>> and cyrpto elements located at AC and WTP, respectively. >>> >>> I find it difficult to interpret it in another way. >>> >>> I do not think it is right to arbitrarily dismiss a >>> compulsory requirement. >>> >>> The fundamental goal of RFC4564 was to put forth key >>> requirements that the protocol has to satisfy. It is a "MUST" >>> - I do not see why we are having this extensive discussion. >>> >>> Saravanan >>> >>> >>> >>> >>> -----Original Message----- >>> From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] >>> Sent: Monday, September 18, 2006 12:07 PM >>> To: Saravanan Govindan; capwap@frascone.com >>> Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i >>> Considerations >>> >>> My thoughts is that the protocol, as defined today, can >>> provide complete support for 802.11i in both Local and Split >>> MAC. So while we may have agreed on a requirement, my >>> objective is to try to keep the protocol as simple as >>> possible. I do not see making this change as necessary, >>> because there is nothing the protocol is unable to do today. >>> Furthermore, I do not see making this change as necessary, >>> because it would introduce additional optional features in >>> the protocol - and consequently increase complexity. >>> >>> So I disagree with your comment of not confusing between need >>> and stated requirement. When we agreed on requirements, I'm >>> not sure we all understood how they could be interpreted. I >>> believe we have a very flexible approach today. >>> >>> so my thought is that if we believe we need to interpret the >>> requirement in the way you have, this requirement is not >>> required. If we interpret the requirement the way I have (see >>> above), then we have already. >>> >>> Pat Calhoun >>> CTO, Wireless Networking Business Unit >>> Cisco Systems >>> >>> >>> >>>> -----Original Message----- >>>> From: Saravanan Govindan >>> [mailto:Saravanan.Govindan@sg.panasonic.com] >>>> Sent: Sunday, September 17, 2006 7:24 PM >>>> To: Pat Calhoun (pacalhou); capwap@frascone.com >>>> Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i >>>> Considerations >>>> >>>> Pat, >>>> >>>> The issue here is about how 802.11i exchanges are done when >>>> authenticator is at the AC and crypto elements are at the >>> WTP. This is >>>> the requirement. >>>> >>>> The proposal is a way to realize this requirement. >>>> >>>> Let's not confuse between actual need and stated requirements. We >>>> achieved consensus on the mandatory requirement because there is >>>> indeed a need for it. >>>> >>>> Given that this topic has been discussed for a while, I >>> would really >>>> like to understand your concerns. What are your thoughts on >>> realizing >>>> this requirement? >>>> >>>> Saravanan >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] >>>> Sent: Saturday, September 16, 2006 1:36 AM >>>> To: Saravanan Govindan; capwap@frascone.com >>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>> Considerations >>>> >>>> The "protocol" performs the function of 802.1X/802.11i without any >>>> issues in both the SplitMAC and LocalMAC operation. >>>> >>>> Are you stating this is required because RFC4564 states that >>>> flexibility is required, or because there is an actual need >>> for this >>>> feature? >>>> >>>> Pat Calhoun >>>> CTO, Wireless Networking Business Unit Cisco Systems >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Saravanan Govindan [mailto:saravanang@hotmail.com] >>>>> Sent: Friday, September 15, 2006 9:00 AM >>>>> To: Pat Calhoun (pacalhou); capwap@frascone.com >>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>>> Considerations >>>>> >>>>> I want to emphasize that this is not an "additional" feature >>>>> - it is a mandatory requirement from RFC 4564. The protocol >>>> currently >>>>> does not meet the requirement. >>>>> >>>>> Saravanan >>>>> >>>>> >>>>> >>>>> ----Original Message Follows---- >>>>> From: "Pat Calhoun (pacalhou)" >>>>> To: "Saravanan Govindan" >>>>> , >>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>>> Considerations >>>>> Date: Fri, 15 Sep 2006 08:01:32 -0700 >>>>> >>>>> I understand the proposal, but stand firm on my belief that this >>>>> additional mode of operation is unnecessary. While it is >>>> possible to >>>>> implement, as everything is in a protocol, I believe the WG >>>> needs to >>>>> focus on fixing the protocol in the areas where it is broken, as >>>>> opposed to adding more optional modes that really do not >>> change the >>>>> outcome of the functions. >>>>> >>>>> Perhaps what would be more useful is not to describe the >>>> method, but >>>>> the reason why this is being proposed. I still fail to >>>> understand why >>>>> you believe this mode of operation is necessary. >>>>> >>>>> >>>>> Pat Calhoun >>>>> CTO, Wireless Networking Business Unit Cisco Systems >>>>> >>>>> >>>>> >>>>> >>>>> ________________________________ >>>>> >>>>> From: Saravanan Govindan >>>>> [mailto:Saravanan.Govindan@sg.panasonic.com] >>>>> Sent: Friday, September 15, 2006 2:03 AM >>>>> To: capwap@frascone.com >>>>> Subject: [Capwap] Issue 43 - Explanation for 802.11i >>> Considerations >>>>> >>>>> >>>>> >>>>> All, >>>>> >>>>> >>>>> I wanted to give a more detailed explanation for the >>>>> IEEE 802.11i Considerations requirement. This note describes >>>>> how CAPWAP can be updated to satisfy this requirement >>>>> >>>>> >>>>> >>>>> I would like to use this to highlight the proposal >>>>> being put forward. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> From RFC 4564, Section 5.1.10 IEEE 802.11i Considerations >>>>> >>>>> >>>>> >>>>> Protocol Requirement: >>>>> >>>>> >>>>> >>>>> The CAPWAP protocol MUST determine the exact structure of the >>>>> >>>>> centralized WLAN architecture in which >>>>> authentication needs to be >>>>> >>>>> supported, i.e., the location of major >>>>> authentication components. >>>>> >>>>> This may be achieved during WTP initialization where major >>>>> >>>>> capabilities are distinguished. >>>>> >>>>> >>>>> >>>>> The protocol MUST allow for the exchange of key >>>>> information when >>>>> >>>>> authenticator and encryption roles are located in >>>>> distinct entities. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Following the requirement, CAPWAP needs; >>>>> >>>>> >>>>> >>>>> 1. to incorporate authentication & encryption locations in >>>>> >>>>> capabilities exchange >>>>> >>>>> >>>>> >>>>> 2. to exchange key information when authentication and crypt are >>>>> >>>>> located in different network entities >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Basic case: >>>>> >>>>> >>>>> >>>>> AC does both IEEE 802.11i authentication and >>>>> cryptography. For 4-way >>>>> >>>>> exchange, AC tracks the KeyRSC, which it then uses for >>>>> Message-3, >>>>> >>>>> i.e., AC calculates KeyMIC and updates EAPoL frame. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> - >>>>> 802.11i Authentication >>>>> >>>>> - >>>>> 802.11i Crypto >>>>> >>>>> >>>>> (KeyRSC maintained here) >>>>> >>>>> >>>>> >>>>> +----------+ +-----+ >>>>> +------+ >>>>> >>>>> | Terminal | | WTP | | >>>>> AC | >>>>> >>>>> +----------+ +-----+ >>>>> +------+ >>>>> >>>>> | | >>>>> | >>>>> >>>>> | 802.1x Authentication >>>>> | >>>>> >>>>> >>>>> |<=====================================================>| >>>>> >>>>> | | >>>>> | >>>>> >>>>> PMK | >>>>> PMK >>>>> >>>>> | | >>>>> | >>>>> >>>>> Generate | >>>>> Generate >>>>> >>>>> SNonce | >>>>> ANonce >>>>> >>>>> | | >>>>> | >>>>> >>>>> | | >>>>> | >>>>> >>>>> | Message-1 >>>>> | >>>>> >>>>> >>>>> |<-------------------------|<---------------------------| >>>>> >>>>> | EAPoL Packet | CAPWAP Packet >>>>> | >>>>> >>>>> Receive | >>>>> | >>>>> >>>>> ANonce | >>>>> | >>>>> >>>>> Generate | >>>>> | >>>>> >>>>> PTK | >>>>> | >>>>> >>>>> | | >>>>> | >>>>> >>>>> | Message-2 >>>>> | >>>>> >>>>> >>>>> |------------------------->|--------------------------->| >>>>> >>>>> | EAPoL Packet | CAPWAP Packet >>>>> | >>>>> >>>>> | | >>>>> Receive >>>>> >>>>> | | >>>>> SNonce >>>>> >>>>> | | >>>>> | >>>>> >>>>> | | >>>>> Generate >>>>> >>>>> | | >>>>> PTK >>>>> >>>>> | | >>>>> GTK >>>>> >>>>> | Message-3 >>>>> | >>>>> >>>>> >>>>> |<-------------------------|<---------------------------| >>>>> >>>>> | EAPoL Packet | CAPWAP Packet >>>>> | >>>>> >>>>> | | | >>>>> | >>>>> >>>>> | | | >>>>> +-----------------------+ >>>>> >>>>> | | \|- EAPoL Frame >>>>> | >>>>> >>>>> Receive | >>>>> +-----------------------+ >>>>> >>>>> GTK | >>>>> | >>>>> >>>>> | | >>>>> | >>>>> >>>>> | | >>>>> | >>>>> >>>>> | Message-4 >>>>> | >>>>> >>>>> >>>>> |------------------------->|--------------------------->| >>>>> >>>>> | EAPoL Packet | CAPWAP Packet >>>>> | >>>>> >>>>> | | >>>>> | >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Case specified by RFC 4564: >>>>> >>>>> >>>>> >>>>> The 802.11i Considerations requirement considers the >>>>> case where 802.11i >>>>> >>>>> authentication is at AC and 802.11i crypto is at WTP. >>>>> So now, the WTP >>>>> >>>>> maintains the KeyRSC while the AC requires this >>>>> information to generate >>>>> >>>>> the EAPoL frame for Message-3 of the 4-way handshake. >>>>> >>>>> >>>>> >>>>> The diagram below shows this; >>>>> >>>>> >>>>> >>>>> - 802.11i Crypto >>>>> >>>>> (KeyRSC maintained here) - 802.11i >>>>> Authentication >>>>> >>>>> >>>>> >>>>> +----------+ +-----+ >>>>> +------+ >>>>> >>>>> | Terminal | | WTP | | >>>>> AC | >>>>> >>>>> +----------+ +-----+ >>>>> +------+ >>>>> >>>>> | | >>>>> | >>>>> >>>>> | 802.1x Authentication >>>>> | >>>>> >>>>> >>>>> |<=====================================================>| >>>>> >>>>> | | >>>>> | >>>>> >>>>> PMK | >>>>> PMK >>>>> >>>>> | | >>>>> | >>>>> >>>>> Generate | >>>>> Generate >>>>> >>>>> SNonce | >>>>> ANonce >>>>> >>>>> | | >>>>> | >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> In this case, the EAPoL frame generated by the AC will >>>>> not be based on >>>>> >>>>> the prevailing value of the KeyRSC, as this counter is >>>>> maintained by >>>>> >>>>> the WTP. >>>>> >>>>> >>>>> >>>>> This problem is currently not solved in the CAPWAP >>>>> specifications. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Proposal: >>>>> >>>>> >>>>> >>>>> The proposal is to include a CAPWAP Key Configuration >>>>> message that can >>>>> >>>>> transport the EAPoL frame between AC and WTP before >>>>> being sent to the >>>>> >>>>> client (terminal). >>>>> >>>>> >>>>> >>>>> Key Configuration is a control message sent by the AC >>>>> to the WTP. The >>>>> >>>>> message contains Message-3 of the 4-way handshake - >>>>> including the >>>>> >>>>> EAPoL-frame. However, the EAPoL frame has its KeyMIC >>>>> field unassigned as >>>>> >>>>> the AC cannot accurately calculate this. >>>>> >>>>> >>>>> >>>>> So on receiving the Key Configuration - containing >>>>> EAPoL frame with >>>>> >>>>> unassigned KeyMIC field, the WTP retrieves the value of >>>>> the KeyRSC it >>>>> >>>>> maintains and computes the corresponding KeyMIC. >>>>> >>>>> >>>>> >>>>> The EAPoL frame is then updated and Message-3 of the >>>>> 4-way handshake is >>>>> >>>>> reconstructed before being sent over the wireless link >>>>> to the client. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The diagram below illustrates this; >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> - 802.11i Crypto >>>>> >>>>> (KeyRSC maintained here) - 802.11i >>>>> Authentication >>>>> >>>>> >>>>> >>>>> +----------+ +-----+ >>>>> +------+ >>>>> >>>>> | Terminal | | WTP | | >>>>> AC | >>>>> >>>>> +----------+ +-----+ >>>>> +------+ >>>>> >>>>> | | >>>>> | >>>>> >>>>> | 802.1x Authentication >>>>> | >>>>> >>>>> >>>>> |<=====================================================>| >>>>> >>>>> | | >>>>> | >>>>> >>>>> PMK | >>>>> PMK >>>>> >>>>> | | >>>>> | >>>>> >>>>> Generate | >>>>> Generate >>>>> >>>>> SNonce | >>>>> ANonce >>>>> >>>>> | | >>>>> | >>>>> >>>>> | | >>>>> | >>>>> >>>>> | Message 1 >>>>> | >>>>> >>>>> >>>>> |<-------------------------|<---------------------------| >>>>> >>>>> | EAPoL Packet | CAPWAP Packet >>>>> | >>>>> >>>>> Receive | >>>>> | >>>>> >>>>> ANonce | >>>>> | >>>>> >>>>> Generate | >>>>> | >>>>> >>>>> PTK | >>>>> | >>>>> >>>>> | | >>>>> | >>>>> >>>>> | Message 2 >>>>> | >>>>> >>>>> >>>>> |------------------------->|--------------------------->| >>>>> >>>>> | EAPoL Packet | CAPWAP Packet >>>>> | >>>>> >>>>> | | >>>>> Receive >>>>> >>>>> | | >>>>> SNonce >>>>> >>>>> | | >>>>> | >>>>> >>>>> | | >>>>> Generate >>>>> >>>>> | | >>>>> PTK >>>>> >>>>> | | >>>>> GTK >>>>> >>>>> | | Message 3 >>>>> | >>>>> >>>>> | >>>>> |<===========================| >>>>> >>>>> | | CAPWAP Packet >>>>> | >>>>> >>>>> | | (Key Configuration) >>>>> | >>>>> >>>>> | | | >>>>> +-----------------------+ >>>>> >>>>> | | \|- GTK-Flag >>>>> | >>>>> >>>>> | -Retrieve KeyRSC |- >>>>> Encryption-Data(PTK) | >>>>> >>>>> | -Update KeyMIC |- >>>>> Encryption-Data(GTK) | >>>>> >>>>> | -Reconstruct |- EAP-Frame >>>>> | >>>>> >>>>> | Message-3 >>>>> +-----------------------+ >>>>> >>>>> | | >>>>> | >>>>> >>>>> |<-------------------------| >>>>> | >>>>> >>>>> | EAPoL Packet | >>>>> | >>>>> >>>>> Receive | >>>>> | >>>>> >>>>> GTK | >>>>> | >>>>> >>>>> | Message 4 >>>>> | >>>>> >>>>> >>>>> |------------------------->|--------------------------->| >>>>> >>>>> | EAPoL Packet | CAPWAP Packet >>>>> | >>>>> >>>>> | | >>>>> | >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This proposal very simply solves the problem while >>>>> directly addressing >>>>> >>>>> the requirement for IEEE 802.11i Considerations. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> >>>>> >>>>> Saravanan >>>>> >>>>> >>>>> >>>>> _________________________________________________________________ >>>>> To unsubscribe or modify your subscription options, please visit: >>>>> http://lists.frascone.com/mailman/listinfo/capwap >>>>> >>>>> Archives: http://lists.frascone.com/pipermail/capwap >>>>> >>>>> _________________________________________________________________ >>>>> Get cheap fares online with MSN Travel >>> http://www.msn.com.sg/travel/ >>>>> >>>> _________________________________________________________________ >>>> 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 _________________________________________________________________ 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 Sep 21 05:48:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLAD-0001nS-98 for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 05:48:13 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQLA6-0007PT-Ne for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 05:48:13 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id E2BE0398087 for ; Thu, 21 Sep 2006 02:47:43 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2B808430059 for ; Thu, 21 Sep 2006 02:47:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0BD39430A20 for ; Thu, 21 Sep 2006 02:47:09 -0700 (PDT) X-Greylist-Status: Sender first seen 01:00:00 ago Received: from thingmagic.com (unknown [204.9.221.19]) by hermes.tigertech.net (Postfix) with ESMTP id E7AEE4309EE for ; Thu, 21 Sep 2006 02:47:07 -0700 (PDT) Received: from [217.194.72.170] (account margaret HELO [10.10.97.237]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1306744; Thu, 21 Sep 2006 04:47:05 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <92B71A8F-1981-440E-9A58-2B3693291451@thingmagic.com> From: Margaret Wasserman Date: Thu, 21 Sep 2006 04:45:21 -0400 To: capwap@frascone.com X-Mailer: Apple Mail (2.752.2) 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] 2-Port/Mux Issue Discussion X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 2857c5c041d6c02d7181d602c22822c8 Hi All, As many of you know, we have had a technical issue open in the CAPWAP WG for some time that is commonly referred to as the 2-port/mux issue. This issue involves a technical choice between: - A solution that uses two different well-known UDP ports for separate data and control communications (the 2-port solution), OR - A solution that uses a single well-known UDP port for all communication, with control and data traffic distinguished by a CAPWAP header value (the mux solution). Strong opinions have been expressed on both sides of this issue, and the WG has had trouble coming to consensus on a single choice. Discussions in this area have included a wide variety of networking topics, such as Quality of Service, NAT Traversal and Mobility. Given the breadth of the technical issues under discussion, our Area Director, Dan Romascanu, decided to solicit advice from the IESG to help us understand the technical trade-offs, and to help us understand which factors it would be reasonable to consider in our working group decision -- specifically whether or not it was reasonable for us to consider the hardware implications of this decision. The only IESG members who showed up for the discussion were Mark Townsley, one of the Internet ADs, and our two OPS ADs, Dan and David Kessens. We didn't receive a definitive answer from the IESG, but a clear message was received from Mark Townsley that it is reasonable for the group to consider the hardware implications of our work -- both compatibility with currently deployed hardware, and the hardware architectures we might want to support in the future. After much discussion with the interested IESG members, the document editors, the proponents of both solutions and some people who have proposed compromise solutions, the chairs believe that the key technical difference between these two proposals is which hardware architecture(s) they will support. There are currently two different classes of AC hardware deployed, and variants on both of these architectures may be deployed in the future: - Single-Processor: In this architecture, the control plane and the data plane run on a single processor. The demultiplexing of control and data packets happens on that processor. - Separate Data & Control Planes: In this architecture, the data and control planes run on separate processors (and possibly on separate cards), typically connected via a switching fabric. This is a common hardware architecture for higher-end routing and switching hardware, and it relies on a port-based splitting/load-balancing approach to separate the control and data traffic. For CAPWAP to work efficiently on these systems, it must be possible to distinguish the control and data traffic in the switching hardware, which is typically done based on the five-tuple of the send & recv IP addresses, the protocol (UDP), and the send & recv port numbers. The switching hardware cannot do the type of deep packet inspection required to demultiplex on CAPWAP header fields. The 2-port approach supports both the "Single-Processor" AC architecture and the "Separate Data & Control Planes" AC architecture. Proponents of this solution believe that it is important to support the "Separate Data & Control Planes" architecture efficiently, both for compatibility with currently deployed hardware and to allow this hardware architecture to be used for future CAPWAP-enabled products. The mux approach will only operate efficiently on "Single-Processor" systems. as it relies on the ability to demultiplex the control and data traffic using CAPWAP header information. Proponents of this solution believe that it will simplify CAPWAP software implementation, and that it makes NAT traversal (when the AC and the WTPs are on different sides of a NAT) simpler to configure. This complexity is a consequence of the choice to tunnel all WLAN data traffic to the AC. In split-MAC local-forwarding mode, only the control plane traffic would be sent to the AC, and data plane forwarding would be handled by the WTPs themselves. We've heard from a couple of strong voices on this issue. but now we'd like to hear from the rest of the WG... Which hardware architecture(s) does the CAPWAP protocol needs to support? Specifically, do you think that it should be a requirement to support efficient operation on currently deployed and future ACs that follow the "Separate Control & Data Planes" architecture described above? Or do you think that it would be acceptable to produce a somewhat cleaner and simpler protocol that will not work efficiently on those ACs? Please send your response by Thursday, October 5th (two weeks from today), so that the chairs can gauge the consensus of the WG in this matter. After we have an understanding of which hardware architecture(s) the CAPWAP protocol needs to support, we will make an effort to sort through the various proposals and counter-proposals that meet that requirement. Thanks, The CAPWAP Chairs Dorothy Gellert, Mahalingam Mani & Margaret Wasserman _________________________________________________________________ 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 Sep 21 05:52:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLEH-0005XU-L7 for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 05:52:25 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQLED-0008Hk-0x for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 05:52:25 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 893DD3980AD for ; Thu, 21 Sep 2006 02:52:20 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 9AC9B430059 for ; Thu, 21 Sep 2006 02:51:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 565D539802A for ; Thu, 21 Sep 2006 02:51:27 -0700 (PDT) X-Greylist-Status: Sender first seen 00:59:59 ago Received: from thingmagic.com (unknown [204.9.221.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1B337398023 for ; Thu, 21 Sep 2006 02:51:25 -0700 (PDT) Received: from [217.194.72.170] (account margaret HELO [10.10.97.237]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1306753; Thu, 21 Sep 2006 04:51:24 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <638DF8C4-F0F1-436E-A383-E07F33D59D0B@lilacglade.org> From: Margaret Wasserman Date: Thu, 21 Sep 2006 04:49:40 -0400 To: capwap@frascone.com X-Mailer: Apple Mail (2.752.2) 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: Subject: [Capwap] 2-Port/Mux Issue Discussion X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 2857c5c041d6c02d7181d602c22822c8 Hi All, As many of you know, we have had a technical issue open in the CAPWAP WG for some time that is commonly referred to as the 2-port/mux issue. This issue involves a technical choice between: - A solution that uses two different well-known UDP ports for separate data and control communications (the 2-port solution), OR - A solution that uses a single well-known UDP port for all communication, with control and data traffic distinguished by a CAPWAP header value (the mux solution). Strong opinions have been expressed on both sides of this issue, and the WG has had trouble coming to consensus on a single choice. Discussions in this area have included a wide variety of networking topics, such as Quality of Service, NAT Traversal and Mobility. Given the breadth of the technical issues under discussion, our Area Director, Dan Romascanu, decided to solicit advice from the IESG to help us understand the technical trade-offs, and to help us understand which factors it would be reasonable to consider in our working group decision -- specifically whether or not it was reasonable for us to consider the hardware implications of this decision. The only IESG members who showed up for the discussion were Mark Townsley, one of the Internet ADs, and our two OPS ADs, Dan and David Kessens. We didn't receive a definitive answer from the IESG, but a clear message was received from Mark Townsley that it is reasonable for the group to consider the hardware implications of our work -- both compatibility with currently deployed hardware, and the hardware architectures we might want to support in the future. After much discussion with the interested IESG members, the document editors, the proponents of both solutions and some people who have proposed compromise solutions, the chairs believe that the key technical difference between these two proposals is which hardware architecture(s) they will support. There are currently two different classes of AC hardware deployed, and variants on both of these architectures may be deployed in the future: - Single-Processor: In this architecture, the control plane and the data plane run on a single processor. The demultiplexing of control and data packets happens on that processor. - Separate Data & Control Planes: In this architecture, the data and control planes run on separate processors (and possibly on separate cards), typically connected via a switching fabric. This is a common hardware architecture for higher-end routing and switching hardware, and it relies on a port-based splitting/load-balancing approach to separate the control and data traffic. For CAPWAP to work efficiently on these systems, it must be possible to distinguish the control and data traffic in the switching hardware, which is typically done based on the five-tuple of the send & recv IP addresses, the protocol (UDP), and the send & recv port numbers. The switching hardware cannot do the type of deep packet inspection required to demultiplex on CAPWAP header fields. The 2-port approach supports both the "Single-Processor" AC architecture and the "Separate Data & Control Planes" AC architecture. Proponents of this solution believe that it is important to support the "Separate Data & Control Planes" architecture efficiently, both for compatibility with currently deployed hardware and to allow this hardware architecture to be used for future CAPWAP-enabled products. The mux approach will only operate efficiently on "Single-Processor" systems. as it relies on the ability to demultiplex the control and data traffic using CAPWAP header information. Proponents of this solution believe that it will simplify CAPWAP software implementation, and that it makes NAT traversal (when the AC and the WTPs are on different sides of a NAT) simpler to configure. This complexity is a consequence of the choice to tunnel all WLAN data traffic to the AC. In split-MAC local-forwarding mode, only the control plane traffic would be sent to the AC, and data plane forwarding would be handled by the WTPs themselves. We've heard from a couple of strong voices on this issue. but now we'd like to hear from the rest of the WG... Which hardware architecture(s) does the CAPWAP protocol needs to support? Specifically, do you think that it should be a requirement to support efficient operation on currently deployed and future ACs that follow the "Separate Control & Data Planes" architecture described above? Or do you think that it would be acceptable to produce a somewhat cleaner and simpler protocol that will not work efficiently on those ACs? Please send your response by Thursday, October 5th (two weeks from today), so that the chairs can gauge the consensus of the WG in this matter. After we have an understanding of which hardware architecture(s) the CAPWAP protocol needs to support, we will make an effort to sort through the various proposals and counter-proposals that meet that requirement. Thanks, The CAPWAP Chairs Dorothy Gellert, Mahalingam Mani & Margaret Wasserman _________________________________________________________________ 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 Sep 21 06:07:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLSi-0003gm-2k for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 06:07:20 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQLSe-0001Li-Kz for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 06:07:20 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 432DF3980CA for ; Thu, 21 Sep 2006 03:07:16 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id EB32C430059 for ; Thu, 21 Sep 2006 03:06:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C4D28398075 for ; Thu, 21 Sep 2006 03:06:19 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 30025398050 for ; Thu, 21 Sep 2006 03:06:17 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k8LA6F7o015408 for ; Thu, 21 Sep 2006 19:06:15 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k8LA6H704905 for ; Thu, 21 Sep 2006 19:06: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 k8LA6Gd03149 for ; Thu, 21 Sep 2006 19:06:17 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Sep 2006 18:05:25 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F1609@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 43 - update Thread-Index: AcbdW/GX9eaY3ofpQNKsYVj5w0v49AACI2ag From: "Saravanan Govindan" To: X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Subject: [Capwap] Issue 43 - update X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 93238566e09e6e262849b4f805833007 All, There have been a number of exchanges on CAPWAP's support for the requirement on IEEE 802.11i Considerations. I continue to believe that the protocol must address the case for 802.11i authenticator and crypto elements being on different entities. The objective was designed based on market realities that the Architecture Taxonomy highlighted. This is a technical issue for which, a technical proposal is being made. However, opinions seem to focus on perception of protocol behaviour. I suggest a closer look at the mandatory objective in relation to the current CAPWAP specifications. Saravanan _________________________________________________________________ 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 Sep 21 06:31:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQLq6-0001i6-02 for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 06:31:30 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQLp9-0004R8-Rg for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 06:30:36 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4DC8A3980BB for ; Thu, 21 Sep 2006 03:30:31 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 76518430018 for ; Thu, 21 Sep 2006 03:30:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 60188398043 for ; Thu, 21 Sep 2006 03:30:02 -0700 (PDT) X-Greylist-Status: Sender first seen 01:42:53 ago Received: from thingmagic.com (unknown [204.9.221.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 336A1398040 for ; Thu, 21 Sep 2006 03:29:59 -0700 (PDT) Received: from [217.194.72.170] (account margaret HELO [10.10.97.237]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1306939; Thu, 21 Sep 2006 06:29:59 -0400 In-Reply-To: <5F09D220B62F79418461A978CA0921BD012F1609@pslexc01.psl.local> References: <5F09D220B62F79418461A978CA0921BD012F1609@pslexc01.psl.local> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <35A6CA8A-49D8-48FF-92E0-4A57A045DAA6@thingmagic.com> From: Margaret Wasserman Date: Thu, 21 Sep 2006 06:28:14 -0400 To: Saravanan Govindan X-Mailer: Apple Mail (2.752.2) 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] Issue 43 - update X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: fb6060cb60c0cea16e3f7219e40a0a81 Hi Saravan, You would probably make more headway in this discussion if you could describe a use case where it is necessary (or considerably more desirable) to have the authenticator on the WTP. Do you believe that it is necessary to allow the authenticator to run on the WTP in order to fully support IEEE 802.11i? If so, could you please let us know why? Several people in the group seem to believe that IEEE 802.11i is fully supported by the current specification. Is there something that will work properly when the authenticator is on the WTP that won't work properly when the authenticator is on the AC? If we've missed some important use case here, please let us know what it is. Are there cases where some significant performance increase is enabled by moving the authenticator (in addition to the encryption code) to the WTP? If so, please explain. If you could tell us what the technical advantages are to allowing the authenticator to run on the WTP, we could weigh those advantages and see if they are worth the added complexity of supporting this option in the specification. At the moment, the only argument you are giving for why we should support having the authenticator on the WTP is that we once thought we would need to do that in order to support IEEE 802.11. However, several WG members now believe that we were mistaken in that detail, because they believe that the current spec does fully support IEEE 802.11i without that option. If you want to convince us otherwise, you will need to explain how the current specification fails to fully support IEEE 802.11i or offer another compelling technical reason for adding this option. Thanks, Margaret On Sep 21, 2006, at 6:05 AM, Saravanan Govindan wrote: > All, > > There have been a number of exchanges on CAPWAP's support for the > requirement on IEEE 802.11i Considerations. > > I continue to believe that the protocol must address the case for > 802.11i authenticator and crypto elements being on different entities. > The objective was designed based on market realities that the > Architecture Taxonomy highlighted. > > This is a technical issue for which, a technical proposal is being > made. > However, opinions seem to focus on perception of protocol behaviour. > > I suggest a closer look at the mandatory objective in relation to the > current CAPWAP specifications. > > 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 Thu Sep 21 07:34:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQMpE-0003Jj-5h for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 07:34:40 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQMpA-0008LS-Jy for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 07:34:40 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id B8D20430E10 for ; Thu, 21 Sep 2006 04:34:32 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 29B3E430018 for ; Thu, 21 Sep 2006 04:33:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 17483398035 for ; Thu, 21 Sep 2006 04:33:03 -0700 (PDT) X-Greylist-Status: Sender first seen 02:45:53 ago Received: from thingmagic.com (unknown [204.9.221.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id F385339803D for ; Thu, 21 Sep 2006 04:33:00 -0700 (PDT) Received: from [217.194.72.170] (account margaret HELO [10.10.97.237]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1307078; Thu, 21 Sep 2006 07:32:59 -0400 In-Reply-To: <35A6CA8A-49D8-48FF-92E0-4A57A045DAA6@thingmagic.com> References: <5F09D220B62F79418461A978CA0921BD012F1609@pslexc01.psl.local> <35A6CA8A-49D8-48FF-92E0-4A57A045DAA6@thingmagic.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: Margaret Wasserman Date: Thu, 21 Sep 2006 07:31:13 -0400 To: Margaret Wasserman X-Mailer: Apple Mail (2.752.2) 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: Saravanan Govindan , capwap@frascone.com Subject: Re: [Capwap] Issue 43 - update X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 386e0819b1192672467565a524848168 Sorry, Saravan... I got this backwards. I realize that you are talking about the case where the authenticator is on the AC and the encryption is on the WTP. Please mentally insert "AC" everywhere that I have used "WTP" below. Margaret On Sep 21, 2006, at 6:28 AM, Margaret Wasserman wrote: > > Hi Saravan, > > You would probably make more headway in this discussion if you could > describe a use case where it is necessary (or considerably more > desirable) to have the authenticator on the WTP. > > Do you believe that it is necessary to allow the authenticator to run > on the WTP in order to fully support IEEE 802.11i? If so, could you > please let us know why? Several people in the group seem to believe > that IEEE 802.11i is fully supported by the current specification. > > Is there something that will work properly when the authenticator is > on the WTP that won't work properly when the authenticator is on the > AC? If we've missed some important use case here, please let us know > what it is. > > Are there cases where some significant performance increase is > enabled by moving the authenticator (in addition to the encryption > code) to the WTP? If so, please explain. > > If you could tell us what the technical advantages are to allowing > the authenticator to run on the WTP, we could weigh those advantages > and see if they are worth the added complexity of supporting this > option in the specification. > > At the moment, the only argument you are giving for why we should > support having the authenticator on the WTP is that we once thought > we would need to do that in order to support IEEE 802.11. However, > several WG members now believe that we were mistaken in that detail, > because they believe that the current spec does fully support IEEE > 802.11i without that option. If you want to convince us otherwise, > you will need to explain how the current specification fails to fully > support IEEE 802.11i or offer another compelling technical reason for > adding this option. > > Thanks, > Margaret > > > On Sep 21, 2006, at 6:05 AM, Saravanan Govindan wrote: > >> All, >> >> There have been a number of exchanges on CAPWAP's support for the >> requirement on IEEE 802.11i Considerations. >> >> I continue to believe that the protocol must address the case for >> 802.11i authenticator and crypto elements being on different >> entities. >> The objective was designed based on market realities that the >> Architecture Taxonomy highlighted. >> >> This is a technical issue for which, a technical proposal is being >> made. >> However, opinions seem to focus on perception of protocol behaviour. >> >> I suggest a closer look at the mandatory objective in relation to the >> current CAPWAP specifications. >> >> 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 _________________________________________________________________ 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 Sep 21 08:28:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQNfO-00008l-Jg for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 08:28:34 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQNfF-0002Aa-1d for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 08:28:34 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 445F8431330 for ; Thu, 21 Sep 2006 05:28:17 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 54431430018 for ; Thu, 21 Sep 2006 05:27:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3C67343119F for ; Thu, 21 Sep 2006 05:27:27 -0700 (PDT) X-Greylist-Status: Sender first seen 03:40:17 ago Received: from thingmagic.com (unknown [204.9.221.19]) by hermes.tigertech.net (Postfix) with ESMTP id 141F3431184 for ; Thu, 21 Sep 2006 05:27:23 -0700 (PDT) Received: from [217.194.72.170] (account margaret HELO [10.10.97.237]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1307225; Thu, 21 Sep 2006 08:27:23 -0400 In-Reply-To: <5F09D220B62F79418461A978CA0921BD012775EA@pslexc01.psl.local> References: <5F09D220B62F79418461A978CA0921BD012775EA@pslexc01.psl.local> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <0D785AAC-14B6-48E2-9710-CE4F13297239@thingmagic.com> From: Margaret Wasserman Date: Thu, 21 Sep 2006 08:25:37 -0400 To: Saravanan Govindan X-Mailer: Apple Mail (2.752.2) 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] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 8b431ad66d60be2d47c7bfeb879db82c Hi again, Okay, I am even more confused than I thought I was... Saravanan, you wrote: On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > Pat, > > The issue here is about how 802.11i exchanges are done when > authenticator is at the AC and crypto elements are at the WTP. This is > the requirement. And, in response, Pat Calhoun wrote: On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: > The current specification allows the authenticator to reside in the > AC, > while the data packet crypto elements in the WTP. This feature is > already in the specification. Pat's message matches my reading of the specification. So, Saravanan, what functionality are you asking for that is not already supported by the specification? And why do you think it is necessary? it will not be helpful to my understanding to re-send your proposal or to cite the requirements document... Please summarize what functionality you think is missing from the current specification and why you think that functionality is necessary to support IEEE 802.11i or any important use case. At some point, the chairs may need to make a consensus call on this issue, and I'd like to understand your view and make sure that it has been clearly communicated to the WG before we ask the WG to decide on this issue. 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 Sep 21 08:45:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQNvO-0001aB-NH for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 08:45:06 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQNvG-0005GZ-7t for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 08:45:06 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6C6D7398055 for ; Thu, 21 Sep 2006 05:44:57 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 619BA430018 for ; Thu, 21 Sep 2006 05:44:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4C0F939802A for ; Thu, 21 Sep 2006 05:44:02 -0700 (PDT) X-Greylist-Status: Sender first seen 03:56:52 ago Received: from thingmagic.com (unknown [204.9.221.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8F56439803D for ; Thu, 21 Sep 2006 05:43:59 -0700 (PDT) Received: from [217.194.72.170] (account margaret HELO [10.10.97.237]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1307274; Thu, 21 Sep 2006 08:43:58 -0400 In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2027A332D@xmb-sjc-235.amer.cisco.com> References: <4FF84B0BC277FF45AA27FE969DD956A2027A332D@xmb-sjc-235.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <35094E3C-26BD-4C4E-8A76-A657162533FD@thingmagic.com> From: Margaret Wasserman Date: Thu, 21 Sep 2006 08:42:13 -0400 To: Pat Calhoun (pacalhou) X-Mailer: Apple Mail (2.752.2) 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] Issue 209: Dealing with Reserved Bits X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: c0bedb65cce30976f0bf60a0a39edea4 Just to clarify, Pat... Did you close this issue with the text that David Nelson sent on August 31, 2006 (that you said was okay with you)? Or based on your original version, sent earlier the same day? Thanks, Margaret On Sep 15, 2006, at 2:20 PM, Pat Calhoun (pacalhou) wrote: > Given the lack of responses, I will assume the proposed text is > acceptable and will close this issue. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > >> -----Original Message----- >> From: Pat Calhoun (pacalhou) >> Sent: Thursday, August 31, 2006 6:39 AM >> To: capwap@frascone.com >> Subject: [Capwap] Issue 209: Dealing with Reserved Bits >> >> Here is the proposed new text: >> >> 4.1. CAPWAP Transport Header >> [...] >> Flags: A set of reserved bits for future flags in the >> CAPWAP header. >> All implementations complying with version zero of this >> protocol >> MUST set these bits to zero. Receivers MUST ignore all bits >> not >> defined for the version of the protocol they support [...] >> Reserved: The 3-bit Reserved field is reserved and set to >> 0 in this >> version of the CAPWAP protocol. Receivers MUST ignore all bits >> not defined for the version of the protocol they support >> >> Comments? >> >> Pat Calhoun >> CTO, Wireless Networking Business Unit >> Cisco Systems >> _________________________________________________________________ >> 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 Thu Sep 21 09:38:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOkr-00089i-Dk for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 09:38:17 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQOkm-0005rc-Ti for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 09:38:17 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 43E67398101 for ; Thu, 21 Sep 2006 06:38:12 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 806FD430094 for ; Thu, 21 Sep 2006 06:37:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 697F51448026 for ; Thu, 21 Sep 2006 06:37:25 -0700 (PDT) X-Greylist-Status: Sender first seen 04:50:15 ago Received: from thingmagic.com (unknown [204.9.221.19]) by hermes.tigertech.net (Postfix) with ESMTP id 91BB01448001 for ; Thu, 21 Sep 2006 06:37:22 -0700 (PDT) Received: from [217.194.72.170] (account margaret HELO [10.10.97.237]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1307468; Thu, 21 Sep 2006 09:37:21 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <3556ABA8-9B14-4063-9693-2B6CAE55D5AA@thingmagic.com> From: Margaret Wasserman Date: Thu, 21 Sep 2006 09:35:36 -0400 To: David T.Perkins X-Mailer: Apple Mail (2.752.2) 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] Regarding next version of draft and packet formats (resend) X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: a8a20a483a84f747e56475e290ee868e Hi David, When Pat said "we are working out the details", I both hope and trust that he meant that the WG was still trying to sort this out, not that the editors were working on the details of a specific change. The WG chairs, editors, some IESG members, you and other proponents of compromise proposals have been working "behind the scenes" a bit to try to better understand this issue and to get some advice and further information that the WG could use to make a good decision regarding this issue. But, as you can hopefully see from the chairs' recent message on this subject, no decision has been made about this issue in private, and no decision will be made without WG discussion and consensus. Margaret On Aug 22, 2006, at 4:13 PM, David T. Perkins wrote: > HI, > > I didn't see this show up on the mailing list. > Sorry if you get it twice. > > Regards, > /david t. perkins > > ---------- Forwarded message ---------- > Date: Tue, 22 Aug 2006 09:52:35 -0700 (PDT) > From: David T. Perkins > To: "Pat Calhoun (pacalhou)" > Cc: Josh Peterson , capwap@frascone.com > Subject: Re: [Capwap] Regarding next version of draft and packet > formats > > HI, > > I'm surprise and distrubed to say the least about the > statement "We are working out the details..."! > > Why? Because such work is being done without WG visibility. > > It would be proper, and I believe would result in a much better > outcome if this was done via an open interim meeting. > > Regards, > /david t. perkins > > On Tue, 22 Aug 2006, Pat Calhoun (pacalhou) wrote: >> We are working out the details of MUX vs. UDP port. Once we've ironed >> out the details of the protocol the editors will be putting out >> the -03 >> document. It is too early to tell what the packet format will look >> like, >> so I can't answer your question right now. >> >> >> Pat Calhoun >> CTO, Wireless Networking Business Unit >> Cisco Systems >> >> >> >> >> ________________________________ >> >> From: Josh Peterson [mailto:student1976@gmail.com] >> Sent: Sunday, August 20, 2006 7:43 PM >> To: capwap@frascone.com >> Subject: [Capwap] Regarding next version of draft and packet >> formats >> >> >> Hi all >> When is the next version of the draft expected to be out? >> >> Also, is the packet format as outlined in >> http://lists.frascone.com/pipermail/capwap/msg03250.html expected >> to be >> the new packet format in that draft? >> >> Thanks >> Josh >> >> >> > > > > _________________________________________________________________ > 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 Sep 21 09:44:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOqi-000493-0Z for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 09:44:20 -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 1GQOFX-0007py-42 for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 09:05:55 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GQO35-0001uR-7b for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 08:53:05 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1C6B03980CD for ; Thu, 21 Sep 2006 05:53:00 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 70403430018 for ; Thu, 21 Sep 2006 05:52:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5D1E21448005 for ; Thu, 21 Sep 2006 05:52:11 -0700 (PDT) X-Greylist-Status: Sender first seen 04:05:02 ago Received: from thingmagic.com (unknown [204.9.221.19]) by hermes.tigertech.net (Postfix) with ESMTP id E0F9B431588 for ; Thu, 21 Sep 2006 05:52:09 -0700 (PDT) Received: from [217.194.72.170] (account margaret HELO [10.10.97.237]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1307305; Thu, 21 Sep 2006 08:52:09 -0400 In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2027A3334@xmb-sjc-235.amer.cisco.com> References: <4FF84B0BC277FF45AA27FE969DD956A2027A3334@xmb-sjc-235.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <6D965EB6-6C3C-4D63-9080-2D5498C46C80@thingmagic.com> From: Margaret Wasserman Date: Thu, 21 Sep 2006 08:50:23 -0400 To: Pat Calhoun (pacalhou) X-Mailer: Apple Mail (2.752.2) 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] Issue 208: Dealing with Reserved Bits X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: a8a20a483a84f747e56475e290ee868e Hi Pat, As you can probably tell, I'm working my way through all of the issues, trying to understand which have been cleanly resolved and which require further discussion or consensus calls within the WG... This particular messaage seems to be in error... The Reserved Bits issue is Issue 209, and you later reported closing that issue. If I'm interpreting the mail thread correctly, Issue 208 was opened to cover a report by Filippo Giordano that the AC Descriptor Message Element and the Radio Administrative State Message Element have incorrect length fields in version -02 of the document. Am I correct? And if so, have you also resolved Issue 208? Thanks, Margaret On Sep 15, 2006, at 2:23 PM, Pat Calhoun (pacalhou) wrote: > Given the lack of responses, I will assume the modified proposed > text is > acceptable and will close this issue. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > >> -----Original Message----- >> From: Pat Calhoun (pacalhou) >> Sent: Thursday, August 31, 2006 2:24 PM >> To: Nelson, David; capwap@frascone.com >> Subject: Re: [Capwap] Issue 209: Dealing with Reserved Bits >> >> I'm ok with this as well. >> >> Pat Calhoun >> CTO, Wireless Networking Business Unit >> Cisco Systems >> >> >> >>> -----Original Message----- >>> From: Nelson, David [mailto:dnelson@enterasys.com] >>> Sent: Thursday, August 31, 2006 2:17 PM >>> To: Pat Calhoun (pacalhou); capwap@frascone.com >>> Subject: RE: [Capwap] Issue 209: Dealing with Reserved Bits >>> >>> For the sake of symmetry, may I suggest a different revision to the >>> text: >>> >>> OLD (Pat C. as of 8/31/06): >>> >>> 4.1. CAPWAP Transport Header >>> [...] >>> Flags: A set of reserved bits for future flags in the CAPWAP >>> header. >>> All implementations complying with version zero of >> this protocol >>> MUST set these bits to zero. Receivers MUST ignore >> all bits not >>> defined for the version of the protocol they support [...] >>> >>> NEW: >>> >>> 4.1. CAPWAP Transport Header >>> [...] >>> Flags: A set of reserved bits for future flags in the CAPWAP >>> header. >>> All implementations complying with this protocol MUST set to >>> zero >>> any bits that are reserved in the version of the protocol >>> supported >>> by that implementation. Receivers MUST ignore all bits not >>> defined >>> for the version of the protocol they support [...] >>> >>> This places a symmetric requirement on senders to zero, and >> receivers >>> to ignore, any bits that are still reserved in the version of the >>> protocol supported in that implementation. >>> >> _________________________________________________________________ >> 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 Thu Sep 21 12:32:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQRTs-0007RI-8H for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 12:32:56 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQRTj-000376-Fz for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 12:32:56 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id E94A5398144 for ; Thu, 21 Sep 2006 09:32:46 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D7970430018 for ; Thu, 21 Sep 2006 09:31:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BD7571448051 for ; Thu, 21 Sep 2006 09:31:31 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by hermes.tigertech.net (Postfix) with ESMTP id 78CED1448044 for ; Thu, 21 Sep 2006 09:31:29 -0700 (PDT) Message-ID: <034901c6dd9b$8a230ca0$526015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Margaret Wasserman" , References: <92B71A8F-1981-440E-9A58-2B3693291451@thingmagic.com> Date: Thu, 21 Sep 2006 09:32:33 -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] 2-Port/Mux Issue Discussion X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: a1852b4f554b02e7e4548cc7928acc1f Mark's points about better compatibility with high performance hardware of the two port solution sound compelling to me, so I support that. jak ----- Original Message ----- From: "Margaret Wasserman" To: Sent: Thursday, September 21, 2006 1:45 AM Subject: [Capwap] 2-Port/Mux Issue Discussion > > Hi All, > > As many of you know, we have had a technical issue open in the CAPWAP > WG for some time that is commonly referred to as the 2-port/mux > issue. This issue involves a technical choice between: > > - A solution that uses two different well-known UDP ports for > separate data and control communications (the 2-port solution), > > OR > > - A solution that uses a single well-known UDP port for all > communication, with control and data traffic distinguished by a > CAPWAP header value (the mux solution). > > Strong opinions have been expressed on both sides of this issue, and > the WG has had trouble coming to consensus on a single choice. > Discussions in this area have included a wide variety of networking > topics, such as Quality of Service, NAT Traversal and Mobility. > > Given the breadth of the technical issues under discussion, our Area > Director, Dan Romascanu, decided to solicit advice from the IESG to > help us understand the technical trade-offs, and to help us > understand which factors it would be reasonable to consider in our > working group decision -- specifically whether or not it was > reasonable for us to consider the hardware implications of this > decision. The only IESG members who showed up for the discussion > were Mark Townsley, one of the Internet ADs, and our two OPS ADs, Dan > and David Kessens. We didn't receive a definitive answer from the > IESG, but a clear message was received from Mark Townsley that it is > reasonable for the group to consider the hardware implications of our > work -- both compatibility with currently deployed hardware, and the > hardware architectures we might want to support in the future. > > After much discussion with the interested IESG members, the document > editors, the proponents of both solutions and some people who have > proposed compromise solutions, the chairs believe that the key > technical difference between these two proposals is which hardware > architecture(s) they will support. There are currently two different > classes of AC hardware deployed, and variants on both of these > architectures may be deployed in the future: > > - Single-Processor: In this architecture, the control plane and the > data plane run on a single processor. The demultiplexing of control > and data packets happens on that processor. > > - Separate Data & Control Planes: In this architecture, the data and > control planes run on separate processors (and possibly on separate > cards), typically connected via a switching fabric. This is a common > hardware architecture for higher-end routing and switching hardware, > and it relies on a port-based splitting/load-balancing approach to > separate the control and data traffic. For CAPWAP to work > efficiently on these systems, it must be possible to distinguish the > control and data traffic in the switching hardware, which is > typically done based on the five-tuple of the send & recv IP > addresses, the protocol (UDP), and the send & recv port numbers. The > switching hardware cannot do the type of deep packet inspection > required to demultiplex on CAPWAP header fields. > > The 2-port approach supports both the "Single-Processor" AC > architecture and the "Separate Data & Control Planes" AC > architecture. Proponents of this solution believe that it is > important to support the "Separate Data & Control Planes" > architecture efficiently, both for compatibility with currently > deployed hardware and to allow this hardware architecture to be used > for future CAPWAP-enabled products. > > The mux approach will only operate efficiently on "Single-Processor" > systems. as it relies on the ability to demultiplex the control and > data traffic using CAPWAP header information. Proponents of this > solution believe that it will simplify CAPWAP software > implementation, and that it makes NAT traversal (when the AC and the > WTPs are on different sides of a NAT) simpler to configure. > > This complexity is a consequence of the choice to tunnel all WLAN > data traffic to the AC. In split-MAC local-forwarding mode, only the > control plane traffic would be sent to the AC, and data plane > forwarding would be handled by the WTPs themselves. > > We've heard from a couple of strong voices on this issue. but now > we'd like to hear from the rest of the WG... > > Which hardware architecture(s) does the CAPWAP protocol needs to > support? > > Specifically, do you think that it should be a requirement to > support efficient operation on currently deployed and future ACs that > follow the "Separate Control & Data Planes" architecture described > above? Or do you think that it would be acceptable to produce a > somewhat cleaner and simpler protocol that will not work efficiently > on those ACs? > > Please send your response by Thursday, October 5th (two weeks from > today), so that the chairs can gauge the consensus of the WG in this > matter. > > After we have an understanding of which hardware architecture(s) the > CAPWAP protocol needs to support, we will make an effort to sort > through the various proposals and counter-proposals that meet that > requirement. > > Thanks, > > The CAPWAP Chairs > Dorothy Gellert, Mahalingam Mani & Margaret Wasserman > > > > _________________________________________________________________ > 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 Sep 21 12:41:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQRcV-0002ai-2G for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 12:41:51 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQRcR-00040b-HJ for capwap-archive@lists.ietf.org; Thu, 21 Sep 2006 12:41:51 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0EEA439811C for ; Thu, 21 Sep 2006 09:41:47 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id F3045430018 for ; Thu, 21 Sep 2006 09:40:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DDAC343178B for ; Thu, 21 Sep 2006 09:40:52 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 815F41448005 for ; Thu, 21 Sep 2006 09:40:51 -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 k8LGeocU003565; Thu, 21 Sep 2006 09:40:50 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k8LGeoUG003562; Thu, 21 Sep 2006 09:40:50 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 21 Sep 2006 09:40:50 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Margaret Wasserman In-Reply-To: <3556ABA8-9B14-4063-9693-2B6CAE55D5AA@thingmagic.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] Regarding next version of draft and packet formats (resend) X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 3a4bc66230659131057bb68ed51598f8 HI, Thanks for the note. Matching an effective process with the participants in a WG can be difficult, and it appears that this WG needs some process changes. I support your efforts in helping the WG become more effective. Regards, /david t. perkins On Thu, 21 Sep 2006, Margaret Wasserman wrote: > > > Hi David, > > When Pat said "we are working out the details", I both hope and trust > that he meant that the WG was still trying to sort this out, not that > the editors were working on the details of a specific change. > > The WG chairs, editors, some IESG members, you and other proponents > of compromise proposals have been working "behind the scenes" a bit > to try to better understand this issue and to get some advice and > further information that the WG could use to make a good decision > regarding this issue. But, as you can hopefully see from the chairs' > recent message on this subject, no decision has been made about this > issue in private, and no decision will be made without WG discussion > and consensus. > > Margaret > > > On Aug 22, 2006, at 4:13 PM, David T. Perkins wrote: > > > HI, > > > > I didn't see this show up on the mailing list. > > Sorry if you get it twice. > > > > Regards, > > /david t. perkins > > > > ---------- Forwarded message ---------- > > Date: Tue, 22 Aug 2006 09:52:35 -0700 (PDT) > > From: David T. Perkins > > To: "Pat Calhoun (pacalhou)" > > Cc: Josh Peterson , capwap@frascone.com > > Subject: Re: [Capwap] Regarding next version of draft and packet > > formats > > > > HI, > > > > I'm surprise and distrubed to say the least about the > > statement "We are working out the details..."! > > > > Why? Because such work is being done without WG visibility. > > > > It would be proper, and I believe would result in a much better > > outcome if this was done via an open interim meeting. > > > > Regards, > > /david t. perkins > > > > On Tue, 22 Aug 2006, Pat Calhoun (pacalhou) wrote: > >> We are working out the details of MUX vs. UDP port. Once we've ironed > >> out the details of the protocol the editors will be putting out > >> the -03 > >> document. It is too early to tell what the packet format will look > >> like, > >> so I can't answer your question right now. > >> > >> > >> Pat Calhoun > >> CTO, Wireless Networking Business Unit > >> Cisco Systems > >> > >> > >> > >> > >> ________________________________ > >> > >> From: Josh Peterson [mailto:student1976@gmail.com] > >> Sent: Sunday, August 20, 2006 7:43 PM > >> To: capwap@frascone.com > >> Subject: [Capwap] Regarding next version of draft and packet > >> formats > >> > >> > >> Hi all > >> When is the next version of the draft expected to be out? > >> > >> Also, is the packet format as outlined in > >> http://lists.frascone.com/pipermail/capwap/msg03250.html expected > >> to be > >> the new packet format in that draft? > >> > >> Thanks > >> Josh > >> > >> > >> > > > > > > > > _________________________________________________________________ > > 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 Sep 22 05:05:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQgyB-0004ie-AI for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 05:05:15 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQgy8-00019l-Qw for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 05:05:15 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8993A398082 for ; Fri, 22 Sep 2006 02:05:01 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 56AAD430059 for ; Fri, 22 Sep 2006 02:04:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 28B2E43093E for ; Fri, 22 Sep 2006 02:04:10 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id D90E343094B for ; Fri, 22 Sep 2006 02:04:07 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k8M943J8016748; Fri, 22 Sep 2006 18:04:03 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k8M945926131; Fri, 22 Sep 2006 18:04: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 k8M945Q27781; Fri, 22 Sep 2006 18:04:05 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Sep 2006 17:03:09 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F17A6@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbdeTQ8CR0SLrwyRMaeKBeBcmDxVQAckCxA From: "Saravanan Govindan" To: "Margaret Wasserman" 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@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 057ebe9b96adec30a7efb2aeda4c26a4 Hi Margaret, Thank you for reviewing the discussion on this issue. The issue here is the working of IEEE 802.11i when the 802.11i authenticator element is at the AC and the 802.11i crypto element is at the WTP. Particularly, it is for the 4-way handshake between authenticator and supplicant. Now, the 4-way handshake requires knowing the value of KeyRSC sequence counter. The KeyRSC helps both authenticator and supplicant keep track of their exchanges. It serves to protect against threats by tracking sequential frames. The KeyRSC is maintained at the at the point of encryption, i.e. just before transmission over the wireless channel. In the case of CAPWAP, the 4-way handshake is between the AC (authenticator) and the wireless station (supplicant). The problem arises, when the authenticator is at the AC and the crypto element (together with KeyRSC) is at the WTP. This is a fairly common design. Now in this case, the AC starts the 4-way handshake but it does not know the value of the KeyRSC. The KeyRSC is maintained by the WTP. Based on this, the current CAPWAP specification does not allow for a way to conduct the 4-way handshake with the correct KeyRSC. The functionality I would like to see is a way for the authenticator (AC) to use the correct prevailing value of KeyRSC (maintained by the WTP) in its 4-way handshake. One way to introduce this functionality in to CAPWAP is to have part of the 4-way handshake be sent from AC to WTP. This will allow the 4-way handshake to use the correct value of the KeyRSC before being sent to the wireless station. I hope this helps clarify my view on the issue. Cheers, Saravanan -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com] Sent: Thursday, September 21, 2006 8:26 PM To: Saravanan Govindan Cc: Pat Calhoun (pacalhou); capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi again, Okay, I am even more confused than I thought I was... Saravanan, you wrote: On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > Pat, > > The issue here is about how 802.11i exchanges are done when > authenticator is at the AC and crypto elements are at the WTP. This is > the requirement. And, in response, Pat Calhoun wrote: On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: > The current specification allows the authenticator to reside in the > AC, > while the data packet crypto elements in the WTP. This feature is > already in the specification. Pat's message matches my reading of the specification. So, Saravanan, what functionality are you asking for that is not already supported by the specification? And why do you think it is necessary? it will not be helpful to my understanding to re-send your proposal or to cite the requirements document... Please summarize what functionality you think is missing from the current specification and why you think that functionality is necessary to support IEEE 802.11i or any important use case. At some point, the chairs may need to make a consensus call on this issue, and I'd like to understand your view and make sure that it has been clearly communicated to the WG before we ask the WG to decide on this issue. 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 yonpsv@tie.cl Fri Sep 22 13:26:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQonX-00088H-HX for capwap-archive@ietf.org; Fri, 22 Sep 2006 13:26:47 -0400 Received: from 113-96-194.adsl.cust.tie.cl ([200.113.96.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQon2-0003Kl-56 for capwap-archive@ietf.org; Fri, 22 Sep 2006 13:26:47 -0400 Message-ID: <001101c6de6c$32197040$c26071c8@Pc1> From: "can" To: capwap-archive@ietf.org Subject: Make Date: Fri, 22 Sep 2006 13:26:10 +0400 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C6DE4A.AB07D040" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 2.6 (++) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 ------=_NextPart_000_000D_01C6DE4A.AB07D040 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C6DE4A.AB07D040" ------=_NextPart_001_000E_01C6DE4A.AB07D040 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Groups Home Help Sign in Web Images VideoNew News Maps more raquo = Advanced Search Members: users: Join Alerts Create new group About = Searched all groups Your search did not match any Make sure words are = spelled Try different keywords. general Members: users: Join Alerts Create new group About Searched all groups = Your search did not match any Make sure words are spelled Try different = keywords. general fewer your on can try Answers for expert help with d Google Groups Home Help Sign in Web Images VideoNew News Maps more = raquo Advanced Search Members: users: Join Alerts Create new group About = Searched all groups Your search did not match any Make sure words are = spelled Try different keywords. general fewer your on can try Answers = for expert help with search. Get the latest messages emailed to Alerts. = Terms of Help Sign in Web Images VideoNew News Maps more raquo Advanced Search = Members: users: Join Alerts Create new group About Searched all groups = Your search did not match any Make sure words are spelled Try different = keywords. general fewer your on can try Answers for expert help with = search. Get the latest messages emailed to Alerts. Terms of Service = Privacy Sign in Web Images VideoNew News Maps more raquo Advanced Search = Members: users: Join Alerts Create new group About Searched all groups = Your search did not match any Make sure words are spelled Try different = keywords. general fewer your on can try Answers for expert help with News Maps more raquo Advanced Search Members: users: Join Alerts Create = new group About Searched all groups Your search did not match any Make = sure words are spelled Try different keywords. general fewer your on can = try Answers for expert help with search. Get the Help Sign in Web Images VideoNew News Maps more raquo Advanced Search = Members: users: Join Alerts Create new group About Searched all groups = Your search did not match any Make sure words are spelled Try ------=_NextPart_001_000E_01C6DE4A.AB07D040 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
Groups Home Help Sign in Web Images VideoNew News Maps more = raquo Advanced Search Members: users: Join Alerts Create new group About = Searched all groups Your search did not match any Make sure words are = spelled Try different keywords. general
Members: users: Join Alerts Create new group About Searched all = groups Your search did not match any Make sure words are spelled Try = different keywords. general fewer your on can try Answers for expert = help with
d Google Groups Home Help Sign in Web Images VideoNew News Maps = more raquo Advanced Search Members: users: Join Alerts Create new group = About Searched all groups Your search did not match any Make sure words = are spelled Try different keywords. general fewer your on can try = Answers for expert help with search. Get the latest messages emailed to = Alerts. Terms of
Help Sign in Web Images VideoNew News Maps more raquo Advanced = Search Members: users: Join Alerts Create new group About Searched all = groups Your search did not match any Make sure words are spelled Try = different keywords. general fewer your on can try Answers for expert = help with search. Get the latest messages emailed to Alerts. Terms of = Service Privacy
Sign in Web Images VideoNew News Maps more raquo Advanced = Search Members: users: Join Alerts Create new group About Searched all = groups Your search did not match any Make sure words are spelled Try = different keywords. general fewer your on can try Answers for expert = help with
News Maps more raquo Advanced Search Members: users: Join = Alerts Create new group About Searched all groups Your search did not = match any Make sure words are spelled Try different keywords. general = fewer your on can try Answers for expert help with search. Get = the
Help Sign in Web Images VideoNew News Maps more raquo Advanced = Search Members: users: Join Alerts Create new group About Searched all = groups Your search did not match any Make sure words are spelled = Try
------=_NextPart_001_000E_01C6DE4A.AB07D040-- ------=_NextPart_000_000D_01C6DE4A.AB07D040 Content-Type: image/gif; name="in.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c6de6c$32197040$c26071c8@Pc1> R0lGODlhsAFsAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAbAAAALAAAAACwAWwBBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUFFCiUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXL mDNr3sy5s+fPoEOLHk26tOnTqFOrRqlnteuurV/Lxhp7tu2otW/rZpp7t++jvX8LH068uPHj yJMrX868ufPn0KNLn069uvXr2LNr386dpZPu4MP+ix9PPjS28ujTq7dcbb379/Djy59Pv779 +/jz69/Pv7///wAGKOCABCq3hkAKFKjgggw26OCDEEYo4YQUVmjhhRhmqOGGHHbo4Ycghiji iCSWaOKJKKao4oostujiizA6aEJFwsRo44045qjjjgeFw+OPCSkB5JBEFmnkkUgmWZYrSkKU SpNQRinllFRWaeWVWGap5ZZLscPll2CGKeaYZJZp5pmf9YDmmmxmhEObcMYpZ07SzMkcLXbm SRM8evbp55+ABirooIQWauihiCaq6KKMNuroo5rJA+mkIZJA6aWUQiOTJ5gm5QmnVVlAkgpW fvpbFxCaWtwpnbbq6qv/sMYq66zg3ULrrbjmquuuvPbq66/ABivssMQWayytbByr7LJGfcLs s9BGK+20kx1AbUrWXmtSttqWxG23I30LbkjijvtRueami5aQ6rbr7rvp1gFvR/LOq1G99maE b74X7csvRf7+O1HAAhds8MEIJ6zwwsO1wfBDDj/cUMQSV2zxxRgv2M/CP2Ts8ceIPgnyyCS/ OGPJKKes8sost/wiIS7HLPPMNNds80rj3Kzzzjz37PPPWU0T1wLWsWqX0CQjPbLSQDft9NOk fQf11FRXbfXVWGet9dZcd13YCF4reEzYZJf9kBlmaw1G2my37fbbcMct99w10+AxCnTnrffe Z3z37fffgAcu+OCEF2744U2p8RwEKDPeOOKQRy55oTNMbvnlfzGA+eacq5fFibN0LvropJdu usDtna766qy37nrTyZIc+8izv247rHaknDvKu5dsR+8kA3/78MQXb/zxyCev/PIpBgQAIfkE AAnpAAAsAAAAALABbAEHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48g Q4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+q0GCDAwZ49BQId6jOowqEEiSZUmhRoQaT/ jD5t6vQp0aBSB2K9ahCqUJ9NqRrN+tUqV7JRi14Fq5WrWbZixVZFu7OuS7ppu8LFG7atX6t9 swpmWzVp2b96+4YdjDiv47+M0eJlDJjv4cuUHzumazmhBbugOU6Ge1kzQqmZG4/dy7otWbCp FZvOm5nya9itJZNWvXvrwtqtS6/+uTu0cZOjEzc+Tbi47OePUafdO3tp8MXBdZv2TVy599nc rf4H7q02MWfnx9ODTA54eXfX55l7lz5da3X58M82dx++7Oi1zg0G4HRMIYYaeeCpxVRn6jWY EXuyMXhbYQY6pR1mrgkVHYURIuhWaf6RFh5SF36nXWcfJqhifA62+BGEvDHE122VIYhhhuVB J5yHuEHXH20i5qijZieid1hsQJpXHIMuNgkRjDvKuB9/2V0X3VtRvgdiklkeGWSUJba35Y/z WXngeE6mGRKURBqJ2ZRibmYmYXr16F6XfgGn2Jlg2mgij79dpydkS7qp5qHWLcihgF7Bl99R jRKIZVRaEogekj8yWqduc/kZZ5EpbsfaeUjeh+ipqKaq6qqsturqq/+wxirrrLTWauutuOaq 66689urrr8AGK+ywxBZr7LHIJqtssAMMkFCzzf4T7UDOQguttNZWmy21zlJL0LQCZavttOKG 2224356L7bPbmmvtuuZi+y636RrUbrrzgktuvteCK6281wJ87r34BqzvuP2q627AAnd7cLzL VuSvvQ7rSy/EF8PL8MAMY6yxutFuzO3DCJE88cMTL5yxxwqjzDG86H48MMws09wyyNpmTPLK IeP88coRR5RyvfJ6i/HJLxcdM8AF+btvvSKr7HHTSSNN79Dz0mwz1Ve/7DTEIlvt7ddEx7vz zizn3LXNCgf90NAXq5201iZrDLbPcfss993+U5f9NNd/Ex14336rvS7WDtstdtkHOW342TdD rXfHWrvtENxgm63ztuXGHDLfPFcMteY/Vz7yxu32vPDfg69OMb95o+55tQ27bjvjqh89d9ps K8245Ze3LTjpMFtN9uel89676KInT3HvgDcvuPSNR2727qAzbzrQdE++OdCOL0855sCXLHzc I38/vdFFi4v24Mi37/72ySOOvfuGL9392sSXznH+/7ra78IHOfB5b23kKx9DyEeu9OmOa5lz F/SgR8D0EfB8xaOeA/fHP/Zx8HBeW18A5de00RlQcur7IAhRmEEFvo1gTMNbBt9VwQ62UGqd O+D1ssa7zvmuXBf+5Bflane71PVLckI82BCJKLDCJVGJBqsaBl1IxSpa8YpYzKIWt8jFLnrx i2AMoxjHSMYymvGMaExjrSymvNVVLIoDvFnPaDjFHIKMagnLGh15qLyUGXGPUQRk7pAYyDwu sYlFnKIaQ7Iv6fHxfRPsW/gI10M2hk5975OdCgFYwKl1LGE2vOG3TAi6RaKkkbpb3NcmyT1W Yi6IHpygyWSoRw2u0nqiRFojH8dJ7D1vIAYwQOtMSZIGNg9+vmSlJGmJwQo2EHdzQ2Yp+Vg5 VUazZU0c5CAfqBA/apCYxTRk3gr3Ohh6k5zmM2H8XOdD57Huf8L7Iyi5Wbs37rCQczz/ZCt9 CU6RAHKcKbzk72TZTL31T3wQnKQ0F7JNJopyaV6LaPQY2jZl9nMk/2xYJ9Fl0XMGFILEGx/e FDo5H2KNhdyjp/462NBh7vOiLtloLu/Y0Yoyk12kFCk660c9tHmwpefzaTx5+UHE/XKgMAWJ TDMJRwNmdIZDzGEcoRnDe7kyqE8E4OZoWD0iAlGGbkRYU5NK1rKa9axoTata18rWtrr1rXCN q1znmpEJ0PWueMUiFvLK17769a+ADaxgB0vYwhr2r/U4rGIXy9jGOvaxkI2sZCdL2cpa9rKY zaxlw6FZylohJJztrGhHS1pVDaO0qGWJNFLL2ta69rUY4Qds/mdL29pixAy2za1ud8vb3vr2 t8ANrnCHS1ydAOAhx6VVcq0IgOYuNybPLYhz/9FcghzXudil7kKyKxDuUve51cVucqN7XfGW N7ve/W51pRte8A4kve+17nTj292LeNe8y4UvedsrXu0ipL/+ra+AqRjdmRTYut11L30HfJAC K3i9CQ6wdsmL4AUveLwVrjCE/XvgDCs4wB12yIcZLGHpGoTCFjZxfPObYQUemLvoXe953ytj 9Q4Ywyr+b31ZbOEQO/jEE96xhK+b4yEDWcAhRjKIS3xkJp+XyPNVL4ZR3OIR0/fHVU6Ie3Hc YuBhWcg3/m6Ky7viKze5wWA2coq7/uzkIAd5y0W28pKZrGIip1nHJOYwjcu84i/3mM16LrKa 0VzmFxP4zHZespUTreckO1rJg6Zznn9sZygjmMpD7m964QvpKW93zVyGM58FHelHC1rOf94w oIPm50Sz+MHTfbCk86zhUUea1JSO8IRhHGc2cxnXYWY0ods85x1reth/XrOve/1fXhvaha0u NqNdrWZhk7rWd0b1pIE8Xk+fOss5fja23/zpbRfbzYCOtrJBzWxkQ3rVrO41j9GN7mknG96B 1jWDTQ3uXDcZ01/+NZbB+2tEezjVl8YziTH97jEvm9glTnLEYDzfeT85v7E+OKj1G175VpnT UqYxhP19/2JVZxq9Go6yyDMtcnGH3OOwrnGzTe7giic41hsmuM0hfu40SlwhPxdj0HU1dCdd oi5Fv7bPi5X04jr96VCPutSnztugN71FWaC6g0Be7q6f2cb4nbXWLadtLTfEx18v+9jdFvCQ 2zzKvOb5wvG99on/W9pizna+2Q3uuhMY7vl+dcJtDey++525YLa4kUXt7ojT/fDxdrPiGU/v wt8b8mTXON4pX+mvO37dmFfWpi/cZ7jvvOY4HzGAQw9t1hP26q6PvezFaIPZ256wXbi97nEC e7N7pPfIbRHwQWPyjwwfVcdvsHnFfvaM/97zK795hwtedJ1jnO5J36/Kuw58rv5fPfnDnreW t08S8YuY675/PujPrnSLmH767R43rUsu/s4z39rp37eIMaJ2iICfvaQHdC0xfP3XfvZ1aTIn ZAzHYe8nfcpmaQ/odWGWcOQXgIk3f6M2Y9IHcA54c263axi3fdNXYxpoY/LFX952gjrWbR1H fi/2diMnY+9nbyjHY5yGYjt3axpBcLZGZsDGefJHeHS2eg/neCOncKKGfyZ2fXqXZZSnaILn cALog5Unf1TYeKG2Z3Mnb1GofxyoaD34bYOngxmheouHhWd4ecoHfYsWfku4avWna93mhmm4 hXpHZTTYZSH4hk9ohfcXbhb4eU44hnWof3Nmf3a4hf/C9n/xl4eeZ295t3zbtYCDVnw9B4l3 x24Fd4iEqH0JyICkB4R66ICQWHwCJ2kcF3e3Fm2wtoGLOG7eJolS6GwGWBFm2IdtdosRgYn9 JoBzp21xiG2o94m8yHOydoejOIYQaIh+KG5oN4GJ6IWDKIbvFou+mIF3xnwUoYsRBn+d+I1D SG/HmI0G13DeuIoNZ4TKuIBmCIYZyIqFZnjmGI4YqHh8h3D4mI1MaI/oaGbQuH622G8tOH4d 93IzuG4zGGoVR4Q9FoMVCGD65XHfFnOCeIIsCHPVVpDstZADWXrhl4Mb+YzdmG4ceYoH2YHO J2b154KbBniP9yqM2HgvqVz/fUWJNCkSIkl0FShXNrl7kAcMPhmUQjmUxBWTJWGURLkTsiiT QLeU7rd/rpiUp1J929gRVveJvJUDmdeUHPmPekiCG4iSIBmPSDlZWkl2NziK5oeQkQiOqOZq 6NdaZ3lo8piC0Fdvbtl8Cjdbc3loKcmAYLmXH+iFEHl+TCmVacKBNjhrH0ZtQqiN5FiWUbcK TtKGI+mV7eaYKumH3CaOiIkoIOd893WNpKiCLMiDqOiQkvmZwqd+T8maxMKIcRl8sFmbtnmb uJmbuplaqwkSvbmbI3FfOwmQ9DebtMkQrTacwLkSoiiYx7mDzbeHzLicNFGMUnaRPTdmgQmR JUlr/8uIitRpE8XYhms5fz4oim8pd8QZniYBkl9oZjmpjHmJnH5mguxpYIunkYBpl6eWkltW mHoJh/eJn5aZZvzZd5pZhZDpmYdZLISAWs15Y5rJb+4IYqWYbgxKhos1Cl0knKZYkKOZf4Pp gacpkSMYgjJoiQPqIkiZfL+5ojkhm8r5nBKRATA6LC96ozp6Kxy6oz76o0AapEI6pERapLCS BHYBA0a6pEzapIgSD07qRVAapVw0pVR6pViapVq6pVzapV76pWAapmI6pmRapll0Bmaapmq6 pmzapm76pnAap3I6p8rCD7JFp6hipxOhpw3Bp3haF3bqpw8hqH/qJIF6p///oKeBShCLmqiy xaeQGqkC0aiOWqgxIamOeqeQOqmP2qmcWqmJWqmbCqqW6hKY6qeEqqieKqqIyqqlahOniqiR uqizKqux2qqvaqqHSqu2CqqqyqmpuqqfmqsvIai/+qmSiqqyiqyPOqyESqwmYaydeg7Oeqik Kq2amq29Cq01Qa0O8azc2iLeyhDgGq4OMq7mGivoWhPFkK7u+q6vBXs5+pprKgOCaXUTgaIq +nILKhHzCix40CI3sJXr+X1YmX+bCJ1mFLCLRWElyJ2BSYH06GsZV6Ig2HIOS4zZySolMBIM e1gZG4b/iWb6eo8eZpJdGHEpm6CvUgIdGxJ48LH/r/eGIkuIAGgQ++BoLnlujpiIF/qvNvGy tuWw37h8OtugsJiPGSqN8Nlb2TArRFuzBmhtQ5eFTNuESnugXrqY71iIEjuOycaPnsmE+XiE ZbqzgLmf9aiaD6hy+qmKaeuJe1ie8LqeKNF9dSuiLGGcepu3byULfnubhxC4hDt2QHuXd9uv IzECsse3UPlx+5pz+OqvyDWcSkikBRid0aeheadvpEmjCLuCUUpyFku1GQq2F2ix14mSaWuQ Lqh8EcukpJufJJuJ6Sh5Y1u0A6eG8Hi4Qrm7Jjl+tsuYjVaIPZu0G6exlyukwBuVR6t5xNuW QGi0FimhcXlx37mkzaue/+DIuXOYu0Joj3RbuzTrpO3otfEYiJtIcvXWs1zbj8jou0MZkS23 tiXLr/WptiTKuvUrhw95ksvrpvJbuEdJwAZ8wAicwArMdohrvjNalfS3EbKpdPlLpb95jmUo wRTcwNprcJZWuiaYlhd7iA1Icdt5sDh4eo47pKz4vSN7u0jWhcfLs21ZhPE7k5LlA0Tnwepb bXgma8ELvSwLuyiXvhgouzxsvX+ZsHsXi9zZw6h5r2eYuZibxNmJuv6oZEwceDYbvTVLxVV8 sngXhuBZiZdntZFpbl+shVtqwnjZv42pfWYMx5LLv/ZZnyAMdgtMKyawx378x4AcyII8yIRc yP+GfMiInMiKvMiM3MiO/MiQHMmSPMmp1QeUfMmYnMmavMmc3Mme/MmgHMqiPMqkXMqmHMkk cCzgsMqsLBCr7MrgUBCvPBCx/A+s3Mq2XMu2TMu6DMu0zMu5fMsIMcu+TBDEbBDE/MrHXMu3 PMvJDMzG3My5HM3UzMvCXM3WHMvNrM29LMu4LM3D3M3ZnMy6rMy9zM3GHMytvM3YrEVC683A 7MzdjMu7vMzoHMzFDM3ffM8Jcc3T3M7w/M/0zM/TLM/MLM7/nNAJ7c/5DNAKTc4KIc/pjMz0 jM0S7csDjc+urNALXc4I/UUQfdHW/Mv2LNAiXcz7zNEUDdEOHc8eXc7/D33PKU3R0JzPDK3S Kl3SDU3TD30QN23TB+3SMJ3Rx9zRNT1GLP3TMh3TAr3LHO3MuxwG5hzRQf3UH63O6QzVJa3V Ow3U1XzSRd3VOo3T+nzVKC3OSe3R9czMa73RRc3SZO1F7AzLYR3UBG3Q3BzWWH3Nc/3VVX3U 3jzPGM3Ue13RFr3NVT3WDj3Wel3T4BzQdf3YIT3Ydq3O5szQjS3Xat3VTq3MhC3MP13YJ83T o53ZmE3Z53zQl/3RcG3SDa3XkX3YVO3TaP3XLi3blZ3b80zQcd1FcA3bI63ToG3YdJ3Xth3Y 0vzWVz3VG03Xn73OxO3VQi3ZCB3bjm3WUA3Y/4i929Jd0MEd3Nzd22L029UN3rLN2d1t2qlt 1f2c2OZ93YB93hi93pxt3d1N282904pt1Eb90k6Nz8oN32XU1zhN3wTe2gHd0Te91cn92F5t 4A6O4PJd0PRd4A1O3gu+z8S938LN19S83uzc4ae8o1cw4iZ+4gl8Dyg+yJltRuAc4g5e3GCN 3Mw933hd3Xz94hcO3f483BMd45Zt3PZd2BN91Ko90/+t3Dk+3Bre5OSc4avN3EA+131N4Oht z0yO5C6yzBaO30L9yzz93K+d4G0932TO3yY91Ofs5WiO1WUN09Gs5h+u2vqt1gFu5Pw82mQe 0mtOEEPQ5jXO3isd3v85bdbGweWwjeNzDucJLuI93c55ztt3ftbO7dZ93uibXdx+zeiVXuZm rtGTHuiE/emu3d6LfekTHuiTHueEPuQy8Q0T4er1DeJNHeaO3uL2LeqrftFL3eLpvdlJXesk zdYM7tZ1ftuQDuLAjt0VHt+2ruwAbd2MXdtpYtBB7uxbPdjPTuUvnehIHuVCftfu7d3Wvu0V LdLZ7dk/rs3PvdqDfuNCztRVPuXNPs7hjOejLta2/eRa3iJ8zubJ3tns/ux+DfA0ze1nfuuo je12Ht7B7t3r7ulpbtwEv+vQvt97buiJju8cTu2jLusNssriQOotne2dnurjrt9zHubHXtb/ +Q3dDO/yMj7T/l3kMP/mFI/pgv7aMp3pAF/XJe/zqk7oM0/eq/LKIy/qs/7hI03wMl/v0J7w rQ7s793l0q3wJ5/kQy/gOm/xK0/pph7f9X7fWx/tFS7hvn7oOy7hM5/fVi/vTk7b/X7tMN7j 67zp0d3aWw/a0Y730y73Ti7pOr7ohm33gM/aqW33St3g8o3whzLyK74RkB/5GDH5lH8Rln/5 FJH5mt/5s5L2gszrg1/nmD36ln7tFo3vRo7643zkkb3k0U3Wjn/jba/6lq74PB77ju/2dK/s tP/u+476oP8rEl3sLV/qNj7sMQ/q3d70Wh/2+d7fGp/3DU/yPu/m/xrt6aV9/XDP6Vxf6lwe 8ETt8cpS/FG/8xS+6GAe9JXO787P/d8f6rw96Gwu5Xet3QP9zMb//Tyf/Yre/wDxDxy4fwIJ FhSIsOBAhQwHHkzIUKHBiRUtXsSYUeNGjh09Vnx4UOJCgiNHkmxYEiJFlQtBrkQosSRKijVb JqRp0eTKkzVZwpwoE+hOkkIvnjQaUaTPn0Eh9mTq0KbOpzxFXs2IdKZMpjk/fgUbVuzYolhj 3uyqNepMli+PPjRIdGpbr07PpnQasizUpCn1lj0L9+5grm3VhnSImCperEB9Iha8UzDeu43j RnZMVvNmzh/lovzsNTFj0G6pJpZbWGpdyv5r7YLOTJNv1cGmXc+Vehjm6MWVS9tW27Xu4dKz Ox9Hnry369DMreKMazuvSqGQoU+GWju4drQvrbf+/Dwn5NXRdb/OTrzo8uCFhz+v2l35fPrI Q/NOS5t5YOmvH8PnjzXuWhtPPgJ7Cu8p8PT7zTz9EGSwNrqiA0489/IjbT3j6uOww460+uuy oRQLLDICBSxQwvL+wwjEyUqs7sXbYBRvrwUzhC1E67aj0SUJB6wMMxn3WirIv7LzMEkll2Sy SSefhDJKKaekskorr8QySy235LJLL78EM0wxxyRTSVfKRDNNNddks00334QzTjnnpLNOO+/E M0+MotCzTy9NUv7RqiMHPVGv7340lLZD/WOUR0Bh+1FEs3yEUdISLVUoivZGFBKu73ZUzLhP QyXRO8ma85Oz6gqEUMUZA12OMLOQvFS6U2VtbFJYsWuUwb5G0hQ7XaPCMMX3BGWxVdYAlDXV 5Fb9T1lieRTNsQ3xoxUwW+N70Cj8DqQupl6BVItPHYdFqlgWj70KW/lQZVS22JwNi6tZdUWV 2lcjjfFE9EakLCl7c8yMuAtnTM0qcycNkd/dfI1QKU/R+nbdFgEWjl6yEk34xukarjZWeR8G 2SZOSfx1YmhjXW1FETGVN2CGh3zZ0gR7bJfgGFGj2V94NRaL4249BndbkU3WV2ajTfi+dFAk 1XP5PKWb3XcxCBtuTkFItw5Sow1RBBosoYm8WVx9k76W4tjIe5gx8gAjND1mKYT1NmB5Plcn t+MFUly3iFKW1q/DVq5sY6etsW6+BR626KK3K3vw8mSEfOh/gg1ZQPjaZm83qxXlPOPBwSbc M4iJrpnavE3lOdlSM9+1RsNnO3IHRBNv/dDK3+q0Yu4M/dzpiQsFFeV5S0c+eeWXZ75555+H Hs1Loqe+euuvxz577bfnvnvvvwc/fPHHJ798889HP33112e/ffffhz9++eenv37778c/f/33 579///8HIPpIEUACFtCAB0RgAhW4QAY2UEkBAQAh+QQAFgAAACwAAAAAsAFsAQcI/gD/CRxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJ0qOyljBjypxJ s6bNmzhzspSks6dPiRJ+Ch1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2BjtgpL tqzZs2jTql3Ltq3bt3Djyp1Lt65djPTu6t3Lt6/fv4ADCx5MmCSTwogTK17MuLHjx5AjS55M ubLly5gza97MubPnz6BDix5NurTp06hTq14d8wjr17Bjy55Nu7bt27hxD8rNu7fv38CDCx9O XKme4siTK1/OvLnz59CjS59Ovbr169iza9/Ovbt34oy+/osfT768+fPo06tfz769+/fw48uf T7++/fv48+vfz7+///8ABijggAQWmJsRBk5nTYIMNujggxBGKOGEFFbomSMWZqjhhhwGNkyH IIYo4ohCKUHiiShCZEOKLLbo4oswxijjjDTWaOONOOao44489ujjj08RAuSQRBZp5GxaHFlZ kkpOxmSTkTGpC3r3tDdlelWqd6V6WZ635Xpdkvcle2F+N2Z7ZXJ3JpSMrcnmm3DGyeIrctZp 55145qnnnnz26eefgAYq6KCEFmrooYgmquiijDbq6KOQRvrWNJJWaumlmGbqkCua7kdBp6CG KuqopJZq6qmopqrqqqz+RWer/7DGKuustKI4Tq245qrrrrz26uuvwAYr7LDEFmvsscgme5Md yi7bLElPMsTsszRNS+1K3lyr7bbcduvtt97FA+645ILVRrnophtfNeq2a9kNWnniLknyzitS vfaChG++Hu3LL0f+/qtRwAJjRHDBoT6C8MIMN+zwwxBH/Cw6ElNEccURXYwxRBpv7FDHHjME csgKjUwyQiafrPLKLLfMa1AuxyxTODLXbPPNZ7n5Jj849yweTz4HLfTQRBdttJyrHK300kw3 7fTTULebV9RUV2311VinW0LWXHft9aMMfC322GSXbfbZaHPNadq17eatLD7D3bMscrNt9914 56333nV8kxVG34AHLvjghOvETuGIJ6744qUFw/jjkGOsQ+SUV2755ZhnrvnmnHdes5Cehy76 6KSXbvrpqKeuutcHrO46SbO8PtwKstduu03n9Jw7UtLwurtRvft+VPDC32788cgnr/zyzDfv /PONTg399NRXb32cAQEAIfkEABcAAAAsAAAAALABbAEHCP4A/wkcSLCgwYMIEypcyLChw4cQ I0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rcybOnz59A gwodSrSo0aNIkypdyrQkoKZQo0qdSrWq1atYswqMo7Wr169gw4odS7as2bM9f6Fdy7at27dw 48qdS7eu3bt48+rdy7ev37+AAwseTLiw4cOIEytenLAc48eQI0ueTHksuMqYM2vezLmz58+g Q4seTXouvNKo+55OzRrvasATWnN+Lbs2XNq2c6/Frbu379/AI8sITtxriuLItR5Pztzq8ubQ oz6PTl3p9OoUu2FHyWO79+/g+/5yCk++vPnz6NOrX8++vfv38OPLB/5svv37+PPr38+/v/// AL53S4AEFmjggQgmqOCCDDbo4IMQRighTsE0OMyEEuqA4YYcdujhhyCGKOKIJJZo4okopqji Z9Cs6OKLf+EBY3V4yDgjdDXeGJ2NOvbo449ABinkkEQWmZIDRiap5JJMNunkk1BGKaVUe0yZ WpVWooZllqRtyWVUByDl5ZegjUmmZ2aeqeaaSaU5kwlsfgYnUnTEmdScdmqGZ56Y7clnZX7+ KVmggkJGaKGIJqrooow26uijkIp1SqSUVmrppZhm6ugQmnbq6aeghipqioeOauqpqKaq6qqs tupqUf+asLXEq7TWauutuObaGiG6CplJr8AGK+ywxBZr7LHIJqvsssw26+yzbXUAbYDDTWvt tSt9gu223HYrGhLehivuuOSWa+656BLYT7rsthuUC+7GK++89NZr77345qvvvvz26++/AAcs 8MAEF2zwwQgnrDByWizcaTYORyzxxBRXbPHF7NKC8UnrbIxRxx5bBHLIFI1MskQmnwxRyiq3 bNKFLscs88w0K6lBzTjnrPPOPKNIQM9Aa4Rk0AUNTbRARh/9T9JKN+3001AzhUHUVFdt9dVY Z6311lx37fXXYIct9thkl202aTefrfba35Hi9tuksC333HTXbffdeOet9956fPft99+ABy74 4IQXbvjhiCeu+OKMN06ZDY6bykLklFdu+eVKOoH5s49s7vnnoIcu+ujM8UEsIqSnrvrqrLc+ 7Rmuxy777LTXbvvtuOeu++689+7778AHL7yHAw5v/PHIJz+WI8w3z/zTjuA9ivLUV2/99dhn r/2SAQEAOw== ------=_NextPart_000_000D_01C6DE4A.AB07D040-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 22 16:20:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQrVv-0004U5-Oh for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 16:20:47 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQrVt-0000y1-7A for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 16:20:47 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id C6395144807C for ; Fri, 22 Sep 2006 13:20:24 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id A733A430018 for ; Fri, 22 Sep 2006 13:17:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 87D9A1448050 for ; Fri, 22 Sep 2006 13:17:52 -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 E2A33144804B for ; Fri, 22 Sep 2006 13:17:49 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 22 Sep 2006 13:17:49 -0700 X-IronPort-AV: i="4.09,204,1157353200"; d="scan'208"; a="324406229:sNHT36838352" 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.20060308/8.12.11) with ESMTP id k8MKHnMh008572; Fri, 22 Sep 2006 13:17:49 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k8MKHmMP014868; Fri, 22 Sep 2006 13:17:49 -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, 22 Sep 2006 13:17:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Sep 2006 13:17:47 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202876754@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 208: Dealing with Reserved Bits Thread-Index: AcbdfMMQtVlYS+M+QvqXRsDdn2eyiwA0xkaw From: "Pat Calhoun (pacalhou)" To: "Margaret Wasserman" X-OriginalArrivalTime: 22 Sep 2006 20:17:48.0463 (UTC) FILETIME=[2C29E3F0:01C6DE84] 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] Issue 208: Dealing with Reserved Bits X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: ff03b0075c3fc728d7d60a15b4ee1ad2 Yes - the mislabeling of the issues was done the first time I sent an e-mail, but I made the necessary corrections when I sent the notice to close. Both are addressed and closed. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, September 21, 2006 5:50 AM > To: Pat Calhoun (pacalhou) > Cc: Nelson, David; capwap@frascone.com > Subject: Re: [Capwap] Issue 208: Dealing with Reserved Bits > > > Hi Pat, > > As you can probably tell, I'm working my way through all of > the issues, trying to understand which have been cleanly > resolved and which require further discussion or consensus > calls within the WG... > > This particular messaage seems to be in error... The > Reserved Bits issue is Issue 209, and you later reported > closing that issue. > > If I'm interpreting the mail thread correctly, Issue 208 was > opened to cover a report by Filippo Giordano that the AC > Descriptor Message Element and the Radio Administrative State > Message Element have incorrect length fields in version -02 > of the document. > > Am I correct? And if so, have you also resolved Issue 208? > > Thanks, > Margaret > > On Sep 15, 2006, at 2:23 PM, Pat Calhoun (pacalhou) wrote: > > > Given the lack of responses, I will assume the modified > proposed text > > is acceptable and will close this issue. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > >> -----Original Message----- > >> From: Pat Calhoun (pacalhou) > >> Sent: Thursday, August 31, 2006 2:24 PM > >> To: Nelson, David; capwap@frascone.com > >> Subject: Re: [Capwap] Issue 209: Dealing with Reserved Bits > >> > >> I'm ok with this as well. > >> > >> Pat Calhoun > >> CTO, Wireless Networking Business Unit > >> Cisco Systems > >> > >> > >> > >>> -----Original Message----- > >>> From: Nelson, David [mailto:dnelson@enterasys.com] > >>> Sent: Thursday, August 31, 2006 2:17 PM > >>> To: Pat Calhoun (pacalhou); capwap@frascone.com > >>> Subject: RE: [Capwap] Issue 209: Dealing with Reserved Bits > >>> > >>> For the sake of symmetry, may I suggest a different > revision to the > >>> text: > >>> > >>> OLD (Pat C. as of 8/31/06): > >>> > >>> 4.1. CAPWAP Transport Header > >>> [...] > >>> Flags: A set of reserved bits for future flags in the CAPWAP > >>> header. > >>> All implementations complying with version zero of > >> this protocol > >>> MUST set these bits to zero. Receivers MUST ignore > >> all bits not > >>> defined for the version of the protocol they support [...] > >>> > >>> NEW: > >>> > >>> 4.1. CAPWAP Transport Header > >>> [...] > >>> Flags: A set of reserved bits for future flags in the CAPWAP > >>> header. > >>> All implementations complying with this protocol MUST set to > >>> zero > >>> any bits that are reserved in the version of the protocol > >>> supported > >>> by that implementation. Receivers MUST ignore all bits not > >>> defined > >>> for the version of the protocol they support [...] > >>> > >>> This places a symmetric requirement on senders to zero, and > >> receivers > >>> to ignore, any bits that are still reserved in the version of the > >>> protocol supported in that implementation. > >>> > >> _________________________________________________________________ > >> 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 Sep 22 16:23:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQrY7-00052B-1d for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 16:23:03 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQrY5-0001DX-IM for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 16:23:03 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id A5A521448019 for ; Fri, 22 Sep 2006 13:22:57 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 08CCB430018 for ; Fri, 22 Sep 2006 13:17:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EAB53144804B for ; Fri, 22 Sep 2006 13:17:52 -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 904391448046 for ; Fri, 22 Sep 2006 13:17:49 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 22 Sep 2006 13:17:49 -0700 X-IronPort-AV: i="4.09,204,1157353200"; d="scan'208"; a="324406226:sNHT78863530" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8MKHmLZ010503; Fri, 22 Sep 2006 13:17:48 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k8MKHmMN014868; Fri, 22 Sep 2006 13:17:48 -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, 22 Sep 2006 13:17:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Sep 2006 13:17:47 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202876753@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 209: Dealing with Reserved Bits Thread-Index: Acbde5xDr/SzPuhRSDGlWnfN7+DOygA1By4g From: "Pat Calhoun (pacalhou)" To: "Margaret Wasserman" X-OriginalArrivalTime: 22 Sep 2006 20:17:48.0181 (UTC) FILETIME=[2BFEDC50:01C6DE84] Authentication-Results: sj-dkim-7.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] Issue 209: Dealing with Reserved Bits X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 31247fb3be228bb596db9127becad0bc Included the recommended changes provided by David Nelson. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, September 21, 2006 5:42 AM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 209: Dealing with Reserved Bits > > > > Just to clarify, Pat... > > Did you close this issue with the text that David Nelson sent > on August 31, 2006 (that you said was okay with you)? Or > based on your original version, sent earlier the same day? > > Thanks, > Margaret > > > On Sep 15, 2006, at 2:20 PM, Pat Calhoun (pacalhou) wrote: > > > Given the lack of responses, I will assume the proposed text is > > acceptable and will close this issue. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > >> -----Original Message----- > >> From: Pat Calhoun (pacalhou) > >> Sent: Thursday, August 31, 2006 6:39 AM > >> To: capwap@frascone.com > >> Subject: [Capwap] Issue 209: Dealing with Reserved Bits > >> > >> Here is the proposed new text: > >> > >> 4.1. CAPWAP Transport Header > >> [...] > >> Flags: A set of reserved bits for future flags in the > >> CAPWAP header. > >> All implementations complying with version zero of this > >> protocol > >> MUST set these bits to zero. Receivers MUST ignore > all bits > >> not > >> defined for the version of the protocol they support [...] > >> Reserved: The 3-bit Reserved field is reserved and set to > >> 0 in this > >> version of the CAPWAP protocol. Receivers MUST > ignore all bits > >> not defined for the version of the protocol they support > >> > >> Comments? > >> > >> Pat Calhoun > >> CTO, Wireless Networking Business Unit > >> Cisco Systems > >> _________________________________________________________________ > >> 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 Sep 22 16:23:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQrYx-0005Dm-V9 for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 16:23:55 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQrYv-0001K2-Co for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 16:23:55 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 8804B144805E for ; Fri, 22 Sep 2006 13:23:49 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2176843009A for ; Fri, 22 Sep 2006 13:17:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 08CA8398044 for ; Fri, 22 Sep 2006 13:17:53 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id 75B2F398055 for ; Fri, 22 Sep 2006 13:17:49 -0700 (PDT) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 22 Sep 2006 13:17:49 -0700 X-IronPort-AV: i="4.09,204,1157353200"; d="scan'208"; a="1854954260:sNHT37788396" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8MKHmai012894; Fri, 22 Sep 2006 13:17:48 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k8MKHmML014868; Fri, 22 Sep 2006 13:17:48 -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, 22 Sep 2006 13:17:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Sep 2006 13:17:47 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202876752@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - update Thread-Index: AcbdcfhQ73Bx9iIFTxWdxSawuyc03AA3VjUA From: "Pat Calhoun (pacalhou)" To: "Margaret Wasserman" X-OriginalArrivalTime: 22 Sep 2006 20:17:47.0775 (UTC) FILETIME=[2BC0E8F0:01C6DE84] Authentication-Results: sj-dkim-6.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: Saravanan Govindan , capwap@frascone.com Subject: Re: [Capwap] Issue 43 - update X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: f49c97ce49302a02285a2d36a99eef8c Margaret, You sort-of got it right the first time. We currently support two modes of operations; one where the authentication and crypto occur in the AC and a second where the crypto is in the WTP. So we already support both modes of operation already. What Saravanan is looking for, is to split the authenticator responsibilities across both the AC and the WTP, so message 3 of the 802.11i key handshake can be handled in the WTP (vs. the AC). Such a change does not increase the level of conformity to the 802.11i protocol - it simply provides another optional architecture. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, September 21, 2006 4:31 AM > To: Margaret Wasserman > Cc: Saravanan Govindan; capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - update > > > > Sorry, Saravan... I got this backwards. I realize that you > are talking about the case where the authenticator is on the > AC and the encryption is on the WTP. > > Please mentally insert "AC" everywhere that I have used "WTP" below. > > Margaret > > On Sep 21, 2006, at 6:28 AM, Margaret Wasserman wrote: > > > > > Hi Saravan, > > > > You would probably make more headway in this discussion if > you could > > describe a use case where it is necessary (or considerably more > > desirable) to have the authenticator on the WTP. > > > > Do you believe that it is necessary to allow the > authenticator to run > > on the WTP in order to fully support IEEE 802.11i? If so, could you > > please let us know why? Several people in the group seem > to believe > > that IEEE 802.11i is fully supported by the current specification. > > > > Is there something that will work properly when the > authenticator is > > on the WTP that won't work properly when the authenticator > is on the > > AC? If we've missed some important use case here, please > let us know > > what it is. > > > > Are there cases where some significant performance increase > is enabled > > by moving the authenticator (in addition to the encryption > > code) to the WTP? If so, please explain. > > > > If you could tell us what the technical advantages are to > allowing the > > authenticator to run on the WTP, we could weigh those > advantages and > > see if they are worth the added complexity of supporting > this option > > in the specification. > > > > At the moment, the only argument you are giving for why we should > > support having the authenticator on the WTP is that we once > thought we > > would need to do that in order to support IEEE 802.11. However, > > several WG members now believe that we were mistaken in > that detail, > > because they believe that the current spec does fully support IEEE > > 802.11i without that option. If you want to convince us otherwise, > > you will need to explain how the current specification > fails to fully > > support IEEE 802.11i or offer another compelling technical > reason for > > adding this option. > > > > Thanks, > > Margaret > > > > > > On Sep 21, 2006, at 6:05 AM, Saravanan Govindan wrote: > > > >> All, > >> > >> There have been a number of exchanges on CAPWAP's support for the > >> requirement on IEEE 802.11i Considerations. > >> > >> I continue to believe that the protocol must address the case for > >> 802.11i authenticator and crypto elements being on different > >> entities. > >> The objective was designed based on market realities that the > >> Architecture Taxonomy highlighted. > >> > >> This is a technical issue for which, a technical proposal is being > >> made. > >> However, opinions seem to focus on perception of protocol > behaviour. > >> > >> I suggest a closer look at the mandatory objective in > relation to the > >> current CAPWAP specifications. > >> > >> 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 > > _________________________________________________________________ > 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 Sep 22 17:19:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQsQu-00038s-5h for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 17:19:40 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQsQr-0000HM-OZ for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 17:19:40 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 11F1C144805D for ; Fri, 22 Sep 2006 14:19:34 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 550F7430018 for ; Fri, 22 Sep 2006 14:18:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 373841448018 for ; Fri, 22 Sep 2006 14:18:50 -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 684611448006 for ; Fri, 22 Sep 2006 14:18:49 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so1209375pyu for ; Fri, 22 Sep 2006 14:18:48 -0700 (PDT) Received: by 10.35.102.1 with SMTP id e1mr2203096pym; Fri, 22 Sep 2006 14:18:48 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Fri, 22 Sep 2006 14:18:48 -0700 (PDT) Message-ID: <26140d940609221418u71f5bd1emeffb195905033a27@mail.gmail.com> Date: Fri, 22 Sep 2006 17:18:48 -0400 From: "Michael Montemurro" To: capwap 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.7 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_10_20, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Proposed resolution to Issue 217 - Frame format when wtp encrypts/decrypts X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1040700258==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 --===============1040700258== Content-Type: multipart/alternative; boundary="----=_Part_54160_9437155.1158959928255" ------=_Part_54160_9437155.1158959928255 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline According to CAPWAP-02, section 11.7 states that the WTP must format the frame according to the IEEE 802.11 specification as described in the IEEE 802.11 (1999) standard. If that is the case, the WTP would transmit the frame to the AC in the same IEEE 802.11 frame format. An AC would use the frame format described in the IEEE 802.11 specification to transmit a frame to the WTP. The WTP would then encrypt the frame and transmit it over the wireless network to the destination. I propose that we do not change CAPWAP to resolve this issue. Cheers, Mike ------=_Part_54160_9437155.1158959928255 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
According to CAPWAP-02, section 11.7 states that the WTP must format the frame according to the IEEE 802.11 specification as described in the IEEE 802.11 (1999) standard.
 
If that is the case, the WTP would transmit the frame to the AC in the same IEEE 802.11 frame format. An AC would use the frame format described in the IEEE 802.11 specification to transmit a frame to the WTP. The WTP would then encrypt the frame and transmit it over the wireless network to the destination.
 
I propose that we do not change CAPWAP to resolve this issue.
 
Cheers,
 
Mike
------=_Part_54160_9437155.1158959928255-- --===============1040700258== 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 --===============1040700258==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 22 17:24:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQsVM-0004oQ-0g for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 17:24:16 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQsVJ-0000z9-JE for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 17:24:15 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id CEA25144806C for ; Fri, 22 Sep 2006 14:24:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 468ED430018 for ; Fri, 22 Sep 2006 14:23:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 327EE1448018 for ; Fri, 22 Sep 2006 14:23:26 -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 77BDA1448019 for ; Fri, 22 Sep 2006 14:23:24 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so1210640pyu for ; Fri, 22 Sep 2006 14:23:23 -0700 (PDT) Received: by 10.35.18.4 with SMTP id v4mr2208676pyi; Fri, 22 Sep 2006 14:23:23 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Fri, 22 Sep 2006 14:23:22 -0700 (PDT) Message-ID: <26140d940609221423q8bee4c2m799cf15b615583dd@mail.gmail.com> Date: Fri, 22 Sep 2006 17:23:22 -0400 From: "Michael Montemurro" To: capwap 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.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: Subject: [Capwap] Issue 216 - setting of the m-bit for 802.3 frames X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1344340494==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 --===============1344340494== Content-Type: multipart/alternative; boundary="----=_Part_54200_8050392.1158960202843" ------=_Part_54200_8050392.1158960202843 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline In section 4.1, the m-bit is required to transport IEEE 802.3 frames. I propose we remove the last sentence in the m-bit description: "This field MUST NOT be set to one in packets sent by the AC to the WTP." Cheers, Mike ------=_Part_54200_8050392.1158960202843 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline In section 4.1, the m-bit is required to transport IEEE 802.3 frames. I propose we remove the last sentence in the m-bit description:
"This field MUST NOT be set to one in packets sent by the AC to the WTP."
 
Cheers,
 
Mike
------=_Part_54200_8050392.1158960202843-- --===============1344340494== 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 --===============1344340494==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 22 17:29:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQsaM-0007XN-Nn for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 17:29:26 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQsaK-0001Zn-9m for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 17:29:26 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id CEFD9144806D for ; Fri, 22 Sep 2006 14:29:20 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id EB693430018 for ; Fri, 22 Sep 2006 14:28:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D384F398017 for ; Fri, 22 Sep 2006 14:28:34 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by zoidberg.tigertech.net (Postfix) with ESMTP id D1524398055 for ; Fri, 22 Sep 2006 14:28:32 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so1212061pyu for ; Fri, 22 Sep 2006 14:28:32 -0700 (PDT) Received: by 10.35.91.10 with SMTP id t10mr2218670pyl; Fri, 22 Sep 2006 14:28:32 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Fri, 22 Sep 2006 14:28:32 -0700 (PDT) Message-ID: <26140d940609221428l6118d7fdg54a1fed3cab704d0@mail.gmail.com> Date: Fri, 22 Sep 2006 17:28:32 -0400 From: "Michael Montemurro" To: capwap MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.901 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Proposed resolution to Issue 214 - Prioritization of IEEE 802.1X frames X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0222671861==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 --===============0222671861== Content-Type: multipart/alternative; boundary="----=_Part_54304_23536968.1158960512174" ------=_Part_54304_23536968.1158960512174 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as IEEE 802.11 Management frames. I will update Section 11.5, rename Quality of Service for IEEE 802.11Control Messages to "Quality of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to indicate that IEEE 802.1X frames are sent at a higher priority. Cheers, Mike ------=_Part_54304_23536968.1158960512174 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as IEEE 802.11 Management frames.
 
I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages to "Quality
of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to indicate that IEEE 802.1X frames are sent at a higher priority.
 
Cheers,
 
Mike
------=_Part_54304_23536968.1158960512174-- --===============0222671861== 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 --===============0222671861==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 22 17:32:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQsdb-0000M4-BG for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 17:32:47 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQsdZ-00023x-VX for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 17:32:47 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 749961448067 for ; Fri, 22 Sep 2006 14:32:42 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8C1AA430018 for ; Fri, 22 Sep 2006 14:31:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 779571448061 for ; Fri, 22 Sep 2006 14:31:56 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by hermes.tigertech.net (Postfix) with ESMTP id 2F7241448060 for ; Fri, 22 Sep 2006 14:31:54 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so1212984pyu for ; Fri, 22 Sep 2006 14:31:54 -0700 (PDT) Received: by 10.35.60.15 with SMTP id n15mr1672304pyk; Fri, 22 Sep 2006 14:31:53 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Fri, 22 Sep 2006 14:31:53 -0700 (PDT) Message-ID: <26140d940609221431v2646f6b4sc21b3ed5965ba5cf@mail.gmail.com> Date: Fri, 22 Sep 2006 17:31:53 -0400 From: "Michael Montemurro" To: capwap 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.6 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_20_30, HTML_MESSAGE, HTML_SHORT_LENGTH, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: [Capwap] Proposed resolution to issue 212 - QoS field in add mobile message element. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1584129186==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.2 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 --===============1584129186== Content-Type: multipart/alternative; boundary="----=_Part_54388_27053427.1158960713817" ------=_Part_54388_27053427.1158960713817 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline The QoS field is included in a separate message element. I propose to ------=_Part_54388_27053427.1158960713817 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
The QoS field is included in a separate message element. I propose to
 
------=_Part_54388_27053427.1158960713817-- --===============1584129186== 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 --===============1584129186==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 22 17:38:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQsip-0002l8-Vk for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 17:38:11 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQsib-0002cB-Em for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 17:38:11 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 04F051448065 for ; Fri, 22 Sep 2006 14:37:54 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 429F9430018 for ; Fri, 22 Sep 2006 14:37:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1EEF81448030 for ; Fri, 22 Sep 2006 14:37:13 -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 4BF231448024 for ; Fri, 22 Sep 2006 14:37:10 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so1214345pyu for ; Fri, 22 Sep 2006 14:37:10 -0700 (PDT) Received: by 10.35.76.10 with SMTP id d10mr2231910pyl; Fri, 22 Sep 2006 14:37:10 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Fri, 22 Sep 2006 14:37:10 -0700 (PDT) Message-ID: <26140d940609221437o76d87534i59e0f20b0ea7651@mail.gmail.com> Date: Fri, 22 Sep 2006 17:37:10 -0400 From: "Michael Montemurro" To: capwap In-Reply-To: <26140d940609221431v2646f6b4sc21b3ed5965ba5cf@mail.gmail.com> MIME-Version: 1.0 References: <26140d940609221431v2646f6b4sc21b3ed5965ba5cf@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.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Proposed resolution to issue 212 - QoS field in add mobile message element. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0950864324==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 --===============0950864324== Content-Type: multipart/alternative; boundary="----=_Part_54448_27171652.1158961030262" ------=_Part_54448_27171652.1158961030262 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Oops...hit the wrong key. :-) I propose to: - delete the paragraph in section 11.9.9 (Add Mobile) describing the QoS field. - add a paragraph in section 11.9.20 (IEEE 802.11 Update Mobile QoS) to describe that the message element is used with the Add Mobile message element, similar to what's described in 11.9.10. Cheers, Mike On 9/22/06, Michael Montemurro wrote: > > The QoS field is included in a separate message element. I propose to > > ------=_Part_54448_27171652.1158961030262 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Oops...hit the wrong key. :-)
 
I propose to:
- delete the paragraph in section 11.9.9 (Add Mobile) describing the QoS field.
- add a paragraph in section 11.9.20 (IEEE 802.11 Update Mobile QoS) to describe that the message element is used with the Add Mobile message element, similar to what's described in 11.9.10.
 
Cheers,
 
Mike

 
On 9/22/06, Michael Montemurro <montemurro.michael@gmail.com> wrote:
The QoS field is included in a separate message element. I propose to
 

------=_Part_54448_27171652.1158961030262-- --===============0950864324== 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 --===============0950864324==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 22 18:14:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQtIM-0004Sa-N1 for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 18:14:54 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQtII-00081v-SL for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 18:14:54 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 2A1DE1448062 for ; Fri, 22 Sep 2006 15:14:47 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 72DA2430018 for ; Fri, 22 Sep 2006 15:14:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4D7791448019 for ; Fri, 22 Sep 2006 15:14:00 -0700 (PDT) X-Greylist-Status: Sender first seen 1 day 13:26:50 ago Received: from thingmagic.com (unknown [204.9.221.19]) by hermes.tigertech.net (Postfix) with ESMTP id CB8A91448018 for ; Fri, 22 Sep 2006 15:13:56 -0700 (PDT) Received: from [66.30.121.250] (account margaret HELO [192.168.2.5]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1312531 for capwap@frascone.com; Fri, 22 Sep 2006 18:13:55 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <5F09D220B62F79418461A978CA0921BD012F17A6@pslexc01.psl.local> References: <5F09D220B62F79418461A978CA0921BD012F17A6@pslexc01.psl.local> Message-Id: <44BF3789-8410-4DD4-A23D-4C08CF94F0E4@thingmagic.com> From: Margaret Wasserman Date: Fri, 22 Sep 2006 18:12:08 -0400 To: capwap@frascone.com X-Mailer: Apple Mail (2.752.2) 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: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 7da5a831c477fb6ef97f379a05fb683c Hi All, I'm trying to get a read on whether this issue needs further discussion or not... Saravanan has made a proposal for change to the specification, and he has offered an explanation for the motivation behind this proposal (see below). Pat Calhoun has argued that this level of flexibility is unnecessary and that the specification fully supports IEEE 802.11i and meets the requirements, as written. I've seen a few notes in support of Pat's position and I haven't noticed anyone else supporting Saravanan's proposal. If there are others who support Saravanan's proposal, please speak up. Unless we see strong support for this proposal, we'll have to conclude that the WG does not have consensus to make this change. Margaret On Sep 22, 2006, at 5:03 AM, Saravanan Govindan wrote: > Hi Margaret, > > Thank you for reviewing the discussion on this issue. > > The issue here is the working of IEEE 802.11i when the 802.11i > authenticator element is at the AC and the 802.11i crypto element > is at > the WTP. Particularly, it is for the 4-way handshake between > authenticator and supplicant. > > Now, the 4-way handshake requires knowing the value of KeyRSC sequence > counter. The KeyRSC helps both authenticator and supplicant keep track > of their exchanges. It serves to protect against threats by tracking > sequential frames. The KeyRSC is maintained at the at the point of > encryption, i.e. just before transmission over the wireless channel. > > In the case of CAPWAP, the 4-way handshake is between the AC > (authenticator) and the wireless station (supplicant). > > The problem arises, when the authenticator is at the AC and the crypto > element (together with KeyRSC) is at the WTP. This is a fairly common > design. Now in this case, the AC starts the 4-way handshake but it > does > not know the value of the KeyRSC. The KeyRSC is maintained by the WTP. > > Based on this, the current CAPWAP specification does not allow for > a way > to conduct the 4-way handshake with the correct KeyRSC. > > The functionality I would like to see is a way for the authenticator > (AC) to use the correct prevailing value of KeyRSC (maintained by the > WTP) in its 4-way handshake. > > One way to introduce this functionality in to CAPWAP is to have > part of > the 4-way handshake be sent from AC to WTP. This will allow the 4-way > handshake to use the correct value of the KeyRSC before being sent to > the wireless station. > > I hope this helps clarify my view on the issue. > > Cheers, > > Saravanan > > > > > > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, September 21, 2006 8:26 PM > To: Saravanan Govindan > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > Hi again, > > Okay, I am even more confused than I thought I was... > > Saravanan, you wrote: > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > >> Pat, >> >> The issue here is about how 802.11i exchanges are done when >> authenticator is at the AC and crypto elements are at the WTP. >> This is >> the requirement. > > And, in response, Pat Calhoun wrote: > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: >> The current specification allows the authenticator to reside in the >> AC, >> while the data packet crypto elements in the WTP. This feature is >> already in the specification. > > Pat's message matches my reading of the specification. > > So, Saravanan, what functionality are you asking for that is not > already supported by the specification? And why do you think it is > necessary? it will not be helpful to my understanding to re-send > your proposal or to cite the requirements document... Please > summarize what functionality you think is missing from the current > specification and why you think that functionality is necessary to > support IEEE 802.11i or any important use case. > > At some point, the chairs may need to make a consensus call on this > issue, and I'd like to understand your view and make sure that it has > been clearly communicated to the WG before we ask the WG to decide on > this issue. > > 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 Fri Sep 22 18:19:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQtMj-0005PV-Jf for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 18:19:25 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQtMh-0000gI-VY for capwap-archive@lists.ietf.org; Fri, 22 Sep 2006 18:19:25 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 72E161448067 for ; Fri, 22 Sep 2006 15:19:20 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4ACE3430018 for ; Fri, 22 Sep 2006 15:18:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 24F88398038 for ; Fri, 22 Sep 2006 15:18:21 -0700 (PDT) Received: from sacmta01.flextronics.com (sacmta01.flextronics.com [205.173.129.14]) by zoidberg.tigertech.net (Postfix) with ESMTP id 97CE039802F for ; Fri, 22 Sep 2006 15:18:19 -0700 (PDT) Received: from AMSAC501.americas.ad.flextronics.com (amsac501.americas.ad.flextronics.com [10.10.9.189]) by sacmta01.flextronics.com (Symantec Mail Security) with ESMTP id D60B58D; Fri, 22 Sep 2006 15:18:17 -0700 (PDT) Received: from AMSACEX1.americas.ad.flextronics.com ([10.10.9.185]) by AMSAC501.americas.ad.flextronics.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Sep 2006 15:18:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Sep 2006 15:18:16 -0700 Message-ID: <7D18BEC883BA014EA4FEBF35727E3602AC9F7D@AMSACEX1.americas.ad.flextronics.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbelHtY03duHyNcQpOTYEY6mc+uAwAAB9YA From: "T Sridhar" To: "Margaret Wasserman" , X-OriginalArrivalTime: 22 Sep 2006 22:18:17.0892 (UTC) FILETIME=[013D3640:01C6DE95] X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: b360bd6cb019c35178e5cf9eeb747a5c Hi, It would be good to get a summary of the reasons why this proposal should be accepted or rejected. Currently we have a number of email threads on this topic but a summary would be great. Saravanan/Pat - could you folks help? Thanks, Sridhar -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com] Sent: Friday, September 22, 2006 3:12 PM To: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi All, I'm trying to get a read on whether this issue needs further discussion or not... Saravanan has made a proposal for change to the specification, and he has offered an explanation for the motivation behind this proposal (see below). Pat Calhoun has argued that this level of flexibility is unnecessary and that the specification fully supports IEEE 802.11i and meets the requirements, as written. I've seen a few notes in support of Pat's position and I haven't noticed anyone else supporting Saravanan's proposal. If there are others who support Saravanan's proposal, please speak up. Unless we see strong support for this proposal, we'll have to conclude that the WG does not have consensus to make this change. Margaret On Sep 22, 2006, at 5:03 AM, Saravanan Govindan wrote: > Hi Margaret, > > Thank you for reviewing the discussion on this issue. > > The issue here is the working of IEEE 802.11i when the 802.11i > authenticator element is at the AC and the 802.11i crypto element > is at > the WTP. Particularly, it is for the 4-way handshake between > authenticator and supplicant. > > Now, the 4-way handshake requires knowing the value of KeyRSC sequence > counter. The KeyRSC helps both authenticator and supplicant keep track > of their exchanges. It serves to protect against threats by tracking > sequential frames. The KeyRSC is maintained at the at the point of > encryption, i.e. just before transmission over the wireless channel. > > In the case of CAPWAP, the 4-way handshake is between the AC > (authenticator) and the wireless station (supplicant). > > The problem arises, when the authenticator is at the AC and the crypto > element (together with KeyRSC) is at the WTP. This is a fairly common > design. Now in this case, the AC starts the 4-way handshake but it > does > not know the value of the KeyRSC. The KeyRSC is maintained by the WTP. > > Based on this, the current CAPWAP specification does not allow for > a way > to conduct the 4-way handshake with the correct KeyRSC. > > The functionality I would like to see is a way for the authenticator > (AC) to use the correct prevailing value of KeyRSC (maintained by the > WTP) in its 4-way handshake. > > One way to introduce this functionality in to CAPWAP is to have > part of > the 4-way handshake be sent from AC to WTP. This will allow the 4-way > handshake to use the correct value of the KeyRSC before being sent to > the wireless station. > > I hope this helps clarify my view on the issue. > > Cheers, > > Saravanan > > > > > > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, September 21, 2006 8:26 PM > To: Saravanan Govindan > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > Hi again, > > Okay, I am even more confused than I thought I was... > > Saravanan, you wrote: > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > >> Pat, >> >> The issue here is about how 802.11i exchanges are done when >> authenticator is at the AC and crypto elements are at the WTP. >> This is >> the requirement. > > And, in response, Pat Calhoun wrote: > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: >> The current specification allows the authenticator to reside in the >> AC, >> while the data packet crypto elements in the WTP. This feature is >> already in the specification. > > Pat's message matches my reading of the specification. > > So, Saravanan, what functionality are you asking for that is not > already supported by the specification? And why do you think it is > necessary? it will not be helpful to my understanding to re-send > your proposal or to cite the requirements document... Please > summarize what functionality you think is missing from the current > specification and why you think that functionality is necessary to > support IEEE 802.11i or any important use case. > > At some point, the chairs may need to make a consensus call on this > issue, and I'd like to understand your view and make sure that it has > been clearly communicated to the WG before we ask the WG to decide on > this issue. > > 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 Legal Disclaimer: The information contained in this message may be privileged and confidential. It is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete or destroy any copy of this message _________________________________________________________________ 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 Sep 23 04:07:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR2Y8-0007dz-Ge for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 04:07:48 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GR2Y6-0007P6-Sh for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 04:07:48 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id B553A398080 for ; Sat, 23 Sep 2006 01:07:35 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id AE5F8430018 for ; Sat, 23 Sep 2006 01:06:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 63FE539803F for ; Sat, 23 Sep 2006 01:06:54 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [61.144.161.54]) by zoidberg.tigertech.net (Postfix) with ESMTP id D50E7398008 for ; Sat, 23 Sep 2006 01:06:50 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6100J4QE2JYU@szxga02-in.huawei.com> for capwap@frascone.com; Sat, 23 Sep 2006 16:25:31 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6100FHOE2I3I@szxga02-in.huawei.com> for capwap@frascone.com; Sat, 23 Sep 2006 16:25:31 +0800 (CST) Received: from dell60 ([10.18.23.153]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J6100CQIDFRP5@szxml03-in.huawei.com> for capwap@frascone.com; Sat, 23 Sep 2006 16:11:55 +0800 (CST) Date: Sat, 23 Sep 2006 13:36:41 +0530 From: sujay In-reply-to: <44BF3789-8410-4DD4-A23D-4C08CF94F0E4@thingmagic.com> To: 'Margaret Wasserman' Message-id: <008901c6dee7$34760800$9917120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcbelGnol3dBhUA9RLCxueQXurfPBAAUhvYg 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, 'Saravanan Govindan' Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 20f22c03b5c66958bff5ef54fcda6e48 Hi Margaret/Pat, I am not sure which section in the current specs solves the issue pointed out by Saravanan . (.. my ignorance !) Could anyone give some pointers? Regds, Sujay G My Location; http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=h &hl=en This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com] Sent: Saturday, September 23, 2006 3:42 AM To: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi All, I'm trying to get a read on whether this issue needs further discussion or not... Saravanan has made a proposal for change to the specification, and he has offered an explanation for the motivation behind this proposal (see below). Pat Calhoun has argued that this level of flexibility is unnecessary and that the specification fully supports IEEE 802.11i and meets the requirements, as written. I've seen a few notes in support of Pat's position and I haven't noticed anyone else supporting Saravanan's proposal. If there are others who support Saravanan's proposal, please speak up. Unless we see strong support for this proposal, we'll have to conclude that the WG does not have consensus to make this change. Margaret On Sep 22, 2006, at 5:03 AM, Saravanan Govindan wrote: > Hi Margaret, > > Thank you for reviewing the discussion on this issue. > > The issue here is the working of IEEE 802.11i when the 802.11i > authenticator element is at the AC and the 802.11i crypto element is > at the WTP. Particularly, it is for the 4-way handshake between > authenticator and supplicant. > > Now, the 4-way handshake requires knowing the value of KeyRSC sequence > counter. The KeyRSC helps both authenticator and supplicant keep track > of their exchanges. It serves to protect against threats by tracking > sequential frames. The KeyRSC is maintained at the at the point of > encryption, i.e. just before transmission over the wireless channel. > > In the case of CAPWAP, the 4-way handshake is between the AC > (authenticator) and the wireless station (supplicant). > > The problem arises, when the authenticator is at the AC and the crypto > element (together with KeyRSC) is at the WTP. This is a fairly common > design. Now in this case, the AC starts the 4-way handshake but it > does not know the value of the KeyRSC. The KeyRSC is maintained by the > WTP. > > Based on this, the current CAPWAP specification does not allow for a > way to conduct the 4-way handshake with the correct KeyRSC. > > The functionality I would like to see is a way for the authenticator > (AC) to use the correct prevailing value of KeyRSC (maintained by the > WTP) in its 4-way handshake. > > One way to introduce this functionality in to CAPWAP is to have part > of the 4-way handshake be sent from AC to WTP. This will allow the > 4-way handshake to use the correct value of the KeyRSC before being > sent to the wireless station. > > I hope this helps clarify my view on the issue. > > Cheers, > > Saravanan > > > > > > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, September 21, 2006 8:26 PM > To: Saravanan Govindan > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > Hi again, > > Okay, I am even more confused than I thought I was... > > Saravanan, you wrote: > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > >> Pat, >> >> The issue here is about how 802.11i exchanges are done when >> authenticator is at the AC and crypto elements are at the WTP. >> This is >> the requirement. > > And, in response, Pat Calhoun wrote: > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: >> The current specification allows the authenticator to reside in the >> AC, while the data packet crypto elements in the WTP. This feature is >> already in the specification. > > Pat's message matches my reading of the specification. > > So, Saravanan, what functionality are you asking for that is not > already supported by the specification? And why do you think it is > necessary? it will not be helpful to my understanding to re-send your > proposal or to cite the requirements document... Please summarize > what functionality you think is missing from the current specification > and why you think that functionality is necessary to support IEEE > 802.11i or any important use case. > > At some point, the chairs may need to make a consensus call on this > issue, and I'd like to understand your view and make sure that it has > been clearly communicated to the WG before we ask the WG to decide on > this issue. > > 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 _________________________________________________________________ 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 Sep 23 05:12:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR3Yv-0005KL-Ae for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 05:12:41 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GR3Ys-0007KE-RP for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 05:12:41 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id B07354308C5 for ; Sat, 23 Sep 2006 02:12:34 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 6F6C5430018 for ; Sat, 23 Sep 2006 02:11:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5926E4308C7 for ; Sat, 23 Sep 2006 02:11:47 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [12.129.211.51]) by hermes.tigertech.net (Postfix) with ESMTP id 88B3A4308D1 for ; Sat, 23 Sep 2006 02:11:44 -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 <0J6100ALPG2CXS@usaga01-in.huawei.com> for capwap@frascone.com; Sat, 23 Sep 2006 02:08:36 -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 <0J61003X6G2AFP@usaga01-in.huawei.com> for capwap@frascone.com; Sat, 23 Sep 2006 02:08:36 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.18.23.62]) by szxmc01-in.huawei.com (mshttpd); Sat, 23 Sep 2006 14:11:47 +0500 Date: Sat, 23 Sep 2006 14:11:47 +0500 From: zhaoyujin 31390 To: Michael Montemurro Message-id: <24efdee24ea3d3.24ea3d324efdee@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_8zlDUZBsW8LuOXITywyZFw)" 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.8 tagged_above=-999.0 required=7.0 tests=HTML_20_30, HTML_MESSAGE, MIME_HTML_MOSTLY X-Spam-Level: Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 - Prioritization of IEEE 802.1X frames X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.8 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a This is a multi-part message in MIME format. --Boundary_(ID_8zlDUZBsW8LuOXITywyZFw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Firstly, I have some doubt one this suggestion. 1. If CAPWAP difines like this, AP device must decode the payload frames of 802.11 frames. 2. Another problem, the 802.1x priority should be implement by 802.11e. When station sends 802.11 data frames, it can set 802.11e priority. AP should transfer 802.11e to actual CAPWAP packet priority. So that I think CAPWAP does not need consider the priority of 802.11 data frames payload. Thanks Michael >Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as >IEEE 802.11 Management frames. > >I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages >to "Quality >of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to >indicate that IEEE 802.1X frames are sent at a higher priority. > >Cheers, > >Mike This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! --Boundary_(ID_8zlDUZBsW8LuOXITywyZFw) Content-type: multipart/alternative; boundary="Boundary_(ID_B+ez/slEmEB2EQUQt7FmRw)" --Boundary_(ID_B+ez/slEmEB2EQUQt7FmRw) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as IEEE 802.11 Management frames. I will update Section 11.5, rename Quality of Service for IEEE 802.11Control Messages to "Quality of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to indicate that IEEE 802.1X frames are sent at a higher priority. Cheers, Mike --Boundary_(ID_B+ez/slEmEB2EQUQt7FmRw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline
Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as IEEE 802.11 Management frames.
 
I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages to "Quality
of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to indicate that IEEE 802.1X frames are sent at a higher priority.
 
Cheers,
 
Mike
--Boundary_(ID_B+ez/slEmEB2EQUQt7FmRw)-- --Boundary_(ID_8zlDUZBsW8LuOXITywyZFw) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii 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 --Boundary_(ID_8zlDUZBsW8LuOXITywyZFw) 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 --Boundary_(ID_8zlDUZBsW8LuOXITywyZFw)-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Sep 23 09:39:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR7ik-0006Fg-MZ for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 09:39:06 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GR7ie-0002p0-94 for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 09:39:06 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 18BCB1448054 for ; Sat, 23 Sep 2006 06:38:48 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 689D343005A for ; Sat, 23 Sep 2006 06:37:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 48CD639800D for ; Sat, 23 Sep 2006 06:37:41 -0700 (PDT) X-Greylist-Status: Sender first seen 2 days 04:50:31 ago Received: from thingmagic.com (unknown [204.9.221.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 719BE398022 for ; Sat, 23 Sep 2006 06:37:37 -0700 (PDT) Received: from [66.30.121.250] (account margaret HELO [192.168.2.5]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1313741; Sat, 23 Sep 2006 09:37:35 -0400 In-Reply-To: <7D18BEC883BA014EA4FEBF35727E3602AC9F7D@AMSACEX1.americas.ad.flextronics.com> References: <7D18BEC883BA014EA4FEBF35727E3602AC9F7D@AMSACEX1.americas.ad.flextronics.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: Margaret Wasserman Date: Sat, 23 Sep 2006 09:35:48 -0400 To: T Sridhar X-Mailer: Apple Mail (2.752.2) 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] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: c075d775af780178ad8663695edfd43a Hi All, [Pat and Saravanan, I have asked some questions of each of you below. In particular, please note the request for more information at the end of the main message, before the beginning of the references section.] At T. Sridhar's request, I'll attempt to summarize the discussion on this issue to date. I realize that this is a _very_ long "summary". Sadly, it may actually be longer than the discussion that it is attempting to summarize... However, if you take the time to read this message, I think that we may be able to reach a good, shared understanding of this issue, which may help us to make a wise and well-informed decision. First, let me point out the relevant portions of the CAPWAP-related documents... == RFC 4564, Section 5.1.10, "IEEE 802.11i Considerations" == This section describes the CAPWAP protocol security requirements related to IEEE 802.11i. It is included under the "Mandatory and Accepted Objectives" section. The full text of this section is included below for reference. The normative text in this section states: "The CAPWAP protocol MUST determine the exact structure of the centralized WLAN architecture in which authentication needs to be supported, i.e., the location of major authentication components. This may be achieved during WTP initialization where major capabilities are distinguished. The protocol MUST allow for the exchange of key information when authenticator and encryption roles are located in distinct entities." In the discussion portion of this section, there is a reference to the "Architecture Taxonomy" document, RFC 4118, and there is an indication that CAPWAP must support the variants described in that document. In summary, this section places two requirements on the CAPWAP protocol: 1) The AC must be able to determine where the authentication and encryption functions reside. (2) The protocol must support the transfer of key information if the authentication and encryption functions reside on different entities. == RFC 4118, Section 5.8.1, "Client Data Security" == This section describes how 802.11 encryption and the 802.11x authenticator function can reside on different entities. The full text of this section is included below for reference. In summary, this section states that the termination point for "over the air" encryption may reside in either the WTP or the AC. It also states that "in most cases" authentication will be performed by the AC. If the encryption is terminated at the WTP, and authentication is performed on the AC, then the pair-wise transient key (PTK) needs to be transferred from the AC to the WTP over a secure channel. It then goes on to discuss some key management issues. == draft-ietf-capwap-protocol-specification-02.txt, Section 4.4.33, "WTP Descriptor" == == draft-ietf-capwap-protocol-specification-02.txt, Section 11.1.1, "Split MAC" == == draft-ietf-capwap-protocol-specification-02.txt,Section 11.1.2, "Local MAC" == Although authentication and encryption are mentioned in various places in the CAPWAP specification, I think it is possible to get an overview of the currently described functionality from reading the three sections listed above, all of which are included at the end of this message for reference. The WTP Descriptor includes a field called "Encryption Capabilities" that allows the WTP to tell the AC whether or not it supports encryption, and to provide binding-specific information regarding what encryption capabilities are supported. If a WTP supports encryption, the AC may (depending on AC configuration) choose to take advantage of that. The Split MAC and Local MAC sections make it clear that both architectures support cases where encryption is supported on either the AC or the WTP, and they both include a provision for securely passing key information to the WTP when encryption is being performed there. Now I'll offer my own interpretation of the above sections... As indicated above, RFC 4564 places two requirements on the CAPWAP protocol: 1) The AC must determine where the authentication and encryption functions reside. (2) The protocol must support the transfer of key information if the authentication and encryption functions reside on different entities. Although the wording in the requirements document is quite abstract, the referenced Architecture Taxonomy makes it clear that we are really talking about cases where authentication resides on the AC and the encryption endpoint resides on either the WTP or the AC. In any case, the requirements document does not seem to place a normative requirement on the CAPWAP specification to support specific configurations, merely for the AC to be able to determine the configuration in use, and for the protocol to be able to securely pass keys between the authenticator and the encryption endpoint if they reside on different entities. The currently-defined CAPWAP protocol meets the first requirement by providing a mechanism for the AC to discover the encryption capabilities of the WTP and to then determine whether the encryption endpoint will be on the WTP or the AC. In the CAPWAP protocol, authentication is always supported on the AC, so no mechanism is needed to discover/determine that. The second requirement is met by the key transfer functions included in both the Split MAC and Local MAC architectures. So, based on my interpretation, the current CAPWAP protocol document does attempt to meet both of the normative requirements from RFC 4564. However, that doesn't mean that we can simply reject this issue, because Saravanan may actually be pointing out a technical flaw in the CAPWAP specification. Saravanan has raised the point, which I don't believe is disputed, that the 4-way handshake will only work properly when the KeyRSC is located on the AC, not when the KeyRSC is located on the WTP. However, Saravanan claims that the KeyRSC will reside at the encryption endpoint (the WTP in this case), not at the authentication endpoint (the AC). If Saravanan is correct, the current 4-way handshake described in the CAPWAP specification will not work properly, because the AC will lack the information necessary to generate the KeyMIC value that it is required to provide in message 3 of the 4-way handshake. Saravanan has made a specific proposal to correct this problem that calls for a modification to the CAPWAP specification that would support the case where the KeyRSC resides at the WTP. For reference, I've included the full text of Saravanan's proposal at the end of this message. == Saravanan's proposal == [Saravanan, please let me know if I am missing or misunderstanding anything here.] In summary, Saravanan is proposing that we change how CAPWAP supports the IEEE 802.11i 4-way handshake to allow the AC to produce a nearly- complete EAPoL frame (containing everything but the KeyMIC value) and pass it to the WTP in a CAPWAP Key Configuration message. The WTP would take then use the KeyRSC to generate the KeyMIC value, insert that value into the EAPoL frame and transmit the message (which is message 3 of the 4-way handshake) to the client. == Pat's response == [Pat, please let me know if I am missing or misunderstanding anything here.] Pat has argued that it is not necessary to support the case where the KeyRSC is maintained on the WTP. Pat believes that is is possible for the encryption endpoint to reside on the WTP while the KeyRSC is maintained on the AC, and that we do not need to add additional options to the CAPWAP specification to support other cases. I personally think that Saravanan and Pat may not be communicating successfully with each other, because Saravanan seems to be saying that the CAPWAP specification will not work as specified and needs to be changed in order to function properly, and Pat seems to think that Saravanan is trying to add an option to support an additional operating mode. Am I misunderstanding something? So, there seems to be at least one point of technical disagreement between Pat and Saravanan regarding where the KeyRSC will reside in the case where the authenticator is running on the AC and the encryption endpoint resides on the WTP. Pat, could you provide some technical information that supports your position that the KeyRSC may reside on the AC, even when the encryption end-point is on the WTP? Saravanan, could you provides some technical information that supports your position that the KeyRSC will reside on the WTP when the encryption end-point is on the WTP? Margaret --- REFERENCE MATERIALS: == RFC 4564, Section 5.1.10, "IEEE 802.11i Considerations" == 5.1.10. IEEE 802.11i Considerations Classification: Operations Description: The CAPWAP protocol must support authentication in the centralized WLAN architecture in which the authenticator and encryption points can be located on distinct entities, i.e., WLAN controller or WTP. The Architecture Taxonomy illustrates a number of variants, in both local-MAC and split-MAC designs, in which the authenticator is located at the WLAN controller and the encryption points are at the WTPs. The CAPWAP protocol must be applicable to these variants and allow authentication mechanisms and their constituent processes to be operable in these cases. An important issue to consider in this case is the exchange of key information when authenticator and encryption points are located on distinct entities. For example, consider the case where IEEE 802.11i is used in a WLAN in which the WLAN controller realizes the authenticator, some WTPs realize encryption (possibly local-MAC WTPs), and other WTPs rely on the WLAN controller for encryption (possibly split-MAC WTPs). Here, CAPWAP will first need to identify the location of the authenticator and encryption points between each WLAN controller-WTP pair. This will likely be part of the initial WTP configuration. Subsequently, the WTPs that realize encryption will need CAPWAP to exchange key information with the authenticator at the WLAN controller. For the WTPs that do not realize encryption, CAPWAP needs to adapt its control to bypass the key exchange phase. Clearly, the centralized WLAN architecture presents a different platform for authentication mechanisms compared to legacy WLANs in which a WTP realized both authenticator and encryption roles. So this objective highlights the need for CAPWAP to support authentication and key management in the centralized WLAN architecture. Protocol Requirement: The CAPWAP protocol MUST determine the exact structure of the centralized WLAN architecture in which authentication needs to be supported, i.e., the location of major authentication components. This may be achieved during WTP initialization where major capabilities are distinguished. The protocol MUST allow for the exchange of key information when authenticator and encryption roles are located in distinct entities. Motivation and Protocol Benefits: The immediate focus of CAPWAP is on supporting IEEE 802.11-based WLANs. As such, it is necessary for the protocol to recognize the major distinction in WLAN design with respect to IEEE 802.11i authenticator and encryption points. This represents a significant variation that has been highlighted in the Architecture Taxonomy. The CAPWAP protocol benefits by accommodating such a major consideration from IEEE 802.11i. These requirements will be common for all authentication mechanisms over the centralized WLAN architecture. So they are applicable to IEEE 802.11i, Universal Access Method (UAM), and other mechanisms. Relation to Problem Statement: The Problem Statement highlights the availability of different WTP designs and the need to ensure interoperability among them. In this regard, operational changes occurring due to the separation of the IEEE 802.11i authenticator and encryption points need to be accommodated within the CAPWAP protocol. == RFC 4118, Section 5.8.1, "Client Data Security" == 5.8.1. Client Data Security The survey shows clearly that the termination point for "over the air" 802.11 encryption [4] can be implemented either in the WTP or in the AC. Furthermore, the 802.1X/EAP [6] functionality is distributed between the WTP and the AC where, in most cases, the AC performs the necessary functions as the authenticator in the 802.1X exchange. If the STA and AC are the parties in the 4-way handshake (defined in [4]), and 802.11i traffic encryption terminates at the WTP, then the Pairwise Transient Key (PTK) has to be transferred from the AC to the WTP. Since the keying material is part of the control and provisioning of the WTPs, a secure encrypted tunnel for control frames is employed to transport the keying material. The centralized model encourages AC implementations to use one PMK for many different WTPs. This practice facilitates speedy transition by an STA from one WTP to another that is connected to the same AC without establishing a separate PMK. However, this leaves the STA in a difficult position, as the STA cannot distinguish between a compromised PMK and one that is intentionally being shared. This issue must be resolved, but the resolution is beyond the scope of the CAPWAP working group. The venue for this resolution is to be determined by the IEEE 802 and IETF liaisons. When the 802.11i encryption/decryption is performed in the AC, the key exchange and state transitions occur between the AC and the STA. Therefore, there is no need to transfer any crypto material between the AC and the WTP. Regardless of where the 802.11i termination point occurs, the Centralized WLAN Architecture records two practices for "over the wire" client data security. In some cases there is an encrypted tunnel (IPsec or SSL) between the WTP and AC, which assumes that the security boundary is in the AC. In other cases, an end-to-end mutually authenticated secure VPN tunnel is assumed between the client and AC, other security gateway, or end host entity. == draft-ietf-capwap-protocol-specification-02.txt, Section 4.4.33, "WTP Descriptor" == 4.4.33. WTP Descriptor The WTP descriptor message element is used by a WTP to communicate it's current hardware/firmware configuration. The value contains the following fields. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max Radios | Radios in use | Encryption Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 33 for WTP Descriptor Length: >= 31 Max Radios: An 8-bit value representing the number of radios (where each radio is identified via the RID field) supported by the WTP Radios in use: An 8-bit value representing the number of radios present in the WTP Encryption Capabilities: This 16-bit field is used by the WTP to communicate it's capabilities to the AC. Since most WTP's support link layer encryption, the AC may make use of these services. There are binding dependent encryption capabilities. A WTP that does not have any encryption capabilities would set this field to zero (0). Refer to the specific binding for further specification of the Encryption Capabilities field. Vendor Identifier: A 32-bit value containing the IANA assigned "SMI Network Management Private Enterprise Codes" Type: The following values are supported. The Hardware Version, Software Version, and Boot Version values MUST be included. 0 - WTP Model Number: The WTP Model Number MUST be included in the WTP Board Data message element. 1 - WTP Serial Number: The WTP Serial Number MUST be included in the WTP Board Data message element. 2 - Board ID: A hardware identifier, which MAY be included in the WTP Board Data mesage element. 3 - Board Revision A revision number of the board, which MAY be included in the WTP Board Data message element. 4 - Hardware Version: The WTP's hardware version number. 5 - Software Version: The WTP's Firmware version number. 6 - Boot Version: The WTP's boot loader's version number. Length: Length of vendor specific encoding of WTP information. Value: Vendor specific encoding of WTP information. == draft-ietf-capwap-protocol-specification-02.txt, Section 11.1.1, "Split MAC" == 11.1.1. Split MAC This section shows the division of labor between the WTP and the AC in a Split MAC architecture. Figure 4 shows the clear separation of functionality among CAPWAP components. Function Location Distribution Service AC Integration Service AC Beacon Generation WTP Probe Response Generation WTP Power Mgmt/Packet Buffering WTP Fragmentation/Defragmentation WTP/AC Assoc/Disassoc/Reassoc AC 802.11e Classifying AC Scheduling WTP/AC Queuing WTP 802.11i 802.1X/EAP AC RSNA Key Management AC 802.11 Encryption/Decryption WTP/AC Figure 4: Mapping of 802.11 Functions for Split MAC Architecture The Distribution and Integration services reside on the AC, and therefore all user data is tunneled between the WTP and the AC. As noted above, all real-time IEEE 802.11 services, including the beacon and probe response frames, are handled on the WTP. All remaining IEEE 802.11 MAC management frames are supported on the Calhoun, Editor, et al. Expires December 23, 2006 [Page 97] Internet-Draft CAPWAP Protocol Specification June 2006 AC, including the Association Request which allows the AC to be involved in the access policy enforcement portion of the IEEE 802.11 protocol. The IEEE 802.1X and IEEE 802.11i key management function are also located on the AC. This implies that the AAA client also resides on the AC. While the admission control component of IEEE 802.11e resides on the AC, the real time scheduling and queuing functions are on the WTP. Note this does not exclude the AC from providing additional policing and scheduling functionality. Note that in the following figure, the use of '( - )' indicates that processing of the frames is done on the WTP. Client WTP AC Beacon <----------------------------- Probe Request ---------------------------- ( - )-------------------------> Probe Response <----------------------------- 802.11 AUTH/Association <---------------------------------------------------------> Mobile Config Request[Add Mobile (Clear Text, 802.1X)] <-------------------------> 802.1X Authentication & 802.11i Key Exchange <---------------------------------------------------------> Mobile Config Request[Add Mobile (AES-CCMP, PTK=x)] <-------------------------> 802.11 Action Frames <---------------------------------------------------------> 802.11 DATA (1) <--------------------------- ( - )-------------------------> Figure 5: Split MAC Message Flow Figure 5 provides an illustration of the division of labor in a Split MAC architecture. In this example, a WLAN has been created that is configured for IEEE 802.11i, using AES-CCMP for privacy. The following process occurs: o The WTP generates the IEEE 802.11 beacon frames, using information provided to it through the Add WLAN (see Section Section 11.9.1) message element. o The WTP processes the probe request and responds with a corresponding probe response. The probe request is then forwarded to the AC for optional processing. o The WTP forwards the IEEEE 802.11 Authentication and Association frames to the AC, which is responsible for responding to the client. o Once the association is complete, the AC transmits an CAPWAP Add Mobile Station request to the WTP (see Section Section 4.4.8. In the above example, the WLAN is configured for IEEE 802.1X, and therefore the '802.1X only' policy bit is enabled. o If the WTP is providing encryption/decryption services, once the client has completed the IEEE 802.11i key exchange, the AC transmits another Add Mobile request to the WTP, stating the security policy to enforce for the client (in this case AES- CCMP), as well as the encryption key to use. If encryption/ decryption is handled in the AC, the IEEE 802.11 Add Mobile Station request would not include the RSN Information Element. o The WTP forwards any 802.11 Action frames received to the AC. o All client data frames are tunneled between the WTP and the AC. Note that the WTP is responsible for encrypting and decrypting frames, if it was indicated in the Add Mobile request. == draft-ietf-capwap-protocol-specification-02.txt,Section 11.1.2, "Local MAC" == 11.1.2. Local MAC This section shows the division of labor between the WTP and the AC in a Local MAC architecture. Figure 6 shows the clear separation of functionality among CAPWAP components. Calhoun, Editor, et al. Expires December 23, 2006 [Page 99] Internet-Draft CAPWAP Protocol Specification June 2006 Function Location Distribution Service WTP Integration Service WTP Beacon Generation WTP Probe Response Generation WTP Power Mgmt/Packet Buffering WTP Fragmentation/Defragmentation WTP Assoc/Disassoc/Reassoc WTP 802.11e Classifying WTP Scheduling WTP Queuing WTP 802.11i 802.1X/EAP AC RSNA Key Management AC 802.11 Encryption/Decryption WTP Figure 6: Mapping of 802.11 Functions for Local AP Architecture Given the Distribution and Integration Services exist on the WTP, client data frames are not forwarded to the AC, with the exception listed in the following paragraphs. While the MAC is terminated on the WTP, it is necessary for the AC to be aware of mobility events within the WTPs. As a consequence, the WTP MUST forward the IEEE 802.11 Association Requests to the AC. The AC MAY reply with a failed Association Response if it deems it necessary, and upon receipt of a failed Association Response from the AC, the WTP must send a Disassociation frame to the mobile station. The IEEE 802.1X and RSNA Key Management function resides in the AC. Therefore, the WTP MUST forward all IEEE 802.1X/RSNA Key Management frames to the AC and forward the associated responses to the station. This implies that the AAA client also resides on the AC. Note that in the following figure, the use of '( - )' indicates that processing of the frames is done on the WTP. Calhoun, Editor, et al. Expires December 23, 2006 [Page 100] Internet-Draft CAPWAP Protocol Specification June 2006 Client WTP AC Beacon <----------------------------- Probe <----------------------------> 802.11 AUTH <----------------------------- 802.11 Association <--------------------------- ( - )-------------------------> Mobile Config Request[Add Mobile (Clear Text, 802.1X)] <-------------------------> 802.1X Authentication & 802.11i Key Exchange <---------------------------------------------------------> 802.11 Action Frames <---------------------------------------------------------> Mobile Config Request[Add Mobile (AES-CCMP, PTK=x)] <-------------------------> 802.11 DATA <-----------------------------> Figure 7: Local MAC Message Flow Figure 7 provides an illustration of the division of labor in a Local MAC architecture. In this example, a WLAN has been created that is configured for IEEE 802.11i, using AES-CCMP for privacy. The following process occurs: o The WTP generates the IEEE 802.11 beacon frames, using information provided to it through the Add WLAN (see Section 11.9.1) message element. o The WTP processes the probe request and responds with a corresponding probe response. o The WTP forwards the IEEE 802.11 Authentication and Association frames to the AC. o Once the association is complete, the AC transmits an CAPWAP Add Mobile Station message element to the WTP (see Section Section 4.4.8. In the above example, the WLAN is configured for IEEE 802.1X, and therefore the '802.1X only' policy bit is enabled. o The WTP forwards all IEEE 802.1X and IEEE 802.11i key exchange messages to the AC for processing. o The AC transmits another Add Mobile Station message element to the WTP, stating the security policy to enforce for the client (in this case AES-CCMP), as well as the encryption key to use. The Add Mobile Station message element MAY include a VLAN name, which when present is used by the WTP to identify the VLAN on which the user's data frames are to be bridged. o The WTP forwards any IEEE 802.11 Action frames received to the AC. o The WTP may locally bridge client data frames (and provide the necessary encryption and decryption services). The WTP may also tunnel client data frames to the AC, using 802.3 frame tunnel mode or 802.11 frame tunnel mode. == Saravanan's Proposal == All, I wanted to give a more detailed explanation for the IEEE 802.11i Considerations requirement. This note describes how CAPWAP can be updated to satisfy this requirement I would like to use this to highlight the proposal being put forward. From RFC 4564, Section 5.1.10 IEEE 802.11i Considerations Protocol Requirement: The CAPWAP protocol MUST determine the exact structure of the centralized WLAN architecture in which authentication needs to be supported, i.e., the location of major authentication components. This may be achieved during WTP initialization where major capabilities are distinguished. The protocol MUST allow for the exchange of key information when authenticator and encryption roles are located in distinct entities. Following the requirement, CAPWAP needs; 1. to incorporate authentication & encryption locations in capabilities exchange 2. to exchange key information when authentication and crypt are located in different network entities Basic case: AC does both IEEE 802.11i authentication and cryptography. For 4-way exchange, AC tracks the KeyRSC, which it then uses for Message-3, i.e., AC calculates KeyMIC and updates EAPoL frame. - 802.11i Authentication - 802.11i Crypto (KeyRSC maintained here) +----------+ +-----+ +------+ | Terminal | | WTP | | AC | +----------+ +-----+ +------+ | | | | 802.1x Authentication | |<=====================================================>| | | | PMK | PMK | | | Generate | Generate SNonce | ANonce | | | | | | | Message-1 | |<-------------------------|<---------------------------| | EAPoL Packet | CAPWAP Packet | Receive | | ANonce | | Generate | | PTK | | | | | | Message-2 | |------------------------->|--------------------------->| | EAPoL Packet | CAPWAP Packet | | | Receive | | SNonce | | | | | Generate | | PTK | | GTK | Message-3 | |<-------------------------|<---------------------------| | EAPoL Packet | CAPWAP Packet | | | | | | | | +-----------------------+ | | \|- EAPoL Frame | Receive | +-----------------------+ GTK | | | | | | | | | Message-4 | |------------------------->|--------------------------->| | EAPoL Packet | CAPWAP Packet | | | | Case specified by RFC 4564: The 802.11i Considerations requirement considers the case where 802.11i authentication is at AC and 802.11i crypto is at WTP. So now, the WTP maintains the KeyRSC while the AC requires this information to generate the EAPoL frame for Message-3 of the 4-way handshake. The diagram below shows this; - 802.11i Crypto (KeyRSC maintained here) - 802.11i Authentication +----------+ +-----+ +------+ | Terminal | | WTP | | AC | +----------+ +-----+ +------+ | | | | 802.1x Authentication | |<=====================================================>| | | | PMK | PMK | | | Generate | Generate SNonce | ANonce | | | In this case, the EAPoL frame generated by the AC will not be based on the prevailing value of the KeyRSC, as this counter is maintained by the WTP. This problem is currently not solved in the CAPWAP specifications. Proposal: The proposal is to include a CAPWAP Key Configuration message that can transport the EAPoL frame between AC and WTP before being sent to the client (terminal). Key Configuration is a control message sent by the AC to the WTP. The message contains Message-3 of the 4-way handshake - including the EAPoL-frame. However, the EAPoL frame has its KeyMIC field unassigned as the AC cannot accurately calculate this. So on receiving the Key Configuration - containing EAPoL frame with unassigned KeyMIC field, the WTP retrieves the value of the KeyRSC it maintains and computes the corresponding KeyMIC. The EAPoL frame is then updated and Message-3 of the 4-way handshake is reconstructed before being sent over the wireless link to the client. The diagram below illustrates this; - 802.11i Crypto (KeyRSC maintained here) - 802.11i Authentication +----------+ +-----+ +------+ | Terminal | | WTP | | AC | +----------+ +-----+ +------+ | | | | 802.1x Authentication | |<=====================================================>| | | | PMK | PMK | | | Generate | Generate SNonce | ANonce | | | | | | | Message 1 | |<-------------------------|<---------------------------| | EAPoL Packet | CAPWAP Packet | Receive | | ANonce | | Generate | | PTK | | | | | | Message 2 | |------------------------->|--------------------------->| | EAPoL Packet | CAPWAP Packet | | | Receive | | SNonce | | | | | Generate | | PTK | | GTK | | Message 3 | | |<===========================| | | CAPWAP Packet | | | (Key Configuration) | | | | +-----------------------+ | | \|- GTK-Flag | | -Retrieve KeyRSC |- Encryption-Data(PTK) | | -Update KeyMIC |- Encryption-Data(GTK) | | -Reconstruct |- EAP-Frame | | Message-3 +-----------------------+ | | | |<-------------------------| | | EAPoL Packet | | Receive | | GTK | | | Message 4 | |------------------------->|--------------------------->| | EAPoL Packet | CAPWAP Packet | | | | This proposal very simply solves the problem while directly addressing the requirement for IEEE 802.11i Considerations. Cheers, Saravanan _________________________________________________________________ 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 Sep 23 13:16:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRB70-0007FH-Q6 for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 13:16:22 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRB6y-00082J-Bs for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 13:16:22 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2F3873980D8 for ; Sat, 23 Sep 2006 10:16:11 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 944C043005A for ; Sat, 23 Sep 2006 10:15:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 43B531448010 for ; Sat, 23 Sep 2006 10:15:38 -0700 (PDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by hermes.tigertech.net (Postfix) with ESMTP id E45B11448001 for ; Sat, 23 Sep 2006 10:15:35 -0700 (PDT) Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id k8NHFUle007052; Sat, 23 Sep 2006 13:15:30 -0400 (EDT) Date: Sat, 23 Sep 2006 13:15:30 -0400 (EDT) From: "T. Charles Clancy" To: T Sridhar In-Reply-To: <7D18BEC883BA014EA4FEBF35727E3602AC9F7D@AMSACEX1.americas.ad.flextronics.com> Message-ID: References: <7D18BEC883BA014EA4FEBF35727E3602AC9F7D@AMSACEX1.americas.ad.flextronics.com> 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.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: Margaret Wasserman , capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 69a74e02bbee44ab4f8eafdbcedd94a1 I think all the discussions about the requirements and taxonomy, etc, overcomplicate the matter. It's a simple technical point in the protocol. First of all, this applies to the scenario where split-mac is being used, and the WTP is performing the packet encryption/decryption. Saravanan's point: In order to perform the 4-way handshake, the AC needs to know the KeyRSC. In the aforementioned scenario, the KeyRSC resides at the WTP. This has nothing to do with optional features; as-is the protocol just plain won't work. It seems to me that the WG has a couple options: 1. Decide that Saravanan's point is technically incorrect, and not inline with 802.11i. 2. Decide that we don't want to support split-mac with the WTP doing the packet crypto. 3. Fix the protocol by having some message to sync the KeyRSC values. Without rereading 802.11i, I think Saravanan has a point, and we should fix the protocol. Of course, Cisco has working code that somehow operates in this scenario. Perhaps Pat and Bob could fill us in on how the KeyRSC is handled in existing systems? Perhaps different KeyRSC values are used, and the client supplicants just don't notice? Unfortunately for the next few weeks my Internet connection is through an extremely slow WiFi network (motivation to finish CAPWAP) that would probably implode upon itself if I tried to download the 11i spec (oh the irony). Without that as a reference, I can't speak with very much authority. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy _________________________________________________________________ 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 Sep 23 14:18:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRC5S-00051q-EH for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 14:18:50 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRC5R-0007FI-1V for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 14:18:50 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1CEBA398049 for ; Sat, 23 Sep 2006 11:18:48 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id BC81543005A for ; Sat, 23 Sep 2006 11:18:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A39DC1448026 for ; Sat, 23 Sep 2006 11:18:19 -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 BE5841448010 for ; Sat, 23 Sep 2006 11:18:18 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so1507976pyu for ; Sat, 23 Sep 2006 11:18:17 -0700 (PDT) Received: by 10.35.106.15 with SMTP id i15mr4199797pym; Sat, 23 Sep 2006 11:18:17 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Sat, 23 Sep 2006 11:18:16 -0700 (PDT) Message-ID: <26140d940609231118m3f5b351cv78499aec7335df6@mail.gmail.com> Date: Sat, 23 Sep 2006 14:18:17 -0400 From: "Michael Montemurro" To: capwap 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.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Proposed resolution to Issue 221 - Fix figure 5: remove "(clear text)" X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1343332443==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb --===============1343332443== Content-Type: multipart/alternative; boundary="----=_Part_7186_21964481.1159035497303" ------=_Part_7186_21964481.1159035497303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Both figure 5 and figure 7 will to be updated to be consistent with the add mobile message element definition. Cheers, Mike ------=_Part_7186_21964481.1159035497303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Both figure 5 and figure 7 will to be updated to be consistent with the add mobile message element definition.
 
Cheers,
 
Mike
------=_Part_7186_21964481.1159035497303-- --===============1343332443== 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 --===============1343332443==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Sep 23 14:29:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRCFT-0008Sj-Pp for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 14:29:11 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRCFS-0007t3-BV for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 14:29:11 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 01D63398045 for ; Sat, 23 Sep 2006 11:29:10 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id CFD5943005A for ; Sat, 23 Sep 2006 11:28:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B83C039802F for ; Sat, 23 Sep 2006 11:28:39 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by zoidberg.tigertech.net (Postfix) with ESMTP id DD14739802D for ; Sat, 23 Sep 2006 11:28:38 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so1510520pyu for ; Sat, 23 Sep 2006 11:28:38 -0700 (PDT) Received: by 10.35.27.1 with SMTP id e1mr4213243pyj; Sat, 23 Sep 2006 11:28:38 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Sat, 23 Sep 2006 11:28:37 -0700 (PDT) Message-ID: <26140d940609231128y4a373754k1e83f29602af5761@mail.gmail.com> Date: Sat, 23 Sep 2006 14:28:37 -0400 From: "Michael Montemurro" To: capwap MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.901 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Proposed treatment of Issue 200. Firmware download while operational X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1112616662==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 --===============1112616662== Content-Type: multipart/alternative; boundary="----=_Part_7318_24618917.1159036117927" ------=_Part_7318_24618917.1159036117927 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I believe that the this issue is something that should be considered as a feature, not a bug, for the following reasons: 1) Both the firmware download and boot process do not take much time so a service outage would be minimal (for non-voice clients). 2) Typically there is overlapping coverage in a WLAN network. The firmward download is typicallly staggered such that other WTP's could provide service while a WTP is being upgraded. I recommend that this issue be treated as a feature request and be addressed in a future version of the CAPWAP protocol. Cheers, Mike ------=_Part_7318_24618917.1159036117927 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I believe that the this issue is something that should be considered as a feature, not a bug,  for the following reasons:
1) Both the firmware download and boot process do not take much time so a service outage would be minimal (for non-voice clients).
2) Typically there is overlapping coverage in a WLAN network. The firmward download is typicallly staggered such that
other WTP's could provide service while a WTP is being upgraded.
 
I recommend that this issue be treated as a  feature request and be addressed in a future version of the CAPWAP protocol.
 
Cheers,
 
Mike
 
 
------=_Part_7318_24618917.1159036117927-- --===============1112616662== 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 --===============1112616662==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Sep 23 14:31:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRCHW-0000Vm-Df for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 14:31:18 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRCHV-00086Q-12 for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 14:31:18 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id A6F04398087 for ; Sat, 23 Sep 2006 11:31:16 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 0BBB743005A for ; Sat, 23 Sep 2006 11:30:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C719E1448043 for ; Sat, 23 Sep 2006 11:30:47 -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 8310D1448042 for ; Sat, 23 Sep 2006 11:30:45 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c31so1738095pyd for ; Sat, 23 Sep 2006 11:30:44 -0700 (PDT) Received: by 10.35.50.1 with SMTP id c1mr4219810pyk; Sat, 23 Sep 2006 11:30:44 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Sat, 23 Sep 2006 11:30:44 -0700 (PDT) Message-ID: <26140d940609231130j729a4e02w6d0be95715e72122@mail.gmail.com> Date: Sat, 23 Sep 2006 14:30:44 -0400 From: "Michael Montemurro" To: capwap 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.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Proposed resolution to issue 194 - duplicate IPv4 address. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0472000165==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb --===============0472000165== Content-Type: multipart/alternative; boundary="----=_Part_7342_4689990.1159036244457" ------=_Part_7342_4689990.1159036244457 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I propose that we add a sentence to sections 4.4.19 and 4.4.20 to indicated that the message is transmitted only once. Cheers, Mike ------=_Part_7342_4689990.1159036244457 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I propose that we add a sentence to sections 4.4.19 and 4.4.20 to indicated that the message is transmitted only once.
 
Cheers,
 
Mike
------=_Part_7342_4689990.1159036244457-- --===============0472000165== 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 --===============0472000165==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Sep 23 14:36:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRCMW-0002Jo-CM for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 14:36:28 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRCMU-0008N1-W9 for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 14:36:28 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id A1B66398087 for ; Sat, 23 Sep 2006 11:36:26 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id ECE6A43005A for ; Sat, 23 Sep 2006 11:35:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CE7631448009 for ; Sat, 23 Sep 2006 11:35:56 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by hermes.tigertech.net (Postfix) with ESMTP id 50E571448026 for ; Sat, 23 Sep 2006 11:35:54 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so1512009pyu for ; Sat, 23 Sep 2006 11:35:53 -0700 (PDT) Received: by 10.35.106.15 with SMTP id i15mr4228414pym; Sat, 23 Sep 2006 11:35:53 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Sat, 23 Sep 2006 11:35:53 -0700 (PDT) Message-ID: <26140d940609231135h6f69edbdif63756e6f3aef71a@mail.gmail.com> Date: Sat, 23 Sep 2006 14:35:53 -0400 From: "Michael Montemurro" To: capwap 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.9 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Proposed resolution to issue 196 on the difficiency of the update mobile QoS message element X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0537446704==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 --===============0537446704== Content-Type: multipart/alternative; boundary="----=_Part_7402_16249514.1159036553181" ------=_Part_7402_16249514.1159036553181 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline This message element is used by the AC to update the WTP on how to prioritize traffic for an associated STA. I do not believe this message element is difficient and I proposed that we close this issue. Cheers, Mike ------=_Part_7402_16249514.1159036553181 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
This message element is used by the AC to update the WTP on how to prioritize traffic for an associated STA. I do not believe this message element is difficient and I proposed that we close this issue.
 
Cheers,
 
Mike
 
------=_Part_7402_16249514.1159036553181-- --===============0537446704== 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 --===============0537446704==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Sep 23 14:49:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRCYe-0007Fo-Af for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 14:49:00 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRCYc-0000bI-UM for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 14:49:00 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5E7B839807D for ; Sat, 23 Sep 2006 11:48:58 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D4FC343005A for ; Sat, 23 Sep 2006 11:48:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B68071448041 for ; Sat, 23 Sep 2006 11:48:28 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by hermes.tigertech.net (Postfix) with ESMTP id E339D1448039 for ; Sat, 23 Sep 2006 11:48:27 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c31so1742493pyd for ; Sat, 23 Sep 2006 11:48:27 -0700 (PDT) Received: by 10.35.91.10 with SMTP id t10mr4244876pyl; Sat, 23 Sep 2006 11:48:26 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Sat, 23 Sep 2006 11:48:26 -0700 (PDT) Message-ID: <26140d940609231148p6a7ee58ek6576c9217677ec27@mail.gmail.com> Date: Sat, 23 Sep 2006 14:48:26 -0400 From: "Michael Montemurro" To: capwap 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.9 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Proposed resolution to issue 192 - Problems with Image data request and response X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1944118482==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 --===============1944118482== Content-Type: multipart/alternative; boundary="----=_Part_7526_28352334.1159037306763" ------=_Part_7526_28352334.1159037306763 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I don't see any issues with the image data request/response as it is described. I proposed that we close this issue with no updates to the specification. Cheers, Mike ------=_Part_7526_28352334.1159037306763 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I don't see any issues with the image data request/response as it is described. I proposed that we close this issue with no updates to the specification.
 
Cheers,
 
Mike
------=_Part_7526_28352334.1159037306763-- --===============1944118482== 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 --===============1944118482==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Sep 23 14:55:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRCf8-0000yS-MU for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 14:55:42 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRCf7-0000yY-7f for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 14:55:42 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id DA90F398077 for ; Sat, 23 Sep 2006 11:55:40 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B616943005A for ; Sat, 23 Sep 2006 11:55:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 96E651448009 for ; Sat, 23 Sep 2006 11:55:11 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by hermes.tigertech.net (Postfix) with ESMTP id AE2171448001 for ; Sat, 23 Sep 2006 11:55:09 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so1516122pyu for ; Sat, 23 Sep 2006 11:55:08 -0700 (PDT) Received: by 10.35.102.1 with SMTP id e1mr4257451pym; Sat, 23 Sep 2006 11:55:08 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Sat, 23 Sep 2006 11:55:08 -0700 (PDT) Message-ID: <26140d940609231155w1b253de2w9f72c5b6f199e40d@mail.gmail.com> Date: Sat, 23 Sep 2006 14:55:08 -0400 From: "Michael Montemurro" To: capwap 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.7 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_10_20, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Proposed resolution to issues 72, 73, 108, 181, and 190. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============2144969290==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 --===============2144969290== Content-Type: multipart/alternative; boundary="----=_Part_7594_5482954.1159037708022" ------=_Part_7594_5482954.1159037708022 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline These issues all have to do with the configuration process and error handing of that process. I propose to resolve these comments by doing the following: 1) Add a add a Configuration Status Acknowledgement Frame. The WTP would send this frame back with a status code to indicate success or failure of its ability to apply the configuration. 2) The configuration update response could be modified to include any message elements that could not be applied by the WTP. 3) In the case of a configuration message that exceeds the MTU between the WTP and the AC, the CAPWAP fragmentation mechanism would be allow the message to be fragmented by the AC and reassembled by the WTP. I don't think there needs to be any updates to CAPWAP to address this issue. Cheers, Mike ------=_Part_7594_5482954.1159037708022 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
These issues all have to do with the configuration process and error handing of that process.
 
I propose to resolve these comments by doing the following:
1) Add a add a Configuration Status Acknowledgement Frame. The WTP would send this frame back with a status code to indicate success or failure of its ability to apply the configuration.
 
2) The configuration update response could be modified to include any message elements that could not be applied by the WTP.
 
3) In the case of a configuration message that exceeds the MTU between the WTP and the AC, the CAPWAP fragmentation mechanism would be allow the message to be fragmented by the AC and reassembled by the WTP. I don't think there needs to be any updates to CAPWAP to address this issue.
 
Cheers,
 
Mike
------=_Part_7594_5482954.1159037708022-- --===============2144969290== 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 --===============2144969290==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Sep 23 14:59:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRCiU-0002ZY-T3 for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 14:59:10 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRCiT-000169-Fy for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 14:59:10 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id D993B398079 for ; Sat, 23 Sep 2006 11:59:08 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 002FD43005A for ; Sat, 23 Sep 2006 11:58:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E301D1448026 for ; Sat, 23 Sep 2006 11:58:36 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by hermes.tigertech.net (Postfix) with ESMTP id 026311448009 for ; Sat, 23 Sep 2006 11:58:34 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so1516914pyu for ; Sat, 23 Sep 2006 11:58:34 -0700 (PDT) Received: by 10.35.76.10 with SMTP id d10mr4259142pyl; Sat, 23 Sep 2006 11:58:34 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Sat, 23 Sep 2006 11:58:34 -0700 (PDT) Message-ID: <26140d940609231158l6b15a518x65889cb02b935ae4@mail.gmail.com> Date: Sat, 23 Sep 2006 14:58:34 -0400 From: "Michael Montemurro" To: capwap 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.9 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Proposed resolution to issue 137 - Proposal for a revised packet header X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0333487747==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 --===============0333487747== Content-Type: multipart/alternative; boundary="----=_Part_7654_25563923.1159037914146" ------=_Part_7654_25563923.1159037914146 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I don't see why a MUX header is required even if the decision to go with separate control and data ports. I don't see how this header definition is better than what is currently in draft -02. If there are specific edits to the header that are required, I would like to know what they are; otherwise I propose closing this issue. Cheers, Mike ------=_Part_7654_25563923.1159037914146 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I don't see why a MUX header is required even if the decision to go with separate control and data ports. I don't see how this header definition is better than what is currently in draft -02.
 
If there are specific edits to the header that are required, I would like to know what they are; otherwise I propose closing this issue.
 
Cheers,
 
Mike
------=_Part_7654_25563923.1159037914146-- --===============0333487747== 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 --===============0333487747==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Sep 23 15:01:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRCkd-00030i-O8 for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 15:01:23 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRCkc-0001BZ-BT for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 15:01:23 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id F056339802F for ; Sat, 23 Sep 2006 12:01:21 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B3FFC43005A for ; Sat, 23 Sep 2006 12:00:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A6B2339802F for ; Sat, 23 Sep 2006 12:00:48 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by zoidberg.tigertech.net (Postfix) with ESMTP id C8AB539802D for ; Sat, 23 Sep 2006 12:00:46 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so1517360pyu for ; Sat, 23 Sep 2006 12:00:46 -0700 (PDT) Received: by 10.35.40.10 with SMTP id s10mr4261220pyj; Sat, 23 Sep 2006 12:00:46 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Sat, 23 Sep 2006 12:00:45 -0700 (PDT) Message-ID: <26140d940609231200y6baae9c7mc78733e986cca557@mail.gmail.com> Date: Sat, 23 Sep 2006 15:00:46 -0400 From: "Michael Montemurro" To: capwap MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.453 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Proposed resolution to Issue 140 - use of VLAN name X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0411339867==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb --===============0411339867== Content-Type: multipart/alternative; boundary="----=_Part_7690_12337296.1159038046000" ------=_Part_7690_12337296.1159038046000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline In section 4.4.8, I propose that we change VLAN name to VLAN Identifier ( as described in IEEE 802.1D). Cheers, Mike ------=_Part_7690_12337296.1159038046000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
In section 4.4.8, I propose that we change VLAN name to VLAN Identifier ( as described in IEEE 802.1D).
 
Cheers,
 
Mike
------=_Part_7690_12337296.1159038046000-- --===============0411339867== 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 --===============0411339867==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Sep 23 15:03:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRCmm-0003Sd-4q for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 15:03:36 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRCmk-0001FQ-OW for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 15:03:36 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6A090398077 for ; Sat, 23 Sep 2006 12:03:34 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 700E743005A for ; Sat, 23 Sep 2006 12:02:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5C2E91448041 for ; Sat, 23 Sep 2006 12:02:55 -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 534031448009 for ; Sat, 23 Sep 2006 12:02:53 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so1517791pyu for ; Sat, 23 Sep 2006 12:02:52 -0700 (PDT) Received: by 10.35.113.12 with SMTP id q12mr3720935pym; Sat, 23 Sep 2006 12:02:52 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Sat, 23 Sep 2006 12:02:52 -0700 (PDT) Message-ID: <26140d940609231202i34c08bd5j1d7558a70f097bd@mail.gmail.com> Date: Sat, 23 Sep 2006 15:02:52 -0400 From: "Michael Montemurro" To: capwap 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.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Proposed resolution to issue 127 - usage of the session ID field X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1703236593==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb --===============1703236593== Content-Type: multipart/alternative; boundary="----=_Part_7722_26798582.1159038172556" ------=_Part_7722_26798582.1159038172556 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I propose we adopt David's proposed resolution and add session ID back into the header as described in tracker. Cheers, Mike ------=_Part_7722_26798582.1159038172556 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I propose we adopt David's proposed resolution and add session ID back into the header as described in tracker.
 
Cheers,
 
Mike
------=_Part_7722_26798582.1159038172556-- --===============1703236593== 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 --===============1703236593==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Sep 23 15:05:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRCox-0004VY-Tr for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 15:05:51 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRCov-0001SB-Fo for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 15:05:51 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 167E3398076 for ; Sat, 23 Sep 2006 12:05:49 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1534743005A for ; Sat, 23 Sep 2006 12:05:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 026B91448009 for ; Sat, 23 Sep 2006 12:05:10 -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 3277A1448039 for ; Sat, 23 Sep 2006 12:05:05 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so1518350pyu for ; Sat, 23 Sep 2006 12:05:05 -0700 (PDT) Received: by 10.35.88.17 with SMTP id q17mr4269762pyl; Sat, 23 Sep 2006 12:05:05 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Sat, 23 Sep 2006 12:05:05 -0700 (PDT) Message-ID: <26140d940609231205j7f49f2f4r331b8fd122337a14@mail.gmail.com> Date: Sat, 23 Sep 2006 15:05:05 -0400 From: "Michael Montemurro" To: capwap 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.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Proposed resolution to Issue 144 - Need length value for vendor-specific payload X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1938985236==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb --===============1938985236== Content-Type: multipart/alternative; boundary="----=_Part_7758_31876993.1159038305145" ------=_Part_7758_31876993.1159038305145 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I propose to resolve this issue by accepting the recommendation to add a length field to the vendor-specific element. Cheers, Mike ------=_Part_7758_31876993.1159038305145 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I propose to resolve this issue by accepting the recommendation to add a length field to the vendor-specific element.
 
Cheers,
 
Mike
------=_Part_7758_31876993.1159038305145-- --===============1938985236== 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 --===============1938985236==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Sep 23 15:07:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRCqc-0005Py-Em for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 15:07:34 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRCqb-0001ZM-25 for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 15:07:34 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 98C22398048 for ; Sat, 23 Sep 2006 12:07:32 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id DE54B43005A for ; Sat, 23 Sep 2006 12:06:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C3903398048 for ; Sat, 23 Sep 2006 12:06:44 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by zoidberg.tigertech.net (Postfix) with ESMTP id D44DB398049 for ; Sat, 23 Sep 2006 12:06:42 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so1518698pyu for ; Sat, 23 Sep 2006 12:06:42 -0700 (PDT) Received: by 10.35.27.1 with SMTP id e1mr4274098pyj; Sat, 23 Sep 2006 12:06:41 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Sat, 23 Sep 2006 12:06:41 -0700 (PDT) Message-ID: <26140d940609231206o2b9c06cm526e831112f13c79@mail.gmail.com> Date: Sat, 23 Sep 2006 15:06:41 -0400 From: "Michael Montemurro" To: capwap MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.901 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Proposed resolution to Issue 188 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1716196215==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 --===============1716196215== Content-Type: multipart/alternative; boundary="----=_Part_7786_14620055.1159038401824" ------=_Part_7786_14620055.1159038401824 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I do not see a problem with the Add MAC ACL Entry issue as defined. Unless there is proposed text to this issue, I recommend that we close it with no changes to the draft. Cheers, Mike ------=_Part_7786_14620055.1159038401824 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I do not see a problem with the Add MAC ACL Entry issue as defined. Unless there is proposed text to this issue, I recommend that we close it with no changes to the draft.
 
Cheers,
 
Mike
------=_Part_7786_14620055.1159038401824-- --===============1716196215== 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 --===============1716196215==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Sep 23 15:09:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRCsJ-0005qI-4x for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 15:09:19 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRCsH-0001jd-Nj for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 15:09:19 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5882339808E for ; Sat, 23 Sep 2006 12:09:17 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3807743005A for ; Sat, 23 Sep 2006 12:08:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1E9AE398059 for ; Sat, 23 Sep 2006 12:08:34 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by zoidberg.tigertech.net (Postfix) with ESMTP id C17DA398048 for ; Sat, 23 Sep 2006 12:08:32 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so1519139pyu for ; Sat, 23 Sep 2006 12:08:32 -0700 (PDT) Received: by 10.35.84.12 with SMTP id m12mr4278134pyl; Sat, 23 Sep 2006 12:08:32 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Sat, 23 Sep 2006 12:08:31 -0700 (PDT) Message-ID: <26140d940609231208u1806d24fnb59c8fc9b1221a72@mail.gmail.com> Date: Sat, 23 Sep 2006 15:08:32 -0400 From: "Michael Montemurro" To: capwap MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.901 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Proposed resolution to issue 173 - message element exceed frame length. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0841582730==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 --===============0841582730== Content-Type: multipart/alternative; boundary="----=_Part_7806_17995878.1159038512032" ------=_Part_7806_17995878.1159038512032 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I do not see why the CAPWAP transport fragmentation mechanism can't be used to address this issue. I propose that we close it with no updates to the draft, unless someone is willing to describe what changes need to be made. Cheers, Mike ------=_Part_7806_17995878.1159038512032 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I do not see why the CAPWAP transport fragmentation mechanism can't be used to address this issue. I propose that we close it with no updates to the draft, unless someone is willing to describe what changes need to be made.
 
Cheers,
 
Mike
------=_Part_7806_17995878.1159038512032-- --===============0841582730== 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 --===============0841582730==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Sep 23 15:19:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRD1z-0000yc-HP for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 15:19:19 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRD1x-0002U7-TD for capwap-archive@lists.ietf.org; Sat, 23 Sep 2006 15:19:19 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id C91AD39808B for ; Sat, 23 Sep 2006 12:19:08 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 90D6043005A for ; Sat, 23 Sep 2006 12:18:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 56FD21448040 for ; Sat, 23 Sep 2006 12:18:09 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by hermes.tigertech.net (Postfix) with ESMTP id D93E61448026 for ; Sat, 23 Sep 2006 12:18:06 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so1521207pyu for ; Sat, 23 Sep 2006 12:18:06 -0700 (PDT) Received: by 10.35.17.12 with SMTP id u12mr3739099pyi; Sat, 23 Sep 2006 12:18:05 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Sat, 23 Sep 2006 12:18:05 -0700 (PDT) Message-ID: <26140d940609231218x42d23db8jcf92cbce2c66ce70@mail.gmail.com> Date: Sat, 23 Sep 2006 15:18:05 -0400 From: "Michael Montemurro" To: "zhaoyujin 31390" In-Reply-To: <24efdee24ea3d3.24ea3d324efdee@huawei.com> MIME-Version: 1.0 References: <24efdee24ea3d3.24ea3d324efdee@huawei.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.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 - Prioritization of IEEE 802.1X frames X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0267376280==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 --===============0267376280== Content-Type: multipart/alternative; boundary="----=_Part_7862_25488359.1159039085639" ------=_Part_7862_25488359.1159039085639 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Michael, Thanks. Is anybody else opinionated on this feature. Cheers, Mike On 9/23/06, zhaoyujin 31390 wrote: > > Firstly, I have some doubt one this suggestion. > > 1. If CAPWAP difines like this, AP device must decode the payload frames > of 802.11 frames. > 2. Another problem, the 802.1x priority should be implement by 802.11e. > When station sends 802.11 data frames, it can set 802.11e priority. AP > should transfer 802.11e to actual CAPWAP packet priority. > > So that I think CAPWAP does not need consider the priority of 802.11 data > frames payload. > > Thanks > Michael > > > > >Practically speaking, IEEE 802.1X frames should be transmitted at the > same priority as >IEEE 802.11 Management frames. > > > >I will update Section 11.5, rename Quality of Service for IEEE 802.11Control Messages >to "Quality > >of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" > and add text to >indicate that IEEE 802.1X frames are sent at a higher > priority. > > > >Cheers, > > > >Mike > > > This e-mail and attachments contain confidential information from HUAWEI, > which is intended only for the person or entity whose address is listed > above. Any use of the information contained herein in any way (including, > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please notify the sender by > phone or email > immediately and delete it! > > > > Practically speaking, IEEE 802.1X frames should be transmitted at the same > priority as IEEE 802.11 Management frames. > > I will update Section 11.5, rename Quality of Service for IEEE 802.11Control Messages to "Quality > of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" > and add text to indicate that IEEE 802.1X frames are sent at a higher > priority. > > 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 > > > ------=_Part_7862_25488359.1159039085639 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Michael,
 
Thanks. Is anybody else opinionated on this feature.
 
Cheers,
 
Mike

 
On 9/23/06, zhaoyujin 31390 <zhaoyujin@huawei.com> wrote:
Firstly, I have some doubt one this suggestion.

1. If CAPWAP difines like this, AP device must decode the payload frames of 802.11 frames.
2. Another problem, the 802.1x priority should be implement by 802.11e. When station sends 802.11 data frames, it can set 802.11e priority. AP should transfer 802.11e to actual CAPWAP packet priority.

So that I think CAPWAP does not need consider the priority of 802.11 data frames payload.

Thanks
Michael



>Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as >IEEE 802.11 Management frames.
>
>I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages >to "Quality
>of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to >indicate that IEEE 802.1X frames are sent at a higher priority.
>
>Cheers,
>
>Mike


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

 

Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as IEEE 802.11 Management frames.
 
I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages to "Quality
of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to indicate that IEEE 802.1X frames are sent at a higher priority.
 
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



------=_Part_7862_25488359.1159039085639-- --===============0267376280== 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 --===============0267376280==-- From philistunnel@firstworld.net Sat Sep 23 22:46:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRK0n-0002Yn-Ru for capwap-archive@ietf.org; Sat, 23 Sep 2006 22:46:33 -0400 Received: from [61.79.84.150] (helo=firstworld.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GRK0m-0007ZJ-8d for capwap-archive@ietf.org; Sat, 23 Sep 2006 22:46:33 -0400 Message-ID: <01c6df83$9cc93660$96544f3d@ga965> Date: Sun, 24 Sep 2006 11:46:19 +0900 X-MSMail-Priority: Normal X-Priority: 3 Reply-To: "Izidor Rybak" From: "Izidor Rybak" To: Subject: PHAhfeRMA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_22CB_01C6DFCF.0CB0DE60" X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.7 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 This is a multi-part message in MIME format. ------=_NextPart_000_22CB_01C6DFCF.0CB0DE60 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi VALfUM $1 , 35 CfALIS $3 , 75 AMBfEN VfAGRA $3 , 45 =20 http://www.vertionmdefunshjin.com ------=_NextPart_000_22CB_01C6DFCF.0CB0DE60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi

VALfUM $1 , 35

CfALIS $3 , 75

AMBfEN

VfAGRA $3 , 45

 
------=_NextPart_000_22CB_01C6DFCF.0CB0DE60-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Sep 24 17:20:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRbP6-0002gk-Tu for capwap-archive@lists.ietf.org; Sun, 24 Sep 2006 17:20:48 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRbP4-0001iR-6x for capwap-archive@lists.ietf.org; Sun, 24 Sep 2006 17:20:48 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 84C6D430157 for ; Sun, 24 Sep 2006 14:20:31 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 0B82043005F for ; Sun, 24 Sep 2006 14:18:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DD66D144800C for ; Sun, 24 Sep 2006 14:18:46 -0700 (PDT) Received: from web60318.mail.yahoo.com (web60318.mail.yahoo.com [209.73.178.126]) by hermes.tigertech.net (Postfix) with SMTP id 88DDA1448002 for ; Sun, 24 Sep 2006 14:18:44 -0700 (PDT) Received: (qmail 29115 invoked by uid 60001); 24 Sep 2006 21:18:43 -0000 Message-ID: <20060924211843.29111.qmail@web60318.mail.yahoo.com> Received: from [67.166.240.5] by web60318.mail.yahoo.com via HTTP; Sun, 24 Sep 2006 14:18:43 PDT Date: Sun, 24 Sep 2006 14:18:43 -0700 (PDT) From: Behcet Sarikaya To: "T. Charles Clancy" 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=2.7 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, HTML_20_30, HTML_MESSAGE X-Spam-Level: ** Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0269726431==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e --===============0269726431== Content-Type: multipart/alternative; boundary="0-1391733967-1159132723=:27272" --0-1391733967-1159132723=:27272 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable I would vote for Option 3:=0A802.11i requires Key RSC value to be set to st= arting sequence number that the Authenticator=A2s STA will use in MPDUs pro= tected by GTK.=0AThe fix would be to add Key RSC field (8 octets)=0Ain IEEE= 802.11 Mobile Session Key message element =0Aand add some behaviour like A= C sends the value (key RSC) it used during 4-way=0Ahandshake together with = the key.=0A--behcet=0A=0A=0A----- Original Message ----=0AFrom: T. Charles = Clancy =0ATo: T Sridhar =0ACc= : Margaret Wasserman ; capwap@frascone.com=0ASent:= Saturday, September 23, 2006 12:15:30 PM=0ASubject: Re: [Capwap] Issue 43 = - Explanation for 802.11i Considerations=0A=0AI think all the discussions a= bout the requirements and taxonomy, etc, =0Aovercomplicate the matter. It'= s a simple technical point in the protocol.=0A=0AFirst of all, this applies= to the scenario where split-mac is being used, =0Aand the WTP is performin= g the packet encryption/decryption.=0A=0ASaravanan's point: In order to pe= rform the 4-way handshake, the AC needs =0Ato know the KeyRSC. In the afor= ementioned scenario, the KeyRSC resides at =0Athe WTP. This has nothing to= do with optional features; as-is the =0Aprotocol just plain won't work.=0A= =0AIt seems to me that the WG has a couple options:=0A=0A1. Decide that Sar= avanan's point is technically incorrect, and not inline=0A with 802.11i.= =0A2. Decide that we don't want to support split-mac with the WTP doing the= =0A packet crypto.=0A3. Fix the protocol by having some message to sync = the KeyRSC values.=0A=0AWithout rereading 802.11i, I think Saravanan has a = point, and we should =0Afix the protocol. Of course, Cisco has working cod= e that somehow operates =0Ain this scenario. Perhaps Pat and Bob could fil= l us in on how the KeyRSC =0Ais handled in existing systems? Perhaps diffe= rent KeyRSC values are used, =0Aand the client supplicants just don't notic= e?=0A=0AUnfortunately for the next few weeks my Internet connection is thro= ugh an =0Aextremely slow WiFi network (motivation to finish CAPWAP) that wo= uld =0Aprobably implode upon itself if I tried to download the 11i spec (oh= the =0Airony). Without that as a reference, I can't speak with very much = =0Aauthority.=0A=0A--=0At. charles clancy, ph.d. | tcc@umd.edu | www.cs= .umd.edu/~clancy=0A________________________________________________________= _________=0ATo unsubscribe or modify your subscription options, please visi= t:=0Ahttp://lists.frascone.com/mailman/listinfo/capwap=0A=0AArchives: http:= //lists.frascone.com/pipermail/capwap=0A=0A=0A=0A=0A --0-1391733967-1159132723=:27272 Content-Type: text/html; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable
I would vote for Option 3:
802.11i requires Key RS= C value to be set to starting sequence number that the Authenticator=A2s ST= A will use in MPDUs protected by GTK.
The fix would be to add Key RSC fi= eld (8 octets)
in IEEE 802.11 Mobile Session Key message element
and= add some behaviour like AC sends the value (key RSC) it used during 4-way
handshake together with t= he key.
--behcet


----- Original Message --= --
From: T. Charles Clancy <clancy@cs.umd.edu>
To: T Sridhar &l= t;T.Sridhar@flextronics.com>
Cc: Margaret Wasserman <margaret@thin= gmagic.com>; capwap@frascone.com
Sent: Saturday, September 23, 2006 12:15:30 PM
S= ubject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations
<= br>
I think all the discussions about the requirements and taxonomy, et= c,
overcomplicate the matter.  It's a simple technical point = in the protocol.

First of all, this applies to the scenario where sp= lit-mac is being used,
and the WTP is performing the packet encryption/= decryption.

Saravanan's point:  In order to perform the 4-= way handshake, the AC needs
to know the KeyRSC.  In the afore= mentioned scenario, the KeyRSC resides at
the WTP.  This has = nothing to do with optional features; as-is the
protocol just plain won= 't work.

It seems to me that the WG has a couple options:

1. = Decide that Saravanan's point is technically incorrect, and not inline
&= nbsp;   with 802.11i.
2. Decide that we don't want to sup= port split-mac with the WTP doing the
    packet crypto.=
3. Fix the protocol by having some message to sync the KeyRSC values.
Without rereading 802.11i, I think Saravanan has a point, and we shou= ld
fix the protocol.  Of course, Cisco has working code that = somehow operates
in this scenario.  Perhaps Pat and Bob could= fill us in on how the KeyRSC
is handled in existing systems? &nbs= p;Perhaps different KeyRSC values are used,
and the client supplicants = just don't notice?

Unfortunately for the next few weeks my Internet = connection is through an
extremely slow WiFi network (motivation to fin= ish CAPWAP) that would
probably implode upon itself if I tried to downl= oad the 11i spec (oh the
irony).  Without that as a reference= , I can't speak with very much
authority.

--
t. charles clanc= y, ph.d.  |  tcc@umd.edu  |  www.cs.umd.edu/~clancy
___= ______________________________________________________________
To unsubs= cribe or modify your subscription options, please visit:
http://lis= ts.frascone.com/mailman/listinfo/capwap

Archives: http://lists.fra= scone.com/pipermail/capwap

--0-1391733967-1159132723=:27272-- --===============0269726431== 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 --===============0269726431==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Sep 24 21:17:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRf5v-0005p4-Ca for capwap-archive@lists.ietf.org; Sun, 24 Sep 2006 21:17:15 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRf5s-0004Ns-PO for capwap-archive@lists.ietf.org; Sun, 24 Sep 2006 21:17:15 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 193131448067 for ; Sun, 24 Sep 2006 18:17:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B0A5E43005F for ; Sun, 24 Sep 2006 18:16:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 82D041448029 for ; Sun, 24 Sep 2006 18:16:17 -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 57298144800C for ; Sun, 24 Sep 2006 18:16:15 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-6.cisco.com with ESMTP; 24 Sep 2006 18:16:14 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8P1GEOc007420; Sun, 24 Sep 2006 18:16:14 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k8P1GDid026878; Sun, 24 Sep 2006 18:16: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.1830); Sun, 24 Sep 2006 18:16:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 24 Sep 2006 18:16:13 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202876981@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbdeTQ8CR0SLrwyRMaeKBeBcmDxVQAckCxAAItzzMA= From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , "Margaret Wasserman" X-OriginalArrivalTime: 25 Sep 2006 01:16:13.0455 (UTC) FILETIME=[313259F0:01C6E040] Authentication-Results: sj-dkim-7.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] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: b1c41982e167b872076d0018e4e1dc3c Saravanan, We've been down this path already, and I believe Bob O'Hara tried to set you in the right direction. Your assessment is incorrect and 802.11i works fine w/ the current spec. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Friday, September 22, 2006 2:03 AM > To: Margaret Wasserman > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Hi Margaret, > > Thank you for reviewing the discussion on this issue. > > The issue here is the working of IEEE 802.11i when the > 802.11i authenticator element is at the AC and the 802.11i > crypto element is at the WTP. Particularly, it is for the > 4-way handshake between authenticator and supplicant. > > Now, the 4-way handshake requires knowing the value of KeyRSC > sequence counter. The KeyRSC helps both authenticator and > supplicant keep track of their exchanges. It serves to > protect against threats by tracking sequential frames. The > KeyRSC is maintained at the at the point of encryption, i.e. > just before transmission over the wireless channel. > > In the case of CAPWAP, the 4-way handshake is between the AC > (authenticator) and the wireless station (supplicant). > > The problem arises, when the authenticator is at the AC and > the crypto element (together with KeyRSC) is at the WTP. This > is a fairly common design. Now in this case, the AC starts > the 4-way handshake but it does not know the value of the > KeyRSC. The KeyRSC is maintained by the WTP. > > Based on this, the current CAPWAP specification does not > allow for a way to conduct the 4-way handshake with the > correct KeyRSC. > > The functionality I would like to see is a way for the authenticator > (AC) to use the correct prevailing value of KeyRSC (maintained by the > WTP) in its 4-way handshake. > > One way to introduce this functionality in to CAPWAP is to > have part of the 4-way handshake be sent from AC to WTP. This > will allow the 4-way handshake to use the correct value of > the KeyRSC before being sent to the wireless station. > > I hope this helps clarify my view on the issue. > > Cheers, > > Saravanan > > > > > > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, September 21, 2006 8:26 PM > To: Saravanan Govindan > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > Hi again, > > Okay, I am even more confused than I thought I was... > > Saravanan, you wrote: > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > Pat, > > > > The issue here is about how 802.11i exchanges are done when > > authenticator is at the AC and crypto elements are at the > WTP. This is > > the requirement. > > And, in response, Pat Calhoun wrote: > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: > > The current specification allows the authenticator to > reside in the > > AC, > > while the data packet crypto elements in the WTP. This feature is > > already in the specification. > > Pat's message matches my reading of the specification. > > So, Saravanan, what functionality are you asking for that is not > already supported by the specification? And why do you think it is > necessary? it will not be helpful to my understanding to re-send > your proposal or to cite the requirements document... Please > summarize what functionality you think is missing from the current > specification and why you think that functionality is necessary to > support IEEE 802.11i or any important use case. > > At some point, the chairs may need to make a consensus call on this > issue, and I'd like to understand your view and make sure > that it has > been clearly communicated to the WG before we ask the WG to > decide on > this issue. > > 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 Sun Sep 24 21:17:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRf6W-0005pc-FT for capwap-archive@lists.ietf.org; Sun, 24 Sep 2006 21:17:52 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRf6U-0004Rq-S0 for capwap-archive@lists.ietf.org; Sun, 24 Sep 2006 21:17:52 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 610C91448019 for ; Sun, 24 Sep 2006 18:17:47 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D60A34300EF for ; Sun, 24 Sep 2006 18:16:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C59BA144800C for ; Sun, 24 Sep 2006 18:16:17 -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 73016144801F for ; Sun, 24 Sep 2006 18:16:15 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 24 Sep 2006 18:16:15 -0700 X-IronPort-AV: i="4.09,210,1157353200"; d="scan'208"; a="1855056565:sNHT41056220" 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 k8P1GEVa006441; Sun, 24 Sep 2006 18:16:14 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k8P1GDif026878; Sun, 24 Sep 2006 18:16: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.1830); Sun, 24 Sep 2006 18:16:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 24 Sep 2006 18:16:13 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202876982@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbelHtY03duHyNcQpOTYEY6mc+uAwAAB9YAAGE4/HA= From: "Pat Calhoun (pacalhou)" To: "T Sridhar" , "Margaret Wasserman" , X-OriginalArrivalTime: 25 Sep 2006 01:16:13.0642 (UTC) FILETIME=[314EE2A0:01C6E040] 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: Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 9c7d7a899dc8f3389bf7ace6f0ad8e29 It should be rejected because the CAPWAP protocol, as defined, is capable of supporting the 802.11i protocol as is. It is capable of providing crypto both at the WTP, as well as in the AC. Both Split and Local MAC are implemented. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: T Sridhar [mailto:T.Sridhar@flextronics.com] > Sent: Friday, September 22, 2006 3:18 PM > To: Margaret Wasserman; capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Hi, > > > > It would be good to get a summary of the reasons why this proposal > > should be accepted or rejected. Currently we have a number of email > > threads on this topic but a summary would be great. Saravanan/Pat - > > could you folks help? > > > > Thanks, > > Sridhar > > > > > > -----Original Message----- > > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > > Sent: Friday, September 22, 2006 3:12 PM > > To: capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > > > Hi All, > > > > I'm trying to get a read on whether this issue needs further > > discussion or not... > > > > Saravanan has made a proposal for change to the > specification, and he > > has offered an explanation for the motivation behind this proposal > > (see below). > > > > Pat Calhoun has argued that this level of flexibility is unnecessary > > and that the specification fully supports IEEE 802.11i and meets the > > requirements, as written. > > > > I've seen a few notes in support of Pat's position and I haven't > > noticed anyone else supporting Saravanan's proposal. If there are > > others who support Saravanan's proposal, please speak up. Unless we > > see strong support for this proposal, we'll have to conclude > that the > > WG does not have consensus to make this change. > > > > Margaret > > > > On Sep 22, 2006, at 5:03 AM, Saravanan Govindan wrote: > > > > > Hi Margaret, > > > > > > Thank you for reviewing the discussion on this issue. > > > > > > The issue here is the working of IEEE 802.11i when the 802.11i > > > authenticator element is at the AC and the 802.11i crypto element > > > is at > > > the WTP. Particularly, it is for the 4-way handshake between > > > authenticator and supplicant. > > > > > > Now, the 4-way handshake requires knowing the value of > KeyRSC sequence > > > counter. The KeyRSC helps both authenticator and supplicant > keep track > > > of their exchanges. It serves to protect against threats by tracking > > > sequential frames. The KeyRSC is maintained at the at the point of > > > encryption, i.e. just before transmission over the wireless channel. > > > > > > In the case of CAPWAP, the 4-way handshake is between the AC > > > (authenticator) and the wireless station (supplicant). > > > > > > The problem arises, when the authenticator is at the AC and > the crypto > > > element (together with KeyRSC) is at the WTP. This is a > fairly common > > > design. Now in this case, the AC starts the 4-way handshake but it > > > does > > > not know the value of the KeyRSC. The KeyRSC is maintained > by the WTP. > > > > > > Based on this, the current CAPWAP specification does not allow for > > > a way > > > to conduct the 4-way handshake with the correct KeyRSC. > > > > > > The functionality I would like to see is a way for the authenticator > > > (AC) to use the correct prevailing value of KeyRSC > (maintained by the > > > WTP) in its 4-way handshake. > > > > > > One way to introduce this functionality in to CAPWAP is to have > > > part of > > > the 4-way handshake be sent from AC to WTP. This will allow > the 4-way > > > handshake to use the correct value of the KeyRSC before > being sent to > > > the wireless station. > > > > > > I hope this helps clarify my view on the issue. > > > > > > Cheers, > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > > > Sent: Thursday, September 21, 2006 8:26 PM > > > To: Saravanan Govindan > > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > > > > > Hi again, > > > > > > Okay, I am even more confused than I thought I was... > > > > > > Saravanan, you wrote: > > > > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > > > >> Pat, > > >> > > >> The issue here is about how 802.11i exchanges are done when > > >> authenticator is at the AC and crypto elements are at the WTP. > > >> This is > > >> the requirement. > > > > > > And, in response, Pat Calhoun wrote: > > > > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: > > >> The current specification allows the authenticator to reside in the > > >> AC, > > >> while the data packet crypto elements in the WTP. This feature is > > >> already in the specification. > > > > > > Pat's message matches my reading of the specification. > > > > > > So, Saravanan, what functionality are you asking for that is not > > > already supported by the specification? And why do you think it is > > > necessary? it will not be helpful to my understanding to re-send > > > your proposal or to cite the requirements document... Please > > > summarize what functionality you think is missing from the current > > > specification and why you think that functionality is necessary to > > > support IEEE 802.11i or any important use case. > > > > > > At some point, the chairs may need to make a consensus call on this > > > issue, and I'd like to understand your view and make sure > that it has > > > been clearly communicated to the WG before we ask the WG to > decide on > > > this issue. > > > > > > 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 > > > > Legal Disclaimer: > > The information contained in this message may be privileged > and confidential. It is intended to be read only by the > individual or entity to whom it is addressed or by their > designee. If the reader of this message is not the intended > recipient, you are on notice that any distribution of this > message, in any form, is strictly prohibited. If you have > received this message in error, please immediately notify the > sender and delete or destroy any copy of this message > > _________________________________________________________________ > 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 Sun Sep 24 21:59:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRfkP-0008U8-Mj for capwap-archive@lists.ietf.org; Sun, 24 Sep 2006 21:59:05 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRfkN-0004HA-6h for capwap-archive@lists.ietf.org; Sun, 24 Sep 2006 21:59:05 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1C6FF398072 for ; Sun, 24 Sep 2006 18:59:02 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 8712243005F for ; Sun, 24 Sep 2006 18:58:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 66C00398051 for ; Sun, 24 Sep 2006 18:58:11 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4920B39803B for ; Sun, 24 Sep 2006 18:58:07 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k8P1vtCd005197; Mon, 25 Sep 2006 10:57:55 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k8P1vtj02320; Mon, 25 Sep 2006 10:57:55 +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 k8P1vt104132; Mon, 25 Sep 2006 10:57:55 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Sep 2006 09:56:58 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F1836@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbfM9biO0PLfqmIRNCdzVK1skoMWgBDu6UA From: "Cheng Hong" To: "T. Charles Clancy" , "T Sridhar" , "Pat Calhoun (pacalhou)" , "Saravanan Govindan" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Cc: Margaret Wasserman , capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: b5d20af10c334b36874c0264b10f59f1 Dear all, I think Charles provided a very good summary of the issue below. The issue should be clarified in two steps: First of all, (without debating on whether the scenario is optional or not), could Pat or Bob provide a technical explanation on how the scenario pointed out by Saravanan is supported by the current CAPWAP specification? (since Pat and Bob have been claiming that "So we already support both modes of operation already.") I don't think something like "our products do not do it that way" is adequate for that. The WG should build a consensus on this point first, i.e. if this is TECHNICALLY a non-issue. This is option 1 in Charles's email. After that, in case the CAPWAP specification as for now cannot support the scenario, the WG could look into how to fix the problem: either to dismiss the scenario (option 2 in Charles's email), or to add some mechanism to cope with the scenario (option 3 in Charles's). For both of the options, I see a need to modify the current specification, i.e. for option 2, a statement should be included to specifically dismiss the scenario. Personally, I would think option 3 is the choice, since the scenario does pose a problem for the current specification. Of course, I would leave the technical analysis to our experts in 802.11. cheers Cheng Hong > -----Original Message----- > From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Sunday, September 24, 2006 1:16 AM > To: T Sridhar > Cc: Margaret Wasserman; capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > I think all the discussions about the requirements and > taxonomy, etc, overcomplicate the matter. It's a simple > technical point in the protocol. > > First of all, this applies to the scenario where split-mac is > being used, and the WTP is performing the packet > encryption/decryption. > > Saravanan's point: In order to perform the 4-way handshake, > the AC needs to know the KeyRSC. In the aforementioned > scenario, the KeyRSC resides at the WTP. This has nothing to > do with optional features; as-is the protocol just plain won't work. > > It seems to me that the WG has a couple options: > > 1. Decide that Saravanan's point is technically incorrect, > and not inline > with 802.11i. > 2. Decide that we don't want to support split-mac with the > WTP doing the > packet crypto. > 3. Fix the protocol by having some message to sync the KeyRSC values. > > Without rereading 802.11i, I think Saravanan has a point, and > we should fix the protocol. Of course, Cisco has working > code that somehow operates in this scenario. Perhaps Pat and > Bob could fill us in on how the KeyRSC is handled in existing > systems? Perhaps different KeyRSC values are used, and the > client supplicants just don't notice? > > Unfortunately for the next few weeks my Internet connection > is through an extremely slow WiFi network (motivation to > finish CAPWAP) that would probably implode upon itself if I > tried to download the 11i spec (oh the irony). Without that > as a reference, I can't speak with very much authority. > > -- > t. charles clancy, ph.d. | tcc@umd.edu | > www.cs.umd.edu/~clancy > _________________________________________________________________ > 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 Sun Sep 24 23:20:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRh18-0004WE-8w for capwap-archive@lists.ietf.org; Sun, 24 Sep 2006 23:20:26 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRh16-0004zM-FH for capwap-archive@lists.ietf.org; Sun, 24 Sep 2006 23:20:26 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6E36839807B for ; Sun, 24 Sep 2006 20:20:15 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6EE1843005F for ; Sun, 24 Sep 2006 20:19:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5698139802A for ; Sun, 24 Sep 2006 20:19:18 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1AC5D398026 for ; Sun, 24 Sep 2006 20:19:16 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k8P3JGXQ009960; Mon, 25 Sep 2006 12:19:16 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k8P3JEp07417; Mon, 25 Sep 2006 12:19:14 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/phillies) with ESMTP id k8P3JEI01922; Mon, 25 Sep 2006 12:19:15 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Sep 2006 11:18:22 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F1879@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames Thread-Index: AcbfRQGzST9WS4EqQQS6QR5FrHix2ABC3ZMA From: "Cheng Hong" To: "Michael Montemurro" , "zhaoyujin 31390" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.511 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_40_50, HTML_MESSAGE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1998911442==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 This is a multi-part message in MIME format. --===============1998911442== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E051.413C17BE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E051.413C17BE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Michael & Michael, =20 Sorry if the issue has already been discussed before. Just thinking if the WTP does not differentiate 802.1X frames from normal data frames, would it be possible that the 802.1X frames being forwarded to a different AC instance than the one processing the control/management frames? (in case different ACs are used to process the control and data channel) Is this acceptable? =20 cheers =20 Cheng Hong =20 =20 =20 _____ =20 From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Sunday, September 24, 2006 3:18 AM To: zhaoyujin 31390 Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames Michael, =20 Thanks. Is anybody else opinionated on this feature.=20 =20 Cheers, =20 Mike =20 On 9/23/06, zhaoyujin 31390 wrote:=20 Firstly, I have some doubt one this suggestion. 1. If CAPWAP difines like this, AP device must decode the payload frames of 802.11 frames. 2. Another problem, the 802.1x priority should be implement by 802.11e. When station sends 802.11 data frames, it can set 802.11e priority. AP should transfer 802.11e to actual CAPWAP packet priority. So that I think CAPWAP does not need consider the priority of 802.11 data frames payload.=20 Thanks Michael >Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as >IEEE 802.11 Management frames. > >I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages >to "Quality >of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to >indicate that IEEE 802.1X frames are sent at a higher priority. >=20 >Cheers, > >Mike This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email=20 immediately and delete it! =20 Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as IEEE 802.11 Management frames.=20 =20 I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages to "Quality of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to indicate that IEEE 802.1X frames are sent at a higher priority. =20 Cheers, =20 Mike _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap =20 ------_=_NextPart_001_01C6E051.413C17BE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Michael & Michael,
 
Sorry=20 if the issue has already been discussed before. Just thinking if the WTP = does=20 not differentiate 802.1X frames from normal data frames, would it be = possible=20 that the 802.1X frames being forwarded to a different AC instance than = the one=20 processing the control/management frames? (in case different ACs are = used to=20 process the control and data channel) Is this = acceptable?
 
cheers
 
Cheng=20 Hong
 
 
 

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Sunday, = September 24,=20 2006 3:18 AM
To: zhaoyujin 31390
Cc:=20 capwap
Subject: Re: [Capwap] This is not need.: Proposed = resolution=20 to Issue 214 -Prioritization of IEEE 802.1X = frames

Michael,
 
Thanks. Is anybody else opinionated on this feature.
 
Cheers,
 
Mike

 
On 9/23/06, zhaoyujin=20 31390 <zhaoyujin@huawei.com> = wrote:=20
Firstly, I have some doubt one this=20 suggestion.

1. If CAPWAP difines like this, AP device must = decode the=20 payload frames of 802.11 frames.
2. Another problem, the 802.1x = priority=20 should be implement by 802.11e. When station sends 802.11 data = frames, it=20 can set 802.11e priority. AP should transfer 802.11e to actual = CAPWAP packet=20 priority.

So that I think CAPWAP does not need consider the = priority=20 of 802.11 data frames payload.=20

Thanks
Michael



>Practically speaking, = IEEE=20 802.1X frames should be transmitted at the same priority as >IEEE = 802.11=20 Management frames.
>
>I will update Section 11.5, rename = Quality=20 of Service for IEEE 802.11 Control Messages >to = "Quality
>of=20 Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL = frames" and=20 add text to >indicate that IEEE 802.1X frames are sent at a = higher=20 priority.
> =
>Cheers,
>
>Mike


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

 

Practically speaking, IEEE 802.1X frames should be transmitted = at the=20 same priority as IEEE 802.11 Management frames.
 
I will update Section 11.5, rename Quality of Service for IEEE = 802.11=20 Control Messages to "Quality
of Service for IEEE 802.11 control = messages=20 and IEEE 802.1X EAPoL frames" and add text to indicate that IEEE = 802.1X=20 frames are sent at a higher priority.
 
Cheers,
 
=
Mike

______________________________________________________= ___________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20



------_=_NextPart_001_01C6E051.413C17BE-- --===============1998911442== 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 --===============1998911442==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Sep 25 01:21:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRiuS-0002lg-MH for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 01:21:40 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRiuO-0002HS-2k for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 01:21:40 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id AC872398089 for ; Sun, 24 Sep 2006 22:21:35 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3B1A943005F for ; Sun, 24 Sep 2006 22:20:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2318639802A for ; Sun, 24 Sep 2006 22:20:55 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [61.144.161.53]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6D0F639800B for ; Sun, 24 Sep 2006 22:20:52 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J64003UOV17LZ@szxga01-in.huawei.com> for capwap@frascone.com; Mon, 25 Sep 2006 13:24:43 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6400KZRV16QB@szxga01-in.huawei.com> for capwap@frascone.com; Mon, 25 Sep 2006 13:24:43 +0800 (CST) Received: from dell60 ([10.18.23.153]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J64004NEV35BV@szxml03-in.huawei.com> for capwap@frascone.com; Mon, 25 Sep 2006 13:25:57 +0800 (CST) Date: Mon, 25 Sep 2006 10:50:39 +0530 From: sujay In-reply-to: <4FF84B0BC277FF45AA27FE969DD956A202876981@xmb-sjc-235.amer.cisco.com> To: "'Pat Calhoun (pacalhou)'" Message-id: <007501c6e062$57264320$9917120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcbdeTQ8CR0SLrwyRMaeKBeBcmDxVQAckCxAAItzzMAAEhSegA== 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] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 848ed35f2a4fc0638fa89629cb640f48 Hi Pat, Perhaps the current specs has no provision for maintaining the KeyRSC required for Multicast and Broadcast messages in the AC, in case the WTP is doing the en/de-cryption. Hence in the 3rd message of the 4 way handshake , I do not see how the AC could possibly send the KeyRSC values to the Mobile Station w/o some assumptions on the Mobile station (supplicant) side ?? I concur with Charles in his analysis. Regds, Sujay G My Location; http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=h &hl=en This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Monday, September 25, 2006 6:46 AM To: Saravanan Govindan; Margaret Wasserman Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations Saravanan, We've been down this path already, and I believe Bob O'Hara tried to set you in the right direction. Your assessment is incorrect and 802.11i works fine w/ the current spec. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Friday, September 22, 2006 2:03 AM > To: Margaret Wasserman > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Hi Margaret, > > Thank you for reviewing the discussion on this issue. > > The issue here is the working of IEEE 802.11i when the 802.11i > authenticator element is at the AC and the 802.11i crypto element is > at the WTP. Particularly, it is for the 4-way handshake between > authenticator and supplicant. > > Now, the 4-way handshake requires knowing the value of KeyRSC sequence > counter. The KeyRSC helps both authenticator and supplicant keep track > of their exchanges. It serves to protect against threats by tracking > sequential frames. The KeyRSC is maintained at the at the point of > encryption, i.e. > just before transmission over the wireless channel. > > In the case of CAPWAP, the 4-way handshake is between the AC > (authenticator) and the wireless station (supplicant). > > The problem arises, when the authenticator is at the AC and the crypto > element (together with KeyRSC) is at the WTP. This is a fairly common > design. Now in this case, the AC starts the 4-way handshake but it > does not know the value of the KeyRSC. The KeyRSC is maintained by the > WTP. > > Based on this, the current CAPWAP specification does not allow for a > way to conduct the 4-way handshake with the correct KeyRSC. > > The functionality I would like to see is a way for the authenticator > (AC) to use the correct prevailing value of KeyRSC (maintained by the > WTP) in its 4-way handshake. > > One way to introduce this functionality in to CAPWAP is to have part > of the 4-way handshake be sent from AC to WTP. This will allow the > 4-way handshake to use the correct value of the KeyRSC before being > sent to the wireless station. > > I hope this helps clarify my view on the issue. > > Cheers, > > Saravanan > > > > > > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, September 21, 2006 8:26 PM > To: Saravanan Govindan > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > Hi again, > > Okay, I am even more confused than I thought I was... > > Saravanan, you wrote: > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > Pat, > > > > The issue here is about how 802.11i exchanges are done when > > authenticator is at the AC and crypto elements are at the > WTP. This is > > the requirement. > > And, in response, Pat Calhoun wrote: > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: > > The current specification allows the authenticator to > reside in the > > AC, > > while the data packet crypto elements in the WTP. This feature is > > already in the specification. > > Pat's message matches my reading of the specification. > > So, Saravanan, what functionality are you asking for that is not > already supported by the specification? And why do you think it is > necessary? it will not be helpful to my understanding to re-send your > proposal or to cite the requirements document... Please summarize > what functionality you think is missing from the current specification > and why you think that functionality is necessary to support IEEE > 802.11i or any important use case. > > At some point, the chairs may need to make a consensus call on this > issue, and I'd like to understand your view and make sure that it has > been clearly communicated to the WG before we ask the WG to decide on > this issue. > > 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 _________________________________________________________________ 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 Sep 25 08:59:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRq3u-0001Wl-8V for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 08:59:54 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRq3n-0004Ef-Iq for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 08:59:54 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id E884F398088 for ; Mon, 25 Sep 2006 05:59:46 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id CB8B2430094 for ; Mon, 25 Sep 2006 05:59:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B17E6431592 for ; Mon, 25 Sep 2006 05:59:04 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by hermes.tigertech.net (Postfix) with ESMTP id 13F24431590 for ; Mon, 25 Sep 2006 05:59:00 -0700 (PDT) Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A45B54F009F for ; Mon, 25 Sep 2006 14:58:54 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 14:58:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Sep 2006 14:58:52 +0200 Message-ID: In-Reply-To: <5F09D220B62F79418461A978CA0921BD012F17A6@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations thread-index: AcbdeTQ8CR0SLrwyRMaeKBeBcmDxVQAckCxAAK1HGpA= From: "Peter Nilsson J (LI/EAB)" Cc: X-OriginalArrivalTime: 25 Sep 2006 12:58:54.0241 (UTC) FILETIME=[5AFBC110:01C6E0A2] X-Brightmail-Tracker: AAAAAA== 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=SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: b2809b6f39decc6de467dcf252f42af1 I think Saravanan has a point. We did a prototype impelementation of the protocol a year ago when it was still called LWAPP. The way we solved this issue then was to let the WTP sniff on all CAPWAP data messages from the AC and when message 3 of the 4-way handshake or message 1 of the groupkey handshake was sent the WTP inserted the correct RSC before sending it off to the supplicant. To avoid the sniffing on all CAPWAP data messages we would need a mechanism with in CAPWAP to handle these two messages. Peter Nilsson -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: den 22 september 2006 11:03 To: Margaret Wasserman Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi Margaret, Thank you for reviewing the discussion on this issue. The issue here is the working of IEEE 802.11i when the 802.11i authenticator element is at the AC and the 802.11i crypto element is at the WTP. Particularly, it is for the 4-way handshake between authenticator and supplicant. Now, the 4-way handshake requires knowing the value of KeyRSC sequence counter. The KeyRSC helps both authenticator and supplicant keep track of their exchanges. It serves to protect against threats by tracking sequential frames. The KeyRSC is maintained at the at the point of encryption, i.e. just before transmission over the wireless channel. In the case of CAPWAP, the 4-way handshake is between the AC (authenticator) and the wireless station (supplicant). The problem arises, when the authenticator is at the AC and the crypto element (together with KeyRSC) is at the WTP. This is a fairly common design. Now in this case, the AC starts the 4-way handshake but it does not know the value of the KeyRSC. The KeyRSC is maintained by the WTP. Based on this, the current CAPWAP specification does not allow for a way to conduct the 4-way handshake with the correct KeyRSC. The functionality I would like to see is a way for the authenticator (AC) to use the correct prevailing value of KeyRSC (maintained by the WTP) in its 4-way handshake. One way to introduce this functionality in to CAPWAP is to have part of the 4-way handshake be sent from AC to WTP. This will allow the 4-way handshake to use the correct value of the KeyRSC before being sent to the wireless station. I hope this helps clarify my view on the issue. Cheers, Saravanan -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com] Sent: Thursday, September 21, 2006 8:26 PM To: Saravanan Govindan Cc: Pat Calhoun (pacalhou); capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi again, Okay, I am even more confused than I thought I was... Saravanan, you wrote: On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > Pat, > > The issue here is about how 802.11i exchanges are done when > authenticator is at the AC and crypto elements are at the WTP. This is > the requirement. And, in response, Pat Calhoun wrote: On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: > The current specification allows the authenticator to reside in the > AC, > while the data packet crypto elements in the WTP. This feature is > already in the specification. Pat's message matches my reading of the specification. So, Saravanan, what functionality are you asking for that is not already supported by the specification? And why do you think it is necessary? it will not be helpful to my understanding to re-send your proposal or to cite the requirements document... Please summarize what functionality you think is missing from the current specification and why you think that functionality is necessary to support IEEE 802.11i or any important use case. At some point, the chairs may need to make a consensus call on this issue, and I'd like to understand your view and make sure that it has been clearly communicated to the WG before we ask the WG to decide on this issue. 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 _________________________________________________________________ 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 Sep 25 10:51:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRroL-0002Et-Cb for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 10:51:57 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRrec-0008PA-GF for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 10:41:56 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id D26311448062 for ; Mon, 25 Sep 2006 07:41:41 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 71931430094 for ; Mon, 25 Sep 2006 07:39:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 53261398012 for ; Mon, 25 Sep 2006 07:39:36 -0700 (PDT) Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by zoidberg.tigertech.net (Postfix) with ESMTP id E751B39800D for ; Mon, 25 Sep 2006 07:39:33 -0700 (PDT) Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id 33E681A49; Mon, 25 Sep 2006 14:39:30 +0000 (GMT) Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.31J) with ESMTP id 538kiyonC0037Mo1; Mon, 25 Sep 2006 14:39:29 GMT Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.31J) with ESMTP id 522kiyonA0037Mo1; Mon, 25 Sep 2006 14:39:26 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.32F); Mon, 25 Sep 2006 14:39:26 GMT X-USANET-Source: 165.212.116.254 IN bhandaru@nexthop.com GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID139kiyonA5689Xo1 Received: from VS4.EXCHPROD.USA.NET ([10.116.208.141]) by GW1.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 08:39:25 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Sep 2006 08:39:05 -0600 Message-ID: <7ADC90A5E95BA74DA5CA5A6C390D53050697B9A7@VS4.EXCHPROD.USA.NET> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbdeTQ8CR0SLrwyRMaeKBeBcmDxVQAckCxAAK1HGpAAA7XMEA== From: "Nehru Bhandaru" To: "Peter Nilsson J (LI/EAB)" X-OriginalArrivalTime: 25 Sep 2006 14:39:25.0646 (UTC) FILETIME=[65FB1EE0:01C6E0B0] 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] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: c54bc2f42d02429833c0ca4b8725abd7 Does this mean WTP has knowledge of (or can compute) the KCK that is used to integrity protect these messages? Does/Did the protocol have a way to communicate this to the WTP? If so, does this have any additional security implications? - Nehru -----Original Message----- From: Peter Nilsson J (LI/EAB) [mailto:peter.j.nilsson@ericsson.com] Sent: Monday, September 25, 2006 8:59 AM Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations I think Saravanan has a point. We did a prototype impelementation of the protocol a year ago when it was still called LWAPP. The way we solved this issue then was to let the WTP sniff on all CAPWAP data messages from the AC and when message 3 of the 4-way handshake or message 1 of the groupkey handshake was sent the WTP inserted the correct RSC before sending it off to the supplicant. To avoid the sniffing on all CAPWAP data messages we would need a mechanism with in CAPWAP to handle these two messages. Peter Nilsson -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: den 22 september 2006 11:03 To: Margaret Wasserman Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi Margaret, Thank you for reviewing the discussion on this issue. The issue here is the working of IEEE 802.11i when the 802.11i authenticator element is at the AC and the 802.11i crypto element is at the WTP. Particularly, it is for the 4-way handshake between authenticator and supplicant. Now, the 4-way handshake requires knowing the value of KeyRSC sequence counter. The KeyRSC helps both authenticator and supplicant keep track of their exchanges. It serves to protect against threats by tracking sequential frames. The KeyRSC is maintained at the at the point of encryption, i.e. just before transmission over the wireless channel. In the case of CAPWAP, the 4-way handshake is between the AC (authenticator) and the wireless station (supplicant). The problem arises, when the authenticator is at the AC and the crypto element (together with KeyRSC) is at the WTP. This is a fairly common design. Now in this case, the AC starts the 4-way handshake but it does not know the value of the KeyRSC. The KeyRSC is maintained by the WTP. Based on this, the current CAPWAP specification does not allow for a way to conduct the 4-way handshake with the correct KeyRSC. The functionality I would like to see is a way for the authenticator (AC) to use the correct prevailing value of KeyRSC (maintained by the WTP) in its 4-way handshake. One way to introduce this functionality in to CAPWAP is to have part of the 4-way handshake be sent from AC to WTP. This will allow the 4-way handshake to use the correct value of the KeyRSC before being sent to the wireless station. I hope this helps clarify my view on the issue. Cheers, Saravanan -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com] Sent: Thursday, September 21, 2006 8:26 PM To: Saravanan Govindan Cc: Pat Calhoun (pacalhou); capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi again, Okay, I am even more confused than I thought I was... Saravanan, you wrote: On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > Pat, > > The issue here is about how 802.11i exchanges are done when > authenticator is at the AC and crypto elements are at the WTP. This is > the requirement. And, in response, Pat Calhoun wrote: On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: > The current specification allows the authenticator to reside in the > AC, > while the data packet crypto elements in the WTP. This feature is > already in the specification. Pat's message matches my reading of the specification. So, Saravanan, what functionality are you asking for that is not already supported by the specification? And why do you think it is necessary? it will not be helpful to my understanding to re-send your proposal or to cite the requirements document... Please summarize what functionality you think is missing from the current specification and why you think that functionality is necessary to support IEEE 802.11i or any important use case. At some point, the chairs may need to make a consensus call on this issue, and I'd like to understand your view and make sure that it has been clearly communicated to the WG before we ask the WG to decide on this issue. 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 _________________________________________________________________ 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 Sep 25 12:27:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRtIY-0007Sr-Rx for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 12:27:14 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRtIW-0007Xm-NF for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 12:27:14 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 4D6DA1448027 for ; Mon, 25 Sep 2006 09:27:08 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 45405430094 for ; Mon, 25 Sep 2006 09:25:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1E1591448039 for ; Mon, 25 Sep 2006 09:25:21 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id D76361448053 for ; Mon, 25 Sep 2006 09:25:17 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id k8PGPFiK013192; Tue, 26 Sep 2006 01:25:15 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k8PGPFp00021; Tue, 26 Sep 2006 01:25:15 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with SMTP id k8PGPEl23456; Tue, 26 Sep 2006 01:25:14 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Sep 2006 00:24:07 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F19A0@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbelHtY03duHyNcQpOTYEY6mc+uAwAAB9YAAIpwBSA= From: "Saravanan Govindan" To: "T Sridhar" , "Margaret Wasserman" , 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] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: a630332fa112280ecc4c4186b5c9ea83 Hi Sridhar, To summarize, the current CAPWAP specifications will not allow the 4-way handshake to be correctly operated in the case where authenticator is at the AC and cyrpto element is at the WTP - the KeyRSC is maintained at the point of the crypto element. The reason is that the 4-way handshake requires KeyRSC information that is unavailable to the AC since the KeyRSC is maintained by the WTP. I hope this helps summarize the issue. Cheers, Saravanan -----Original Message----- From: T Sridhar [mailto:T.Sridhar@flextronics.com] Sent: Saturday, September 23, 2006 6:18 AM To: Margaret Wasserman; capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi, It would be good to get a summary of the reasons why this proposal should be accepted or rejected. Currently we have a number of email threads on this topic but a summary would be great. Saravanan/Pat - could you folks help? Thanks, Sridhar -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com] Sent: Friday, September 22, 2006 3:12 PM To: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi All, I'm trying to get a read on whether this issue needs further discussion or not... Saravanan has made a proposal for change to the specification, and he has offered an explanation for the motivation behind this proposal (see below). Pat Calhoun has argued that this level of flexibility is unnecessary and that the specification fully supports IEEE 802.11i and meets the requirements, as written. I've seen a few notes in support of Pat's position and I haven't noticed anyone else supporting Saravanan's proposal. If there are others who support Saravanan's proposal, please speak up. Unless we see strong support for this proposal, we'll have to conclude that the WG does not have consensus to make this change. Margaret On Sep 22, 2006, at 5:03 AM, Saravanan Govindan wrote: > Hi Margaret, > > Thank you for reviewing the discussion on this issue. > > The issue here is the working of IEEE 802.11i when the 802.11i > authenticator element is at the AC and the 802.11i crypto element > is at > the WTP. Particularly, it is for the 4-way handshake between > authenticator and supplicant. > > Now, the 4-way handshake requires knowing the value of KeyRSC sequence > counter. The KeyRSC helps both authenticator and supplicant keep track > of their exchanges. It serves to protect against threats by tracking > sequential frames. The KeyRSC is maintained at the at the point of > encryption, i.e. just before transmission over the wireless channel. > > In the case of CAPWAP, the 4-way handshake is between the AC > (authenticator) and the wireless station (supplicant). > > The problem arises, when the authenticator is at the AC and the crypto > element (together with KeyRSC) is at the WTP. This is a fairly common > design. Now in this case, the AC starts the 4-way handshake but it > does > not know the value of the KeyRSC. The KeyRSC is maintained by the WTP. > > Based on this, the current CAPWAP specification does not allow for > a way > to conduct the 4-way handshake with the correct KeyRSC. > > The functionality I would like to see is a way for the authenticator > (AC) to use the correct prevailing value of KeyRSC (maintained by the > WTP) in its 4-way handshake. > > One way to introduce this functionality in to CAPWAP is to have > part of > the 4-way handshake be sent from AC to WTP. This will allow the 4-way > handshake to use the correct value of the KeyRSC before being sent to > the wireless station. > > I hope this helps clarify my view on the issue. > > Cheers, > > Saravanan > > > > > > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, September 21, 2006 8:26 PM > To: Saravanan Govindan > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > Hi again, > > Okay, I am even more confused than I thought I was... > > Saravanan, you wrote: > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > >> Pat, >> >> The issue here is about how 802.11i exchanges are done when >> authenticator is at the AC and crypto elements are at the WTP. >> This is >> the requirement. > > And, in response, Pat Calhoun wrote: > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: >> The current specification allows the authenticator to reside in the >> AC, >> while the data packet crypto elements in the WTP. This feature is >> already in the specification. > > Pat's message matches my reading of the specification. > > So, Saravanan, what functionality are you asking for that is not > already supported by the specification? And why do you think it is > necessary? it will not be helpful to my understanding to re-send > your proposal or to cite the requirements document... Please > summarize what functionality you think is missing from the current > specification and why you think that functionality is necessary to > support IEEE 802.11i or any important use case. > > At some point, the chairs may need to make a consensus call on this > issue, and I'd like to understand your view and make sure that it has > been clearly communicated to the WG before we ask the WG to decide on > this issue. > > 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 Legal Disclaimer: The information contained in this message may be privileged and confidential. It is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete or destroy any copy of this message _________________________________________________________________ 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 Sep 25 12:50:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRtec-0002CK-HT for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 12:50:02 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRtYq-0002IV-3w for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 12:44:05 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 81E5314480AB for ; Mon, 25 Sep 2006 09:44:00 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7DBE2430094 for ; Mon, 25 Sep 2006 09:42:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 70881398064 for ; Mon, 25 Sep 2006 09:42:35 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id DE884398049 for ; Mon, 25 Sep 2006 09:42:32 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k8PGgPPm019890; Tue, 26 Sep 2006 01:42:25 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k8PGgRp03267; Tue, 26 Sep 2006 01:42:27 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with SMTP id k8PGgRQ27453; Tue, 26 Sep 2006 01:42:27 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Sep 2006 00:41:19 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F19A1@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbfFWuNO4Y7DZ5mQ3inxW0kHvwFBwBqrXsg From: "Saravanan Govindan" To: "Margaret Wasserman" , "T Sridhar" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 538aad3a3c4f01d8b6a6477ca4248793 Hi Margaret, You provide a very thorough summary of the issue! I am pasting only a portion of your note here; > Saravanan, could you provides some technical information that > supports your position that the KeyRSC will reside on the WTP when > the encryption end-point is on the WTP? As a sequence counter, the KeyRSC is used to track frames over the wireless channel. Fundamentally, the KeyRSC is updated only when a frame is exchanged over the channel. So in the CAPWAP architecture; AC <-> WTP <-> Wireless The WTP "neighbours" the wireless channel. So it is the WTP that will maintain the KeyRSC. Cheers, Saravanan -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com] Sent: Saturday, September 23, 2006 9:36 PM To: T Sridhar Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi All, [Pat and Saravanan, I have asked some questions of each of you below. In particular, please note the request for more information at the end of the main message, before the beginning of the references section.] At T. Sridhar's request, I'll attempt to summarize the discussion on this issue to date. . . . . _________________________________________________________________ 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 Sep 25 12:50:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRted-0002CK-6l for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 12:50:03 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRtYF-0002Gl-0U for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 12:43:30 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 034DF1448051 for ; Mon, 25 Sep 2006 09:43:23 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 26D58430094 for ; Mon, 25 Sep 2006 09:39:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0EF38144800B for ; Mon, 25 Sep 2006 09:39:35 -0700 (PDT) Received: from web60325.mail.yahoo.com (web60325.mail.yahoo.com [209.73.178.133]) by hermes.tigertech.net (Postfix) with SMTP id 4A9121448029 for ; Mon, 25 Sep 2006 09:39:32 -0700 (PDT) Received: (qmail 54509 invoked by uid 60001); 25 Sep 2006 16:39:31 -0000 Message-ID: <20060925163931.54507.qmail@web60325.mail.yahoo.com> Received: from [12.129.211.52] by web60325.mail.yahoo.com via HTTP; Mon, 25 Sep 2006 09:39:31 PDT Date: Mon, 25 Sep 2006 09:39:31 -0700 (PDT) From: Behcet Sarikaya To: "Peter Nilsson J (LI/EAB)" 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=2.7 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, HTML_20_30, HTML_MESSAGE X-Spam-Level: ** Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0457682629==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc --===============0457682629== Content-Type: multipart/alternative; boundary="0-1326101630-1159202371=:54393" --0-1326101630-1159202371=:54393 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Are you saying that the RSC value can not be set by AC? I fail to understan= d it because the user (STA) is new under this WTP anyways.=0A=0A--behcet=0A= =0A=0A----- Original Message ----=0AFrom: Peter Nilsson J (LI/EAB) =0ACc: capwap@frascone.com=0ASent: Monday, September = 25, 2006 7:58:52 AM=0ASubject: Re: [Capwap] Issue 43 - Explanation for 802.= 11i Considerations=0A=0A=0AI think Saravanan has a point. We did a prototyp= e impelementation of the=0Aprotocol a year ago when it was still called LWA= PP. The way we solved=0Athis issue then was to let the WTP sniff on all CAP= WAP data messages=0Afrom the AC and when message 3 of the 4-way handshake o= r message 1 of=0Athe groupkey handshake was sent the WTP inserted the corre= ct RSC before=0Asending it off to the supplicant. To avoid the sniffing on = all CAPWAP=0Adata messages we would need a mechanism with in CAPWAP to hand= le these=0Atwo messages.=0A=0APeter Nilsson =0A=0A-----Original Message--= ---=0AFrom: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]= =0ASent: den 22 september 2006 11:03=0ATo: Margaret Wasserman=0ACc: capwap= @frascone.com=0ASubject: Re: [Capwap] Issue 43 - Explanation for 802.11i Co= nsiderations=0A=0AHi Margaret,=0A=0AThank you for reviewing the discussion = on this issue.=0A=0AThe issue here is the working of IEEE 802.11i when the = 802.11i=0Aauthenticator element is at the AC and the 802.11i crypto element= is at=0Athe WTP. Particularly, it is for the 4-way handshake between=0Aaut= henticator and supplicant. =0A=0ANow, the 4-way handshake requires knowing = the value of KeyRSC sequence=0Acounter. The KeyRSC helps both authenticator= and supplicant keep track=0Aof their exchanges. It serves to protect again= st threats by tracking=0Asequential frames. The KeyRSC is maintained at the= at the point of=0Aencryption, i.e. just before transmission over the wirel= ess channel.=0A=0AIn the case of CAPWAP, the 4-way handshake is between the= AC=0A(authenticator) and the wireless station (supplicant). =0A=0AThe prob= lem arises, when the authenticator is at the AC and the crypto=0Aelement (t= ogether with KeyRSC) is at the WTP. This is a fairly common=0Adesign. Now i= n this case, the AC starts the 4-way handshake but it does=0Anot know the v= alue of the KeyRSC. The KeyRSC is maintained by the WTP. =0A=0ABased on thi= s, the current CAPWAP specification does not allow for a way=0Ato conduct t= he 4-way handshake with the correct KeyRSC.=0A=0AThe functionality I would = like to see is a way for the authenticator=0A(AC) to use the correct prevai= ling value of KeyRSC (maintained by the=0AWTP) in its 4-way handshake. =0A= =0AOne way to introduce this functionality in to CAPWAP is to have part of= =0Athe 4-way handshake be sent from AC to WTP. This will allow the 4-way=0A= handshake to use the correct value of the KeyRSC before being sent to=0Athe= wireless station. =0A=0AI hope this helps clarify my view on the issue. = =0A=0ACheers,=0A=0ASaravanan=0A=0A=0A=0A=0A=0A=0A-----Original Message-----= =0AFrom: Margaret Wasserman [mailto:margaret@thingmagic.com]=0ASent: Thursd= ay, September 21, 2006 8:26 PM=0ATo: Saravanan Govindan=0ACc: Pat Calhoun (= pacalhou); capwap@frascone.com=0ASubject: Re: [Capwap] Issue 43 - Explanati= on for 802.11i Considerations=0A=0A=0A=0AHi again,=0A=0AOkay, I am even mor= e confused than I thought I was...=0A=0ASaravanan, you wrote:=0A=0AOn Sep 1= 7, 2006, at 10:24 PM, Saravanan Govindan wrote:=0A=0A> Pat,=0A>=0A> The iss= ue here is about how 802.11i exchanges are done when=0A> authenticator is a= t the AC and crypto elements are at the WTP. This is=0A> the requirement.= =0A=0AAnd, in response, Pat Calhoun wrote:=0A=0AOn Sep 18, 2006, at 4:15 PM= , Pat Calhoun (pacalhou) wrote:=0A> The current specification allows the au= thenticator to reside in the =0A> AC,=0A> while the data packet crypto ele= ments in the WTP. This feature is=0A> already in the specification.=0A=0APa= t's message matches my reading of the specification.=0A=0ASo, Saravanan, wh= at functionality are you asking for that is not =0Aalready supported by th= e specification? And why do you think it is =0Anecessary? it will not be= helpful to my understanding to re-send =0Ayour proposal or to cite the re= quirements document... Please =0Asummarize what functionality you think i= s missing from the current =0Aspecification and why you think that functio= nality is necessary to =0Asupport IEEE 802.11i or any important use case.= =0A=0AAt some point, the chairs may need to make a consensus call on this = =0Aissue, and I'd like to understand your view and make sure that it has = =0Abeen clearly communicated to the WG before we ask the WG to decide on = =0Athis issue.=0A=0AThanks,=0AMargaret=0A=0A=0A=0A=0A=0A=0A________________= _________________________________________________=0ATo unsubscribe or modif= y your subscription options, please visit:=0Ahttp://lists.frascone.com/mail= man/listinfo/capwap=0A=0AArchives: http://lists.frascone.com/pipermail/capw= ap=0A_________________________________________________________________=0ATo= unsubscribe or modify your subscription options, please visit:=0Ahttp://li= sts.frascone.com/mailman/listinfo/capwap=0A=0AArchives: http://lists.frasco= ne.com/pipermail/capwap --0-1326101630-1159202371=:54393 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Are you saying that the RSC value can not be set by= AC? I fail to understand it because the user (STA) is new under this WTP a= nyways.
=0A
 
=0A
--behcet

=0A<= DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times= , serif">----- Original Message ----
From: Peter Nilsson J (LI/EAB) <= peter.j.nilsson@ericsson.com>
Cc: capwap@frascone.com
Sent: Monday= , September 25, 2006 7:58:52 AM
Subject: Re: [Capwap] Issue 43 - Explana= tion for 802.11i Considerations

=0A
I think Saravanan has a poin= t. We did a prototype impelementation of the
protocol a year ago when it= was still called LWAPP. The way we solved
this issue then was to let th= e WTP sniff on all CAPWAP data messages
from the AC and when message 3 o= f the 4-way handshake or message 1 of
the groupkey handshake was sent th= e WTP inserted the correct RSC before
sending it off to the supplicant. = To avoid the sniffing on all CAPWAP
data messages we would need a mechan= ism with in CAPWAP to handle these
two messages.

Peter Nilsson&nb= sp; 

-----Original Message-----
From: Saravanan Govindan [m= ailto:Saravanan.Govindan@sg.panasonic.com]
Sent: den 22 september 2006 = 11:03
To: Margaret Wasserman
Cc: capwap@frascone.com
Subject: Re: = [Capwap] Issue 43 - Explanation for 802.11i Considerations

Hi Margar= et,

Thank you for reviewing the discussion on this issue.

The= issue here is the working of IEEE 802.11i when the 802.11i
authenticator element is at the AC and the 802.11i crypto eleme= nt is at
the WTP. Particularly, it is for the 4-way handshake betweenauthenticator and supplicant.

Now, the 4-way handshake requires kn= owing the value of KeyRSC sequence
counter. The KeyRSC helps both authen= ticator and supplicant keep track
of their exchanges. It serves to prote= ct against threats by tracking
sequential frames. The KeyRSC is maintain= ed at the at the point of
encryption, i.e. just before transmission over= the wireless channel.

In the case of CAPWAP, the 4-way handshake is= between the AC
(authenticator) and the wireless station (supplicant). <= BR>
The problem arises, when the authenticator is at the AC and the cryp= to
element (together with KeyRSC) is at the WTP. This is a fairly common=
design. Now in this case, the AC starts the 4-way handshake but it does=
not know the value of the KeyRSC. The KeyRSC is maintained by the WTP. =

Based on this, the current CAPWAP specification does not allow for a way
to c= onduct the 4-way handshake with the correct KeyRSC.

The functionalit= y I would like to see is a way for the authenticator
(AC) to use the cor= rect prevailing value of KeyRSC (maintained by the
WTP) in its 4-way han= dshake.

One way to introduce this functionality in to CAPWAP is to = have part of
the 4-way handshake be sent from AC to WTP. This will allow= the 4-way
handshake to use the correct value of the KeyRSC before being= sent to
the wireless station.

I hope this helps clarify my view= on the issue.

Cheers,

Saravanan






= -----Original Message-----
From: Margaret Wasserman [mailto:margaret@thi= ngmagic.com]
Sent: Thursday, September 21, 2006 8:26 PM
To: Saravanan= Govindan
Cc: Pat Calhoun (pacalhou); capwap@frascone.com
Subject: Re= : [Capwap] Issue 43 - Explanation for 802.11i Considerations


Hi again,

Okay, I am even more confused than I thought I was...
Saravanan, you wrote:

On Sep 17, 2006, at 10:24 PM, Saravanan Govin= dan wrote:

> Pat,
>
> The issue here is about how 802= .11i exchanges are done when
> authenticator is at the AC and crypto = elements are at the WTP. This is
> the requirement.

And, in re= sponse, Pat Calhoun wrote:

On Sep 18, 2006, at 4:15 PM, Pat Calhoun = (pacalhou) wrote:
> The current specification allows the authenticato= r to reside in the  
> AC,
> while the data packet cr= ypto elements in the WTP. This feature is
> already in the specificat= ion.

Pat's message matches my reading of the specification.

S= o, Saravanan, what functionality are you asking for that is not  =
already supported by the specification?  And why do you think= it is  
necessary?  it will not be helpful to my un= derstanding to re-send  
your proposal or to cite the requirements docume= nt...  Please  
summarize what functionality you thi= nk is missing from the current  
specification and why you thi= nk that functionality is necessary to  
support IEEE 802.11i o= r any important use case.

At some point, the chairs may need to make= a consensus call on this  
issue, and I'd like to understand = your view and make sure that it has  
been clearly communicate= d to the WG before we ask the WG to decide on  
this issue.
Thanks,
Margaret






_______________________= __________________________________________
To unsubscribe or modify your= subscription options, please visit:
http://lists.frascone.com/mailma= n/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap
________= _________________________________________________________
To unsubscribe= or modify your subscription options, please visit:
http://lists.fras= cone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com= /pipermail/capwap
=0A

--0-1326101630-1159202371=:54393-- --===============0457682629== 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 --===============0457682629==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Sep 25 12:50:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRtfT-0002aU-Ng for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 12:50:55 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRtfS-0003i5-5i for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 12:50:55 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id B404414480BB for ; Mon, 25 Sep 2006 09:50:50 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 0DC78430094 for ; Mon, 25 Sep 2006 09:50:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 012F0398041 for ; Mon, 25 Sep 2006 09:50:02 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 30FD5398049 for ; Mon, 25 Sep 2006 09:49:45 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k8PGnfeF024095; Tue, 26 Sep 2006 01:49:41 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k8PGnhp04602; Tue, 26 Sep 2006 01:49:43 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with SMTP id k8PGnh121705; Tue, 26 Sep 2006 01:49:43 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Sep 2006 00:48:39 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F19A2@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbdeTQ8CR0SLrwyRMaeKBeBcmDxVQAckCxAAItzzMAAKhaB0A== From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , "Margaret Wasserman" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 3971661e40967acfc35f708dd5f33760 Pat, I have asked both Bob and yourself to clarify how the current specifications allow 802.11i to operate in the case under consideration. Sujay has made another note on this. We are still waiting to get substantive explanation on how the protocol currently does this. Saravanan -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Monday, September 25, 2006 9:16 AM To: Saravanan Govindan; Margaret Wasserman Cc: capwap@frascone.com Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations Saravanan, We've been down this path already, and I believe Bob O'Hara tried to set you in the right direction. Your assessment is incorrect and 802.11i works fine w/ the current spec. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Friday, September 22, 2006 2:03 AM > To: Margaret Wasserman > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Hi Margaret, > > Thank you for reviewing the discussion on this issue. > > The issue here is the working of IEEE 802.11i when the > 802.11i authenticator element is at the AC and the 802.11i > crypto element is at the WTP. Particularly, it is for the > 4-way handshake between authenticator and supplicant. > > Now, the 4-way handshake requires knowing the value of KeyRSC > sequence counter. The KeyRSC helps both authenticator and > supplicant keep track of their exchanges. It serves to > protect against threats by tracking sequential frames. The > KeyRSC is maintained at the at the point of encryption, i.e. > just before transmission over the wireless channel. > > In the case of CAPWAP, the 4-way handshake is between the AC > (authenticator) and the wireless station (supplicant). > > The problem arises, when the authenticator is at the AC and > the crypto element (together with KeyRSC) is at the WTP. This > is a fairly common design. Now in this case, the AC starts > the 4-way handshake but it does not know the value of the > KeyRSC. The KeyRSC is maintained by the WTP. > > Based on this, the current CAPWAP specification does not > allow for a way to conduct the 4-way handshake with the > correct KeyRSC. > > The functionality I would like to see is a way for the authenticator > (AC) to use the correct prevailing value of KeyRSC (maintained by the > WTP) in its 4-way handshake. > > One way to introduce this functionality in to CAPWAP is to > have part of the 4-way handshake be sent from AC to WTP. This > will allow the 4-way handshake to use the correct value of > the KeyRSC before being sent to the wireless station. > > I hope this helps clarify my view on the issue. > > Cheers, > > Saravanan > > > > > > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, September 21, 2006 8:26 PM > To: Saravanan Govindan > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > Hi again, > > Okay, I am even more confused than I thought I was... > > Saravanan, you wrote: > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > Pat, > > > > The issue here is about how 802.11i exchanges are done when > > authenticator is at the AC and crypto elements are at the > WTP. This is > > the requirement. > > And, in response, Pat Calhoun wrote: > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: > > The current specification allows the authenticator to > reside in the > > AC, > > while the data packet crypto elements in the WTP. This feature is > > already in the specification. > > Pat's message matches my reading of the specification. > > So, Saravanan, what functionality are you asking for that is not > already supported by the specification? And why do you think it is > necessary? it will not be helpful to my understanding to re-send > your proposal or to cite the requirements document... Please > summarize what functionality you think is missing from the current > specification and why you think that functionality is necessary to > support IEEE 802.11i or any important use case. > > At some point, the chairs may need to make a consensus call on this > issue, and I'd like to understand your view and make sure > that it has > been clearly communicated to the WG before we ask the WG to > decide on > this issue. > > 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 mylulry@tpnet.pl Mon Sep 25 13:17:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRu52-0004eV-1v for capwap-archive@ietf.org; Mon, 25 Sep 2006 13:17:20 -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 1GRu51-0000M5-TP for capwap-archive@ietf.org; Mon, 25 Sep 2006 13:17:20 -0400 Received: from ewi1.neoplus.adsl.tpnet.pl ([83.20.232.1] helo=euq234.neoplus.adsl.tpnet.pl) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GRu4x-0004ft-4f for capwap-archive@ietf.org; Mon, 25 Sep 2006 13:17:19 -0400 Message-ID: <000801c6e0c6$67c09aa0$eabc1453@mariusz> From: "did not" To: capwap-archive@ietf.org Subject: for expert help Date: Mon, 25 Sep 2006 19:16:57 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C6E0D7.2B496AA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: -0.1 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b ------=_NextPart_000_0004_01C6E0D7.2B496AA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C6E0D7.2B496AA0" ------=_NextPart_001_0005_01C6E0D7.2B496AA0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Groups Home Help Sign in Web Images VideoNew News Maps more raquo = Advanced Search Members: users: Join Alerts Create new group About = Searched all groups Your search did not match any Make sure words are = spelled Try different keywords. general fewer your on can try Answers = for expert help with search. Get the oogle Groups Home Help Sign in Web Images VideoNew News Maps more raquo = Advanced Search Members: users: Join Alerts Create new group About = Searched all groups Your search did not match any Make sure words are = spelled Try different keywords. general fewer your on can try Answers = for expert help with search. Get the latest messages emailed to Alerts. = Terms of Service Privacy Images VideoNew News Maps more raquo Advanced Search Members: users: = Join Alerts Create new group About Searched all groups Your search did = not match any Make sure words are spelled Try different keywords. = general fewer your on can try Answers for expert help with oogle Groups Home Help Sign in Web Images VideoNew News Maps more raquo = Advanced Search Members: users: Join Alerts Create new group About = Searched all groups Your search did not match any Make sure words are = spelled Try different keywords. general fewer your on can try Answers = for expert help with search. Get the latest messages emailed to Alerts. = Terms of Service Privacy Policy copy Home Help Sign in Web Images VideoNew News Maps more raquo Advanced = Search Members: users: Join Alerts Create new group About Searched all = groups Your search did not match any Make sure words are spelled Try = different keywords. general fewer Your search did not match any Make sure words are spelled Try different = keywords. general fewer your on can try Answers for expert help with = search. Get the latest messages emailed to Alerts. Terms of Service = Privacy group About Searched all groups Your search did not match any ------=_NextPart_001_0005_01C6E0D7.2B496AA0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
Groups Home Help Sign in Web Images VideoNew News Maps more = raquo Advanced Search Members: users: Join Alerts Create new group About = Searched all groups Your search did not match any Make sure words are = spelled Try different keywords. general fewer your on can try Answers = for expert help with search. Get the
oogle Groups Home Help Sign in Web Images VideoNew News Maps = more raquo Advanced Search Members: users: Join Alerts Create new group = About Searched all groups Your search did not match any Make sure words = are spelled Try different keywords. general fewer your on can try = Answers for expert help with search. Get the latest messages emailed to = Alerts. Terms of Service Privacy
Images VideoNew News Maps more raquo Advanced Search Members: = users: Join Alerts Create new group About Searched all groups Your = search did not match any Make sure words are spelled Try different = keywords. general fewer your on can try Answers for expert help = with
oogle Groups Home Help Sign in Web Images VideoNew News Maps = more raquo Advanced Search Members: users: Join Alerts Create new group = About Searched all groups Your search did not match any Make sure words = are spelled Try different keywords. general fewer your on can try = Answers for expert help with search. Get the latest messages emailed to = Alerts. Terms of Service Privacy Policy copy
Home Help Sign in Web Images VideoNew News Maps more raquo = Advanced Search Members: users: Join Alerts Create new group About = Searched all groups Your search did not match any Make sure words are = spelled Try different keywords. general fewer
Your search did not match any Make sure words are spelled Try = different keywords. general fewer your on can try Answers for expert = help with search. Get the latest messages emailed to Alerts. Terms of = Service Privacy
group About Searched all groups Your search did not match = any
------=_NextPart_001_0005_01C6E0D7.2B496AA0-- ------=_NextPart_000_0004_01C6E0D7.2B496AA0 Content-Type: image/gif; name="not.gif" Content-Transfer-Encoding: base64 Content-ID: <000301c6e0c6$67c09aa0$eabc1453@mariusz> R0lGODlhAAJIAocAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAQAAAALAAAAAAAAkgCBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/AqEBHky4sOHDiBMrXsy4sePHkCNLnky5suXL mDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGNjhFRxhOzbuHPr3s27t+/fwIMLH96WEPHj yJMrX868ufPn0KNLn069uvXr2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djy59Pv779 +/jz69/Pv7///wDO9E2ABC40YIEIGnRgggz+s2CDCD4IIYESTghghRZmqOGGHHbo4Ycghiji iCSWaOKJKKao4oostujiizDGKOOMNG41Ro045qjjjjz26OOPQAYp5JBEFmnkkUgmqeSSTDbp 5JNQRinllFRWaeWVWGap5ZZcdunll2CGKeaYZJZp5plopqnmmmy26eabcMY51jly1mnnnXjm qeeeMeXD55+ABirooIQWauihiCaq6KJeksPoo5BGKumklFZq6aWYZqrpppx26umnoIYq6qg9 GkHqqaimquqqrLbq6qv/sMYq66x/wkHrc6bequuuvPbq66/ATndDsHIWQ+yxyB7kaLLMNuvs s9BKR2e01FZr7bXYZqvtttx26+234IYr7rg/XkLuudCpgu667Lbr7rvwxivvvPTWa++9+IL0 Q7427csvTf7+K1PAAsNEcMEuHYwwSwovrFLDDqMEMY7jRGzxxRhnnFU0Gnfs8ccghyzyyCSX bPLJKKes8sost+zyyzDHLPPMa8VC80Ox2HxzQzrvzFDPPieUM5W2Hgd00AgdjfTSTDft9NNQ 87RIglpEbfXVWGet9dZcd71nIV6HLfbYZJdt9tlop6322my37fbbcFdKQNx012333Xjnrffe /nz3/a0Ffgcu+OCEW8mx1odnNoygiWPdOFFVjPu41ZNHXTnUlz+deeGcd+65Sex8DiwFopdu +umop646uyWs7vrrsMcu++y012777bjnrntsQ+zu++/Afwt28MQXb/zxyCev/PLMN+/889BH L/301Fdv/fXYZx+0ANp37/2kq3wv/vjkl2/++einr/76kZLC/vvwxy///PTXXxE99uev//78 9+///wAMoAAHSMACGvCACEygAhfIQO8IoYEgaQEEJ0jBClrwghjMoAbxVokNevCDIAwhYaIg whKa8IQoTKEKV8jCFrrwhdRJhQxnuLVUwPCGCqwFDnfIwx768IdAoAyiEA3VuiEa8YhIdFMF srZErDXxak+0WhSjNkWoVfFpV3RaFpu2RaZ10Tlz0FoYg/IIiMwtidlLARrXyMY29s8Qboyj HOdIxzra8Y44uYDW9IjHPvrxY+HIWiCxNsirFdJqh/yjIhfJyEY68pFWsiFn1ADJSlrykpjM pCY3yckG8qCToAxleKYgylKa8pSoTKUqV8nKVrrylbCMpSxpFxAAIfkEABgAAAAsAAAAAAAC SAIHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pc ybKly5cwY8qcSbOmzZs4c+rcybOnz59AgwodSrSo0aNIkypdyrSp06dQo0qdSrWq1atYV7LK yrWr169gw4odS7as2bNo06pdy7at27dw48qdS7eu3bt48+rdy7ev37+AAwseTLiw4cOIEyte zLix48eQI0ueTLmy5cuYM2vezLmz58+gQ4seTbq06dOoU6tezbq169ewY8ueTbu27du4c+t+ i2O379/AgwsfTry48eN5DyBfbveAcubQ4z6PTp2t8+rY1U7Pzn3s9e7gw/5uD0++vPnz6NOr X8++vfv38OPLn0+/vv37+PPr38+/v///AAYo4IAEFmjggQgmqOCCDDbo4IMQRijhTsZMaOGF j+WD4YYcdujhhyCGyNwcGhEi4okopqjiiiy26OKLMMYo44w01mjjjTjmqOOOPPbo449ABink kEQWaeSRSCap5JJMNunkk1BGKeWUVFZp5ZVYZqnlllx26eWXBuoB5phklmnmmWimqeaabLbp 5ptwxinnnIGRQ+edeOap55589unnn4AGKuigaQJB6KGIJqrooow26uijkEYq6aSUVmrppTB9 gqlhn3Sq6aaBefopqKSWauqpqKaq6qpLFsPqq/+wxirrZCDMauutuOaq66689urrr8AGK+yw V6FCrFrGHotWssqaxWyzZD0L7bTUVmvttdhmq+223EI3QrfghivuuOSWa+656Karbl31rOvu u24GAO+89NbLGQf25qvvvvz26++/AAcs8MAEF2zwwQgnrPDCDDf8oQQORyzxxBSH9k3FGGes carybHxSxx6XBHJ4iIRs8skop6zyyiy37PLLMMcs88w012zzzTjnrPPOPPfs8880LgI0ao0M bfTRSCet9NJMN+3001BHLfXUVFdt9dVYZ6311lx37fXXYIct9thkl2322WinrfbabLft9ttw xy333HR3VUfdeOet997+fPft99+ABy744ITfhUfhiCeu+OJHosP445BHjhEzkjfmeOWYZz6g BZp37vnnoP9VTeikl2766ainrvrqBFbA+uuwxy777LTXbvvtuOeu++689+7778AHL/zwxBdv /PHIJ1+x0MpDO0Tzi8fipRDQV2/99dhnr/2dAmzv/ffghy/++OSXb/756Kev/vrst+/+pBC/ j7w28tfvvQv256+/k1hEyYfT/+PPPFwUQKYVcGkH3J8CF8jABgZqG03bBgS1hYGsTBBbGMig A89VC6PV4oMgBOEGR0jCEprwhChMoQpvw48VuvCFMIyhDE8zjhna8IY4zKEO/eOEHfrwh0CG DKIQh0jEIhrxiEhMohKXyMQmOvGJUIyiFKdIxSpasWb0uKIWt+gXdnDxi7ErBBjHSMYymvGM h0kCGtfIxja68Y1wRKEh4kjHOtrxLpy7ox5Z5ok9dgYSfgykIAdJyEIy6hCGTKQiF8nIL+XB aY9sWiSZNsmlVVJpl0xaJpG2yUZ68pOFCQgAIfkEAAoAAAAsAAAAAAACSAIHCP4A/wkcSLCg wYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOm zZs4c+rcybOnz59AgwodSrSo0aNIkyqVOGOp06dQo0qdSrWq1atYs2rdyrWr169gw4odS7as 2bNo06pdy7at27dw48qdS7eu3bt48+rdy7ev37+AAwseTLiw4cOIEytezLix48eQI0ueTLmy 5cuYM2vezLmz58+gQ4sezdcB6dOoU6tezbq169ewY8ueTbu27du4c+vezbu379/Ag+dOIry4 8ePIkytfzry58+fQo0vPaWG69bPVr2sXm327964Wuv5/H0++vPnz6NOrX8++vfueDN7Ln0+/ vv37+PPr38+/v///AAYo4IAEFmjggbmJguCCDDbo4IMQRijhhBRWaOGFGEb4S4YcdujhhyCG KOKIJJZo4okopqjiiiy26OKLMMYo44w01mjjjTjmqOOOPPbo449ABinkkEQWaeSRSCap5JJM Nunkk1BGKeWUVFZp5ZVYZqnlllx26eWXYIYp5phklmnmmWimqeZzJ6zp5oqovKlanHKiRmed pN2J55589inbO34GKuigut1C6KGIJqrooow26uijkEYq6aSU1rdJpZBdiqljmm7KWKeeKgbq YF6EStCophq2Caqpturqq/+wxqrVEbJKhMhbtNYKWK66+sVrr8AGK+ywxBZrrF3YHKvsT70s 6+yz0EYr7bTUVmvttdhmq+223Hbr7bfghivuuOSWa+656Kar7rrstuvuu/DGK++89NZr7734 RtdJvvz26++/AAcs8MAEO8tMwQgnrPDCDDfs8MMQRyzxxPeaQvHFGEO1QsYcd+zxxyDfC0PI JJds8skop6zyyrX6wfLLMMcs88w012zzzTjnrPNb/Ozs889ABy30h2AMbfTRSCet9NJMN+30 01BHLfXUVFdt9dVYZ6311lx37fWSrXx9IyxiF9ZG2WinrfbabLft9ttwxy03XUHMbffdeOet 997+fPdtXQF+By744IQXbvjhiCeu+OKMN+7445BHLvnklM/LSuWYZ6755nV6wrlPqnwu+ugh zxPhKBOaDrXqT7PutOuSxdEo7IrFYfvtss++2jmk9+7778AHL/zwxBdv/PHIJ6/88sw37/zz 0Ecv/fTUV2/99dhnLxIN2nfvPZPqyBb29+SXb/756Kev/vrst+/++9IaAP/89NdvP9Pd3K// /vzHJEP/AAygAAdIwAIa8IAITKACF8jABjrwgRCMoARn8gqoVfBpF5ygBs1ShQ168IMgDKEI R0jCEprwhChMoQpXyMIWuvCFMIyhDB+GgBnakCFNuaEOd8jDHvrwh0CRDKIQh0jEIn4NA1BD YhLfcgNpKfFpT2xaFKW4xBzx4i5qKMsUl7ZFI3qReRL4ohjH6EA8kPGMaEyjGtfIxja68Y1w jKMc58gSwNHxjnjMo8QWocc++vGPgAykIAdJyEIa8pBD8wciF8nIJOGikZCMpCR9RgBHUYEy lXxaJp22yaZ1kmmfXFooJ0nKUprylA8KCAAh+QQAyuQAACwAAAAAAAJIAgcI/gD/CRxIsKDB gwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN m/8C6DSoM4DAnkBz7lzYM+dPoEORDhXq0yfPnU2XFj0qFSlBpVGtKkVolerAolifOmVq9GrQ gmfJUl26tuvBsF+nomXr9atZp1jT8lQIti1Ut3Grzh3blyvUu4TpMg0L2K5Yo1PPjsVZdu/P y2Unc43rGDNez5zRhtZM+Grnyp8zm67MejVq0apbY0at+fXp0qtrp54Ne/fk2kKfwr5NfLPx 4LF3s/59enbi41JdK06au7ns58tdUwZ+ffhx53y9/uuuTr58d+3NgeNuTTo87/Hge/duz969 9fHM80tHv5k7c/T/nUeXcrLVJ2B2BMZnV4Cg8VZgTf5ZZp138knI2zAWpudgbBvSx2CHndE3 YYhEkVihY02Zt6GGFEJmmn4onvjWg9w5GCB8KcbIUITywajcepd9qCN/NvEIYImGKXZdjcgF Jplljdko13mIAWngd0q2dZ+NDXI44pVbvrZeYrpNOZx/RmoZpm8rZrgmeHhNCdiYSc5IWZvw ffkedQWiyZeVCaaWppd5Fidimx2qp6KXHArqJov8OWqbmFAmZOVcGRKIo46/Tfddg5L+uJ+C oil6J42ZImnipy3KyGij/3ZOWOh7XBI5YqGB1urjo7VGCqqTuB2aZJZHjgoigr3aumlyK96Y Fo+z3uRhqsWuGiut4ulaabOtCoutsEwCieux05qVLLW+Btlll0JSOG61Qmqq6bWvsilptgaW CyZON6Lbp7HYhrbkkKSK66+LtxobrXSX9lvcpAQzSeW/RxFMKKTnNgmudg4DbCSDYwZbqop0 BnyqX3F2SqZeiAHLlpxqlZpUVSsHZm5di4EVpV+DPfYWdWbmTFrQcpmZVdA9D6ZedEK7jDLL RQ8YM85y1ozznsROvZbNnuV19Mxkcq3WkyeXbfbZaKet9tpst+3223DHLbdDYMxt99145633 3v589+3334AHLvjghBdu+OGIJ6744ow37vjjkEcu+eSUV275RQNkblDmAwjE+ef/cL6Q6J1r TpDoA3V++ueme6556a2zznrqryekuusFyY765rG/7jvors8efOi2rw687MMbDzztwu+u++6h 1+7878f/zrzuqV+++O25Z0/899wfdLvp4X/vvfeqj0+7592bD/76CIVffvqnx9+++dyrjz78 4t///v6bq5//9AdA9hkwegc0IP3wdz4FCtB92jNc+RJIwQk+EHzyq98EMyhADm7wghpcXfs4 6D8GJpCAF7Rg6VJ4Qgq6sIQPRGED/zfD+dXwhRBkySUi2BIVBhCEP/7sXv5CGEQcerCFDFlh 9oaYQxvGsIH6Y+Lo3MfEKvYvhw4MoBVneEMgSjGKMOSh4HxYQguKsIPnkyEEVYi86LUOd8U7 4AJpyEXsyXF5bpSfGU1IRSRuEHrKs18guVhBGH7xemEUI+DICMI9ntGEBHQiIdeYxdwxMpKV rOP9wIhG3gkSf8sTHhbnOMJPZpKRhRxgGlOpSMoYASSoZGVDSKnEPErSiKWcIu+cR8RbshKT kwSiLQn5wSJe0X5SFCYlvShEZTqylXo7YhmnWUA4klCWdMwmEhtZQVKOcpOrJCYzOxnGDDrS jMCk5jWb2MxJPhOaeDskNV0YO3piU5Iy9P8m7DRJzmrGMp18ZF891XlMFi6zi9IsoDzHyU1l wrNvdoTe9ES5RPK9kXgTZd4uNRq8iLpxox29KOzwaDyNku6Nz6MfID8aUj26FHR2vN5Je/e8 klpyfigVqfJ4+dCe+vSnQA2qUIdK1KIa9ahITapSl8rUpjr1qVCNqlSnStWqWvWqWM2qVrfK 1a569atgDatYx0rWspr1rGhNq1rXyta2uvWtcI2rXOdKVzE+oa54Letd88pXsO61r4Dd6l8D S1irDrawiI3qYRPL2MY6tiKVeKxkJ0vWD1hWIJb9AGYvOxDNEiSzoP3sZTWb2c5y1rSeBW1p DVJaz272tJ8VbWj+EzLbf8DWtrBdrWxR69rbqra2BXHta4cb3NHiVrXH1e1xZSvc4LLWuM8l 7XKJm1ze5va3yW0tcnfb3O1Od7mrVa53Yxtd2053ts2VnHDX61zyprazpsVse+f7XvPSt7fk za984XsQ9u5Xv5t9Ln//m976/hfA9j0wgQ1sX//iV8H9vS9r45tgAufXvw3er4MvTGEOK/jB EAbxgAfMWQxXeHImZm96T9zdD0d4vhPmb4Fjm+IXu7fFzlVxiAPsXhibF8cnPjCDRzzjIE+4 xjAe8pAzPGIXx9jCTU6wiKUcZSrTGMAGBjLlMNziFWsZyzauMoSDrGMih1nDFZ5xmYv+LF0Z P/nHMfbyi5F84xXD18RndjKbEYxjOtuZxE3e8JO7jGA0+xjF8mXwlFmMkN/K+dCiPTSIewtc PhuazBZecn0fXGQr35m23RWvpQvtadwqxLfYxXR2zwzc8Zq60bXVcpujm1tA9/e2Y47cexUd 5S8HOs9/7nCnJ51rVXM6zobec7IH3WuGnFbRlTbyo8kc7Ge3V9l27nOPbx1mJUNayLY2Mpzf zBFH3K3Ns34trn3tZEk7RNPWDbe702zsZV/7yqpe9beRTW5Ieznaxb60wC897TEvutluBnOj Lxzrhee7cuimt8J/zeh+/1nQ2064bR8A7A8Pm8nKpjCQv3z/8YyTWtydFnjKvV1vg/vbzAgf OLvBXXFtt9tyeCY5s28ecwFD+ecqdzjQd8zjUi+a1xQX86uZ/Ok5v/zGvT62h4GeckZz+ehT r7p+We5pPEcwxc8Oe4HFjtrirhfXiUY12dV93VuvPdDW/m6sfZvds1P67gsPL3aVy3bq7na4 pEV74FP79rmfvexsH23bB09rtZe38YTHO3X1XmLKWv7ymM+85jfP+c57/vOgD73oR0/60pv+ 9KhPvepXz/rWu/71sI+97GdP+9rb/va27wfud48T3fP+9zTxPfCH/xLhE//4KjE+8pdfEuUz //kgcX5eNQD9wUm/rtSvvvY9kv3t/lfOHmbtvvfHT/7ym39vxhjcOc7P/va7//3wj7/850// +tv//vjPv/73z//++///hYUAADiABFiABniACJiACriADNiADsgRTfCAEjiBFFiBFniBGJiB GriBHNiBHviBIHgnXhCCZsMKJHiCKJiCKriC8MQPLqgQLsgP//CCBBGDMxiDNmiDC5GDNaiD NyiDBYGDQigQPpiDQiiDR4iEQ9iDSGgQRhiENPiDM4gQQEiEPhiEF4GDTKiFA8GDXRiFXwiE SSiFVLiEOriElQMAaggA/8CGNLGGbriGMlGFCVGFdEiEeDiFeniHB2GHdliDX+iEYgiIetiF eTiIhbiH/4RYiGBoiHm4iH7Yh4vIiFZoEXT4h4r4iI3Ih5p4iI9IhYR4iY44OWo4EKVYE3Io EG4YE5yIhZU4iYkYi07oinw4iKKIiJ4Ii3fIiaL4ibwYiKHoipNYi51IEcSoi8L4ibAYi604 ipnIjKS4iqpoE2x4itL4Es04ik3ojNAIg6BIi4m4jb24i8n4jOHIjZKIh+O4g+U4hWd4g0yo juRYjvM4i7KojN1Yh8Eoi9mYOKdoEHCoiqU4kAQZkAJpjQR5kG34j9NojQcZhwmZigv5jwwZ Ef1IiRjJjf3YiseIi+K4jxoJhWCIhq/4jc+IiyaJjx6JiH7YiCpJj+yYjsjojf+OeIXLyDgV KZA6OZELqZMI2ZNAKYc/2YYA6ZNBCZHVCJFHuZMTcZGYaI75mJLLyJK5iIb1qIwoiZI9aJKY qJX2iI4eWZNayJFfiZUxWZZmCYNc6I5S2Tg5uZRwmZBAqZBxGYdFSZd0OZRy+ZYS4ZTOuI0h SZNomYlUeY9XGZXaqI9feYv4CJPgWIyHCZaOiRD+QJaT2ZZQ2ZiL85Z6qZQ92Zl1aYqcKZpK CZqfCYfXaIzt+JQlmZaBWZP2+IeFeZmIWYy+KJO7qJWH2ZGJWZsvOZOvmYvA6ZqQOJh3c30M wZmeCZo/aZoUOZqiGZpLyZcV0YvCeIzB+Yu32ZvwKJz/14mW5GidUaid/MidkpmYgBmWzWid 51me5kmc2DmM7eiW0piUO8mcpbmcnsmUBHGN9imdckmUc2mRRyiISniVRVigfeiSa1mEVriW ImmgYTiWI9mENvmgZPiXLqmSV/iCRiiGHrqhD1qLDDqSP8iFHTqeCgqiucmiXvk4qEmaSJmU NBqjD4maNGqKByGRAoqjASmUBbmK1ClVuhASFxlBR+pTQ9oQqflYRQoSSVo5UdpTS5oQA5l5 T/oRUxo5WwpPBhkRPHp5WcqCoTemZPp5ZnqmnacLaaqmbvqmcBqncjqndFqndnqneOpTr5Cn fNqnfvqngBqogjqohFqohnqo/4jVCIi6qIFzoWdYoBfKqCkhlBMRpjt6pRJhqQBZpQ1hmYSp mZJqEkMpoA6xpKMKpk26qRnhqcEZqpMqpDr6EKYKq5WaqgXBqQzBqsTpqijBowb5pb+KlJta n0EakQgpkcC6n33ZlpHJq6LKkPgZl1YKrXbJk82Zn/eprBbJrPPprCWBrPo5oJ+5EOA6jaF5 rdm6qtx6k976rc75nzKanM8ppOGKrnCZhY85nPfYrhtBr+l6mrcKr7canXgZrQB7r5ZYnJfZ pfwKEfiJrT2qrf/KlAa7l+HalCtaoS0JoWwFfqKXowSbrDPKkwMbpvRakBMJsin7kOLasERl qy4LVv+YGrNmpak0e7M4m7M6u7M8i1Uw27M+W5Ew26R8SazV2K9fWhFJyxI/a6XyurRN2xHV Klc+SrSp+qMkS41E6a8IkZO2Wp8Em6k7GqsUAbYcEbVj67ADe5fmehJmS6pxBa2XOrcTi4pb 258K4Z9OS7ZtC6ZpC7d+u7YagbZsy6RwS7SC+614y7dvhauquriOO6mAO7mL25Cpqbdde5TC mrVkW68oW7mxCq8Ci6wp+58OSZHW+rklS5qFa64ny7qwq5eay7eES1YOmbqWWrQjy7Iry59S e7l5259T27eUm7Vc26OXSrquy7iTC7LO27YqS6tbe7pTK72Va73Ma7rLu73/yGu51fq2xNtW NmqtLau702mXpgkSQhu8nZu4h3u7Nwq5f9u99Au8a0ur+Bu616u/2yu9iAu989u/7kuq1QvA hzvAbAW/1Pq4qnqtXBu5FnG0zAu62Iu57cu4vzq/BdyQAVy/Bpy/F+zB9Hu3yYu6rVu/2EvA H8y/xFu7YuW1xMrAAVuXMwrBSnvAe2vAGCy44AvCibvBJDzAG+zDw+u/K3zA/8vCoKvC8svD RzzCFty4bAgLsBC25Xu1pvu6NhzBQVy8fVvBhWu9x4u+P+y6z5m5nfu936vERyusICzBLQu4 ZEzBTTzE/Eupy3u1VHu5MSzDEIupASqxSGu0tEut/0kcr3hJsjEqtOM7rhOMyJaro4ZcsP6a ozg6oFarxf7ZyEBKyLBrlJ08l+DrVkkbrMqZij+KyuB6xiHhwmp7E65svyvhymhDyw5oyyJB y7IsuXuDy7c8Ezabt5Pcq1tsNr4MtMiczMq8zMxcgInQzCNxzNA8VLkrzdMsq8EczMJ8yVoL x158zR6xtDIsq/cptRnRxo8Mzh8RtedQzL7br+eMxNaszuRKnTZqypxrxfhcrDXKu+68wN9M zxfRyCGbxeVMtzSsyAYtyr5swgEt0BhRzfypyuH7zhSdrukb0SIM0bm8sgabz8Ib0qPqwBcd z0DM0er7uBb7yQyc0cE6zv9lS8IpjNIDPbwFjbD2/MD7yceh28a47KvuTNNdm82LPL5fu8o+ eqO7W7diK9S1fLbc7NSb6c0avcRSfTjaXLbifNVc3dVe/dVgzafzHNaQY7IBO9YQjdTbPDfo PNHpTNbxe6owTc7hfMPe/LZoDc6VLMhWHLjmHNO73MVwzb5yHb+9G8qIvM81GqT+7MJee8KD 3dISa6+yO8MJTdHpa8Pri7d5LdBAatHKetE8Lbw7/cd8Tc49/NaRfbCM/dGaesYjnZ8vzcWp XdGrHZ2FTdmvq9IX29hzXapdjNe3bdm9fdOnqpwKTbEtDcqOPcyJPNy9y7vD2snKS7dVe6yq DND/mg3dsHzOUc3dfDOzXGzV4I03We2wW13e6r3eUSUN7P3e8B3f8l2BPICBZ4BUBDDf+r3f /N3f/v3fAB7gAj7gV5UPBH7gCJ7gCr7gDN7gDv7gEB7hEj7hFF7hFn7hGJ7hGr7hHN7hHv7h IB7iVy0xdeIQWWN784B8J24pJC4wIs4RSLMjLf7iIREVNkMzz6EzRzM2kTHjNP4iKhMcM1Mx yGHjmWHkcfLjEZHkRP4yQ17kU/MXPq7kYhE1TY7kYUM1KUPlE4EdRY7lRB7lT641XK4qV14x T+7kXYPmZ17mLA42WiHlcEEbcP4sU+7mGXHneK4Sh7Hn27Hifh7ogj7o/4Re6CjYB4YOEw4Q E22Q6I7+6JAe6ZI+6ZRe6ZZ+6Zie6ZoeVp0tVB4rp6ucnJlqyEMr3ikd4FE81H4Lx037wOrb 6V6d6miM2iOcw7V+tgKOuaPL6tS7uiwd2Io8u5Eso3r7sCA92MV+u8sJyZaNwCENuQ79vEz8 7HZs23Ct6yxcw98MncIcwkxMxGxb7Q/91djOvTY9tM0L3NP+7dke7jpM1bdd7iIs65wN2V+s w+wOvdwOxPAe7yGsxqxevG391iY88Pl+6/sbscdrqNBwMqGO2axrs6GevcarsgptyVsN1Dh8 qA2PkzExyq/M8VsF8uou8lyV3vUM6ynY8ZtOEv8s3/Ij8fIwDxIyP/MfUfOEo/JcjvKjnupE zcetnsumrsROTfJiy+sJj9B9rfR0Ta5Lf7BSDexHv/Hr7uscLOpN7fSPbNM0DbyIjcriCu/C ne5gu9tGmZenubkgjcVrfNX2S8QSv8szbe7zftCH3e7hu9kyzdVv39N4rOp0bO1tL+7a/r8n a75xbe2e7e5g7LS17cWD/8TnTtonTdj3y/eMv8OOH/iQL8l0f/Dvju9lLMeKv/i0O+39freP /7VhW+1/H/B5XPUF7/njrs7ivMkWT9q6/8m47/eJPLOIXboM7fWT/N3+rfM2n/zKv/zM3/zO //yW9/ckYfxaT95KO6//s67aQr3wuB7GWV/X1s/IZE3v8ez9fg3+6Sz1bm/d6OvTaH+s5s+5 YA/2BYvJ8Kv5xovb4z/rzhvt9H/IAAHg3z+BAwseJIgwocGBBBMqVNhQIgCKFSNCNFhQ4kaO HT1+BBlS5EiSJU2eRJlS5UqWLV2+hBnzo8aNGiM6bGhRoE2GHHXmBIozKE+hF3uCpImTqFGZ TZ0+hRpV6lSqVa2mTBpU6USuXbf67Eh0Yc+lQ7VSRFrzKMajV92+hRtX7ly6bpMypZlXLdmw fdt+Lcv3b1atggEXrptY8WLGjR07FXsQrd6zRRne9Xt46861nb9mNsy24mPSpU2fRj139ETO /qtXZ9w5WXZNtD5rP4S90HXt0b1v3/3NW7hkoamNH0eeXPly5s2dP4ceXfp06tWtX8eeXft2 7t29fwcfXvx48uXNn0efXv169u3dv4cfX/58+vXt38efX/9+/v39/wcwQAEHJLBAAw9EMEEF F2SwQQcfdPALCCeksEILL8QwQw035LBDDz8EMUQRRySxRBNPRDFFFVdksUUXX4QxRhlnpLFG G2/EMUcdd+SxRx9/BDJIIYckskgjj0QyybdYULJJBJl0MsoBoZSySv+otDLL/LDUskv6uPQy zPfAFLNM9cg0M00112SzTTffzE4bOTmSU5uB6sTznzo/2rOjPCXa/tNOPPvUc047AZ2z0EMH HVTRPPt8tKFAPZp0o0MlNfTSOxOtFNFGGRU0UU8ZtZRQUukcVVRFVy11UVX9NJRVRxvd9M9Z M231Vk1rLbRVU0EVtVJQR8XUVl53PVbWX4Nl1thbo0L2Tkml1ZNaPikFdNpNra22214tzVZb TRcNd1xxMfUTXXDX9fbcbdclt11X6YzXWnO5RXbXe+3FVttr39UXX3+9vTdfausNt92D4S1X 3Xgv3TdidRPmlF2JG0Z1YJmiVVhhjjXmdmF32e14326jRXlghA1OWNqA3x25Y41TNnflkE9u uVqTL85Y5pwRxtlfnhEl2Wd7X0Y63ZmL/g6aX5ALZjjqmJd2imOWQWa65JubNlpgp6GeGuie sX1ZZ4xFSnramr1m2WSzVab434+39threWMW9GeQIL7baa7nLhtvrHMOWWygxda6KavH7lrm q1919lWG6zW2csmJ7jfzi/mG+d9iwX4bdHEjF5p0ut/eO/ODLSfU0bMD75lyoT8vVfXEaZ0Y Vl8hzThtpudu6A+TFi8a+JSL5xxl4vMmmO1sgf+WZFPh/rp2z0UW+WFb276Zc67vNOL0xulO 23fsm6/b8+RnPz/3wnsnH3Dv2/8e8atjIl7v1Bl3XPytmWfe/5QGvcSprHJwO57SsPYw+t1u ZtujWtcImD/s/g0tgagT3/wCiEHowY57pzPe+xx4NsIR8CTmE2EEXQa/qdnteStcoAIveD/0 sc9jNrNdAgEoQKm5TXZxa9kEpVZBIPLQfYB74AtjqMIR9q17JPxe/d4HO5gMLYUFrCHB1ve8 +QWxeHVzW/RmGMEunqyMTAxgsMhXxCz+jY1U1FwRLbg0GiLxifpTWxfvp8GJ5WuLNnQiH524 sVO1blmRO1WtasapQspqbOMi1bAgZUhH+qpYlwwU5Fx2OV4pMpPJw50lO+nJz6kqU6EKpSGt JrllpSpVj9LkJWGFyi+WsmKtq6TrRtkrWqJqkhBrlh+B+alQwqk8JjRmMpmDTGU2/9OZz4Rm NKXZoQVM05rXxGY2JUIGbXbzJa1UpCxtiTbM2RKXsvzlzxhZzEPq65R/+mRIJgVOXT7LnLPU WSQht09iInKDsxJnPB1ZzP/F6pfu7Kc505nIV4oSk50c1kB/lavxMaZsVnShAu8YRhdScYt1 3CgR/QfMFM4xe7HD4QWpxzNWAjKLj+MfSQfprsPZTZDSo54W2fdDm8YOOSiMYvrSBckh9i+n GMRiLWP5tMGttKhuzJrz+GdUnGa0hhddIhj1d0Y8NvClGjVcT3/H1Oj5LTVAtd9UOdg3GgYS XB69Hs586NP9KZWFd9So4KaKQ7PKUIVpnSLhvNrVoGE1q/5RRFxS2yhXNqImoh8cK12bFlb4 8TWMHysfExdLr91VDF7OyiBCOao8UyKSTxD04iop2Vdx1tWT67woaKVKsbbCNGreY2Zd0GrE rOKWfsfbISDbSrU/4tWEaoRiYW2nu/OptLnxA+sVjcbSwf0zh7e1GAhRq84SSnZkPD3rUwEr WNytTbGhu+FqBStC85K1omELKW/351yqNra78F1vILf7VMYB1W8UdK99bUvCNP5UvIElb1E9 W13GklGt6XNnZIU629+ydrrJ1aoSs3tUCk+4qigEb179e9XlNnGxAw4bV0ljWLPy1a5DtKN0 yxjjGUv4ssX9qlUxi+MNpvSttP4NsG+jytYN5/i6UAQvffXrUixiNLeKoef29ClbZbHTnteD 5DAlKj8tB7G0qARtL6NMTzFyUsxThmU/00y0XjbUU/QibTpHCU7ZjhlYxyrtm2e5yC7vUpXN KrI3BT1oQhfa0IdGdKIVvWhGN9rRj4Z0pO8jyWAy1J4M/XM+2blOPLd5l/jM8gytLGn+MBDC 931uThfcZDnmFaUcnjBHSY0fD46UwI1N7FGFPOQO321n+Z11fWodVCKrul8UvKmSDyuwXzc1 2PQR7UFV5ypccpXKDcbo+JZqw2Fu+9m0frFqkYtiDC/Msq6mVI3/i9dvg3ur8vSrff2HXhYD +66lm/+edNu9HVJ888Vx7ase573DeiM1cJT1HRz3LZ9hD7uqYvWwjp36tF230cULpzWgX+tP im4r0xufdq4oTVBP17OdRH0vxlW+cpa33OUvh3nMYcQEmUOa5jV/9M1x3mid71zRPfd5ooEe 9AJBguhHR3rSlb50pjfd6U+HetSlPnWqV93qV8d61rW+da533etfB3vYxT52spfd7GdHe9rV vna2t93tb4d73OU+d7rX3e53x3ve9b53vZPD7xzxOzkGEnjC/yPwHzn84P/eEMFv5PCNZ3zh FU94wVP+74uPPOQNT/nMFz7xnf/84AF/+clv3vGYfzxINC+R0LM+9JZffef+QY/5yaOe87Vv veYT7/nLr/7zqT/96WFf+cXvvvikd33jja974Uu+9MSHfO6Pf3vuxF7011f+9RHveO6zPvKA Z3z4xc98w4O/+9onv/XJL372o5797f/+9j1i/fLDv/7q977265///a9//frfvwCMPvPrP/zr vvTjv/uLvwT8vwBUwP6LP9/riAF8wOqbPwIEQAwUwA18P/TrwAw0vQTUPwo8PxH0vv8jQdqr QBAUPfozQBGkPwdcwQm0Pw+8QP87PxXMPhMMwfGjwffbwQxEwRP8wQ4MQhCMvRjEDhfUQCV0 QOZrQAKkQAQMvyjEQQ48QPCLQg+kwpGovAvUwCf/lL/8O0L+I0EIlMEv9MEc5EAnbEEyHEEz /MASPMPye0EWlMAwdMPqYMISlMHm+z0gjEHqc77No70gTMJCVMQJzD1BlEIb3EM09EMhnMQP VL7WA71MlD05LL1HRMM9RMTay8IjVMFRjENK5EFDLERLDI8+hMGQyENJXEAGxD44tL8kBEBS /MFYTEROfEDdK0VZnENcTMU0rMUi/MUs9EU1ZMNjBEZiTEYxtEMh7EM1vMJXRMY/hEblwIaU cEUjhMUcXEVWXMNKhEJPRMJs1ER0PEdpHD1M1MYmHMNyBMNjxEJApEcbfEN3pMUyrMJ9VMdp FMh1BMdsvEMWzI483EZ+/5RGhTTBLuRB34PGLZTAg9RFfVS8XDRIeVzIQTQ/J+xCilRGd5RI jWxCf9xHZrzHfxxIhoxFe0zHStSOayxIVMzHSyRHmGzJnTTGGgTIGVTJ+0vBnBTJh/TFnqxH YcTAixRDhwRCoozIj2zGXKzDp8RGqDTJSYxE6YC9TvTKrky+2cs8OyxFy8O93uO8RgzL2Xs8 s+zK3yM9uIQ+OoRHuUw+RcREeNxEQ0S823u94ePLsxTFtnzJcQzMKjRLq0RMjxTE6LO9RHTM yBS+teS7yrTMy8TMzNTMzeTMzvTMz2SPG/CP1NPLVSRNtyzL6XM9QPTLx1RF6bvE2HxL1JRN av+EzLOcy/lzTUtEvrskTN6DzMTcS+FkQOrjy7xUzbFkRB1EPrB8R6R8PomMzSeUzuFMTuA7 zudwTDxcxov8xoVcwTrcQX8cwjYcCBcIz6gswvFEyKzMyrJ0RjLsRSykyY6kRe7MSTpsP/aM x4zUSnLczv88xXvkzx5cDqcUUIicQ6U00Bk8SoQszxdET4zsTz2UyZpsyS10T5ZMSVv00Ka8 Twr1yWGUSgz1w4oUx5FMQwSlRyrUUOP4RgDdxWJESZUsUCIMQ8WcQjKcUAc9yPz8w6vMUJJg URtNz55sQCPVUfn7USRVvXmkQV40zydV0CP9xOmIUZtkzkPcvmocv9L/TEqpRMS/9LsercuA hM4gZUufDMYTfT0uPEViNE5JnNOq5FBzlMIsXVCM3FH0Y8w+5URrZESRsAPU0NOOBFQ1VdM+ RckgVcLsC8U2NNMKTUX7fNJlHL1LbdH4fE0ZRcpEFVEaVceSvNBnZNNbDD5PJE8fbNQGVY5D zdEa1dSldFAcvVCBVNISnNBVzdE0BUlxBNMwNUD+/NFIXUfx3NNFHdWNFFbfPMqgtElcfURI FYmtfAwW5UnvZFYITVXGTFPuo1YSbYhdNVGTtFQTLUOmlMdp1UlUPEMEldIQ5cgS3dCrjFfq HFAj5FVpvUNrvdZTHVD3A9Fy9dSbvNWVRNFx/83VeazKwlxXhbTTDWVGgf3OJf3Q+izVZ13A l6TV9wTQhkVHfnTBiEUOucRLLl0+4DzZ5QRX2pRMr0TGZ1RZwhTFFW1NU8XNyRTM5zvM58zZ QHzNkd1N3BPL7/tNMl3Ok4XCLVU9u4zO3GTV1CzMvKzUngXNq8VarhuArOXarvXarwXbsBXb +ZjNyHTONT1OqT3bnN1LlpXNlC1NuNRZfx3bNUzXfOXUAszUlYxGvvVTq7xRi33Quj0Jjm1V AR3SwxXSaGXQPZXTeyVclDDcdkVcIw3cdTVKMGxSd6XPyFUJ6ZQ8w8zcCrRGvSxX8Gxbxy3R ofRcyT1Ryh1dYoXd0/9dyuKLyWW90vZkNAwAkMlV1Njl1EjkWF9NVm/dVJJtXSjFViil074N x9GtyUdl3nRF3uTdVp3M0hQE1eyt2hF90c49WOvVzZcNWtFFWqAdvjZFzjat2fKlzKRVzhEV 3/ml3/q13/vF3/zV3/3l3/4VkOWzTvINWvj1z7F8W6YNzDedxbSdU/dNXaJlWzQ1TgDOTgd2 xFZgy0N0WfZVxQWGTeA0YNcU2gDNYIFVEYyt1yQdXNmFThXO3Mst0KKUReOdyikNwcAdXnWF yIpl3Gi8VxIOUTkdXBNh3Q8lXnfFVuMdQmB83ecF0uatVkcVXBcG19U0YjuV4S/NWHtVzI// VdFiJBFjNdgEFdMrZlhwbMd6xVysrNU7fVAxjtUNrNIbzeJafFHfbVwZddHwDZGFxV4LddLG lV5prUE4dsMcfsfH9Fb1M018xd3c9dH27VTchWMYFE4mDtO+rU0wDmMyht52jVQ9ZdWARVVO ZsgWnl0sXtwF/tRSFmIbBmRQXdyGLVZI/OMWQeRTfuWLleIu/clJluPwzeX7PGTDpOLrheBg DuQafmFbXWNBjmUcFWUi9mQgBVlH7tUOdWFSTdYU7thfhV48dskvtt0hjthdLuBnLuJvpV78 ZJFtpMkuBt/uPWNsPNfpVc9bpl10RVZ7pleE9dt5Vl0uLuB+LVjd/y2R9b3NRA5G51NLnU1K nB3g4nxUtU3a6TPNoZ3o+CXL6vzKOt1o9/1LArZaoY1fmu3ovtTojnZo/3Xplz67foDpmabp mrbpm8ZpbIJb9e3NDv7ojDZfhybOn1Xkod5SsLTLtWXglbba9h3q2g3dm2XN6iU1Rl3Pdy1I g15PefZhFQVPpnRKWdXH1IxZrhZSbe3Y363qbF7eu6XUCqVqidVdHeTWHsbUn4RWdPbICDVi d8Y41PXrW67lqVRc321UJZXVzR3rO83rf95rYu5roGQ5wO5lM35rm1VkJ2Zb84XEYM3mAkRf N0ZS0YVimKzRh/5rts5ktx5syP5dw3ZnFsru1UGeUhheXU0129wW1+FtN8rm3oZ8ZMAl0iYG 5w715c/G6q6u5kFs6Tie7clW7b5m7SrO5zZW57nu1jGk7BmGU3YOVeB2btFGaEnb7uQm5Til Z8lGZrc+aPUuXuEu6LLGW3MNSAWlW0dDWpVOZJ8V6QbeWaX+6RL26MVU2ZPmaeijYKFkZI3W 4NwecKImxJyW8Amn8ApXO1Cw8AzX8PpghA338A8H8RAX8REn8RI38RNH8RRX8RVn8RZ38ReH 8RiX8Rmn8RrfkIAAADs= ------=_NextPart_000_0004_01C6E0D7.2B496AA0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Sep 25 13:20:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRu81-0005LC-Bt for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 13:20:25 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRu7z-0000vW-I4 for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 13:20:25 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 8DECC1448064 for ; Mon, 25 Sep 2006 10:20:17 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B9020430094 for ; Mon, 25 Sep 2006 10:17:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A8AD31448056 for ; Mon, 25 Sep 2006 10:17:28 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by hermes.tigertech.net (Postfix) with ESMTP id 05E541448053 for ; Mon, 25 Sep 2006 10:17:25 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id b36so2439177pyb for ; Mon, 25 Sep 2006 10:17:25 -0700 (PDT) Received: by 10.35.93.1 with SMTP id v1mr8724540pyl; Mon, 25 Sep 2006 10:17:23 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Mon, 25 Sep 2006 10:17:18 -0700 (PDT) Message-ID: <26140d940609251017s24fd496agae38c9d348fc561e@mail.gmail.com> Date: Mon, 25 Sep 2006 13:17:18 -0400 From: "Michael Montemurro" To: "Cheng Hong" In-Reply-To: <5F09D220B62F79418461A978CA0921BD012F1879@pslexc01.psl.local> MIME-Version: 1.0 References: <5F09D220B62F79418461A978CA0921BD012F1879@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.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0393294600==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e --===============0393294600== Content-Type: multipart/alternative; boundary="----=_Part_32479_13220579.1159204638075" ------=_Part_32479_13220579.1159204638075 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cheng Hong, In the CAPWAP draft, both wireless data and management frames are treated as CAPWAP data frames. Given that, all CAPWAP data traffic would need to go to the same logical instance of the AC. Cheers, Mike On 9/24/06, Cheng Hong wrote: > > Hi Michael & Michael, > > Sorry if the issue has already been discussed before. Just thinking if the > WTP does not differentiate 802.1X frames from normal data frames, would it > be possible that the 802.1X frames being forwarded to a different AC > instance than the one processing the control/management frames? (in case > different ACs are used to process the control and data channel) Is this > acceptable? > > cheers > > Cheng Hong > > > > > ------------------------------ > *From:* Michael Montemurro [mailto:montemurro.michael@gmail.com] > *Sent:* Sunday, September 24, 2006 3:18 AM > *To:* zhaoyujin 31390 > *Cc:* capwap > *Subject:* Re: [Capwap] This is not need.: Proposed resolution to Issue > 214 -Prioritization of IEEE 802.1X frames > > > Michael, > > Thanks. Is anybody else opinionated on this feature. > > Cheers, > > Mike > > > On 9/23/06, zhaoyujin 31390 wrote: > > > > Firstly, I have some doubt one this suggestion. > > > > 1. If CAPWAP difines like this, AP device must decode the payload frames > > of 802.11 frames. > > 2. Another problem, the 802.1x priority should be implement by 802.11e. > > When station sends 802.11 data frames, it can set 802.11e priority. AP > > should transfer 802.11e to actual CAPWAP packet priority. > > > > So that I think CAPWAP does not need consider the priority of 802.11data frames payload. > > > > Thanks > > Michael > > > > > > > > >Practically speaking, IEEE 802.1X frames should be transmitted at the > > same priority as >IEEE 802.11 Management frames. > > > > > >I will update Section 11.5, rename Quality of Service for IEEE 802.11Control Messages >to "Quality > > >of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL > > frames" and add text to >indicate that IEEE 802.1X frames are sent at a > > higher priority. > > > > > >Cheers, > > > > > >Mike > > > > > > This e-mail and attachments contain confidential information from > > HUAWEI, which is intended only for the person or entity whose address is > > listed above. Any use of the information contained herein in any way > > (including, but not limited to, total or partial disclosure, reproduction, > > or dissemination) by persons other than the intended recipient's) is > > prohibited. If you receive this e-mail in error, please notify the sender by > > phone or email > > immediately and delete it! > > > > > > > > Practically speaking, IEEE 802.1X frames should be transmitted at the > > same priority as IEEE 802.11 Management frames. > > > > I will update Section 11.5, rename Quality of Service for IEEE 802.11Control Messages to "Quality > > of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL > > frames" and add text to indicate that IEEE 802.1X frames are sent at a > > higher priority. > > > > 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 > > > > > > > ------=_Part_32479_13220579.1159204638075 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Cheng Hong,
 
In the CAPWAP draft, both wireless data and management frames are treated as CAPWAP data frames. Given that, all CAPWAP data traffic would need to go to the same logical instance of the AC.
 
Cheers,
 
Mike


 
On 9/24/06, Cheng Hong <Hong.Cheng@sg.panasonic.com> wrote:
Hi Michael & Michael,
 
Sorry if the issue has already been discussed before. Just thinking if the WTP does not differentiate 802.1X frames from normal data frames, would it be possible that the 802.1X frames being forwarded to a different AC instance than the one processing the control/management frames? (in case different ACs are used to process the control and data channel) Is this acceptable?
 
cheers
 
Cheng Hong
 
 
 

From: Michael Montemurro [mailto:montemurro.michael@gmail.com]
Sent: Sunday, September 24, 2006 3:18 AM
To: zhaoyujin 31390
Cc: capwap
Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames

 
Michael,
 
Thanks. Is anybody else opinionated on this feature.
 
Cheers,
 
Mike

 
On 9/23/06, zhaoyujin 31390 <zhaoyujin@huawei.com > wrote:
Firstly, I have some doubt one this suggestion.

1. If CAPWAP difines like this, AP device must decode the payload frames of 802.11 frames.
2. Another problem, the 802.1x priority should be implement by 802.11e. When station sends 802.11 data frames, it can set 802.11e priority. AP should transfer 802.11e to actual CAPWAP packet priority.

So that I think CAPWAP does not need consider the priority of 802.11 data frames payload.

Thanks
Michael



>Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as >IEEE 802.11 Management frames.
>
>I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages >to "Quality
>of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to >indicate that IEEE 802.1X frames are sent at a higher priority.
>
>Cheers,
>
>Mike


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

 

Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as IEEE 802.11 Management frames.
 
I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages to "Quality
of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to indicate that IEEE 802.1X frames are sent at a higher priority.
 
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




------=_Part_32479_13220579.1159204638075-- --===============0393294600== 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 --===============0393294600==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Sep 25 14:38:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRvLV-0007Dy-Su for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 14:38:25 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRvLS-0004YB-B5 for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 14:38:25 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2D9673980A6 for ; Mon, 25 Sep 2006 11:38:17 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 42A4C430094 for ; Mon, 25 Sep 2006 11:37:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D33691448006 for ; Mon, 25 Sep 2006 11:37:09 -0700 (PDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by hermes.tigertech.net (Postfix) with ESMTP id E0BDB1448039 for ; Mon, 25 Sep 2006 11:37:05 -0700 (PDT) Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id k8PIatle027564; Mon, 25 Sep 2006 14:36:57 -0400 (EDT) Date: Mon, 25 Sep 2006 14:36:55 -0400 (EDT) From: "T. Charles Clancy" To: "Peter Nilsson J (LI/EAB)" In-Reply-To: Message-ID: References: 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.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: c54bc2f42d02429833c0ca4b8725abd7 This is a very interesting solution. The AC selects the KeyRSC and performs the 4-way handshake. The WTP sniffs the 4-way handshake traffic and grabs the KeyRSC value and uses it to initialize its own counter. Pat/Bob: Is this how the Cisco implementation works? I have to agree with Saravanan that I've yet to see a technical description of how Cisco implements it. IMHO, this is somewhat hackish, and it would be cleaner to have the AC generate the KeyRSC and include it in the AddMobile message as Behcet suggests. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > I think Saravanan has a point. We did a prototype impelementation of the > protocol a year ago when it was still called LWAPP. The way we solved > this issue then was to let the WTP sniff on all CAPWAP data messages > from the AC and when message 3 of the 4-way handshake or message 1 of > the groupkey handshake was sent the WTP inserted the correct RSC before > sending it off to the supplicant. To avoid the sniffing on all CAPWAP > data messages we would need a mechanism with in CAPWAP to handle these > two messages. > > Peter Nilsson > > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: den 22 september 2006 11:03 > To: Margaret Wasserman > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > Hi Margaret, > > Thank you for reviewing the discussion on this issue. > > The issue here is the working of IEEE 802.11i when the 802.11i > authenticator element is at the AC and the 802.11i crypto element is at > the WTP. Particularly, it is for the 4-way handshake between > authenticator and supplicant. > > Now, the 4-way handshake requires knowing the value of KeyRSC sequence > counter. The KeyRSC helps both authenticator and supplicant keep track > of their exchanges. It serves to protect against threats by tracking > sequential frames. The KeyRSC is maintained at the at the point of > encryption, i.e. just before transmission over the wireless channel. > > In the case of CAPWAP, the 4-way handshake is between the AC > (authenticator) and the wireless station (supplicant). > > The problem arises, when the authenticator is at the AC and the crypto > element (together with KeyRSC) is at the WTP. This is a fairly common > design. Now in this case, the AC starts the 4-way handshake but it does > not know the value of the KeyRSC. The KeyRSC is maintained by the WTP. > > Based on this, the current CAPWAP specification does not allow for a way > to conduct the 4-way handshake with the correct KeyRSC. > > The functionality I would like to see is a way for the authenticator > (AC) to use the correct prevailing value of KeyRSC (maintained by the > WTP) in its 4-way handshake. > > One way to introduce this functionality in to CAPWAP is to have part of > the 4-way handshake be sent from AC to WTP. This will allow the 4-way > handshake to use the correct value of the KeyRSC before being sent to > the wireless station. > > I hope this helps clarify my view on the issue. > > Cheers, > > Saravanan > > > > > > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, September 21, 2006 8:26 PM > To: Saravanan Govindan > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > > > Hi again, > > Okay, I am even more confused than I thought I was... > > Saravanan, you wrote: > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > >> Pat, >> >> The issue here is about how 802.11i exchanges are done when >> authenticator is at the AC and crypto elements are at the WTP. This is >> the requirement. > > And, in response, Pat Calhoun wrote: > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: >> The current specification allows the authenticator to reside in the >> AC, >> while the data packet crypto elements in the WTP. This feature is >> already in the specification. > > Pat's message matches my reading of the specification. > > So, Saravanan, what functionality are you asking for that is not > already supported by the specification? And why do you think it is > necessary? it will not be helpful to my understanding to re-send > your proposal or to cite the requirements document... Please > summarize what functionality you think is missing from the current > specification and why you think that functionality is necessary to > support IEEE 802.11i or any important use case. > > At some point, the chairs may need to make a consensus call on this > issue, and I'd like to understand your view and make sure that it has > been clearly communicated to the WG before we ask the WG to decide on > this issue. > > 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 > _________________________________________________________________ > 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 Sep 25 15:07:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRvnF-0005N8-HR for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 15:07:05 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRvjf-0007by-Ps for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 15:03:29 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 190431448089 for ; Mon, 25 Sep 2006 12:03:20 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 72BE1430094 for ; Mon, 25 Sep 2006 12:02:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5F1FC144808A for ; Mon, 25 Sep 2006 12:02:00 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by hermes.tigertech.net (Postfix) with ESMTP id DDC831448094 for ; Mon, 25 Sep 2006 12:01:57 -0700 (PDT) Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Mon, 25 Sep 2006 12:01:41 -0700 X-Server-Uuid: 450F6D01-B290-425C-84F8-E170B39A25C9 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id F32352AF; Mon, 25 Sep 2006 12:01:40 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id CD2B52AE; Mon, 25 Sep 2006 12:01:40 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EFV61627; Mon, 25 Sep 2006 12:01:36 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 3621E20502; Mon, 25 Sep 2006 12:01:36 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Sep 2006 12:01:34 -0700 Message-ID: <8954613CA6BB3242A1531D916A527A4101DBF44C@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <26140d940609221418u71f5bd1emeffb195905033a27@mail.gmail.com> Thread-Topic: [Capwap] Proposed resolution to Issue 217 - Frame format when wtp encrypts/decrypts Thread-Index: AcbejNL+PYXQLOH0QvmoNk92p3iE1gCRVQFQ From: "Puneet Agarwal" To: "Michael Montemurro" , "capwap" X-TMWD-Spam-Summary: TS=20060925190145; SEV=2.0.2; DFV=A2006092506; IFV=2.0.4,4.0-8; RPD=4.00.0004; ENG=IBF; RPDID=303030312E30413031303230352E34353138323538382E303035432D412D; CAT=NONE; CON=NONE X-MMS-Spam-Filter-ID: A2006092506_4.00.0004_4.0-8 X-WSS-ID: 6906F81F2304024326-01-01 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=HTML_60_70, HTML_MESSAGE X-Spam-Level: Subject: Re: [Capwap] Proposed resolution to Issue 217 - Frame format when wtp encrypts/decrypts X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1472738307==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f This is a multi-part message in MIME format. --===============1472738307== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E0D5.05EEE505" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E0D5.05EEE505 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Michael, =20 I disagree with the disposition. =20 This issue was created because it is unclear what the 802.11 frame from WTP to AC looks like when the WTP is performing 802.11 decryption and 802.11 reassembly. At this point, the original over the air 802.11 frame(s) may have no bearing on the pseudo-802.11 frames (frames that are slightly different from the actual over the air frames) sent by the WTP to the AC. =20 For Frames from WTP to AC (this is a generic list): ------------------------------------------- a) Would these WTP to AC pseudo-802.11 frames have the .11 encryption headers b) Are 802.11 Sequence # fields valid and (how are the sequence control bits set by WTP after reassembly) c) Is Duration ID valid (if so how is it set by WTP) d) What are the other fields(s) that must be ignored by the AC? =20 =20 All one wants to know is what fields must be set correctly by WTP and what fields must be ignored by the AC as they may no longer be valid. =20 Similarly, on the AC-->WTP side, what fields must be set by AC and what fields must be ignored by WTP for these pseudo-802.11 frames. =20 One hopes that CAPWAP can define this to ensure interoperable implementations. =20 Thanks. =20 -Puneet ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Friday, September 22, 2006 2:19 PM To: capwap Subject: [Capwap] Proposed resolution to Issue 217 - Frame format when wtp encrypts/decrypts According to CAPWAP-02, section 11.7 states that the WTP must format the frame according to the IEEE 802.11 specification as described in the IEEE 802.11 (1999) standard.=20 =20 If that is the case, the WTP would transmit the frame to the AC in the same IEEE 802.11 frame format. An AC would use the frame format described in the IEEE 802.11 specification to transmit a frame to the WTP. The WTP would then encrypt the frame and transmit it over the wireless network to the destination.=20 =20 I propose that we do not change CAPWAP to resolve this issue. =20 Cheers, =20 Mike ------_=_NextPart_001_01C6E0D5.05EEE505 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Hi Michael,
 
I disagree with the = disposition.
 
This issue was created because it is unclear = what the=20 802.11 frame from WTP to AC looks like when the WTP is performing 802.11 = decryption and 802.11 reassembly. At this point, the original over the = air=20 802.11 frame(s) may have no bearing on  the pseudo-802.11 frames = (frames=20 that are slightly different from the actual over the air frames) sent by = the WTP=20 to the AC.
 
For Frames from WTP to AC (this is a generic=20 list):
-------------------------------------------
a) Would these WTP to AC pseudo-802.11 frames = have the .11=20 encryption headers
b) Are 802.11 Sequence # fields valid and (how = are the=20 sequence control bits set by WTP after reassembly)
c) Is Duration ID valid (if so how is it set by = WTP)
d) What are the other  fields(s) that must = be ignored=20 by the AC?
 
 
All one wants to know is what fields must be = set correctly=20 by WTP and what fields must be ignored by the AC as they may no longer = be=20 valid.
 
Similarly, on the AC-->WTP side, what fields = must be set=20 by AC and what fields must be ignored by WTP for these pseudo-802.11=20 frames.
 
One hopes that CAPWAP can define this to ensure = interoperable implementations.
 
Thanks.
 
-Puneet

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Friday, September = 22,=20 2006 2:19 PM
To: capwap
Subject: [Capwap] Proposed=20 resolution to Issue 217 - Frame format when wtp=20 encrypts/decrypts

According to CAPWAP-02, section 11.7 states that the WTP must = format the=20 frame according to the IEEE 802.11 specification as described in the = IEEE 802.11=20 (1999) standard.
 
If that is the case, the WTP would transmit the frame to the AC in = the same=20 IEEE 802.11 frame format. An AC would use the frame format described in = the IEEE=20 802.11 specification to transmit a frame to the WTP. The WTP would then = encrypt=20 the frame and transmit it over the wireless network to the destination. =
 
I propose that we do not change CAPWAP to resolve this issue.
 
Cheers,
 
Mike
------_=_NextPart_001_01C6E0D5.05EEE505-- --===============1472738307== 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 --===============1472738307==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Sep 25 15:27:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRw73-0006Wu-0T for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 15:27:33 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRw6z-0003nJ-7V for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 15:27:32 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 4BC4814480A1 for ; Mon, 25 Sep 2006 12:27:25 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B7F13430094 for ; Mon, 25 Sep 2006 12:25:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9A21D1448089 for ; Mon, 25 Sep 2006 12:25:52 -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 7259B144805D for ; Mon, 25 Sep 2006 12:25:50 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 25 Sep 2006 12:25:50 -0700 X-IronPort-AV: i="4.09,215,1157353200"; d="scan'208,217"; a="325088567:sNHT54301272" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8PJPnLc012913; Mon, 25 Sep 2006 12:25: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 k8PJPmif002568; Mon, 25 Sep 2006 12:25:49 -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); Mon, 25 Sep 2006 12:25:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Sep 2006 12:25:48 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202876B9F@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Control channel packet classification Thread-Index: AcbFyjcrr70SneUbQKCVjqUJ24/lPwbDiBmQ From: "Pat Calhoun (pacalhou)" To: "Hasan Raza" , X-OriginalArrivalTime: 25 Sep 2006 19:25:48.0869 (UTC) FILETIME=[67FADF50:01C6E0D8] Authentication-Results: sj-dkim-5.cisco.com; header.From=pcalhoun@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_30_40, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Control channel packet classification X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1582260170==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 This is a multi-part message in MIME format. --===============1582260170== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E0D8.67D3B9B5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E0D8.67D3B9B5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hasan, =20 This issue should be clarified in the spec, so I have created issue 224 to track it. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Hasan Raza [mailto:Hasan@sinett.com]=20 Sent: Tuesday, August 22, 2006 2:06 AM To: capwap@frascone.com Subject: [Capwap] Control channel packet classification =09 =09 Hi, =09 I have a basic question regarding the classification of packets exchanged over control channel. It is stated in the draft that AC in Idle state can receive Discovery as well as DTLS clientHello (+other dtls handshake) packets. The clientHello packets are delivered to the SSL layer and Discovery packets are consumed by the CAPWAP. Question is how? The draft assumes some magic way of doing it. Since both of the packets are in plain, and are received on a single udp port, which state/policy/field classifies such packets from one another? Theoretically speaking, WTP can send a discovery packet which is also a valid clientHello packet! Now AC would respond with a discovery response or a clientHello reponse? =09 =09 In thread http://lists.frascone.com/pipermail/capwap/msg03035.html, Pat talks about the negotiated policy for the appropriate treatment of the received packets. That may mean, if the AC is in join onwards state, it can be assumed that AC will only receive encrypted packets. Though this policy can work, but there would be exceptions in which WTP dies and comes back with a discovery packet. AC still being in join+ state, the received packets will be delivered to the SSL layer. Assumptions can be made here that SSL would discard non-dtls packets and with timeouts in picture, WTP and AC would eventually reach a consensus. But is this ok to assume? =09 In the same thread, Perkins suggested the mux header approach for control channel, but it was not acknowledged? Is there some other hidden mechanism for the classification? Or there is some basic point which I miss here? =09 =09 Thanks Hasan =09 ------_=_NextPart_001_01C6E0D8.67D3B9B5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Control channel packet classification
Hasan,
 
This=20 issue should be clarified in the spec, so I have created issue 224 to = track=20 it.
 

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

 

From: Hasan Raza = [mailto:Hasan@sinett.com]=20
Sent: Tuesday, August 22, 2006 2:06 AM
To:=20 capwap@frascone.com
Subject: [Capwap] Control channel packet = classification


Hi,

I have a basic question regarding the=20 classification of packets exchanged over
control channel. It is = stated in=20 the draft that AC in Idle state can receive
Discovery as well as = DTLS=20 clientHello (+other dtls handshake) packets. The
clientHello = packets are=20 delivered to the SSL layer and Discovery packets are
consumed by = the=20 CAPWAP. Question is how? The draft assumes some magic
way of doing = it.=20 Since both of the packets are in plain, and are received on
a = single udp=20 port, which state/policy/field classifies such packets from = one
another?=20 Theoretically speaking, WTP can send a discovery packet which = is
also a=20 valid clientHello packet! Now AC would respond with a = discovery
response or=20 a clientHello reponse?


In thread http://= lists.frascone.com/pipermail/capwap/msg03035.html,=20 Pat talks about
the negotiated policy for the appropriate treatment = of the=20 received packets. That may
mean, if the AC is in join onwards = state, it can=20 be assumed that AC will only receive
encrypted packets. Though this = policy=20 can work, but there would be exceptions in
which WTP dies and comes = back=20 with a discovery packet. AC still being in join+
state, the = received=20 packets will be delivered to the SSL layer. Assumptions can be
made = here=20 that SSL would discard non-dtls packets and with timeouts in picture,=20 WTP
and AC would eventually reach a consensus. But is this ok to=20 assume?

In the same thread, Perkins suggested the mux header = approach=20 for control channel,
but it was not acknowledged? Is there some = other=20 hidden mechanism for the
classification? Or there is some basic = point which=20 I miss=20 here?


Thanks
Hasan

------_=_NextPart_001_01C6E0D8.67D3B9B5-- --===============1582260170== 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 --===============1582260170==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Sep 25 15:39:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRwJ0-00067m-TM for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 15:39:54 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRwIz-0007Hd-0W for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 15:39:54 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id C24541448085 for ; Mon, 25 Sep 2006 12:39:48 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 88173430094 for ; Mon, 25 Sep 2006 12:35:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E4137398078 for ; Mon, 25 Sep 2006 12:35:31 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7E6B2398070 for ; Mon, 25 Sep 2006 12:35:27 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 25 Sep 2006 12:35:27 -0700 X-IronPort-AV: i="4.09,215,1157353200"; d="scan'208,217"; a="325091642:sNHT68260100" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8PJZR6i016622; Mon, 25 Sep 2006 12:35:27 -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 k8PJZQML024978; Mon, 25 Sep 2006 12:35:27 -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); Mon, 25 Sep 2006 12:35:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Sep 2006 12:35:25 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202876BAF@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Editorial - WTP Event Request Thread-Index: AcbKUWJN8WmxKk+XRnO8RxdQKdbKtQAFiISQABg08cAFhEyFEA== From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , "sujay" , "Saravanan Govindan" , X-OriginalArrivalTime: 25 Sep 2006 19:35:26.0406 (UTC) FILETIME=[C0380660:01C6E0D9] Authentication-Results: sj-dkim-7.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: Subject: Re: [Capwap] Editorial - WTP Event Request X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0099053665==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: db284e046c8702920c1c6125bc4d0b7a This is a multi-part message in MIME format. --===============0099053665== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E0D9.C01BEBEB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E0D9.C01BEBEB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have created issue 225 to track this request. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Pat Calhoun (pacalhou)=20 Sent: Monday, August 28, 2006 10:36 AM To: sujay; Saravanan Govindan; capwap@frascone.com Subject: Re: [Capwap] Editorial - WTP Event Request =09 =09 I believe the quoted text is the agreed upon text. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: sujay [mailto:sujayg@huawei.com]=20 Sent: Sunday, August 27, 2006 11:18 PM To: 'Saravanan Govindan'; capwap@frascone.com Subject: Re: [Capwap] Editorial - WTP Event Request =09 =09 Saravanan, =20 =20 "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)." =20 As the understanding is, arrival of *any* authenticated control message obviates the need for an 'echo request' message, to keep up the neighbour as up. I wouldn't prefer the last statement..viz.. "In cases where regular CAPWAP control messages are not exchanged, explicit keep alive is used (see Section 7)." This kind of sounds making the keep alive and control message usage mutually exclusive. Could we put more simpler, " CAPWAP control messages MAY/SHOULD be treated equivalent to an Echo request message=20 received(See Section 7)" , Again noting; WTP event request message is just one of those possible control messages. Regds, Sujay G My Location; =09 http://maps.google.com/maps?ll=3D14.626109,76.959229&spn=3D4.724852,7.525= 085 &t=3Dh&hl=3Den =09 =09 This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!=20 =20 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Monday, August 28, 2006 8:54 AM To: capwap@frascone.com Subject: [Capwap] Editorial - WTP Event Request =09 =09 All, =20 This is a follow-up on an earlier thread; =20 http://lists.frascone.com/pipermail/capwap/msg03208.html =20 Is the proposal ok for the next draft?=20 =20 Cheers, =09 Saravanan ------_=_NextPart_001_01C6E0D9.C01BEBEB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have=20 created issue 225 to track this request.
 

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

 

From: Pat Calhoun (pacalhou) =
Sent:=20 Monday, August 28, 2006 10:36 AM
To: sujay; Saravanan = Govindan;=20 capwap@frascone.com
Subject: Re: [Capwap] Editorial - WTP = Event=20 Request

I=20 believe the quoted text is the agreed upon text.
 

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

 

From: sujay = [mailto:sujayg@huawei.com]=20
Sent: Sunday, August 27, 2006 11:18 PM
To: = 'Saravanan=20 Govindan'; capwap@frascone.com
Subject: Re: [Capwap] = Editorial -=20 WTP Event Request

Saravanan,
 
<snip> 
"The exchange of a CAPWAP control = message=20 serves as an implicit keep
alive mechanism for the WTP. The = arrival of a=20 CAPWAP control message at
the AC indicates the WTP is = operational. In=20 cases where regular CAPWAP
control messages are not exchanged, = explicit=20 keep alive is used (see
Section 7)."<snip/>
 
As the understanding is, = arrival of=20 *any* authenticated control message = obviates
the need for an 'echo = request'=20 message, to keep up the neighbour as up.
 I wouldn't prefer = the last=20 statement..viz..
"In cases where regular = CAPWAP control=20 messages are not exchanged, explicit keep alive is used = (see
Section=20 7)."
This kind of sounds making = the keep=20 alive and control message usage mutually exclusive. Could we=20 put
more simpler, " CAPWAP = control=20 messages MAY/SHOULD  be treated equivalent to an Echo request = message=20
received(See Section 7)"=20 ,
Again noting; WTP event = request=20 message is just one of those possible control=20 messages.
Regds,
Sujay G
My Location;
http://maps.google.com/maps?ll=3D1=
4.626109,76.959229&spn=3D4.724852,7.525085&t=3Dh&hl=3Den<=
BR>

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

From: Saravanan Govindan=20 [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: = Monday, August=20 28, 2006 8:54 AM
To: = capwap@frascone.com
Subject:=20 [Capwap] Editorial - WTP Event Request

All,

 

This is a follow-up on = an=20 earlier thread;

 

http://= lists.frascone.com/pipermail/capwap/msg03208.html

 

Is the proposal ok for = the next=20 draft?

 

Cheers,


Saravanan

------_=_NextPart_001_01C6E0D9.C01BEBEB-- --===============0099053665== 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 --===============0099053665==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Sep 25 20:04:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS0R9-0007xE-P0 for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 20:04:35 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS0Ju-0007Bs-CN for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 19:57:10 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4F07A398088 for ; Mon, 25 Sep 2006 16:56:57 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 78BF5430094 for ; Mon, 25 Sep 2006 16:56:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 58D0D144805D for ; Mon, 25 Sep 2006 16:56:13 -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 225F91448028 for ; Mon, 25 Sep 2006 16:56:11 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so2255530pyu for ; Mon, 25 Sep 2006 16:56:11 -0700 (PDT) Received: by 10.35.126.7 with SMTP id d7mr186631pyn; Mon, 25 Sep 2006 16:56:10 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Mon, 25 Sep 2006 16:56:10 -0700 (PDT) Message-ID: <26140d940609251656o27188f93icc89deff65e6b559@mail.gmail.com> Date: Mon, 25 Sep 2006 19:56:10 -0400 From: "Michael Montemurro" To: "Puneet Agarwal" In-Reply-To: <8954613CA6BB3242A1531D916A527A4101DBF44C@NT-SJCA-0751.brcm.ad.broadcom.com> MIME-Version: 1.0 References: <26140d940609221418u71f5bd1emeffb195905033a27@mail.gmail.com> <8954613CA6BB3242A1531D916A527A4101DBF44C@NT-SJCA-0751.brcm.ad.broadcom.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.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed resolution to Issue 217 - Frame format when wtp encrypts/decrypts X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1101041788==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 --===============1101041788== Content-Type: multipart/alternative; boundary="----=_Part_39801_14604179.1159228570847" ------=_Part_39801_14604179.1159228570847 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Puneet, I'm perfectly happy to add clarifying text. What do you want me to add? How do you think it should work? Cheers, Mike On 9/25/06, Puneet Agarwal wrote: > > Hi Michael, > > I disagree with the disposition. > > This issue was created because it is unclear what the 802.11 frame from > WTP to AC looks like when the WTP is performing 802.11 decryption and > 802.11 reassembly. At this point, the original over the air 802.11frame(s) may have no bearing on the > pseudo-802.11 frames (frames that are slightly different from the actual > over the air frames) sent by the WTP to the AC. > > For Frames from WTP to AC (this is a generic list): > ------------------------------------------- > a) Would these WTP to AC pseudo-802.11 frames have the .11 encryption > headers > b) Are 802.11 Sequence # fields valid and (how are the sequence control > bits set by WTP after reassembly) > c) Is Duration ID valid (if so how is it set by WTP) > d) What are the other fields(s) that must be ignored by the AC? > > > All one wants to know is what fields must be set correctly by WTP and what > fields must be ignored by the AC as they may no longer be valid. > > Similarly, on the AC-->WTP side, what fields must be set by AC and what > fields must be ignored by WTP for these pseudo-802.11 frames. > > One hopes that CAPWAP can define this to ensure interoperable > implementations. > > Thanks. > > -Puneet > > ------------------------------ > *From:* Michael Montemurro [mailto:montemurro.michael@gmail.com] > *Sent:* Friday, September 22, 2006 2:19 PM > *To:* capwap > *Subject:* [Capwap] Proposed resolution to Issue 217 - Frame format when > wtp encrypts/decrypts > > > According to CAPWAP-02, section 11.7 states that the WTP must format the > frame according to the IEEE 802.11 specification as described in the IEEE > 802.11 (1999) standard. > > If that is the case, the WTP would transmit the frame to the AC in the > same IEEE 802.11 frame format. An AC would use the frame format described > in the IEEE 802.11 specification to transmit a frame to the WTP. The WTP > would then encrypt the frame and transmit it over the wireless network to > the destination. > > I propose that we do not change CAPWAP to resolve this issue. > > Cheers, > > Mike > ------=_Part_39801_14604179.1159228570847 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Puneet,
 
I'm perfectly happy to add clarifying text. What do you want me to add? How do you think it should work?
 
Cheers,
 
Mike

 
On 9/25/06, Puneet Agarwal <pagarwal@broadcom.com> wrote:
Hi Michael,
 
I disagree with the disposition.
 
This issue was created because it is unclear what the 802.11 frame from WTP to AC looks like when the WTP is performing 802.11 decryption and 802.11 reassembly. At this point, the original over the air 802.11 frame(s) may have no bearing on  the pseudo-802.11 frames (frames that are slightly different from the actual over the air frames) sent by the WTP to the AC.
 
For Frames from WTP to AC (this is a generic list):
-------------------------------------------
a) Would these WTP to AC pseudo-802.11 frames have the .11 encryption headers
b) Are 802.11 Sequence # fields valid and (how are the sequence control bits set by WTP after reassembly)
c) Is Duration ID valid (if so how is it set by WTP)
d) What are the other  fields(s) that must be ignored by the AC?
 
 
All one wants to know is what fields must be set correctly by WTP and what fields must be ignored by the AC as they may no longer be valid.
 
Similarly, on the AC-->WTP side, what fields must be set by AC and what fields must be ignored by WTP for these pseudo-802.11 frames.
 
One hopes that CAPWAP can define this to ensure interoperable implementations.
 
Thanks.
 
-Puneet

From: Michael Montemurro [mailto:montemurro.michael@gmail.com]
Sent: Friday, September 22, 2006 2:19 PM
To: capwap
Subject: [Capwap] Proposed resolution to Issue 217 - Frame format when wtp encrypts/decrypts

 
According to CAPWAP-02, section 11.7 states that the WTP must format the frame according to the IEEE 802.11 specification as described in the IEEE 802.11 (1999) standard.
 
If that is the case, the WTP would transmit the frame to the AC in the same IEEE 802.11 frame format. An AC would use the frame format described in the IEEE 802.11 specification to transmit a frame to the WTP. The WTP would then encrypt the frame and transmit it over the wireless network to the destination.
 
I propose that we do not change CAPWAP to resolve this issue.
 
Cheers,
 
Mike

------=_Part_39801_14604179.1159228570847-- --===============1101041788== 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 --===============1101041788==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Sep 25 21:24:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS1gv-0003e5-6p for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 21:24:57 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS1gs-0002aL-A6 for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 21:24:57 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id E34C7144800F for ; Mon, 25 Sep 2006 18:24:49 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9FEAD430094 for ; Mon, 25 Sep 2006 18:22:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 89C9E1448028 for ; Mon, 25 Sep 2006 18:22:44 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id CE16A144800D for ; Mon, 25 Sep 2006 18:22:42 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id k8Q1Me3I017267; Tue, 26 Sep 2006 10:22:40 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k8Q1MfM28130; Tue, 26 Sep 2006 10:22:41 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with ESMTP id k8Q1MeQ28753; Tue, 26 Sep 2006 10:22:40 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Sep 2006 09:21:38 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F19CF@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames Thread-Index: AcbgxlxW7xtb/X1GRXCaT8rkNryRpgAP231A From: "Cheng Hong" To: "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.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_50_60, HTML_MESSAGE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0626774872==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b5216aa5b0df24d46eaed76d4f65aa31 This is a multi-part message in MIME format. --===============0626774872== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E10A.2225DA11" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E10A.2225DA11 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike, =20 In this case, I tend to agree with the other Michael on the first point. =20 However, on the mapping 802.11e priority back to CAPWAP priority, I am not really sure how that is done. Is it based on 802.11e AC or TID (UP)? For later case, does it mean the WTP need to read into the QoS Control Field? =20 cheers =20 Cheng Hong =20 =20 _____ =20 From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Tuesday, September 26, 2006 1:17 AM To: Cheng Hong Cc: zhaoyujin 31390; capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames Cheng Hong, =20 In the CAPWAP draft, both wireless data and management frames are treated as CAPWAP data frames. Given that, all CAPWAP data traffic would need to go to the same logical instance of the AC. =20 Cheers, =20 Mike =20 On 9/24/06, Cheng Hong wrote:=20 Hi Michael & Michael, =20 Sorry if the issue has already been discussed before. Just thinking if the WTP does not differentiate 802.1X frames from normal data frames, would it be possible that the 802.1X frames being forwarded to a different AC instance than the one processing the control/management frames? (in case different ACs are used to process the control and data channel) Is this acceptable? =20 cheers =20 Cheng Hong =20 =20 =20 _____ =20 From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Sunday, September 24, 2006 3:18 AM To: zhaoyujin 31390 Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames=20 =20 Michael, =20 Thanks. Is anybody else opinionated on this feature.=20 =20 Cheers, =20 Mike =20 On 9/23/06, zhaoyujin 31390 > wrote:=20 Firstly, I have some doubt one this suggestion. 1. If CAPWAP difines like this, AP device must decode the payload frames of 802.11 frames. 2. Another problem, the 802.1x priority should be implement by 802.11e. When station sends 802.11 data frames, it can set 802.11e priority. AP should transfer 802.11e to actual CAPWAP packet priority. So that I think CAPWAP does not need consider the priority of 802.11 data frames payload.=20 Thanks Michael >Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as >IEEE 802.11 Management frames. > >I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages >to "Quality >of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to >indicate that IEEE 802.1X frames are sent at a higher priority. >=20 >Cheers, > >Mike This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email=20 immediately and delete it! =20 Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as IEEE 802.11 Management frames.=20 =20 I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages to "Quality of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to indicate that IEEE 802.1X frames are sent at a higher priority. =20 Cheers, =20 Mike _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap =20 ------_=_NextPart_001_01C6E10A.2225DA11 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Mike,
 
In=20 this case, I tend to agree with the other Michael on the first point.=20
 
However, on the mapping 802.11e priority back to CAPWAP = priority, I=20 am not really sure how that is done. Is it based on 802.11e AC or TID = (UP)? For=20 later case, does it mean the WTP need to read into the QoS Control=20 Field?
 
cheers
 
Cheng=20 Hong
 
 
From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Tuesday, = September 26,=20 2006 1:17 AM
To: Cheng Hong
Cc: zhaoyujin 31390;=20 capwap
Subject: Re: [Capwap] This is not need.: Proposed = resolution=20 to Issue 214 -Prioritization of IEEE 802.1X = frames

Cheng Hong,
 
In the CAPWAP draft, both wireless data and management frames are = treated=20 as CAPWAP data frames. Given that, all CAPWAP data traffic = would=20 need to go to the same logical instance of the AC.
 
Cheers,
 
Mike


 
On 9/24/06, Cheng=20 Hong <Hong.Cheng@sg.panasonic.com>=20 wrote:=20
Hi Michael = &=20 Michael,
 
Sorry if the = issue has=20 already been discussed before. Just thinking if the WTP does not=20 differentiate 802.1X frames from normal data frames, would it be = possible=20 that the 802.1X frames being forwarded to a different AC instance = than the=20 one processing the control/management frames? (in case different ACs = are=20 used to process the control and data channel) Is this=20 acceptable?
 
cheers
 
Cheng=20 Hong
 
 
 

From: Michael Montemurro = [mailto:montemurro.michael@gmail.com]
Sent: = Sunday,=20 September 24, 2006 3:18 AM
To: zhaoyujin = 31390
Cc:=20 capwap
Subject: Re: [Capwap] This is not need.: Proposed = resolution to Issue 214 -Prioritization of IEEE 802.1X frames=20

 
Michael,
 
Thanks. Is anybody else opinionated on this feature.
 
Cheers,
 
Mike

 
On 9/23/06, zhaoyujin 31390 <zhaoyujin@huawei.com=20 > wrote:=20
Firstly, I have some doubt one = this=20 suggestion.

1. If CAPWAP difines like this, AP device = must decode=20 the payload frames of 802.11 frames.
2. Another problem, the = 802.1x=20 priority should be implement by 802.11e. When station sends = 802.11 data=20 frames, it can set 802.11e priority. AP should transfer 802.11e = to=20 actual CAPWAP packet priority.

So that I think CAPWAP = does not=20 need consider the priority of 802.11 data frames payload.=20

Thanks
Michael



>Practically = speaking, IEEE=20 802.1X frames should be transmitted at the same priority as = >IEEE=20 802.11 Management frames.
>
>I will update Section = 11.5,=20 rename Quality of Service for IEEE 802.11 Control Messages = >to=20 "Quality
>of Service for IEEE 802.11 control messages and = IEEE=20 802.1X EAPoL frames" and add text to >indicate that IEEE = 802.1X=20 frames are sent at a higher priority.
>=20
>Cheers,
>
>Mike


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

 

Practically speaking, IEEE 802.1X frames should be = transmitted at=20 the same priority as IEEE 802.11 Management frames.
 
I will update Section 11.5, rename Quality of Service for = IEEE=20 802.11 Control Messages to "Quality
of Service for IEEE = 802.11=20 control messages and IEEE 802.1X EAPoL frames" and add text to = indicate=20 that IEEE 802.1X frames are sent at a higher priority.
 
Cheers,
 
=
Mike

______________________________________________________= ___________
To=20 unsubscribe or modify your subscription options, please = visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20 =




------_=_NextPart_001_01C6E10A.2225DA11-- --===============0626774872== 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 --===============0626774872==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Sep 25 22:22:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS2b2-0005pz-2V for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 22:22:56 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS2ax-0003Wc-SZ for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 22:22:56 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 1FEC4144802F for ; Mon, 25 Sep 2006 19:22:46 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 798D8430094 for ; Mon, 25 Sep 2006 19:21:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6909C39800F for ; Mon, 25 Sep 2006 19:21:42 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by zoidberg.tigertech.net (Postfix) with ESMTP id 42EAC398014 for ; Mon, 25 Sep 2006 19:21:39 -0700 (PDT) Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Mon, 25 Sep 2006 19:21:30 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 9A2C22AE; Mon, 25 Sep 2006 19:21:30 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 5AD6A2AF; Mon, 25 Sep 2006 19:21:30 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EFW31621; Mon, 25 Sep 2006 19:21:26 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 0A10B20501; Mon, 25 Sep 2006 19:21:26 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Sep 2006 19:21:26 -0700 Message-ID: <8954613CA6BB3242A1531D916A527A4101DBF52C@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <26140d940609251656o27188f93icc89deff65e6b559@mail.gmail.com> Thread-Topic: [Capwap] Proposed resolution to Issue 217 - Frame format when wtp encrypts/decrypts Thread-Index: Acbg/jXyz4PAaRbDQrqvu7RNtZTa1QACBkfA From: "Puneet Agarwal" To: "Michael Montemurro" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006092509; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230332E34353138384339432E303031442D412D; ENG=IBF; TS=20060926022133; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006092509_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 690651203889700202-01-01 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.001 tagged_above=-999 required=7 tests=HTML_MESSAGE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed resolution to Issue 217 - Frame format when wtp encrypts/decrypts X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1059414236==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 111b48b3edee1f6fe0a892c95423c18d This is a multi-part message in MIME format. --===============1059414236== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E112.775134F5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E112.775134F5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sure. Here is my take on the solution (the exact wording can be worked out once we agree on the general contents). I am sure the working group will help clarify this further. =20 I assume that there are 2 models supported in CAPWAP Split-MAC for 802.11 DATA frames (note that we will have to fill this up for 802.11 Management frames also at a later time): =20 A) 802.11 encryption and 802.11 fragmentation done at the AC (as well as 802.11 decryption and 802.11 re-assembly at AC).=20 This is the simple case. B) 802.11 encryption and 802.11 fragmentation done at the WTP (as well as 802.11 decryption and 802.11 re-assembly done at WTP). =20 ****** CASE A ****** =20 a1) The WTP forwards the unmodified 802.11 Data frame that it successfully receives over the air to the AC. Question1: Received Sequence numbers are maintained at the AC I assume - is this correct. Is the CAPWAP conforming AC expected to do any sanity checks on the sequence numbers (especially for un-encrypted packets)? =20 a2) The AC sends a fully formed 802.11 DATA frame to the WTP. The WTP is allowed to change the following fields: 11.FrameControl.MoreFrag 11.FrameControl.Retry 11.FrameControl.MoreData 11.Duration Question2: Transmitted Sequence numbers are maintained at the AC or at the WTP? What is the requirement? For .11 fragments one would assume that Transmit sequence number is maintained in the AC (though one can structure it so that either place can work - we need to define some requirements here). =20 ****** CASE B (the more interesting case) ****** In this case the WTP creates a pseudo-802.11 header when sending frames from WTP to AC. =20 b1) For DATA frames sent from the WTP to the AC, the fields MUST be interpreted/processed as follows by the AC: 11.FrameControl.MoreFrag must be set to 0 by WTP (and checked by the AC) 11.FrameControl.Retry must be ignored by the AC 11.FrameControl.Protected Frame must be set to 0 by WTP (and checked by the AC) 11.Duration must be ignored by the AC 11.Sequence Control.Sequence Number should be set to the sequence number of the "over the air" .11 frame(s) 11.Sequence Control.Fragment Number MUST be set to 0 by WTP =20 It is expected that all other .11 header fields are the same as in the received "over the air" .11 frame. =20 Question3: I assume the sequence numbers MUST be maintained by the WTP in this case. Is that correct? =20 b2) For .11 DATA frames sent from the AC to the WTP, the fields MUST be interpreted/processed as follows by the WTP/AC: =20 11.FrameControl.MoreFrag MUST be set to 0 by AC 11.FrameControl.Retry SHOULD be set to 0 by AC 11.FrameControl.Protected Frame MUST be set to 0 by AC 11.Duration must be ignored by the WTP 11.Sequence Control.Sequence Number should be set to 0 by the AC 11.Sequence Control.Fragment Number MUST be set to 0 by WTP =20 =20 It is quite likely that I have missed more than a few cases. It would be great if others can chime in. =20 Thanks. =20 -Puneet =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Monday, September 25, 2006 4:56 PM To: Puneet Agarwal Cc: capwap Subject: Re: [Capwap] Proposed resolution to Issue 217 - Frame format when wtp encrypts/decrypts Puneet, =20 I'm perfectly happy to add clarifying text. What do you want me to add? How do you think it should work? =20 Cheers, =20 Mike =20 On 9/25/06, Puneet Agarwal wrote:=20 Hi Michael, =20 I disagree with the disposition. =20 This issue was created because it is unclear what the 802.11 frame from WTP to AC looks like when the WTP is performing 802.11 decryption and 802.11 reassembly. At this point, the original over the air 802.11 frame(s) may have no bearing on the pseudo-802.11 frames (frames that are slightly different from the actual over the air frames) sent by the WTP to the AC.=20 =20 For Frames from WTP to AC (this is a generic list): ------------------------------------------- a) Would these WTP to AC pseudo-802.11 frames have the .11 encryption headers b) Are 802.11 Sequence # fields valid and (how are the sequence control bits set by WTP after reassembly) c) Is Duration ID valid (if so how is it set by WTP) d) What are the other fields(s) that must be ignored by the AC? =20 =20 All one wants to know is what fields must be set correctly by WTP and what fields must be ignored by the AC as they may no longer be valid.=20 =20 Similarly, on the AC-->WTP side, what fields must be set by AC and what fields must be ignored by WTP for these pseudo-802.11 frames.=20 =20 One hopes that CAPWAP can define this to ensure interoperable implementations. =20 Thanks. =20 -Puneet ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Friday, September 22, 2006 2:19 PM To: capwap Subject: [Capwap] Proposed resolution to Issue 217 - Frame format when wtp encrypts/decrypts =09 =20 =09 According to CAPWAP-02, section 11.7 states that the WTP must format the frame according to the IEEE 802.11 specification as described in the IEEE 802.11 (1999) standard.=20 =20 If that is the case, the WTP would transmit the frame to the AC in the same IEEE 802.11 frame format. An AC would use the frame format described in the IEEE 802.11 specification to transmit a frame to the WTP. The WTP would then encrypt the frame and transmit it over the wireless network to the destination.=20 =20 I propose that we do not change CAPWAP to resolve this issue. =20 Cheers, =20 Mike ------_=_NextPart_001_01C6E112.775134F5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Sure. Here is my take on the solution (the = exact wording=20 can be worked out once we agree on the general contents). I am sure the = working=20 group will help clarify this further.
 
I assume that there are 2 models supported in = CAPWAP=20 Split-MAC for 802.11 DATA frames (note that we will have to fill this up = for=20 802.11 Management frames also at a later time):
 
A) 802.11 encryption and 802.11 fragmentation = done at the=20 AC (as well as 802.11 decryption and 802.11 re-assembly at AC).=20
This is the simple = case.
B) 802.11 encryption and 802.11 = fragmentation=20 done at the WTP (as well as 802.11 decryption and 802.11 re-assembly = done at=20 WTP).
   
****** CASE A ******
 
a1) The WTP forwards the unmodified 802.11 = Data frame=20 that it successfully receives over the air to the = AC.
      Question1: = Received Sequence=20 numbers are maintained at the AC I assume -  is this = correct. Is=20 the CAPWAP conforming AC expected to do any sanity checks on the = sequence=20 numbers (especially for un-encrypted packets)?
 
a2) The AC sends a fully formed 802.11 DATA = frame to the=20 WTP. The WTP is allowed to change the  following=20 fields:
    11.FrameControl.MoreFrag<= /FONT>
    11.FrameControl.Retry<= /FONT>
    11.FrameControl.MoreData
    11.Duration
Question2: = Transmitted=20 Sequence numbers are maintained at the AC or at the WTP? What is the=20 requirement?
For .11 = fragments one would=20 assume that Transmit sequence number is maintained in the AC (though one = can=20 structure it so that either place can work - we need to define some = requirements=20 here).
 
****** CASE B (the more interesting=20 case) ******
In this = case the WTP=20 creates a pseudo-802.11 header when sending frames from WTP to = AC.
 
b1) For = DATA frames sent=20 from the WTP to the AC, the fields MUST be interpreted/processed as = follows by=20 the AC:
    11.FrameControl.MoreFrag = must be set=20 to 0 by WTP (and checked by the AC)
    11.FrameContro= l.Retry=20 must be ignored by the AC
   =20 11.FrameControl.Protected=20 Frame must be set to 0 by WTP (and checked by the=20 AC)
    11.Duration=20 must be ignored by the AC
    11.Sequence Control.Sequence Number should be set to the sequence = number of=20 the "over the air" .11 frame(s)
    11.Sequence Control.Fragment Number MUST be set to 0 by=20 WTP
 
It is = expected that all=20 other .11 header fields are the same as in the received "over the air" = .11=20 frame.
 
Question3: I = assume the=20 sequence numbers MUST be maintained by the WTP in this case. Is that=20 correct?
 
b2) For .11 = DATA frames=20 sent from the AC to the WTP, the fields MUST = be interpreted/processed=20 as follows by the WTP/AC:
 
        11.FrameControl.MoreFrag MUST be set to 0 by=20 AC<= /FONT>
       =20 11.FrameControl.Retry SHOULD be set to 0 by=20 AC<= /DIV>
       &nbs= p;11.FrameControl.Protected Frame MUST be set = to 0 by=20 AC
       &nbs= p;11.Duration=20 must be ignored by the WTP
        = 11.Sequence Control.Sequence Number should be set to 0 by the = AC
        = 11.Sequence Control.Fragment Number MUST be set to 0 by=20 WTP
 
 
It is quite = likely that=20 I have missed more than a few cases. It would be great if others = can chime=20 in.
 
Thanks.
 
-Puneet
    <= /DIV>
From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Monday, September = 25,=20 2006 4:56 PM
To: Puneet Agarwal
Cc:=20 capwap
Subject: Re: [Capwap] Proposed resolution to Issue 217 = - Frame=20 format when wtp encrypts/decrypts

Puneet,
 
I'm perfectly happy to add clarifying text. What do you want me to = add? How=20 do you think it should work?
 
Cheers,
 
Mike

 
On 9/25/06, Puneet=20 Agarwal <pagarwal@broadcom.com> = wrote:=20
Hi=20 Michael,
 
I disagree=20 with the disposition.
 
This issue=20 was created because it is unclear what the 802.11 frame from WTP to AC = looks=20 like when the WTP is performing 802.11 decryption and 802.11 = reassembly. At=20 this point, the original over the air 802.11 frame(s) may have no = bearing on=20  the pseudo-802.11 frames (frames that are slightly different = from the=20 actual over the air frames) sent by the WTP to the AC. =
 
For Frames=20 from WTP to AC (this is a generic list):
-------------------------------------------
a) Would=20 these WTP to AC pseudo-802.11 frames have the .11 encryption=20 headers
b) Are=20 802.11 Sequence # fields valid and (how are the sequence control bits = set by=20 WTP after reassembly)
c) Is=20 Duration ID valid (if so how is it set by WTP)
d) What=20 are the other  fields(s) that must be ignored by the=20 AC?
 
 
All one=20 wants to know is what fields must be set correctly by WTP and what = fields must=20 be ignored by the AC as they may no longer be valid. =
 
Similarly,=20 on the AC-->WTP side, what fields must be set by AC and what fields = must be=20 ignored by WTP for these pseudo-802.11 frames.
 
One hopes=20 that CAPWAP can define this to ensure interoperable=20 implementations.
 
Thanks.
 
-Puneet

From: Michael Montemurro = [mailto:montemurro.michael@gmail.com]
Sent: = Friday,=20 September 22, 2006 2:19 PM
To: capwap
Subject: = [Capwap]=20 Proposed resolution to Issue 217 - Frame format when wtp=20 encrypts/decrypts

 
According to CAPWAP-02, section 11.7 states that the WTP must = format the=20 frame according to the IEEE 802.11 specification as described in the = IEEE=20 802.11 (1999) standard.
 
If that is the case, the WTP would transmit the frame to the AC = in the=20 same IEEE 802.11 frame format. An AC would use the frame format = described in=20 the IEEE 802.11 specification to transmit a frame to the WTP. The WTP = would=20 then encrypt the frame and transmit it over the wireless network to = the=20 destination.
 
I propose that we do not change CAPWAP to resolve this = issue.
 
Cheers,
 
=
Mike

------_=_NextPart_001_01C6E112.775134F5-- --===============1059414236== 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 --===============1059414236==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Sep 25 23:48:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS3w1-0003L2-Lx for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 23:48:41 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS3w0-0008R0-7a for capwap-archive@lists.ietf.org; Mon, 25 Sep 2006 23:48:41 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 3BE20144800F for ; Mon, 25 Sep 2006 20:48:36 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 5F62B430094 for ; Mon, 25 Sep 2006 20:47:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3BDFA39800F for ; Mon, 25 Sep 2006 20:47:40 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [12.129.211.51]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8D2A8398014 for ; Mon, 25 Sep 2006 20:47:36 -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 <0J6600DG1L256O@usaga01-in.huawei.com> for capwap@frascone.com; Mon, 25 Sep 2006 20:44:29 -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 <0J6600CSGL24I2@usaga01-in.huawei.com> for capwap@frascone.com; Mon, 25 Sep 2006 20:44:29 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.18.23.62]) by szxmc01-in.huawei.com (mshttpd); Tue, 26 Sep 2006 08:47:37 +0500 Date: Tue, 26 Sep 2006 08:47:37 +0500 From: zhaoyujin 31390 To: "Pat Calhoun (pacalhou)" Message-id: <2616db92612879.26128792616db9@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-language: zh-CN Content-disposition: inline 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] One issue, please discuss: I suggest some change for "11.9.18. IEEE 802.11 Tx Power" X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 538aad3a3c4f01d8b6a6477ca4248793 Section 11.9.18 has following discripiton, I suggestion some change From "Current Tx Power: This attribute contains the transmit output power in mW." to "Current Tx Power: This attribute contains the transmit output power in 0.1mW." The reason is: normally WLAN will use dbm. The conversion between dbm and mw can not satisfy this TLV requirement. If capwap transimit one mw value, the device can't precise get corresponding dbm. For example 1 dbm<----->1.3mw ----> 1mw 2 dbm<----->1.6mw ----> 2mw 3 dbm<----->2.0mw ----> 2mw This time, if capwap transmits 2 mw, system doesn't know it is 2dbm or 3 dbm. The following is suggestion: For example 1 dbm<----->1.3mw ----> 13mw 2 dbm<----->1.6mw ----> 16mw 3 dbm<----->2.0mw ----> 20mw Thanks Michael > The Tx power message element value is bi-directional. When sent by > the WTP, it contains the current power level of the radio in > question. When sent by the AC, it contains the power level the WTP > MUST adhere to. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Radio ID | Reserved | Current Tx Power | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: 1041 for IEEE 802.11 Tx Power > > Length: 4 > > Radio ID: An 8-bit value representing the radio to configure. > > Reserved: MUST be set to zero > > Current Tx Power: This attribute contains the transmit output power > in mW. This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _________________________________________________________________ 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 Sep 26 12:29:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSFnx-0008NX-AZ for capwap-archive@lists.ietf.org; Tue, 26 Sep 2006 12:29:09 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSFnt-0000gi-DT for capwap-archive@lists.ietf.org; Tue, 26 Sep 2006 12:29:09 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id E6A7343135E for ; Tue, 26 Sep 2006 09:28:53 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D2779430094 for ; Tue, 26 Sep 2006 09:24:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BCA92431295 for ; Tue, 26 Sep 2006 09:24:16 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by hermes.tigertech.net (Postfix) with ESMTP id E69B943127F for ; Tue, 26 Sep 2006 09:24:13 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so2521020pyu for ; Tue, 26 Sep 2006 09:24:13 -0700 (PDT) Received: by 10.35.89.10 with SMTP id r10mr1147672pyl; Tue, 26 Sep 2006 09:24:12 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Tue, 26 Sep 2006 09:24:10 -0700 (PDT) Message-ID: <26140d940609260924r22f01939v6259b821fe94d355@mail.gmail.com> Date: Tue, 26 Sep 2006 12:24:12 -0400 From: "Michael Montemurro" To: "Cheng Hong" In-Reply-To: <5F09D220B62F79418461A978CA0921BD012F19CF@pslexc01.psl.local> MIME-Version: 1.0 References: <5F09D220B62F79418461A978CA0921BD012F19CF@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.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1348122929==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 --===============1348122929== Content-Type: multipart/alternative; boundary="----=_Part_10138_19774466.1159287852607" ------=_Part_10138_19774466.1159287852607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cheng, Thanks for you input. Also, that's a good question. In my opinion, the CAPWAP priority should be based on the TID(UP). Which means yes, the WTP would need to read into the QoS control field. Cheers, Mike On 9/25/06, Cheng Hong wrote: > > Hi Mike, > > In this case, I tend to agree with the other Michael on the first point. > > However, on the mapping 802.11e priority back to CAPWAP priority, I am not > really sure how that is done. Is it based on 802.11e AC or TID (UP)? For > later case, does it mean the WTP need to read into the QoS Control Field? > > cheers > > Cheng Hong > > > > ------------------------------ > *From:* Michael Montemurro [mailto:montemurro.michael@gmail.com] > *Sent:* Tuesday, September 26, 2006 1:17 AM > *To:* Cheng Hong > *Cc:* zhaoyujin 31390; capwap > *Subject:* Re: [Capwap] This is not need.: Proposed resolution to Issue > 214 -Prioritization of IEEE 802.1X frames > > > Cheng Hong, > > In the CAPWAP draft, both wireless data and management frames are treated > as CAPWAP data frames. Given that, all CAPWAP data traffic would need to go > to the same logical instance of the AC. > > Cheers, > > Mike > > > > On 9/24/06, Cheng Hong wrote: > > > > Hi Michael & Michael, > > > > Sorry if the issue has already been discussed before. Just thinking if > > the WTP does not differentiate 802.1X frames from normal data frames, > > would it be possible that the 802.1X frames being forwarded to a > > different AC instance than the one processing the control/management frames? > > (in case different ACs are used to process the control and data channel) Is > > this acceptable? > > > > cheers > > > > Cheng Hong > > > > > > > > > > ------------------------------ > > *From:* Michael Montemurro [mailto:montemurro.michael@gmail.com] > > *Sent:* Sunday, September 24, 2006 3:18 AM > > *To:* zhaoyujin 31390 > > *Cc:* capwap > > *Subject:* Re: [Capwap] This is not need.: Proposed resolution to Issue > > 214 -Prioritization of IEEE 802.1X frames > > > > > > Michael, > > > > Thanks. Is anybody else opinionated on this feature. > > > > Cheers, > > > > Mike > > > > > > On 9/23/06, zhaoyujin 31390 wrote: > > > > > > Firstly, I have some doubt one this suggestion. > > > > > > 1. If CAPWAP difines like this, AP device must decode the payload > > > frames of 802.11 frames. > > > 2. Another problem, the 802.1x priority should be implement by 802.11e. > > > When station sends 802.11 data frames, it can set 802.11e priority. AP > > > should transfer 802.11e to actual CAPWAP packet priority. > > > > > > So that I think CAPWAP does not need consider the priority of 802.11data frames payload. > > > > > > Thanks > > > Michael > > > > > > > > > > > > >Practically speaking, IEEE 802.1X frames should be transmitted at the > > > same priority as >IEEE 802.11 Management frames. > > > > > > > >I will update Section 11.5, rename Quality of Service for IEEE 802.11Control Messages >to "Quality > > > >of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL > > > frames" and add text to >indicate that IEEE 802.1X frames are sent at > > > a higher priority. > > > > > > > >Cheers, > > > > > > > >Mike > > > > > > > > > This e-mail and attachments contain confidential information from > > > HUAWEI, which is intended only for the person or entity whose address is > > > listed above. Any use of the information contained herein in any way > > > (including, but not limited to, total or partial disclosure, reproduction, > > > or dissemination) by persons other than the intended recipient's) is > > > prohibited. If you receive this e-mail in error, please notify the sender by > > > phone or email > > > immediately and delete it! > > > > > > > > > > > > Practically speaking, IEEE 802.1X frames should be transmitted at the > > > same priority as IEEE 802.11 Management frames. > > > > > > I will update Section 11.5, rename Quality of Service for IEEE 802.11Control Messages to "Quality > > > of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL > > > frames" and add text to indicate that IEEE 802.1X frames are sent at a > > > higher priority. > > > > > > 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 > > > > > > > > > > > > ------=_Part_10138_19774466.1159287852607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Cheng,
 
Thanks for you input.
 
Also, that's a good question. In my opinion, the CAPWAP priority should be based on the TID(UP). Which means yes, the WTP would need to read into the QoS control field.
 
Cheers,
 
Mike
 
On 9/25/06, Cheng Hong <Hong.Cheng@sg.panasonic.com> wrote:
Hi Mike,
 
In this case, I tend to agree with the other Michael on the first point.
 
However, on the mapping 802.11e priority back to CAPWAP priority, I am not really sure how that is done. Is it based on 802.11e AC or TID (UP)? For later case, does it mean the WTP need to read into the QoS Control Field?
 
cheers
 
Cheng Hong
 
 
From: Michael Montemurro [mailto:montemurro.michael@gmail.com ]
Sent: Tuesday, September 26, 2006 1:17 AM
To: Cheng Hong
Cc: zhaoyujin 31390; capwap

Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames

 
Cheng Hong,
 
In the CAPWAP draft, both wireless data and management frames are treated as CAPWAP data frames. Given that, all CAPWAP data traffic would need to go to the same logical instance of the AC.
 
Cheers,
 
Mike


 
On 9/24/06, Cheng Hong <Hong.Cheng@sg.panasonic.com > wrote:
Hi Michael & Michael,
 
Sorry if the issue has already been discussed before. Just thinking if the WTP does not differentiate 802.1X frames from normal data frames, would it be possible that the 802.1X frames being forwarded to a different AC instance than the one processing the control/management frames? (in case different ACs are used to process the control and data channel) Is this acceptable?
 
cheers
 
Cheng Hong
 
 
 

From: Michael Montemurro [mailto:montemurro.michael@gmail.com]
Sent: Sunday, September 24, 2006 3:18 AM
To: zhaoyujin 31390
Cc: capwap
Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames

 
Michael,
 
Thanks. Is anybody else opinionated on this feature.
 
Cheers,
 
Mike

 
On 9/23/06, zhaoyujin 31390 <zhaoyujin@huawei.com > wrote:
Firstly, I have some doubt one this suggestion.

1. If CAPWAP difines like this, AP device must decode the payload frames of 802.11 frames.
2. Another problem, the 802.1x priority should be implement by 802.11e. When station sends 802.11 data frames, it can set 802.11e priority. AP should transfer 802.11e to actual CAPWAP packet priority.

So that I think CAPWAP does not need consider the priority of 802.11 data frames payload.

Thanks
Michael



>Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as >IEEE 802.11 Management frames.
>
>I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages >to "Quality
>of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to >indicate that IEEE 802.1X frames are sent at a higher priority.
>
>Cheers,
>
>Mike


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

 

Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as IEEE 802.11 Management frames.
 
I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages to "Quality
of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to indicate that IEEE 802.1X frames are sent at a higher priority.
 
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





------=_Part_10138_19774466.1159287852607-- --===============1348122929== 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 --===============1348122929==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Sep 26 14:33:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSHkF-0006pe-0v for capwap-archive@lists.ietf.org; Tue, 26 Sep 2006 14:33:27 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSHkB-00019i-8Z for capwap-archive@lists.ietf.org; Tue, 26 Sep 2006 14:33:27 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5BC6D398096 for ; Tue, 26 Sep 2006 11:33:20 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4AD95430094 for ; Tue, 26 Sep 2006 11:32:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 31D27398083 for ; Tue, 26 Sep 2006 11:32:07 -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 03D8E398079 for ; Tue, 26 Sep 2006 11:32:01 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 26 Sep 2006 11:32:02 -0700 X-IronPort-AV: i="4.09,221,1157353200"; d="scan'208"; a="343332087:sNHT63132088" 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 k8QIW17q027245; Tue, 26 Sep 2006 11:32:01 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8QIW11E019303; Tue, 26 Sep 2006 11:32:01 -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); Tue, 26 Sep 2006 11:32:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Sep 2006 11:31:59 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC02133714@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: Acbg0apVLhatsbAIQ02cILmAIvbQhAAwcJng From: "Bob O'Hara (boohara)" To: "T. Charles Clancy" , "Peter Nilsson J (LI/EAB)" X-OriginalArrivalTime: 26 Sep 2006 18:32:01.0003 (UTC) FILETIME=[0E6F5BB0:01C6E19A] Authentication-Results: sj-dkim-2.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: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 32029c790f79bd4a84a26bd2915c54b9 Charles, Peter, Below is an expansion of a snippet from a thread on this topic that I sent to the list on July 25, 2006. I think this will be helpful to understand why the exchange that Saranavan is requesting is not necessary. In fact, there are several systems from several manufacturers in the field using precursor protocols to CAPWAP that are Wi-Fi certified for WPA2/802.11i operation using the protocol as it is described below. BTW, this whole discussion is about the KeyRSC for the group key, not the pairwise key. This is so because the WTP and AC both know the initial sequence counter value for the pairwise key, since it has never been used to send a frame. 802.11i requires the first frame sent on a key to use the sequence counter value of 1. See 8.3.2.6 c) and 8.3.3.4.3 c) in 802.11i for this requirement. The same is not true of the group key, i.e., after the WTP begins operation, the AC will not know the value of the sequence counter for the group key when it needs to complete the EAPOL-key handshake with a newly associated STA. However, as you will see from the tutorial below, it is not necessary for the AC and WTP to exchange any information about the group key KeyRSC for the protocol to operate as it is intended. 1. A value for the KeyRSC in the EAPOL-key frame 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. A value of zero in the EAPOL-key frame for the group key will always work. 3. The client STA will use the value of KeyRSC received in the EAPOL-key frame to validate frame using the KeyMIC. 4. The client STA will also set its group key RSC to the value received in KeyRSC, say, zero. 5. The value in the client STA's RSC will be compared against the sequence number in subsequent received frames to identify replay attacks. Any frame received with a sequence counter value within the replay window will be checked to have a valid MIC. If the MIC is not valid, the frame is dropped. 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, if the value is greater than its current RSC value. Only the AP can meet these criteria as the source of a frame received by the STA. 7. Please see item 6, immediately above, for the reason that the AC and WTP do not need to coordinate and exchange the RSC. The only possible attack mode is for the attacker to send frames to the client STA between the time of the EAPOL-key frame and the first frame encrypted with the group key. During this time, the client will receive the frame and proceed to validate its MIC. This is a potential attack against the STA resources. But, the MIC validation is done in the STA's 802.11 chip and consumes no more resources than receiving any other frame. Thus, the attack does not actually consume any STA resources beyond those of receiving a frame. This attack is not unique to the use of the value zero for the KeyRSC, either. The same attack is available to an attacker at any other time, as well. It is no more nor less effective at either time. For these reasons, the protocol is not in need of any changes to address the issue raised by Saranavan. -Bob -----Original Message----- From: T. Charles Clancy [mailto:clancy@cs.umd.edu] Sent: Monday, September 25, 2006 11:37 AM To: Peter Nilsson J (LI/EAB) Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations This is a very interesting solution. The AC selects the KeyRSC and performs the 4-way handshake. The WTP sniffs the 4-way handshake traffic and grabs the KeyRSC value and uses it to initialize its own counter. Pat/Bob: Is this how the Cisco implementation works? I have to agree with Saravanan that I've yet to see a technical description of how Cisco implements it. IMHO, this is somewhat hackish, and it would be cleaner to have the AC generate the KeyRSC and include it in the AddMobile message as Behcet suggests. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > I think Saravanan has a point. We did a prototype impelementation of the > protocol a year ago when it was still called LWAPP. The way we solved > this issue then was to let the WTP sniff on all CAPWAP data messages > from the AC and when message 3 of the 4-way handshake or message 1 of > the groupkey handshake was sent the WTP inserted the correct RSC before > sending it off to the supplicant. To avoid the sniffing on all CAPWAP > data messages we would need a mechanism with in CAPWAP to handle these > two messages. > > Peter Nilsson > > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: den 22 september 2006 11:03 > To: Margaret Wasserman > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > Hi Margaret, > > Thank you for reviewing the discussion on this issue. > > The issue here is the working of IEEE 802.11i when the 802.11i > authenticator element is at the AC and the 802.11i crypto element is at > the WTP. Particularly, it is for the 4-way handshake between > authenticator and supplicant. > > Now, the 4-way handshake requires knowing the value of KeyRSC sequence > counter. The KeyRSC helps both authenticator and supplicant keep track > of their exchanges. It serves to protect against threats by tracking > sequential frames. The KeyRSC is maintained at the at the point of > encryption, i.e. just before transmission over the wireless channel. > > In the case of CAPWAP, the 4-way handshake is between the AC > (authenticator) and the wireless station (supplicant). > > The problem arises, when the authenticator is at the AC and the crypto > element (together with KeyRSC) is at the WTP. This is a fairly common > design. Now in this case, the AC starts the 4-way handshake but it does > not know the value of the KeyRSC. The KeyRSC is maintained by the WTP. > > Based on this, the current CAPWAP specification does not allow for a way > to conduct the 4-way handshake with the correct KeyRSC. > > The functionality I would like to see is a way for the authenticator > (AC) to use the correct prevailing value of KeyRSC (maintained by the > WTP) in its 4-way handshake. > > One way to introduce this functionality in to CAPWAP is to have part of > the 4-way handshake be sent from AC to WTP. This will allow the 4-way > handshake to use the correct value of the KeyRSC before being sent to > the wireless station. > > I hope this helps clarify my view on the issue. > > Cheers, > > Saravanan > > > > > > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, September 21, 2006 8:26 PM > To: Saravanan Govindan > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > > > Hi again, > > Okay, I am even more confused than I thought I was... > > Saravanan, you wrote: > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > >> Pat, >> >> The issue here is about how 802.11i exchanges are done when >> authenticator is at the AC and crypto elements are at the WTP. This is >> the requirement. > > And, in response, Pat Calhoun wrote: > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: >> The current specification allows the authenticator to reside in the >> AC, >> while the data packet crypto elements in the WTP. This feature is >> already in the specification. > > Pat's message matches my reading of the specification. > > So, Saravanan, what functionality are you asking for that is not > already supported by the specification? And why do you think it is > necessary? it will not be helpful to my understanding to re-send > your proposal or to cite the requirements document... Please > summarize what functionality you think is missing from the current > specification and why you think that functionality is necessary to > support IEEE 802.11i or any important use case. > > At some point, the chairs may need to make a consensus call on this > issue, and I'd like to understand your view and make sure that it has > been clearly communicated to the WG before we ask the WG to decide on > this issue. > > 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 > _________________________________________________________________ > 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 Tue Sep 26 15:04:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSIEj-00048d-Gf for capwap-archive@lists.ietf.org; Tue, 26 Sep 2006 15:04:57 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSIEi-0005dU-2u for capwap-archive@lists.ietf.org; Tue, 26 Sep 2006 15:04:57 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6F8033980B8 for ; Tue, 26 Sep 2006 12:04:55 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 242F8430094 for ; Tue, 26 Sep 2006 12:04:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C5DBF1448003 for ; Tue, 26 Sep 2006 12:04:02 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by hermes.tigertech.net (Postfix) with ESMTP id 1F1791448009 for ; Tue, 26 Sep 2006 12:04:00 -0700 (PDT) Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 26 Sep 2006 12:03:45 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 62A422AE; Tue, 26 Sep 2006 12:03:45 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 36D6C2AE for ; Tue, 26 Sep 2006 12:03:45 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EFX76016; Tue, 26 Sep 2006 12:03:40 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id A467520502 for ; Tue, 26 Sep 2006 12:03:40 -0700 ( PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Sep 2006 12:03:39 -0700 Message-ID: <8954613CA6BB3242A1531D916A527A4101DBF5FC@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: 802.11 Duplicate Removal in Split MAC Thread-Index: AcbhnnpJ1Jwn3/FhSrGG1rb2ro8HsA== From: "Puneet Agarwal" To: capwap@frascone.com X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006092607; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230352E34353139373737432E303032322D412D; ENG=IBF; TS=20060926190349; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006092607_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6907A61B3L0228801-01-01 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=HTML_MESSAGE X-Spam-Level: Subject: [Capwap] 802.11 Duplicate Removal in Split MAC X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0015285050==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da This is a multi-part message in MIME format. --===============0015285050== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E19E.7A92FA96" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E19E.7A92FA96 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable In Split MAC (section 11.1.1), I assume that 802.11 Duplicate frame removal is always done by the WTP and a duplicate frame is never forwarded to the AC. Is this a correct assumption? =20 Thanks. =20 -Puneet ------_=_NextPart_001_01C6E19E.7A92FA96 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
In = Split MAC=20 (section 11.1.1),  I assume that 802.11 Duplicate frame removal is = always=20 done by the WTP and a duplicate frame is never forwarded to the AC. Is = this a=20 correct assumption?
 
Thanks.
 
-Puneet
------_=_NextPart_001_01C6E19E.7A92FA96-- --===============0015285050== 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 --===============0015285050==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Sep 26 16:49:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSJrv-0001WR-41 for capwap-archive@lists.ietf.org; Tue, 26 Sep 2006 16:49:31 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSJrr-00024V-1J for capwap-archive@lists.ietf.org; Tue, 26 Sep 2006 16:49:29 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id CAFCF398028 for ; Tue, 26 Sep 2006 13:49:08 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E3B5E430094 for ; Tue, 26 Sep 2006 13:45:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C90D2398062 for ; Tue, 26 Sep 2006 13:45:23 -0700 (PDT) Received: from web60320.mail.yahoo.com (web60320.mail.yahoo.com [209.73.178.128]) by zoidberg.tigertech.net (Postfix) with SMTP id CFFEB39801A for ; Tue, 26 Sep 2006 13:45:18 -0700 (PDT) Received: (qmail 10825 invoked by uid 60001); 26 Sep 2006 20:45:18 -0000 Message-ID: <20060926204518.10823.qmail@web60320.mail.yahoo.com> Received: from [12.129.211.52] by web60320.mail.yahoo.com via HTTP; Tue, 26 Sep 2006 13:45:18 PDT Date: Tue, 26 Sep 2006 13:45:18 -0700 (PDT) From: Behcet Sarikaya To: "Bob O'Hara (boohara)" MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=2.747 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, HTML_20_30, HTML_MESSAGE X-Spam-Level: ** Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============2055341746==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 --===============2055341746== Content-Type: multipart/alternative; boundary="0-240595431-1159303518=:2569" --0-240595431-1159303518=:2569 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable So, Bob, communicating the key RSC value to WTP would not hurt, would it?= =0AOr something to this effect, like AC initializing to zero of the group k= ey KeyRSC of all WTPs?=0A=0ARegards,=0A=0A--behcet=0A=0A=0A----- Original M= essage ----=0AFrom: Bob O'Hara (boohara) =0ATo: T. Charl= es Clancy ; Peter Nilsson J (LI/EAB) =0ACc: capwap@frascone.com=0ASent: Tuesday, September 26, 2006 1= :31:59 PM=0ASubject: Re: [Capwap] Issue 43 - Explanation for 802.11i Consid= erations=0A=0A=0ACharles, Peter,=0A=0ABelow is an expansion of a snippet fr= om a thread on this topic that I=0Asent to the list on July 25, 2006. I th= ink this will be helpful to=0Aunderstand why the exchange that Saranavan is= requesting is not=0Anecessary. In fact, there are several systems from se= veral=0Amanufacturers in the field using precursor protocols to CAPWAP that= are=0AWi-Fi certified for WPA2/802.11i operation using the protocol as it = is=0Adescribed below. =0A=0ABTW, this whole discussion is about the KeyRSC= for the group key, not=0Athe pairwise key. This is so because the WTP and= AC both know the=0Ainitial sequence counter value for the pairwise key, si= nce it has never=0Abeen used to send a frame. 802.11i requires the first f= rame sent on a=0Akey to use the sequence counter value of 1. See 8.3.2.6 c= ) and=0A8.3.3.4.3 c) in 802.11i for this requirement.=0A=0AThe same is not = true of the group key, i.e., after the WTP begins=0Aoperation, the AC will = not know the value of the sequence counter for=0Athe group key when it need= s to complete the EAPOL-key handshake with a=0Anewly associated STA. Howev= er, as you will see from the tutorial below,=0Ait is not necessary for the = AC and WTP to exchange any information about=0Athe group key KeyRSC for the= protocol to operate as it is intended.=0A=0A1. A value for the KeyRSC in t= he EAPOL-key frame is necessary to=0Acalculate the KeyMIC. =0A=0A2. This va= lue does not need to bear any specific relationship to the RSC=0Avalue main= tained by the WTP. A value of zero in the EAPOL-key frame for=0Athe group = key will always work.=0A=0A3. The client STA will use the value of KeyRSC r= eceived in the EAPOL-key=0Aframe to validate frame using the KeyMIC. =0A=0A= 4. The client STA will also set its group key RSC to the value received=0Ai= n KeyRSC, say, zero.=0A=0A5. The value in the client STA's RSC will be comp= ared against the=0Asequence number in subsequent received frames to identif= y replay=0Aattacks. Any frame received with a sequence counter value withi= n the=0Areplay window will be checked to have a valid MIC. If the MIC is n= ot=0Avalid, the frame is dropped.=0A=0A6. For any frame that is determined = not to be a replay attack frame and=0Ameets all other validity and authenti= city requirements, the client STA=0Aupdates its RSC value to the sequence n= umber in the received frame, if=0Athe value is greater than its current RSC= value. Only the AP can meet=0Athese criteria as the source of a frame rec= eived by the STA.=0A=0A7. Please see item 6, immediately above, for the rea= son that the AC and=0AWTP do not need to coordinate and exchange the RSC.= =0A=0A=0AThe only possible attack mode is for the attacker to send frames t= o the=0Aclient STA between the time of the EAPOL-key frame and the first fr= ame=0Aencrypted with the group key. During this time, the client will rece= ive=0Athe frame and proceed to validate its MIC. This is a potential attac= k=0Aagainst the STA resources. But, the MIC validation is done in the STA'= s=0A802.11 chip and consumes no more resources than receiving any other=0Af= rame. Thus, the attack does not actually consume any STA resources=0Abeyon= d those of receiving a frame.=0A=0AThis attack is not unique to the use of = the value zero for the KeyRSC,=0Aeither. The same attack is available to a= n attacker at any other time,=0Aas well. It is no more nor less effective = at either time.=0A=0AFor these reasons, the protocol is not in need of any = changes to address=0Athe issue raised by Saranavan.=0A=0A-Bob =0A-----Origi= nal Message-----=0AFrom: T. Charles Clancy [mailto:clancy@cs.umd.edu] =0ASe= nt: Monday, September 25, 2006 11:37 AM=0ATo: Peter Nilsson J (LI/EAB)=0ACc= : capwap@frascone.com=0ASubject: Re: [Capwap] Issue 43 - Explanation for 80= 2.11i Considerations=0A=0AThis is a very interesting solution. The AC sele= cts the KeyRSC and =0Aperforms the 4-way handshake. The WTP sniffs the 4-w= ay handshake=0Atraffic =0Aand grabs the KeyRSC value and uses it to initial= ize its own counter.=0A=0APat/Bob: Is this how the Cisco implementation wor= ks? I have to agree=0Awith =0ASaravanan that I've yet to see a technical d= escription of how Cisco =0Aimplements it.=0A=0AIMHO, this is somewhat hacki= sh, and it would be cleaner to have the AC =0Agenerate the KeyRSC and inclu= de it in the AddMobile message as Behcet =0Asuggests.=0A=0A--=0At. charles = clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy=0A=0AOn Mon, 25 Se= p 2006, Peter Nilsson J (LI/EAB) wrote:=0A=0A> I think Saravanan has a poin= t. We did a prototype impelementation of=0Athe=0A> protocol a year ago when= it was still called LWAPP. The way we solved=0A> this issue then was to le= t the WTP sniff on all CAPWAP data messages=0A> from the AC and when messag= e 3 of the 4-way handshake or message 1 of=0A> the groupkey handshake was s= ent the WTP inserted the correct RSC=0Abefore=0A> sending it off to the sup= plicant. To avoid the sniffing on all CAPWAP=0A> data messages we would nee= d a mechanism with in CAPWAP to handle these=0A> two messages.=0A>=0A> Pete= r Nilsson=0A>=0A> -----Original Message-----=0A> From: Saravanan Govindan [= mailto:Saravanan.Govindan@sg.panasonic.com]=0A> Sent: den 22 september 2006= 11:03=0A> To: Margaret Wasserman=0A> Cc: capwap@frascone.com=0A> Subject: = Re: [Capwap] Issue 43 - Explanation for 802.11i=0AConsiderations=0A>=0A> Hi= Margaret,=0A>=0A> Thank you for reviewing the discussion on this issue.=0A= >=0A> The issue here is the working of IEEE 802.11i when the 802.11i=0A> au= thenticator element is at the AC and the 802.11i crypto element is=0Aat=0A>= the WTP. Particularly, it is for the 4-way handshake between=0A> authentic= ator and supplicant.=0A>=0A> Now, the 4-way handshake requires knowing the = value of KeyRSC sequence=0A> counter. The KeyRSC helps both authenticator a= nd supplicant keep track=0A> of their exchanges. It serves to protect again= st threats by tracking=0A> sequential frames. The KeyRSC is maintained at t= he at the point of=0A> encryption, i.e. just before transmission over the w= ireless channel.=0A>=0A> In the case of CAPWAP, the 4-way handshake is betw= een the AC=0A> (authenticator) and the wireless station (supplicant).=0A>= =0A> The problem arises, when the authenticator is at the AC and the crypto= =0A> element (together with KeyRSC) is at the WTP. This is a fairly common= =0A> design. Now in this case, the AC starts the 4-way handshake but it=0Ad= oes=0A> not know the value of the KeyRSC. The KeyRSC is maintained by the W= TP.=0A>=0A> Based on this, the current CAPWAP specification does not allow = for a=0Away=0A> to conduct the 4-way handshake with the correct KeyRSC.=0A>= =0A> The functionality I would like to see is a way for the authenticator= =0A> (AC) to use the correct prevailing value of KeyRSC (maintained by the= =0A> WTP) in its 4-way handshake.=0A>=0A> One way to introduce this functio= nality in to CAPWAP is to have part=0Aof=0A> the 4-way handshake be sent fr= om AC to WTP. This will allow the 4-way=0A> handshake to use the correct va= lue of the KeyRSC before being sent to=0A> the wireless station.=0A>=0A> I = hope this helps clarify my view on the issue.=0A>=0A> Cheers,=0A>=0A> Sarav= anan=0A>=0A>=0A>=0A>=0A>=0A>=0A> -----Original Message-----=0A> From: Marga= ret Wasserman [mailto:margaret@thingmagic.com]=0A> Sent: Thursday, Septembe= r 21, 2006 8:26 PM=0A> To: Saravanan Govindan=0A> Cc: Pat Calhoun (pacalhou= ); capwap@frascone.com=0A> Subject: Re: [Capwap] Issue 43 - Explanation for= 802.11i=0AConsiderations=0A>=0A>=0A>=0A> Hi again,=0A>=0A> Okay, I am even= more confused than I thought I was...=0A>=0A> Saravanan, you wrote:=0A>=0A= > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote:=0A>=0A>> Pat,=0A>= >=0A>> The issue here is about how 802.11i exchanges are done when=0A>> aut= henticator is at the AC and crypto elements are at the WTP. This=0Ais=0A>> = the requirement.=0A>=0A> And, in response, Pat Calhoun wrote:=0A>=0A> On Se= p 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote:=0A>> The current spec= ification allows the authenticator to reside in the=0A>> AC,=0A>> while the= data packet crypto elements in the WTP. This feature is=0A>> already in th= e specification.=0A>=0A> Pat's message matches my reading of the specificat= ion.=0A>=0A> So, Saravanan, what functionality are you asking for that is n= ot=0A> already supported by the specification? And why do you think it is= =0A> necessary? it will not be helpful to my understanding to re-send=0A> = your proposal or to cite the requirements document... Please=0A> summarize= what functionality you think is missing from the current=0A> specification= and why you think that functionality is necessary to=0A> support IEEE 802.= 11i or any important use case.=0A>=0A> At some point, the chairs may need t= o make a consensus call on this=0A> issue, and I'd like to understand your = view and make sure that it has=0A> been clearly communicated to the WG befo= re we ask the WG to decide on=0A> this issue.=0A>=0A> Thanks,=0A> Margaret= =0A>=0A>=0A>=0A>=0A>=0A>=0A> ______________________________________________= ___________________=0A> To unsubscribe or modify your subscription options,= please visit:=0A> http://lists.frascone.com/mailman/listinfo/capwap=0A>=0A= > Archives: http://lists.frascone.com/pipermail/capwap=0A> ________________= _________________________________________________=0A> To unsubscribe or mod= ify your subscription options, please visit:=0A> http://lists.frascone.com/= mailman/listinfo/capwap=0A>=0A> Archives: http://lists.frascone.com/piperma= il/capwap=0A>=0A___________________________________________________________= ______=0ATo unsubscribe or modify your subscription options, please visit:= =0Ahttp://lists.frascone.com/mailman/listinfo/capwap=0A=0AArchives: http://= lists.frascone.com/pipermail/capwap=0A_____________________________________= ____________________________=0ATo unsubscribe or modify your subscription o= ptions, please visit:=0Ahttp://lists.frascone.com/mailman/listinfo/capwap= =0A=0AArchives: http://lists.frascone.com/pipermail/capwap --0-240595431-1159303518=:2569 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
So, Bob, communicating the key RSC value to WTP wou= ld not hurt, would it?
=0A
Or something to this effect, like A= C initializing to zero of the group key KeyRSC of all WTPs?
=0A
Regards,
=0A
 
=0A
--behcet

=0A
----- Original Message ----
From: Bo= b O'Hara (boohara) <boohara@cisco.com>
To: T. Charles Clancy <c= lancy@cs.umd.edu>; Peter Nilsson J (LI/EAB) <peter.j.nilsson@ericsson= .com>
Cc: capwap@frascone.com
Sent: Tuesday, September 26, 2006 1:= 31:59 PM
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Consid= erations

=0A
Charles, Peter,

Below is an expansion of a s= nippet from a thread on this topic that I
sent to the list on July 25, 2= 006.  I think this will be helpful to
understand why the excha= nge that Saranavan is requesting is not
necessary.  In fact, t= here are several systems from several
manufacturers in the field using p= recursor protocols to CAPWAP that are
Wi-Fi certified for WPA2/802.11i o= peration using the protocol as it is
described below.  
BTW, this whole discussion is about the KeyRSC for the group key, not
t= he pairwise key.  This is so because the WTP and AC both know the=
initial sequence counter value for the pairwise key, since it has never=
been used to send a frame.  802.11i requires the first frame = sent on a
key to use the sequence counter value of 1.  See 8.3= .2.6 c) and
8.3.3.4.3 c) in 802.11i for this requirement.

The sam= e is not true of the group key, i.e., after the WTP begins
operation, the AC will not know the value of= the sequence counter for
the group key when it needs to complete the EA= POL-key handshake with a
newly associated STA.  However, as yo= u will see from the tutorial below,
it is not necessary for the AC and W= TP to exchange any information about
the group key KeyRSC for the protoc= ol to operate as it is intended.

1. A value for the KeyRSC in the EA= POL-key frame is necessary to
calculate the KeyMIC.

2. This valu= e does not need to bear any specific relationship to the RSC
value maint= ained by the WTP.  A value of zero in the EAPOL-key frame for
= the group key will always work.

3. The client STA will use the value= of KeyRSC received in the EAPOL-key
frame to validate frame using the K= eyMIC.

4. The client STA will also set its group key RSC to the val= ue received
in KeyRSC, say, zero.

5. The value in the client STA'= s RSC will be compared against the
sequence number in subsequent received frames to i= dentify replay
attacks.  Any frame received with a sequence co= unter value within the
replay window will be checked to have a valid MIC= .  If the MIC is not
valid, the frame is dropped.

6. Fo= r any frame that is determined not to be a replay attack frame and
meets= all other validity and authenticity requirements, the client STA
update= s its RSC value to the sequence number in the received frame, if
the val= ue is greater than its current RSC value.  Only the AP can meetthese criteria as the source of a frame received by the STA.

7. Pl= ease see item 6, immediately above, for the reason that the AC and
WTP d= o not need to coordinate and exchange the RSC.


The only possible= attack mode is for the attacker to send frames to the
client STA betwee= n the time of the EAPOL-key frame and the first frame
encrypted with the= group key.  During this time, the client will receive
the frame and= proceed to validate its MIC.  This is a potential attack
agai= nst the STA resources.  But, the MIC validation is done in the ST= A's
802.11 chip and consumes no more resources than receiving any other<= BR>frame.  Thus, the attack does not actually consume any STA res= ources
beyond those of receiving a frame.

This attack is not uniq= ue to the use of the value zero for the KeyRSC,
either.  The s= ame attack is available to an attacker at any other time,
as well. =  It is no more nor less effective at either time.

For these rea= sons, the protocol is not in need of any changes to address
the issue ra= ised by Saranavan.

-Bob
-----Original Message-----
From: T. C= harles Clancy [mailto:clancy@cs.umd.edu]
Sent: Monday, September 25, 20= 06 11:37 AM
To: Peter Nilsson J (LI/EAB)
Cc: capwap@frascone.com
S= ubject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

This is = a very interesting solution.  The AC selects the KeyRSC and
p= erforms the 4-way handshake.  The WTP sniffs the 4-way handshake<= BR>traffic
and grabs the KeyRSC value and uses it to initialize its own= counter.

Pat/Bob: Is this how the Cisco implementation works? =  I have to agree
with
Saravanan that I've yet to see a technica= l description of how Cisco
implements it.

IMHO, this is somewhat= hackish, and it would be cleaner to have the AC
generate the KeyRSC an= d include it in the AddMobile message as Behcet
suggests.

--
= t. charles clancy, ph.d.  |  tcc@umd.edu  |&n= bsp; www.cs.= umd.edu/~clancy

On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wr= ote:

> I think Saravanan has a point. We did a prototype impeleme= ntation of
the
> protocol a year ago when it was still called LWAPP. The = way we solved
> this issue then was to let the WTP sniff on all CAPWA= P data messages
> from the AC and when message 3 of the 4-way handsha= ke or message 1 of
> the groupkey handshake was sent the WTP inserted= the correct RSC
before
> sending it off to the supplicant. To avo= id the sniffing on all CAPWAP
> data messages we would need a mechani= sm with in CAPWAP to handle these
> two messages.
>
> Pet= er Nilsson
>
> -----Original Message-----
> From: Saravan= an Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
> Sent: den = 22 september 2006 11:03
> To: Margaret Wasserman
> Cc: capwap@f= rascone.com
> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11= i
Considerations
>
> Hi Margaret,
>
> Thank you = for reviewing the discussion on this issue.
>
> The issue here = is the working of IEEE 802.11i when the 802.11i
> authenticator element is = at the AC and the 802.11i crypto element is
at
> the WTP. Particul= arly, it is for the 4-way handshake between
> authenticator and suppl= icant.
>
> Now, the 4-way handshake requires knowing the value = of KeyRSC sequence
> counter. The KeyRSC helps both authenticator and= supplicant keep track
> of their exchanges. It serves to protect aga= inst threats by tracking
> sequential frames. The KeyRSC is maintaine= d at the at the point of
> encryption, i.e. just before transmission = over the wireless channel.
>
> In the case of CAPWAP, the 4-way= handshake is between the AC
> (authenticator) and the wireless stati= on (supplicant).
>
> The problem arises, when the authenticator= is at the AC and the crypto
> element (together with KeyRSC) is at t= he WTP. This is a fairly common
> design. Now in this case, the AC st= arts the 4-way handshake but it
does
> not know the value of the KeyRSC. T= he KeyRSC is maintained by the WTP.
>
> Based on this, the curr= ent CAPWAP specification does not allow for a
way
> to conduct the= 4-way handshake with the correct KeyRSC.
>
> The functionality= I would like to see is a way for the authenticator
> (AC) to use the= correct prevailing value of KeyRSC (maintained by the
> WTP) in its = 4-way handshake.
>
> One way to introduce this functionality in= to CAPWAP is to have part
of
> the 4-way handshake be sent from A= C to WTP. This will allow the 4-way
> handshake to use the correct va= lue of the KeyRSC before being sent to
> the wireless station.
>= ;
> I hope this helps clarify my view on the issue.
>
> C= heers,
>
> Saravanan
>
>
>
>
>>
> -----Original Message-----
> From: Margaret Wasserman [mailto:margaret@thingmagic.com]
> Sent: Thursday, September 21, 200= 6 8:26 PM
> To: Saravanan Govindan
> Cc: Pat Calhoun (pacalhou)= ; capwap@frascone.com
> Subject: Re: [Capwap] Issue 43 - Explanation = for 802.11i
Considerations
>
>
>
> Hi again,
= >
> Okay, I am even more confused than I thought I was...
><= BR>> Saravanan, you wrote:
>
> On Sep 17, 2006, at 10:24 PM,= Saravanan Govindan wrote:
>
>> Pat,
>>
>>= The issue here is about how 802.11i exchanges are done when
>> au= thenticator is at the AC and crypto elements are at the WTP. This
is
= >> the requirement.
>
> And, in response, Pat Calhoun wro= te:
>
> On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wro= te:
>> The current specification allows the authenticator to resid= e in the
>> AC,
>> while the data packet crypto elements = in the WTP. This feature is
>> already in the specification.
>
> = Pat's message matches my reading of the specification.
>
> So, = Saravanan, what functionality are you asking for that is not
> alread= y supported by the specification?  And why do you think it is
= > necessary?  it will not be helpful to my understanding to re= -send
> your proposal or to cite the requirements document... &n= bsp;Please
> summarize what functionality you think is missing from t= he current
> specification and why you think that functionality is ne= cessary to
> support IEEE 802.11i or any important use case.
><= BR>> At some point, the chairs may need to make a consensus call on this=
> issue, and I'd like to understand your view and make sure that it = has
> been clearly communicated to the WG before we ask the WG to dec= ide on
> this issue.
>
> Thanks,
> Margaret
>
>
>
>
>
>
> _________= ________________________________________________________
> To unsubsc= ribe or modify your subscription options, please visit:
> http://l= ists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://= lists.frascone.com/pipermail/capwap
> ___________________________= ______________________________________
> To unsubscribe or modify you= r 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://list= s.frascone.com/pipermail/capwap
____________________________________= _____________________________
To unsubscribe or modify your subscription= options, please visit:
http://lists.frascone.com/mailman/listinfo/ca= pwap

Archives: http://lists.frascone.com/pipermail/capwap
<= /DIV>=0A

--0-240595431-1159303518=:2569-- --===============2055341746== 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 --===============2055341746==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Sep 26 21:07:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSNtt-0003TN-8Q for capwap-archive@lists.ietf.org; Tue, 26 Sep 2006 21:07:49 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSNtn-0006FX-FA for capwap-archive@lists.ietf.org; Tue, 26 Sep 2006 21:07:49 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 38D431448039 for ; Tue, 26 Sep 2006 18:07:38 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 51565430094 for ; Tue, 26 Sep 2006 18:04:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2FDC339803C for ; Tue, 26 Sep 2006 18:04:28 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id D525E398010 for ; Tue, 26 Sep 2006 18:04:23 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id k8R147qm001172; Wed, 27 Sep 2006 10:04:07 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k8R148108701; Wed, 27 Sep 2006 10:04:08 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id k8R146l29377; Wed, 27 Sep 2006 10:04:07 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Sep 2006 09:03:04 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F1B93@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: Acbg0apVLhatsbAIQ02cILmAIvbQhAAwcJngAA7+dpA= From: "Cheng Hong" To: "Bob O'Hara (boohara)" , "T. Charles Clancy" , "Peter Nilsson J (LI/EAB)" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 7e267523e0685e5aa2dbbdde4b659686 Hi Bob, If I understand your description below correct, you are proposing a solution (to the problem pointed out by Saravanan) by mandating the behavior of the AC to always set the KeyRSC in the 4-way handshake to zero. This is not a defined behavior according to the current 802.11 standard. Are you suggesting that we CAPWAP WG should specifically mandate that in our CAPWAP protocol spec, e.g. something like "a CAPWAP compatible AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, since not all AC implementation have to follow what you described. Or, are you planning to take this issue to TGm for 802.11 standard revision? (since based on your description, there is essentially no use of the KeyRSC). cheers Cheng Hong > -----Original Message----- > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > Sent: Wednesday, September 27, 2006 2:32 AM > To: T. Charles Clancy; Peter Nilsson J (LI/EAB) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Charles, Peter, > > Below is an expansion of a snippet from a thread on this > topic that I sent to the list on July 25, 2006. I think this > will be helpful to understand why the exchange that Saranavan > is requesting is not necessary. In fact, there are several > systems from several manufacturers in the field using > precursor protocols to CAPWAP that are Wi-Fi certified for > WPA2/802.11i operation using the protocol as it is described below. > > BTW, this whole discussion is about the KeyRSC for the group > key, not the pairwise key. This is so because the WTP and AC > both know the initial sequence counter value for the pairwise > key, since it has never been used to send a frame. 802.11i > requires the first frame sent on a key to use the sequence > counter value of 1. See 8.3.2.6 c) and > 8.3.3.4.3 c) in 802.11i for this requirement. > > The same is not true of the group key, i.e., after the WTP > begins operation, the AC will not know the value of the > sequence counter for the group key when it needs to complete > the EAPOL-key handshake with a newly associated STA. > However, as you will see from the tutorial below, it is not > necessary for the AC and WTP to exchange any information > about the group key KeyRSC for the protocol to operate as it > is intended. > > 1. A value for the KeyRSC in the EAPOL-key frame 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. A value of zero in > the EAPOL-key frame for the group key will always work. > > 3. The client STA will use the value of KeyRSC received in > the EAPOL-key frame to validate frame using the KeyMIC. > > 4. The client STA will also set its group key RSC to the > value received in KeyRSC, say, zero. > > 5. The value in the client STA's RSC will be compared against > the sequence number in subsequent received frames to identify > replay attacks. Any frame received with a sequence counter > value within the replay window will be checked to have a > valid MIC. If the MIC is not valid, the frame is dropped. > > 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, if the value is > greater than its current RSC value. Only the AP can meet > these criteria as the source of a frame received by the STA. > > 7. Please see item 6, immediately above, for the reason that > the AC and WTP do not need to coordinate and exchange the RSC. > > > The only possible attack mode is for the attacker to send > frames to the client STA between the time of the EAPOL-key > frame and the first frame encrypted with the group key. > During this time, the client will receive the frame and > proceed to validate its MIC. This is a potential attack > against the STA resources. But, the MIC validation is done > in the STA's > 802.11 chip and consumes no more resources than receiving any > other frame. Thus, the attack does not actually consume any > STA resources beyond those of receiving a frame. > > This attack is not unique to the use of the value zero for > the KeyRSC, either. The same attack is available to an > attacker at any other time, as well. It is no more nor less > effective at either time. > > For these reasons, the protocol is not in need of any changes > to address the issue raised by Saranavan. > > -Bob > -----Original Message----- > From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Monday, September 25, 2006 11:37 AM > To: Peter Nilsson J (LI/EAB) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > This is a very interesting solution. The AC selects the > KeyRSC and performs the 4-way handshake. The WTP sniffs the > 4-way handshake traffic and grabs the KeyRSC value and uses > it to initialize its own counter. > > Pat/Bob: Is this how the Cisco implementation works? I have > to agree with Saravanan that I've yet to see a technical > description of how Cisco implements it. > > IMHO, this is somewhat hackish, and it would be cleaner to > have the AC generate the KeyRSC and include it in the > AddMobile message as Behcet suggests. > > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > > > I think Saravanan has a point. We did a prototype impelementation of > the > > protocol a year ago when it was still called LWAPP. The way > we solved > > this issue then was to let the WTP sniff on all CAPWAP data > messages > > from the AC and when message 3 of the 4-way handshake or > message 1 of > > the groupkey handshake was sent the WTP inserted the correct RSC > before > > sending it off to the supplicant. To avoid the sniffing on > all CAPWAP > > data messages we would need a mechanism with in CAPWAP to > handle these > > two messages. > > > > Peter Nilsson > > > > -----Original Message----- > > From: Saravanan Govindan > [mailto:Saravanan.Govindan@sg.panasonic.com] > > Sent: den 22 september 2006 11:03 > > To: Margaret Wasserman > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > Hi Margaret, > > > > Thank you for reviewing the discussion on this issue. > > > > The issue here is the working of IEEE 802.11i when the 802.11i > > authenticator element is at the AC and the 802.11i crypto element is > at > > the WTP. Particularly, it is for the 4-way handshake between > > authenticator and supplicant. > > > > Now, the 4-way handshake requires knowing the value of > KeyRSC sequence > > counter. The KeyRSC helps both authenticator and supplicant > keep track > > of their exchanges. It serves to protect against threats by > tracking > > sequential frames. The KeyRSC is maintained at the at the point of > > encryption, i.e. just before transmission over the wireless channel. > > > > In the case of CAPWAP, the 4-way handshake is between the AC > > (authenticator) and the wireless station (supplicant). > > > > The problem arises, when the authenticator is at the AC and > the crypto > > element (together with KeyRSC) is at the WTP. This is a > fairly common > > design. Now in this case, the AC starts the 4-way handshake but it > does > > not know the value of the KeyRSC. The KeyRSC is maintained > by the WTP. > > > > Based on this, the current CAPWAP specification does not allow for a > way > > to conduct the 4-way handshake with the correct KeyRSC. > > > > The functionality I would like to see is a way for the authenticator > > (AC) to use the correct prevailing value of KeyRSC > (maintained by the > > WTP) in its 4-way handshake. > > > > One way to introduce this functionality in to CAPWAP is to have part > of > > the 4-way handshake be sent from AC to WTP. This will allow > the 4-way > > handshake to use the correct value of the KeyRSC before > being sent to > > the wireless station. > > > > I hope this helps clarify my view on the issue. > > > > Cheers, > > > > Saravanan > > > > > > > > > > > > > > -----Original Message----- > > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > > Sent: Thursday, September 21, 2006 8:26 PM > > To: Saravanan Govindan > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > > > > > Hi again, > > > > Okay, I am even more confused than I thought I was... > > > > Saravanan, you wrote: > > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > >> Pat, > >> > >> The issue here is about how 802.11i exchanges are done when > >> authenticator is at the AC and crypto elements are at the WTP. This > is > >> the requirement. > > > > And, in response, Pat Calhoun wrote: > > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: > >> The current specification allows the authenticator to > reside in the > >> AC, while the data packet crypto elements in the WTP. This > feature is > >> already in the specification. > > > > Pat's message matches my reading of the specification. > > > > So, Saravanan, what functionality are you asking for that is not > > already supported by the specification? And why do you think it is > > necessary? it will not be helpful to my understanding to > re-send your > > proposal or to cite the requirements document... Please summarize > > what functionality you think is missing from the current > specification > > and why you think that functionality is necessary to support IEEE > > 802.11i or any important use case. > > > > At some point, the chairs may need to make a consensus call on this > > issue, and I'd like to understand your view and make sure > that it has > > been clearly communicated to the WG before we ask the WG to > decide on > > this issue. > > > > 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 > > _________________________________________________________________ > > 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 > _________________________________________________________________ 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 Sep 26 22:06:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSOp5-0004bK-I2 for capwap-archive@lists.ietf.org; Tue, 26 Sep 2006 22:06:55 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSOp0-00055L-If for capwap-archive@lists.ietf.org; Tue, 26 Sep 2006 22:06:55 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 76D56144802C for ; Tue, 26 Sep 2006 19:06:46 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 327ED430094 for ; Tue, 26 Sep 2006 19:03:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 13B3A398010 for ; Tue, 26 Sep 2006 19:03:23 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 73DF2398036 for ; Tue, 26 Sep 2006 19:03:11 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k8R239dE018839; Wed, 27 Sep 2006 11:03:09 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k8R23BQ12894; Wed, 27 Sep 2006 11:03:11 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with ESMTP id k8R23AQ12938; Wed, 27 Sep 2006 11:03:10 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Sep 2006 10:02:08 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F1BBD@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames Thread-Index: AcbhiBcmB+JXaOulQXiBu0bqEzHiZAAUGh/Q From: "Cheng Hong" To: "Michael Montemurro" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.452 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_60_70, HTML_MESSAGE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0607455195==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 3d48d865303330c98a6e90d450cf2ff2 This is a multi-part message in MIME format. --===============0607455195== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E1D8.F4E223E4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E1D8.F4E223E4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike,=20 =20 It seems OK to use TID in the EDCA case. If the HCCA is used, would the TID still be meaningful in mapping the priority? (Haven't check the 802.11 standards in detail).=20 =20 cheers =20 Cheng Hong=20 _____ =20 From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Wednesday, September 27, 2006 12:24 AM To: Cheng Hong Cc: zhaoyujin 31390; capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames Cheng, =20 Thanks for you input. =20 Also, that's a good question. In my opinion, the CAPWAP priority should be based on the TID(UP). Which means yes, the WTP would need to read into the QoS control field. =20 Cheers, =20 Mike =20 On 9/25/06, Cheng Hong wrote:=20 Hi Mike, =20 In this case, I tend to agree with the other Michael on the first point. =20 However, on the mapping 802.11e priority back to CAPWAP priority, I am not really sure how that is done. Is it based on 802.11e AC or TID (UP)? For later case, does it mean the WTP need to read into the QoS Control Field?=20 =20 cheers =20 Cheng Hong =20 =20 _____ =20 From: Michael Montemurro [mailto:montemurro.michael@gmail.com ]=20 Sent: Tuesday, September 26, 2006 1:17 AM To: Cheng Hong Cc: zhaoyujin 31390; capwap=20 Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames =20 Cheng Hong, =20 In the CAPWAP draft, both wireless data and management frames are treated as CAPWAP data frames. Given that, all CAPWAP data traffic would need to go to the same logical instance of the AC. =20 Cheers, =20 Mike =20 On 9/24/06, Cheng Hong > wrote:=20 Hi Michael & Michael, =20 Sorry if the issue has already been discussed before. Just thinking if the WTP does not differentiate 802.1X frames from normal data frames, would it be possible that the 802.1X frames being forwarded to a different AC instance than the one processing the control/management frames? (in case different ACs are used to process the control and data channel) Is this acceptable? =20 cheers =20 Cheng Hong =20 =20 =20 _____ =20 From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Sunday, September 24, 2006 3:18 AM To: zhaoyujin 31390 Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames=20 =20 Michael, =20 Thanks. Is anybody else opinionated on this feature.=20 =20 Cheers, =20 Mike =20 On 9/23/06, zhaoyujin 31390 > wrote:=20 Firstly, I have some doubt one this suggestion. 1. If CAPWAP difines like this, AP device must decode the payload frames of 802.11 frames. 2. Another problem, the 802.1x priority should be implement by 802.11e. When station sends 802.11 data frames, it can set 802.11e priority. AP should transfer 802.11e to actual CAPWAP packet priority. So that I think CAPWAP does not need consider the priority of 802.11 data frames payload.=20 Thanks Michael >Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as >IEEE 802.11 Management frames. > >I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages >to "Quality >of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to >indicate that IEEE 802.1X frames are sent at a higher priority. >=20 >Cheers, > >Mike This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email=20 immediately and delete it! =20 Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as IEEE 802.11 Management frames.=20 =20 I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages to "Quality of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to indicate that IEEE 802.1X frames are sent at a higher priority. =20 Cheers, =20 Mike _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap =20 ------_=_NextPart_001_01C6E1D8.F4E223E4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Mike,
 
It=20 seems OK to use TID in the EDCA case. If the HCCA is used, would the TID = still=20 be meaningful in mapping the priority? (Haven't check the 802.11 = standards in=20 detail).
 
cheers
 
Cheng=20 Hong

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Wednesday, = September=20 27, 2006 12:24 AM
To: Cheng Hong
Cc: zhaoyujin = 31390;=20 capwap
Subject: Re: [Capwap] This is not need.: Proposed = resolution=20 to Issue 214 -Prioritization of IEEE 802.1X = frames

Cheng,
 
Thanks for you input.
 
Also, that's a good question. In my opinion, the CAPWAP priority = should=20 be based on the TID(UP). Which means yes, the WTP would need to = read into=20 the QoS control field.
 
Cheers,
 
Mike
 
On 9/25/06, Cheng=20 Hong <Hong.Cheng@sg.panasonic.com>=20 wrote:=20
Hi=20 Mike,
 
In this case, = I tend to=20 agree with the other Michael on the first point. =
 
However, on = the mapping=20 802.11e priority back to CAPWAP priority, I am not really sure = how that=20 is done. Is it based on 802.11e AC or TID (UP)? For later case, does = it mean=20 the WTP need to read into the QoS Control Field? =
 
cheers
 
Cheng=20 Hong
 
 
From: Michael = Montemurro=20 [mailto:montemurro.michael@gmail.com ] =
Sent:=20 Tuesday, September 26, 2006 1:17 AM
To: Cheng = Hong
Cc:=20 zhaoyujin 31390; capwap=20

Subject: = Re:=20 [Capwap] This is not need.: Proposed resolution to Issue 214=20 -Prioritization of IEEE 802.1X=20 frames

 
Cheng Hong,
 
In the CAPWAP draft, both wireless data and management frames = are=20 treated as CAPWAP data frames. Given that, all CAPWAP = data=20 traffic would need to go to the same logical instance of the = AC.
 
Cheers,
 
Mike


 
On 9/24/06, Cheng=20 Hong <Hong.Cheng@sg.panasonic.com > wrote: =
Hi = Michael &=20 Michael,
 
Sorry if = the issue has=20 already been discussed before. Just thinking if the WTP does not = differentiate 802.1X frames from normal data frames, would it be = possible that the 802.1X frames being forwarded to a different = AC=20 instance than the one processing the control/management frames? = (in case=20 different ACs are used to process the control and data channel) = Is this=20 acceptable?
 
cheers
 
Cheng=20 Hong
 
 
 

From: Michael Montemurro = [mailto:montemurro.michael@gmail.com] =
Sent:=20 Sunday, September 24, 2006 3:18 AM
To: zhaoyujin=20 31390
Cc: capwap
Subject: Re: [Capwap] = This is not=20 need.: Proposed resolution to Issue 214 -Prioritization of = IEEE 802.1X=20 frames

 
Michael,
 
Thanks. Is anybody else opinionated on this feature. =
 
Cheers,
 
Mike

 
On 9/23/06, zhaoyujin 31390 <zhaoyujin@huawei.com=20 > wrote:=20
Firstly, I have some doubt one = this=20 suggestion.

1. If CAPWAP difines like this, AP device = must=20 decode the payload frames of 802.11 frames.
2. Another = problem,=20 the 802.1x priority should be implement by 802.11e. When = station=20 sends 802.11 data frames, it can set 802.11e priority. AP = should=20 transfer 802.11e to actual CAPWAP packet priority.

So = that I=20 think CAPWAP does not need consider the priority of 802.11 = data=20 frames payload.=20

Thanks
Michael



>Practically = speaking,=20 IEEE 802.1X frames should be transmitted at the same = priority as=20 >IEEE 802.11 Management frames.
>
>I will = update=20 Section 11.5, rename Quality of Service for IEEE 802.11 = Control=20 Messages >to "Quality
>of Service for IEEE 802.11 = control=20 messages and IEEE 802.1X EAPoL frames" and add text to = >indicate=20 that IEEE 802.1X frames are sent at a higher = priority.
>=20
>Cheers,
>
>Mike


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

 

Practically speaking, IEEE 802.1X frames should be = transmitted=20 at the same priority as IEEE 802.11 Management frames. =
 
I will update Section 11.5, rename Quality of Service = for IEEE=20 802.11 Control Messages to "Quality
of Service for IEEE = 802.11=20 control messages and IEEE 802.1X EAPoL frames" and add text = to=20 indicate that IEEE 802.1X frames are sent at a higher=20 priority.
 
Cheers,
 
=
Mike

______________________________________________________= ___________
To=20 unsubscribe or modify your subscription options, please = visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20 =




<= BR> ------_=_NextPart_001_01C6E1D8.F4E223E4-- --===============0607455195== 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 --===============0607455195==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Sep 27 11:55:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSbkU-0006Uv-T5 for capwap-archive@lists.ietf.org; Wed, 27 Sep 2006 11:55:02 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSbkS-0005EF-EI for capwap-archive@lists.ietf.org; Wed, 27 Sep 2006 11:55:02 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id A6B911448057 for ; Wed, 27 Sep 2006 08:54:43 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id CF31343009A for ; Wed, 27 Sep 2006 08:46:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BAFDA1448006 for ; Wed, 27 Sep 2006 08:46:01 -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 A382E144804C for ; Wed, 27 Sep 2006 08:45:49 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 27 Sep 2006 08:45:49 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8RFjnKZ002326; Wed, 27 Sep 2006 08:45:49 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8RFjnQV017791; Wed, 27 Sep 2006 08:45:49 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Sep 2006 08:45:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Sep 2006 08:45:48 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2028E90A2@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbhrVFsuJcovZ2mRUybOfoBC38tFwAKcHEg From: "Pat Calhoun (pacalhou)" To: "Behcet Sarikaya" , "Bob O'Hara (boohara)" X-OriginalArrivalTime: 27 Sep 2006 15:45:49.0229 (UTC) FILETIME=[013525D0:01C6E24C] Authentication-Results: sj-dkim-3.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.9 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_20_30, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0377491641==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: e535e8fdae689580ce57283401d548ee This is a multi-part message in MIME format. --===============0377491641== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E24C.00FE6611" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E24C.00FE6611 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We could send the communicated value to the WTP via the means we currently communicate the Pairwise RSC value. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Tuesday, September 26, 2006 1:45 PM To: Bob O'Hara (boohara) Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations =09 =09 So, Bob, communicating the key RSC value to WTP would not hurt, would it? Or something to this effect, like AC initializing to zero of the group key KeyRSC of all WTPs? =20 Regards, =20 --behcet =09 =09 ----- Original Message ---- From: Bob O'Hara (boohara) To: T. Charles Clancy ; Peter Nilsson J (LI/EAB) Cc: capwap@frascone.com Sent: Tuesday, September 26, 2006 1:31:59 PM Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations =09 =09 Charles, Peter, =09 Below is an expansion of a snippet from a thread on this topic that I sent to the list on July 25, 2006. I think this will be helpful to understand why the exchange that Saranavan is requesting is not necessary. In fact, there are several systems from several manufacturers in the field using precursor protocols to CAPWAP that are Wi-Fi certified for WPA2/802.11i operation using the protocol as it is described below. =20 =09 BTW, this whole discussion is about the KeyRSC for the group key, not the pairwise key. This is so because the WTP and AC both know the initial sequence counter value for the pairwise key, since it has never been used to send a frame. 802.11i requires the first frame sent on a key to use the sequence counter value of 1. See 8.3.2.6 c) and 8.3.3.4.3 c) in 802.11i for this requirement. =09 The same is not true of the group key, i.e., after the WTP begins operation, the AC will not know the value of the sequence counter for the group key when it needs to complete the EAPOL-key handshake with a newly associated STA. However, as you will see from the tutorial below, it is not necessary for the AC and WTP to exchange any information about the group key KeyRSC for the protocol to operate as it is intended. =09 1. A value for the KeyRSC in the EAPOL-key frame is necessary to calculate the KeyMIC.=20 =09 2. This value does not need to bear any specific relationship to the RSC value maintained by the WTP. A value of zero in the EAPOL-key frame for the group key will always work. =09 3. The client STA will use the value of KeyRSC received in the EAPOL-key frame to validate frame using the KeyMIC.=20 =09 4. The client STA will also set its group key RSC to the value received in KeyRSC, say, zero. =09 5. The value in the client STA's RSC will be compared against the sequence number in subsequent received frames to identify replay attacks. Any frame received with a sequence counter value within the replay window will be checked to have a valid MIC. If the MIC is not valid, the frame is dropped. =09 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, if the value is greater than its current RSC value. Only the AP can meet these criteria as the source of a frame received by the STA. =09 7. Please see item 6, immediately above, for the reason that the AC and WTP do not need to coordinate and exchange the RSC. =09 =09 The only possible attack mode is for the attacker to send frames to the client STA between the time of the EAPOL-key frame and the first frame encrypted with the group key. During this time, the client will receive the frame and proceed to validate its MIC. This is a potential attack against the STA resources. But, the MIC validation is done in the STA's 802.11 chip and consumes no more resources than receiving any other frame. Thus, the attack does not actually consume any STA resources beyond those of receiving a frame. =09 This attack is not unique to the use of the value zero for the KeyRSC, either. The same attack is available to an attacker at any other time, as well. It is no more nor less effective at either time. =09 For these reasons, the protocol is not in need of any changes to address the issue raised by Saranavan. =09 -Bob=20 -----Original Message----- From: T. Charles Clancy [mailto:clancy@cs.umd.edu]=20 Sent: Monday, September 25, 2006 11:37 AM To: Peter Nilsson J (LI/EAB) Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations =09 This is a very interesting solution. The AC selects the KeyRSC and=20 performs the 4-way handshake. The WTP sniffs the 4-way handshake traffic=20 and grabs the KeyRSC value and uses it to initialize its own counter. =09 Pat/Bob: Is this how the Cisco implementation works? I have to agree with=20 Saravanan that I've yet to see a technical description of how Cisco=20 implements it. =09 IMHO, this is somewhat hackish, and it would be cleaner to have the AC=20 generate the KeyRSC and include it in the AddMobile message as Behcet=20 suggests. =09 -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy =09 On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: =09 > I think Saravanan has a point. We did a prototype impelementation of the > protocol a year ago when it was still called LWAPP. The way we solved > this issue then was to let the WTP sniff on all CAPWAP data messages > from the AC and when message 3 of the 4-way handshake or message 1 of > the groupkey handshake was sent the WTP inserted the correct RSC before > sending it off to the supplicant. To avoid the sniffing on all CAPWAP > data messages we would need a mechanism with in CAPWAP to handle these > two messages. > > Peter Nilsson > > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: den 22 september 2006 11:03 > To: Margaret Wasserman > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > Hi Margaret, > > Thank you for reviewing the discussion on this issue. > > The issue here is the working of IEEE 802.11i when the 802.11i > authenticator element is at the AC and the 802.11i crypto element is at > the WTP. Particularly, it is for the 4-way handshake between > authenticator and supplicant. > > Now, the 4-way handshake requires knowing the value of KeyRSC sequence > counter. The KeyRSC helps both authenticator and supplicant keep track > of their exchanges. It serves to protect against threats by tracking > sequential frames. The KeyRSC is maintained at the at the point of > encryption, i.e. just before transmission over the wireless channel. > > In the case of CAPWAP, the 4-way handshake is between the AC > (authenticator) and the wireless station (supplicant). > > The problem arises, when the authenticator is at the AC and the crypto > element (together with KeyRSC) is at the WTP. This is a fairly common > design. Now in this case, the AC starts the 4-way handshake but it does > not know the value of the KeyRSC. The KeyRSC is maintained by the WTP. > > Based on this, the current CAPWAP specification does not allow for a way > to conduct the 4-way handshake with the correct KeyRSC. > > The functionality I would like to see is a way for the authenticator > (AC) to use the correct prevailing value of KeyRSC (maintained by the > WTP) in its 4-way handshake. > > One way to introduce this functionality in to CAPWAP is to have part of > the 4-way handshake be sent from AC to WTP. This will allow the 4-way > handshake to use the correct value of the KeyRSC before being sent to > the wireless station. > > I hope this helps clarify my view on the issue. > > Cheers, > > Saravanan > > > > > > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, September 21, 2006 8:26 PM > To: Saravanan Govindan > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > > > Hi again, > > Okay, I am even more confused than I thought I was... > > Saravanan, you wrote: > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > >> Pat, >> >> The issue here is about how 802.11i exchanges are done when >> authenticator is at the AC and crypto elements are at the WTP. This is >> the requirement. > > And, in response, Pat Calhoun wrote: > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: >> The current specification allows the authenticator to reside in the >> AC, >> while the data packet crypto elements in the WTP. This feature is >> already in the specification. > > Pat's message matches my reading of the specification. > > So, Saravanan, what functionality are you asking for that is not > already supported by the specification? And why do you think it is > necessary? it will not be helpful to my understanding to re-send > your proposal or to cite the requirements document... Please > summarize what functionality you think is missing from the current > specification and why you think that functionality is necessary to > support IEEE 802.11i or any important use case. > > At some point, the chairs may need to make a consensus call on this > issue, and I'd like to understand your view and make sure that it has > been clearly communicated to the WG before we ask the WG to decide on > this issue. > > 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 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap ------_=_NextPart_001_01C6E24C.00FE6611 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
We=20 could send the communicated value to the WTP via the means we currently=20 communicate the Pairwise RSC value.
 

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

 

From: Behcet Sarikaya=20 [mailto:behcetsarikaya@yahoo.com]
Sent: Tuesday, September = 26, 2006=20 1:45 PM
To: Bob O'Hara (boohara)
Cc:=20 capwap@frascone.com
Subject: Re: [Capwap] Issue 43 - = Explanation for=20 802.11i Considerations

So,=20 Bob, communicating the key RSC value to WTP would not hurt, would = it?
Or=20 something to this effect, like AC initializing to zero of the group = key KeyRSC=20 of all WTPs?
 
Regards,
  --behcet

-----=20 Original Message ----
From: Bob O'Hara (boohara)=20 <boohara@cisco.com>
To: T. Charles Clancy = <clancy@cs.umd.edu>;=20 Peter Nilsson J (LI/EAB) <peter.j.nilsson@ericsson.com>
Cc:=20 capwap@frascone.com
Sent: Tuesday, September 26, 2006 1:31:59=20 PM
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i=20 Considerations

Charles, Peter,

Below is an expansion of a snippet from a = thread=20 on this topic that I
sent to the list on July 25, = 2006.  I think=20 this will be helpful to
understand why the exchange that Saranavan = is=20 requesting is not
necessary.  In fact, there are several = systems=20 from several
manufacturers in the field using precursor protocols = to CAPWAP=20 that are
Wi-Fi certified for WPA2/802.11i operation using the = protocol as=20 it is
described below.  

BTW, this whole = discussion is=20 about the KeyRSC for the group key, not
the pairwise = key.  This=20 is so because the WTP and AC both know the
initial sequence counter = value=20 for the pairwise key, since it has never
been used to send a=20 frame.  802.11i requires the first frame sent on a
key to = use the=20 sequence counter value of 1.  See 8.3.2.6 c) = and
8.3.3.4.3 c) in=20 802.11i for this requirement.

The same is not true of the group = key,=20 i.e., after the WTP begins
operation, the AC will not know the = value of the=20 sequence counter for
the group key when it needs to complete the = EAPOL-key=20 handshake with a
newly associated STA.  However, as you = will see=20 from the tutorial below,
it is not necessary for the AC and WTP to = exchange=20 any information about
the group key KeyRSC for the protocol to = operate as=20 it is intended.

1. A value for the KeyRSC in the EAPOL-key = frame is=20 necessary to
calculate the KeyMIC.

2. This value does not = need to=20 bear any specific relationship to the RSC
value maintained by the=20 WTP.  A value of zero in the EAPOL-key frame for
the = group key=20 will always work.

3. The client STA will use the value of = KeyRSC=20 received in the EAPOL-key
frame to validate frame using the KeyMIC. =

4. The client STA will also set its group key RSC to the value = received
in KeyRSC, say, zero.

5. The value in the client = STA's RSC=20 will be compared against the
sequence number in subsequent received = frames=20 to identify replay
attacks.  Any frame received with a = sequence=20 counter value within the
replay window will be checked to have a = valid=20 MIC.  If the MIC is not
valid, the frame is = dropped.

6.=20 For any frame that is determined not to be a replay attack frame = and
meets=20 all other validity and authenticity requirements, the client = STA
updates=20 its RSC value to the sequence number in the received frame, if
the = value is=20 greater than its current RSC value.  Only the AP can = meet
these=20 criteria as the source of a frame received by the STA.

7. = Please see=20 item 6, immediately above, for the reason that the AC and
WTP do = not need=20 to coordinate and exchange the RSC.


The only possible = attack mode=20 is for the attacker to send frames to the
client STA between the = time of=20 the EAPOL-key frame and the first frame
encrypted with the group=20 key.  During this time, the client will receive
the frame = and=20 proceed to validate its MIC.  This is a potential = attack
against=20 the STA resources.  But, the MIC validation is done in the=20 STA's
802.11 chip and consumes no more resources than receiving any = other
frame.  Thus, the attack does not actually consume = any STA=20 resources
beyond those of receiving a frame.

This attack is = not=20 unique to the use of the value zero for the = KeyRSC,
either.  The=20 same attack is available to an attacker at any other time,
as=20 well.  It is no more nor less effective at either = time.

For=20 these reasons, the protocol is not in need of any changes to = address
the=20 issue raised by Saranavan.

-Bob
-----Original = Message-----
From:=20 T. Charles Clancy [mailto:clancy@cs.umd.edu]
Sent: Monday, = September 25,=20 2006 11:37 AM
To: Peter Nilsson J (LI/EAB)
Cc:=20 capwap@frascone.com
Subject: Re: [Capwap] Issue 43 - Explanation = for=20 802.11i Considerations

This is a very interesting=20 solution.  The AC selects the KeyRSC and
performs the = 4-way=20 handshake.  The WTP sniffs the 4-way handshake
traffic =
and=20 grabs the KeyRSC value and uses it to initialize its own=20 counter.

Pat/Bob: Is this how the Cisco implementation=20 works?  I have to agree
with
Saravanan that I've yet = to see a=20 technical description of how Cisco
implements it.

IMHO, = this is=20 somewhat hackish, and it would be cleaner to have the AC
generate = the=20 KeyRSC and include it in the AddMobile message as Behcet=20
suggests.

--
t. charles clancy,=20 ph.d.  |  tcc@umd.edu  |  www.cs.umd.edu/~clancy

On Mon, 25 Sep 2006, = Peter=20 Nilsson J (LI/EAB) wrote:

> I think Saravanan has a point. = We did a=20 prototype impelementation of
the
> protocol a year ago when = it was=20 still called LWAPP. The way we solved
> this issue then was to = let the=20 WTP sniff on all CAPWAP data messages
> from the AC and when = message 3=20 of the 4-way handshake or message 1 of
> the groupkey handshake = was sent=20 the WTP inserted the correct RSC
before
> sending it off to = the=20 supplicant. To avoid the sniffing on all CAPWAP
> data messages = we would=20 need a mechanism with in CAPWAP to handle these
> two=20 messages.
>
> Peter Nilsson
>
> -----Original=20 Message-----
> From: Saravanan Govindan=20 [mailto:Saravanan.Govindan@sg.panasonic.com]
> Sent: den 22 = september=20 2006 11:03
> To: Margaret Wasserman
> Cc:=20 capwap@frascone.com
> Subject: Re: [Capwap] Issue 43 - = Explanation for=20 802.11i
Considerations
>
> Hi Margaret,
>
> = Thank=20 you for reviewing the discussion on this issue.
>
> The = issue here=20 is the working of IEEE 802.11i when the 802.11i
> authenticator = element=20 is at the AC and the 802.11i crypto element is
at
> the WTP.=20 Particularly, it is for the 4-way handshake between
> = authenticator and=20 supplicant.
>
> Now, the 4-way handshake requires knowing = the=20 value of KeyRSC sequence
> counter. The KeyRSC helps both = authenticator=20 and supplicant keep track
> of their exchanges. It serves to = protect=20 against threats by tracking
> sequential frames. The KeyRSC is=20 maintained at the at the point of
> encryption, i.e. just before = transmission over the wireless channel.
>
> In the case of = CAPWAP,=20 the 4-way handshake is between the AC
> (authenticator) and the = wireless=20 station (supplicant).
>
> The problem arises, when the=20 authenticator is at the AC and the crypto
> element (together = with=20 KeyRSC) is at the WTP. This is a fairly common
> design. Now in = this=20 case, the AC starts the 4-way handshake but it
does
> not = know the=20 value of the KeyRSC. The KeyRSC is maintained by the = WTP.
>
>=20 Based on this, the current CAPWAP specification does not allow for=20 a
way
> to conduct the 4-way handshake with the correct=20 KeyRSC.
>
> The functionality I would like to see is a way = for the=20 authenticator
> (AC) to use the correct prevailing value of = KeyRSC=20 (maintained by the
> WTP) in its 4-way = handshake.
>
> One=20 way to introduce this functionality in to CAPWAP is to have = part
of
>=20 the 4-way handshake be sent from AC to WTP. This will allow the = 4-way
>=20 handshake to use the correct value of the KeyRSC before being sent = to
>=20 the wireless station.
>
> I hope this helps clarify my = view on the=20 issue.
>
> Cheers,
>
>=20 Saravanan
>
>
>
>
>
>
>=20 -----Original Message-----
> From: Margaret Wasserman=20 [mailto:margaret@thingmagic.com]
> Sent: Thursday, September 21, = 2006=20 8:26 PM
> To: Saravanan Govindan
> Cc: Pat Calhoun = (pacalhou);=20 capwap@frascone.com
> Subject: Re: [Capwap] Issue 43 - = Explanation for=20 802.11i
Considerations
>
>
>
> Hi=20 again,
>
> Okay, I am even more confused than I thought I=20 was...
>
> Saravanan, you wrote:
>
> On Sep = 17, 2006,=20 at 10:24 PM, Saravanan Govindan wrote:
>
>>=20 Pat,
>>
>> The issue here is about how 802.11i = exchanges are=20 done when
>> authenticator is at the AC and crypto elements = are at=20 the WTP. This
is
>> the requirement.
>
> And, = in=20 response, Pat Calhoun wrote:
>
> On Sep 18, 2006, at 4:15 = PM, Pat=20 Calhoun (pacalhou) wrote:
>> The current specification allows = the=20 authenticator to reside in the
>> AC,
>> while the = data=20 packet crypto elements in the WTP. This feature is
>> already = in the=20 specification.
>
> Pat's message matches my reading of the = specification.
>
> So, Saravanan, what functionality are = you=20 asking for that is not
> already supported by the=20 specification?  And why do you think it is
>=20 necessary?  it will not be helpful to my understanding to=20 re-send
> your proposal or to cite the requirements=20 document...  Please
> summarize what functionality you = think=20 is missing from the current
> specification and why you think = that=20 functionality is necessary to
> support IEEE 802.11i or any = important=20 use case.
>
> At some point, the chairs may need to make a = consensus call on this
> issue, and I'd like to understand your = view and=20 make sure that it has
> been clearly communicated to the WG = before we=20 ask the WG to decide on
> this issue.
>
> = Thanks,
>=20 Margaret
>
>
>
>
>
>
>=20 = _________________________________________________________________
>= To=20 unsubscribe or modify your subscription options, please visit:
> = http://lists.frascone.com/mailman/listinfo/capwap
= >
>=20 Archives: http://lists.frascone.com/pipermail/capwap
> = = _________________________________________________________________
>= To=20 unsubscribe or modify your subscription options, please visit:
> = http://lists.frascone.com/mailman/listinfo/capwap
= >
>=20 Archives: http://lists.frascone.com/pipermail/capwap
>_________________________________________________________________
To = unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap
_______= __________________________________________________________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap

------_=_NextPart_001_01C6E24C.00FE6611-- --===============0377491641== 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 --===============0377491641==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Sep 27 16:29:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSg29-0002Ik-GF for capwap-archive@lists.ietf.org; Wed, 27 Sep 2006 16:29:33 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSg27-0005I6-Il for capwap-archive@lists.ietf.org; Wed, 27 Sep 2006 16:29:33 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id C87B63980AC for ; Wed, 27 Sep 2006 13:29:28 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6F39743009A for ; Wed, 27 Sep 2006 13:28:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6265639800F for ; Wed, 27 Sep 2006 13:28:00 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id D65403980AC for ; Wed, 27 Sep 2006 13:27:30 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 27 Sep 2006 13:27:30 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8RKRUZn006858; Wed, 27 Sep 2006 13:27:30 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8RKRUQV010810; Wed, 27 Sep 2006 13:27:30 -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); Wed, 27 Sep 2006 13:27:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Sep 2006 13:27:28 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC02133D01@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: Acbg0apVLhatsbAIQ02cILmAIvbQhAAwcJngAA7+dpAAKO4YIA== From: "Bob O'Hara (boohara)" To: "Cheng Hong" , "T. Charles Clancy" , "Peter Nilsson J (LI/EAB)" X-OriginalArrivalTime: 27 Sep 2006 20:27:30.0148 (UTC) FILETIME=[5AF0BA40:01C6E273] Authentication-Results: sj-dkim-1.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: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 5ba9b8496764663b12c333825fbf6b3d I am describing an implementation of CAPWAP that would be perfectly functional and compliant with a WTP providing 802.11 service with 802.11i. We could include a note to the effect that the group KeyRSC should be zero in the EAPOL-key frame. But, this is not new standards making. There is no need to change anything in 802.11. -Bob -----Original Message----- From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] Sent: Tuesday, September 26, 2006 6:03 PM To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson J (LI/EAB) Cc: capwap@frascone.com Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi Bob, If I understand your description below correct, you are proposing a solution (to the problem pointed out by Saravanan) by mandating the behavior of the AC to always set the KeyRSC in the 4-way handshake to zero. This is not a defined behavior according to the current 802.11 standard. Are you suggesting that we CAPWAP WG should specifically mandate that in our CAPWAP protocol spec, e.g. something like "a CAPWAP compatible AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, since not all AC implementation have to follow what you described. Or, are you planning to take this issue to TGm for 802.11 standard revision? (since based on your description, there is essentially no use of the KeyRSC). cheers Cheng Hong > -----Original Message----- > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > Sent: Wednesday, September 27, 2006 2:32 AM > To: T. Charles Clancy; Peter Nilsson J (LI/EAB) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Charles, Peter, > > Below is an expansion of a snippet from a thread on this > topic that I sent to the list on July 25, 2006. I think this > will be helpful to understand why the exchange that Saranavan > is requesting is not necessary. In fact, there are several > systems from several manufacturers in the field using > precursor protocols to CAPWAP that are Wi-Fi certified for > WPA2/802.11i operation using the protocol as it is described below. > > BTW, this whole discussion is about the KeyRSC for the group > key, not the pairwise key. This is so because the WTP and AC > both know the initial sequence counter value for the pairwise > key, since it has never been used to send a frame. 802.11i > requires the first frame sent on a key to use the sequence > counter value of 1. See 8.3.2.6 c) and > 8.3.3.4.3 c) in 802.11i for this requirement. > > The same is not true of the group key, i.e., after the WTP > begins operation, the AC will not know the value of the > sequence counter for the group key when it needs to complete > the EAPOL-key handshake with a newly associated STA. > However, as you will see from the tutorial below, it is not > necessary for the AC and WTP to exchange any information > about the group key KeyRSC for the protocol to operate as it > is intended. > > 1. A value for the KeyRSC in the EAPOL-key frame 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. A value of zero in > the EAPOL-key frame for the group key will always work. > > 3. The client STA will use the value of KeyRSC received in > the EAPOL-key frame to validate frame using the KeyMIC. > > 4. The client STA will also set its group key RSC to the > value received in KeyRSC, say, zero. > > 5. The value in the client STA's RSC will be compared against > the sequence number in subsequent received frames to identify > replay attacks. Any frame received with a sequence counter > value within the replay window will be checked to have a > valid MIC. If the MIC is not valid, the frame is dropped. > > 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, if the value is > greater than its current RSC value. Only the AP can meet > these criteria as the source of a frame received by the STA. > > 7. Please see item 6, immediately above, for the reason that > the AC and WTP do not need to coordinate and exchange the RSC. > > > The only possible attack mode is for the attacker to send > frames to the client STA between the time of the EAPOL-key > frame and the first frame encrypted with the group key. > During this time, the client will receive the frame and > proceed to validate its MIC. This is a potential attack > against the STA resources. But, the MIC validation is done > in the STA's > 802.11 chip and consumes no more resources than receiving any > other frame. Thus, the attack does not actually consume any > STA resources beyond those of receiving a frame. > > This attack is not unique to the use of the value zero for > the KeyRSC, either. The same attack is available to an > attacker at any other time, as well. It is no more nor less > effective at either time. > > For these reasons, the protocol is not in need of any changes > to address the issue raised by Saranavan. > > -Bob > -----Original Message----- > From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Monday, September 25, 2006 11:37 AM > To: Peter Nilsson J (LI/EAB) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > This is a very interesting solution. The AC selects the > KeyRSC and performs the 4-way handshake. The WTP sniffs the > 4-way handshake traffic and grabs the KeyRSC value and uses > it to initialize its own counter. > > Pat/Bob: Is this how the Cisco implementation works? I have > to agree with Saravanan that I've yet to see a technical > description of how Cisco implements it. > > IMHO, this is somewhat hackish, and it would be cleaner to > have the AC generate the KeyRSC and include it in the > AddMobile message as Behcet suggests. > > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > > > I think Saravanan has a point. We did a prototype impelementation of > the > > protocol a year ago when it was still called LWAPP. The way > we solved > > this issue then was to let the WTP sniff on all CAPWAP data > messages > > from the AC and when message 3 of the 4-way handshake or > message 1 of > > the groupkey handshake was sent the WTP inserted the correct RSC > before > > sending it off to the supplicant. To avoid the sniffing on > all CAPWAP > > data messages we would need a mechanism with in CAPWAP to > handle these > > two messages. > > > > Peter Nilsson > > > > -----Original Message----- > > From: Saravanan Govindan > [mailto:Saravanan.Govindan@sg.panasonic.com] > > Sent: den 22 september 2006 11:03 > > To: Margaret Wasserman > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > Hi Margaret, > > > > Thank you for reviewing the discussion on this issue. > > > > The issue here is the working of IEEE 802.11i when the 802.11i > > authenticator element is at the AC and the 802.11i crypto element is > at > > the WTP. Particularly, it is for the 4-way handshake between > > authenticator and supplicant. > > > > Now, the 4-way handshake requires knowing the value of > KeyRSC sequence > > counter. The KeyRSC helps both authenticator and supplicant > keep track > > of their exchanges. It serves to protect against threats by > tracking > > sequential frames. The KeyRSC is maintained at the at the point of > > encryption, i.e. just before transmission over the wireless channel. > > > > In the case of CAPWAP, the 4-way handshake is between the AC > > (authenticator) and the wireless station (supplicant). > > > > The problem arises, when the authenticator is at the AC and > the crypto > > element (together with KeyRSC) is at the WTP. This is a > fairly common > > design. Now in this case, the AC starts the 4-way handshake but it > does > > not know the value of the KeyRSC. The KeyRSC is maintained > by the WTP. > > > > Based on this, the current CAPWAP specification does not allow for a > way > > to conduct the 4-way handshake with the correct KeyRSC. > > > > The functionality I would like to see is a way for the authenticator > > (AC) to use the correct prevailing value of KeyRSC > (maintained by the > > WTP) in its 4-way handshake. > > > > One way to introduce this functionality in to CAPWAP is to have part > of > > the 4-way handshake be sent from AC to WTP. This will allow > the 4-way > > handshake to use the correct value of the KeyRSC before > being sent to > > the wireless station. > > > > I hope this helps clarify my view on the issue. > > > > Cheers, > > > > Saravanan > > > > > > > > > > > > > > -----Original Message----- > > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > > Sent: Thursday, September 21, 2006 8:26 PM > > To: Saravanan Govindan > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > > > > > Hi again, > > > > Okay, I am even more confused than I thought I was... > > > > Saravanan, you wrote: > > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > >> Pat, > >> > >> The issue here is about how 802.11i exchanges are done when > >> authenticator is at the AC and crypto elements are at the WTP. This > is > >> the requirement. > > > > And, in response, Pat Calhoun wrote: > > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: > >> The current specification allows the authenticator to > reside in the > >> AC, while the data packet crypto elements in the WTP. This > feature is > >> already in the specification. > > > > Pat's message matches my reading of the specification. > > > > So, Saravanan, what functionality are you asking for that is not > > already supported by the specification? And why do you think it is > > necessary? it will not be helpful to my understanding to > re-send your > > proposal or to cite the requirements document... Please summarize > > what functionality you think is missing from the current > specification > > and why you think that functionality is necessary to support IEEE > > 802.11i or any important use case. > > > > At some point, the chairs may need to make a consensus call on this > > issue, and I'd like to understand your view and make sure > that it has > > been clearly communicated to the WG before we ask the WG to > decide on > > this issue. > > > > 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 > > _________________________________________________________________ > > 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 > _________________________________________________________________ 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 Sep 27 17:15:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSgkC-0002X6-UD for capwap-archive@lists.ietf.org; Wed, 27 Sep 2006 17:15:04 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSgc3-0001YO-Af for capwap-archive@lists.ietf.org; Wed, 27 Sep 2006 17:06:41 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id D2F8839809D for ; Wed, 27 Sep 2006 14:06:37 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 5190243009A for ; Wed, 27 Sep 2006 10:38:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 45652398068 for ; Wed, 27 Sep 2006 10:38:39 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id 648A039803B for ; Wed, 27 Sep 2006 10:38:34 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 27 Sep 2006 10:38:34 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8RHcYEq004166; Wed, 27 Sep 2006 10:38:34 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8RHcXQX012951; Wed, 27 Sep 2006 10:38:33 -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, 27 Sep 2006 10:38:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Sep 2006 10:38:32 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2028E9188@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: Acbg0apVLhatsbAIQ02cILmAIvbQhAAwcJngAA7+dpAAIw1B0A== From: "Pat Calhoun (pacalhou)" To: "Cheng Hong" , "Bob O'Hara (boohara)" , "T. Charles Clancy" , "Peter Nilsson J (LI/EAB)" X-OriginalArrivalTime: 27 Sep 2006 17:38:33.0048 (UTC) FILETIME=[C0C20580:01C6E25B] 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 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] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 17cf8eab1d6bbd2874a56f9e3554d91d Bob's point is 802.11i works this way today. The AP (or in this case AC) can set the RSC to whatever value it wishes. Bob used zero (0) as an example. Implementations could use any other value, which would require some form of communication to the WTP, as suggested by Behcet. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > Sent: Tuesday, September 26, 2006 6:03 PM > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson J (LI/EAB) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Hi Bob, > > If I understand your description below correct, you are > proposing a solution (to the problem pointed out by > Saravanan) by mandating the behavior of the AC to always set > the KeyRSC in the 4-way handshake to zero. > > This is not a defined behavior according to the current > 802.11 standard. > Are you suggesting that we CAPWAP WG should specifically > mandate that in our CAPWAP protocol spec, e.g. something like > "a CAPWAP compatible AC MUST set KeyRSC to zero"? Otherwise, > the problem still exists, since not all AC implementation > have to follow what you described. > > Or, are you planning to take this issue to TGm for 802.11 > standard revision? (since based on your description, there is > essentially no use of the KeyRSC). > > cheers > > Cheng Hong > > > > > > -----Original Message----- > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > > Sent: Wednesday, September 27, 2006 2:32 AM > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > Charles, Peter, > > > > Below is an expansion of a snippet from a thread on this > topic that I > > sent to the list on July 25, 2006. I think this will be helpful to > > understand why the exchange that Saranavan is requesting is not > > necessary. In fact, there are several systems from several > > manufacturers in the field using precursor protocols to CAPWAP that > > are Wi-Fi certified for WPA2/802.11i operation using the > protocol as > > it is described below. > > > > BTW, this whole discussion is about the KeyRSC for the > group key, not > > the pairwise key. This is so because the WTP and AC both know the > > initial sequence counter value for the pairwise key, since it has > > never been used to send a frame. 802.11i requires the first frame > > sent on a key to use the sequence counter value of 1. See > 8.3.2.6 c) > > and > > 8.3.3.4.3 c) in 802.11i for this requirement. > > > > The same is not true of the group key, i.e., after the WTP begins > > operation, the AC will not know the value of the sequence > counter for > > the group key when it needs to complete the EAPOL-key > handshake with a > > newly associated STA. > > However, as you will see from the tutorial below, it is not > necessary > > for the AC and WTP to exchange any information about the group key > > KeyRSC for the protocol to operate as it is intended. > > > > 1. A value for the KeyRSC in the EAPOL-key frame 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. A value of zero in the EAPOL-key > > frame for the group key will always work. > > > > 3. The client STA will use the value of KeyRSC received in the > > EAPOL-key frame to validate frame using the KeyMIC. > > > > 4. The client STA will also set its group key RSC to the value > > received in KeyRSC, say, zero. > > > > 5. The value in the client STA's RSC will be compared against the > > sequence number in subsequent received frames to identify replay > > attacks. Any frame received with a sequence counter value > within the > > replay window will be checked to have a valid MIC. If the > MIC is not > > valid, the frame is dropped. > > > > 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, if the value is greater than its current RSC value. > Only the > > AP can meet these criteria as the source of a frame received by the > > STA. > > > > 7. Please see item 6, immediately above, for the reason that the AC > > and WTP do not need to coordinate and exchange the RSC. > > > > > > The only possible attack mode is for the attacker to send frames to > > the client STA between the time of the EAPOL-key frame and > the first > > frame encrypted with the group key. > > During this time, the client will receive the frame and proceed to > > validate its MIC. This is a potential attack against the STA > > resources. But, the MIC validation is done in the STA's > > 802.11 chip and consumes no more resources than receiving any other > > frame. Thus, the attack does not actually consume any STA > resources > > beyond those of receiving a frame. > > > > This attack is not unique to the use of the value zero for > the KeyRSC, > > either. The same attack is available to an attacker at any other > > time, as well. It is no more nor less effective at either time. > > > > For these reasons, the protocol is not in need of any changes to > > address the issue raised by Saranavan. > > > > -Bob > > -----Original Message----- > > From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > > Sent: Monday, September 25, 2006 11:37 AM > > To: Peter Nilsson J (LI/EAB) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > This is a very interesting solution. The AC selects the KeyRSC and > > performs the 4-way handshake. The WTP sniffs the 4-way handshake > > traffic and grabs the KeyRSC value and uses it to > initialize its own > > counter. > > > > Pat/Bob: Is this how the Cisco implementation works? I > have to agree > > with Saravanan that I've yet to see a technical description of how > > Cisco implements it. > > > > IMHO, this is somewhat hackish, and it would be cleaner to > have the AC > > generate the KeyRSC and include it in the AddMobile message > as Behcet > > suggests. > > > > -- > > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > > > > > I think Saravanan has a point. We did a prototype > impelementation of > > the > > > protocol a year ago when it was still called LWAPP. The way > > we solved > > > this issue then was to let the WTP sniff on all CAPWAP data > > messages > > > from the AC and when message 3 of the 4-way handshake or > > message 1 of > > > the groupkey handshake was sent the WTP inserted the correct RSC > > before > > > sending it off to the supplicant. To avoid the sniffing on > > all CAPWAP > > > data messages we would need a mechanism with in CAPWAP to > > handle these > > > two messages. > > > > > > Peter Nilsson > > > > > > -----Original Message----- > > > From: Saravanan Govindan > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > Sent: den 22 september 2006 11:03 > > > To: Margaret Wasserman > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > > > Hi Margaret, > > > > > > Thank you for reviewing the discussion on this issue. > > > > > > The issue here is the working of IEEE 802.11i when the 802.11i > > > authenticator element is at the AC and the 802.11i crypto > element is > > at > > > the WTP. Particularly, it is for the 4-way handshake between > > > authenticator and supplicant. > > > > > > Now, the 4-way handshake requires knowing the value of > > KeyRSC sequence > > > counter. The KeyRSC helps both authenticator and supplicant > > keep track > > > of their exchanges. It serves to protect against threats by > > tracking > > > sequential frames. The KeyRSC is maintained at the at the > point of > > > encryption, i.e. just before transmission over the > wireless channel. > > > > > > In the case of CAPWAP, the 4-way handshake is between the AC > > > (authenticator) and the wireless station (supplicant). > > > > > > The problem arises, when the authenticator is at the AC and > > the crypto > > > element (together with KeyRSC) is at the WTP. This is a > > fairly common > > > design. Now in this case, the AC starts the 4-way handshake but it > > does > > > not know the value of the KeyRSC. The KeyRSC is maintained > > by the WTP. > > > > > > Based on this, the current CAPWAP specification does not > allow for a > > way > > > to conduct the 4-way handshake with the correct KeyRSC. > > > > > > The functionality I would like to see is a way for the > authenticator > > > (AC) to use the correct prevailing value of KeyRSC > > (maintained by the > > > WTP) in its 4-way handshake. > > > > > > One way to introduce this functionality in to CAPWAP is > to have part > > of > > > the 4-way handshake be sent from AC to WTP. This will allow > > the 4-way > > > handshake to use the correct value of the KeyRSC before > > being sent to > > > the wireless station. > > > > > > I hope this helps clarify my view on the issue. > > > > > > Cheers, > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > > > Sent: Thursday, September 21, 2006 8:26 PM > > > To: Saravanan Govindan > > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > > > > > > > > > Hi again, > > > > > > Okay, I am even more confused than I thought I was... > > > > > > Saravanan, you wrote: > > > > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > > > >> Pat, > > >> > > >> The issue here is about how 802.11i exchanges are done when > > >> authenticator is at the AC and crypto elements are at > the WTP. This > > is > > >> the requirement. > > > > > > And, in response, Pat Calhoun wrote: > > > > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: > > >> The current specification allows the authenticator to > > reside in the > > >> AC, while the data packet crypto elements in the WTP. This > > feature is > > >> already in the specification. > > > > > > Pat's message matches my reading of the specification. > > > > > > So, Saravanan, what functionality are you asking for that is not > > > already supported by the specification? And why do you > think it is > > > necessary? it will not be helpful to my understanding to > > re-send your > > > proposal or to cite the requirements document... Please > summarize > > > what functionality you think is missing from the current > > specification > > > and why you think that functionality is necessary to support IEEE > > > 802.11i or any important use case. > > > > > > At some point, the chairs may need to make a consensus > call on this > > > issue, and I'd like to understand your view and make sure > > that it has > > > been clearly communicated to the WG before we ask the WG to > > decide on > > > this issue. > > > > > > 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 > > > _________________________________________________________________ > > > 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 > > > _________________________________________________________________ > 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 Sep 27 17:18:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSgne-0002wg-2F for capwap-archive@lists.ietf.org; Wed, 27 Sep 2006 17:18:38 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSgnb-00032v-Jd for capwap-archive@lists.ietf.org; Wed, 27 Sep 2006 17:18:38 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 29E803980AE for ; Wed, 27 Sep 2006 14:18:34 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 12B4643009A for ; Wed, 27 Sep 2006 13:25:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id DD19D398021 for ; Wed, 27 Sep 2006 13:25:33 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id 72588398098 for ; Wed, 27 Sep 2006 13:25:17 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 27 Sep 2006 13:25:17 -0700 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.20060308/8.12.11) with ESMTP id k8RKPHxr004436; Wed, 27 Sep 2006 13:25:17 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8RKPH1G026587; Wed, 27 Sep 2006 13:25:17 -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); Wed, 27 Sep 2006 13:25:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Sep 2006 13:25:15 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC02133CFC@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbhrK8d6E+n1WYUQouEbYdAQoMsqgAxjJTQ From: "Bob O'Hara (boohara)" To: "Behcet Sarikaya" X-OriginalArrivalTime: 27 Sep 2006 20:25:17.0587 (UTC) FILETIME=[0BED8630:01C6E273] Authentication-Results: sj-dkim-1.cisco.com; header.From=boohara@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.877 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_20_30, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1518497250==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: c52a6b2685a9a1f963a24bd74e30b072 This is a multi-part message in MIME format. --===============1518497250== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E273.0BBCFA2F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E273.0BBCFA2F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bechet,=20 =20 no, it would not hurt. But it is completely unnecessary, as is sending a copy of the Oxford English Dictionary to the WTP. but, we could do that, too. -Bob =20 =20 ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Tuesday, September 26, 2006 1:45 PM To: Bob O'Hara (boohara) Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations So, Bob, communicating the key RSC value to WTP would not hurt, would it? Or something to this effect, like AC initializing to zero of the group key KeyRSC of all WTPs? =20 Regards, =20 --behcet ----- Original Message ---- From: Bob O'Hara (boohara) To: T. Charles Clancy ; Peter Nilsson J (LI/EAB) Cc: capwap@frascone.com Sent: Tuesday, September 26, 2006 1:31:59 PM Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations Charles, Peter, Below is an expansion of a snippet from a thread on this topic that I sent to the list on July 25, 2006. I think this will be helpful to understand why the exchange that Saranavan is requesting is not necessary. In fact, there are several systems from several manufacturers in the field using precursor protocols to CAPWAP that are Wi-Fi certified for WPA2/802.11i operation using the protocol as it is described below. =20 BTW, this whole discussion is about the KeyRSC for the group key, not the pairwise key. This is so because the WTP and AC both know the initial sequence counter value for the pairwise key, since it has never been used to send a frame. 802.11i requires the first frame sent on a key to use the sequence counter value of 1. See 8.3.2.6 c) and 8.3.3.4.3 c) in 802.11i for this requirement. The same is not true of the group key, i.e., after the WTP begins operation, the AC will not know the value of the sequence counter for the group key when it needs to complete the EAPOL-key handshake with a newly associated STA. However, as you will see from the tutorial below, it is not necessary for the AC and WTP to exchange any information about the group key KeyRSC for the protocol to operate as it is intended. 1. A value for the KeyRSC in the EAPOL-key frame is necessary to calculate the KeyMIC.=20 2. This value does not need to bear any specific relationship to the RSC value maintained by the WTP. A value of zero in the EAPOL-key frame for the group key will always work. 3. The client STA will use the value of KeyRSC received in the EAPOL-key frame to validate frame using the KeyMIC.=20 4. The client STA will also set its group key RSC to the value received in KeyRSC, say, zero. 5. The value in the client STA's RSC will be compared against the sequence number in subsequent received frames to identify replay attacks. Any frame received with a sequence counter value within the replay window will be checked to have a valid MIC. If the MIC is not valid, the frame is dropped. 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, if the value is greater than its current RSC value. Only the AP can meet these criteria as the source of a frame received by the STA. 7. Please see item 6, immediately above, for the reason that the AC and WTP do not need to coordinate and exchange the RSC. The only possible attack mode is for the attacker to send frames to the client STA between the time of the EAPOL-key frame and the first frame encrypted with the group key. During this time, the client will receive the frame and proceed to validate its MIC. This is a potential attack against the STA resources. But, the MIC validation is done in the STA's 802.11 chip and consumes no more resources than receiving any other frame. Thus, the attack does not actually consume any STA resources beyond those of receiving a frame. This attack is not unique to the use of the value zero for the KeyRSC, either. The same attack is available to an attacker at any other time, as well. It is no more nor less effective at either time. For these reasons, the protocol is not in need of any changes to address the issue raised by Saranavan. -Bob=20 -----Original Message----- From: T. Charles Clancy [mailto:clancy@cs.umd.edu]=20 Sent: Monday, September 25, 2006 11:37 AM To: Peter Nilsson J (LI/EAB) Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations This is a very interesting solution. The AC selects the KeyRSC and=20 performs the 4-way handshake. The WTP sniffs the 4-way handshake traffic=20 and grabs the KeyRSC value and uses it to initialize its own counter. Pat/Bob: Is this how the Cisco implementation works? I have to agree with=20 Saravanan that I've yet to see a technical description of how Cisco=20 implements it. IMHO, this is somewhat hackish, and it would be cleaner to have the AC=20 generate the KeyRSC and include it in the AddMobile message as Behcet=20 suggests. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > I think Saravanan has a point. We did a prototype impelementation of the > protocol a year ago when it was still called LWAPP. The way we solved > this issue then was to let the WTP sniff on all CAPWAP data messages > from the AC and when message 3 of the 4-way handshake or message 1 of > the groupkey handshake was sent the WTP inserted the correct RSC before > sending it off to the supplicant. To avoid the sniffing on all CAPWAP > data messages we would need a mechanism with in CAPWAP to handle these > two messages. > > Peter Nilsson > > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: den 22 september 2006 11:03 > To: Margaret Wasserman > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > Hi Margaret, > > Thank you for reviewing the discussion on this issue. > > The issue here is the working of IEEE 802.11i when the 802.11i > authenticator element is at the AC and the 802.11i crypto element is at > the WTP. Particularly, it is for the 4-way handshake between > authenticator and supplicant. > > Now, the 4-way handshake requires knowing the value of KeyRSC sequence > counter. The KeyRSC helps both authenticator and supplicant keep track > of their exchanges. It serves to protect against threats by tracking > sequential frames. The KeyRSC is maintained at the at the point of > encryption, i.e. just before transmission over the wireless channel. > > In the case of CAPWAP, the 4-way handshake is between the AC > (authenticator) and the wireless station (supplicant). > > The problem arises, when the authenticator is at the AC and the crypto > element (together with KeyRSC) is at the WTP. This is a fairly common > design. Now in this case, the AC starts the 4-way handshake but it does > not know the value of the KeyRSC. The KeyRSC is maintained by the WTP. > > Based on this, the current CAPWAP specification does not allow for a way > to conduct the 4-way handshake with the correct KeyRSC. > > The functionality I would like to see is a way for the authenticator > (AC) to use the correct prevailing value of KeyRSC (maintained by the > WTP) in its 4-way handshake. > > One way to introduce this functionality in to CAPWAP is to have part of > the 4-way handshake be sent from AC to WTP. This will allow the 4-way > handshake to use the correct value of the KeyRSC before being sent to > the wireless station. > > I hope this helps clarify my view on the issue. > > Cheers, > > Saravanan > > > > > > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, September 21, 2006 8:26 PM > To: Saravanan Govindan > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > > > Hi again, > > Okay, I am even more confused than I thought I was... > > Saravanan, you wrote: > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > >> Pat, >> >> The issue here is about how 802.11i exchanges are done when >> authenticator is at the AC and crypto elements are at the WTP. This is >> the requirement. > > And, in response, Pat Calhoun wrote: > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: >> The current specification allows the authenticator to reside in the >> AC, >> while the data packet crypto elements in the WTP. This feature is >> already in the specification. > > Pat's message matches my reading of the specification. > > So, Saravanan, what functionality are you asking for that is not > already supported by the specification? And why do you think it is > necessary? it will not be helpful to my understanding to re-send > your proposal or to cite the requirements document... Please > summarize what functionality you think is missing from the current > specification and why you think that functionality is necessary to > support IEEE 802.11i or any important use case. > > At some point, the chairs may need to make a consensus call on this > issue, and I'd like to understand your view and make sure that it has > been clearly communicated to the WG before we ask the WG to decide on > this issue. > > 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 > _________________________________________________________________ > 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 ------_=_NextPart_001_01C6E273.0BBCFA2F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Bechet,
 
no, it would not hurt.  <sarcasm>But = it is=20 completely unnecessary, as is sending a copy of the Oxford English = Dictionary to=20 the WTP.  but, we could do that, = too.</sarcasm>

 -Bob
 

 

From: Behcet Sarikaya=20 [mailto:behcetsarikaya@yahoo.com]
Sent: Tuesday, September = 26, 2006=20 1:45 PM
To: Bob O'Hara (boohara)
Cc:=20 capwap@frascone.com
Subject: Re: [Capwap] Issue 43 - = Explanation for=20 802.11i Considerations

So,=20 Bob, communicating the key RSC value to WTP would not hurt, would = it? Or=20 something to this effect, like AC initializing to zero of the group key = KeyRSC=20 of all WTPs?   Regards,   --behcet

-----=20 Original Message ----
From: Bob O'Hara (boohara)=20 <boohara@cisco.com>
To: T. Charles Clancy = <clancy@cs.umd.edu>;=20 Peter Nilsson J (LI/EAB) <peter.j.nilsson@ericsson.com>
Cc:=20 capwap@frascone.com
Sent: Tuesday, September 26, 2006 1:31:59 = PM
Subject:=20 Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Charles, Peter,

Below is an expansion of a snippet from a = thread on=20 this topic that I
sent to the list on July 25, 2006.  I = think this=20 will be helpful to
understand why the exchange that Saranavan is = requesting=20 is not
necessary.  In fact, there are several systems from=20 several
manufacturers in the field using precursor protocols to = CAPWAP that=20 are
Wi-Fi certified for WPA2/802.11i operation using the protocol as = it=20 is
described below.  

BTW, this whole discussion is = about=20 the KeyRSC for the group key, not
the pairwise key.  This = is so=20 because the WTP and AC both know the
initial sequence counter value = for the=20 pairwise key, since it has never
been used to send a=20 frame.  802.11i requires the first frame sent on a
key to = use the=20 sequence counter value of 1.  See 8.3.2.6 c) and
8.3.3.4.3 = c) in=20 802.11i for this requirement.

The same is not true of the group = key,=20 i.e., after the WTP begins
operation, the AC will not know the value = of the=20 sequence counter for
the group key when it needs to complete the = EAPOL-key=20 handshake with a
newly associated STA.  However, as you = will see=20 from the tutorial below,
it is not necessary for the AC and WTP to = exchange=20 any information about
the group key KeyRSC for the protocol to = operate as it=20 is intended.

1. A value for the KeyRSC in the EAPOL-key frame is=20 necessary to
calculate the KeyMIC.

2. This value does not = need to=20 bear any specific relationship to the RSC
value maintained by the=20 WTP.  A value of zero in the EAPOL-key frame for
the group = key will=20 always work.

3. The client STA will use the value of KeyRSC = received in=20 the EAPOL-key
frame to validate frame using the KeyMIC.

4. = The client=20 STA will also set its group key RSC to the value received
in KeyRSC, = say,=20 zero.

5. The value in the client STA's RSC will be compared = against=20 the
sequence number in subsequent received frames to identify=20 replay
attacks.  Any frame received with a sequence counter = value=20 within the
replay window will be checked to have a valid = MIC.  If=20 the MIC is not
valid, the frame is dropped.

6. For any frame = that is=20 determined not to be a replay attack frame and
meets all other = validity and=20 authenticity requirements, the client STA
updates its RSC value to = the=20 sequence number in the received frame, if
the value is greater than = its=20 current RSC value.  Only the AP can meet
these criteria as = the=20 source of a frame received by the STA.

7. Please see item 6, = immediately=20 above, for the reason that the AC and
WTP do not need to coordinate = and=20 exchange the RSC.


The only possible attack mode is for the = attacker=20 to send frames to the
client STA between the time of the EAPOL-key = frame and=20 the first frame
encrypted with the group key.  During this = time,=20 the client will receive
the frame and proceed to validate its=20 MIC.  This is a potential attack
against the STA=20 resources.  But, the MIC validation is done in the = STA's
802.11=20 chip and consumes no more resources than receiving any=20 other
frame.  Thus, the attack does not actually consume = any STA=20 resources
beyond those of receiving a frame.

This attack is = not unique=20 to the use of the value zero for the KeyRSC,
either.  The = same=20 attack is available to an attacker at any other time,
as = well.  It=20 is no more nor less effective at either time.

For these reasons, = the=20 protocol is not in need of any changes to address
the issue raised by = Saranavan.

-Bob
-----Original Message-----
From: T. = Charles Clancy=20 [mailto:clancy@cs.umd.edu]
Sent: Monday, September 25, 2006 11:37 = AM
To:=20 Peter Nilsson J (LI/EAB)
Cc: capwap@frascone.com
Subject: Re: = [Capwap]=20 Issue 43 - Explanation for 802.11i Considerations

This is a very=20 interesting solution.  The AC selects the KeyRSC and =
performs the=20 4-way handshake.  The WTP sniffs the 4-way = handshake
traffic=20
and grabs the KeyRSC value and uses it to initialize its own=20 counter.

Pat/Bob: Is this how the Cisco implementation=20 works?  I have to agree
with
Saravanan that I've yet to = see a=20 technical description of how Cisco
implements it.

IMHO, this = is=20 somewhat hackish, and it would be cleaner to have the AC
generate = the KeyRSC=20 and include it in the AddMobile message as Behcet =
suggests.

--
t.=20 charles clancy,=20 ph.d.  |  tcc@umd.edu  |  www.cs.umd.edu/~clancy

On Mon, 25 Sep 2006, = Peter=20 Nilsson J (LI/EAB) wrote:

> I think Saravanan has a point. We = did a=20 prototype impelementation of
the
> protocol a year ago when it = was=20 still called LWAPP. The way we solved
> this issue then was to let = the WTP=20 sniff on all CAPWAP data messages
> from the AC and when message 3 = of the=20 4-way handshake or message 1 of
> the groupkey handshake was sent = the WTP=20 inserted the correct RSC
before
> sending it off to the = supplicant. To=20 avoid the sniffing on all CAPWAP
> data messages we would need a = mechanism=20 with in CAPWAP to handle these
> two messages.
>
> = Peter=20 Nilsson
>
> -----Original Message-----
> From: = Saravanan=20 Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
> Sent: den = 22=20 september 2006 11:03
> To: Margaret Wasserman
> Cc:=20 capwap@frascone.com
> Subject: Re: [Capwap] Issue 43 - Explanation = for=20 802.11i
Considerations
>
> Hi Margaret,
>
> = Thank you=20 for reviewing the discussion on this issue.
>
> The issue = here is=20 the working of IEEE 802.11i when the 802.11i
> authenticator = element is at=20 the AC and the 802.11i crypto element is
at
> the WTP. = Particularly, it=20 is for the 4-way handshake between
> authenticator and=20 supplicant.
>
> Now, the 4-way handshake requires knowing = the value=20 of KeyRSC sequence
> counter. The KeyRSC helps both authenticator = and=20 supplicant keep track
> of their exchanges. It serves to protect = against=20 threats by tracking
> sequential frames. The KeyRSC is maintained = at the=20 at the point of
> encryption, i.e. just before transmission over = the=20 wireless channel.
>
> In the case of CAPWAP, the 4-way = handshake is=20 between the AC
> (authenticator) and the wireless station=20 (supplicant).
>
> The problem arises, when the authenticator = is at=20 the AC and the crypto
> element (together with KeyRSC) is at the = WTP. This=20 is a fairly common
> design. Now in this case, the AC starts the = 4-way=20 handshake but it
does
> not know the value of the KeyRSC. The = KeyRSC is=20 maintained by the WTP.
>
> Based on this, the current CAPWAP = specification does not allow for a
way
> to conduct the 4-way = handshake=20 with the correct KeyRSC.
>
> The functionality I would like = to see=20 is a way for the authenticator
> (AC) to use the correct = prevailing value=20 of KeyRSC (maintained by the
> WTP) in its 4-way=20 handshake.
>
> One way to introduce this functionality in to = CAPWAP=20 is to have part
of
> the 4-way handshake be sent from AC to = WTP. This=20 will allow the 4-way
> handshake to use the correct value of the = KeyRSC=20 before being sent to
> the wireless station.
>
> I = hope this=20 helps clarify my view on the issue.
>
> = Cheers,
>
>=20 Saravanan
>
>
>
>
>
>
> = -----Original=20 Message-----
> From: Margaret Wasserman=20 [mailto:margaret@thingmagic.com]
> Sent: Thursday, September 21, = 2006 8:26=20 PM
> To: Saravanan Govindan
> Cc: Pat Calhoun (pacalhou);=20 capwap@frascone.com
> Subject: Re: [Capwap] Issue 43 - Explanation = for=20 802.11i
Considerations
>
>
>
> Hi=20 again,
>
> Okay, I am even more confused than I thought I=20 was...
>
> Saravanan, you wrote:
>
> On Sep 17, = 2006, at=20 10:24 PM, Saravanan Govindan wrote:
>
>>=20 Pat,
>>
>> The issue here is about how 802.11i = exchanges are=20 done when
>> authenticator is at the AC and crypto elements are = at the=20 WTP. This
is
>> the requirement.
>
> And, in = response,=20 Pat Calhoun wrote:
>
> On Sep 18, 2006, at 4:15 PM, Pat = Calhoun=20 (pacalhou) wrote:
>> The current specification allows the = authenticator=20 to reside in the
>> AC,
>> while the data packet = crypto=20 elements in the WTP. This feature is
>> already in the=20 specification.
>
> Pat's message matches my reading of the=20 specification.
>
> So, Saravanan, what functionality are you = asking=20 for that is not
> already supported by the = specification?  And=20 why do you think it is
> necessary?  it will not be = helpful to=20 my understanding to re-send
> your proposal or to cite the = requirements=20 document...  Please
> summarize what functionality you = think is=20 missing from the current
> specification and why you think that=20 functionality is necessary to
> support IEEE 802.11i or any = important use=20 case.
>
> At some point, the chairs may need to make a = consensus=20 call on this
> issue, and I'd like to understand your view and = make sure=20 that it has
> been clearly communicated to the WG before we ask = the WG to=20 decide on
> this issue.
>
> Thanks,
>=20 Margaret
>
>
>
>
>
>
>=20 _________________________________________________________________
>= To=20 unsubscribe or modify your subscription options, please visit:
> = http://lists.frascone.com/mailman/listinfo/capwap
= >
>=20 Archives: http://lists.frascone.com/pipermail/capwap
>=20 _________________________________________________________________
>= To=20 unsubscribe or modify your subscription options, please visit:
> = http://lists.frascone.com/mailman/listinfo/capwap
= >
>=20 Archives: http://lists.frascone.com/pipermail/capwap
>_________________________________________________________________
To = unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap
_______= __________________________________________________________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap

------_=_NextPart_001_01C6E273.0BBCFA2F-- --===============1518497250== 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 --===============1518497250==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Sep 27 17:23:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSgk6-0002Tn-2i for capwap-archive@lists.ietf.org; Wed, 27 Sep 2006 17:14:58 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSggM-0001pY-VK for capwap-archive@lists.ietf.org; Wed, 27 Sep 2006 17:11:07 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3E93939801A for ; Wed, 27 Sep 2006 14:11:06 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 6F52243009A for ; Wed, 27 Sep 2006 11:22:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5B9A6144803A for ; Wed, 27 Sep 2006 11:22:40 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by hermes.tigertech.net (Postfix) with ESMTP id 5128C144806E for ; Wed, 27 Sep 2006 11:22:35 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so304144pyu for ; Wed, 27 Sep 2006 11:22:34 -0700 (PDT) Received: by 10.35.96.7 with SMTP id y7mr1346233pyl; Wed, 27 Sep 2006 11:22:34 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Wed, 27 Sep 2006 11:22:34 -0700 (PDT) Message-ID: <26140d940609271122y5289343dt3b0d9ac7d10bf134@mail.gmail.com> Date: Wed, 27 Sep 2006 14:22:34 -0400 From: "Michael Montemurro" To: "Cheng Hong" In-Reply-To: <5F09D220B62F79418461A978CA0921BD012F1BBD@pslexc01.psl.local> MIME-Version: 1.0 References: <5F09D220B62F79418461A978CA0921BD012F1BBD@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.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0280463555==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 --===============0280463555== Content-Type: multipart/alternative; boundary="----=_Part_34420_247938.1159381354413" ------=_Part_34420_247938.1159381354413 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cheng, In the HCCA case, the TID case should work as well. I don't see why it wouldn't. Cheers, Mike On 9/26/06, Cheng Hong wrote: > > Hi Mike, > > It seems OK to use TID in the EDCA case. If the HCCA is used, would the > TID still be meaningful in mapping the priority? (Haven't check the 802.11standards in detail). > > cheers > > Cheng Hong > > ------------------------------ > *From:* Michael Montemurro [mailto:montemurro.michael@gmail.com] > *Sent:* Wednesday, September 27, 2006 12:24 AM > *To:* Cheng Hong > *Cc:* zhaoyujin 31390; capwap > *Subject:* Re: [Capwap] This is not need.: Proposed resolution to Issue > 214 -Prioritization of IEEE 802.1X frames > > > Cheng, > > Thanks for you input. > > Also, that's a good question. In my opinion, the CAPWAP priority should be > based on the TID(UP). Which means yes, the WTP would need to read into the > QoS control field. > > Cheers, > > Mike > > On 9/25/06, Cheng Hong wrote: > > > > Hi Mike, > > > > In this case, I tend to agree with the other Michael on the first point. > > > > > > However, on the mapping 802.11e priority back to CAPWAP priority, I am > > not really sure how that is done. Is it based on 802.11e AC or TID (UP)? > > For later case, does it mean the WTP need to read into the QoS Control > > Field? > > > > cheers > > > > Cheng Hong > > > > > > > > ------------------------------ > > *From:* Michael Montemurro [mailto:montemurro.michael@gmail.com ] > > *Sent:* Tuesday, September 26, 2006 1:17 AM > > *To:* Cheng Hong > > *Cc:* zhaoyujin 31390; capwap > > *Subject:* Re: [Capwap] This is not need.: Proposed resolution to Issue > > 214 -Prioritization of IEEE 802.1X frames > > > > > > Cheng Hong, > > > > In the CAPWAP draft, both wireless data and management frames are > > treated as CAPWAP data frames. Given that, all CAPWAP data traffic would > > need to go to the same logical instance of the AC. > > > > Cheers, > > > > Mike > > > > > > > > On 9/24/06, Cheng Hong wrote: > > > > > > Hi Michael & Michael, > > > > > > Sorry if the issue has already been discussed before. Just thinking if > > > the WTP does not differentiate 802.1X frames from normal data frames, > > > would it be possible that the 802.1X frames being forwarded to a > > > different AC instance than the one processing the control/management frames? > > > (in case different ACs are used to process the control and data channel) Is > > > this acceptable? > > > > > > cheers > > > > > > Cheng Hong > > > > > > > > > > > > > > > ------------------------------ > > > *From:* Michael Montemurro [mailto:montemurro.michael@gmail.com] > > > *Sent:* Sunday, September 24, 2006 3:18 AM > > > *To:* zhaoyujin 31390 > > > *Cc:* capwap > > > *Subject:* Re: [Capwap] This is not need.: Proposed resolution to > > > Issue 214 -Prioritization of IEEE 802.1X frames > > > > > > > > > Michael, > > > > > > Thanks. Is anybody else opinionated on this feature. > > > > > > Cheers, > > > > > > Mike > > > > > > > > > On 9/23/06, zhaoyujin 31390 wrote: > > > > > > > > Firstly, I have some doubt one this suggestion. > > > > > > > > 1. If CAPWAP difines like this, AP device must decode the payload > > > > frames of 802.11 frames. > > > > 2. Another problem, the 802.1x priority should be implement by > > > > 802.11e. When station sends 802.11 data frames, it can set 802.11epriority. AP should transfer > > > > 802.11e to actual CAPWAP packet priority. > > > > > > > > So that I think CAPWAP does not need consider the priority of 802.11data frames payload. > > > > > > > > Thanks > > > > Michael > > > > > > > > > > > > > > > > >Practically speaking, IEEE 802.1X frames should be transmitted at > > > > the same priority as >IEEE 802.11 Management frames. > > > > > > > > > >I will update Section 11.5, rename Quality of Service for IEEE > > > > 802.11 Control Messages >to "Quality > > > > >of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL > > > > frames" and add text to >indicate that IEEE 802.1X frames are sent > > > > at a higher priority. > > > > > > > > > >Cheers, > > > > > > > > > >Mike > > > > > > > > > > > > This e-mail and attachments contain confidential information from > > > > HUAWEI, which is intended only for the person or entity whose address is > > > > listed above. Any use of the information contained herein in any way > > > > (including, but not limited to, total or partial disclosure, reproduction, > > > > or dissemination) by persons other than the intended recipient's) is > > > > prohibited. If you receive this e-mail in error, please notify the sender by > > > > phone or email > > > > immediately and delete it! > > > > > > > > > > > > > > > > Practically speaking, IEEE 802.1X frames should be transmitted at > > > > the same priority as IEEE 802.11 Management frames. > > > > > > > > I will update Section 11.5, rename Quality of Service for IEEE > > > > 802.11 Control Messages to "Quality > > > > of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL > > > > frames" and add text to indicate that IEEE 802.1X frames are sent at > > > > a higher priority. > > > > > > > > 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 > > > > > > > > > > > > > > > > > > ------=_Part_34420_247938.1159381354413 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Cheng,
 
In the HCCA case, the TID case should work as well. I don't see why it wouldn't.
 
Cheers,
 
Mike

 
On 9/26/06, Cheng Hong <Hong.Cheng@sg.panasonic.com> wrote:
Hi Mike,
 
It seems OK to use TID in the EDCA case. If the HCCA is used, would the TID still be meaningful in mapping the priority? (Haven't check the 802.11 standards in detail).
 
cheers
 
Cheng Hong

From: Michael Montemurro [mailto:montemurro.michael@gmail.com ]
Sent: Wednesday, September 27, 2006 12:24 AM

To: Cheng Hong
Cc: zhaoyujin 31390; capwap
Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames

 
Cheng,
 
Thanks for you input.
 
Also, that's a good question. In my opinion, the CAPWAP priority should be based on the TID(UP). Which means yes, the WTP would need to read into the QoS control field.
 
Cheers,
 
Mike
 
On 9/25/06, Cheng Hong <Hong.Cheng@sg.panasonic.com > wrote:
Hi Mike,
 
In this case, I tend to agree with the other Michael on the first point.
 
However, on the mapping 802.11e priority back to CAPWAP priority, I am not really sure how that is done. Is it based on 802.11e AC or TID (UP)? For later case, does it mean the WTP need to read into the QoS Control Field?
 
cheers
 
Cheng Hong
 
 
From: Michael Montemurro [mailto:montemurro.michael@gmail.com ]
Sent: Tuesday, September 26, 2006 1:17 AM
To: Cheng Hong
Cc: zhaoyujin 31390; capwap

Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames

 
Cheng Hong,
 
In the CAPWAP draft, both wireless data and management frames are treated as CAPWAP data frames. Given that, all CAPWAP data traffic would need to go to the same logical instance of the AC.
 
Cheers,
 
Mike


 
On 9/24/06, Cheng Hong <Hong.Cheng@sg.panasonic.com > wrote:
Hi Michael & Michael,
 
Sorry if the issue has already been discussed before. Just thinking if the WTP does not differentiate 802.1X frames from normal data frames, would it be possible that the 802.1X frames being forwarded to a different AC instance than the one processing the control/management frames? (in case different ACs are used to process the control and data channel) Is this acceptable?
 
cheers
 
Cheng Hong
 
 
 

From: Michael Montemurro [mailto:montemurro.michael@gmail.com]
Sent: Sunday, September 24, 2006 3:18 AM
To: zhaoyujin 31390
Cc: capwap
Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames

 
Michael,
 
Thanks. Is anybody else opinionated on this feature.
 
Cheers,
 
Mike

 
On 9/23/06, zhaoyujin 31390 <zhaoyujin@huawei.com > wrote:
Firstly, I have some doubt one this suggestion.

1. If CAPWAP difines like this, AP device must decode the payload frames of 802.11 frames.
2. Another problem, the 802.1x priority should be implement by 802.11e. When station sends 802.11 data frames, it can set 802.11e priority. AP should transfer 802.11e to actual CAPWAP packet priority.

So that I think CAPWAP does not need consider the priority of 802.11 data frames payload.

Thanks
Michael



>Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as >IEEE 802.11 Management frames.
>
>I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages >to "Quality
>of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to >indicate that IEEE 802.1X frames are sent at a higher priority.
>
>Cheers,
>
>Mike


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

 

Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as IEEE 802.11 Management frames.
 
I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages to "Quality
of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to indicate that IEEE 802.1X frames are sent at a higher priority.
 
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






------=_Part_34420_247938.1159381354413-- --===============0280463555== 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 --===============0280463555==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Sep 27 19:53:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSjDX-0006V4-Ra for capwap-archive@lists.ietf.org; Wed, 27 Sep 2006 19:53:31 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSjDT-0008F1-Ep for capwap-archive@lists.ietf.org; Wed, 27 Sep 2006 19:53:31 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id E2790398009 for ; Wed, 27 Sep 2006 16:53:16 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3C62643009A for ; Wed, 27 Sep 2006 16:45:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 23C9E144803A for ; Wed, 27 Sep 2006 16:45:37 -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 78FE31448027 for ; Wed, 27 Sep 2006 16:45:30 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so386860pyu for ; Wed, 27 Sep 2006 16:45:29 -0700 (PDT) Received: by 10.35.102.18 with SMTP id e18mr2461169pym; Wed, 27 Sep 2006 16:45:29 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Wed, 27 Sep 2006 16:45:29 -0700 (PDT) Message-ID: <26140d940609271645p1f2db0cds2dc52b2ffb2d3e90@mail.gmail.com> Date: Wed, 27 Sep 2006 19:45:29 -0400 From: "Michael Montemurro" To: "Bob O'Hara (boohara)" In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC02133CFC@xmb-sjc-237.amer.cisco.com> MIME-Version: 1.0 References: <17B8C6DE4E228348B4939BDA6B05A9DC02133CFC@xmb-sjc-237.amer.cisco.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.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0237623755==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 563af5038a5e1dade28c8affc0fff375 --===============0237623755== Content-Type: multipart/alternative; boundary="----=_Part_39618_26389767.1159400729375" ------=_Part_39618_26389767.1159400729375 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Actually, in CAPWAP-02, the keyRSC is sent to the WTP on the group key update. But as yet, we have left the Oxford English Dictionary out. :-) Cheers, Mike On 9/27/06, Bob O'Hara (boohara) wrote: > > Bechet, > > no, it would not hurt. But it is completely unnecessary, as is > sending a copy of the Oxford English Dictionary to the WTP. but, we could > do that, too. > > -Bob > > > > ------------------------------ > *From:* Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > *Sent:* Tuesday, September 26, 2006 1:45 PM > *To:* Bob O'Hara (boohara) > *Cc:* capwap@frascone.com > *Subject:* Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > > So, Bob, communicating the key RSC value to WTP would not hurt, would it? > Or something to this effect, like AC initializing to zero of the group key > KeyRSC of all WTPs? > > Regards, > > --behcet > > > ----- Original Message ---- > From: Bob O'Hara (boohara) > To: T. Charles Clancy ; Peter Nilsson J (LI/EAB) < > peter.j.nilsson@ericsson.com> > Cc: capwap@frascone.com > Sent: Tuesday, September 26, 2006 1:31:59 PM > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > Charles, Peter, > > Below is an expansion of a snippet from a thread on this topic that I > sent to the list on July 25, 2006. I think this will be helpful to > understand why the exchange that Saranavan is requesting is not > necessary. In fact, there are several systems from several > manufacturers in the field using precursor protocols to CAPWAP that are > Wi-Fi certified for WPA2/802.11i operation using the protocol as it is > described below. > > BTW, this whole discussion is about the KeyRSC for the group key, not > the pairwise key. This is so because the WTP and AC both know the > initial sequence counter value for the pairwise key, since it has never > been used to send a frame. 802.11i requires the first frame sent on a > key to use the sequence counter value of 1. See 8.3.2.6 c) and > 8.3.3.4.3 c) in 802.11i for this requirement. > > The same is not true of the group key, i.e., after the WTP begins > operation, the AC will not know the value of the sequence counter for > the group key when it needs to complete the EAPOL-key handshake with a > newly associated STA. However, as you will see from the tutorial below, > it is not necessary for the AC and WTP to exchange any information about > the group key KeyRSC for the protocol to operate as it is intended. > > 1. A value for the KeyRSC in the EAPOL-key frame 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. A value of zero in the EAPOL-key frame for > the group key will always work. > > 3. The client STA will use the value of KeyRSC received in the EAPOL-key > frame to validate frame using the KeyMIC. > > 4. The client STA will also set its group key RSC to the value received > in KeyRSC, say, zero. > > 5. The value in the client STA's RSC will be compared against the > sequence number in subsequent received frames to identify replay > attacks. Any frame received with a sequence counter value within the > replay window will be checked to have a valid MIC. If the MIC is not > valid, the frame is dropped. > > 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, if > the value is greater than its current RSC value. Only the AP can meet > these criteria as the source of a frame received by the STA. > > 7. Please see item 6, immediately above, for the reason that the AC and > WTP do not need to coordinate and exchange the RSC. > > > The only possible attack mode is for the attacker to send frames to the > client STA between the time of the EAPOL-key frame and the first frame > encrypted with the group key. During this time, the client will receive > the frame and proceed to validate its MIC. This is a potential attack > against the STA resources. But, the MIC validation is done in the STA's > 802.11 chip and consumes no more resources than receiving any other > frame. Thus, the attack does not actually consume any STA resources > beyond those of receiving a frame. > > This attack is not unique to the use of the value zero for the KeyRSC, > either. The same attack is available to an attacker at any other time, > as well. It is no more nor less effective at either time. > > For these reasons, the protocol is not in need of any changes to address > the issue raised by Saranavan. > > -Bob > -----Original Message----- > From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Monday, September 25, 2006 11:37 AM > To: Peter Nilsson J (LI/EAB) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > This is a very interesting solution. The AC selects the KeyRSC and > performs the 4-way handshake. The WTP sniffs the 4-way handshake > traffic > and grabs the KeyRSC value and uses it to initialize its own counter. > > Pat/Bob: Is this how the Cisco implementation works? I have to agree > with > Saravanan that I've yet to see a technical description of how Cisco > implements it. > > IMHO, this is somewhat hackish, and it would be cleaner to have the AC > generate the KeyRSC and include it in the AddMobile message as Behcet > suggests. > > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > > > I think Saravanan has a point. We did a prototype impelementation of > the > > protocol a year ago when it was still called LWAPP. The way we solved > > this issue then was to let the WTP sniff on all CAPWAP data messages > > from the AC and when message 3 of the 4-way handshake or message 1 of > > the groupkey handshake was sent the WTP inserted the correct RSC > before > > sending it off to the supplicant. To avoid the sniffing on all CAPWAP > > data messages we would need a mechanism with in CAPWAP to handle these > > two messages. > > > > Peter Nilsson > > > > -----Original Message----- > > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > > Sent: den 22 september 2006 11:03 > > To: Margaret Wasserman > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > Hi Margaret, > > > > Thank you for reviewing the discussion on this issue. > > > > The issue here is the working of IEEE 802.11i when the 802.11i > > authenticator element is at the AC and the 802.11i crypto element is > at > > the WTP. Particularly, it is for the 4-way handshake between > > authenticator and supplicant. > > > > Now, the 4-way handshake requires knowing the value of KeyRSC sequence > > counter. The KeyRSC helps both authenticator and supplicant keep track > > of their exchanges. It serves to protect against threats by tracking > > sequential frames. The KeyRSC is maintained at the at the point of > > encryption, i.e. just before transmission over the wireless channel. > > > > In the case of CAPWAP, the 4-way handshake is between the AC > > (authenticator) and the wireless station (supplicant). > > > > The problem arises, when the authenticator is at the AC and the crypto > > element (together with KeyRSC) is at the WTP. This is a fairly common > > design. Now in this case, the AC starts the 4-way handshake but it > does > > not know the value of the KeyRSC. The KeyRSC is maintained by the WTP. > > > > Based on this, the current CAPWAP specification does not allow for a > way > > to conduct the 4-way handshake with the correct KeyRSC. > > > > The functionality I would like to see is a way for the authenticator > > (AC) to use the correct prevailing value of KeyRSC (maintained by the > > WTP) in its 4-way handshake. > > > > One way to introduce this functionality in to CAPWAP is to have part > of > > the 4-way handshake be sent from AC to WTP. This will allow the 4-way > > handshake to use the correct value of the KeyRSC before being sent to > > the wireless station. > > > > I hope this helps clarify my view on the issue. > > > > Cheers, > > > > Saravanan > > > > > > > > > > > > > > -----Original Message----- > > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > > Sent: Thursday, September 21, 2006 8:26 PM > > To: Saravanan Govindan > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > > > > > Hi again, > > > > Okay, I am even more confused than I thought I was... > > > > Saravanan, you wrote: > > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > >> Pat, > >> > >> The issue here is about how 802.11i exchanges are done when > >> authenticator is at the AC and crypto elements are at the WTP. This > is > >> the requirement. > > > > And, in response, Pat Calhoun wrote: > > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: > >> The current specification allows the authenticator to reside in the > >> AC, > >> while the data packet crypto elements in the WTP. This feature is > >> already in the specification. > > > > Pat's message matches my reading of the specification. > > > > So, Saravanan, what functionality are you asking for that is not > > already supported by the specification? And why do you think it is > > necessary? it will not be helpful to my understanding to re-send > > your proposal or to cite the requirements document... Please > > summarize what functionality you think is missing from the current > > specification and why you think that functionality is necessary to > > support IEEE 802.11i or any important use case. > > > > At some point, the chairs may need to make a consensus call on this > > issue, and I'd like to understand your view and make sure that it has > > been clearly communicated to the WG before we ask the WG to decide on > > this issue. > > > > 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 > > _________________________________________________________________ > > 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 > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_39618_26389767.1159400729375 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Actually, in CAPWAP-02, the keyRSC is sent to the WTP on the group key update.
 
But as yet, we have left the Oxford English Dictionary out. :-)
 
Cheers,
 
Mike

 
On 9/27/06, Bob O'Hara (boohara) <boohara@cisco.com> wrote:
Bechet,
 
no, it would not hurt.  <sarcasm>But it is completely unnecessary, as is sending a copy of the Oxford English Dictionary to the WTP.  but, we could do that, too.</sarcasm>

 -Bob
 

 

From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]
Sent: Tuesday, September 26, 2006 1:45 PM
To: Bob O'Hara (boohara)
Cc: capwap@frascone.com
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

 
So, Bob, communicating the key RSC value to WTP would not hurt, would it?
Or something to this effect, like AC initializing to zero of the group key KeyRSC of all WTPs?
 
Regards,
 
--behcet

 
----- Original Message ----
From: Bob O'Hara (boohara) < boohara@cisco.com>
To: T. Charles Clancy <clancy@cs.umd.edu>; Peter Nilsson J (LI/EAB) < peter.j.nilsson@ericsson.com>
Cc: capwap@frascone.com
Sent: Tuesday, September 26, 2006 1:31:59 PM
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Charles, Peter,

Below is an expansion of a snippet from a thread on this topic that I
sent to the list on July 25, 2006.  I think this will be helpful to
understand why the exchange that Saranavan is requesting is not
necessary.  In fact, there are several systems from several
manufacturers in the field using precursor protocols to CAPWAP that are
Wi-Fi certified for WPA2/802.11i operation using the protocol as it is
described below.  

BTW, this whole discussion is about the KeyRSC for the group key, not
the pairwise key.  This is so because the WTP and AC both know the
initial sequence counter value for the pairwise key, since it has never
been used to send a frame.  802.11i requires the first frame sent on a
key to use the sequence counter value of 1.  See 8.3.2.6 c) and
8.3.3.4.3 c) in 802.11i for this requirement.

The same is not true of the group key, i.e., after the WTP begins
operation, the AC will not know the value of the sequence counter for
the group key when it needs to complete the EAPOL-key handshake with a
newly associated STA.  However, as you will see from the tutorial below,
it is not necessary for the AC and WTP to exchange any information about
the group key KeyRSC for the protocol to operate as it is intended.

1. A value for the KeyRSC in the EAPOL-key frame 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.  A value of zero in the EAPOL-key frame for
the group key will always work.

3. The client STA will use the value of KeyRSC received in the EAPOL-key
frame to validate frame using the KeyMIC.

4. The client STA will also set its group key RSC to the value received
in KeyRSC, say, zero.

5. The value in the client STA's RSC will be compared against the
sequence number in subsequent received frames to identify replay
attacks.  Any frame received with a sequence counter value within the
replay window will be checked to have a valid MIC.  If the MIC is not
valid, the frame is dropped.

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, if
the value is greater than its current RSC value.  Only the AP can meet
these criteria as the source of a frame received by the STA.

7. Please see item 6, immediately above, for the reason that the AC and
WTP do not need to coordinate and exchange the RSC.


The only possible attack mode is for the attacker to send frames to the
client STA between the time of the EAPOL-key frame and the first frame
encrypted with the group key.  During this time, the client will receive
the frame and proceed to validate its MIC.  This is a potential attack
against the STA resources.  But, the MIC validation is done in the STA's
802.11 chip and consumes no more resources than receiving any other
frame.  Thus, the attack does not actually consume any STA resources
beyond those of receiving a frame.

This attack is not unique to the use of the value zero for the KeyRSC,
either.  The same attack is available to an attacker at any other time,
as well.  It is no more nor less effective at either time.

For these reasons, the protocol is not in need of any changes to address
the issue raised by Saranavan.

-Bob
-----Original Message-----
From: T. Charles Clancy [mailto:clancy@cs.umd.edu]
Sent: Monday, September 25, 2006 11:37 AM
To: Peter Nilsson J (LI/EAB)
Cc: capwap@frascone.com
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

This is a very interesting solution.  The AC selects the KeyRSC and
performs the 4-way handshake.  The WTP sniffs the 4-way handshake
traffic
and grabs the KeyRSC value and uses it to initialize its own counter.

Pat/Bob: Is this how the Cisco implementation works?  I have to agree
with
Saravanan that I've yet to see a technical description of how Cisco
implements it.

IMHO, this is somewhat hackish, and it would be cleaner to have the AC
generate the KeyRSC and include it in the AddMobile message as Behcet
suggests.

--
t. charles clancy, ph.d.  |   tcc@umd.edu  |  www.cs.umd.edu/~clancy

On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote:

> I think Saravanan has a point. We did a prototype impelementation of
the
> protocol a year ago when it was still called LWAPP. The way we solved
> this issue then was to let the WTP sniff on all CAPWAP data messages
> from the AC and when message 3 of the 4-way handshake or message 1 of
> the groupkey handshake was sent the WTP inserted the correct RSC
before
> sending it off to the supplicant. To avoid the sniffing on all CAPWAP
> data messages we would need a mechanism with in CAPWAP to handle these
> two messages.
>
> Peter Nilsson
>
> -----Original Message-----
> From: Saravanan Govindan [mailto: Saravanan.Govindan@sg.panasonic.com]
> Sent: den 22 september 2006 11:03
> To: Margaret Wasserman
> Cc: capwap@frascone.com
> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
Considerations
>
> Hi Margaret,
>
> Thank you for reviewing the discussion on this issue.
>
> The issue here is the working of IEEE 802.11i when the 802.11i
> authenticator element is at the AC and the 802.11i crypto element is
at
> the WTP. Particularly, it is for the 4-way handshake between
> authenticator and supplicant.
>
> Now, the 4-way handshake requires knowing the value of KeyRSC sequence
> counter. The KeyRSC helps both authenticator and supplicant keep track
> of their exchanges. It serves to protect against threats by tracking
> sequential frames. The KeyRSC is maintained at the at the point of
> encryption, i.e. just before transmission over the wireless channel.
>
> In the case of CAPWAP, the 4-way handshake is between the AC
> (authenticator) and the wireless station (supplicant).
>
> The problem arises, when the authenticator is at the AC and the crypto
> element (together with KeyRSC) is at the WTP. This is a fairly common
> design. Now in this case, the AC starts the 4-way handshake but it
does
> not know the value of the KeyRSC. The KeyRSC is maintained by the WTP.
>
> Based on this, the current CAPWAP specification does not allow for a
way
> to conduct the 4-way handshake with the correct KeyRSC.
>
> The functionality I would like to see is a way for the authenticator
> (AC) to use the correct prevailing value of KeyRSC (maintained by the
> WTP) in its 4-way handshake.
>
> One way to introduce this functionality in to CAPWAP is to have part
of
> the 4-way handshake be sent from AC to WTP. This will allow the 4-way
> handshake to use the correct value of the KeyRSC before being sent to
> the wireless station.
>
> I hope this helps clarify my view on the issue.
>
> Cheers,
>
> Saravanan
>
>
>
>
>
>
> -----Original Message-----
> From: Margaret Wasserman [mailto:margaret@thingmagic.com]
> Sent: Thursday, September 21, 2006 8:26 PM
> To: Saravanan Govindan
> Cc: Pat Calhoun (pacalhou); capwap@frascone.com
> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
Considerations
>
>
>
> Hi again,
>
> Okay, I am even more confused than I thought I was...
>
> Saravanan, you wrote:
>
> On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote:
>
>> Pat,
>>
>> The issue here is about how 802.11i exchanges are done when
>> authenticator is at the AC and crypto elements are at the WTP. This
is
>> the requirement.
>
> And, in response, Pat Calhoun wrote:
>
> On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote:
>> The current specification allows the authenticator to reside in the
>> AC,
>> while the data packet crypto elements in the WTP. This feature is
>> already in the specification.
>
> Pat's message matches my reading of the specification.
>
> So, Saravanan, what functionality are you asking for that is not
> already supported by the specification?  And why do you think it is
> necessary?  it will not be helpful to my understanding to re-send
> your proposal or to cite the requirements document...  Please
> summarize what functionality you think is missing from the current
> specification and why you think that functionality is necessary to
> support IEEE 802.11i or any important use case.
>
> At some point, the chairs may need to make a consensus call on this
> issue, and I'd like to understand your view and make sure that it has
> been clearly communicated to the WG before we ask the WG to decide on
> this issue.
>
> 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
> _________________________________________________________________
> 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

 

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

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


------=_Part_39618_26389767.1159400729375-- --===============0237623755== 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 --===============0237623755==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Sep 27 21:22:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSkbv-0001qg-B9 for capwap-archive@lists.ietf.org; Wed, 27 Sep 2006 21:22:47 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSkbs-00025c-36 for capwap-archive@lists.ietf.org; Wed, 27 Sep 2006 21:22:47 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id A8DD9398055 for ; Wed, 27 Sep 2006 18:22:42 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 5F7A843009A for ; Wed, 27 Sep 2006 18:20:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 517C0398067 for ; Wed, 27 Sep 2006 18:20:58 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 37C08398028 for ; Wed, 27 Sep 2006 18:20:53 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id k8S1KpKw015696; Thu, 28 Sep 2006 10:20:51 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k8S1Kr704022; Thu, 28 Sep 2006 10:20:53 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with ESMTP id k8S1Kp500417; Thu, 28 Sep 2006 10:20:51 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Sep 2006 09:19:56 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F1DAF@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] This is not need.: Proposed resolution to Issue 214-Prioritization of IEEE 802.1X frames Thread-Index: AcbieUNFx2Heibn8RoyIXIp63oas0QAIb/jg From: "Cheng Hong" To: "Michael Montemurro" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.452 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_60_70, HTML_MESSAGE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214-Prioritization of IEEE 802.1X frames X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0707550228==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 2ea7cf203b0fe53e1e7e4a76478f388c This is a multi-part message in MIME format. --===============0707550228== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E29C.35C21BA2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E29C.35C21BA2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike, =20 In the HCCA case, the TID value is in the range of 8 to 15, and according to clause 6.1.1.1.1 point b: =20 "b) QoS subtypes, in which case the QAP shall infer the UP value from the TID in the QoS Control field directly for TID values between 0 and 7. For TID values between 8 and 15, the QAP shall extract the UP value in the UP subfield of the TS Info field in the associated TSPEC or from the UP field in the associated TCLAS (traffic classification) element, as applicable." =20 It seems that the WTP needs to do much more to obtain the actual UP value. In case the TSPEC or TCLAS elemets are located at the AC, how would the WTP get the UP value in the HCCA case? =20 Or is there any place that prevents sending EAPOL frames using HCCA? If that is the case, it is not a problem. But, then again, all the data traffic sent using HCCA will have difficulty to obtain the correct priority in CAPWAP delivery. =20 cheers =20 Cheng Hong =20 =20 =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Thursday, September 28, 2006 2:23 AM To: Cheng Hong Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214-Prioritization of IEEE 802.1X frames =09 =09 Cheng, =20 In the HCCA case, the TID case should work as well. I don't see why it wouldn't. =20 Cheers, =20 Mike =09 =20 On 9/26/06, Cheng Hong wrote:=20 Hi Mike,=20 =20 It seems OK to use TID in the EDCA case. If the HCCA is used, would the TID still be meaningful in mapping the priority? (Haven't check the 802.11 standards in detail).=20 =20 cheers =20 Cheng Hong=20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com ]=20 Sent: Wednesday, September 27, 2006 12:24 AM=20 =09 To: Cheng Hong Cc: zhaoyujin 31390; capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames =09 =20 =09 Cheng, =20 Thanks for you input. =20 Also, that's a good question. In my opinion, the CAPWAP priority should be based on the TID(UP). Which means yes, the WTP would need to read into the QoS control field. =20 Cheers, =20 Mike =20 On 9/25/06, Cheng Hong wrote:=20 Hi Mike, =20 In this case, I tend to agree with the other Michael on the first point.=20 =20 However, on the mapping 802.11e priority back to CAPWAP priority, I am not really sure how that is done. Is it based on 802.11e AC or TID (UP)? For later case, does it mean the WTP need to read into the QoS Control Field?=20 =20 cheers =20 Cheng Hong =20 =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com ]=20 Sent: Tuesday, September 26, 2006 1:17 AM To: Cheng Hong Cc: zhaoyujin 31390; capwap=20 =09 Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames =09 =20 =09 Cheng Hong, =20 In the CAPWAP draft, both wireless data and management frames are treated as CAPWAP data frames. Given that, all CAPWAP data traffic would need to go to the same logical instance of the AC. =20 Cheers, =20 Mike =20 On 9/24/06, Cheng Hong wrote:=20 Hi Michael & Michael, =20 Sorry if the issue has already been discussed before. Just thinking if the WTP does not differentiate 802.1X frames from normal data frames, would it be possible that the 802.1X frames being forwarded to a different AC instance than the one processing the control/management frames? (in case different ACs are used to process the control and data channel) Is this acceptable? =20 cheers =20 Cheng Hong =20 =20 =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Sunday, September 24, 2006 3:18 AM To: zhaoyujin 31390 Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames=20 =09 =20 =09 Michael, =20 Thanks. Is anybody else opinionated on this feature.=20 =20 Cheers, =20 Mike =09 =20 On 9/23/06, zhaoyujin 31390 wrote:=20 Firstly, I have some doubt one this suggestion. =09 1. If CAPWAP difines like this, AP device must decode the payload frames of 802.11 frames. 2. Another problem, the 802.1x priority should be implement by 802.11e. When station sends 802.11 data frames, it can set 802.11e priority. AP should transfer 802.11e to actual CAPWAP packet priority. =09 So that I think CAPWAP does not need consider the priority of 802.11 data frames payload.=20 =09 Thanks Michael =09 =09 =09 >Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as >IEEE 802.11 Management frames. > >I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages >to "Quality >of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to >indicate that IEEE 802.1X frames are sent at a higher priority. >=20 >Cheers, > >Mike =09 =09 This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email=20 immediately and delete it! =09 =20 Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as IEEE 802.11 Management frames.=20 =20 I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages to "Quality of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to indicate that IEEE 802.1X frames are sent at a higher priority. =20 Cheers, =20 Mike =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: =09 http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 =09 ------_=_NextPart_001_01C6E29C.35C21BA2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Mike,
 
In the=20 HCCA case, the TID value is in the range of 8 to 15, and according to = clause=20 6.1.1.1.1 point b:
 
"b) QoS = subtypes, in which=20 case the QAP shall infer the UP value from the TID in the QoS Control=20 field
directly for=20 TID values between 0 and 7. For TID values between 8 and 15, the QAP = shall=20 extract the
UP value in=20 the UP subfield of the TS Info field in the associated TSPEC or from the = UP=20 field in the
associated TCLAS (traffic classification) element, as=20 applicable."
&nbs= p;
It seems that the WTP needs to do much more = to obtain=20 the actual UP value. In case the TSPEC or TCLAS elemets are located at = the AC,=20 how would the WTP get the UP value in the HCCA case?
&nbs= p;
Or is there any place that prevents sending = EAPOL=20 frames using HCCA? If that is the case, it is not a problem. But, then = again,=20 all the data traffic sent using HCCA will have difficulty to obtain the = correct=20 priority in CAPWAP = delivery.
&nbs= p;
cheers
&nbs= p;
Cheng Hong
&nbs= p;
 
 

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Thursday, = September 28,=20 2006 2:23 AM
To: Cheng Hong
Cc: = capwap
Subject:=20 Re: [Capwap] This is not need.: Proposed resolution to Issue=20 214-Prioritization of IEEE 802.1X frames

Cheng,
 
In the HCCA case, the TID case should work as well. I don't see = why it=20 wouldn't.
 
Cheers,
 
Mike

 
On 9/26/06, Cheng=20 Hong <Hong.Cheng@sg.panasonic.com>=20 wrote:=20
Hi Mike,=20
 
It seems OK = to use TID in=20 the EDCA case. If the HCCA is used, would the TID still be = meaningful in=20 mapping the priority? (Haven't check the 802.11 standards in = detail).=20
 
cheers
 
Cheng Hong=20

From: Michael = Montemurro=20 [mailto:montemurro.michael@gmail.com ] =
Sent:=20 Wednesday, September 27, 2006 12:24 AM=20

To: = Cheng=20 Hong
Cc: zhaoyujin 31390; capwap
Subject: Re: = [Capwap]=20 This is not need.: Proposed resolution to Issue 214 = -Prioritization of=20 IEEE 802.1X frames

 
Cheng,
 
Thanks for you input.
 
Also, that's a good question. In my opinion, the CAPWAP = priority=20 should be based on the TID(UP). Which means yes, the WTP = would need=20 to read into the QoS control field.
 
Cheers,
 
Mike
 
On 9/25/06, Cheng=20 Hong <Hong.Cheng@sg.panasonic.com > wrote: =
Hi=20 Mike,
 
In this = case, I tend to=20 agree with the other Michael on the first point. =
 
However, = on the mapping=20 802.11e priority back to CAPWAP priority, I am not really = sure how=20 that is done. Is it based on 802.11e AC or TID (UP)? For later = case,=20 does it mean the WTP need to read into the QoS Control Field?=20
 
cheers
 
Cheng=20 Hong
 
 
From: Michael = Montemurro=20 [mailto:montemurro.michael@gmail.com ]=20
Sent: Tuesday, September 26, 2006 1:17=20 AM
To: Cheng Hong
Cc: zhaoyujin 31390; = capwap=20

Subject: Re: [Capwap] This is not need.: = Proposed resolution to Issue 214 -Prioritization of IEEE = 802.1X=20 frames

 
Cheng Hong,
 
In the CAPWAP draft, both wireless data and management = frames are=20 treated as CAPWAP data frames. Given that, = all CAPWAP data=20 traffic would need to go to the same logical instance of the = AC.
 
Cheers,
 
Mike


 
On 9/24/06, Cheng Hong <Hong.Cheng@sg.panasonic.com > = wrote:=20
Hi = Michael &=20 Michael,
 
Sorry = if the issue=20 has already been discussed before. Just thinking if the WTP = does not=20 differentiate 802.1X frames from normal data frames, would = it be=20 possible that the 802.1X frames being forwarded to a = different AC=20 instance than the one processing the control/management = frames? (in=20 case different ACs are used to process the control and data = channel)=20 Is this acceptable?
 
cheers
 
Cheng = Hong
 
 
 

From: Michael = Montemurro=20 [mailto:montemurro.michael@gmail.com] =
Sent:=20 Sunday, September 24, 2006 3:18 AM
To: zhaoyujin = 31390
Cc: capwap
Subject: Re: [Capwap] = This is=20 not need.: Proposed resolution to Issue 214 = -Prioritization of=20 IEEE 802.1X frames

 
Michael,
 
Thanks. Is anybody else opinionated on this feature. =
 
Cheers,
 
Mike

 
On 9/23/06, zhaoyujin 31390 <zhaoyujin@huawei.com > = wrote:=20
Firstly, I have some doubt = one this=20 suggestion.

1. If CAPWAP difines like this, AP = device=20 must decode the payload frames of 802.11 frames.
2. = Another=20 problem, the 802.1x priority should be implement by = 802.11e.=20 When station sends 802.11 data frames, it can set = 802.11e=20 priority. AP should transfer 802.11e to actual CAPWAP = packet=20 priority.

So that I think CAPWAP does not need = consider=20 the priority of 802.11 data frames payload.=20

Thanks
Michael



>Practically = speaking, IEEE 802.1X frames should be transmitted at = the same=20 priority as >IEEE 802.11 Management = frames.
>
>I=20 will update Section 11.5, rename Quality of Service for = IEEE=20 802.11 Control Messages >to "Quality
>of = Service for=20 IEEE 802.11 control messages and IEEE 802.1X EAPoL = frames" and=20 add text to >indicate that IEEE 802.1X frames are = sent at a=20 higher priority.
>=20
>Cheers,
>
>Mike


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

 

Practically speaking, IEEE 802.1X frames should be=20 transmitted at the same priority as IEEE 802.11 = Management=20 frames.
 
I will update Section 11.5, rename Quality of = Service for=20 IEEE 802.11 Control Messages to "Quality
of Service = for IEEE=20 802.11 control messages and IEEE 802.1X EAPoL frames" = and add=20 text to indicate that IEEE 802.1X frames are sent at a = higher=20 priority.
 
Cheers,
 
=
Mike

______________________________________________________= ___________
To=20 unsubscribe or modify your subscription options, please=20 visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20 =




<= BR>
------_=_NextPart_001_01C6E29C.35C21BA2-- --===============0707550228== 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 --===============0707550228==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Sep 27 21:54:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSl6d-0003Qb-31 for capwap-archive@lists.ietf.org; Wed, 27 Sep 2006 21:54:31 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSl6Z-0007AV-5B for capwap-archive@lists.ietf.org; Wed, 27 Sep 2006 21:54:31 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 58314398028 for ; Wed, 27 Sep 2006 18:54:22 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A84DE43009A for ; Wed, 27 Sep 2006 18:51:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 93E52398009 for ; Wed, 27 Sep 2006 18:51:56 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 16C0139800F for ; Wed, 27 Sep 2006 18:51:47 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id k8S1pI5P005228; Thu, 28 Sep 2006 10:51:18 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k8S1pK719805; Thu, 28 Sep 2006 10:51:20 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id k8S1pHq13106; Thu, 28 Sep 2006 10:51:18 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Sep 2006 09:50:20 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F1DCD@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: Acbg0apVLhatsbAIQ02cILmAIvbQhAAwcJngAA7+dpAAIw1B0AAQNarg From: "Cheng Hong" To: "Pat Calhoun (pacalhou)" , "Bob O'Hara (boohara)" , "T. Charles Clancy" , "Peter Nilsson J (LI/EAB)" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: ff67cea9f7df2d77f61a364cea0926e8 Hi Pat and all, So, based on this, I would say that we have consensus that setting the correct KeyRSC is an issue for the CAPWAP protocol design. So far, we have three option/solutions: 1) As proposed by Bob: Using a static value (0) for the KeyRSC. 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP 3) As suggested by Saravanana: Some exchange mechanism between WTP and AC Among the three, the first option seems the easiest. However, it requires a mandated Authenticator behavior(in this case AC) that is not mandated by 802.11. Therefore, we have to specify that (e.g. as proposed by Bob: "We could include a note to the effect that the group KeyRSC should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11, because otherwise there is no interoperability. For example, AC provided by another vendor does not have to set KeyRSC to 0 to be compliant with CAPWAP and 802.11i. Another implication is that we don't really understand the impact of mandating a static KeyRSC value. Although Bob provided an excellent analysis, I still have some doubts about the profoundness of the impact. If the KeyRSC value is as described of no use, why would it appear in the EAPOL frames in the first place? By mandating it to static value, what have we lost? Maybe some liaison letter to 802.1 or 802.11 could provide us a better understanding of the issue. For the last two options, I think they are both within CAPWAP's scope. Further analysis could help us to decide which one is better (or someone could propose other solutions). cheers Cheng Hong > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Thursday, September 28, 2006 1:39 AM > To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; > Peter Nilsson J (LI/EAB) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Bob's point is 802.11i works this way today. The AP (or in > this case AC) can set the RSC to whatever value it wishes. > Bob used zero (0) as an example. Implementations could use > any other value, which would require some form of > communication to the WTP, as suggested by Behcet. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > > Sent: Tuesday, September 26, 2006 6:03 PM > > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson > J (LI/EAB) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > Hi Bob, > > > > If I understand your description below correct, you are proposing a > > solution (to the problem pointed out by > > Saravanan) by mandating the behavior of the AC to always set the > > KeyRSC in the 4-way handshake to zero. > > > > This is not a defined behavior according to the current > > 802.11 standard. > > Are you suggesting that we CAPWAP WG should specifically > mandate that > > in our CAPWAP protocol spec, e.g. something like "a CAPWAP > compatible > > AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, > > since not all AC implementation have to follow what you described. > > > > Or, are you planning to take this issue to TGm for 802.11 standard > > revision? (since based on your description, there is essentially no > > use of the KeyRSC). > > > > cheers > > > > Cheng Hong > > > > > > > > > > > -----Original Message----- > > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > > > Sent: Wednesday, September 27, 2006 2:32 AM > > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > Charles, Peter, > > > > > > Below is an expansion of a snippet from a thread on this > > topic that I > > > sent to the list on July 25, 2006. I think this will be > helpful to > > > understand why the exchange that Saranavan is requesting is not > > > necessary. In fact, there are several systems from several > > > manufacturers in the field using precursor protocols to > CAPWAP that > > > are Wi-Fi certified for WPA2/802.11i operation using the > > protocol as > > > it is described below. > > > > > > BTW, this whole discussion is about the KeyRSC for the > > group key, not > > > the pairwise key. This is so because the WTP and AC both > know the > > > initial sequence counter value for the pairwise key, since it has > > > never been used to send a frame. 802.11i requires the > first frame > > > sent on a key to use the sequence counter value of 1. See > > 8.3.2.6 c) > > > and > > > 8.3.3.4.3 c) in 802.11i for this requirement. > > > > > > The same is not true of the group key, i.e., after the WTP begins > > > operation, the AC will not know the value of the sequence > > counter for > > > the group key when it needs to complete the EAPOL-key > > handshake with a > > > newly associated STA. > > > However, as you will see from the tutorial below, it is not > > necessary > > > for the AC and WTP to exchange any information about the > group key > > > KeyRSC for the protocol to operate as it is intended. > > > > > > 1. A value for the KeyRSC in the EAPOL-key frame 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. A value of zero in the > EAPOL-key > > > frame for the group key will always work. > > > > > > 3. The client STA will use the value of KeyRSC received in the > > > EAPOL-key frame to validate frame using the KeyMIC. > > > > > > 4. The client STA will also set its group key RSC to the value > > > received in KeyRSC, say, zero. > > > > > > 5. The value in the client STA's RSC will be compared against the > > > sequence number in subsequent received frames to identify replay > > > attacks. Any frame received with a sequence counter value > > within the > > > replay window will be checked to have a valid MIC. If the > > MIC is not > > > valid, the frame is dropped. > > > > > > 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, if the value is greater than its current RSC value. > > Only the > > > AP can meet these criteria as the source of a frame > received by the > > > STA. > > > > > > 7. Please see item 6, immediately above, for the reason > that the AC > > > and WTP do not need to coordinate and exchange the RSC. > > > > > > > > > The only possible attack mode is for the attacker to send > frames to > > > the client STA between the time of the EAPOL-key frame and > > the first > > > frame encrypted with the group key. > > > During this time, the client will receive the frame and > proceed to > > > validate its MIC. This is a potential attack against the STA > > > resources. But, the MIC validation is done in the STA's > > > 802.11 chip and consumes no more resources than receiving > any other > > > frame. Thus, the attack does not actually consume any STA > > resources > > > beyond those of receiving a frame. > > > > > > This attack is not unique to the use of the value zero for > > the KeyRSC, > > > either. The same attack is available to an attacker at any other > > > time, as well. It is no more nor less effective at either time. > > > > > > For these reasons, the protocol is not in need of any changes to > > > address the issue raised by Saranavan. > > > > > > -Bob > > > -----Original Message----- > > > From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > > > Sent: Monday, September 25, 2006 11:37 AM > > > To: Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > This is a very interesting solution. The AC selects the > KeyRSC and > > > performs the 4-way handshake. The WTP sniffs the 4-way handshake > > > traffic and grabs the KeyRSC value and uses it to > > initialize its own > > > counter. > > > > > > Pat/Bob: Is this how the Cisco implementation works? I > > have to agree > > > with Saravanan that I've yet to see a technical > description of how > > > Cisco implements it. > > > > > > IMHO, this is somewhat hackish, and it would be cleaner to > > have the AC > > > generate the KeyRSC and include it in the AddMobile message > > as Behcet > > > suggests. > > > > > > -- > > > t. charles clancy, ph.d. | tcc@umd.edu | > www.cs.umd.edu/~clancy > > > > > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > > > > > > > I think Saravanan has a point. We did a prototype > > impelementation of > > > the > > > > protocol a year ago when it was still called LWAPP. The way > > > we solved > > > > this issue then was to let the WTP sniff on all CAPWAP data > > > messages > > > > from the AC and when message 3 of the 4-way handshake or > > > message 1 of > > > > the groupkey handshake was sent the WTP inserted the correct RSC > > > before > > > > sending it off to the supplicant. To avoid the sniffing on > > > all CAPWAP > > > > data messages we would need a mechanism with in CAPWAP to > > > handle these > > > > two messages. > > > > > > > > Peter Nilsson > > > > > > > > -----Original Message----- > > > > From: Saravanan Govindan > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > Sent: den 22 september 2006 11:03 > > > > To: Margaret Wasserman > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > Hi Margaret, > > > > > > > > Thank you for reviewing the discussion on this issue. > > > > > > > > The issue here is the working of IEEE 802.11i when the 802.11i > > > > authenticator element is at the AC and the 802.11i crypto > > element is > > > at > > > > the WTP. Particularly, it is for the 4-way handshake between > > > > authenticator and supplicant. > > > > > > > > Now, the 4-way handshake requires knowing the value of > > > KeyRSC sequence > > > > counter. The KeyRSC helps both authenticator and supplicant > > > keep track > > > > of their exchanges. It serves to protect against threats by > > > tracking > > > > sequential frames. The KeyRSC is maintained at the at the > > point of > > > > encryption, i.e. just before transmission over the > > wireless channel. > > > > > > > > In the case of CAPWAP, the 4-way handshake is between the AC > > > > (authenticator) and the wireless station (supplicant). > > > > > > > > The problem arises, when the authenticator is at the AC and > > > the crypto > > > > element (together with KeyRSC) is at the WTP. This is a > > > fairly common > > > > design. Now in this case, the AC starts the 4-way > handshake but it > > > does > > > > not know the value of the KeyRSC. The KeyRSC is maintained > > > by the WTP. > > > > > > > > Based on this, the current CAPWAP specification does not > > allow for a > > > way > > > > to conduct the 4-way handshake with the correct KeyRSC. > > > > > > > > The functionality I would like to see is a way for the > > authenticator > > > > (AC) to use the correct prevailing value of KeyRSC > > > (maintained by the > > > > WTP) in its 4-way handshake. > > > > > > > > One way to introduce this functionality in to CAPWAP is > > to have part > > > of > > > > the 4-way handshake be sent from AC to WTP. This will allow > > > the 4-way > > > > handshake to use the correct value of the KeyRSC before > > > being sent to > > > > the wireless station. > > > > > > > > I hope this helps clarify my view on the issue. > > > > > > > > Cheers, > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > > > > Sent: Thursday, September 21, 2006 8:26 PM > > > > To: Saravanan Govindan > > > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > > > > > > > > > Hi again, > > > > > > > > Okay, I am even more confused than I thought I was... > > > > > > > > Saravanan, you wrote: > > > > > > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > > > > > >> Pat, > > > >> > > > >> The issue here is about how 802.11i exchanges are done when > > > >> authenticator is at the AC and crypto elements are at > > the WTP. This > > > is > > > >> the requirement. > > > > > > > > And, in response, Pat Calhoun wrote: > > > > > > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: > > > >> The current specification allows the authenticator to > > > reside in the > > > >> AC, while the data packet crypto elements in the WTP. This > > > feature is > > > >> already in the specification. > > > > > > > > Pat's message matches my reading of the specification. > > > > > > > > So, Saravanan, what functionality are you asking for > that is not > > > > already supported by the specification? And why do you > > think it is > > > > necessary? it will not be helpful to my understanding to > > > re-send your > > > > proposal or to cite the requirements document... Please > > summarize > > > > what functionality you think is missing from the current > > > specification > > > > and why you think that functionality is necessary to > support IEEE > > > > 802.11i or any important use case. > > > > > > > > At some point, the chairs may need to make a consensus > > call on this > > > > issue, and I'd like to understand your view and make sure > > > that it has > > > > been clearly communicated to the WG before we ask the WG to > > > decide on > > > > this issue. > > > > > > > > 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 > > > > > _________________________________________________________________ > > > > 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 > > > > > _________________________________________________________________ > > 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 oqtaisks@cncnet.net Wed Sep 27 22:00:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSlCX-0006pI-3X for capwap-archive@ietf.org; Wed, 27 Sep 2006 22:00:37 -0400 Received: from [220.249.242.69] (helo=reverse.gdsz.cncnet.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSlCU-0007ic-49 for capwap-archive@ietf.org; Wed, 27 Sep 2006 22:00:37 -0400 Message-ID: <000901c6e2a1$db06b620$45f2f9dc@zgjxzjx> From: "and" To: capwap-archive@ietf.org Subject: Wednesday denying reports Date: Thu, 28 Sep 2006 10:00:21 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C6E2E4.E929F620" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 ------=_NextPart_000_0005_01C6E2E4.E929F620 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C6E2E4.E929F620" ------=_NextPart_001_0006_01C6E2E4.E929F620 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable chief: Landis cheater great Byron Nelson dies rates slightly Div. RSS = Featured Circus still dont really know what happened Tuesday but drama = Opinions Playing wingJason Cole Matchup Giant Buser Big Rotowski: Week = Harris Hes realTom Verducci SI.com Dan Wetzel All Analysts Local Team = Edit Teams Standing Customize see stories interest sign in. view image = Sep pm EDTAP Charles Krupa Reed Saxon Slideshow Gallery Features Events = Expert picks: NCAAF MLS Yankees CSN YES Mets Atlanta SNY Milwaukee Cubs :pm ET Add FSN Kansas = City Minnesota RTN FSNO Diego St. Louis CH FSMW LA Dodgers Colorado KCAL = FSRM Angels FSW Oakland Seattle FSBA FSNW Full Times Eastern live: = scores way want themSign Links will open new window Through tried kill himself Tests confirm foot broken Bengals Thurman suspended = season La Russa keeps sagging Cards positive As back playoffs AL West = champs Colts Wayne expected return Thursday DEA: Kiel admits shipping = cough syrup Cycling Tour France La Russa keeps sagging Cards positive As back playoffs AL West champs = Colts Wayne expected return Thursday DEA: Kiel admits shipping cough = syrup Cycling Tour France chief: Landis cheater great Byron Nelson dies = rates slightly Div. RSS Featured Circus still dont really know what = happened Tuesday but drama Opinions Playing wingJason Cole Matchup Giant = Buser Big Rotowski: Week Harris Hes realTom Verducci SI.com Dan Wetzel = All Analysts Kiel admits shipping cough syrup Cycling Tour France chief: Landis = cheater great Byron Nelson dies rates slightly Div. RSS Featured Circus = still dont really know what happened Tuesday but drama Opinions Playing = wingJason Cole Matchup Giant Buser Big Rotowski: Week Harris Hes realTom = Verducci SI.com Dan Wetzel All Analysts Local Team Big Rotowski: Week Harris Hes realTom Verducci SI.com Dan Wetzel All = Analysts Local Team Edit Teams Standing Customize Other Arizona vs San Francisco Final Box Florida Bot TV: FSOH ------=_NextPart_001_0006_01C6E2E4.E929F620 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
chief: Landis cheater great Byron Nelson dies rates slightly = Div. RSS Featured Circus still dont really know what happened Tuesday = but drama Opinions Playing wingJason Cole Matchup Giant Buser Big = Rotowski: Week Harris Hes realTom Verducci SI.com Dan Wetzel All = Analysts Local Team Edit Teams Standing Customize see stories interest = sign in. view image Sep pm EDTAP Charles Krupa Reed Saxon Slideshow = Gallery Features Events Expert picks: NCAAF MLS
Yankees CSN YES Mets Atlanta SNY Milwaukee Cubs :pm ET Add FSN = Kansas City Minnesota RTN FSNO Diego St. Louis CH FSMW LA Dodgers = Colorado KCAL FSRM Angels FSW Oakland Seattle FSBA FSNW Full Times = Eastern live: scores way want themSign Links will open new window = Through
tried kill himself Tests confirm foot broken Bengals Thurman = suspended season La Russa keeps sagging Cards positive As back playoffs = AL West champs Colts Wayne expected return Thursday DEA: Kiel admits = shipping cough syrup Cycling Tour France
La Russa keeps sagging Cards positive As back playoffs AL West = champs Colts Wayne expected return Thursday DEA: Kiel admits shipping = cough syrup Cycling Tour France chief: Landis cheater great Byron Nelson = dies rates slightly Div. RSS Featured Circus still dont really know what = happened Tuesday but drama Opinions Playing wingJason Cole Matchup Giant = Buser Big Rotowski: Week Harris Hes realTom Verducci SI.com Dan Wetzel = All Analysts
Kiel admits shipping cough syrup Cycling Tour France chief: = Landis cheater great Byron Nelson dies rates slightly Div. RSS Featured = Circus still dont really know what happened Tuesday but drama Opinions = Playing wingJason Cole Matchup Giant Buser Big Rotowski: Week Harris Hes = realTom Verducci SI.com Dan Wetzel All Analysts Local Team
Big Rotowski: Week Harris Hes realTom Verducci SI.com Dan = Wetzel All Analysts Local Team Edit Teams Standing = Customize
Other Arizona vs San Francisco Final Box Florida Bot TV: = FSOH
------=_NextPart_001_0006_01C6E2E4.E929F620-- ------=_NextPart_000_0005_01C6E2E4.E929F620 Content-Type: image/gif; name="denies.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c6e2a1$db06b620$45f2f9dc@zgjxzjx> R0lGODlhvAFEAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAVAAAALAAAAAC8AUQBBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXco046ymUEPq0WknqtWrEDlh3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXotqcVpDjrc2jky5MsrJ ljNr/oh5s+fPFTuDHk16oejSqFP/O626tevXsGPLnk27tu3buHPr3s27t+/fwIMLH048sJfi yJMrX96TCXPU2p5L7xp9+kJQ1odWz+5wE3ee27/+izca3qGp8ehjlk/PHnz79z3Xw58vUz79 +y7t49/Pv7///wAGKOCAH9FB4IEIJqjgggw26OCDEEYo4YQUVmjhhRhmqOGGHHbo4Ycghiji iCRmqAtX55So4oostmjdOC7GKKNakM1o44045qjjjjxGxsZyjPQo5JBhhUPkeEYe+V2SSmYX DpNNRinllFRWaeWVWLamRJZcdunll2CGeaQ8Yv5GZpm+nYmmS5n0peaaur0JJ25yzmlbnXbS hmeesu3JZ1mK6OTnn4QWauihiCaq6KKM8vVFoYNWyEWjlFZq5aSWZqrpppx26umnoIYq6qik lmrqqaimqqpGP64qGBv/sLoaWKyy1mrrrbjmquuuvPbq66/ABivssMQWy+kUxiar7LLMNuvs s708K+201FZr7bXYZqvtttx26+234IYr7rjklgvuD+amq+66fU31qyvsKgXvnA/gNm+8R92L b1H67jtUv/4GBXDAPw1McE8GH1xREQo37PDDEEcs8cQUV2zxxRhnrDFqImzs8ccghyzyyCSX bLKyy5ys8sost+zyyzDHLPPMNNds883/gYCzunLs7PPPSt0D9NBEFx0sCwNOYrSnzSzt9NNQ Ry311FRXbfXVWGe9bwxad+3112AvaiDYY39dttdnd5221mtn3TbWdLwd9tw59oEoFl/jHXUq dgvp3bXfhjVxKuBZE1443YgnrvjijDfu+OOQRy755J4+Q/nluEGD+eacd+7556DbNcdMn/DJ Wuiop6766qy37vrrsMduKNKy12777bjnrju3luzue2JafB2818N3XbzWx2edPNbLX9281c// LhAw0ldv/fXABQQAIfkEAAXgAAAsAAAAALwBRAEHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qc SBAexYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmwQA4cf7TKTDATp8Def4k mFMnT6NFewINmvRnTqZPnQpVGlXoUqlImWIl+tTq0KFFgYbFKrbp2Jtmk471utZnVptw48qd WvWrUq1474Ita9fu26NXp3LVWreg1aVv0VLt+TVx37yHG199LJju0b5ZBcvdzJmlZaOYEQee nPauZcKiQyOMrFax3r2ry4IGrNq1X7d8B+vOK3Wnasedgwsnubb356ZUI+t1zDp126iQ3fY2 LPp5ZbHT03ZFfhv16+S5of7O3r4d9vDz6BfqgEh38envmg9XHe3dNGnurBdTj/4Yr+zk3231 WnPQcVXebr459Rtu6TXoIEXt2bfbe+IFSGFiwPGWX4DdSXjQZcvNFxt/Emo22HVE1VfiZA+2 6KJtCTJ2IX3+MYhgcyGOyF9gtuH4IXZBkdhjah6a6KGGKRr54pJMwshjWxqqxdd181UpH1IF gsdYkPsNiFuBrXF5G3kUCqiclloWFySUGTbp5ptwxinnnHTWaeedeOap55589umnRlj8Keig hBZq6KE0qYPooow26uijkEYq6aR/DmDppf9YOpCmlw4gUKeebgpqpp2Kiqmmn5KKqUGjqooq qv+kxmoqrAS1amuombrK6am4egrrrqsyFCyttNZaaqm6+trrp8ga22uzrTJ77LO6VittsZSm 9Cu1smJrrKjMhmtqqq/iKi644W4rq7jFtkvtqtyy++q6u0Y0rLneYlsuq/N6O6685/KLbqzE hrpvoZl0pi7A6x608MHX5rpwwPQqC27BAzdcsau5Blwupxv7i1C9DedrLsPO+qrxtwdDLPC5 JDMscrYnbXvrtSfDbPDOp3I8scbqBo1vvEC/y7HHBvv8brMKkYwxv/dSLDGvwV68s7xV6zzq 1ldbS7NKE0Mc7cDREivtxhmHvPS3SBcU9Nltd8yr1Q5n7fTQIyPbMsj+quLstsVeixw24H5L /TVKg0ut79oe0x032YTHjDbFb+vMNuME55wQqJLP3G3XBKddMNeTv6w2y0Qfrm28LivOrcv4 fv737OliLjvbkHecatyxC/2Q72m/LLbKm9Ju+d6bs0747RhLXigxLSU+bdaW195z8WPPyrPN HwNrMrx61wo537vfSr3p3itbtfnbkz+13Zinj/7Sc1tfr/Oq56//oYHu7///guofAAdIwDoJ sIAIVF07DJjABjqwRQd8oAQF4o0J2iSCFmxgBTNIEwxy8B8f+IBAQjhCEZbQhCAMoQpPSEIS lpAgKhRhDF04kBm+cIQwtCENWxjDHPbQhj7+3CAQU8jDGrKQhkREIhFraEIlAnGISSziC3co wx4ycYU+5OEKnwjFJF6xiSiEiAc56MIyohCLTExjDtXIxhQahIpLBOEbz0hHNyIEjnY8oRDB qEYsVjEhZvRhH8MIRyWu8YZuLCQf81gQJxJykYy8oRSlGJExZjCQdqRkHh3ZRkYaUpEtnCMb NdnIOm7yj6eU5BYjechMotKLrSRlLOuoSFXeMYyehKQh1xjIXX6QIkWs5ShxOUNOdjKVVfwk HXVoxVkicpKmLKMXfZnKRC6TmLRs5jCZmUZMdpGLW9QlLmeJyV9qpJjCfCY2O4lEZXbzhKJU Jyu32U5U4lGaSzT/4yMHmct4WhOQpvznFLX5zR8+Eo3zrKYszTkRP+qzmXgcZilbKdGASnSg AO3mNcPJTzliFJHILOYx0+nPdAZznAnV5C5Xuk+BMjQj5YxoROVJUXdOEYYlzWZGbRlSmhKy mjyV6ThJOlF5CtOmoqznQZDK05duJKYBrSdHQQpRlD4Rp0UNKUJp6lItUjGURoziQYV6zCiC NKv3tCIoHenQqWb1iw89q1PnSte62tUmC7irXvcqqQnw9a+AHYhfA0tYvQ62sIid62ETy9jG OvaxkI2sZCdL2cpa9rKYzaxmN8vZznr2s6ANrWhHS9rSmva0qE2talfL2ta69rWwja1s/mdL 29ra9raepQNud8vb3vr2t8ANrnAhlYbhGve4yE2ucpfL3OY697nQja50p0vd4B6jutjNrnab xI3tIsoN3g2veMdL3vKa97zoTa9618sZPbD3vfCtKyQaMt871RdSAMhvfmmyX4EAQCaQCHCA /yFgAt93vgIe8H0NjOADM3jAA1nwgSFMYIIkOMIKdrBALvxghBSYwhOm8IYtDOIIU6TAG+Zw h0n8YQdL2MIF4bCGF8yo/tpEv/4FsEHqW2Ia+zjFJqaxiYc8YxiP+MglrrCRF8LjInt4yErW cESkrOQjH8THLl5yla2MYC7j978F0S+YxfxfHP+DzAMRs3/V/nzmMYN5zft1c3/RbOY2z/nN U97xiHm85T7z+c9PDnKMt/ziKBtayEK+8p4XHWg/M3jFj65woaFMZSIPGtBQdvSif+woG6/5 03cGtZvDXOZRhzrNdsZzm1fN6jibWtUPSTCfJb1nFHO6y5JGMYYv/ONJG5rWwI6xiPUMbFwr 2sqMrrKxGzzoJVcaybw+NIt17eVh9xlRnm51qT+96lPTedSpDjOc4exqbruazRdBNJKDjexf dznRhHa0r2cN6CZz+tj1Tkillx3kaDeb0pkmtqWNHe9pA/nfNVZ1qL297W6/2tx1zrGoJ65t Vm9E3dK+97ppDe8X91rL9N60lq9t/2mO6zvg/E52uzWtbIXcmt2+ljfCF5XthYO73A6nuI2z fWaCNBznNif1iYk9YZZv3MAkL7iTvXx0CO975bNGetInHfUsqxzgmcb4vRUM8qN7Hd6GQnO4 K+7wOn+b2xZHtdrPTna2SwTLy25wizMc9wfPe9e7lnuIlR1ivaOc6weHNLKpDfgoO93Dw4Z7 yJ3t90JHnelgHyDPHTJ5xkY+z4u6/P8qzxDOF1bzmDcU6ONL+tKb3rz2OL1dl1ETe6Re9bJ9 PexjK/vZv7b2tm8t7nPP+977/vfAD77wh0/84hv/+MhPvvLr5PmMND/tyz+U2xvCebFH5PnP ZzKvrb7hpf6MPvooqTmsFVL57JN//ELHCJYFnXXw10T8d945jk+NdoinutRyln/QJ/JxmI/c /S8hdvJHcQRIbjf3cw+XczlnfjsWbZiWYioGgDHhdvtHbgchgGbGcBVXgUNnZO/WdRL4fg23 gXiGbheYf/angEA3gh04cAW3ciEYgCPIgTh3gmn2Zhq4f+XGgDNXdHcXgzJodvGHg/MHbgbo c0Rof9bHZjUYelzWeP8HhHbCg1IYWFRYhViYhVq4hVyYQcjQhcyHftcnhhBxhRORD2DYEhq4 EGZoEGY4fSOBhgORD3QohwRRh3aIh2k4hil4fhtxheJXEnr4D3QoEIU4h3JYiP+HeIh7SH0H aIFHuIRCOIQoSHb1p236V4nNp4iESIiJaIcFoYif2IgPsYOPqIMImHb0p3MlqHCp6GkceBCc aIijaBCLWIuk2HlkRomv+GpqxoQHmIERB30rOHa7+BCDeIu2mIe4aFvr8CjCaIRKmIBIWIwM F4hI2HZFSBFoKIq0GIqgqIy56Ihoh43WiH7nWI6wFoir2ITQZ4ud6I2eOI+M+I3zOI66WH8Y uI2YeG5EGI0D6Ia/qImT6I6yWIeIqIx4eIv1iI8P0oYiAYoOKSgQGRISOZEYmZEauZEc2ZEe +ZEgGZIiOZIkWZIm6RHscJILEQoq2SBq0JIZ9JIwaUH/MjmTNnmTOJmTOrmTPNmTPvmTQBmU QjmURFmURnmUSJl8U5CUTKmFztCUUBmVUjmVVFmVVnmVWImRcpCVXNmVE5EKXhmWzQUNYgla BEAAw3GWm6GW48iWbomWB8GWcQmXBnGWdvkPcomWcomXdLmXdnmXELGXGiGYgukQhdkQf0mX DHGYfzkQjYkQj8mXeQmYkqmYtfWWAnGYfJkQmumXbrmZjtmXlgmaEaGZFEGZlBmYo7mYq8ma dQmXaomZr5mZegmbtUmbpLlbsvmWvGmbsRmZuBmasZmbkzmbuOmbogmYwEmbvWmZjfmY0BmZ icmcthmc1imcyImckHmbuTmX/6D5m8fZmpd5m4UJntcpm9Spl5VJnIk5mpNJmNxpnp4Znue5 nvIZn/hZEPdJENP5nflpmu8pnsGJmQS6nOPZntjJnex5norpmwt6ndbpmXdZoMBZoPXpnxhq of6pnKmZnpW5n50pmhDKnyK6mRpqmrDFodVpoiU6oA3aoKH5oN1JmsXJovTpnTZKnLN5ov+5 ogYao/B5o/r5oiPKoDe6n7q5ohnaohgao47JnzJani3KozPqok2amTtanVSKnihqnk7qpU76 pQranVuqpeQpoHolAyaBnh/KnNR5pTr6pNNZoyQapm16p/2JnVb6pEP6pk3an3kqpaj5nNIp oSqqpP8fqp1+up42iqJT6agKAakPIalluRGUiqOWWqmauqktCQGc+qmg+prJGaDuSah1iqV0 mqgeeqrNGaG12aF3KpwJOqSjWqp8Cqg+eqZVynuDuqdBaqfKSaO26qqsqqBeiqRiSqIlKqHJ qqyoKqK7qauXSnrIeqxECqwTKqzGqa3KqqTWCqdXWq1muqd6aqz52ahj6nviyq0e6pf2iaB9 SqzdSqzFyabheq5LSq7P+q3oSp/TGl/rmqrzeav8eqrsGqb1Cq0Gmqc5WqP3CasO6rDtOa7/ +l4Tq60Ce61YKqRSirDDirEKO6PWOqcKS7IiC6TLypv+iqanl7C+6pwai5f/UJqq8iqyU2qu 4BqtKEuuyLqxz+qxRVp8CTuoEPui2SqnTMqgsMqeRMulGvutgQqXHVCwMkuwqem0OYqFLhCq XNu1Xvu1sDUHYDu2ZFu2Znu2aJu2avsnQrC2RBkCbhu3cutdnTC3dnu3eJu3eru3fNu3fst7 VPC3gju4hFu4hnu4kOUDiJuGFWkSpEAKwgG5EyG5JUG5LgG5kvu4I2G5lpsQnfsimBsXkkiO Nui4mmsQn3sRlJu6ERG6AtG5rPu6AwG7H+G6k+u5DxG6scsRnNsQvUsRsbu7t3sQtiuCl5iP McG6wgsRyysRq4tDDPG8jqu6G6G7lUsQzdu8vou7/x6hvP+gvSoxgENogeNbdud2gwv3jqj7 uo+buafbvrKLuZp7ut/7vvPLvu5Lv7L7vfFbv/L7vv4Lu/MLv/zrvwVBwPBLvwhcwLNrv/mb v/gbvwRswMTrwP2bufu7wA+MvRHcwRj8v6s7wRGMwBZMwQkcwhtswvoruknYhLDoiiqYgP6o vge8v/wrvTeMwQVMu8/bw7PLwTv8vRCAw9Zrwwzsw6nrw0HMwcX7uzf8w0n8xP2rEERcvxls xDlsw72rxE/8wVD8w2CMxVN8xEtsu2ZMxsIhvvgnjZQYw6I2kK2rxWgsxWWMv2fMxVvcxXNc xAy8x1l8wO3rujocyHTcx/94bMgJTMYrXMNyjMQ7nMhy/MVjLL+STMeci8MBfMSEPMgBfMcN nMYtjIIvTILaSIxkSLyNHMZnHMSHfMhfbL1VvMqRbMlOfMWWXMhO7MmpTMTem8oXfMtVXMme 7MWTjLqyLMu2XLyKDMidsYYFmI45CMPHu77L7Mt13MrCzMisrMq3zM1jbMiSTMx6HMbV3M3j DM6obM1o7MrgjM3njMzZXMxTLM66DMSbMbroBsf358b9OIOnDMm4DMDJbMfs+8g63MfrXNCO jMX3e8GLvMBlnMgCDMHrvMF3vMjkDNGzvMnYK8IUbcKfLL2E3MAhTNBWDNIRfdDuS8G9JwIW BL7/iwsSIhzTNF3TNt2SMG3Pw4HR6MHTOb0kPJ0SP20TPk0T8Ly7mDy91GvMQe3NuevATU3N 9gy+Iw28c5wRy9vLHczSM828gBzVV+27+ovCwvu5SZ285By9ad0ZZu3Vw4vQMN3WYowQQ829 3avWxszN7BzHa03FVp3BwUzXUl3XGMHJ/5vJObzCJ6zAij3AJP3YiA3CJD3RW43QXD3AggzV dq3JZl3CIzzBM93ZKLzMutvQoN3Yox3anu3UtKvTKszYY83Ujw3JJBzUgU3ZLG3AVd3VHWHY fozMsZzRV5zUwxzP6gzZXFzO8MzQUl3OrH3VbqDRTQzF9OzcqFzLx/3c/wX9yYK91yiNy9l8 1uiM2Ho92MZdu3p8zOb821V9zSPN0b8sz9nNxPBtzcvd2iad3bHc3vQN0MqtyJucxP4t14Ws 0/yN3wTt3dQ94OG91viNycm90Z0sErB8wyOwy8I939eszcUt39ZdwwjuznBt3kYc4b+t1iHe 4N/M3epM4Mrc1wg+3vXsvSlezMRN4jJu2cGt1NuM4SVe3j/e48D8yudt4kxcyf8N4c2t5Ct+ 4nM95EAO5ePt3C5u2WKs0lct4jSO5Fru2hIe5c8t3rwLxiu90HC9yqGdzLDd4QaN26I92h6c 2Vg+2Qed3x5cwRU90XD+2mgu55Vt0iT81XN92v8dveeTneeXDNvI7edZ/t6aLehW3tAGTUCE nSfFgJS83SiXftMtsemcvhLF4OmfPuqEW+mVa+rOO+Ze/uStq9UThN2bwd9xLOYagepvvdkG ruirbscvTteZzsPN/ddTrc0UDifZu+tEfdfXyxJZjef2zeKCzeocns59beV8PewqYes1cezV nuyQrttEftgfrdpzvthwvtu1Lduf7eYP7dTDvRBkDdlRLtlSbO7IfeYfrdsQ7dGTTt4anNuc fNnsDsGPzueLTtGnPdbS/e3ZLtDgLcE2juTeLMjYruLrfeQOLvHafdJ1Tu173eV8nOQPruPl LeDP3sMdX8cYT+xKXN3/Ig7i8z7sYq7ttxvI0x3xEnzCTK3AGd7mIk/uNy/z0W7nid3U++3R C+/IPJ/zkg7mEk7JHF7fM76+RRzgSx7ONi71J53gdJ7lZK7jmX4SypzLSe7sg97zU2/kVG7e rp7WsD7tTc7cEV/SEV7lVT7JZC/0Hv7Lx1zLLY/zrD31FZ/QI3+5aw/4wI3tFB/zXQ7mdj/0 Xx/kkR7zbt/geQz4YBwBL77jkg/yMB75U/67WbD4aS/c7Jz4s+zuYp/wB9/n/d7VCw/ugC3p KQz76b71d67uuJ/mZx/JvF/o9F7a5e7whT7ow6zYxe/vxI/8WrzY6r7vTH/vOX/oHL/mwL/q /7KOQDTfWNu/7N4uE0mwJ2EPWt1PEuVf66Se/uq//h/h0ouSAvAf//D/J4Td9n4NupV+/tRO 7BrvEGCNugAh4t9AggUNDiR1UOFChgxJJVQIseFEigdTVMSYUePGjBILenT4kSBIkCI5/it5 MKXGlSZRshx58uTKlAlbNryJU0TJmi9xxpTp0yXJoBhzFkWa9KfKih4lHgXK8SjUpVU3PlXa dGFPqga7et0a0mpRnlGzUvx6VinWhw8R+mz7FqXbuRDjIryL1+Zdm3Dz1n1Kt29crCPd2pXL V3FfuXpfFv5bF7BhxIkFX6Y7+ePit3YF+3WKubNXwo5LD+Ybs7Rkzf6bPYfe+5n1aNZtAyOO rVa32MeqK/cWWRi4UKFs5zZ2avbxb+HFEzs3jnwodLPCGQ+/DjY68e2Dtf+e3pmoQO9RP3en Tpu7aqbSsxt2z1584931p3e3Dfq67f3he1sPL7/m3jMOtdWGQ9A54Pjzrz+2YHOwOvn+02u/ suIDi7zlzJswQvX64/BC6jIzT8AOFbQvxfSw0+5E/1AsD8UVQVQvvhgxrFFBxmgK0cXj0Bvw xBgJTA7HkQTCjkYPWUSvR7BwJLG5GWVUcTcge2ySRQ5HA9BJLZVb77kPiSMTxi2lGzPIK+m7 ckkJjTRSySnXDDNBM4tEk0kfy6wSKRNrTPRNM9EqJG1E1yCkLLvMamKOMjQXbU/GyH4EKi8B Fz3wNZI4WzBTErmTjbTDZhtVPEwvAy1Px/gs9b9PYSN01dDo67NWW8mSKa2ZbuW1V19/DUpX YIcl9kmp+hS2WGWXZVarZp+FNlppp6W2WmuvxTZbbbfltltvvwU3XHHHJbdcc89FN11ua1C3 XXffhTdeeee1ZV5778U3X20f0bdff/8FOGCBBya4YIMPRjhhhRdmuGGHoaXmYYknzqoeii/G OGONN+a4Y4+jTeNjkUcmuWSTT0Y5ZZVXZrlll1+GOWaZZ6a5ZptvtpYTnHfmuWeffwaa44AA ACH5BAAKAAAALAAAAAC8AUQBBwj+AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mix o8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSAuGSMq0 qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmzaK06S3tzE9u3cOPKnUu3rt27ePPq3cu3 r9+/gAMLHky4sOHDiHcaSMy4sePHkCNLnky5suXLmDNnbaC5s+fPoEOLznljtOnTqFOrXs26 tevXsGPLnk27tu3Wi27r3s27t+/fwIMLH068uPHjyJMrX868ufPn0KNLn069unXT1q5r3869 u/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djy59Pv779+/jz69/Pv7///wAGKKBlFAxYlwhZFWjg dAouGF2DDq6kymcQjpRPhBhmqOGGHMaUTYcghijiiCSWaOKJKKao4oopJcFiaEK8KOOMNNZo 44045qjjjjz26OOPQAYppH0gDBnYLSEVidkkRi6kJHAonPhkk6NNSSVoVl75WZZadunll+mN A+aYqtlB5plopqnmmlu1weabcG54CGJhxGnnnQ+xgqdCqFhUwJ509QloYoIOelihhhaGaKKD LcpoYI4++lekkvZFaaV7XYrpppx26umnoIYqmSSilmrqqaimquqqrLbq6qv/sMYqK3WdzGrr rbjmquuuvOrKTa9f/QpsV8I6N82wyCar7LLMNuvss9BGK+201FZr7bXYZqvtttx26+234IYr 7rilLrDcE+Smq+667Lbr7rvwxivvvPTWa++9+Oar774cucLvvwAHLPDABBds8MEIJ6zwwgwn pkXDEEfc7gYSV2yxcPRcrLFV6Gzs8ccghyzyv7yM3FDJJi+EcsoJrczyQS6/XFDMMtfnlsQ2 1Kzzzjz37PPPQAct9NBEF2300UgnrfTSBs/A9NNQSwZO1D9xRvXVWGet9dY3MsD112ADF03Y B30itNlBf4I22Wy37fbbcMct99x012333dyVgTd3XACAPDVEfQMduHk1zDe4z4fzHMw/iRus TEeND6zM4x5F/u/kIVmuL+Z7d+7556CT1UfopJdu+rNcAJ36z6v73PrpTaEL++yE4UD77bjn rvvuvHtUgrfL9C68uAEBADs= ------=_NextPart_000_0005_01C6E2E4.E929F620-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Sep 28 08:36:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSv7e-0004SA-Qa for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 08:36:14 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSv7a-00062K-TU for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 08:36:14 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id C9B513980B5 for ; Thu, 28 Sep 2006 05:36:05 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9757043005F for ; Thu, 28 Sep 2006 05:35:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7B9B1430DE2 for ; Thu, 28 Sep 2006 05:35:20 -0700 (PDT) Received: from huawei-3com.com (h3cml02-in.huawei-3com.com [210.21.230.97]) by hermes.tigertech.net (Postfix) with ESMTP id 48D62430DD7 for ; Thu, 28 Sep 2006 05:35:12 -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 <0J6A00GM3ZH1QL@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Thu, 28 Sep 2006 20:46:13 +0800 (CST) Received: from smtp2.huawei-3com.com ([172.19.1.39]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6A00JPDZH0D0@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Thu, 28 Sep 2006 20:46:13 +0800 (CST) Received: from unknown (HELO RichardYoung) ([10.18.23.88]) by smtp2.huawei-3com.com with ESMTP; Thu, 28 Sep 2006 20:34:58 +0800 Date: Thu, 28 Sep 2006 18:05:01 +0530 From: young To: capwap@frascone.com Message-id: <000001c6e2fa$84b16f00$5817120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acbi+oPKcvRelgJeTC6BjN+Ioh2fbA== 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: Subject: [Capwap] suggestion for Issue # 204, "More general wireless support" X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0654437255==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8aa7cbc518894eb04182283f0682f662 This is a multi-part message in MIME format. --===============0654437255== Content-type: multipart/alternative; boundary="Boundary_(ID_dFjeG6D3vpJzFtxKSy0icA)" This is a multi-part message in MIME format. --Boundary_(ID_dFjeG6D3vpJzFtxKSy0icA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Pat and all, I used to raise issue #204, and here intend to give solution. 1) Redefine 11.9.1 "IEEE 802.11 add WLAN" as "Add wireless service", and put it in the section 4.4 The glossary "wireless service" will be more abstract than "WLAN". Refer to current "IEEE 802.11 add WLAN" format, we could keep Radio ID, service ID (rename "WLAN ID" to it), MAC Mode, tunnel mode these kinds common element (more element maybe put here). While for any specific wireless binding could follow the Wireless binding identifier. The Wireless binding identifier will identify what kinds binding are using (Probably eventually managed by IANA) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | WLAN ID | MAC Mode | Tunnel Mode +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wireless binding identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It is similar for "IEEE 802.11 deletes WLAN" and "IEEE 802.11 Update WLAN". 2) Rename "11.9.22. IEEE 802.11 WTP Quality of Service" as "WTP Quality of Service" Same idea, we could keep the radio ID, Tag Packets, Queue Depth in the "WTP Quality of Service". For any binding, we use Wireless binding identifier to suggest them. For Tag Packets, if IANA already have some kind assignment, it will be great. 3) Add "WTP RF Radio configuration" in the section 4.4 The Tx power, radio type, channel assignment and so on these kind parameter are common for any kind wireless binding. I suggest CAPWAP define it in the base protocol part. Although the protocol already has "WTP Radio Information", while Tx power these kind Info should not be sent during discovery and join phase. So the separated "WTP RF Radio configuration" is better. If keep them in one, which element will be mandatory in what kind message should be suggested by protocol. The TLV of "WTP RF Radio configuration" will include radio ID, radio type, Tx power, Channel, country code and so on. For any binding, we use Wireless binding identifier to suggest them. The "WTP RF Radio configuration" could be sent by bi-direction, by this way, AC could configure WTP's RF parameter and know current configuration on the WTP radio. If this way, current "11.9.18. IEEE 802.11 Tx Power", "11.9.12. IEEE 802.11 OFDM Control "and "11.9.5. IEEE 802.11 Direct Sequence Control" and so on will merely keep the IEEE 802.11 related element. 4) Redefine "IEEE 802.11 Statistics" as "WTP Statistics" in the section 4.4 Most case, the wireless binding will be link layer protocol, I think most the element in the "IEEE 802.11 Statistics" could be put on the section 4.4, except the element like "RTS Success Count" and so on. For any binding, we use Wireless binding identifier to suggest them. Any way, I thought many TLV will change their location as new CAPWAP will be divided into two parts. Cheers Richard (Shiyang) --Boundary_(ID_dFjeG6D3vpJzFtxKSy0icA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Pat and all,

I used to raise issue #204, and here intend to give solution.

1)      Redefine 11.9.1 “IEEE 802.11 add WLAN” as “Add wireless service”, and put it in the section 4.4

The glossary “wireless service” will be more abstract than “WLAN”.

Refer to current “IEEE 802.11 add WLAN” format, we could keep

Radio ID, service ID (rename “WLAN ID” to it), MAC Mode, tunnel mode

these kinds common element (more element maybe put here).

While for any specific wireless binding could follow the Wireless binding identifier.

The Wireless binding identifier will identify what kinds binding are using

(Probably eventually managed by IANA)

 

        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

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |    Radio ID   |    WLAN ID    |        MAC Mode    | Tunnel Mode       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |             Wireless binding identifier                     |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |         Type                  |             Length            |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                          Value...

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It is similar for “IEEE 802.11 deletes WLAN” and “IEEE 802.11 Update WLAN”.

 

2) Rename “11.9.22.  IEEE 802.11 WTP Quality of Service” as  “WTP Quality of Service”

Same idea, we could keep the radio ID, Tag Packets, Queue Depth in the “WTP Quality of Service”.

For any binding, we use Wireless binding identifier to suggest them.

For Tag Packets, if IANA already have some kind assignment, it will be great.

 

3)      Add “WTP RF Radio configuration” in the section 4.4

The Tx power, radio type, channel assignment and so on these kind parameter are common for any kind wireless binding.

I suggest CAPWAP define it in the base protocol part.

Although the protocol already has “WTP Radio Information”, while Tx power these kind Info should not be sent

during discovery and join phase. So the separated “WTP RF Radio configuration” is better.

If keep them in one, which element will be mandatory in what kind message should be suggested by protocol.

The TLV of “WTP RF Radio configuration” will include radio ID, radio type, Tx power, Channel, country code and so on.

For any binding, we use Wireless binding identifier to suggest them.

The “WTP RF Radio configuration” could be sent by bi-direction, by this way, AC could configure WTP’s RF parameter

and know current configuration on the WTP radio.

If this way, current “11.9.18.  IEEE 802.11 Tx Power”, “11.9.12.  IEEE 802.11 OFDM Control “and “11.9.5. 

IEEE 802.11 Direct Sequence Control” and so on will merely keep the IEEE 802.11 related element.

 

4)      Redefine “IEEE 802.11 Statistics” as  “WTP Statistics” in the section 4.4

Most case, the wireless binding will be link layer protocol, I think most the element in the “IEEE 802.11 Statistics”

could be put on the section 4.4, except the element like “RTS Success Count” and so on.

For any binding, we use Wireless binding identifier to suggest them.

 

Any way, I thought many TLV will change their location as new CAPWAP will be divided into two parts.

 

Cheers

 

Richard  (Shiyang)

 

--Boundary_(ID_dFjeG6D3vpJzFtxKSy0icA)-- --===============0654437255== 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 --===============0654437255==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Sep 28 09:08:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSvcS-0005te-7R for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 09:08:04 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSvcQ-00040u-D3 for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 09:08:04 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 4139C430E8C for ; Thu, 28 Sep 2006 06:07:58 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 8888B43005F for ; Thu, 28 Sep 2006 06:05:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 752F6398017 for ; Thu, 28 Sep 2006 06:05:09 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id B7B92398008 for ; Thu, 28 Sep 2006 06:05:05 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id k8SD4ecg014738; Thu, 28 Sep 2006 22:04:40 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k8SD4hc28472; Thu, 28 Sep 2006 22:04:43 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id k8SD4gq08761; Thu, 28 Sep 2006 22:04:43 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Sep 2006 21:03:42 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F1F63@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: Acbg0apVLhatsbAIQ02cILmAIvbQhAAwcJngAFpvgFA= From: "Saravanan Govindan" To: "Bob O'Hara (boohara)" , "T. Charles Clancy" , "Peter Nilsson J (LI/EAB)" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: e178fd6cb61ffb6940cd878e7fea8606 This seems to suggest that the standard specify parametric values. It seems to place a limitation on 802.11i operation. Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] Sent: Wednesday, September 27, 2006 2:32 AM To: T. Charles Clancy; Peter Nilsson J (LI/EAB) Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations Charles, Peter, Below is an expansion of a snippet from a thread on this topic that I sent to the list on July 25, 2006. I think this will be helpful to understand why the exchange that Saranavan is requesting is not necessary. In fact, there are several systems from several manufacturers in the field using precursor protocols to CAPWAP that are Wi-Fi certified for WPA2/802.11i operation using the protocol as it is described below. BTW, this whole discussion is about the KeyRSC for the group key, not the pairwise key. This is so because the WTP and AC both know the initial sequence counter value for the pairwise key, since it has never been used to send a frame. 802.11i requires the first frame sent on a key to use the sequence counter value of 1. See 8.3.2.6 c) and 8.3.3.4.3 c) in 802.11i for this requirement. The same is not true of the group key, i.e., after the WTP begins operation, the AC will not know the value of the sequence counter for the group key when it needs to complete the EAPOL-key handshake with a newly associated STA. However, as you will see from the tutorial below, it is not necessary for the AC and WTP to exchange any information about the group key KeyRSC for the protocol to operate as it is intended. 1. A value for the KeyRSC in the EAPOL-key frame 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. A value of zero in the EAPOL-key frame for the group key will always work. 3. The client STA will use the value of KeyRSC received in the EAPOL-key frame to validate frame using the KeyMIC. 4. The client STA will also set its group key RSC to the value received in KeyRSC, say, zero. 5. The value in the client STA's RSC will be compared against the sequence number in subsequent received frames to identify replay attacks. Any frame received with a sequence counter value within the replay window will be checked to have a valid MIC. If the MIC is not valid, the frame is dropped. 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, if the value is greater than its current RSC value. Only the AP can meet these criteria as the source of a frame received by the STA. 7. Please see item 6, immediately above, for the reason that the AC and WTP do not need to coordinate and exchange the RSC. The only possible attack mode is for the attacker to send frames to the client STA between the time of the EAPOL-key frame and the first frame encrypted with the group key. During this time, the client will receive the frame and proceed to validate its MIC. This is a potential attack against the STA resources. But, the MIC validation is done in the STA's 802.11 chip and consumes no more resources than receiving any other frame. Thus, the attack does not actually consume any STA resources beyond those of receiving a frame. This attack is not unique to the use of the value zero for the KeyRSC, either. The same attack is available to an attacker at any other time, as well. It is no more nor less effective at either time. For these reasons, the protocol is not in need of any changes to address the issue raised by Saranavan. -Bob -----Original Message----- From: T. Charles Clancy [mailto:clancy@cs.umd.edu] Sent: Monday, September 25, 2006 11:37 AM To: Peter Nilsson J (LI/EAB) Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations This is a very interesting solution. The AC selects the KeyRSC and performs the 4-way handshake. The WTP sniffs the 4-way handshake traffic and grabs the KeyRSC value and uses it to initialize its own counter. Pat/Bob: Is this how the Cisco implementation works? I have to agree with Saravanan that I've yet to see a technical description of how Cisco implements it. IMHO, this is somewhat hackish, and it would be cleaner to have the AC generate the KeyRSC and include it in the AddMobile message as Behcet suggests. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > I think Saravanan has a point. We did a prototype impelementation of the > protocol a year ago when it was still called LWAPP. The way we solved > this issue then was to let the WTP sniff on all CAPWAP data messages > from the AC and when message 3 of the 4-way handshake or message 1 of > the groupkey handshake was sent the WTP inserted the correct RSC before > sending it off to the supplicant. To avoid the sniffing on all CAPWAP > data messages we would need a mechanism with in CAPWAP to handle these > two messages. > > Peter Nilsson > > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: den 22 september 2006 11:03 > To: Margaret Wasserman > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > Hi Margaret, > > Thank you for reviewing the discussion on this issue. > > The issue here is the working of IEEE 802.11i when the 802.11i > authenticator element is at the AC and the 802.11i crypto element is at > the WTP. Particularly, it is for the 4-way handshake between > authenticator and supplicant. > > Now, the 4-way handshake requires knowing the value of KeyRSC sequence > counter. The KeyRSC helps both authenticator and supplicant keep track > of their exchanges. It serves to protect against threats by tracking > sequential frames. The KeyRSC is maintained at the at the point of > encryption, i.e. just before transmission over the wireless channel. > > In the case of CAPWAP, the 4-way handshake is between the AC > (authenticator) and the wireless station (supplicant). > > The problem arises, when the authenticator is at the AC and the crypto > element (together with KeyRSC) is at the WTP. This is a fairly common > design. Now in this case, the AC starts the 4-way handshake but it does > not know the value of the KeyRSC. The KeyRSC is maintained by the WTP. > > Based on this, the current CAPWAP specification does not allow for a way > to conduct the 4-way handshake with the correct KeyRSC. > > The functionality I would like to see is a way for the authenticator > (AC) to use the correct prevailing value of KeyRSC (maintained by the > WTP) in its 4-way handshake. > > One way to introduce this functionality in to CAPWAP is to have part of > the 4-way handshake be sent from AC to WTP. This will allow the 4-way > handshake to use the correct value of the KeyRSC before being sent to > the wireless station. > > I hope this helps clarify my view on the issue. > > Cheers, > > Saravanan > > > > > > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, September 21, 2006 8:26 PM > To: Saravanan Govindan > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > > > Hi again, > > Okay, I am even more confused than I thought I was... > > Saravanan, you wrote: > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > >> Pat, >> >> The issue here is about how 802.11i exchanges are done when >> authenticator is at the AC and crypto elements are at the WTP. This is >> the requirement. > > And, in response, Pat Calhoun wrote: > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: >> The current specification allows the authenticator to reside in the >> AC, >> while the data packet crypto elements in the WTP. This feature is >> already in the specification. > > Pat's message matches my reading of the specification. > > So, Saravanan, what functionality are you asking for that is not > already supported by the specification? And why do you think it is > necessary? it will not be helpful to my understanding to re-send > your proposal or to cite the requirements document... Please > summarize what functionality you think is missing from the current > specification and why you think that functionality is necessary to > support IEEE 802.11i or any important use case. > > At some point, the chairs may need to make a consensus call on this > issue, and I'd like to understand your view and make sure that it has > been clearly communicated to the WG before we ask the WG to decide on > this issue. > > 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 > _________________________________________________________________ > 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 _________________________________________________________________ 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 Sep 28 12:14:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSyWm-0007b7-IF for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 12:14:24 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSyWj-0000tS-PN for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 12:14:24 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6A13A3980E0 for ; Thu, 28 Sep 2006 09:14:11 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8F40C43005F for ; Thu, 28 Sep 2006 09:11:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 747371448005 for ; Thu, 28 Sep 2006 09:11:15 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by hermes.tigertech.net (Postfix) with ESMTP id CFAA61448028 for ; Thu, 28 Sep 2006 09:11:12 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so757601nfb for ; Thu, 28 Sep 2006 09:11:09 -0700 (PDT) Received: by 10.49.29.3 with SMTP id g3mr305585nfj; Thu, 28 Sep 2006 09:11:09 -0700 (PDT) Received: by 10.49.42.6 with HTTP; Thu, 28 Sep 2006 09:11:08 -0700 (PDT) Message-ID: <5bfe7a820609280911l68996b70y73b85ce2ca65205@mail.gmail.com> Date: Thu, 28 Sep 2006 09:11:09 -0700 From: "Dorothy Stanley" To: "Michael Montemurro" In-Reply-To: <26140d940609231158l6b15a518x65889cb02b935ae4@mail.gmail.com> MIME-Version: 1.0 References: <26140d940609231158l6b15a518x65889cb02b935ae4@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=1.0 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed resolution to issue 137 - Proposal for a revised packet header X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0251932792==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 --===============0251932792== Content-Type: multipart/alternative; boundary="----=_Part_64074_10981691.1159459869081" ------=_Part_64074_10981691.1159459869081 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Mike, Use of a mux header, (regardless of 1 or 2 ports, not needed if 3 ports are used) is also one solution to the (recently opened Issue 224, regarding the) need to clearly distinguish Discovery frames in the control channel: *"I have a basic question regarding the classification of packets exchanged over control channel. It is stated in the draft that AC in Idle state can receive Discovery as well as DTLS clientHello (+other dtls handshake) packets. The clientHello packets are delivered to the SSL layer and Discovery packets are consumed by the CAPWAP. Question is how? The draft assumes some magic way of doing it. Since both of the packets are in plain, and are received on a single udp port, which state/policy/field classifies such packets from one another? Theoretically speaking, WTP can send a discovery packet which is also a valid clientHello packet! Now AC would respond with a discovery response or a clientHello reponse? In thread **http://lists.frascone.com/pipermail/capwap/msg03035.html* *, Pat talks about the negotiated policy for the appropriate treatment of the received packets. That may mean, if the AC is in join onwards state, it can be assumed that AC will only receive encrypted packets. Though this policy can work, but there would be exceptions in which WTP dies and comes back with a discovery packet. AC still being in join+ state, the received packets will be delivered to the SSL layer. Assumptions can be made here that SSL would discard non-dtls packets and with timeouts in picture, WTP and AC would eventually reach a consensus. But is this ok to assume? In the same thread, Perkins suggested the mux header approach for control channel, but it was not acknowledged? Is there some other hidden mechanism for the classification? Or there is some basic point which I miss here?"* This issue is noted in the issue 137 text (there is alot of text), and is stated in terms of protected vs unprotected messages, though the note comments that this is essentially the same as identifying the Discover (unprotected contro)l message: * NOTE: A CAPWAP MUX header is needed whether or not the same or different UDP ports are used for CAPWAP control and data messages. This is because both CAPWAP data and control messages can be unprotected or protected by DTLS, and the MUX header is needed to distinguish protected from unprotected. Remember that CAPWAP "discovery requests" and "discovery responses" are unprotected, and that all other CAPWAP control message types are protected*. The current -02 draft in incomplete in its specification of how Discovery frames are clearly identified. The header definition proposed in issue 137, or a variant - one that differentiates between discovery, control and data CAPWAP messages for example, provides a means to clearly identify Discovery frames. If an implementation has another means - the issue 224 commenter used the term "magic", to disambiguate the frames, that implementation can chose to ignore an added mux field; however the protocol should be explicit. Dorothy On 9/23/06, Michael Montemurro wrote: > > I don't see why a MUX header is required even if the decision to go with > separate control and data ports. I don't see how this header definition is > better than what is currently in draft -02. > > If there are specific edits to the header that are required, I would like > to know what they are; otherwise I propose closing this issue. > > 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 > > ------=_Part_64074_10981691.1159459869081 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Mike,
 
Use of a mux header, (regardless of 1 or 2 ports, not needed if 3 ports are used) is also one solution to the (recently opened
Issue 224, regarding the) need to clearly distinguish Discovery frames in the control channel:
 
"I have a basic question regarding the classification of packets exchanged over
control channel. It is stated in the draft that AC in Idle state can receive
Discovery as well as DTLS clientHello (+other dtls handshake) packets. The
clientHello packets are delivered to the SSL layer and Discovery packets are
consumed by the CAPWAP. Question is how? The draft assumes some magic
way of doing it. Since both of the packets are in plain, and are received on
a single udp port, which state/policy/field classifies such packets from one
another? Theoretically speaking, WTP can send a discovery packet which is
also a valid clientHello packet! Now AC would respond with a discovery
response or a clientHello reponse?

In thread http://lists.frascone.com/pipermail/capwap/msg03035.html, Pat talks about
the negotiated policy for the appropriate treatment of the received packets. That may
mean, if the AC is in join onwards state, it can be assumed that AC will only receive
encrypted packets. Though this policy can work, but there would be exceptions in
which WTP dies and comes back with a discovery packet. AC still being in join+
state, the received packets will be delivered to the SSL layer. Assumptions can be
made here that SSL would discard non-dtls packets and with timeouts in picture, WTP
and AC would eventually reach a consensus. But is this ok to assume?

In the same thread, Perkins suggested the mux header approach for control channel,
but it was not acknowledged? Is there some other hidden mechanism for the
classification? Or there is some basic point which I miss here?"
 
This issue is noted in the issue 137 text (there is alot of text), and
is stated in terms of protected vs unprotected messages, though the
note comments that this is essentially the same as identifying the Discover (unprotected
contro)l message:
 
NOTE: A CAPWAP MUX header is needed whether or not the same or
       different UDP ports are used for CAPWAP control and
       data messages. This is because both CAPWAP data and
       control messages can be unprotected or protected by
       DTLS, and the MUX header is needed to distinguish
       protected from unprotected. Remember that CAPWAP
       "discovery requests" and "discovery responses" are
       unprotected, and that all other CAPWAP control
       message types are protected.
 
The current -02 draft in incomplete in its specification of how
Discovery frames are clearly identified. The header definition proposed in issue 137, or a variant -
one that differentiates between discovery, control and data CAPWAP messages for example, provides a means to clearly identify Discovery frames.
 
If an implementation has another means - the issue 224 commenter used the term "magic",  to
disambiguate the frames, that implementation can chose to ignore an added mux field; however
the protocol should be explicit.

Dorothy


 
On 9/23/06, Michael Montemurro <montemurro.michael@gmail.com > wrote:
I don't see why a MUX header is required even if the decision to go with separate control and data ports. I don't see how this header definition is better than what is currently in draft -02.
 
If there are specific edits to the header that are required, I would like to know what they are; otherwise I propose closing this issue.
 
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


------=_Part_64074_10981691.1159459869081-- --===============0251932792== 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 --===============0251932792==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Sep 28 12:25:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSyh4-0005Sh-Fi for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 12:25:02 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSyh3-0001TG-1z for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 12:25:02 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 69444398121 for ; Thu, 28 Sep 2006 09:25:00 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 84AC743005F for ; Thu, 28 Sep 2006 09:23:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5C08E144809B for ; Thu, 28 Sep 2006 09:23:30 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by hermes.tigertech.net (Postfix) with ESMTP id 1AFA4144809F for ; Thu, 28 Sep 2006 09:23:20 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so760516nfb for ; Thu, 28 Sep 2006 09:23:19 -0700 (PDT) Received: by 10.49.8.1 with SMTP id l1mr3893020nfi; Thu, 28 Sep 2006 09:23:19 -0700 (PDT) Received: by 10.49.42.6 with HTTP; Thu, 28 Sep 2006 09:23:18 -0700 (PDT) Message-ID: <5bfe7a820609280923l35224a20v77d1d30a26e06085@mail.gmail.com> Date: Thu, 28 Sep 2006 09:23:18 -0700 From: "Dorothy Stanley" To: "Michael Montemurro" In-Reply-To: <26140d940609231118m3f5b351cv78499aec7335df6@mail.gmail.com> MIME-Version: 1.0 References: <26140d940609231118m3f5b351cv78499aec7335df6@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=1.0 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_50_60, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: capwap Subject: Re: [Capwap] Proposed resolution to Issue 221 - Fix figure 5: remove "(clear text)" X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1294555646==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 --===============1294555646== Content-Type: multipart/alternative; boundary="----=_Part_64282_18334985.1159460598726" ------=_Part_64282_18334985.1159460598726 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Mike, I agree with this proposed resolution to issue 211 (vs 221). Thanks, Dorothy On 9/23/06, Michael Montemurro wrote: > > Both figure 5 and figure 7 will to be updated to be consistent with the > add mobile message element definition. > > 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 > > ------=_Part_64282_18334985.1159460598726 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Mike,
 
I agree with this proposed resolution to issue 211 (vs 221).
 
Thanks,
 
Dorothy

 
On 9/23/06, Michael Montemurro <montemurro.michael@gmail.com> wrote:
Both figure 5 and figure 7 will to be updated to be consistent with the add mobile message element definition.
 
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


------=_Part_64282_18334985.1159460598726-- --===============1294555646== 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 --===============1294555646==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Sep 28 13:45:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSzxO-0004me-Am for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 13:45:58 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSzxM-0002Nq-I0 for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 13:45:58 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 64D5C3980CF for ; Thu, 28 Sep 2006 10:45:55 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 768EB43005F for ; Thu, 28 Sep 2006 10:44:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 40EE439803E for ; Thu, 28 Sep 2006 10:44:40 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by zoidberg.tigertech.net (Postfix) with ESMTP id EC89D3980B8 for ; Thu, 28 Sep 2006 10:44:09 -0700 (PDT) Received: from [209.86.224.37] (helo=elwamui-karabash.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GSzvd-0003Op-Af for capwap@frascone.com; Thu, 28 Sep 2006 13:44:09 -0400 Received: from 75.32.19.206 by webmail.pas.earthlink.net with HTTP; Thu, 28 Sep 2006 13:44:09 -0400 Message-ID: <26298393.1159465449346.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> Date: Thu, 28 Sep 2006 10:44:09 -0700 (GMT-07:00) From: "Scott G. Kelly" To: capwap Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710878ac99e9b9a71a50f7a5d4ee18087cd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.37 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] 2-Port/Mux Issue Discussion X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 225414c974e0d6437992164e91287a51 I was going to just leave this, but there are some things that might best be called misconceptions in Margaret's summary below. I had an offline exchange with Margaret about this, and I have no doubt that this just didn't come out quite the way she meant it, so please don't view this as offensive. I am quite tired of arguing on this topic, but since the associated email archive essentially represents a record of our deliberations, I think for whatever it's worth, it's important that it accurately reflect what's gone on here. So, I've inlined some clarifications below: Margaret Wasserman wrote: > > As many of you know, we have had a technical issue open in > the CAPWAP > WG for some time that is commonly referred to as the 2-port/mux > issue. This issue involves a technical choice between: > > - A solution that uses two different well-known UDP ports for > separate data and control communications (the 2-port solution), > > OR > > - A solution that uses a single well-known UDP port for all > communication, with control and data traffic distinguished by a > CAPWAP header value (the mux solution). > > Strong opinions have been expressed on both sides of this issue, and > the WG has had trouble coming to consensus on a single choice. > Discussions in this area have included a wide variety of networking > topics, such as Quality of Service, NAT Traversal and Mobility. > > Given the breadth of the technical issues under discussion, our Area > Director, Dan Romascanu, decided to solicit advice from the IESG to > help us understand the technical trade-offs, and to help us > understand which factors it would be reasonable to consider in our > working group decision -- specifically whether or not it was > reasonable for us to consider the hardware implications of this > decision. The only IESG members who showed up for the discussion > were Mark Townsley, one of the Internet ADs, and our two OPS > ADs, Dan > and David Kessens. We didn't receive a definitive answer from the > IESG, but a clear message was received from Mark Townsley that it is > reasonable for the group to consider the hardware > implications of our > work -- both compatibility with currently deployed hardware, and the > hardware architectures we might want to support in the future. > > After much discussion with the interested IESG members, the document > editors, the proponents of both solutions and some people who have > proposed compromise solutions, the chairs believe that the key > technical difference between these two proposals is which hardware > architecture(s) they will support. There are currently two > different > classes of AC hardware deployed, and variants on both of these > architectures may be deployed in the future: > > - Single-Processor: In this architecture, the control plane and the > data plane run on a single processor. The demultiplexing of control > and data packets happens on that processor. > > - Separate Data & Control Planes: In this architecture, the > data and > control planes run on separate processors (and possibly on separate > cards), typically connected via a switching fabric. This is > a common > hardware architecture for higher-end routing and switching hardware, > and it relies on a port-based splitting/load-balancing approach to > separate the control and data traffic. For CAPWAP to work > efficiently on these systems, it must be possible to distinguish the > control and data traffic in the switching hardware, which is > typically done based on the five-tuple of the send & recv IP > addresses, the protocol (UDP), and the send & recv port > numbers. The > switching hardware cannot do the type of deep packet inspection > required to demultiplex on CAPWAP header fields. This is one of the mischaracterizations I see. The issues have nothing to do with how many processors there are - they have to do with separation of control and data planes, and with the switching facility used to distribute packets between these two planes. This is a critical distinction. > The 2-port approach supports both the "Single-Processor" AC > architecture and the "Separate Data & Control Planes" AC > architecture. Proponents of this solution believe that it is > important to support the "Separate Data & Control Planes" > architecture efficiently, both for compatibility with currently > deployed hardware and to allow this hardware architecture to be used > for future CAPWAP-enabled products. > > The mux approach will only operate efficiently on "Single-Processor" > systems. as it relies on the ability to demultiplex the control and > data traffic using CAPWAP header information. Proponents of this > solution believe that it will simplify CAPWAP software > implementation, and that it makes NAT traversal (when the AC and the > WTPs are on different sides of a NAT) simpler to configure. Based on the clarification above, it should be clear that this is also a mischaracterization. Either approach will work in either of the architectures, and in particular, in either of the architectures _as they are deployed today_. The real problem appears to be that one vendor has made a conscious choice to limit the control/data switching facility to 5-tuple-based solutions. Here's the picture Pat used to explain this: +-----------------------------------------------+ | +---------+ +--------+ +--------+ | | | | | | | | | | | Control | | Data 1 | | Data 2 | | | | | | | | | | | +---------+ +--------+ +--------+ | | ^ ^ AC | +------|----------------|-----------------------+ | | +----|----------------|---------------------+ | \ | Ethernet | | ----------------+ Switch | +---------------------|---------------------+ | +---------+ | | | WTP | | | +---------+ I can't say I've cracked open WLAN controllers from every vendor in the market, but I've seen the insides of at least 5, and all of them had either NPU(s) or NPU-like capabilities. The picture above represents an implementation decision that is not constrained by currently deployed wlan technology. That's a really important point. > This complexity is a consequence of the choice to tunnel all WLAN > data traffic to the AC. In split-MAC local-forwarding mode, > only the > control plane traffic would be sent to the AC, and data plane > forwarding would be handled by the WTPs themselves. This also seems mischaracterized, because in all currently defined split-MAC modes, a data channel must be established in order to handle 802.11 management and authentication frames (even when you're doing local bridging of the data). > We've heard from a couple of strong voices on this issue. but now > we'd like to hear from the rest of the WG... > > Which hardware architecture(s) does the CAPWAP protocol needs to > support? > > Specifically, do you think that it should be a requirement to > support efficient operation on currently deployed and future > ACs that > follow the "Separate Control & Data Planes" architecture described > above? Or do you think that it would be acceptable to produce a > somewhat cleaner and simpler protocol that will not work efficiently > on those ACs? > > Please send your response by Thursday, October 5th (two weeks from > today), so that the chairs can gauge the consensus of the WG in this > matter. > > After we have an understanding of which hardware architecture(s) the > CAPWAP protocol needs to support, we will make an effort to sort > through the various proposals and counter-proposals that meet that > requirement. > > Thanks, > > The CAPWAP Chairs > Dorothy Gellert, Mahalingam Mani & Margaret Wasserman I think the working group has a right to know that when we took this offline and attempted to bring in experts, it came out that there really were *no* QoS or routing issues, and that all along, this had been about integrating airespace wlan controllers with catalyst switching gear. We wasted weeks chasing red herrings and misdirection. Gotta wonder what that was about. In any event, Margaret is right: the working group needs to speak up so we can close this and move on. I'm done arguing about this, and life will go on one way or another regardless of what we choose. But at least, we should all be clear on what's happened here, and go into this eyes wide open. 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 Thu Sep 28 13:47:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSzz6-0005oU-5E for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 13:47:44 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSzz4-0002SR-9o for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 13:47:44 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4BC143980D7 for ; Thu, 28 Sep 2006 10:47:41 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id F029543005F for ; Thu, 28 Sep 2006 10:44:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D61A939806D for ; Thu, 28 Sep 2006 10:43:59 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id D98BA39805A for ; Thu, 28 Sep 2006 10:43:32 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 28 Sep 2006 10:36:04 -0700 X-IronPort-AV: i="4.09,231,1157353200"; d="scan'208"; a="326326707:sNHT4398843440" 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.20060308/8.12.11) with ESMTP id k8SHa4Ra005957; Thu, 28 Sep 2006 10:36:04 -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 k8SHa2Yr009366; Thu, 28 Sep 2006 10:36:03 -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, 28 Sep 2006 10:36:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Sep 2006 10:35:59 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC02188A0F@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: Acbg0apVLhatsbAIQ02cILmAIvbQhAAwcJngAFpvgFAACcQusA== From: "Bob O'Hara (boohara)" To: "Saravanan Govindan" , "T. Charles Clancy" , "Peter Nilsson J (LI/EAB)" X-OriginalArrivalTime: 28 Sep 2006 17:36:00.0384 (UTC) FILETIME=[902D1800:01C6E324] Authentication-Results: sj-dkim-2.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: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 453b1bfcf0292bffe4cab90ba115f503 There is no limit placed on 802.11i operation. Please explain that statement. Please READ 802.11i, first, specifically the two subclauses I cited. -Bob -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Thursday, September 28, 2006 6:04 AM To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson J (LI/EAB) Cc: capwap@frascone.com Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations This seems to suggest that the standard specify parametric values. It seems to place a limitation on 802.11i operation. Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] Sent: Wednesday, September 27, 2006 2:32 AM To: T. Charles Clancy; Peter Nilsson J (LI/EAB) Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations Charles, Peter, Below is an expansion of a snippet from a thread on this topic that I sent to the list on July 25, 2006. I think this will be helpful to understand why the exchange that Saranavan is requesting is not necessary. In fact, there are several systems from several manufacturers in the field using precursor protocols to CAPWAP that are Wi-Fi certified for WPA2/802.11i operation using the protocol as it is described below. BTW, this whole discussion is about the KeyRSC for the group key, not the pairwise key. This is so because the WTP and AC both know the initial sequence counter value for the pairwise key, since it has never been used to send a frame. 802.11i requires the first frame sent on a key to use the sequence counter value of 1. See 8.3.2.6 c) and 8.3.3.4.3 c) in 802.11i for this requirement. The same is not true of the group key, i.e., after the WTP begins operation, the AC will not know the value of the sequence counter for the group key when it needs to complete the EAPOL-key handshake with a newly associated STA. However, as you will see from the tutorial below, it is not necessary for the AC and WTP to exchange any information about the group key KeyRSC for the protocol to operate as it is intended. 1. A value for the KeyRSC in the EAPOL-key frame 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. A value of zero in the EAPOL-key frame for the group key will always work. 3. The client STA will use the value of KeyRSC received in the EAPOL-key frame to validate frame using the KeyMIC. 4. The client STA will also set its group key RSC to the value received in KeyRSC, say, zero. 5. The value in the client STA's RSC will be compared against the sequence number in subsequent received frames to identify replay attacks. Any frame received with a sequence counter value within the replay window will be checked to have a valid MIC. If the MIC is not valid, the frame is dropped. 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, if the value is greater than its current RSC value. Only the AP can meet these criteria as the source of a frame received by the STA. 7. Please see item 6, immediately above, for the reason that the AC and WTP do not need to coordinate and exchange the RSC. The only possible attack mode is for the attacker to send frames to the client STA between the time of the EAPOL-key frame and the first frame encrypted with the group key. During this time, the client will receive the frame and proceed to validate its MIC. This is a potential attack against the STA resources. But, the MIC validation is done in the STA's 802.11 chip and consumes no more resources than receiving any other frame. Thus, the attack does not actually consume any STA resources beyond those of receiving a frame. This attack is not unique to the use of the value zero for the KeyRSC, either. The same attack is available to an attacker at any other time, as well. It is no more nor less effective at either time. For these reasons, the protocol is not in need of any changes to address the issue raised by Saranavan. -Bob -----Original Message----- From: T. Charles Clancy [mailto:clancy@cs.umd.edu] Sent: Monday, September 25, 2006 11:37 AM To: Peter Nilsson J (LI/EAB) Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations This is a very interesting solution. The AC selects the KeyRSC and performs the 4-way handshake. The WTP sniffs the 4-way handshake traffic and grabs the KeyRSC value and uses it to initialize its own counter. Pat/Bob: Is this how the Cisco implementation works? I have to agree with Saravanan that I've yet to see a technical description of how Cisco implements it. IMHO, this is somewhat hackish, and it would be cleaner to have the AC generate the KeyRSC and include it in the AddMobile message as Behcet suggests. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > I think Saravanan has a point. We did a prototype impelementation of the > protocol a year ago when it was still called LWAPP. The way we solved > this issue then was to let the WTP sniff on all CAPWAP data messages > from the AC and when message 3 of the 4-way handshake or message 1 of > the groupkey handshake was sent the WTP inserted the correct RSC before > sending it off to the supplicant. To avoid the sniffing on all CAPWAP > data messages we would need a mechanism with in CAPWAP to handle these > two messages. > > Peter Nilsson > > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: den 22 september 2006 11:03 > To: Margaret Wasserman > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > Hi Margaret, > > Thank you for reviewing the discussion on this issue. > > The issue here is the working of IEEE 802.11i when the 802.11i > authenticator element is at the AC and the 802.11i crypto element is at > the WTP. Particularly, it is for the 4-way handshake between > authenticator and supplicant. > > Now, the 4-way handshake requires knowing the value of KeyRSC sequence > counter. The KeyRSC helps both authenticator and supplicant keep track > of their exchanges. It serves to protect against threats by tracking > sequential frames. The KeyRSC is maintained at the at the point of > encryption, i.e. just before transmission over the wireless channel. > > In the case of CAPWAP, the 4-way handshake is between the AC > (authenticator) and the wireless station (supplicant). > > The problem arises, when the authenticator is at the AC and the crypto > element (together with KeyRSC) is at the WTP. This is a fairly common > design. Now in this case, the AC starts the 4-way handshake but it does > not know the value of the KeyRSC. The KeyRSC is maintained by the WTP. > > Based on this, the current CAPWAP specification does not allow for a way > to conduct the 4-way handshake with the correct KeyRSC. > > The functionality I would like to see is a way for the authenticator > (AC) to use the correct prevailing value of KeyRSC (maintained by the > WTP) in its 4-way handshake. > > One way to introduce this functionality in to CAPWAP is to have part of > the 4-way handshake be sent from AC to WTP. This will allow the 4-way > handshake to use the correct value of the KeyRSC before being sent to > the wireless station. > > I hope this helps clarify my view on the issue. > > Cheers, > > Saravanan > > > > > > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, September 21, 2006 8:26 PM > To: Saravanan Govindan > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > > > Hi again, > > Okay, I am even more confused than I thought I was... > > Saravanan, you wrote: > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > >> Pat, >> >> The issue here is about how 802.11i exchanges are done when >> authenticator is at the AC and crypto elements are at the WTP. This is >> the requirement. > > And, in response, Pat Calhoun wrote: > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: >> The current specification allows the authenticator to reside in the >> AC, >> while the data packet crypto elements in the WTP. This feature is >> already in the specification. > > Pat's message matches my reading of the specification. > > So, Saravanan, what functionality are you asking for that is not > already supported by the specification? And why do you think it is > necessary? it will not be helpful to my understanding to re-send > your proposal or to cite the requirements document... Please > summarize what functionality you think is missing from the current > specification and why you think that functionality is necessary to > support IEEE 802.11i or any important use case. > > At some point, the chairs may need to make a consensus call on this > issue, and I'd like to understand your view and make sure that it has > been clearly communicated to the WG before we ask the WG to decide on > this issue. > > 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 > _________________________________________________________________ > 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 _________________________________________________________________ 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 Sep 28 14:16:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT0R9-0006Qh-Ab for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 14:16:43 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT0R5-0006Zx-5h for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 14:16:43 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 916EB144803F for ; Thu, 28 Sep 2006 11:16:31 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4AA5A43005F for ; Thu, 28 Sep 2006 11:12:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 37DBB144803F for ; Thu, 28 Sep 2006 11:12:01 -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 84283144800B for ; Thu, 28 Sep 2006 11:11:56 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 28 Sep 2006 11:11:52 -0700 X-IronPort-AV: i="4.09,231,1157353200"; d="scan'208"; a="444452082:sNHT112228640" 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 k8SIBpkq024874; Thu, 28 Sep 2006 11:11:51 -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 k8SIBpQV001207; Thu, 28 Sep 2006 11:11:51 -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); Thu, 28 Sep 2006 11:11:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Sep 2006 11:11:50 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC02188A65@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: Acbg0apVLhatsbAIQ02cILmAIvbQhAAwcJngAA7+dpAAIw1B0AAQNargACIJW2A= From: "Bob O'Hara (boohara)" To: "Cheng Hong" , "Pat Calhoun (pacalhou)" , "T. Charles Clancy" , "Peter Nilsson J (LI/EAB)" X-OriginalArrivalTime: 28 Sep 2006 18:11:51.0493 (UTC) FILETIME=[92564750:01C6E329] Authentication-Results: sj-dkim-4.cisco.com; header.From=boohara@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] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 64b72a8e61417554b4b727cb14e7034d Please understand that 802.11i specifies no behavior in this area for the 802.1X authenticator. Our choice to send a group key KeyRSC value of zero in the EAPOL-key frame requires no change to 802.11i or to 802.1X. It requires us to state this in the CAPWAP spec, if we want this behavior to be consistent across all implementations. The problem with what Bechet and Saranavan are asking is that either of three different things are required: 1: the WTP must communicate the group key TSC to the AC every time it is updated, or 2: the AC must request the current value of the group key TSC for the KeyRSC before constructing the EAPOL-key frame, or 3: the AC must send the KCK to the AC so that it can insert the KeyRSC value and also calculate the correct MIC, inserting that into the proper EAPOL-key frame. The first item requires a tremendous amount of additional CAPWAP communication between WTP and AC, at least one new CAPWAP packet for every multicast frame sent by the WTP, if the packet is not acknowledged, or two new CAPWAP packets, if it is acknowledged. This is a very expensive addition to the protocol. The second item requires new protocol between the AC and WTP during what can be a time critical portion of the 802.11 transition (handoff, roam) from one WTP to another. It also introduces a race condition that is not present in the protocol today. Once the value for the KeyRSC is sent from the WTP to the AC, it is possible that the WTP can send another multicast frame encrypted with the group key. This puts the value of the sequence counter out of sync with the value that will be shortly communicated to the client in the EAPOL-key frame from the AC. This will behave exactly the same as if a value of zero is sent in the EAPOL-key frame. The third item requires a new architecture split that is not required in our objectives. The new split is not splitting the MAC, but splitting the authenticator. Placing the KCK in the WTP is also a potential reduction in the security of the overall WLAN system, since these devices are normally not in a secured wiring closet, but exposed and more easily compromised than the AC. The simplest to implement, least expensive, and most secure option is to use the protocol as it is now specified and have the AC send a value of zero in the KeyRSC field of the EAPOL-key frame. -Bob -----Original Message----- From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] Sent: Wednesday, September 27, 2006 6:50 PM To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson J (LI/EAB) Cc: capwap@frascone.com Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi Pat and all, So, based on this, I would say that we have consensus that setting the correct KeyRSC is an issue for the CAPWAP protocol design. So far, we have three option/solutions: 1) As proposed by Bob: Using a static value (0) for the KeyRSC. 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP 3) As suggested by Saravanana: Some exchange mechanism between WTP and AC Among the three, the first option seems the easiest. However, it requires a mandated Authenticator behavior(in this case AC) that is not mandated by 802.11. Therefore, we have to specify that (e.g. as proposed by Bob: "We could include a note to the effect that the group KeyRSC should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11, because otherwise there is no interoperability. For example, AC provided by another vendor does not have to set KeyRSC to 0 to be compliant with CAPWAP and 802.11i. Another implication is that we don't really understand the impact of mandating a static KeyRSC value. Although Bob provided an excellent analysis, I still have some doubts about the profoundness of the impact. If the KeyRSC value is as described of no use, why would it appear in the EAPOL frames in the first place? By mandating it to static value, what have we lost? Maybe some liaison letter to 802.1 or 802.11 could provide us a better understanding of the issue. For the last two options, I think they are both within CAPWAP's scope. Further analysis could help us to decide which one is better (or someone could propose other solutions). cheers Cheng Hong > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Thursday, September 28, 2006 1:39 AM > To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; > Peter Nilsson J (LI/EAB) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Bob's point is 802.11i works this way today. The AP (or in > this case AC) can set the RSC to whatever value it wishes. > Bob used zero (0) as an example. Implementations could use > any other value, which would require some form of > communication to the WTP, as suggested by Behcet. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > > Sent: Tuesday, September 26, 2006 6:03 PM > > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson > J (LI/EAB) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > Hi Bob, > > > > If I understand your description below correct, you are proposing a > > solution (to the problem pointed out by > > Saravanan) by mandating the behavior of the AC to always set the > > KeyRSC in the 4-way handshake to zero. > > > > This is not a defined behavior according to the current > > 802.11 standard. > > Are you suggesting that we CAPWAP WG should specifically > mandate that > > in our CAPWAP protocol spec, e.g. something like "a CAPWAP > compatible > > AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, > > since not all AC implementation have to follow what you described. > > > > Or, are you planning to take this issue to TGm for 802.11 standard > > revision? (since based on your description, there is essentially no > > use of the KeyRSC). > > > > cheers > > > > Cheng Hong > > > > > > > > > > > -----Original Message----- > > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > > > Sent: Wednesday, September 27, 2006 2:32 AM > > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > Charles, Peter, > > > > > > Below is an expansion of a snippet from a thread on this > > topic that I > > > sent to the list on July 25, 2006. I think this will be > helpful to > > > understand why the exchange that Saranavan is requesting is not > > > necessary. In fact, there are several systems from several > > > manufacturers in the field using precursor protocols to > CAPWAP that > > > are Wi-Fi certified for WPA2/802.11i operation using the > > protocol as > > > it is described below. > > > > > > BTW, this whole discussion is about the KeyRSC for the > > group key, not > > > the pairwise key. This is so because the WTP and AC both > know the > > > initial sequence counter value for the pairwise key, since it has > > > never been used to send a frame. 802.11i requires the > first frame > > > sent on a key to use the sequence counter value of 1. See > > 8.3.2.6 c) > > > and > > > 8.3.3.4.3 c) in 802.11i for this requirement. > > > > > > The same is not true of the group key, i.e., after the WTP begins > > > operation, the AC will not know the value of the sequence > > counter for > > > the group key when it needs to complete the EAPOL-key > > handshake with a > > > newly associated STA. > > > However, as you will see from the tutorial below, it is not > > necessary > > > for the AC and WTP to exchange any information about the > group key > > > KeyRSC for the protocol to operate as it is intended. > > > > > > 1. A value for the KeyRSC in the EAPOL-key frame 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. A value of zero in the > EAPOL-key > > > frame for the group key will always work. > > > > > > 3. The client STA will use the value of KeyRSC received in the > > > EAPOL-key frame to validate frame using the KeyMIC. > > > > > > 4. The client STA will also set its group key RSC to the value > > > received in KeyRSC, say, zero. > > > > > > 5. The value in the client STA's RSC will be compared against the > > > sequence number in subsequent received frames to identify replay > > > attacks. Any frame received with a sequence counter value > > within the > > > replay window will be checked to have a valid MIC. If the > > MIC is not > > > valid, the frame is dropped. > > > > > > 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, if the value is greater than its current RSC value. > > Only the > > > AP can meet these criteria as the source of a frame > received by the > > > STA. > > > > > > 7. Please see item 6, immediately above, for the reason > that the AC > > > and WTP do not need to coordinate and exchange the RSC. > > > > > > > > > The only possible attack mode is for the attacker to send > frames to > > > the client STA between the time of the EAPOL-key frame and > > the first > > > frame encrypted with the group key. > > > During this time, the client will receive the frame and > proceed to > > > validate its MIC. This is a potential attack against the STA > > > resources. But, the MIC validation is done in the STA's > > > 802.11 chip and consumes no more resources than receiving > any other > > > frame. Thus, the attack does not actually consume any STA > > resources > > > beyond those of receiving a frame. > > > > > > This attack is not unique to the use of the value zero for > > the KeyRSC, > > > either. The same attack is available to an attacker at any other > > > time, as well. It is no more nor less effective at either time. > > > > > > For these reasons, the protocol is not in need of any changes to > > > address the issue raised by Saranavan. > > > > > > -Bob > > > -----Original Message----- > > > From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > > > Sent: Monday, September 25, 2006 11:37 AM > > > To: Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > This is a very interesting solution. The AC selects the > KeyRSC and > > > performs the 4-way handshake. The WTP sniffs the 4-way handshake > > > traffic and grabs the KeyRSC value and uses it to > > initialize its own > > > counter. > > > > > > Pat/Bob: Is this how the Cisco implementation works? I > > have to agree > > > with Saravanan that I've yet to see a technical > description of how > > > Cisco implements it. > > > > > > IMHO, this is somewhat hackish, and it would be cleaner to > > have the AC > > > generate the KeyRSC and include it in the AddMobile message > > as Behcet > > > suggests. > > > > > > -- > > > t. charles clancy, ph.d. | tcc@umd.edu | > www.cs.umd.edu/~clancy > > > > > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > > > > > > > I think Saravanan has a point. We did a prototype > > impelementation of > > > the > > > > protocol a year ago when it was still called LWAPP. The way > > > we solved > > > > this issue then was to let the WTP sniff on all CAPWAP data > > > messages > > > > from the AC and when message 3 of the 4-way handshake or > > > message 1 of > > > > the groupkey handshake was sent the WTP inserted the correct RSC > > > before > > > > sending it off to the supplicant. To avoid the sniffing on > > > all CAPWAP > > > > data messages we would need a mechanism with in CAPWAP to > > > handle these > > > > two messages. > > > > > > > > Peter Nilsson > > > > > > > > -----Original Message----- > > > > From: Saravanan Govindan > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > Sent: den 22 september 2006 11:03 > > > > To: Margaret Wasserman > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > Hi Margaret, > > > > > > > > Thank you for reviewing the discussion on this issue. > > > > > > > > The issue here is the working of IEEE 802.11i when the 802.11i > > > > authenticator element is at the AC and the 802.11i crypto > > element is > > > at > > > > the WTP. Particularly, it is for the 4-way handshake between > > > > authenticator and supplicant. > > > > > > > > Now, the 4-way handshake requires knowing the value of > > > KeyRSC sequence > > > > counter. The KeyRSC helps both authenticator and supplicant > > > keep track > > > > of their exchanges. It serves to protect against threats by > > > tracking > > > > sequential frames. The KeyRSC is maintained at the at the > > point of > > > > encryption, i.e. just before transmission over the > > wireless channel. > > > > > > > > In the case of CAPWAP, the 4-way handshake is between the AC > > > > (authenticator) and the wireless station (supplicant). > > > > > > > > The problem arises, when the authenticator is at the AC and > > > the crypto > > > > element (together with KeyRSC) is at the WTP. This is a > > > fairly common > > > > design. Now in this case, the AC starts the 4-way > handshake but it > > > does > > > > not know the value of the KeyRSC. The KeyRSC is maintained > > > by the WTP. > > > > > > > > Based on this, the current CAPWAP specification does not > > allow for a > > > way > > > > to conduct the 4-way handshake with the correct KeyRSC. > > > > > > > > The functionality I would like to see is a way for the > > authenticator > > > > (AC) to use the correct prevailing value of KeyRSC > > > (maintained by the > > > > WTP) in its 4-way handshake. > > > > > > > > One way to introduce this functionality in to CAPWAP is > > to have part > > > of > > > > the 4-way handshake be sent from AC to WTP. This will allow > > > the 4-way > > > > handshake to use the correct value of the KeyRSC before > > > being sent to > > > > the wireless station. > > > > > > > > I hope this helps clarify my view on the issue. > > > > > > > > Cheers, > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > > > > Sent: Thursday, September 21, 2006 8:26 PM > > > > To: Saravanan Govindan > > > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > > > > > > > > > Hi again, > > > > > > > > Okay, I am even more confused than I thought I was... > > > > > > > > Saravanan, you wrote: > > > > > > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > > > > > >> Pat, > > > >> > > > >> The issue here is about how 802.11i exchanges are done when > > > >> authenticator is at the AC and crypto elements are at > > the WTP. This > > > is > > > >> the requirement. > > > > > > > > And, in response, Pat Calhoun wrote: > > > > > > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: > > > >> The current specification allows the authenticator to > > > reside in the > > > >> AC, while the data packet crypto elements in the WTP. This > > > feature is > > > >> already in the specification. > > > > > > > > Pat's message matches my reading of the specification. > > > > > > > > So, Saravanan, what functionality are you asking for > that is not > > > > already supported by the specification? And why do you > > think it is > > > > necessary? it will not be helpful to my understanding to > > > re-send your > > > > proposal or to cite the requirements document... Please > > summarize > > > > what functionality you think is missing from the current > > > specification > > > > and why you think that functionality is necessary to > support IEEE > > > > 802.11i or any important use case. > > > > > > > > At some point, the chairs may need to make a consensus > > call on this > > > > issue, and I'd like to understand your view and make sure > > > that it has > > > > been clearly communicated to the WG before we ask the WG to > > > decide on > > > > this issue. > > > > > > > > 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 > > > > > _________________________________________________________________ > > > > 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 > > > > > _________________________________________________________________ > > 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 Thu Sep 28 14:31:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT0fS-0006XR-2f for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 14:31:30 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT0fP-0001Lo-E0 for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 14:31:30 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 5409C1448024 for ; Thu, 28 Sep 2006 11:31:19 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C367A43005F for ; Thu, 28 Sep 2006 11:14:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B39A0144803C for ; Thu, 28 Sep 2006 11:14:01 -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 C05D61448061 for ; Thu, 28 Sep 2006 11:13:50 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 28 Sep 2006 11:13:50 -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 k8SIDo8G018659; Thu, 28 Sep 2006 11:13:50 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8SIDn1E005768; Thu, 28 Sep 2006 11:13:49 -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); Thu, 28 Sep 2006 11:13:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Sep 2006 11:13:49 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC02188A68@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbijwZCS/drdZO0QDS7JR+3RgvYSAAmpSQA From: "Bob O'Hara (boohara)" To: "Michael Montemurro" X-OriginalArrivalTime: 28 Sep 2006 18:13:49.0853 (UTC) FILETIME=[D8E294D0:01C6E329] Authentication-Results: sj-dkim-2.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.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_40_50, HTML_MESSAGE, NORMAL_HTTP_TO_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1106981273==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 946b615681bce2b72aace5af8d0d8a1d This is a multi-part message in MIME format. --===============1106981273== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E329.D8ADB6C1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E329.D8ADB6C1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Michael, =20 This is entirely unnecessary, as 802.11i requires the TSC (KeyRSC) to be initialized to a fixed value, i.e., the first frame encrypted with the new key MUST use the value of 1 for the sequence counter. -Bob =20 =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Wednesday, September 27, 2006 4:45 PM To: Bob O'Hara (boohara) Cc: Behcet Sarikaya; capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations Actually, in CAPWAP-02, the keyRSC is sent to the WTP on the group key update. =20 But as yet, we have left the Oxford English Dictionary out. :-) =20 Cheers, =20 Mike =20 On 9/27/06, Bob O'Hara (boohara) wrote:=20 Bechet,=20 =20 no, it would not hurt. But it is completely unnecessary, as is sending a copy of the Oxford English Dictionary to the WTP. but, we could do that, too.=20 -Bob =20 =20 ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Tuesday, September 26, 2006 1:45 PM To: Bob O'Hara (boohara) Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations =09 =20 =09 So, Bob, communicating the key RSC value to WTP would not hurt, would it? Or something to this effect, like AC initializing to zero of the group key KeyRSC of all WTPs? =20 Regards, =20 --behcet =09 =20 ----- Original Message ---- From: Bob O'Hara (boohara) < boohara@cisco.com > To: T. Charles Clancy ; Peter Nilsson J (LI/EAB) < peter.j.nilsson@ericsson.com > =09 Cc: capwap@frascone.com Sent: Tuesday, September 26, 2006 1:31:59 PM=20 Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations =09 =09 Charles, Peter, =09 Below is an expansion of a snippet from a thread on this topic that I sent to the list on July 25, 2006. I think this will be helpful to understand why the exchange that Saranavan is requesting is not=20 necessary. In fact, there are several systems from several manufacturers in the field using precursor protocols to CAPWAP that are Wi-Fi certified for WPA2/802.11i operation using the protocol as it is described below. =20 =09 BTW, this whole discussion is about the KeyRSC for the group key, not the pairwise key. This is so because the WTP and AC both know the initial sequence counter value for the pairwise key, since it has never=20 been used to send a frame. 802.11i requires the first frame sent on a key to use the sequence counter value of 1. See 8.3.2.6 c) and 8.3.3.4.3 c) in 802.11i for this requirement. =09 The same is not true of the group key, i.e., after the WTP begins operation, the AC will not know the value of the sequence counter for the group key when it needs to complete the EAPOL-key handshake with a=20 newly associated STA. However, as you will see from the tutorial below, it is not necessary for the AC and WTP to exchange any information about the group key KeyRSC for the protocol to operate as it is intended.=20 =09 1. A value for the KeyRSC in the EAPOL-key frame is necessary to calculate the KeyMIC.=20 =09 2. This value does not need to bear any specific relationship to the RSC value maintained by the WTP. A value of zero in the EAPOL-key frame for=20 the group key will always work. =09 3. The client STA will use the value of KeyRSC received in the EAPOL-key frame to validate frame using the KeyMIC.=20 =09 4. The client STA will also set its group key RSC to the value received=20 in KeyRSC, say, zero. =09 5. The value in the client STA's RSC will be compared against the sequence number in subsequent received frames to identify replay attacks. Any frame received with a sequence counter value within the=20 replay window will be checked to have a valid MIC. If the MIC is not valid, the frame is dropped. =09 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=20 updates its RSC value to the sequence number in the received frame, if the value is greater than its current RSC value. Only the AP can meet these criteria as the source of a frame received by the STA. =09 7. Please see item 6, immediately above, for the reason that the AC and=20 WTP do not need to coordinate and exchange the RSC. =09 =09 The only possible attack mode is for the attacker to send frames to the client STA between the time of the EAPOL-key frame and the first frame encrypted with the group key. During this time, the client will receive=20 the frame and proceed to validate its MIC. This is a potential attack against the STA resources. But, the MIC validation is done in the STA's 802.11 chip and consumes no more resources than receiving any other=20 frame. Thus, the attack does not actually consume any STA resources beyond those of receiving a frame. =09 This attack is not unique to the use of the value zero for the KeyRSC, either. The same attack is available to an attacker at any other time,=20 as well. It is no more nor less effective at either time. =09 For these reasons, the protocol is not in need of any changes to address the issue raised by Saranavan. =09 -Bob=20 -----Original Message----- From: T. Charles Clancy [mailto:clancy@cs.umd.edu]=20 Sent: Monday, September 25, 2006 11:37 AM To: Peter Nilsson J (LI/EAB)=20 Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations =09 This is a very interesting solution. The AC selects the KeyRSC and=20 performs the 4-way handshake. The WTP sniffs the 4-way handshake traffic=20 and grabs the KeyRSC value and uses it to initialize its own counter.=20 =09 Pat/Bob: Is this how the Cisco implementation works? I have to agree with=20 Saravanan that I've yet to see a technical description of how Cisco=20 implements it. =09 IMHO, this is somewhat hackish, and it would be cleaner to have the AC=20 generate the KeyRSC and include it in the AddMobile message as Behcet=20 suggests. =09 -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy =09 On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: =09 > I think Saravanan has a point. We did a prototype impelementation of the > protocol a year ago when it was still called LWAPP. The way we solved > this issue then was to let the WTP sniff on all CAPWAP data messages=20 > from the AC and when message 3 of the 4-way handshake or message 1 of > the groupkey handshake was sent the WTP inserted the correct RSC before > sending it off to the supplicant. To avoid the sniffing on all CAPWAP=20 > data messages we would need a mechanism with in CAPWAP to handle these > two messages. > > Peter Nilsson > > -----Original Message----- > From: Saravanan Govindan [mailto: Saravanan.Govindan@sg.panasonic.com ] > Sent: den 22 september 2006 11:03 > To: Margaret Wasserman > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > Hi Margaret, > > Thank you for reviewing the discussion on this issue. > > The issue here is the working of IEEE 802.11i when the 802.11i > authenticator element is at the AC and the 802.11i crypto element is at > the WTP. Particularly, it is for the 4-way handshake between > authenticator and supplicant. >=20 > Now, the 4-way handshake requires knowing the value of KeyRSC sequence > counter. The KeyRSC helps both authenticator and supplicant keep track > of their exchanges. It serves to protect against threats by tracking=20 > sequential frames. The KeyRSC is maintained at the at the point of > encryption, i.e. just before transmission over the wireless channel. > > In the case of CAPWAP, the 4-way handshake is between the AC=20 > (authenticator) and the wireless station (supplicant). > > The problem arises, when the authenticator is at the AC and the crypto > element (together with KeyRSC) is at the WTP. This is a fairly common=20 > design. Now in this case, the AC starts the 4-way handshake but it does > not know the value of the KeyRSC. The KeyRSC is maintained by the WTP. > > Based on this, the current CAPWAP specification does not allow for a=20 way > to conduct the 4-way handshake with the correct KeyRSC. > > The functionality I would like to see is a way for the authenticator > (AC) to use the correct prevailing value of KeyRSC (maintained by the=20 > WTP) in its 4-way handshake. > > One way to introduce this functionality in to CAPWAP is to have part of > the 4-way handshake be sent from AC to WTP. This will allow the 4-way > handshake to use the correct value of the KeyRSC before being sent to=20 > the wireless station. > > I hope this helps clarify my view on the issue. > > Cheers, > > Saravanan > > > > > > > -----Original Message-----=20 > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, September 21, 2006 8:26 PM=20 > To: Saravanan Govindan > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > > > Hi again, > > Okay, I am even more confused than I thought I was... > > Saravanan, you wrote: > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote:=20 > >> Pat, >> >> The issue here is about how 802.11i exchanges are done when >> authenticator is at the AC and crypto elements are at the WTP. This is >> the requirement.=20 > > And, in response, Pat Calhoun wrote: > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: >> The current specification allows the authenticator to reside in the >> AC,=20 >> while the data packet crypto elements in the WTP. This feature is >> already in the specification. > > Pat's message matches my reading of the specification. > > So, Saravanan, what functionality are you asking for that is not=20 > already supported by the specification? And why do you think it is > necessary? it will not be helpful to my understanding to re-send > your proposal or to cite the requirements document... Please > summarize what functionality you think is missing from the current > specification and why you think that functionality is necessary to > support IEEE 802.11i or any important use case. > > At some point, the chairs may need to make a consensus call on this=20 > issue, and I'd like to understand your view and make sure that it has > been clearly communicated to the WG before we ask the WG to decide on > this issue. > > 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=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap=20 > =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =20 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit:=20 http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap =09 =09 ------_=_NextPart_001_01C6E329.D8ADB6C1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Michael,
 
This is entirely unnecessary, as 802.11i = requires the TSC=20 (KeyRSC) to be initialized to a fixed value, i.e., the first frame = encrypted=20 with the new key MUST use the value of 1 for the sequence=20 counter.

 -Bob
 

 

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Wednesday, = September 27,=20 2006 4:45 PM
To: Bob O'Hara (boohara)
Cc: Behcet = Sarikaya;=20 capwap@frascone.com
Subject: Re: [Capwap] Issue 43 - = Explanation for=20 802.11i Considerations

Actually, in CAPWAP-02, the keyRSC is sent to the WTP on the group = key=20 update.
 
But as yet, we have left the Oxford English Dictionary out. = :-)
 
Cheers,
 
Mike

 
On 9/27/06, Bob O'Hara=20 (boohara) <boohara@cisco.com>=20 wrote:=20
Bechet,=20
 
no, it=20 would not hurt.  <sarcasm>But it is completely unnecessary, = as is=20 sending a copy of the Oxford English Dictionary to the WTP.  but, = we=20 could do that, too.</sarcasm>

 -Bob
 

 

From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]
Sent: = Tuesday,=20 September 26, 2006 1:45 PM
To: Bob O'Hara=20 (boohara)
Cc: capwap@frascone.com
Subject: Re: = [Capwap] Issue 43=20 - Explanation for 802.11i = Considerations

 
So,=20 Bob, communicating the key RSC value to WTP would not hurt, would = it?
Or=20 something to this effect, like AC initializing to zero of the group = key KeyRSC=20 of all WTPs?
  Regards,   --behcet

  ----- Original Message ----
From: Bob O'Hara (boohara) = <=20 boohara@cisco.com>
To: T. Charles Clancy <clancy@cs.umd.edu>; Peter=20 Nilsson J (LI/EAB) <=20 peter.j.nilsson@ericsson.com>
Cc: capwap@frascone.com
Sent: Tuesday, September = 26, 2006=20 1:31:59 PM
Subject: Re: [Capwap] Issue 43 - Explanation for = 802.11i=20 Considerations

Charles, Peter,

Below is an expansion of a snippet from a = thread=20 on this topic that I
sent to the list on July 25, = 2006.  I think=20 this will be helpful to
understand why the exchange that Saranavan = is=20 requesting is not
necessary.  In fact, there are several = systems=20 from several
manufacturers in the field using precursor protocols = to CAPWAP=20 that are
Wi-Fi certified for WPA2/802.11i operation using the = protocol as=20 it is
described below.  

BTW, this whole = discussion is=20 about the KeyRSC for the group key, not
the pairwise = key.  This=20 is so because the WTP and AC both know the
initial sequence counter = value=20 for the pairwise key, since it has never
been used to send a=20 frame.  802.11i requires the first frame sent on a
key to = use the=20 sequence counter value of 1.  See 8.3.2.6 c) and
8.3.3.4.3 c) in 802.11i for this = requirement.

The same is not true of the group key, i.e., after = the WTP=20 begins
operation, the AC will not know the value of the sequence = counter=20 for
the group key when it needs to complete the EAPOL-key handshake = with a=20
newly associated STA.  However, as you will see from the = tutorial below,
it is not necessary for the AC and WTP to exchange = any=20 information about
the group key KeyRSC for the protocol to operate = as it is=20 intended.

1. A value for the KeyRSC in the EAPOL-key frame is=20 necessary to
calculate the KeyMIC.

2. This value does not = need to=20 bear any specific relationship to the RSC
value maintained by the=20 WTP.  A value of zero in the EAPOL-key frame for
the = group key=20 will always work.

3. The client STA will use the value of = KeyRSC=20 received in the EAPOL-key
frame to validate frame using the KeyMIC. =

4. The client STA will also set its group key RSC to the value = received
in KeyRSC, say, zero.

5. The value in the client = STA's RSC=20 will be compared against the
sequence number in subsequent received = frames=20 to identify replay
attacks.  Any frame received with a = sequence=20 counter value within the
replay window will be checked to have a = valid=20 MIC.  If the MIC is not
valid, the frame is = dropped.

6.=20 For any frame that is determined not to be a replay attack frame = and
meets=20 all other validity and authenticity requirements, the client STA =
updates=20 its RSC value to the sequence number in the received frame, if
the = value is=20 greater than its current RSC value.  Only the AP can = meet
these=20 criteria as the source of a frame received by the STA.

7. = Please see=20 item 6, immediately above, for the reason that the AC and
WTP do = not need=20 to coordinate and exchange the RSC.


The only possible = attack mode=20 is for the attacker to send frames to the
client STA between the = time of=20 the EAPOL-key frame and the first frame
encrypted with the group=20 key.  During this time, the client will receive
the = frame and=20 proceed to validate its MIC.  This is a potential = attack
against=20 the STA resources.  But, the MIC validation is done in the=20 STA's
802.11 chip and consumes no more resources than receiving any = other=20
frame.  Thus, the attack does not actually consume any = STA=20 resources
beyond those of receiving a frame.

This attack is = not=20 unique to the use of the value zero for the = KeyRSC,
either.  The=20 same attack is available to an attacker at any other time,
as=20 well.  It is no more nor less effective at either = time.

For=20 these reasons, the protocol is not in need of any changes to = address
the=20 issue raised by Saranavan.

-Bob
-----Original = Message-----
From:=20 T. Charles Clancy [mailto:clancy@cs.umd.edu]
Sent:=20 Monday, September 25, 2006 11:37 AM
To: Peter Nilsson J (LI/EAB) =
Cc: capwap@frascone.com
Subject: Re: [Capwap] Issue = 43 -=20 Explanation for 802.11i Considerations

This is a very = interesting=20 solution.  The AC selects the KeyRSC and
performs the = 4-way=20 handshake.  The WTP sniffs the 4-way handshake
traffic =
and=20 grabs the KeyRSC value and uses it to initialize its own counter.=20

Pat/Bob: Is this how the Cisco implementation = works?  I have=20 to agree
with
Saravanan that I've yet to see a technical = description of=20 how Cisco
implements it.

IMHO, this is somewhat hackish, = and it=20 would be cleaner to have the AC
generate the KeyRSC and include it = in the=20 AddMobile message as Behcet
suggests.

--
t. charles = clancy,=20 ph.d.  |  =20 tcc@umd.edu  |  www.cs.umd.edu/~clancy

On Mon, 25 Sep 2006, = Peter=20 Nilsson J (LI/EAB) wrote:

> I think Saravanan has a point. = We did a=20 prototype impelementation of
the
> protocol a year ago when = it was=20 still called LWAPP. The way we solved
> this issue then was to = let the=20 WTP sniff on all CAPWAP data messages
> from the AC and when = message 3=20 of the 4-way handshake or message 1 of
> the groupkey handshake = was sent=20 the WTP inserted the correct RSC
before
> sending it off to = the=20 supplicant. To avoid the sniffing on all CAPWAP
> data messages = we=20 would need a mechanism with in CAPWAP to handle these
> two=20 messages.
>
> Peter Nilsson
>
> -----Original=20 Message-----
> From: Saravanan Govindan [mailto:=20 Saravanan.Govindan@sg.panasonic.com]
> Sent: den 22 = september 2006=20 11:03
> To: Margaret Wasserman
> Cc: capwap@frascone.com
> Subject: Re: [Capwap] = Issue 43 -=20 Explanation for 802.11i
Considerations
>
> Hi=20 Margaret,
>
> Thank you for reviewing the discussion on = this=20 issue.
>
> The issue here is the working of IEEE 802.11i = when the=20 802.11i
> authenticator element is at the AC and the 802.11i = crypto=20 element is
at
> the WTP. Particularly, it is for the 4-way = handshake=20 between
> authenticator and supplicant.
>
> Now, = the 4-way=20 handshake requires knowing the value of KeyRSC sequence
> = counter. The=20 KeyRSC helps both authenticator and supplicant keep track
> of = their=20 exchanges. It serves to protect against threats by tracking
>=20 sequential frames. The KeyRSC is maintained at the at the point = of
>=20 encryption, i.e. just before transmission over the wireless=20 channel.
>
> In the case of CAPWAP, the 4-way handshake is = between=20 the AC
> (authenticator) and the wireless station=20 (supplicant).
>
> The problem arises, when the = authenticator is at=20 the AC and the crypto
> element (together with KeyRSC) is at the = WTP.=20 This is a fairly common
> design. Now in this case, the AC = starts the=20 4-way handshake but it
does
> not know the value of the = KeyRSC. The=20 KeyRSC is maintained by the WTP.
>
> Based on this, the = current=20 CAPWAP specification does not allow for a
way
> to conduct = the 4-way=20 handshake with the correct KeyRSC.
>
> The functionality I = would=20 like to see is a way for the authenticator
> (AC) to use the = correct=20 prevailing value of KeyRSC (maintained by the
> WTP) in its = 4-way=20 handshake.
>
> One way to introduce this functionality in = to=20 CAPWAP is to have part
of
> the 4-way handshake be sent from = AC to=20 WTP. This will allow the 4-way
> handshake to use the correct = value of=20 the KeyRSC before being sent to
> the wireless = station.
>
>=20 I hope this helps clarify my view on the issue.
>
>=20 Cheers,
>
>=20 Saravanan
>
>
>
>
>
>
>=20 -----Original Message-----
> From: Margaret Wasserman = [mailto:margaret@thingmagic.com]
> Sent: Thursday, = September=20 21, 2006 8:26 PM
> To: Saravanan Govindan
> Cc: Pat = Calhoun=20 (pacalhou); capwap@frascone.com
> Subject: Re: [Capwap] = Issue 43 -=20 Explanation for = 802.11i
Considerations
>
>
>
> Hi=20 again,
>
> Okay, I am even more confused than I thought I=20 was...
>
> Saravanan, you wrote:
>
> On Sep = 17, 2006,=20 at 10:24 PM, Saravanan Govindan wrote:
>
>>=20 Pat,
>>
>> The issue here is about how 802.11i = exchanges are=20 done when
>> authenticator is at the AC and crypto elements = are at=20 the WTP. This
is
>> the requirement.
>
> And, = in=20 response, Pat Calhoun wrote:
>
> On Sep 18, 2006, at 4:15 = PM, Pat=20 Calhoun (pacalhou) wrote:
>> The current specification allows = the=20 authenticator to reside in the
>> AC,
>> while the = data=20 packet crypto elements in the WTP. This feature is
>> already = in the=20 specification.
>
> Pat's message matches my reading of the = specification.
>
> So, Saravanan, what functionality are = you=20 asking for that is not
> already supported by the=20 specification?  And why do you think it is
>=20 necessary?  it will not be helpful to my understanding to=20 re-send
> your proposal or to cite the requirements=20 document...  Please
> summarize what functionality you = think=20 is missing from the current
> specification and why you think = that=20 functionality is necessary to
> support IEEE 802.11i or any = important=20 use case.
>
> At some point, the chairs may need to make a = consensus call on this
> issue, and I'd like to understand your = view=20 and make sure that it has
> been clearly communicated to the WG = before=20 we ask the WG to decide on
> this issue.
>
> = Thanks,
>=20 Margaret
>
>
>
>
>
>
>=20 = _________________________________________________________________
>= To=20 unsubscribe or modify your subscription options, please visit:
> = http://lists.frascone.com/mailman/listinfo/capwap
= >
>=20 Archives: http://lists.frascone.com/pipermail/capwap =
>=20 = _________________________________________________________________
>= To=20 unsubscribe or modify your subscription options, please visit:
> = http://lists.frascone.com/mailman/listinfo/capwap
= >
>=20 Archives: http://lists.frascone.com/pipermail/capwap=20 =
>
_________________________________________________________= ________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20 =
_________________________________________________________________=
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20

 
_____________________________= ____________________________________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap


------_=_NextPart_001_01C6E329.D8ADB6C1-- --===============1106981273== 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 --===============1106981273==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Sep 28 14:49:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT0wp-0001E8-Va for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 14:49:27 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT0wn-0005Al-Qv for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 14:49:27 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id C855E1448057 for ; Thu, 28 Sep 2006 11:49:16 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4BC9243005F for ; Thu, 28 Sep 2006 11:40:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3087C1448050 for ; Thu, 28 Sep 2006 11:40:57 -0700 (PDT) Received: from bay0-omc2-s28.bay0.hotmail.com (bay0-omc2-s28.bay0.hotmail.com [65.54.246.164]) by hermes.tigertech.net (Postfix) with ESMTP id F4118144807D for ; Thu, 28 Sep 2006 11:40:53 -0700 (PDT) Received: from hotmail.com ([207.46.8.209]) by bay0-omc2-s28.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Sep 2006 11:40:53 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 28 Sep 2006 11:40:43 -0700 Message-ID: Received: from 207.46.8.251 by by118fd.bay118.hotmail.msn.com with HTTP; Thu, 28 Sep 2006 18:40:42 GMT X-Originating-IP: [24.226.128.157] X-Originating-Email: [saravanang@hotmail.com] X-Sender: saravanang@hotmail.com In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC02188A65@xmb-sjc-237.amer.cisco.com> From: "Saravanan Govindan" To: boohara@cisco.com, Hong.Cheng@sg.panasonic.com, pcalhoun@cisco.com, clancy@cs.umd.edu, peter.j.nilsson@ericsson.com Date: Fri, 29 Sep 2006 02:40:42 +0800 Mime-Version: 1.0 X-OriginalArrivalTime: 28 Sep 2006 18:40:43.0631 (UTC) FILETIME=[9AC58FF0:01C6E32D] 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: * Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 9b157e6e8a3799aef911c0bc37fc93a6 I find it difficult to consider an approach for a protocol standard that requires specific numeric values for protocol parameters. I thought the aim of a standard was to provide an interoperable framework that goes beyond specific parameter values. Saravanan ----Original Message Follows---- From: "Bob O'Hara (boohara)" To: "Cheng Hong" ,"Pat Calhoun (pacalhou)" ,"T. Charles Clancy" ,"Peter Nilsson J (LI/EAB)" CC: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations Date: Thu, 28 Sep 2006 11:11:50 -0700 Please understand that 802.11i specifies no behavior in this area for the 802.1X authenticator. Our choice to send a group key KeyRSC value of zero in the EAPOL-key frame requires no change to 802.11i or to 802.1X. It requires us to state this in the CAPWAP spec, if we want this behavior to be consistent across all implementations. The problem with what Bechet and Saranavan are asking is that either of three different things are required: 1: the WTP must communicate the group key TSC to the AC every time it is updated, or 2: the AC must request the current value of the group key TSC for the KeyRSC before constructing the EAPOL-key frame, or 3: the AC must send the KCK to the AC so that it can insert the KeyRSC value and also calculate the correct MIC, inserting that into the proper EAPOL-key frame. The first item requires a tremendous amount of additional CAPWAP communication between WTP and AC, at least one new CAPWAP packet for every multicast frame sent by the WTP, if the packet is not acknowledged, or two new CAPWAP packets, if it is acknowledged. This is a very expensive addition to the protocol. The second item requires new protocol between the AC and WTP during what can be a time critical portion of the 802.11 transition (handoff, roam) from one WTP to another. It also introduces a race condition that is not present in the protocol today. Once the value for the KeyRSC is sent from the WTP to the AC, it is possible that the WTP can send another multicast frame encrypted with the group key. This puts the value of the sequence counter out of sync with the value that will be shortly communicated to the client in the EAPOL-key frame from the AC. This will behave exactly the same as if a value of zero is sent in the EAPOL-key frame. The third item requires a new architecture split that is not required in our objectives. The new split is not splitting the MAC, but splitting the authenticator. Placing the KCK in the WTP is also a potential reduction in the security of the overall WLAN system, since these devices are normally not in a secured wiring closet, but exposed and more easily compromised than the AC. The simplest to implement, least expensive, and most secure option is to use the protocol as it is now specified and have the AC send a value of zero in the KeyRSC field of the EAPOL-key frame. -Bob -----Original Message----- From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] Sent: Wednesday, September 27, 2006 6:50 PM To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson J (LI/EAB) Cc: capwap@frascone.com Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi Pat and all, So, based on this, I would say that we have consensus that setting the correct KeyRSC is an issue for the CAPWAP protocol design. So far, we have three option/solutions: 1) As proposed by Bob: Using a static value (0) for the KeyRSC. 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP 3) As suggested by Saravanana: Some exchange mechanism between WTP and AC Among the three, the first option seems the easiest. However, it requires a mandated Authenticator behavior(in this case AC) that is not mandated by 802.11. Therefore, we have to specify that (e.g. as proposed by Bob: "We could include a note to the effect that the group KeyRSC should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11, because otherwise there is no interoperability. For example, AC provided by another vendor does not have to set KeyRSC to 0 to be compliant with CAPWAP and 802.11i. Another implication is that we don't really understand the impact of mandating a static KeyRSC value. Although Bob provided an excellent analysis, I still have some doubts about the profoundness of the impact. If the KeyRSC value is as described of no use, why would it appear in the EAPOL frames in the first place? By mandating it to static value, what have we lost? Maybe some liaison letter to 802.1 or 802.11 could provide us a better understanding of the issue. For the last two options, I think they are both within CAPWAP's scope. Further analysis could help us to decide which one is better (or someone could propose other solutions). cheers Cheng Hong > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Thursday, September 28, 2006 1:39 AM > To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; > Peter Nilsson J (LI/EAB) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Bob's point is 802.11i works this way today. The AP (or in > this case AC) can set the RSC to whatever value it wishes. > Bob used zero (0) as an example. Implementations could use > any other value, which would require some form of > communication to the WTP, as suggested by Behcet. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > > Sent: Tuesday, September 26, 2006 6:03 PM > > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson > J (LI/EAB) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > Hi Bob, > > > > If I understand your description below correct, you are proposing a > > solution (to the problem pointed out by > > Saravanan) by mandating the behavior of the AC to always set the > > KeyRSC in the 4-way handshake to zero. > > > > This is not a defined behavior according to the current > > 802.11 standard. > > Are you suggesting that we CAPWAP WG should specifically > mandate that > > in our CAPWAP protocol spec, e.g. something like "a CAPWAP > compatible > > AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, > > since not all AC implementation have to follow what you described. > > > > Or, are you planning to take this issue to TGm for 802.11 standard > > revision? (since based on your description, there is essentially no > > use of the KeyRSC). > > > > cheers > > > > Cheng Hong > > > > > > > > > > > -----Original Message----- > > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > > > Sent: Wednesday, September 27, 2006 2:32 AM > > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > Charles, Peter, > > > > > > Below is an expansion of a snippet from a thread on this > > topic that I > > > sent to the list on July 25, 2006. I think this will be > helpful to > > > understand why the exchange that Saranavan is requesting is not > > > necessary. In fact, there are several systems from several > > > manufacturers in the field using precursor protocols to > CAPWAP that > > > are Wi-Fi certified for WPA2/802.11i operation using the > > protocol as > > > it is described below. > > > > > > BTW, this whole discussion is about the KeyRSC for the > > group key, not > > > the pairwise key. This is so because the WTP and AC both > know the > > > initial sequence counter value for the pairwise key, since it has > > > never been used to send a frame. 802.11i requires the > first frame > > > sent on a key to use the sequence counter value of 1. See > > 8.3.2.6 c) > > > and > > > 8.3.3.4.3 c) in 802.11i for this requirement. > > > > > > The same is not true of the group key, i.e., after the WTP begins > > > operation, the AC will not know the value of the sequence > > counter for > > > the group key when it needs to complete the EAPOL-key > > handshake with a > > > newly associated STA. > > > However, as you will see from the tutorial below, it is not > > necessary > > > for the AC and WTP to exchange any information about the > group key > > > KeyRSC for the protocol to operate as it is intended. > > > > > > 1. A value for the KeyRSC in the EAPOL-key frame 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. A value of zero in the > EAPOL-key > > > frame for the group key will always work. > > > > > > 3. The client STA will use the value of KeyRSC received in the > > > EAPOL-key frame to validate frame using the KeyMIC. > > > > > > 4. The client STA will also set its group key RSC to the value > > > received in KeyRSC, say, zero. > > > > > > 5. The value in the client STA's RSC will be compared against the > > > sequence number in subsequent received frames to identify replay > > > attacks. Any frame received with a sequence counter value > > within the > > > replay window will be checked to have a valid MIC. If the > > MIC is not > > > valid, the frame is dropped. > > > > > > 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, if the value is greater than its current RSC value. > > Only the > > > AP can meet these criteria as the source of a frame > received by the > > > STA. > > > > > > 7. Please see item 6, immediately above, for the reason > that the AC > > > and WTP do not need to coordinate and exchange the RSC. > > > > > > > > > The only possible attack mode is for the attacker to send > frames to > > > the client STA between the time of the EAPOL-key frame and > > the first > > > frame encrypted with the group key. > > > During this time, the client will receive the frame and > proceed to > > > validate its MIC. This is a potential attack against the STA > > > resources. But, the MIC validation is done in the STA's > > > 802.11 chip and consumes no more resources than receiving > any other > > > frame. Thus, the attack does not actually consume any STA > > resources > > > beyond those of receiving a frame. > > > > > > This attack is not unique to the use of the value zero for > > the KeyRSC, > > > either. The same attack is available to an attacker at any other > > > time, as well. It is no more nor less effective at either time. > > > > > > For these reasons, the protocol is not in need of any changes to > > > address the issue raised by Saranavan. > > > > > > -Bob > > > -----Original Message----- > > > From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > > > Sent: Monday, September 25, 2006 11:37 AM > > > To: Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > This is a very interesting solution. The AC selects the > KeyRSC and > > > performs the 4-way handshake. The WTP sniffs the 4-way handshake > > > traffic and grabs the KeyRSC value and uses it to > > initialize its own > > > counter. > > > > > > Pat/Bob: Is this how the Cisco implementation works? I > > have to agree > > > with Saravanan that I've yet to see a technical > description of how > > > Cisco implements it. > > > > > > IMHO, this is somewhat hackish, and it would be cleaner to > > have the AC > > > generate the KeyRSC and include it in the AddMobile message > > as Behcet > > > suggests. > > > > > > -- > > > t. charles clancy, ph.d. | tcc@umd.edu | > www.cs.umd.edu/~clancy > > > > > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > > > > > > > I think Saravanan has a point. We did a prototype > > impelementation of > > > the > > > > protocol a year ago when it was still called LWAPP. The way > > > we solved > > > > this issue then was to let the WTP sniff on all CAPWAP data > > > messages > > > > from the AC and when message 3 of the 4-way handshake or > > > message 1 of > > > > the groupkey handshake was sent the WTP inserted the correct RSC > > > before > > > > sending it off to the supplicant. To avoid the sniffing on > > > all CAPWAP > > > > data messages we would need a mechanism with in CAPWAP to > > > handle these > > > > two messages. > > > > > > > > Peter Nilsson > > > > > > > > -----Original Message----- > > > > From: Saravanan Govindan > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > Sent: den 22 september 2006 11:03 > > > > To: Margaret Wasserman > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > Hi Margaret, > > > > > > > > Thank you for reviewing the discussion on this issue. > > > > > > > > The issue here is the working of IEEE 802.11i when the 802.11i > > > > authenticator element is at the AC and the 802.11i crypto > > element is > > > at > > > > the WTP. Particularly, it is for the 4-way handshake between > > > > authenticator and supplicant. > > > > > > > > Now, the 4-way handshake requires knowing the value of > > > KeyRSC sequence > > > > counter. The KeyRSC helps both authenticator and supplicant > > > keep track > > > > of their exchanges. It serves to protect against threats by > > > tracking > > > > sequential frames. The KeyRSC is maintained at the at the > > point of > > > > encryption, i.e. just before transmission over the > > wireless channel. > > > > > > > > In the case of CAPWAP, the 4-way handshake is between the AC > > > > (authenticator) and the wireless station (supplicant). > > > > > > > > The problem arises, when the authenticator is at the AC and > > > the crypto > > > > element (together with KeyRSC) is at the WTP. This is a > > > fairly common > > > > design. Now in this case, the AC starts the 4-way > handshake but it > > > does > > > > not know the value of the KeyRSC. The KeyRSC is maintained > > > by the WTP. > > > > > > > > Based on this, the current CAPWAP specification does not > > allow for a > > > way > > > > to conduct the 4-way handshake with the correct KeyRSC. > > > > > > > > The functionality I would like to see is a way for the > > authenticator > > > > (AC) to use the correct prevailing value of KeyRSC > > > (maintained by the > > > > WTP) in its 4-way handshake. > > > > > > > > One way to introduce this functionality in to CAPWAP is > > to have part > > > of > > > > the 4-way handshake be sent from AC to WTP. This will allow > > > the 4-way > > > > handshake to use the correct value of the KeyRSC before > > > being sent to > > > > the wireless station. > > > > > > > > I hope this helps clarify my view on the issue. > > > > > > > > Cheers, > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > > > > Sent: Thursday, September 21, 2006 8:26 PM > > > > To: Saravanan Govindan > > > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > > > > > > > > > Hi again, > > > > > > > > Okay, I am even more confused than I thought I was... > > > > > > > > Saravanan, you wrote: > > > > > > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > > > > > >> Pat, > > > >> > > > >> The issue here is about how 802.11i exchanges are done when > > > >> authenticator is at the AC and crypto elements are at > > the WTP. This > > > is > > > >> the requirement. > > > > > > > > And, in response, Pat Calhoun wrote: > > > > > > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: > > > >> The current specification allows the authenticator to > > > reside in the > > > >> AC, while the data packet crypto elements in the WTP. This > > > feature is > > > >> already in the specification. > > > > > > > > Pat's message matches my reading of the specification. > > > > > > > > So, Saravanan, what functionality are you asking for > that is not > > > > already supported by the specification? And why do you > > think it is > > > > necessary? it will not be helpful to my understanding to > > > re-send your > > > > proposal or to cite the requirements document... Please > > summarize > > > > what functionality you think is missing from the current > > > specification > > > > and why you think that functionality is necessary to > support IEEE > > > > 802.11i or any important use case. > > > > > > > > At some point, the chairs may need to make a consensus > > call on this > > > > issue, and I'd like to understand your view and make sure > > > that it has > > > > been clearly communicated to the WG before we ask the WG to > > > decide on > > > > this issue. > > > > > > > > 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 > > > > > _________________________________________________________________ > > > > 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 > > > > > _________________________________________________________________ > > 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 _________________________________________________________________ Be seen and heard with Windows Live Messenger and Microsoft LifeCams http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://www.microsoft.com/hardware/digitalcommunication/default.mspx?locale=en-us&source=hmtagline _________________________________________________________________ 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 Sep 28 15:26:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT1X8-0008QU-Pb for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 15:26:58 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT1X7-0005zv-7z for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 15:26:58 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 87EDC1448090 for ; Thu, 28 Sep 2006 12:26:53 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 02F9D43005F for ; Thu, 28 Sep 2006 12:26:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E27401448012 for ; Thu, 28 Sep 2006 12:26:06 -0700 (PDT) X-Greylist-Status: Sender first seen 7 days 10:38:57 ago Received: from thingmagic.com (unknown [204.9.221.19]) by hermes.tigertech.net (Postfix) with ESMTP id D99A3144800B for ; Thu, 28 Sep 2006 12:26:04 -0700 (PDT) Received: from [10.0.0.189] (account margaret [10.0.0.189] verified) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1330488; Thu, 28 Sep 2006 15:26:02 -0400 In-Reply-To: <26298393.1159465449346.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> References: <26298393.1159465449346.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <92EA30D4-8C07-4FC3-A2CB-4EED0CEDEEBB@thingmagic.com> From: Margaret Wasserman Date: Thu, 28 Sep 2006 15:24:13 -0400 To: "Scott G. Kelly" X-Mailer: Apple Mail (2.752.2) 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 Subject: Re: [Capwap] 2-Port/Mux Issue Discussion X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: c83ccb5cc10e751496398f1233ca9c3a Hi Scott, I'd just like to state, for clarity, that the message you are responding to came from all three of the CAPWAP chairs. Although I drafted and sent the message, it did reflect input from Mani and Dorothy. This response is just from me, and the opinions expressed are mine. The other chairs may not agree. On Sep 28, 2006, at 1:44 PM, Scott G. Kelly wrote: >> - Single-Processor: In this architecture, the control plane and the >> data plane run on a single processor. The demultiplexing of control >> and data packets happens on that processor. >> >> - Separate Data & Control Planes: In this architecture, the >> data and >> control planes run on separate processors (and possibly on separate >> cards), typically connected via a switching fabric. This is >> a common >> hardware architecture for higher-end routing and switching hardware, >> and it relies on a port-based splitting/load-balancing approach to >> separate the control and data traffic. For CAPWAP to work >> efficiently on these systems, it must be possible to distinguish the >> control and data traffic in the switching hardware, which is >> typically done based on the five-tuple of the send & recv IP >> addresses, the protocol (UDP), and the send & recv port >> numbers. The >> switching hardware cannot do the type of deep packet inspection >> required to demultiplex on CAPWAP header fields. > > This is one of the mischaracterizations I see. The issues have > nothing to do with how many processors there are - they have to do > with separation of control and data planes, and with the switching > facility used to distribute packets between these two planes. This > is a critical distinction. I agree with you comment, and your private note on this subject was very helpful to advance my thinking on this matter. However, I do not think that your correction fundamentally changes the situation. It would have been better if we had characterized these systems based on how received packets are handled, rather than based on the number of processors in the system, but that doesn't change the fact that there are two type of systems: (1) Those where the packet is initially received by a component (such as a NPU or a CPU) that can distinguish between control and data traffic by looking at the CAPWAP headers. There may be additional processors on this type of systems, so using the phrase "single- processor" to describe these systems was not correct. AND (2) Those where the packet is initially received by switching hardware that can only efficiently distinguish between control and data traffic using a five-tuple that includes the UDP ports. There are both high- and low-performance systems that correspond to each architecture. > Based on the clarification above, it should be clear that this is > also a mischaracterization. Either approach will work in either of > the architectures, and in particular, in either of the > architectures _as they are deployed today_. The real problem > appears to be that one vendor has made a conscious choice to limit > the control/data switching facility to 5-tuple-based solutions. I am personally aware of switching equipment from more than one vendor that is restricted to using a five-tuple for switching incoming traffic. I am not currently aware of whether these systems are sold as WLAN switches, but I believe that many of them could be software upgraded to serve in that role. Given the widespread deployment of switches that employ this architecture, I believe that it is desirable to make sure that CAPWAP can be added, as a software upgrade, to systems of this type. I could express some opinions about which architecture is better, but my opinion on that subject is immaterial. Both systems are widely deployed, and I think that we are likely to see wider deployment of CAPWAP if it can work well on both architectures. >> This complexity is a consequence of the choice to tunnel all WLAN >> data traffic to the AC. In split-MAC local-forwarding mode, >> only the >> control plane traffic would be sent to the AC, and data plane >> forwarding would be handled by the WTPs themselves. > > This also seems mischaracterized, because in all currently defined > split-MAC modes, a data channel must be established in order to > handle 802.11 management and authentication frames (even when > you're doing local bridging of the data). Perhaps Mani could respond to this point, as he was the originator of this text. > In any event, Margaret is right: the working group needs to speak > up so we can close this and move on. I'm done arguing about this, > and life will go on one way or another regardless of what we > choose. But at least, we should all be clear on what's happened > here, and go into this eyes wide open. Thanks for your comments, and for your continuing efforts to keep this work moving forward. 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 Sep 28 16:35:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT2ay-0003wI-Oz for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 16:35:00 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT2au-00047t-Ar for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 16:35:00 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 187DB1448023 for ; Thu, 28 Sep 2006 13:34:52 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 6A45D43005F for ; Thu, 28 Sep 2006 13:33:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5071A1448023 for ; Thu, 28 Sep 2006 13:33:13 -0700 (PDT) X-Greylist-Status: Sender first seen 00:05:55 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 EB06F1448024 for ; Thu, 28 Sep 2006 13:33:10 -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 k8SKJ6B6016912 for ; Thu, 28 Sep 2006 16:19:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Sep 2006 14:27:13 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] 2-Port/Mux Issue Discussion Thread-Index: AcbjNAX4FhJtr1W2Rlmf3NSBX9ziswAASFSg From: "Mani, Mahalingam (Mani)" To: "Margaret Wasserman" , "Scott G. Kelly" 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: Cc: capwap Subject: Re: [Capwap] 2-Port/Mux Issue Discussion X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Scott, My response inline to the one about mischaracterization of a given mode. It is not to say that the spli-MAC modes are the issues. Rather the topological deployments that are reportedly likely to be problematic in the claimed traversal cases are better served by local bridging mode provided... More inline. [...] >> This complexity is a consequence of the choice to tunnel all WLAN >> data traffic to the AC. In split-MAC local-forwarding mode, >> only the >> control plane traffic would be sent to the AC, and data plane >> forwarding would be handled by the WTPs themselves. > > This also seems mischaracterized, because in all currently defined > split-MAC modes, a data channel must be established in order to > handle 802.11 management and authentication frames (even when > you're doing local bridging of the data). [Mani, Mahalingam (Mani)] I disagree on the mischaracterization. This suggests WG not to preclude considering use of management & authentication frames over control channel. While the auth frames and mgmt frames (eventually) may not need the protection of the control channel; it is not clear (at least to me) that they can't use them. -mani Perhaps Mani could respond to this point, as he was the originator of this text. > In any event, Margaret is right: the working group needs to speak > up so we can close this and move on. I'm done arguing about this, > and life will go on one way or another regardless of what we > choose. But at least, we should all be clear on what's happened > here, and go into this eyes wide open. Thanks for your comments, and for your continuing efforts to keep this work moving forward. Margaret _________________________________________________________________ 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 Sep 28 16:44:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT2kb-0007oy-T7 for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 16:44:57 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT2kY-0005JE-Qq for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 16:44:57 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id B963D1448039 for ; Thu, 28 Sep 2006 13:44:48 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3D35C43005F for ; Thu, 28 Sep 2006 13:16:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 040091448028 for ; Thu, 28 Sep 2006 13:16:56 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by hermes.tigertech.net (Postfix) with ESMTP id BA0E5144803B for ; Thu, 28 Sep 2006 13:16:42 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so813598nfb for ; Thu, 28 Sep 2006 13:16:39 -0700 (PDT) Received: by 10.48.48.15 with SMTP id v15mr560067nfv; Thu, 28 Sep 2006 13:16:39 -0700 (PDT) Received: by 10.49.42.6 with HTTP; Thu, 28 Sep 2006 13:16:38 -0700 (PDT) Message-ID: <5bfe7a820609281316w349c9c0ep211ecb52a79f1f23@mail.gmail.com> Date: Thu, 28 Sep 2006 13:16:38 -0700 From: "Dorothy Stanley" To: "Bob O'Hara (boohara)" In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC02188A65@xmb-sjc-237.amer.cisco.com> MIME-Version: 1.0 References: <17B8C6DE4E228348B4939BDA6B05A9DC02188A65@xmb-sjc-237.amer.cisco.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=1.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_20_30, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: capwap@frascone.com, Cheng Hong Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0413512929==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.1 (+) X-Scan-Signature: 93a9b7eb0f4b3b8a49c341eb77478ab2 --===============0413512929== Content-Type: multipart/alternative; boundary="----=_Part_70292_24901560.1159474598621" ------=_Part_70292_24901560.1159474598621 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, Below is the text from 802.11REV-maD8.0 Clause 8.5.2, describing the Key RSC field.: "g) Key RSC. This field is 8 octets in length. It contains the receive sequence counter (RSC) for the GTK being installed in IEEE 802.11. It is used in Message 3 of the 4-Way Handshake and Message 1 of the Group Key Handshake, where it is used to synchronize the IEEE 802.11 replay state. It may also be used in the Michael MIC Failure Report frame, to report the TSC field value of the frame experiencing a MIC failure. It shall contain 0 in other messages. The Key RSC field gives the current message number for the GTK, to allow a STA to identify replayed MPDUs. If the Key RSC field value is less than 8 octets in length, the remaining octets shall be set to 0. The least significant octet of the TSC or PN should be in the first octet of the Key RSC field." The intent of adding this value in message 3 was to immediately minimize the number of replayed frames that a STA would potentially process: "The Key RSC field gives the current message number for the GTK, to allow a STA to identify replayed MPDUs." Setting the value to 0 in Msg 3 does not provide the current sequence counter (in most cases not even close) of the GTK.. Perhaps the WTP could periodically/frequently notify the AC of its current GTK sequence counter, and the AC would use the most recently received value in the message 3 sent to new STAs. The RSC value would not be up to date at all times, but would be closer than "0", not require an "in-the-critical-path message exchange between the AC and WTP, and still be close to the intended use of the field. Dorothy On 9/28/06, Bob O'Hara (boohara) wrote: > > Please understand that 802.11i specifies no behavior in this area for > the 802.1X authenticator. Our choice to send a group key KeyRSC value > of zero in the EAPOL-key frame requires no change to 802.11i or to > 802.1X. It requires us to state this in the CAPWAP spec, if we want > this behavior to be consistent across all implementations. > > The problem with what Bechet and Saranavan are asking is that either of > three different things are required: > 1: the WTP must communicate the group key TSC to the AC every time it is > updated, or > 2: the AC must request the current value of the group key TSC for the > KeyRSC before constructing the EAPOL-key frame, or > 3: the AC must send the KCK to the AC so that it can insert the KeyRSC > value and also calculate the correct MIC, inserting that into the proper > EAPOL-key frame. > > The first item requires a tremendous amount of additional CAPWAP > communication between WTP and AC, at least one new CAPWAP packet for > every multicast frame sent by the WTP, if the packet is not > acknowledged, or two new CAPWAP packets, if it is acknowledged. This is > a very expensive addition to the protocol. > > The second item requires new protocol between the AC and WTP during what > can be a time critical portion of the 802.11 transition (handoff, roam) > from one WTP to another. It also introduces a race condition that is > not present in the protocol today. Once the value for the KeyRSC is > sent from the WTP to the AC, it is possible that the WTP can send > another multicast frame encrypted with the group key. This puts the > value of the sequence counter out of sync with the value that will be > shortly communicated to the client in the EAPOL-key frame from the AC. > This will behave exactly the same as if a value of zero is sent in the > EAPOL-key frame. > > The third item requires a new architecture split that is not required in > our objectives. The new split is not splitting the MAC, but splitting > the authenticator. Placing the KCK in the WTP is also a potential > reduction in the security of the overall WLAN system, since these > devices are normally not in a secured wiring closet, but exposed and > more easily compromised than the AC. > > The simplest to implement, least expensive, and most secure option is to > use the protocol as it is now specified and have the AC send a value of > zero in the KeyRSC field of the EAPOL-key frame. > > -Bob > > -----Original Message----- > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > Sent: Wednesday, September 27, 2006 6:50 PM > To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy; > Peter Nilsson J (LI/EAB) > Cc: capwap@frascone.com > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > Hi Pat and all, > > So, based on this, I would say that we have consensus that setting the > correct KeyRSC is an issue for the CAPWAP protocol design. > > So far, we have three option/solutions: > > 1) As proposed by Bob: Using a static value (0) for the KeyRSC. > > 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP > > 3) As suggested by Saravanana: Some exchange mechanism between WTP and > AC > > Among the three, the first option seems the easiest. However, it > requires a mandated Authenticator behavior(in this case AC) that is not > mandated by 802.11. Therefore, we have to specify that (e.g. as proposed > by Bob: "We could include a note to the effect that the group KeyRSC > should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11, > because otherwise there is no interoperability. For example, AC provided > by another vendor does not have to set KeyRSC to 0 to be compliant with > CAPWAP and 802.11i. > > Another implication is that we don't really understand the impact of > mandating a static KeyRSC value. Although Bob provided an excellent > analysis, I still have some doubts about the profoundness of the impact. > If the KeyRSC value is as described of no use, why would it appear in > the EAPOL frames in the first place? By mandating it to static value, > what have we lost? Maybe some liaison letter to 802.1 or 802.11 could > provide us a better understanding of the issue. > > For the last two options, I think they are both within CAPWAP's scope. > Further analysis could help us to decide which one is better (or > someone could propose other solutions). > > cheers > > Cheng Hong > > > > > > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Thursday, September 28, 2006 1:39 AM > > To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; > > Peter Nilsson J (LI/EAB) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > Bob's point is 802.11i works this way today. The AP (or in > > this case AC) can set the RSC to whatever value it wishes. > > Bob used zero (0) as an example. Implementations could use > > any other value, which would require some form of > > communication to the WTP, as suggested by Behcet. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > > > Sent: Tuesday, September 26, 2006 6:03 PM > > > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson > > J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > Hi Bob, > > > > > > If I understand your description below correct, you are proposing a > > > solution (to the problem pointed out by > > > Saravanan) by mandating the behavior of the AC to always set the > > > KeyRSC in the 4-way handshake to zero. > > > > > > This is not a defined behavior according to the current > > > 802.11 standard. > > > Are you suggesting that we CAPWAP WG should specifically > > mandate that > > > in our CAPWAP protocol spec, e.g. something like "a CAPWAP > > compatible > > > AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, > > > since not all AC implementation have to follow what you described. > > > > > > Or, are you planning to take this issue to TGm for 802.11 standard > > > revision? (since based on your description, there is essentially no > > > use of the KeyRSC). > > > > > > cheers > > > > > > Cheng Hong > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > > > > Sent: Wednesday, September 27, 2006 2:32 AM > > > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB) > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > Considerations > > > > > > > > Charles, Peter, > > > > > > > > Below is an expansion of a snippet from a thread on this > > > topic that I > > > > sent to the list on July 25, 2006. I think this will be > > helpful to > > > > understand why the exchange that Saranavan is requesting is not > > > > necessary. In fact, there are several systems from several > > > > manufacturers in the field using precursor protocols to > > CAPWAP that > > > > are Wi-Fi certified for WPA2/802.11i operation using the > > > protocol as > > > > it is described below. > > > > > > > > BTW, this whole discussion is about the KeyRSC for the > > > group key, not > > > > the pairwise key. This is so because the WTP and AC both > > know the > > > > initial sequence counter value for the pairwise key, since it has > > > > never been used to send a frame. 802.11i requires the > > first frame > > > > sent on a key to use the sequence counter value of 1. See > > > 8.3.2.6 c) > > > > and > > > > 8.3.3.4.3 c) in 802.11i for this requirement. > > > > > > > > The same is not true of the group key, i.e., after the WTP begins > > > > operation, the AC will not know the value of the sequence > > > counter for > > > > the group key when it needs to complete the EAPOL-key > > > handshake with a > > > > newly associated STA. > > > > However, as you will see from the tutorial below, it is not > > > necessary > > > > for the AC and WTP to exchange any information about the > > group key > > > > KeyRSC for the protocol to operate as it is intended. > > > > > > > > 1. A value for the KeyRSC in the EAPOL-key frame 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. A value of zero in the > > EAPOL-key > > > > frame for the group key will always work. > > > > > > > > 3. The client STA will use the value of KeyRSC received in the > > > > EAPOL-key frame to validate frame using the KeyMIC. > > > > > > > > 4. The client STA will also set its group key RSC to the value > > > > received in KeyRSC, say, zero. > > > > > > > > 5. The value in the client STA's RSC will be compared against the > > > > sequence number in subsequent received frames to identify replay > > > > attacks. Any frame received with a sequence counter value > > > within the > > > > replay window will be checked to have a valid MIC. If the > > > MIC is not > > > > valid, the frame is dropped. > > > > > > > > 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, if the value is greater than its current RSC value. > > > Only the > > > > AP can meet these criteria as the source of a frame > > received by the > > > > STA. > > > > > > > > 7. Please see item 6, immediately above, for the reason > > that the AC > > > > and WTP do not need to coordinate and exchange the RSC. > > > > > > > > > > > > The only possible attack mode is for the attacker to send > > frames to > > > > the client STA between the time of the EAPOL-key frame and > > > the first > > > > frame encrypted with the group key. > > > > During this time, the client will receive the frame and > > proceed to > > > > validate its MIC. This is a potential attack against the STA > > > > resources. But, the MIC validation is done in the STA's > > > > 802.11 chip and consumes no more resources than receiving > > any other > > > > frame. Thus, the attack does not actually consume any STA > > > resources > > > > beyond those of receiving a frame. > > > > > > > > This attack is not unique to the use of the value zero for > > > the KeyRSC, > > > > either. The same attack is available to an attacker at any other > > > > time, as well. It is no more nor less effective at either time. > > > > > > > > For these reasons, the protocol is not in need of any changes to > > > > address the issue raised by Saranavan. > > > > > > > > -Bob > > > > -----Original Message----- > > > > From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > > > > Sent: Monday, September 25, 2006 11:37 AM > > > > To: Peter Nilsson J (LI/EAB) > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > Considerations > > > > > > > > This is a very interesting solution. The AC selects the > > KeyRSC and > > > > performs the 4-way handshake. The WTP sniffs the 4-way handshake > > > > traffic and grabs the KeyRSC value and uses it to > > > initialize its own > > > > counter. > > > > > > > > Pat/Bob: Is this how the Cisco implementation works? I > > > have to agree > > > > with Saravanan that I've yet to see a technical > > description of how > > > > Cisco implements it. > > > > > > > > IMHO, this is somewhat hackish, and it would be cleaner to > > > have the AC > > > > generate the KeyRSC and include it in the AddMobile message > > > as Behcet > > > > suggests. > > > > > > > > -- > > > > t. charles clancy, ph.d. | tcc@umd.edu | > > www.cs.umd.edu/~clancy > > > > > > > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > > > > > > > > > I think Saravanan has a point. We did a prototype > > > impelementation of > > > > the > > > > > protocol a year ago when it was still called LWAPP. The way > > > > we solved > > > > > this issue then was to let the WTP sniff on all CAPWAP data > > > > messages > > > > > from the AC and when message 3 of the 4-way handshake or > > > > message 1 of > > > > > the groupkey handshake was sent the WTP inserted the correct RSC > > > > before > > > > > sending it off to the supplicant. To avoid the sniffing on > > > > all CAPWAP > > > > > data messages we would need a mechanism with in CAPWAP to > > > > handle these > > > > > two messages. > > > > > > > > > > Peter Nilsson > > > > > > > > > > -----Original Message----- > > > > > From: Saravanan Govindan > > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > > Sent: den 22 september 2006 11:03 > > > > > To: Margaret Wasserman > > > > > Cc: capwap@frascone.com > > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > Considerations > > > > > > > > > > Hi Margaret, > > > > > > > > > > Thank you for reviewing the discussion on this issue. > > > > > > > > > > The issue here is the working of IEEE 802.11i when the 802.11i > > > > > authenticator element is at the AC and the 802.11i crypto > > > element is > > > > at > > > > > the WTP. Particularly, it is for the 4-way handshake between > > > > > authenticator and supplicant. > > > > > > > > > > Now, the 4-way handshake requires knowing the value of > > > > KeyRSC sequence > > > > > counter. The KeyRSC helps both authenticator and supplicant > > > > keep track > > > > > of their exchanges. It serves to protect against threats by > > > > tracking > > > > > sequential frames. The KeyRSC is maintained at the at the > > > point of > > > > > encryption, i.e. just before transmission over the > > > wireless channel. > > > > > > > > > > In the case of CAPWAP, the 4-way handshake is between the AC > > > > > (authenticator) and the wireless station (supplicant). > > > > > > > > > > The problem arises, when the authenticator is at the AC and > > > > the crypto > > > > > element (together with KeyRSC) is at the WTP. This is a > > > > fairly common > > > > > design. Now in this case, the AC starts the 4-way > > handshake but it > > > > does > > > > > not know the value of the KeyRSC. The KeyRSC is maintained > > > > by the WTP. > > > > > > > > > > Based on this, the current CAPWAP specification does not > > > allow for a > > > > way > > > > > to conduct the 4-way handshake with the correct KeyRSC. > > > > > > > > > > The functionality I would like to see is a way for the > > > authenticator > > > > > (AC) to use the correct prevailing value of KeyRSC > > > > (maintained by the > > > > > WTP) in its 4-way handshake. > > > > > > > > > > One way to introduce this functionality in to CAPWAP is > > > to have part > > > > of > > > > > the 4-way handshake be sent from AC to WTP. This will allow > > > > the 4-way > > > > > handshake to use the correct value of the KeyRSC before > > > > being sent to > > > > > the wireless station. > > > > > > > > > > I hope this helps clarify my view on the issue. > > > > > > > > > > Cheers, > > > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > > > > > Sent: Thursday, September 21, 2006 8:26 PM > > > > > To: Saravanan Govindan > > > > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > Considerations > > > > > > > > > > > > > > > > > > > > Hi again, > > > > > > > > > > Okay, I am even more confused than I thought I was... > > > > > > > > > > Saravanan, you wrote: > > > > > > > > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > > > > > > > >> Pat, > > > > >> > > > > >> The issue here is about how 802.11i exchanges are done when > > > > >> authenticator is at the AC and crypto elements are at > > > the WTP. This > > > > is > > > > >> the requirement. > > > > > > > > > > And, in response, Pat Calhoun wrote: > > > > > > > > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: > > > > >> The current specification allows the authenticator to > > > > reside in the > > > > >> AC, while the data packet crypto elements in the WTP. This > > > > feature is > > > > >> already in the specification. > > > > > > > > > > Pat's message matches my reading of the specification. > > > > > > > > > > So, Saravanan, what functionality are you asking for > > that is not > > > > > already supported by the specification? And why do you > > > think it is > > > > > necessary? it will not be helpful to my understanding to > > > > re-send your > > > > > proposal or to cite the requirements document... Please > > > summarize > > > > > what functionality you think is missing from the current > > > > specification > > > > > and why you think that functionality is necessary to > > support IEEE > > > > > 802.11i or any important use case. > > > > > > > > > > At some point, the chairs may need to make a consensus > > > call on this > > > > > issue, and I'd like to understand your view and make sure > > > > that it has > > > > > been clearly communicated to the WG before we ask the WG to > > > > decide on > > > > > this issue. > > > > > > > > > > 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 > > > > > > > _________________________________________________________________ > > > > > 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 > > > > > > > _________________________________________________________________ > > > 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 > ------=_Part_70292_24901560.1159474598621 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All,

Below is the text from 802.11REV-maD8.0 Clause 8.5.2, describing the Key RSC field.:

"g) Key RSC. This field is 8 octets in length. It contains the receive sequence counter (RSC) for the
GTK being installed in IEEE 802.11. It is used in Message 3 of the 4-Way Handshake and
Message 1 of the Group Key Handshake, where it is used to synchronize the IEEE 802.11 replay
state. It may also be used in the Michael MIC Failure Report frame, to report the TSC field value of
the frame experiencing a MIC failure. It shall contain 0 in other messages. The Key RSC field gives
the current message number for the GTK, to allow a STA to identify replayed MPDUs. If the Key
RSC field value is less than 8 octets in length, the remaining octets shall be set to 0. The least significant
octet of the TSC or PN should be in the first octet of the Key RSC field."

The intent of adding this value in message 3 was to immediately minimize the number of
replayed frames that a STA would potentially process: "The Key RSC field gives
the current message number for the GTK, to allow a STA to identify replayed MPDUs."
Setting the value to 0 in Msg 3 does not provide the current sequence counter (in most cases
not even close) of the GTK..

Perhaps the WTP could periodically/frequently notify the AC of its current GTK sequence counter, and the
AC would use the most recently received value in the message 3 sent to new STAs. The RSC value
would not be  up to date at all times, but would be closer than "0", not require an "in-the-critical-path
message exchange between the AC and WTP, and still be close to the intended use of the field.

Dorothy

On 9/28/06, Bob O'Hara (boohara) <boohara@cisco.com> wrote:
Please understand that 802.11i specifies no behavior in this area for
the 802.1X authenticator.  Our choice to send a group key KeyRSC value
of zero in the EAPOL-key frame requires no change to 802.11i or to
802.1X .  It requires us to state this in the CAPWAP spec, if we want
this behavior to be consistent across all implementations.

The problem with what Bechet and Saranavan are asking is that either of
three different things are required:
1: the WTP must communicate the group key TSC to the AC every time it is
updated, or
2: the AC must request the current value of the group key TSC for the
KeyRSC before constructing the EAPOL-key frame, or
3: the AC must send the KCK to the AC so  that it can insert the KeyRSC
value and also calculate the correct MIC, inserting that into the proper
EAPOL-key frame.

The first item requires a tremendous amount of additional CAPWAP
communication between WTP and AC, at least one new CAPWAP packet for
every multicast frame sent by the WTP, if the packet is not
acknowledged, or two new CAPWAP packets, if it is acknowledged.  This is
a very expensive addition to the protocol.

The second item requires new protocol between the AC and WTP during what
can be a time critical portion of the 802.11 transition (handoff, roam)
from one WTP to another.  It also introduces a race condition that is
not present in the protocol today.  Once the value for the KeyRSC is
sent from the WTP to the AC, it is possible that the WTP can send
another multicast frame encrypted with the group key.  This puts the
value of the sequence counter out of sync with the value that will be
shortly communicated to the client in the EAPOL-key frame from the AC.
This will behave exactly the same as if a value of zero is sent in the
EAPOL-key frame.

The third item requires a new architecture split that is not required in
our objectives.  The new split is not splitting the MAC, but splitting
the authenticator.  Placing the KCK in the WTP is also a potential
reduction in the security of the overall WLAN system, since these
devices are normally not in a secured wiring closet, but exposed and
more easily compromised than the AC.

The simplest to implement, least expensive, and most secure option is to
use the protocol as it is now specified and have the AC send a value of
zero in the KeyRSC field of the EAPOL-key frame.

-Bob

-----Original Message-----
From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com]
Sent: Wednesday, September 27, 2006 6:50 PM
To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy;
Peter Nilsson J (LI/EAB)
Cc: capwap@frascone.com
Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Hi Pat and all,

So, based on this, I would say that we have consensus that setting the
correct KeyRSC is an issue for the CAPWAP protocol design.

So far, we have three option/solutions:

1) As proposed by Bob: Using a static value (0) for the KeyRSC.

2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP

3) As suggested by Saravanana: Some exchange mechanism between WTP and
AC

Among the three, the first option seems the easiest. However, it
requires a mandated Authenticator behavior(in this case AC) that is not
mandated by 802.11. Therefore, we have to specify that (e.g. as proposed
by Bob: "We could include a note to the effect that the group KeyRSC
should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11,
because otherwise there is no interoperability. For example, AC provided
by another vendor does not have to set KeyRSC to 0 to be compliant with
CAPWAP and 802.11i.

Another implication is that we don't really understand the impact of
mandating a static KeyRSC value. Although Bob provided an excellent
analysis, I still have some doubts about the profoundness of the impact.
If the KeyRSC value is as described of no use, why would it appear in
the EAPOL frames in the first place? By mandating it to static value,
what have we lost? Maybe some liaison letter to 802.1 or 802.11 could
provide us a better understanding of the issue.

For the last two options, I think they are both within CAPWAP's scope.
Further analysis could help us to decide which one  is better (or
someone could propose other solutions).

cheers

Cheng Hong







> -----Original Message-----
> From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com]
> Sent: Thursday, September 28, 2006 1:39 AM
> To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy;
> Peter Nilsson J (LI/EAB)
> Cc: capwap@frascone.com
> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> Considerations
>
> Bob's point is 802.11i works this way today. The AP (or in
> this case AC) can set the RSC to whatever value it wishes.
> Bob used zero (0) as an example. Implementations could use
> any other value, which would require some form of
> communication to the WTP, as suggested by Behcet.
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
>
> > -----Original Message-----
> > From: Cheng Hong [mailto: Hong.Cheng@sg.panasonic.com]
> > Sent: Tuesday, September 26, 2006 6:03 PM
> > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson
> J (LI/EAB)
> > Cc: capwap@frascone.com
> > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > Considerations
> >
> > Hi Bob,
> >
> > If I understand your description below correct, you are proposing a
> > solution (to the problem pointed out by
> > Saravanan) by mandating the behavior of the AC to always set the
> > KeyRSC in the 4-way handshake to zero.
> >
> > This is not a defined behavior according to the current
> > 802.11 standard.
> > Are you suggesting that we CAPWAP WG should specifically
> mandate that
> > in our CAPWAP protocol spec, e.g. something like "a CAPWAP
> compatible
> > AC MUST set KeyRSC to zero"? Otherwise, the problem still exists,
> > since not all AC implementation have to follow what you described.
> >
> > Or, are you planning to take this issue to TGm for 802.11 standard
> > revision? (since based on your description, there is essentially no
> > use of the KeyRSC).
> >
> > cheers
> >
> > Cheng Hong
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]
> > > Sent: Wednesday, September 27, 2006 2:32 AM
> > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB)
> > > Cc: capwap@frascone.com
> > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > > Considerations
> > >
> > > Charles, Peter,
> > >
> > > Below is an expansion of a snippet from a thread on this
> > topic that I
> > > sent to the list on July 25, 2006.  I think this will be
> helpful to
> > > understand why the exchange that Saranavan is requesting is not
> > > necessary.  In fact, there are several systems from several
> > > manufacturers in the field using precursor protocols to
> CAPWAP that
> > > are Wi-Fi certified for WPA2/802.11i operation using the
> > protocol as
> > > it is described below.
> > >
> > > BTW, this whole discussion is about the KeyRSC for the
> > group key, not
> > > the pairwise key.  This is so because the WTP and AC both
> know the
> > > initial sequence counter value for the pairwise key, since it has
> > > never been used to send a frame.   802.11i requires the
> first frame
> > > sent on a key to use the sequence counter value of 1.  See
> > 8.3.2.6 c)
> > > and
> > > 8.3.3.4.3 c) in 802.11i for this requirement.
> > >
> > > The same is not true of the group key, i.e., after the WTP begins
> > > operation, the AC will not know the value of the sequence
> > counter for
> > > the group key when it needs to complete the EAPOL-key
> > handshake with a
> > > newly associated STA.
> > > However, as you will see from the tutorial below, it is not
> > necessary
> > > for the AC and WTP to exchange any information about the
> group key
> > > KeyRSC for the protocol to operate as it is intended.
> > >
> > > 1. A value for the KeyRSC in the EAPOL-key frame 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.  A value of zero in the
> EAPOL-key
> > > frame for the group key will always work.
> > >
> > > 3. The client STA will use the value of KeyRSC received in the
> > > EAPOL-key frame to validate frame using the KeyMIC.
> > >
> > > 4. The client STA will also set its group key RSC to the value
> > > received in KeyRSC, say, zero.
> > >
> > > 5. The value in the client STA's RSC will be compared against the
> > > sequence number in subsequent received frames to identify replay
> > > attacks.  Any frame received with a sequence counter value
> > within the
> > > replay window will be checked to have a valid MIC.  If the
> > MIC is not
> > > valid, the frame is dropped.
> > >
> > > 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, if the value is greater than its current RSC value.
> > Only the
> > > AP can meet these criteria as the source of a frame
> received by the
> > > STA.
> > >
> > > 7. Please see item 6, immediately above, for the reason
> that the AC
> > > and WTP do not need to coordinate and exchange the RSC.
> > >
> > >
> > > The only possible attack mode is for the attacker to send
> frames to
> > > the client STA between the time of the EAPOL-key frame and
> > the first
> > > frame encrypted with the group key.
> > > During this time, the client will receive the frame and
> proceed to
> > > validate its MIC.  This is a potential attack against the STA
> > > resources.  But, the MIC validation is done in the STA's
> > > 802.11 chip and consumes no more resources than receiving
> any other
> > > frame.  Thus, the attack does not actually consume any STA
> > resources
> > > beyond those of receiving a frame.
> > >
> > > This attack is not unique to the use of the value zero for
> > the KeyRSC,
> > > either.  The same attack is available to an attacker at any other
> > > time, as well.  It is no more nor less effective at either time.
> > >
> > > For these reasons, the protocol is not in need of any changes to
> > > address the issue raised by Saranavan.
> > >
> > >  -Bob
> > > -----Original Message-----
> > > From: T. Charles Clancy [mailto:clancy@cs.umd.edu]
> > > Sent: Monday, September 25, 2006 11:37 AM
> > > To: Peter Nilsson J (LI/EAB)
> > > Cc: capwap@frascone.com
> > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > > Considerations
> > >
> > > This is a very interesting solution.  The AC selects the
> KeyRSC and
> > > performs the 4-way handshake.  The WTP sniffs the 4-way handshake
> > > traffic and grabs the KeyRSC value and uses it to
> > initialize its own
> > > counter.
> > >
> > > Pat/Bob: Is this how the Cisco implementation works?  I
> > have to agree
> > > with Saravanan that I've yet to see a technical
> description of how
> > > Cisco implements it.
> > >
> > > IMHO, this is somewhat hackish, and it would be cleaner to
> > have the AC
> > > generate the KeyRSC and include it in the AddMobile message
> > as Behcet
> > > suggests.
> > >
> > > --
> > > t. charles clancy, ph.d.  |  tcc@umd.edu  |
> www.cs.umd.edu/~clancy
> > >
> > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote:
> > >
> > > > I think Saravanan has a point. We did a prototype
> > impelementation of
> > > the
> > > > protocol a year ago when it was still called LWAPP. The way
> > > we solved
> > > > this issue then was to let the WTP sniff on all CAPWAP data
> > > messages
> > > > from the AC and when message 3 of the 4-way handshake or
> > > message 1 of
> > > > the groupkey handshake was sent the WTP inserted the correct RSC
> > > before
> > > > sending it off to the supplicant. To avoid the sniffing on
> > > all CAPWAP
> > > > data messages we would need a mechanism with in CAPWAP to
> > > handle these
> > > > two messages.
> > > >
> > > > Peter Nilsson
> > > >
> > > > -----Original Message-----
> > > > From: Saravanan Govindan
> > > [mailto:Saravanan.Govindan@sg.panasonic.com]
> > > > Sent: den 22 september 2006 11:03
> > > > To: Margaret Wasserman
> > > > Cc: capwap@frascone.com
> > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > > Considerations
> > > >
> > > > Hi Margaret,
> > > >
> > > > Thank you for reviewing the discussion on this issue.
> > > >
> > > > The issue here is the working of IEEE 802.11i when the 802.11i
> > > > authenticator element is at the AC and the 802.11i crypto
> > element is
> > > at
> > > > the WTP. Particularly, it is for the 4-way handshake between
> > > > authenticator and supplicant.
> > > >
> > > > Now, the 4-way handshake requires knowing the value of
> > > KeyRSC sequence
> > > > counter. The KeyRSC helps both authenticator and supplicant
> > > keep track
> > > > of their exchanges. It serves to protect against threats by
> > > tracking
> > > > sequential frames. The KeyRSC is maintained at the at the
> > point of
> > > > encryption, i.e. just before transmission over the
> > wireless channel.
> > > >
> > > > In the case of CAPWAP, the 4-way handshake is between the AC
> > > > (authenticator) and the wireless station (supplicant).
> > > >
> > > > The problem arises, when the authenticator is at the AC and
> > > the crypto
> > > > element (together with KeyRSC) is at the WTP. This is a
> > > fairly common
> > > > design. Now in this case, the AC starts the 4-way
> handshake but it
> > > does
> > > > not know the value of the KeyRSC. The KeyRSC is maintained
> > > by the WTP.
> > > >
> > > > Based on this, the current CAPWAP specification does not
> > allow for a
> > > way
> > > > to conduct the 4-way handshake with the correct KeyRSC.
> > > >
> > > > The functionality I would like to see is a way for the
> > authenticator
> > > > (AC) to use the correct prevailing value of KeyRSC
> > > (maintained by the
> > > > WTP) in its 4-way handshake.
> > > >
> > > > One way to introduce this functionality in to CAPWAP is
> > to have part
> > > of
> > > > the 4-way handshake be sent from AC to WTP. This will allow
> > > the 4-way
> > > > handshake to use the correct value of the KeyRSC before
> > > being sent to
> > > > the wireless station.
> > > >
> > > > I hope this helps clarify my view on the issue.
> > > >
> > > > Cheers,
> > > >
> > > > Saravanan
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Margaret Wasserman [mailto:margaret@thingmagic.com]
> > > > Sent: Thursday, September 21, 2006 8:26 PM
> > > > To: Saravanan Govindan
> > > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com
> > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > > Considerations
> > > >
> > > >
> > > >
> > > > Hi again,
> > > >
> > > > Okay, I am even more confused than I thought I was...
> > > >
> > > > Saravanan, you wrote:
> > > >
> > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote:
> > > >
> > > >> Pat,
> > > >>
> > > >> The issue here is about how 802.11i exchanges are done when
> > > >> authenticator is at the AC and crypto elements are at
> > the WTP. This
> > > is
> > > >> the requirement.
> > > >
> > > > And, in response, Pat Calhoun wrote:
> > > >
> > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote:
> > > >> The current specification allows the authenticator to
> > > reside in the
> > > >> AC, while the data packet crypto elements in the WTP. This
> > > feature is
> > > >> already in the specification.
> > > >
> > > > Pat's message matches my reading of the specification.
> > > >
> > > > So, Saravanan, what functionality are you asking for
> that is not
> > > > already supported by the specification?  And why do you
> > think it is
> > > > necessary?  it will not be helpful to my understanding to
> > > re-send your
> > > > proposal or to cite the requirements document...  Please
> > summarize
> > > > what functionality you think is missing from the current
> > > specification
> > > > and why you think that functionality is necessary to
> support IEEE
> > > > 802.11i or any important use case.
> > > >
> > > > At some point, the chairs may need to make a consensus
> > call on this
> > > > issue, and I'd like to understand your view and make sure
> > > that it has
> > > > been clearly communicated to the WG before we ask the WG to
> > > decide on
> > > > this issue.
> > > >
> > > > 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
> > > >
> _________________________________________________________________
> > > > 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
> > >
> > _________________________________________________________________
> > 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

------=_Part_70292_24901560.1159474598621-- --===============0413512929== 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 --===============0413512929==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Sep 28 17:28:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT3Qf-0004DC-EQ for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 17:28:25 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT3Qc-0004Vl-6k for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 17:28:25 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 954B439808D for ; Thu, 28 Sep 2006 14:28:18 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 32DFA43005F for ; Thu, 28 Sep 2006 14:21:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 062AC398067 for ; Thu, 28 Sep 2006 14:21:18 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 03A59398015 for ; Thu, 28 Sep 2006 14:21:12 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 28 Sep 2006 14:21:12 -0700 X-IronPort-AV: i="4.09,231,1157353200"; d="scan'208,217"; a="326397130:sNHT231523820" 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.20060308/8.12.11) with ESMTP id k8SLLCiW026213; Thu, 28 Sep 2006 14:21:12 -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 k8SLLAYx011300; Thu, 28 Sep 2006 14:21:12 -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); Thu, 28 Sep 2006 14:21:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Sep 2006 14:21:09 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC02188BC3@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbjOwaBxAxmTegASwKjGKmQD0OreAAB7o8Q From: "Bob O'Hara (boohara)" To: "Dorothy Stanley" X-OriginalArrivalTime: 28 Sep 2006 21:21:10.0568 (UTC) FILETIME=[04DF9280:01C6E344] Authentication-Results: sj-dkim-2.cisco.com; header.From=boohara@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.509 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE, NORMAL_HTTP_TO_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com, Cheng Hong Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1268748470==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b4580c331621db7f218107db9d61a1f9 This is a multi-part message in MIME format. --===============1268748470== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E344.049CEE77" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E344.049CEE77 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dorothy, =20 The problem with this proposal is that it is no more effective than sending a value of zero for the KeyRSC. It doesn't eliminate any potential attacks. It doesn't add any functionality. However, it does add cost and complexity to the protocol. =20 -Bob =20 =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Thursday, September 28, 2006 1:17 PM To: Bob O'Hara (boohara) Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations All, Below is the text from 802.11REV-maD8.0 Clause 8.5.2, describing the Key RSC field.: "g) Key RSC. This field is 8 octets in length. It contains the receive sequence counter (RSC) for the GTK being installed in IEEE 802.11. It is used in Message 3 of the 4-Way Handshake and Message 1 of the Group Key Handshake, where it is used to synchronize the IEEE 802.11 replay state. It may also be used in the Michael MIC Failure Report frame, to report the TSC field value of the frame experiencing a MIC failure. It shall contain 0 in other messages. The Key RSC field gives the current message number for the GTK, to allow a STA to identify replayed MPDUs. If the Key RSC field value is less than 8 octets in length, the remaining octets shall be set to 0. The least significant octet of the TSC or PN should be in the first octet of the Key RSC field." The intent of adding this value in message 3 was to immediately minimize the number of=20 replayed frames that a STA would potentially process: "The Key RSC field gives the current message number for the GTK, to allow a STA to identify replayed MPDUs." Setting the value to 0 in Msg 3 does not provide the current sequence counter (in most cases not even close) of the GTK.. Perhaps the WTP could periodically/frequently notify the AC of its current GTK sequence counter, and the AC would use the most recently received value in the message 3 sent to new STAs. The RSC value would not be up to date at all times, but would be closer than "0", not require an "in-the-critical-path message exchange between the AC and WTP, and still be close to the intended use of the field. Dorothy On 9/28/06, Bob O'Hara (boohara) wrote:=20 Please understand that 802.11i specifies no behavior in this area for the 802.1X authenticator. Our choice to send a group key KeyRSC value of zero in the EAPOL-key frame requires no change to 802.11i or to 802.1X . It requires us to state this in the CAPWAP spec, if we want this behavior to be consistent across all implementations. =09 The problem with what Bechet and Saranavan are asking is that either of three different things are required:=20 1: the WTP must communicate the group key TSC to the AC every time it is updated, or 2: the AC must request the current value of the group key TSC for the KeyRSC before constructing the EAPOL-key frame, or 3: the AC must send the KCK to the AC so that it can insert the KeyRSC value and also calculate the correct MIC, inserting that into the proper EAPOL-key frame. =09 The first item requires a tremendous amount of additional CAPWAP communication between WTP and AC, at least one new CAPWAP packet for every multicast frame sent by the WTP, if the packet is not acknowledged, or two new CAPWAP packets, if it is acknowledged. This is a very expensive addition to the protocol.=20 =09 The second item requires new protocol between the AC and WTP during what can be a time critical portion of the 802.11 transition (handoff, roam) from one WTP to another. It also introduces a race condition that is=20 not present in the protocol today. Once the value for the KeyRSC is sent from the WTP to the AC, it is possible that the WTP can send another multicast frame encrypted with the group key. This puts the value of the sequence counter out of sync with the value that will be=20 shortly communicated to the client in the EAPOL-key frame from the AC. This will behave exactly the same as if a value of zero is sent in the EAPOL-key frame. =09 The third item requires a new architecture split that is not required in=20 our objectives. The new split is not splitting the MAC, but splitting the authenticator. Placing the KCK in the WTP is also a potential reduction in the security of the overall WLAN system, since these devices are normally not in a secured wiring closet, but exposed and=20 more easily compromised than the AC. =09 The simplest to implement, least expensive, and most secure option is to use the protocol as it is now specified and have the AC send a value of zero in the KeyRSC field of the EAPOL-key frame.=20 =09 -Bob =09 -----Original Message----- From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] Sent: Wednesday, September 27, 2006 6:50 PM To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy;=20 Peter Nilsson J (LI/EAB) Cc: capwap@frascone.com Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations =09 Hi Pat and all, =09 So, based on this, I would say that we have consensus that setting the=20 correct KeyRSC is an issue for the CAPWAP protocol design. =09 So far, we have three option/solutions: =09 1) As proposed by Bob: Using a static value (0) for the KeyRSC. =09 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP=20 =09 3) As suggested by Saravanana: Some exchange mechanism between WTP and AC =09 Among the three, the first option seems the easiest. However, it requires a mandated Authenticator behavior(in this case AC) that is not=20 mandated by 802.11. Therefore, we have to specify that (e.g. as proposed by Bob: "We could include a note to the effect that the group KeyRSC should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11, because otherwise there is no interoperability. For example, AC provided by another vendor does not have to set KeyRSC to 0 to be compliant with CAPWAP and 802.11i. =09 Another implication is that we don't really understand the impact of=20 mandating a static KeyRSC value. Although Bob provided an excellent analysis, I still have some doubts about the profoundness of the impact. If the KeyRSC value is as described of no use, why would it appear in the EAPOL frames in the first place? By mandating it to static value, what have we lost? Maybe some liaison letter to 802.1 or 802.11 could provide us a better understanding of the issue. =09 For the last two options, I think they are both within CAPWAP's scope.=20 Further analysis could help us to decide which one is better (or someone could propose other solutions). =09 cheers =09 Cheng Hong =09 =09 =09 =09 =09 =09 =09 > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com] > Sent: Thursday, September 28, 2006 1:39 AM > To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; > Peter Nilsson J (LI/EAB) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Bob's point is 802.11i works this way today. The AP (or in=20 > this case AC) can set the RSC to whatever value it wishes. > Bob used zero (0) as an example. Implementations could use > any other value, which would require some form of > communication to the WTP, as suggested by Behcet.=20 > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Cheng Hong [mailto: Hong.Cheng@sg.panasonic.com ] > > Sent: Tuesday, September 26, 2006 6:03 PM > > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson > J (LI/EAB) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > Hi Bob, > > > > If I understand your description below correct, you are proposing a=20 > > solution (to the problem pointed out by > > Saravanan) by mandating the behavior of the AC to always set the > > KeyRSC in the 4-way handshake to zero. > > > > This is not a defined behavior according to the current=20 > > 802.11 standard. > > Are you suggesting that we CAPWAP WG should specifically > mandate that > > in our CAPWAP protocol spec, e.g. something like "a CAPWAP > compatible > > AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, > > since not all AC implementation have to follow what you described. > > > > Or, are you planning to take this issue to TGm for 802.11 standard > > revision? (since based on your description, there is essentially no > > use of the KeyRSC). > > > > cheers > > > > Cheng Hong > > > >=20 > > > > > > > -----Original Message----- > > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > > > Sent: Wednesday, September 27, 2006 2:32 AM=20 > > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i=20 > > > Considerations > > > > > > Charles, Peter, > > > > > > Below is an expansion of a snippet from a thread on this > > topic that I > > > sent to the list on July 25, 2006. I think this will be=20 > helpful to > > > understand why the exchange that Saranavan is requesting is not > > > necessary. In fact, there are several systems from several > > > manufacturers in the field using precursor protocols to=20 > CAPWAP that > > > are Wi-Fi certified for WPA2/802.11i operation using the > > protocol as > > > it is described below. > > > > > > BTW, this whole discussion is about the KeyRSC for the=20 > > group key, not > > > the pairwise key. This is so because the WTP and AC both > know the > > > initial sequence counter value for the pairwise key, since it has > > > never been used to send a frame. 802.11i requires the > first frame > > > sent on a key to use the sequence counter value of 1. See > > 8.3.2.6 c) > > > and > > > 8.3.3.4.3 c) in 802.11i for this requirement. > > > > > > The same is not true of the group key, i.e., after the WTP begins > > > operation, the AC will not know the value of the sequence > > counter for=20 > > > the group key when it needs to complete the EAPOL-key > > handshake with a > > > newly associated STA. > > > However, as you will see from the tutorial below, it is not > > necessary > > > for the AC and WTP to exchange any information about the > group key > > > KeyRSC for the protocol to operate as it is intended. > > > > > > 1. A value for the KeyRSC in the EAPOL-key frame is necessary to=20 > > > calculate the KeyMIC. > > > > > > 2. This value does not need to bear any specific > > relationship to the > > > RSC value maintained by the WTP. A value of zero in the=20 > EAPOL-key > > > frame for the group key will always work. > > > > > > 3. The client STA will use the value of KeyRSC received in the > > > EAPOL-key frame to validate frame using the KeyMIC.=20 > > > > > > 4. The client STA will also set its group key RSC to the value > > > received in KeyRSC, say, zero. > > > > > > 5. The value in the client STA's RSC will be compared against the=20 > > > sequence number in subsequent received frames to identify replay > > > attacks. Any frame received with a sequence counter value > > within the > > > replay window will be checked to have a valid MIC. If the > > MIC is not > > > valid, the frame is dropped. > > > > > > 6. For any frame that is determined not to be a replay > attack frame > > > and meets all other validity and authenticity requirements,=20 > > the client > > > STA updates its RSC value to the sequence number in the received > > > frame, if the value is greater than its current RSC value. > > Only the > > > AP can meet these criteria as the source of a frame=20 > received by the > > > STA. > > > > > > 7. Please see item 6, immediately above, for the reason > that the AC > > > and WTP do not need to coordinate and exchange the RSC.=20 > > > > > > > > > The only possible attack mode is for the attacker to send > frames to > > > the client STA between the time of the EAPOL-key frame and > > the first=20 > > > frame encrypted with the group key. > > > During this time, the client will receive the frame and > proceed to > > > validate its MIC. This is a potential attack against the STA=20 > > > resources. But, the MIC validation is done in the STA's > > > 802.11 chip and consumes no more resources than receiving > any other > > > frame. Thus, the attack does not actually consume any STA > > resources > > > beyond those of receiving a frame. > > > > > > This attack is not unique to the use of the value zero for > > the KeyRSC, > > > either. The same attack is available to an attacker at any other=20 > > > time, as well. It is no more nor less effective at either time. > > > > > > For these reasons, the protocol is not in need of any changes to > > > address the issue raised by Saranavan.=20 > > > > > > -Bob > > > -----Original Message----- > > > From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > > > Sent: Monday, September 25, 2006 11:37 AM=20 > > > To: Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations=20 > > > > > > This is a very interesting solution. The AC selects the > KeyRSC and > > > performs the 4-way handshake. The WTP sniffs the 4-way handshake > > > traffic and grabs the KeyRSC value and uses it to=20 > > initialize its own > > > counter. > > > > > > Pat/Bob: Is this how the Cisco implementation works? I > > have to agree > > > with Saravanan that I've yet to see a technical=20 > description of how > > > Cisco implements it. > > > > > > IMHO, this is somewhat hackish, and it would be cleaner to > > have the AC > > > generate the KeyRSC and include it in the AddMobile message=20 > > as Behcet > > > suggests. > > > > > > -- > > > t. charles clancy, ph.d. | tcc@umd.edu | > www.cs.umd.edu/~clancy > > > > > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > > > > > > > I think Saravanan has a point. We did a prototype > > impelementation of=20 > > > the > > > > protocol a year ago when it was still called LWAPP. The way > > > we solved > > > > this issue then was to let the WTP sniff on all CAPWAP data > > > messages=20 > > > > from the AC and when message 3 of the 4-way handshake or > > > message 1 of > > > > the groupkey handshake was sent the WTP inserted the correct RSC > > > before=20 > > > > sending it off to the supplicant. To avoid the sniffing on > > > all CAPWAP > > > > data messages we would need a mechanism with in CAPWAP to > > > handle these=20 > > > > two messages. > > > > > > > > Peter Nilsson > > > > > > > > -----Original Message----- > > > > From: Saravanan Govindan > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > Sent: den 22 september 2006 11:03 > > > > To: Margaret Wasserman > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > Hi Margaret, > > > > > > > > Thank you for reviewing the discussion on this issue. > > > > > > > > The issue here is the working of IEEE 802.11i when the 802.11i > > > > authenticator element is at the AC and the 802.11i crypto > > element is > > > at > > > > the WTP. Particularly, it is for the 4-way handshake between=20 > > > > authenticator and supplicant. > > > > > > > > Now, the 4-way handshake requires knowing the value of > > > KeyRSC sequence > > > > counter. The KeyRSC helps both authenticator and supplicant=20 > > > keep track > > > > of their exchanges. It serves to protect against threats by > > > tracking > > > > sequential frames. The KeyRSC is maintained at the at the > > point of > > > > encryption, i.e. just before transmission over the > > wireless channel. > > > > > > > > In the case of CAPWAP, the 4-way handshake is between the AC=20 > > > > (authenticator) and the wireless station (supplicant). > > > > > > > > The problem arises, when the authenticator is at the AC and > > > the crypto > > > > element (together with KeyRSC) is at the WTP. This is a=20 > > > fairly common > > > > design. Now in this case, the AC starts the 4-way > handshake but it > > > does > > > > not know the value of the KeyRSC. The KeyRSC is maintained=20 > > > by the WTP. > > > > > > > > Based on this, the current CAPWAP specification does not > > allow for a > > > way > > > > to conduct the 4-way handshake with the correct KeyRSC.=20 > > > > > > > > The functionality I would like to see is a way for the > > authenticator > > > > (AC) to use the correct prevailing value of KeyRSC > > > (maintained by the=20 > > > > WTP) in its 4-way handshake. > > > > > > > > One way to introduce this functionality in to CAPWAP is > > to have part > > > of > > > > the 4-way handshake be sent from AC to WTP. This will allow=20 > > > the 4-way > > > > handshake to use the correct value of the KeyRSC before > > > being sent to > > > > the wireless station. > > > > > > > > I hope this helps clarify my view on the issue.=20 > > > > > > > > Cheers, > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > > > > Sent: Thursday, September 21, 2006 8:26 PM=20 > > > > To: Saravanan Govindan > > > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > > > > > > > > > Hi again, > > > > > > > > Okay, I am even more confused than I thought I was...=20 > > > > > > > > Saravanan, you wrote: > > > > > > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > > > > > >> Pat,=20 > > > >> > > > >> The issue here is about how 802.11i exchanges are done when > > > >> authenticator is at the AC and crypto elements are at > > the WTP. This=20 > > > is > > > >> the requirement. > > > > > > > > And, in response, Pat Calhoun wrote: > > > > > > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote:=20 > > > >> The current specification allows the authenticator to > > > reside in the > > > >> AC, while the data packet crypto elements in the WTP. This > > > feature is=20 > > > >> already in the specification. > > > > > > > > Pat's message matches my reading of the specification. > > > > > > > > So, Saravanan, what functionality are you asking for=20 > that is not > > > > already supported by the specification? And why do you > > think it is > > > > necessary? it will not be helpful to my understanding to > > > re-send your=20 > > > > proposal or to cite the requirements document... Please > > summarize > > > > what functionality you think is missing from the current > > > specification > > > > and why you think that functionality is necessary to=20 > support IEEE > > > > 802.11i or any important use case. > > > > > > > > At some point, the chairs may need to make a consensus > > call on this > > > > issue, and I'd like to understand your view and make sure=20 > > > that it has > > > > been clearly communicated to the WG before we ask the WG to > > > decide on > > > > this issue. > > > > > > > > Thanks,=20 > > > > Margaret > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________=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 > > > > 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 > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > >=20 > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit:=20 > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit:=20 > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap=20 > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > =09 _________________________________________________________________=20 To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap =09 ------_=_NextPart_001_01C6E344.049CEE77 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dorothy,
 
The problem with this proposal is that it is no = more=20 effective than sending a value of zero for the KeyRSC.  It = doesn't=20 eliminate any potential attacks.  It doesn't add any=20 functionality.  However, it does add cost and complexity = to the=20 protocol. 

 -Bob
 

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Thursday, September 28, = 2006=20 1:17 PM
To: Bob O'Hara (boohara)
Cc: Cheng Hong; Pat = Calhoun=20 (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB);=20 capwap@frascone.com
Subject: Re: [Capwap] Issue 43 - = Explanation for=20 802.11i Considerations

All,

Below is the text from 802.11REV-maD8.0 Clause = 8.5.2,=20 describing the Key RSC field.:

"g) Key=20 RSC. This field is 8 octets in length. It contains the receive sequence = counter=20 (RSC) for the
GTK being installed in IEEE 802.11. It is = used in=20 Message 3 of the 4-Way Handshake and
Message 1 of the Group Key Handshake, where = it is=20 used to synchronize the IEEE 802.11 replaystate. = It may also=20 be used in the Michael MIC Failure Report frame, to report the TSC field = value=20 of
the=20 frame experiencing a MIC failure. It shall contain 0 in other messages. = The Key=20 RSC field gives
the current message number for the GTK, to = allow a=20 STA to identify replayed MPDUs. If the KeyRSC = field value is=20 less than 8 octets in length, the remaining octets shall be set to 0. = The least=20 significant
octet of the TSC or PN should be in the = first octet=20 of the Key RSC field."

The intent of adding this value in = message=20 3 was to immediately minimize the number of
replayed frames that a = STA would=20 potentially process: "The Key RSC field gives
the current message = number for=20 the GTK, to allow a STA to identify replayed MPDUs."
Setting the = value to 0=20 in Msg 3 does not provide the current sequence counter (in most = cases
not=20 even close) of the GTK..

Perhaps the WTP could = periodically/frequently=20 notify the AC of its current GTK sequence counter, and the
AC would = use the=20 most recently received value in the message 3 sent to new STAs. The RSC=20 value
would not be  up to date at all times, but would be closer = than=20 "0", not require an "in-the-critical-path
message exchange between = the AC and=20 WTP, and still be close to the intended use of the = field.

Dorothy

On 9/28/06, Bob O'Hara=20 (boohara) <boohara@cisco.com>=20 wrote:
Please=20 understand that 802.11i specifies no behavior in this area for
the = 802.1X=20 authenticator.  Our choice to send a group key KeyRSC = value
of=20 zero in the EAPOL-key frame requires no change to 802.11i or = to
802.1X=20 .  It requires us to state this in the CAPWAP spec, if we=20 want
this behavior to be consistent across all = implementations.

The=20 problem with what Bechet and Saranavan are asking is that either = of
three=20 different things are required:
1: the WTP must communicate the = group key=20 TSC to the AC every time it is
updated, or
2: the AC must = request the=20 current value of the group key TSC for the
KeyRSC before = constructing the=20 EAPOL-key frame, or
3: the AC must send the KCK to the AC=20 so  that it can insert the KeyRSC
value and also = calculate the=20 correct MIC, inserting that into the proper
EAPOL-key = frame.

The=20 first item requires a tremendous amount of additional CAPWAP =
communication=20 between WTP and AC, at least one new CAPWAP packet for
every = multicast=20 frame sent by the WTP, if the packet is not
acknowledged, or two = new CAPWAP=20 packets, if it is acknowledged.  This is
a very expensive = addition to the protocol.

The second item requires new = protocol=20 between the AC and WTP during what
can be a time critical portion = of the=20 802.11 transition (handoff, roam)
from one WTP to = another.  It=20 also introduces a race condition that is
not present in the = protocol=20 today.  Once the value for the KeyRSC is
sent from the = WTP to the=20 AC, it is possible that the WTP can send
another multicast frame = encrypted=20 with the group key.  This puts the
value of the sequence = counter=20 out of sync with the value that will be
shortly communicated to = the client=20 in the EAPOL-key frame from the AC.
This will behave exactly the = same as if=20 a value of zero is sent in the
EAPOL-key frame.

The third = item=20 requires a new architecture split that is not required in
our=20 objectives.  The new split is not splitting the MAC, but=20 splitting
the authenticator.  Placing the KCK in the WTP = is also=20 a potential
reduction in the security of the overall WLAN system, = since=20 these
devices are normally not in a secured wiring closet, but = exposed and=20
more easily compromised than the AC.

The simplest to = implement,=20 least expensive, and most secure option is to
use the protocol as = it is now=20 specified and have the AC send a value of
zero in the KeyRSC field = of the=20 EAPOL-key frame.

-Bob

-----Original = Message-----
From: Cheng=20 Hong [mailto:Hong.Cheng@sg.panasonic.com]
Sent:=20 Wednesday, September 27, 2006 6:50 PM
To: Pat Calhoun (pacalhou); = Bob=20 O'Hara (boohara); T. Charles Clancy;
Peter Nilsson J = (LI/EAB)
Cc: capwap@frascone.com
Subject: = RE:=20 [Capwap] Issue 43 - Explanation for 802.11i Considerations

Hi = Pat and=20 all,

So, based on this, I would say that we have consensus that = setting=20 the
correct KeyRSC is an issue for the CAPWAP protocol = design.

So=20 far, we have three option/solutions:

1) As proposed by Bob: = Using a=20 static value (0) for the KeyRSC.

2) As suggested by Behcet: AC=20 communicate a correct KeyRSC to WTP

3) As suggested by = Saravanana:=20 Some exchange mechanism between WTP and
AC

Among the three, = the=20 first option seems the easiest. However, it
requires a mandated=20 Authenticator behavior(in this case AC) that is not
mandated by = 802.11.=20 Therefore, we have to specify that (e.g. as proposed
by Bob: "We = could=20 include a note to the effect that the group KeyRSC
should be zero = in the=20 EAPOL-key frame.") either in CAPWAP or 802.11,
because otherwise = there is=20 no interoperability. For example, AC provided
by another vendor = does not=20 have to set KeyRSC to 0 to be compliant with
CAPWAP and=20 802.11i.

Another implication is that we don't really understand = the=20 impact of
mandating a static KeyRSC value. Although Bob provided = an=20 excellent
analysis, I still have some doubts about the profoundness = of the=20 impact.
If the KeyRSC value is as described of no use, why would it = appear=20 in
the EAPOL frames in the first place? By mandating it to static=20 value,
what have we lost? Maybe some liaison letter to 802.1 or = 802.11=20 could
provide us a better understanding of the issue.

For = the last=20 two options, I think they are both within CAPWAP's scope.
Further = analysis=20 could help us to decide which one  is better (or
someone = could=20 propose other solutions).

cheers

Cheng=20 Hong







> -----Original = Message-----
>=20 From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com]
> = Sent:=20 Thursday, September 28, 2006 1:39 AM
> To: Cheng Hong; Bob = O'Hara=20 (boohara); T. Charles Clancy;
> Peter Nilsson J (LI/EAB)
> = Cc: capwap@frascone.com
> = Subject: Re:=20 [Capwap] Issue 43 - Explanation for 802.11i
>=20 Considerations
>
> Bob's point is 802.11i works this way = today.=20 The AP (or in
> this case AC) can set the RSC to whatever value = it=20 wishes.
> Bob used zero (0) as an example. Implementations could = use
> any other value, which would require some form of
>=20 communication to the WTP, as suggested by Behcet.
>
> Pat = Calhoun
> CTO, Wireless Networking Business Unit
> Cisco=20 Systems
>
>
>
> > -----Original=20 Message-----
> > From: Cheng Hong [mailto:=20 Hong.Cheng@sg.panasonic.com]
> > Sent: Tuesday, September = 26,=20 2006 6:03 PM
> > To: Bob O'Hara (boohara); T. Charles Clancy; = Peter=20 Nilsson
> J (LI/EAB)
> > Cc: capwap@frascone.com
> = >=20 Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> >=20 Considerations
> >
> > Hi Bob,
> >
> = > If=20 I understand your description below correct, you are proposing a =
> >=20 solution (to the problem pointed out by
> > Saravanan) by = mandating=20 the behavior of the AC to always set the
> > KeyRSC in the = 4-way=20 handshake to zero.
> >
> > This is not a defined = behavior=20 according to the current
> > 802.11 standard.
> > = Are you=20 suggesting that we CAPWAP WG should specifically
> mandate = that
>=20 > in our CAPWAP protocol spec, e.g. something like "a = CAPWAP
>=20 compatible
> > AC MUST set KeyRSC to zero"? Otherwise, the = problem=20 still exists,
> > since not all AC implementation have to = follow what=20 you described.
> >
> > Or, are you planning to take = this=20 issue to TGm for 802.11 standard
> > revision? (since based = on your=20 description, there is essentially no
> > use of the = KeyRSC).
>=20 >
> > cheers
> >
> > Cheng Hong
>=20 >
> >
> >
> >
> > > = -----Original=20 Message-----
> > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]
> > = > Sent:=20 Wednesday, September 27, 2006 2:32 AM
> > > To: T. = Charles=20 Clancy; Peter Nilsson J (LI/EAB)
> > > Cc: capwap@frascone.com
> = > >=20 Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > = >=20 Considerations
> > >
> > > Charles, = Peter,
>=20 > >
> > > Below is an expansion of a snippet from a = thread=20 on this
> > topic that I
> > > sent to the list = on July=20 25, 2006.  I think this will be
> helpful to
> = >=20 > understand why the exchange that Saranavan is requesting is = not
>=20 > > necessary.  In fact, there are several systems = from=20 several
> > > manufacturers in the field using precursor = protocols=20 to
> CAPWAP that
> > > are Wi-Fi certified for = WPA2/802.11i=20 operation using the
> > protocol as
> > > it is = described=20 below.
> > >
> > > BTW, this whole discussion = is about=20 the KeyRSC for the
> > group key, not
> > > the = pairwise=20 key.  This is so because the WTP and AC both
> know=20 the
> > > initial sequence counter value for the pairwise = key,=20 since it has
> > > never been used to send a = frame.  =20 802.11i requires the
> first frame
> > > sent on a = key to=20 use the sequence counter value of 1.  See
> > 8.3.2.6 c)
> > > and
> = > >=20 8.3.3.4.3 c) in 802.11i for this requirement.
> > = >
> >=20 > The same is not true of the group key, i.e., after the WTP = begins
>=20 > > operation, the AC will not know the value of the = sequence
>=20 > counter for
> > > the group key when it needs to = complete=20 the EAPOL-key
> > handshake with a
> > > newly = associated=20 STA.
> > > However, as you will see from the tutorial = below, it is=20 not
> > necessary
> > > for the AC and WTP to = exchange=20 any information about the
> group key
> > > KeyRSC = for the=20 protocol to operate as it is intended.
> > >
> > = > 1.=20 A value for the KeyRSC in the EAPOL-key frame is necessary to
> = >=20 > calculate the KeyMIC.
> > >
> > > 2. This = value=20 does not need to bear any specific
> > relationship to = the
>=20 > > RSC value maintained by the WTP.  A value of zero = in the=20
> EAPOL-key
> > > frame for the group key will = always=20 work.
> > >
> > > 3. The client STA will use = the value=20 of KeyRSC received in the
> > > EAPOL-key frame to = validate frame=20 using the KeyMIC.
> > >
> > > 4. The client = STA will=20 also set its group key RSC to the value
> > > received in = KeyRSC,=20 say, zero.
> > >
> > > 5. The value in the = client=20 STA's RSC will be compared against the
> > > sequence = number in=20 subsequent received frames to identify replay
> > >=20 attacks.  Any frame received with a sequence counter = value
>=20 > within the
> > > replay window will be checked to = have a=20 valid MIC.  If the
> > MIC is not
> > = > valid,=20 the frame is dropped.
> > >
> > > 6. For any = frame=20 that is determined not to be a replay
> attack frame
> = > >=20 and meets all other validity and authenticity requirements,
> = > the=20 client
> > > STA updates its RSC value to the sequence = number in=20 the received
> > > frame, if the value is greater than its = current=20 RSC value.
> > Only the
> > > AP can meet these = criteria=20 as the source of a frame
> received by the
> > >=20 STA.
> > >
> > > 7. Please see item 6, = immediately=20 above, for the reason
> that the AC
> > > and WTP do = not=20 need to coordinate and exchange the RSC.
> > >
> = >=20 >
> > > The only possible attack mode is for the = attacker to=20 send
> frames to
> > > the client STA between the = time of=20 the EAPOL-key frame and
> > the first
> > > = frame=20 encrypted with the group key.
> > > During this time, the = client=20 will receive the frame and
> proceed to
> > > = validate its=20 MIC.  This is a potential attack against the STA
> = > >=20 resources.  But, the MIC validation is done in the = STA's
>=20 > > 802.11 chip and consumes no more resources than = receiving
>=20 any other
> > > frame.  Thus, the attack does = not=20 actually consume any STA
> > resources
> > > = beyond=20 those of receiving a frame.
> > >
> > > This = attack is=20 not unique to the use of the value zero for
> > the = KeyRSC,
>=20 > > either.  The same attack is available to an = attacker at=20 any other
> > > time, as well.  It is no more = nor less=20 effective at either time.
> > >
> > > For = these=20 reasons, the protocol is not in need of any changes to
> > = >=20 address the issue raised by Saranavan.
> > >
> > = >  -Bob
> > > -----Original = Message-----
> >=20 > From: T. Charles Clancy [mailto:clancy@cs.umd.edu]
> > = > Sent:=20 Monday, September 25, 2006 11:37 AM
> > > To: Peter = Nilsson J=20 (LI/EAB)
> > > Cc: capwap@frascone.com
> = > >=20 Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > = >=20 Considerations
> > >
> > > This is a very = interesting=20 solution.  The AC selects the
> KeyRSC and
> = > >=20 performs the 4-way handshake.  The WTP sniffs the 4-way=20 handshake
> > > traffic and grabs the KeyRSC value and = uses it to=20
> > initialize its own
> > > counter.
> = >=20 >
> > > Pat/Bob: Is this how the Cisco implementation=20 works?  I
> > have to agree
> > > with=20 Saravanan that I've yet to see a technical
> description of = how
>=20 > > Cisco implements it.
> > >
> > > = IMHO, this=20 is somewhat hackish, and it would be cleaner to
> > have the=20 AC
> > > generate the KeyRSC and include it in the = AddMobile=20 message
> > as Behcet
> > > suggests.
> = >=20 >
> > > --
> > > t. charles clancy,=20 ph.d.  |  tcc@umd.edu  |
> www.cs.umd.edu/~clancy
>= >=20 >
> > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB)=20 wrote:
> > >
> > > > I think Saravanan has = a point.=20 We did a prototype
> > impelementation of
> > >=20 the
> > > > protocol a year ago when it was still = called LWAPP.=20 The way
> > > we solved
> > > > this issue = then was=20 to let the WTP sniff on all CAPWAP data
> > > messages =
>=20 > > > from the AC and when message 3 of the 4-way handshake=20 or
> > > message 1 of
> > > > the groupkey=20 handshake was sent the WTP inserted the correct RSC
> > > = before=20
> > > > sending it off to the supplicant. To avoid the = sniffing on
> > > all CAPWAP
> > > > data = messages=20 we would need a mechanism with in CAPWAP to
> > > handle = these=20
> > > > two messages.
> > > >
> = > >=20 > Peter Nilsson
> > > >
> > > > = -----Original=20 Message-----
> > > > From: Saravanan Govindan
> = > >=20 [mailto:Saravanan.Govindan@sg= .panasonic.com]
>=20 > > > Sent: den 22 september 2006 11:03
> > > = > To:=20 Margaret Wasserman
> > > > Cc: capwap@frascone.com
> = > >=20 > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> = >=20 > Considerations
> > > >
> > > > Hi=20 Margaret,
> > > >
> > > > Thank you for=20 reviewing the discussion on this issue.
> > > >
> = >=20 > > The issue here is the working of IEEE 802.11i when the=20 802.11i
> > > > authenticator element is at the AC and = the=20 802.11i crypto
> > element is
> > > at
> = > >=20 > the WTP. Particularly, it is for the 4-way handshake between =
>=20 > > > authenticator and supplicant.
> > > = >
>=20 > > > Now, the 4-way handshake requires knowing the value = of
>=20 > > KeyRSC sequence
> > > > counter. The KeyRSC = helps=20 both authenticator and supplicant
> > > keep = track
> >=20 > > of their exchanges. It serves to protect against threats = by
>=20 > > tracking
> > > > sequential frames. The = KeyRSC is=20 maintained at the at the
> > point of
> > > >=20 encryption, i.e. just before transmission over the
> > = wireless=20 channel.
> > > >
> > > > In the case of = CAPWAP,=20 the 4-way handshake is between the AC
> > > > = (authenticator)=20 and the wireless station (supplicant).
> > > >
> = >=20 > > The problem arises, when the authenticator is at the AC = and
>=20 > > the crypto
> > > > element (together with = KeyRSC) is=20 at the WTP. This is a
> > > fairly common
> > = > >=20 design. Now in this case, the AC starts the 4-way
> handshake = but=20 it
> > > does
> > > > not know the value of = the=20 KeyRSC. The KeyRSC is maintained
> > > by the = WTP.
> >=20 > >
> > > > Based on this, the current CAPWAP=20 specification does not
> > allow for a
> > > = way
>=20 > > > to conduct the 4-way handshake with the correct KeyRSC. =
> > > >
> > > > The functionality I = would like=20 to see is a way for the
> > authenticator
> > > = > (AC)=20 to use the correct prevailing value of KeyRSC
> > > = (maintained by=20 the
> > > > WTP) in its 4-way handshake.
> > = >=20 >
> > > > One way to introduce this functionality in = to=20 CAPWAP is
> > to have part
> > > of
> > = >=20 > the 4-way handshake be sent from AC to WTP. This will allow =
> >=20 > the 4-way
> > > > handshake to use the correct = value of=20 the KeyRSC before
> > > being sent to
> > > = > the=20 wireless station.
> > > >
> > > > I hope = this=20 helps clarify my view on the issue.
> > > >
> = > >=20 > Cheers,
> > > >
> > > > = Saravanan
>=20 > > >
> > > >
> > > >
> = > >=20 >
> > > >
> > > >
> > > = >=20 -----Original Message-----
> > > > From: Margaret = Wasserman=20 [mailto:margaret@thingmagic.com]
&= gt;=20 > > > Sent: Thursday, September 21, 2006 8:26 PM
> = > >=20 > To: Saravanan Govindan
> > > > Cc: Pat Calhoun = (pacalhou);=20 capwap@frascone.com
> = > >=20 > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> = >=20 > Considerations
> > > >
> > > = >
> >=20 > >
> > > > Hi again,
> > > = >
> >=20 > > Okay, I am even more confused than I thought I was... =
> >=20 > >
> > > > Saravanan, you wrote:
> > = >=20 >
> > > > On Sep 17, 2006, at 10:24 PM, Saravanan = Govindan=20 wrote:
> > > >
> > > >> Pat,
> = >=20 > >>
> > > >> The issue here is about how = 802.11i=20 exchanges are done when
> > > >> authenticator is at = the AC=20 and crypto elements are at
> > the WTP. This
> > = >=20 is
> > > >> the requirement.
> > > = >
>=20 > > > And, in response, Pat Calhoun wrote:
> > >=20 >
> > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun=20 (pacalhou) wrote:
> > > >> The current = specification allows=20 the authenticator to
> > > reside in the
> > > = >> AC, while the data packet crypto elements in the WTP. = This
>=20 > > feature is
> > > >> already in the=20 specification.
> > > >
> > > > Pat's = message=20 matches my reading of the specification.
> > > = >
> >=20 > > So, Saravanan, what functionality are you asking for =
> that=20 is not
> > > > already supported by the=20 specification?  And why do you
> > think it = is
> >=20 > > necessary?  it will not be helpful to my = understanding=20 to
> > > re-send your
> > > > proposal or = to cite=20 the requirements document...  Please
> > = summarize
>=20 > > > what functionality you think is missing from the=20 current
> > > specification
> > > > and why = you=20 think that functionality is necessary to
> support IEEE
> = >=20 > > 802.11i or any important use case.
> > > = >
>=20 > > > At some point, the chairs may need to make a = consensus
>=20 > call on this
> > > > issue, and I'd like to = understand=20 your view and make sure
> > > that it has
> > = > >=20 been clearly communicated to the WG before we ask the WG to
> = > >=20 decide on
> > > > this issue.
> > > = >
>=20 > > > Thanks,
> > > > Margaret
> > = >=20 >
> > > >
> > > >
> > >=20 >
> > > >
> > > >
> > >=20 >
> = _________________________________________________________________=20
> > > > To unsubscribe or modify your subscription=20 options,
> please visit:
> > > > http://lists.f= rascone.com/mailman/listinfo/capwap=20
> > > >
> > > > Archives: http://lists.frascone= .com/pipermail/capwap
>=20 > > >
>=20 _________________________________________________________________ =
>=20 > > > To unsubscribe or modify your subscription = options,
>=20 please visit:
> > > > http://lists.f= rascone.com/mailman/listinfo/capwap=20
> > > >
> > > > Archives: http://lists.frascone= .com/pipermail/capwap
>=20 > > >
> > >=20 _________________________________________________________________ =
>=20 > > To unsubscribe or modify your subscription options, please=20 visit:
> > > http://lists.f= rascone.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.f= rascone.com/mailman/listinfo/capwap
>=20 > >
> > > Archives: http://lists.frascone= .com/pipermail/capwap
>=20 > >
> >=20 = _________________________________________________________________
>= >=20 To unsubscribe or modify your subscription options, please visit: =
>=20 > http://lists.f= rascone.com/mailman/listinfo/capwap
>=20 >
> > Archives: http://lists.frascone= .com/pipermail/capwap=20
> >
>=20 = _________________________________________________________________
>= To=20 unsubscribe or modify your subscription options, please visit:
> = http://lists.f= rascone.com/mailman/listinfo/capwap
>
>=20 Archives: http://lists.frascone= .com/pipermail/capwap
>
____________________________________= _____________________________=20
To unsubscribe or modify your subscription options, please = visit:
http://lists.f= rascone.com/mailman/listinfo/capwap

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

------_=_NextPart_001_01C6E344.049CEE77-- --===============1268748470== 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 --===============1268748470==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Sep 28 20:05:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT5sp-0003gr-Hc for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 20:05:39 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT5sm-0005ah-7K for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 20:05:39 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 828F31448023 for ; Thu, 28 Sep 2006 17:05:24 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D597D43005F for ; Thu, 28 Sep 2006 16:41:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BD49A144807B for ; Thu, 28 Sep 2006 16:41:13 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by hermes.tigertech.net (Postfix) with ESMTP id 917B61448074 for ; Thu, 28 Sep 2006 16:40:56 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so771560pyu for ; Thu, 28 Sep 2006 16:40:55 -0700 (PDT) Received: by 10.35.101.1 with SMTP id d1mr1273254pym; Thu, 28 Sep 2006 16:40:55 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Thu, 28 Sep 2006 16:40:55 -0700 (PDT) Message-ID: <26140d940609281640h3e3aa030r4cb0e704bc5c34a0@mail.gmail.com> Date: Thu, 28 Sep 2006 19:40:55 -0400 From: "Michael Montemurro" To: "Bob O'Hara (boohara)" In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC02188BC3@xmb-sjc-237.amer.cisco.com> MIME-Version: 1.0 References: <17B8C6DE4E228348B4939BDA6B05A9DC02188BC3@xmb-sjc-237.amer.cisco.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.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com, Cheng Hong Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0557266619==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: f27aa5169a850f4f07ecb12d54c20028 --===============0557266619== Content-Type: multipart/alternative; boundary="----=_Part_20635_5715948.1159486855192" ------=_Part_20635_5715948.1159486855192 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Bob and all interested parties, In the last round of edits, I updated Section 11.3 to describe the GTK update procedure. I thought that it lines up pretty well with what's in IEEE 802.11i (and implementations of IEEE 802.11i that I am aware of). Could someone make recommendations on how you think this section should be updated? Thanks, Mike On 9/28/06, Bob O'Hara (boohara) wrote: > > Dorothy, > > The problem with this proposal is that it is no more effective than > sending a value of zero for the KeyRSC. It doesn't eliminate any potential > attacks. It doesn't add any functionality. However, it does add cost and > complexity to the protocol. > > -Bob > > > > ------------------------------ > *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > *Sent:* Thursday, September 28, 2006 1:17 PM > *To:* Bob O'Hara (boohara) > *Cc:* Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson > J (LI/EAB); capwap@frascone.com > *Subject:* Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > > All, > > Below is the text from 802.11REV-maD8.0 Clause 8.5.2, describing the Key > RSC field.: > > "g) Key RSC. This field is 8 octets in length. It contains the receive > sequence counter (RSC) for the > GTK being installed in IEEE 802.11. It is used in Message 3 of the 4-Way > Handshake and > Message 1 of the Group Key Handshake, where it is used to synchronize the > IEEE 802.11 replay > state. It may also be used in the Michael MIC Failure Report frame, to > report the TSC field value of > the frame experiencing a MIC failure. It shall contain 0 in other > messages. The Key RSC field gives > the current message number for the GTK, to allow a STA to identify > replayed MPDUs. If the Key > RSC field value is less than 8 octets in length, the remaining octets > shall be set to 0. The least significant > octet of the TSC or PN should be in the first octet of the Key RSC field." > > The intent of adding this value in message 3 was to immediately minimize > the number of > replayed frames that a STA would potentially process: "The Key RSC field > gives > the current message number for the GTK, to allow a STA to identify > replayed MPDUs." > Setting the value to 0 in Msg 3 does not provide the current sequence > counter (in most cases > not even close) of the GTK.. > > Perhaps the WTP could periodically/frequently notify the AC of its current > GTK sequence counter, and the > AC would use the most recently received value in the message 3 sent to new > STAs. The RSC value > would not be up to date at all times, but would be closer than "0", not > require an "in-the-critical-path > message exchange between the AC and WTP, and still be close to the > intended use of the field. > > Dorothy > > On 9/28/06, Bob O'Hara (boohara) wrote: > > > > Please understand that 802.11i specifies no behavior in this area for > > the 802.1X authenticator. Our choice to send a group key KeyRSC value > > of zero in the EAPOL-key frame requires no change to 802.11i or to > > 802.1X . It requires us to state this in the CAPWAP spec, if we want > > this behavior to be consistent across all implementations. > > > > The problem with what Bechet and Saranavan are asking is that either of > > three different things are required: > > 1: the WTP must communicate the group key TSC to the AC every time it is > > updated, or > > 2: the AC must request the current value of the group key TSC for the > > KeyRSC before constructing the EAPOL-key frame, or > > 3: the AC must send the KCK to the AC so that it can insert the KeyRSC > > value and also calculate the correct MIC, inserting that into the proper > > EAPOL-key frame. > > > > The first item requires a tremendous amount of additional CAPWAP > > communication between WTP and AC, at least one new CAPWAP packet for > > every multicast frame sent by the WTP, if the packet is not > > acknowledged, or two new CAPWAP packets, if it is acknowledged. This is > > a very expensive addition to the protocol. > > > > The second item requires new protocol between the AC and WTP during what > > can be a time critical portion of the 802.11 transition (handoff, roam) > > from one WTP to another. It also introduces a race condition that is > > not present in the protocol today. Once the value for the KeyRSC is > > sent from the WTP to the AC, it is possible that the WTP can send > > another multicast frame encrypted with the group key. This puts the > > value of the sequence counter out of sync with the value that will be > > shortly communicated to the client in the EAPOL-key frame from the AC. > > This will behave exactly the same as if a value of zero is sent in the > > EAPOL-key frame. > > > > The third item requires a new architecture split that is not required in > > > > our objectives. The new split is not splitting the MAC, but splitting > > the authenticator. Placing the KCK in the WTP is also a potential > > reduction in the security of the overall WLAN system, since these > > devices are normally not in a secured wiring closet, but exposed and > > more easily compromised than the AC. > > > > The simplest to implement, least expensive, and most secure option is to > > use the protocol as it is now specified and have the AC send a value of > > zero in the KeyRSC field of the EAPOL-key frame. > > > > -Bob > > > > -----Original Message----- > > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > > Sent: Wednesday, September 27, 2006 6:50 PM > > To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy; > > Peter Nilsson J (LI/EAB) > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > > > Hi Pat and all, > > > > So, based on this, I would say that we have consensus that setting the > > correct KeyRSC is an issue for the CAPWAP protocol design. > > > > So far, we have three option/solutions: > > > > 1) As proposed by Bob: Using a static value (0) for the KeyRSC. > > > > 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP > > > > 3) As suggested by Saravanana: Some exchange mechanism between WTP and > > AC > > > > Among the three, the first option seems the easiest. However, it > > requires a mandated Authenticator behavior(in this case AC) that is not > > mandated by 802.11. Therefore, we have to specify that (e.g. as proposed > > by Bob: "We could include a note to the effect that the group KeyRSC > > should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11, > > because otherwise there is no interoperability. For example, AC provided > > by another vendor does not have to set KeyRSC to 0 to be compliant with > > CAPWAP and 802.11i. > > > > Another implication is that we don't really understand the impact of > > mandating a static KeyRSC value. Although Bob provided an excellent > > analysis, I still have some doubts about the profoundness of the impact. > > If the KeyRSC value is as described of no use, why would it appear in > > the EAPOL frames in the first place? By mandating it to static value, > > what have we lost? Maybe some liaison letter to 802.1 or 802.11 could > > provide us a better understanding of the issue. > > > > For the last two options, I think they are both within CAPWAP's scope. > > Further analysis could help us to decide which one is better (or > > someone could propose other solutions). > > > > cheers > > > > Cheng Hong > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com] > > > Sent: Thursday, September 28, 2006 1:39 AM > > > To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; > > > Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > Bob's point is 802.11i works this way today. The AP (or in > > > this case AC) can set the RSC to whatever value it wishes. > > > Bob used zero (0) as an example. Implementations could use > > > any other value, which would require some form of > > > communication to the WTP, as suggested by Behcet. > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit > > > Cisco Systems > > > > > > > > > > > > > -----Original Message----- > > > > From: Cheng Hong [mailto: Hong.Cheng@sg.panasonic.com] > > > > Sent: Tuesday, September 26, 2006 6:03 PM > > > > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson > > > J (LI/EAB) > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > Considerations > > > > > > > > Hi Bob, > > > > > > > > If I understand your description below correct, you are proposing a > > > > solution (to the problem pointed out by > > > > Saravanan) by mandating the behavior of the AC to always set the > > > > KeyRSC in the 4-way handshake to zero. > > > > > > > > This is not a defined behavior according to the current > > > > 802.11 standard. > > > > Are you suggesting that we CAPWAP WG should specifically > > > mandate that > > > > in our CAPWAP protocol spec, e.g. something like "a CAPWAP > > > compatible > > > > AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, > > > > since not all AC implementation have to follow what you described. > > > > > > > > Or, are you planning to take this issue to TGm for 802.11 standard > > > > revision? (since based on your description, there is essentially no > > > > use of the KeyRSC). > > > > > > > > cheers > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > > > > > Sent: Wednesday, September 27, 2006 2:32 AM > > > > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB) > > > > > Cc: capwap@frascone.com > > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > > Considerations > > > > > > > > > > Charles, Peter, > > > > > > > > > > Below is an expansion of a snippet from a thread on this > > > > topic that I > > > > > sent to the list on July 25, 2006. I think this will be > > > helpful to > > > > > understand why the exchange that Saranavan is requesting is not > > > > > necessary. In fact, there are several systems from several > > > > > manufacturers in the field using precursor protocols to > > > CAPWAP that > > > > > are Wi-Fi certified for WPA2/802.11i operation using the > > > > protocol as > > > > > it is described below. > > > > > > > > > > BTW, this whole discussion is about the KeyRSC for the > > > > group key, not > > > > > the pairwise key. This is so because the WTP and AC both > > > know the > > > > > initial sequence counter value for the pairwise key, since it has > > > > > never been used to send a frame. 802.11i requires the > > > first frame > > > > > sent on a key to use the sequence counter value of 1. See > > > > 8.3.2.6 c) > > > > > and > > > > > 8.3.3.4.3 c) in 802.11i for this requirement. > > > > > > > > > > The same is not true of the group key, i.e., after the WTP begins > > > > > operation, the AC will not know the value of the sequence > > > > counter for > > > > > the group key when it needs to complete the EAPOL-key > > > > handshake with a > > > > > newly associated STA. > > > > > However, as you will see from the tutorial below, it is not > > > > necessary > > > > > for the AC and WTP to exchange any information about the > > > group key > > > > > KeyRSC for the protocol to operate as it is intended. > > > > > > > > > > 1. A value for the KeyRSC in the EAPOL-key frame 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. A value of zero in the > > > EAPOL-key > > > > > frame for the group key will always work. > > > > > > > > > > 3. The client STA will use the value of KeyRSC received in the > > > > > EAPOL-key frame to validate frame using the KeyMIC. > > > > > > > > > > 4. The client STA will also set its group key RSC to the value > > > > > received in KeyRSC, say, zero. > > > > > > > > > > 5. The value in the client STA's RSC will be compared against the > > > > > sequence number in subsequent received frames to identify replay > > > > > attacks. Any frame received with a sequence counter value > > > > within the > > > > > replay window will be checked to have a valid MIC. If the > > > > MIC is not > > > > > valid, the frame is dropped. > > > > > > > > > > 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, if the value is greater than its current RSC value. > > > > Only the > > > > > AP can meet these criteria as the source of a frame > > > received by the > > > > > STA. > > > > > > > > > > 7. Please see item 6, immediately above, for the reason > > > that the AC > > > > > and WTP do not need to coordinate and exchange the RSC. > > > > > > > > > > > > > > > The only possible attack mode is for the attacker to send > > > frames to > > > > > the client STA between the time of the EAPOL-key frame and > > > > the first > > > > > frame encrypted with the group key. > > > > > During this time, the client will receive the frame and > > > proceed to > > > > > validate its MIC. This is a potential attack against the STA > > > > > resources. But, the MIC validation is done in the STA's > > > > > 802.11 chip and consumes no more resources than receiving > > > any other > > > > > frame. Thus, the attack does not actually consume any STA > > > > resources > > > > > beyond those of receiving a frame. > > > > > > > > > > This attack is not unique to the use of the value zero for > > > > the KeyRSC, > > > > > either. The same attack is available to an attacker at any other > > > > > time, as well. It is no more nor less effective at either time. > > > > > > > > > > For these reasons, the protocol is not in need of any changes to > > > > > address the issue raised by Saranavan. > > > > > > > > > > -Bob > > > > > -----Original Message----- > > > > > From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > > > > > Sent: Monday, September 25, 2006 11:37 AM > > > > > To: Peter Nilsson J (LI/EAB) > > > > > Cc: capwap@frascone.com > > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > > Considerations > > > > > > > > > > This is a very interesting solution. The AC selects the > > > KeyRSC and > > > > > performs the 4-way handshake. The WTP sniffs the 4-way handshake > > > > > traffic and grabs the KeyRSC value and uses it to > > > > initialize its own > > > > > counter. > > > > > > > > > > Pat/Bob: Is this how the Cisco implementation works? I > > > > have to agree > > > > > with Saravanan that I've yet to see a technical > > > description of how > > > > > Cisco implements it. > > > > > > > > > > IMHO, this is somewhat hackish, and it would be cleaner to > > > > have the AC > > > > > generate the KeyRSC and include it in the AddMobile message > > > > as Behcet > > > > > suggests. > > > > > > > > > > -- > > > > > t. charles clancy, ph.d. | tcc@umd.edu | > > > www.cs.umd.edu/~clancy > > > > > > > > > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > > > > > > > > > > > I think Saravanan has a point. We did a prototype > > > > impelementation of > > > > > the > > > > > > protocol a year ago when it was still called LWAPP. The way > > > > > we solved > > > > > > this issue then was to let the WTP sniff on all CAPWAP data > > > > > messages > > > > > > from the AC and when message 3 of the 4-way handshake or > > > > > message 1 of > > > > > > the groupkey handshake was sent the WTP inserted the correct RSC > > > > > before > > > > > > sending it off to the supplicant. To avoid the sniffing on > > > > > all CAPWAP > > > > > > data messages we would need a mechanism with in CAPWAP to > > > > > handle these > > > > > > two messages. > > > > > > > > > > > > Peter Nilsson > > > > > > > > > > > > -----Original Message----- > > > > > > From: Saravanan Govindan > > > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > > > Sent: den 22 september 2006 11:03 > > > > > > To: Margaret Wasserman > > > > > > Cc: capwap@frascone.com > > > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > > Considerations > > > > > > > > > > > > Hi Margaret, > > > > > > > > > > > > Thank you for reviewing the discussion on this issue. > > > > > > > > > > > > The issue here is the working of IEEE 802.11i when the 802.11i > > > > > > authenticator element is at the AC and the 802.11i crypto > > > > element is > > > > > at > > > > > > the WTP. Particularly, it is for the 4-way handshake between > > > > > > authenticator and supplicant. > > > > > > > > > > > > Now, the 4-way handshake requires knowing the value of > > > > > KeyRSC sequence > > > > > > counter. The KeyRSC helps both authenticator and supplicant > > > > > keep track > > > > > > of their exchanges. It serves to protect against threats by > > > > > tracking > > > > > > sequential frames. The KeyRSC is maintained at the at the > > > > point of > > > > > > encryption, i.e. just before transmission over the > > > > wireless channel. > > > > > > > > > > > > In the case of CAPWAP, the 4-way handshake is between the AC > > > > > > (authenticator) and the wireless station (supplicant). > > > > > > > > > > > > The problem arises, when the authenticator is at the AC and > > > > > the crypto > > > > > > element (together with KeyRSC) is at the WTP. This is a > > > > > fairly common > > > > > > design. Now in this case, the AC starts the 4-way > > > handshake but it > > > > > does > > > > > > not know the value of the KeyRSC. The KeyRSC is maintained > > > > > by the WTP. > > > > > > > > > > > > Based on this, the current CAPWAP specification does not > > > > allow for a > > > > > way > > > > > > to conduct the 4-way handshake with the correct KeyRSC. > > > > > > > > > > > > The functionality I would like to see is a way for the > > > > authenticator > > > > > > (AC) to use the correct prevailing value of KeyRSC > > > > > (maintained by the > > > > > > WTP) in its 4-way handshake. > > > > > > > > > > > > One way to introduce this functionality in to CAPWAP is > > > > to have part > > > > > of > > > > > > the 4-way handshake be sent from AC to WTP. This will allow > > > > > the 4-way > > > > > > handshake to use the correct value of the KeyRSC before > > > > > being sent to > > > > > > the wireless station. > > > > > > > > > > > > I hope this helps clarify my view on the issue. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > > > > > > Sent: Thursday, September 21, 2006 8:26 PM > > > > > > To: Saravanan Govindan > > > > > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > > Considerations > > > > > > > > > > > > > > > > > > > > > > > > Hi again, > > > > > > > > > > > > Okay, I am even more confused than I thought I was... > > > > > > > > > > > > Saravanan, you wrote: > > > > > > > > > > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > > > > > > > > > >> Pat, > > > > > >> > > > > > >> The issue here is about how 802.11i exchanges are done when > > > > > >> authenticator is at the AC and crypto elements are at > > > > the WTP. This > > > > > is > > > > > >> the requirement. > > > > > > > > > > > > And, in response, Pat Calhoun wrote: > > > > > > > > > > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: > > > > > >> The current specification allows the authenticator to > > > > > reside in the > > > > > >> AC, while the data packet crypto elements in the WTP. This > > > > > feature is > > > > > >> already in the specification. > > > > > > > > > > > > Pat's message matches my reading of the specification. > > > > > > > > > > > > So, Saravanan, what functionality are you asking for > > > that is not > > > > > > already supported by the specification? And why do you > > > > think it is > > > > > > necessary? it will not be helpful to my understanding to > > > > > re-send your > > > > > > proposal or to cite the requirements document... Please > > > > summarize > > > > > > what functionality you think is missing from the current > > > > > specification > > > > > > and why you think that functionality is necessary to > > > support IEEE > > > > > > 802.11i or any important use case. > > > > > > > > > > > > At some point, the chairs may need to make a consensus > > > > call on this > > > > > > issue, and I'd like to understand your view and make sure > > > > > that it has > > > > > > been clearly communicated to the WG before we ask the WG to > > > > > decide on > > > > > > this issue. > > > > > > > > > > > > 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 > > > > > > > > > _________________________________________________________________ > > > > > > 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 > > > > > > > > > _________________________________________________________________ > > > > 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 > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_20635_5715948.1159486855192 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Bob and all interested parties,
 
In the last round of edits, I updated Section 11.3 to describe the GTK update procedure. I thought that it lines up pretty well with what's in IEEE 802.11i (and implementations of IEEE 802.11i that I am aware of).
 
Could someone make recommendations on how you think this section should be updated?
 
Thanks,
 
Mike

 
On 9/28/06, Bob O'Hara (boohara) <boohara@cisco.com> wrote:
Dorothy,
 
The problem with this proposal is that it is no more effective than sending a value of zero for the KeyRSC.  It doesn't eliminate any potential attacks.  It doesn't add any functionality.  However, it does add cost and complexity to the protocol. 

 -Bob
 

 

From: Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Thursday, September 28, 2006 1:17 PM
To: Bob O'Hara (boohara)
Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com

Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

 
All,

Below is the text from 802.11REV-maD8.0 Clause 8.5.2, describing the Key RSC field.:

"g) Key RSC. This field is 8 octets in length. It contains the receive sequence counter (RSC) for the
GTK being installed in IEEE 802.11. It is used in Message 3 of the 4-Way Handshake and
Message 1 of the Group Key Handshake, where it is used to synchronize the IEEE 802.11 replay
state. It may also be used in the Michael MIC Failure Report frame, to report the TSC field value of
the frame experiencing a MIC failure. It shall contain 0 in other messages. The Key RSC field gives
the current message number for the GTK, to allow a STA to identify replayed MPDUs. If the Key
RSC field value is less than 8 octets in length, the remaining octets shall be set to 0. The least significant
octet of the TSC or PN should be in the first octet of the Key RSC field."

The intent of adding this value in message 3 was to immediately minimize the number of
replayed frames that a STA would potentially process: "The Key RSC field gives
the current message number for the GTK, to allow a STA to identify replayed MPDUs."
Setting the value to 0 in Msg 3 does not provide the current sequence counter (in most cases
not even close) of the GTK..

Perhaps the WTP could periodically/frequently notify the AC of its current GTK sequence counter, and the
AC would use the most recently received value in the message 3 sent to new STAs. The RSC value
would not be  up to date at all times, but would be closer than "0", not require an "in-the-critical-path
message exchange between the AC and WTP, and still be close to the intended use of the field.

Dorothy

On 9/28/06, Bob O'Hara (boohara) <boohara@cisco.com > wrote:
Please understand that 802.11i specifies no behavior in this area for
the 802.1X authenticator.  Our choice to send a group key KeyRSC value
of zero in the EAPOL-key frame requires no change to 802.11i or to
802.1X .  It requires us to state this in the CAPWAP spec, if we want
this behavior to be consistent across all implementations.

The problem with what Bechet and Saranavan are asking is that either of
three different things are required:
1: the WTP must communicate the group key TSC to the AC every time it is
updated, or
2: the AC must request the current value of the group key TSC for the
KeyRSC before constructing the EAPOL-key frame, or
3: the AC must send the KCK to the AC so  that it can insert the KeyRSC
value and also calculate the correct MIC, inserting that into the proper
EAPOL-key frame.

The first item requires a tremendous amount of additional CAPWAP
communication between WTP and AC, at least one new CAPWAP packet for
every multicast frame sent by the WTP, if the packet is not
acknowledged, or two new CAPWAP packets, if it is acknowledged.  This is
a very expensive addition to the protocol.

The second item requires new protocol between the AC and WTP during what
can be a time critical portion of the 802.11 transition (handoff, roam)
from one WTP to another.  It also introduces a race condition that is
not present in the protocol today.  Once the value for the KeyRSC is
sent from the WTP to the AC, it is possible that the WTP can send
another multicast frame encrypted with the group key.  This puts the
value of the sequence counter out of sync with the value that will be
shortly communicated to the client in the EAPOL-key frame from the AC.
This will behave exactly the same as if a value of zero is sent in the
EAPOL-key frame.

The third item requires a new architecture split that is not required in
our objectives.  The new split is not splitting the MAC, but splitting
the authenticator.  Placing the KCK in the WTP is also a potential
reduction in the security of the overall WLAN system, since these
devices are normally not in a secured wiring closet, but exposed and
more easily compromised than the AC.

The simplest to implement, least expensive, and most secure option is to
use the protocol as it is now specified and have the AC send a value of
zero in the KeyRSC field of the EAPOL-key frame.

-Bob

-----Original Message-----
From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com ]
Sent: Wednesday, September 27, 2006 6:50 PM
To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy;
Peter Nilsson J (LI/EAB)
Cc: capwap@frascone.com
Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Hi Pat and all,

So, based on this, I would say that we have consensus that setting the
correct KeyRSC is an issue for the CAPWAP protocol design.

So far, we have three option/solutions:

1) As proposed by Bob: Using a static value (0) for the KeyRSC.

2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP

3) As suggested by Saravanana: Some exchange mechanism between WTP and
AC

Among the three, the first option seems the easiest. However, it
requires a mandated Authenticator behavior(in this case AC) that is not
mandated by 802.11. Therefore, we have to specify that (e.g. as proposed
by Bob: "We could include a note to the effect that the group KeyRSC
should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11,
because otherwise there is no interoperability. For example, AC provided
by another vendor does not have to set KeyRSC to 0 to be compliant with
CAPWAP and 802.11i.

Another implication is that we don't really understand the impact of
mandating a static KeyRSC value. Although Bob provided an excellent
analysis, I still have some doubts about the profoundness of the impact.
If the KeyRSC value is as described of no use, why would it appear in
the EAPOL frames in the first place? By mandating it to static value,
what have we lost? Maybe some liaison letter to 802.1 or 802.11 could
provide us a better understanding of the issue.

For the last two options, I think they are both within CAPWAP's scope.
Further analysis could help us to decide which one  is better (or
someone could propose other solutions).

cheers

Cheng Hong







> -----Original Message-----
> From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com]
> Sent: Thursday, September 28, 2006 1:39 AM
> To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy;
> Peter Nilsson J (LI/EAB)
> Cc: capwap@frascone.com
> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> Considerations
>
> Bob's point is 802.11i works this way today. The AP (or in
> this case AC) can set the RSC to whatever value it wishes.
> Bob used zero (0) as an example. Implementations could use
> any other value, which would require some form of
> communication to the WTP, as suggested by Behcet.
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
>
> > -----Original Message-----
> > From: Cheng Hong [mailto: Hong.Cheng@sg.panasonic.com]
> > Sent: Tuesday, September 26, 2006 6:03 PM
> > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson
> J (LI/EAB)
> > Cc: capwap@frascone.com
> > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > Considerations
> >
> > Hi Bob,
> >
> > If I understand your description below correct, you are proposing a
> > solution (to the problem pointed out by
> > Saravanan) by mandating the behavior of the AC to always set the
> > KeyRSC in the 4-way handshake to zero.
> >
> > This is not a defined behavior according to the current
> > 802.11 standard.
> > Are you suggesting that we CAPWAP WG should specifically
> mandate that
> > in our CAPWAP protocol spec, e.g. something like "a CAPWAP
> compatible
> > AC MUST set KeyRSC to zero"? Otherwise, the problem still exists,
> > since not all AC implementation have to follow what you described.
> >
> > Or, are you planning to take this issue to TGm for 802.11 standard
> > revision? (since based on your description, there is essentially no
> > use of the KeyRSC).
> >
> > cheers
> >
> > Cheng Hong
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Bob O'Hara (boohara) [mailto: boohara@cisco.com]
> > > Sent: Wednesday, September 27, 2006 2:32 AM
> > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB)
> > > Cc: capwap@frascone.com
> > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > > Considerations
> > >
> > > Charles, Peter,
> > >
> > > Below is an expansion of a snippet from a thread on this
> > topic that I
> > > sent to the list on July 25, 2006.  I think this will be
> helpful to
> > > understand why the exchange that Saranavan is requesting is not
> > > necessary.  In fact, there are several systems from several
> > > manufacturers in the field using precursor protocols to
> CAPWAP that
> > > are Wi-Fi certified for WPA2/802.11i operation using the
> > protocol as
> > > it is described below.
> > >
> > > BTW, this whole discussion is about the KeyRSC for the
> > group key, not
> > > the pairwise key.  This is so because the WTP and AC both
> know the
> > > initial sequence counter value for the pairwise key, since it has
> > > never been used to send a frame.   802.11i requires the
> first frame
> > > sent on a key to use the sequence counter value of 1.  See
> > 8.3.2.6 c)
> > > and
> > > 8.3.3.4.3 c) in 802.11i for this requirement.
> > >
> > > The same is not true of the group key, i.e., after the WTP begins
> > > operation, the AC will not know the value of the sequence
> > counter for
> > > the group key when it needs to complete the EAPOL-key
> > handshake with a
> > > newly associated STA.
> > > However, as you will see from the tutorial below, it is not
> > necessary
> > > for the AC and WTP to exchange any information about the
> group key
> > > KeyRSC for the protocol to operate as it is intended.
> > >
> > > 1. A value for the KeyRSC in the EAPOL-key frame 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.  A value of zero in the
> EAPOL-key
> > > frame for the group key will always work.
> > >
> > > 3. The client STA will use the value of KeyRSC received in the
> > > EAPOL-key frame to validate frame using the KeyMIC.
> > >
> > > 4. The client STA will also set its group key RSC to the value
> > > received in KeyRSC, say, zero.
> > >
> > > 5. The value in the client STA's RSC will be compared against the
> > > sequence number in subsequent received frames to identify replay
> > > attacks.  Any frame received with a sequence counter value
> > within the
> > > replay window will be checked to have a valid MIC.  If the
> > MIC is not
> > > valid, the frame is dropped.
> > >
> > > 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, if the value is greater than its current RSC value.
> > Only the
> > > AP can meet these criteria as the source of a frame
> received by the
> > > STA.
> > >
> > > 7. Please see item 6, immediately above, for the reason
> that the AC
> > > and WTP do not need to coordinate and exchange the RSC.
> > >
> > >
> > > The only possible attack mode is for the attacker to send
> frames to
> > > the client STA between the time of the EAPOL-key frame and
> > the first
> > > frame encrypted with the group key.
> > > During this time, the client will receive the frame and
> proceed to
> > > validate its MIC.  This is a potential attack against the STA
> > > resources.  But, the MIC validation is done in the STA's
> > > 802.11 chip and consumes no more resources than receiving
> any other
> > > frame.  Thus, the attack does not actually consume any STA
> > resources
> > > beyond those of receiving a frame.
> > >
> > > This attack is not unique to the use of the value zero for
> > the KeyRSC,
> > > either.  The same attack is available to an attacker at any other
> > > time, as well.  It is no more nor less effective at either time.
> > >
> > > For these reasons, the protocol is not in need of any changes to
> > > address the issue raised by Saranavan.
> > >
> > >  -Bob
> > > -----Original Message-----
> > > From: T. Charles Clancy [mailto: clancy@cs.umd.edu]
> > > Sent: Monday, September 25, 2006 11:37 AM
> > > To: Peter Nilsson J (LI/EAB)
> > > Cc: capwap@frascone.com
> > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > > Considerations
> > >
> > > This is a very interesting solution.  The AC selects the
> KeyRSC and
> > > performs the 4-way handshake.  The WTP sniffs the 4-way handshake
> > > traffic and grabs the KeyRSC value and uses it to
> > initialize its own
> > > counter.
> > >
> > > Pat/Bob: Is this how the Cisco implementation works?  I
> > have to agree
> > > with Saravanan that I've yet to see a technical
> description of how
> > > Cisco implements it.
> > >
> > > IMHO, this is somewhat hackish, and it would be cleaner to
> > have the AC
> > > generate the KeyRSC and include it in the AddMobile message
> > as Behcet
> > > suggests.
> > >
> > > --
> > > t. charles clancy, ph.d.  |  tcc@umd.edu   |
> www.cs.umd.edu/~clancy
> > >
> > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote:
> > >
> > > > I think Saravanan has a point. We did a prototype
> > impelementation of
> > > the
> > > > protocol a year ago when it was still called LWAPP. The way
> > > we solved
> > > > this issue then was to let the WTP sniff on all CAPWAP data
> > > messages
> > > > from the AC and when message 3 of the 4-way handshake or
> > > message 1 of
> > > > the groupkey handshake was sent the WTP inserted the correct RSC
> > > before
> > > > sending it off to the supplicant. To avoid the sniffing on
> > > all CAPWAP
> > > > data messages we would need a mechanism with in CAPWAP to
> > > handle these
> > > > two messages.
> > > >
> > > > Peter Nilsson
> > > >
> > > > -----Original Message-----
> > > > From: Saravanan Govindan
> > > [mailto: Saravanan.Govindan@sg.panasonic.com]
> > > > Sent: den 22 september 2006 11:03
> > > > To: Margaret Wasserman
> > > > Cc: capwap@frascone.com
> > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > > Considerations
> > > >
> > > > Hi Margaret,
> > > >
> > > > Thank you for reviewing the discussion on this issue.
> > > >
> > > > The issue here is the working of IEEE 802.11i when the 802.11i
> > > > authenticator element is at the AC and the 802.11i crypto
> > element is
> > > at
> > > > the WTP. Particularly, it is for the 4-way handshake between
> > > > authenticator and supplicant.
> > > >
> > > > Now, the 4-way handshake requires knowing the value of
> > > KeyRSC sequence
> > > > counter. The KeyRSC helps both authenticator and supplicant
> > > keep track
> > > > of their exchanges. It serves to protect against threats by
> > > tracking
> > > > sequential frames. The KeyRSC is maintained at the at the
> > point of
> > > > encryption, i.e. just before transmission over the
> > wireless channel.
> > > >
> > > > In the case of CAPWAP, the 4-way handshake is between the AC
> > > > (authenticator) and the wireless station (supplicant).
> > > >
> > > > The problem arises, when the authenticator is at the AC and
> > > the crypto
> > > > element (together with KeyRSC) is at the WTP. This is a
> > > fairly common
> > > > design. Now in this case, the AC starts the 4-way
> handshake but it
> > > does
> > > > not know the value of the KeyRSC. The KeyRSC is maintained
> > > by the WTP.
> > > >
> > > > Based on this, the current CAPWAP specification does not
> > allow for a
> > > way
> > > > to conduct the 4-way handshake with the correct KeyRSC.
> > > >
> > > > The functionality I would like to see is a way for the
> > authenticator
> > > > (AC) to use the correct prevailing value of KeyRSC
> > > (maintained by the
> > > > WTP) in its 4-way handshake.
> > > >
> > > > One way to introduce this functionality in to CAPWAP is
> > to have part
> > > of
> > > > the 4-way handshake be sent from AC to WTP. This will allow
> > > the 4-way
> > > > handshake to use the correct value of the KeyRSC before
> > > being sent to
> > > > the wireless station.
> > > >
> > > > I hope this helps clarify my view on the issue.
> > > >
> > > > Cheers,
> > > >
> > > > Saravanan
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Margaret Wasserman [mailto: margaret@thingmagic.com]
> > > > Sent: Thursday, September 21, 2006 8:26 PM
> > > > To: Saravanan Govindan
> > > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com
> > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > > Considerations
> > > >
> > > >
> > > >
> > > > Hi again,
> > > >
> > > > Okay, I am even more confused than I thought I was...
> > > >
> > > > Saravanan, you wrote:
> > > >
> > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote:
> > > >
> > > >> Pat,
> > > >>
> > > >> The issue here is about how 802.11i exchanges are done when
> > > >> authenticator is at the AC and crypto elements are at
> > the WTP. This
> > > is
> > > >> the requirement.
> > > >
> > > > And, in response, Pat Calhoun wrote:
> > > >
> > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote:
> > > >> The current specification allows the authenticator to
> > > reside in the
> > > >> AC, while the data packet crypto elements in the WTP. This
> > > feature is
> > > >> already in the specification.
> > > >
> > > > Pat's message matches my reading of the specification.
> > > >
> > > > So, Saravanan, what functionality are you asking for
> that is not
> > > > already supported by the specification?  And why do you
> > think it is
> > > > necessary?  it will not be helpful to my understanding to
> > > re-send your
> > > > proposal or to cite the requirements document...  Please
> > summarize
> > > > what functionality you think is missing from the current
> > > specification
> > > > and why you think that functionality is necessary to
> support IEEE
> > > > 802.11i or any important use case.
> > > >
> > > > At some point, the chairs may need to make a consensus
> > call on this
> > > > issue, and I'd like to understand your view and make sure
> > > that it has
> > > > been clearly communicated to the WG before we ask the WG to
> > > decide on
> > > > this issue.
> > > >
> > > > 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
> > > >
> _________________________________________________________________
> > > > 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
> > >
> > _________________________________________________________________
> > 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


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

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


------=_Part_20635_5715948.1159486855192-- --===============0557266619== 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 --===============0557266619==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Sep 28 20:54:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT6eS-00018z-04 for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 20:54:52 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT6eO-0003Xj-Kc for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 20:54:51 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id AC82F1448094 for ; Thu, 28 Sep 2006 17:54:42 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 5D5EC43005F for ; Thu, 28 Sep 2006 17:35:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3D0451448046 for ; Thu, 28 Sep 2006 17:35:35 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id EEBCC1448036 for ; Thu, 28 Sep 2006 17:35:26 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id k8T0Z17A021244; Fri, 29 Sep 2006 09:35:01 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k8T0Z2C11641; Fri, 29 Sep 2006 09:35:02 +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 k8T0Z0111978; Fri, 29 Sep 2006 09:35:00 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Sep 2006 08:34:02 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F1F7F@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbjOwaBxAxmTegASwKjGKmQD0OreAAB7o8QAAZYQgA= From: "Cheng Hong" To: "Bob O'Hara (boohara)" , "Dorothy Stanley" 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.6 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_30_40, HTML_MESSAGE, NORMAL_HTTP_TO_IP X-Spam-Level: Cc: capwap@frascone.com, Saravanan Govindan Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1123308397==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 51094133f49674dc57910e362ae628af This is a multi-part message in MIME format. --===============1123308397== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E35E.F875F2C7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E35E.F875F2C7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bob, =20 As Dorothy correctly pointed out below, setting the KeyRSC to a value closer to the current RSC would be better than setting it to a pre-defined value zero.=20 =20 It is true that 802.11i and 802.1X do not specify what is the KeyRSC value to be used, since they are trying to provide us a tool to correctly synchronize the RSC using the Msg 3. By mandating the KeyRSC to zero, we are just disabling the tool. It is not wrong, but just deprives the system a designed function. =20 As for the effectiveness of KeyRSC, setting it to a predefined value of 0 would pose a greater threat. In a simple example, if the RSC is currently 1000, and we are mandating the KeyRSC to be always zero, the attacker basically can safely replay the last 1000 packets to the STA without being detected. If the KeyRSC can be set to a closer value of the current RSC, say, 900, the number of possible replayed packets can be reduced to 10 percent, 100 packets.=20 =20 Therefore, I would say, setting the KeyRSC value to zero does place a bigger threat. Is that how the cisco products implemented? Maybe you could share with us some other implementation/testing data to prove otherwise. Or, you have some other considerations that could defend the replay attack? =20 cheers =20 Cheng Hong =20 _____ =20 From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Friday, September 29, 2006 5:21 AM To: Dorothy Stanley Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations Dorothy, =20 The problem with this proposal is that it is no more effective than sending a value of zero for the KeyRSC. It doesn't eliminate any potential attacks. It doesn't add any functionality. However, it does add cost and complexity to the protocol. =20 -Bob =20 =20 _____ =20 From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Thursday, September 28, 2006 1:17 PM To: Bob O'Hara (boohara) Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations All, Below is the text from 802.11REV-maD8.0 Clause 8.5.2, describing the Key RSC field.: "g) Key RSC. This field is 8 octets in length. It contains the receive sequence counter (RSC) for the GTK being installed in IEEE 802.11. It is used in Message 3 of the 4-Way Handshake and Message 1 of the Group Key Handshake, where it is used to synchronize the IEEE 802.11 replay state. It may also be used in the Michael MIC Failure Report frame, to report the TSC field value of the frame experiencing a MIC failure. It shall contain 0 in other messages. The Key RSC field gives the current message number for the GTK, to allow a STA to identify replayed MPDUs. If the Key RSC field value is less than 8 octets in length, the remaining octets shall be set to 0. The least significant octet of the TSC or PN should be in the first octet of the Key RSC field." The intent of adding this value in message 3 was to immediately minimize the number of=20 replayed frames that a STA would potentially process: "The Key RSC field gives the current message number for the GTK, to allow a STA to identify replayed MPDUs." Setting the value to 0 in Msg 3 does not provide the current sequence counter (in most cases not even close) of the GTK.. Perhaps the WTP could periodically/frequently notify the AC of its current GTK sequence counter, and the AC would use the most recently received value in the message 3 sent to new STAs. The RSC value would not be up to date at all times, but would be closer than "0", not require an "in-the-critical-path message exchange between the AC and WTP, and still be close to the intended use of the field. Dorothy On 9/28/06, Bob O'Hara (boohara) wrote:=20 Please understand that 802.11i specifies no behavior in this area for the 802.1X authenticator. Our choice to send a group key KeyRSC value of zero in the EAPOL-key frame requires no change to 802.11i or to 802.1X . It requires us to state this in the CAPWAP spec, if we want this behavior to be consistent across all implementations. The problem with what Bechet and Saranavan are asking is that either of three different things are required:=20 1: the WTP must communicate the group key TSC to the AC every time it is updated, or 2: the AC must request the current value of the group key TSC for the KeyRSC before constructing the EAPOL-key frame, or 3: the AC must send the KCK to the AC so that it can insert the KeyRSC value and also calculate the correct MIC, inserting that into the proper EAPOL-key frame. The first item requires a tremendous amount of additional CAPWAP=20 communication between WTP and AC, at least one new CAPWAP packet for every multicast frame sent by the WTP, if the packet is not acknowledged, or two new CAPWAP packets, if it is acknowledged. This is a very expensive addition to the protocol.=20 The second item requires new protocol between the AC and WTP during what can be a time critical portion of the 802.11 transition (handoff, roam) from one WTP to another. It also introduces a race condition that is=20 not present in the protocol today. Once the value for the KeyRSC is sent from the WTP to the AC, it is possible that the WTP can send another multicast frame encrypted with the group key. This puts the value of the sequence counter out of sync with the value that will be=20 shortly communicated to the client in the EAPOL-key frame from the AC. This will behave exactly the same as if a value of zero is sent in the EAPOL-key frame. The third item requires a new architecture split that is not required in our objectives. The new split is not splitting the MAC, but splitting the authenticator. Placing the KCK in the WTP is also a potential reduction in the security of the overall WLAN system, since these devices are normally not in a secured wiring closet, but exposed and=20 more easily compromised than the AC. The simplest to implement, least expensive, and most secure option is to use the protocol as it is now specified and have the AC send a value of zero in the KeyRSC field of the EAPOL-key frame.=20 -Bob -----Original Message----- From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] Sent: Wednesday, September 27, 2006 6:50 PM To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy;=20 Peter Nilsson J (LI/EAB) Cc: capwap@frascone.com Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi Pat and all, So, based on this, I would say that we have consensus that setting the=20 correct KeyRSC is an issue for the CAPWAP protocol design. So far, we have three option/solutions: 1) As proposed by Bob: Using a static value (0) for the KeyRSC. 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP=20 3) As suggested by Saravanana: Some exchange mechanism between WTP and AC Among the three, the first option seems the easiest. However, it requires a mandated Authenticator behavior(in this case AC) that is not=20 mandated by 802.11. Therefore, we have to specify that (e.g. as proposed by Bob: "We could include a note to the effect that the group KeyRSC should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11, because otherwise there is no interoperability. For example, AC provided by another vendor does not have to set KeyRSC to 0 to be compliant with CAPWAP and 802.11i. Another implication is that we don't really understand the impact of=20 mandating a static KeyRSC value. Although Bob provided an excellent analysis, I still have some doubts about the profoundness of the impact. If the KeyRSC value is as described of no use, why would it appear in the EAPOL frames in the first place? By mandating it to static value, what have we lost? Maybe some liaison letter to 802.1 or 802.11 could provide us a better understanding of the issue. For the last two options, I think they are both within CAPWAP's scope.=20 Further analysis could help us to decide which one is better (or someone could propose other solutions). cheers Cheng Hong > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com] > Sent: Thursday, September 28, 2006 1:39 AM > To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; > Peter Nilsson J (LI/EAB) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Bob's point is 802.11i works this way today. The AP (or in=20 > this case AC) can set the RSC to whatever value it wishes. > Bob used zero (0) as an example. Implementations could use > any other value, which would require some form of > communication to the WTP, as suggested by Behcet.=20 > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Cheng Hong [mailto: Hong.Cheng@sg.panasonic.com] > > Sent: Tuesday, September 26, 2006 6:03 PM > > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson > J (LI/EAB) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > Hi Bob, > > > > If I understand your description below correct, you are proposing a=20 > > solution (to the problem pointed out by > > Saravanan) by mandating the behavior of the AC to always set the > > KeyRSC in the 4-way handshake to zero. > > > > This is not a defined behavior according to the current=20 > > 802.11 standard. > > Are you suggesting that we CAPWAP WG should specifically > mandate that > > in our CAPWAP protocol spec, e.g. something like "a CAPWAP > compatible > > AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, > > since not all AC implementation have to follow what you described. > > > > Or, are you planning to take this issue to TGm for 802.11 standard > > revision? (since based on your description, there is essentially no > > use of the KeyRSC). > > > > cheers > > > > Cheng Hong > > > >=20 > > > > > > > -----Original Message----- > > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > > > Sent: Wednesday, September 27, 2006 2:32 AM=20 > > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i=20 > > > Considerations > > > > > > Charles, Peter, > > > > > > Below is an expansion of a snippet from a thread on this > > topic that I > > > sent to the list on July 25, 2006. I think this will be=20 > helpful to > > > understand why the exchange that Saranavan is requesting is not > > > necessary. In fact, there are several systems from several > > > manufacturers in the field using precursor protocols to=20 > CAPWAP that > > > are Wi-Fi certified for WPA2/802.11i operation using the > > protocol as > > > it is described below. > > > > > > BTW, this whole discussion is about the KeyRSC for the=20 > > group key, not > > > the pairwise key. This is so because the WTP and AC both > know the > > > initial sequence counter value for the pairwise key, since it has > > > never been used to send a frame. 802.11i requires the > first frame > > > sent on a key to use the sequence counter value of 1. See > > 8.3.2.6 c) > > > and > > > 8.3.3.4.3 c) in 802.11i for this requirement. > > > > > > The same is not true of the group key, i.e., after the WTP begins > > > operation, the AC will not know the value of the sequence > > counter for=20 > > > the group key when it needs to complete the EAPOL-key > > handshake with a > > > newly associated STA. > > > However, as you will see from the tutorial below, it is not > > necessary > > > for the AC and WTP to exchange any information about the > group key > > > KeyRSC for the protocol to operate as it is intended. > > > > > > 1. A value for the KeyRSC in the EAPOL-key frame is necessary to=20 > > > calculate the KeyMIC. > > > > > > 2. This value does not need to bear any specific > > relationship to the > > > RSC value maintained by the WTP. A value of zero in the=20 > EAPOL-key > > > frame for the group key will always work. > > > > > > 3. The client STA will use the value of KeyRSC received in the > > > EAPOL-key frame to validate frame using the KeyMIC.=20 > > > > > > 4. The client STA will also set its group key RSC to the value > > > received in KeyRSC, say, zero. > > > > > > 5. The value in the client STA's RSC will be compared against the=20 > > > sequence number in subsequent received frames to identify replay > > > attacks. Any frame received with a sequence counter value > > within the > > > replay window will be checked to have a valid MIC. If the=20 > > MIC is not > > > valid, the frame is dropped. > > > > > > 6. For any frame that is determined not to be a replay > attack frame > > > and meets all other validity and authenticity requirements,=20 > > the client > > > STA updates its RSC value to the sequence number in the received > > > frame, if the value is greater than its current RSC value. > > Only the > > > AP can meet these criteria as the source of a frame=20 > received by the > > > STA. > > > > > > 7. Please see item 6, immediately above, for the reason > that the AC > > > and WTP do not need to coordinate and exchange the RSC.=20 > > > > > > > > > The only possible attack mode is for the attacker to send > frames to > > > the client STA between the time of the EAPOL-key frame and > > the first=20 > > > frame encrypted with the group key. > > > During this time, the client will receive the frame and > proceed to > > > validate its MIC. This is a potential attack against the STA=20 > > > resources. But, the MIC validation is done in the STA's > > > 802.11 chip and consumes no more resources than receiving > any other > > > frame. Thus, the attack does not actually consume any STA=20 > > resources > > > beyond those of receiving a frame. > > > > > > This attack is not unique to the use of the value zero for > > the KeyRSC, > > > either. The same attack is available to an attacker at any other=20 > > > time, as well. It is no more nor less effective at either time. > > > > > > For these reasons, the protocol is not in need of any changes to > > > address the issue raised by Saranavan.=20 > > > > > > -Bob > > > -----Original Message----- > > > From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > > > Sent: Monday, September 25, 2006 11:37 AM=20 > > > To: Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations=20 > > > > > > This is a very interesting solution. The AC selects the > KeyRSC and > > > performs the 4-way handshake. The WTP sniffs the 4-way handshake > > > traffic and grabs the KeyRSC value and uses it to=20 > > initialize its own > > > counter. > > > > > > Pat/Bob: Is this how the Cisco implementation works? I > > have to agree > > > with Saravanan that I've yet to see a technical=20 > description of how > > > Cisco implements it. > > > > > > IMHO, this is somewhat hackish, and it would be cleaner to > > have the AC > > > generate the KeyRSC and include it in the AddMobile message=20 > > as Behcet > > > suggests. > > > > > > -- > > > t. charles clancy, ph.d. | tcc@umd.edu | > www.cs.umd.edu/~clancy > > > > > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > > > > > > > I think Saravanan has a point. We did a prototype > > impelementation of=20 > > > the > > > > protocol a year ago when it was still called LWAPP. The way > > > we solved > > > > this issue then was to let the WTP sniff on all CAPWAP data > > > messages=20 > > > > from the AC and when message 3 of the 4-way handshake or > > > message 1 of > > > > the groupkey handshake was sent the WTP inserted the correct RSC > > > before=20 > > > > sending it off to the supplicant. To avoid the sniffing on > > > all CAPWAP > > > > data messages we would need a mechanism with in CAPWAP to > > > handle these=20 > > > > two messages. > > > > > > > > Peter Nilsson > > > > > > > > -----Original Message----- > > > > From: Saravanan Govindan > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > Sent: den 22 september 2006 11:03 > > > > To: Margaret Wasserman > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > Hi Margaret, > > > > > > > > Thank you for reviewing the discussion on this issue. > > > > > > > > The issue here is the working of IEEE 802.11i when the 802.11i > > > > authenticator element is at the AC and the 802.11i crypto > > element is > > > at > > > > the WTP. Particularly, it is for the 4-way handshake between=20 > > > > authenticator and supplicant. > > > > > > > > Now, the 4-way handshake requires knowing the value of > > > KeyRSC sequence > > > > counter. The KeyRSC helps both authenticator and supplicant=20 > > > keep track > > > > of their exchanges. It serves to protect against threats by > > > tracking > > > > sequential frames. The KeyRSC is maintained at the at the > > point of > > > > encryption, i.e. just before transmission over the > > wireless channel. > > > > > > > > In the case of CAPWAP, the 4-way handshake is between the AC=20 > > > > (authenticator) and the wireless station (supplicant). > > > > > > > > The problem arises, when the authenticator is at the AC and > > > the crypto > > > > element (together with KeyRSC) is at the WTP. This is a=20 > > > fairly common > > > > design. Now in this case, the AC starts the 4-way > handshake but it > > > does > > > > not know the value of the KeyRSC. The KeyRSC is maintained=20 > > > by the WTP. > > > > > > > > Based on this, the current CAPWAP specification does not > > allow for a > > > way > > > > to conduct the 4-way handshake with the correct KeyRSC.=20 > > > > > > > > The functionality I would like to see is a way for the > > authenticator > > > > (AC) to use the correct prevailing value of KeyRSC > > > (maintained by the=20 > > > > WTP) in its 4-way handshake. > > > > > > > > One way to introduce this functionality in to CAPWAP is > > to have part > > > of > > > > the 4-way handshake be sent from AC to WTP. This will allow=20 > > > the 4-way > > > > handshake to use the correct value of the KeyRSC before > > > being sent to > > > > the wireless station. > > > > > > > > I hope this helps clarify my view on the issue.=20 > > > > > > > > Cheers, > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > > > > Sent: Thursday, September 21, 2006 8:26 PM=20 > > > > To: Saravanan Govindan > > > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > > > > > > > > > Hi again, > > > > > > > > Okay, I am even more confused than I thought I was...=20 > > > > > > > > Saravanan, you wrote: > > > > > > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > > > > > >> Pat,=20 > > > >> > > > >> The issue here is about how 802.11i exchanges are done when > > > >> authenticator is at the AC and crypto elements are at > > the WTP. This=20 > > > is > > > >> the requirement. > > > > > > > > And, in response, Pat Calhoun wrote: > > > > > > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote:=20 > > > >> The current specification allows the authenticator to > > > reside in the > > > >> AC, while the data packet crypto elements in the WTP. This > > > feature is=20 > > > >> already in the specification. > > > > > > > > Pat's message matches my reading of the specification. > > > > > > > > So, Saravanan, what functionality are you asking for=20 > that is not > > > > already supported by the specification? And why do you > > think it is > > > > necessary? it will not be helpful to my understanding to > > > re-send your=20 > > > > proposal or to cite the requirements document... Please > > summarize > > > > what functionality you think is missing from the current > > > specification > > > > and why you think that functionality is necessary to=20 > support IEEE > > > > 802.11i or any important use case. > > > > > > > > At some point, the chairs may need to make a consensus > > call on this > > > > issue, and I'd like to understand your view and make sure=20 > > > that it has > > > > been clearly communicated to the WG before we ask the WG to > > > decide on > > > > this issue. > > > > > > > > Thanks,=20 > > > > Margaret > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________=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 > > > > 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 > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > >=20 > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit:=20 > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit:=20 > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap =20 > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________=20 To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap ------_=_NextPart_001_01C6E35E.F875F2C7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Bob,
 
As=20 Dorothy correctly pointed out below, setting the KeyRSC to a value = closer to the=20 current RSC would be better than setting it to a pre-defined value zero. =
 
It is=20 true that 802.11i and 802.1X do not specify what is the KeyRSC value to = be used,=20 since they are trying to provide us a tool to correctly synchronize the = RSC=20 using the Msg 3. By mandating the KeyRSC to zero, we are just disabling = the=20 tool. It is not wrong, but just deprives the system a designed=20 function.
 
As for=20 the effectiveness of KeyRSC, setting it to a predefined value of 0 would = pose a=20 greater threat. In a simple example, if the RSC is currently 1000, and = we are=20 mandating the KeyRSC to be always zero, the attacker basically can = safely=20 replay the last 1000 packets to the STA without being detected. If = the=20 KeyRSC can be set to a closer value of the current RSC, say, 900, the = number of=20 possible replayed packets can be reduced to 10 percent, 100 = packets.=20
 
Therefore, I would say, setting the KeyRSC value to zero does = place a=20 bigger threat. Is that how the cisco products implemented? Maybe you = could share=20 with us some other implementation/testing data to prove otherwise. Or, = you have=20 some other considerations that could defend the replay=20 attack?
 
cheers
 
Cheng=20 Hong
 

From: Bob O'Hara (boohara)=20 [mailto:boohara@cisco.com]
Sent: Friday, September 29, 2006 = 5:21=20 AM
To: Dorothy Stanley
Cc: Cheng Hong; Pat Calhoun = (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB);=20 capwap@frascone.com
Subject: RE: [Capwap] Issue 43 - = Explanation for=20 802.11i Considerations

Dorothy,
 
The problem with this proposal is that it is = no more=20 effective than sending a value of zero for the KeyRSC.  It = doesn't=20 eliminate any potential attacks.  It doesn't add any=20 functionality.  However, it does add cost and = complexity to the=20 protocol. 

 -Bob
 

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Thursday, September = 28, 2006=20 1:17 PM
To: Bob O'Hara (boohara)
Cc: Cheng Hong; = Pat=20 Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB);=20 capwap@frascone.com
Subject: Re: [Capwap] Issue 43 - = Explanation for=20 802.11i Considerations

All,

Below is the text from 802.11REV-maD8.0 Clause = 8.5.2,=20 describing the Key RSC field.:

"g) Key=20 RSC. This field is 8 octets in length. It contains the receive = sequence=20 counter (RSC) for the
GTK being installed in IEEE 802.11. It is = used in=20 Message 3 of the 4-Way Handshake andMessage 1 of the=20 Group Key Handshake, where it is used to synchronize the IEEE 802.11=20 replay
state. It may also be used in the Michael = MIC=20 Failure Report frame, to report the TSC field value ofthe = frame=20 experiencing a MIC failure. It shall contain 0 in other messages. The = Key RSC=20 field gives
the current message number for the GTK, = to allow a=20 STA to identify replayed MPDUs. If the KeyRSC = field value is=20 less than 8 octets in length, the remaining octets shall be set to 0. = The=20 least significant
octet of the TSC or PN should be in the = first octet=20 of the Key RSC field."

The intent of adding this value = in=20 message 3 was to immediately minimize the number of
replayed = frames that a=20 STA would potentially process: "The Key RSC field gives
the current = message=20 number for the GTK, to allow a STA to identify replayed = MPDUs."
Setting the=20 value to 0 in Msg 3 does not provide the current sequence counter (in = most=20 cases
not even close) of the GTK..

Perhaps the WTP could=20 periodically/frequently notify the AC of its current GTK sequence = counter, and=20 the
AC would use the most recently received value in the message 3 = sent to=20 new STAs. The RSC value
would not be  up to date at all times, = but=20 would be closer than "0", not require an = "in-the-critical-path
message=20 exchange between the AC and WTP, and still be close to the intended = use of the=20 field.

Dorothy

On 9/28/06, Bob O'Hara=20 (boohara) <boohara@cisco.com>=20 wrote:=20
Please=20 understand that 802.11i specifies no behavior in this area = for
the 802.1X=20 authenticator.  Our choice to send a group key KeyRSC = value
of=20 zero in the EAPOL-key frame requires no change to 802.11i or = to
802.1X=20 .  It requires us to state this in the CAPWAP spec, if we=20 want
this behavior to be consistent across all=20 implementations.

The problem with what Bechet and Saranavan = are=20 asking is that either of
three different things are required: =
1: the=20 WTP must communicate the group key TSC to the AC every time it=20 is
updated, or
2: the AC must request the current value of the = group=20 key TSC for the
KeyRSC before constructing the EAPOL-key frame, = or
3:=20 the AC must send the KCK to the AC so  that it can insert = the=20 KeyRSC
value and also calculate the correct MIC, inserting that = into the=20 proper
EAPOL-key frame.

The first item requires a = tremendous=20 amount of additional CAPWAP
communication between WTP and AC, at = least=20 one new CAPWAP packet for
every multicast frame sent by the WTP, = if the=20 packet is not
acknowledged, or two new CAPWAP packets, if it is=20 acknowledged.  This is
a very expensive addition to the = protocol.

The second item requires new protocol between the = AC and=20 WTP during what
can be a time critical portion of the 802.11 = transition=20 (handoff, roam)
from one WTP to another.  It also = introduces a=20 race condition that is
not present in the protocol=20 today.  Once the value for the KeyRSC is
sent from the = WTP to=20 the AC, it is possible that the WTP can send
another multicast = frame=20 encrypted with the group key.  This puts the
value of = the=20 sequence counter out of sync with the value that will be
shortly = communicated to the client in the EAPOL-key frame from the = AC.
This will=20 behave exactly the same as if a value of zero is sent in = the
EAPOL-key=20 frame.

The third item requires a new architecture split that = is not=20 required in
our objectives.  The new split is not = splitting=20 the MAC, but splitting
the authenticator.  Placing the = KCK in=20 the WTP is also a potential
reduction in the security of the = overall WLAN=20 system, since these
devices are normally not in a secured wiring = closet,=20 but exposed and
more easily compromised than the AC.

The = simplest=20 to implement, least expensive, and most secure option is to
use = the=20 protocol as it is now specified and have the AC send a value = of
zero in=20 the KeyRSC field of the EAPOL-key frame. =

-Bob

-----Original=20 Message-----
From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com]
Sent:=20 Wednesday, September 27, 2006 6:50 PM
To: Pat Calhoun (pacalhou); = Bob=20 O'Hara (boohara); T. Charles Clancy;
Peter Nilsson J = (LI/EAB)
Cc: capwap@frascone.com
Subject: = RE:=20 [Capwap] Issue 43 - Explanation for 802.11i Considerations

Hi = Pat and=20 all,

So, based on this, I would say that we have consensus = that=20 setting the
correct KeyRSC is an issue for the CAPWAP protocol=20 design.

So far, we have three option/solutions:

1) As = proposed=20 by Bob: Using a static value (0) for the KeyRSC.

2) As = suggested by=20 Behcet: AC communicate a correct KeyRSC to WTP

3) As = suggested by=20 Saravanana: Some exchange mechanism between WTP = and
AC

Among the=20 three, the first option seems the easiest. However, it
requires a = mandated Authenticator behavior(in this case AC) that is not =
mandated by=20 802.11. Therefore, we have to specify that (e.g. as proposed
by = Bob: "We=20 could include a note to the effect that the group KeyRSC
should = be zero=20 in the EAPOL-key frame.") either in CAPWAP or 802.11,
because = otherwise=20 there is no interoperability. For example, AC provided
by another = vendor=20 does not have to set KeyRSC to 0 to be compliant with
CAPWAP and=20 802.11i.

Another implication is that we don't really = understand the=20 impact of
mandating a static KeyRSC value. Although Bob provided = an=20 excellent
analysis, I still have some doubts about the = profoundness of=20 the impact.
If the KeyRSC value is as described of no use, why = would it=20 appear in
the EAPOL frames in the first place? By mandating it to = static=20 value,
what have we lost? Maybe some liaison letter to 802.1 or = 802.11=20 could
provide us a better understanding of the issue.

For = the last=20 two options, I think they are both within CAPWAP's scope. =
Further=20 analysis could help us to decide which one  is better=20 (or
someone could propose other = solutions).

cheers

Cheng=20 Hong







> -----Original = Message-----
>=20 From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com]
> = Sent:=20 Thursday, September 28, 2006 1:39 AM
> To: Cheng Hong; Bob = O'Hara=20 (boohara); T. Charles Clancy;
> Peter Nilsson J = (LI/EAB)
> Cc:=20 capwap@frascone.com
>=20 Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
>=20 Considerations
>
> Bob's point is 802.11i works this way = today.=20 The AP (or in
> this case AC) can set the RSC to whatever = value it=20 wishes.
> Bob used zero (0) as an example. Implementations = could=20 use
> any other value, which would require some form = of
>=20 communication to the WTP, as suggested by Behcet.
>
> = Pat=20 Calhoun
> CTO, Wireless Networking Business Unit
> Cisco = Systems
>
>
>
> > -----Original=20 Message-----
> > From: Cheng Hong [mailto:=20 Hong.Cheng@sg.panasonic.com]
> > Sent: Tuesday, = September 26,=20 2006 6:03 PM
> > To: Bob O'Hara (boohara); T. Charles = Clancy; Peter=20 Nilsson
> J (LI/EAB)
> > Cc: capwap@frascone.com
> = >=20 Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> = >=20 Considerations
> >
> > Hi Bob,
> = >
> >=20 If I understand your description below correct, you are proposing a =
>=20 > solution (to the problem pointed out by
> > Saravanan) = by=20 mandating the behavior of the AC to always set the
> > = KeyRSC in=20 the 4-way handshake to zero.
> >
> > This is not a = defined=20 behavior according to the current
> > 802.11 = standard.
>=20 > Are you suggesting that we CAPWAP WG should = specifically
>=20 mandate that
> > in our CAPWAP protocol spec, e.g. = something like=20 "a CAPWAP
> compatible
> > AC MUST set KeyRSC to = zero"?=20 Otherwise, the problem still exists,
> > since not all AC=20 implementation have to follow what you described.
> = >
> >=20 Or, are you planning to take this issue to TGm for 802.11 = standard
>=20 > revision? (since based on your description, there is = essentially=20 no
> > use of the KeyRSC).
> >
> > = cheers
>=20 >
> > Cheng Hong
> >
> >
> = >
>=20 >
> > > -----Original Message-----
> > > = From:=20 Bob O'Hara (boohara) [mailto:boohara@cisco.com]
> = > >=20 Sent: Wednesday, September 27, 2006 2:32 AM
> > > To: = T.=20 Charles Clancy; Peter Nilsson J (LI/EAB)
> > > Cc: capwap@frascone.com
> = > >=20 Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> = > >=20 Considerations
> > >
> > > Charles, = Peter,
>=20 > >
> > > Below is an expansion of a snippet from = a thread=20 on this
> > topic that I
> > > sent to the list = on July=20 25, 2006.  I think this will be
> helpful = to
> >=20 > understand why the exchange that Saranavan is requesting is = not
>=20 > > necessary.  In fact, there are several systems = from=20 several
> > > manufacturers in the field using precursor = protocols to
> CAPWAP that
> > > are Wi-Fi = certified for=20 WPA2/802.11i operation using the
> > protocol as
> = > >=20 it is described below.
> > >
> > > BTW, this = whole=20 discussion is about the KeyRSC for the
> > group key, = not
>=20 > > the pairwise key.  This is so because the WTP = and AC=20 both
> know the
> > > initial sequence counter = value for=20 the pairwise key, since it has
> > > never been used to = send a=20 frame.   802.11i requires the
> first frame
> = >=20 > sent on a key to use the sequence counter value of=20 1.  See
> > 8.3.2.6=20 c)
> > > and
> > > 8.3.3.4.3 c) in 802.11i = for this=20 requirement.
> > >
> > > The same is not = true of the=20 group key, i.e., after the WTP begins
> > > operation, = the AC=20 will not know the value of the sequence
> > counter for =
>=20 > > the group key when it needs to complete the = EAPOL-key
> >=20 handshake with a
> > > newly associated STA.
> = > >=20 However, as you will see from the tutorial below, it is not
> = >=20 necessary
> > > for the AC and WTP to exchange any = information=20 about the
> group key
> > > KeyRSC for the = protocol to=20 operate as it is intended.
> > >
> > > 1. A = value=20 for the KeyRSC in the EAPOL-key frame is necessary to
> > = >=20 calculate the KeyMIC.
> > >
> > > 2. This = value does=20 not need to bear any specific
> > relationship to = the
> >=20 > RSC value maintained by the WTP.  A value of zero in = the=20
> EAPOL-key
> > > frame for the group key will = always=20 work.
> > >
> > > 3. The client STA will use = the=20 value of KeyRSC received in the
> > > EAPOL-key frame to = validate frame using the KeyMIC.
> > >
> > = > 4. The=20 client STA will also set its group key RSC to the value
> > = >=20 received in KeyRSC, say, zero.
> > >
> > > = 5. The=20 value in the client STA's RSC will be compared against the
> = >=20 > sequence number in subsequent received frames to identify=20 replay
> > > attacks.  Any frame received with = a=20 sequence counter value
> > within the
> > > = replay=20 window will be checked to have a valid MIC.  If the =
> >=20 MIC is not
> > > valid, the frame is dropped.
> = >=20 >
> > > 6. For any frame that is determined not to be = a=20 replay
> attack frame
> > > and meets all other = validity=20 and authenticity requirements,
> > the client
> > = >=20 STA updates its RSC value to the sequence number in the = received
>=20 > > frame, if the value is greater than its current RSC = value.
>=20 > Only the
> > > AP can meet these criteria as the = source of=20 a frame
> received by the
> > > STA.
> > = >
> > > 7. Please see item 6, immediately above, for = the=20 reason
> that the AC
> > > and WTP do not need to=20 coordinate and exchange the RSC.
> > >
> >=20 >
> > > The only possible attack mode is for the = attacker to=20 send
> frames to
> > > the client STA between the = time of=20 the EAPOL-key frame and
> > the first
> > > = frame=20 encrypted with the group key.
> > > During this time, = the client=20 will receive the frame and
> proceed to
> > > = validate its=20 MIC.  This is a potential attack against the STA
> = >=20 > resources.  But, the MIC validation is done in the=20 STA's
> > > 802.11 chip and consumes no more resources = than=20 receiving
> any other
> > > = frame.  Thus, the=20 attack does not actually consume any STA
> > = resources
>=20 > > beyond those of receiving a frame.
> > = >
> >=20 > This attack is not unique to the use of the value zero = for
> >=20 the KeyRSC,
> > > either.  The same attack is=20 available to an attacker at any other
> > > time, as=20 well.  It is no more nor less effective at either = time.
>=20 > >
> > > For these reasons, the protocol is not = in need=20 of any changes to
> > > address the issue raised by = Saranavan.=20
> > >
> > >  -Bob
> > = >=20 -----Original Message-----
> > > From: T. Charles Clancy = [mailto:clancy@cs.umd.edu]
>=20 > > Sent: Monday, September 25, 2006 11:37 AM
> > = > To:=20 Peter Nilsson J (LI/EAB)
> > > Cc: capwap@frascone.com
> = > >=20 Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> = > >=20 Considerations
> > >
> > > This is a very=20 interesting solution.  The AC selects the
> KeyRSC=20 and
> > > performs the 4-way handshake.  The = WTP=20 sniffs the 4-way handshake
> > > traffic and grabs the = KeyRSC=20 value and uses it to
> > initialize its own
> > = >=20 counter.
> > >
> > > Pat/Bob: Is this how = the Cisco=20 implementation works?  I
> > have to = agree
> >=20 > with Saravanan that I've yet to see a technical
> = description of=20 how
> > > Cisco implements it.
> > >
> = >=20 > IMHO, this is somewhat hackish, and it would be cleaner = to
> >=20 have the AC
> > > generate the KeyRSC and include it in = the=20 AddMobile message
> > as Behcet
> > >=20 suggests.
> > >
> > > --
> > > = t.=20 charles clancy, ph.d.  |  tcc@umd.edu  |
> www.cs.umd.edu/~clancy
>= >=20 >
> > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) = wrote:
> > >
> > > > I think Saravanan = has a=20 point. We did a prototype
> > impelementation of
> = > >=20 the
> > > > protocol a year ago when it was still = called=20 LWAPP. The way
> > > we solved
> > > > = this issue=20 then was to let the WTP sniff on all CAPWAP data
> > > = messages=20
> > > > from the AC and when message 3 of the 4-way=20 handshake or
> > > message 1 of
> > > > = the=20 groupkey handshake was sent the WTP inserted the correct RSC
> = >=20 > before
> > > > sending it off to the = supplicant. To=20 avoid the sniffing on
> > > all CAPWAP
> > > = >=20 data messages we would need a mechanism with in CAPWAP to
> = > >=20 handle these
> > > > two messages.
> > > = >
> > > > Peter Nilsson
> > > = >
>=20 > > > -----Original Message-----
> > > > = From:=20 Saravanan Govindan
> > > [mailto:Saravanan.Govindan@sg= .panasonic.com]
>=20 > > > Sent: den 22 september 2006 11:03
> > > = > To:=20 Margaret Wasserman
> > > > Cc: capwap@frascone.com
> = > >=20 > Subject: Re: [Capwap] Issue 43 - Explanation for = 802.11i
> >=20 > Considerations
> > > >
> > > > Hi = Margaret,
> > > >
> > > > Thank you = for=20 reviewing the discussion on this issue.
> > > = >
> >=20 > > The issue here is the working of IEEE 802.11i when the=20 802.11i
> > > > authenticator element is at the AC = and the=20 802.11i crypto
> > element is
> > > at
> = >=20 > > the WTP. Particularly, it is for the 4-way handshake = between=20
> > > > authenticator and supplicant.
> > = >=20 >
> > > > Now, the 4-way handshake requires = knowing the=20 value of
> > > KeyRSC sequence
> > > > = counter.=20 The KeyRSC helps both authenticator and supplicant
> > = > keep=20 track
> > > > of their exchanges. It serves to = protect=20 against threats by
> > > tracking
> > > > = sequential frames. The KeyRSC is maintained at the at the
> = > point=20 of
> > > > encryption, i.e. just before transmission = over=20 the
> > wireless channel.
> > > >
> = > >=20 > In the case of CAPWAP, the 4-way handshake is between the AC =
>=20 > > > (authenticator) and the wireless station=20 (supplicant).
> > > >
> > > > The = problem=20 arises, when the authenticator is at the AC and
> > > = the=20 crypto
> > > > element (together with KeyRSC) is at = the WTP.=20 This is a
> > > fairly common
> > > > = design.=20 Now in this case, the AC starts the 4-way
> handshake but = it
>=20 > > does
> > > > not know the value of the = KeyRSC. The=20 KeyRSC is maintained
> > > by the WTP.
> > = >=20 >
> > > > Based on this, the current CAPWAP = specification=20 does not
> > allow for a
> > > way
> > = >=20 > to conduct the 4-way handshake with the correct KeyRSC. =
> >=20 > >
> > > > The functionality I would like to = see is a=20 way for the
> > authenticator
> > > > (AC) = to use=20 the correct prevailing value of KeyRSC
> > > (maintained = by the=20
> > > > WTP) in its 4-way handshake.
> > = >=20 >
> > > > One way to introduce this functionality = in to=20 CAPWAP is
> > to have part
> > > of
> = > >=20 > the 4-way handshake be sent from AC to WTP. This will allow =
>=20 > > the 4-way
> > > > handshake to use the = correct=20 value of the KeyRSC before
> > > being sent to
> = > >=20 > the wireless station.
> > > >
> > > = > I=20 hope this helps clarify my view on the issue.
> > >=20 >
> > > > Cheers,
> > > >
> = > >=20 > Saravanan
> > > >
> > > >
> = >=20 > >
> > > >
> > > >
> = > >=20 >
> > > > -----Original Message-----
> > = >=20 > From: Margaret Wasserman [mailto:margaret@thingmagic.com]
&= gt;=20 > > > Sent: Thursday, September 21, 2006 8:26 PM
> = > >=20 > To: Saravanan Govindan
> > > > Cc: Pat Calhoun=20 (pacalhou); capwap@frascone.com
> = > >=20 > Subject: Re: [Capwap] Issue 43 - Explanation for = 802.11i
> >=20 > Considerations
> > > >
> > > = >
>=20 > > >
> > > > Hi again,
> > >=20 >
> > > > Okay, I am even more confused than I = thought I=20 was...
> > > >
> > > > Saravanan, you = wrote:
> > > >
> > > > On Sep 17, = 2006, at=20 10:24 PM, Saravanan Govindan wrote:
> > > >
> = > >=20 >> Pat,
> > > >>
> > > >> = The=20 issue here is about how 802.11i exchanges are done when
> > = >=20 >> authenticator is at the AC and crypto elements are = at
> >=20 the WTP. This
> > > is
> > > >> the=20 requirement.
> > > >
> > > > And, in = response,=20 Pat Calhoun wrote:
> > > >
> > > > On = Sep 18,=20 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote:
> > > = >>=20 The current specification allows the authenticator to
> > = >=20 reside in the
> > > >> AC, while the data packet = crypto=20 elements in the WTP. This
> > > feature is
> > = >=20 >> already in the specification.
> > > = >
> >=20 > > Pat's message matches my reading of the = specification.
>=20 > > >
> > > > So, Saravanan, what = functionality are=20 you asking for
> that is not
> > > > already = supported=20 by the specification?  And why do you
> > think = it=20 is
> > > > necessary?  it will not be = helpful to my=20 understanding to
> > > re-send your
> > > = >=20 proposal or to cite the requirements = document...  Please
>=20 > summarize
> > > > what functionality you think = is=20 missing from the current
> > > specification
> = > >=20 > and why you think that functionality is necessary to
> = support=20 IEEE
> > > > 802.11i or any important use = case.
> >=20 > >
> > > > At some point, the chairs may need = to make=20 a consensus
> > call on this
> > > > issue, = and I'd=20 like to understand your view and make sure
> > > that = it=20 has
> > > > been clearly communicated to the WG = before we ask=20 the WG to
> > > decide on
> > > > this=20 issue.
> > > >
> > > > Thanks, =
> >=20 > > Margaret
> > > >
> > > = >
>=20 > > >
> > > >
> > > >
> = >=20 > >
> > > >
>=20 _________________________________________________________________ =
>=20 > > > To unsubscribe or modify your subscription = options,
>=20 please visit:
> > > > http://lists.f= rascone.com/mailman/listinfo/capwap=20
> > > >
> > > > Archives: http://lists.frascone= .com/pipermail/capwap
>=20 > > >
>=20 _________________________________________________________________ =
>=20 > > > To unsubscribe or modify your subscription = options,
>=20 please visit:
> > > > http://lists.f= rascone.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.f= rascone.com/mailman/listinfo/capwap
>=20 > >
> > > Archives: http://lists.frascone= .com/pipermail/capwap
>=20 > >=20 = _________________________________________________________________
>= =20 > > To unsubscribe or modify your subscription options, please = visit:=20
> > > http://lists.f= rascone.com/mailman/listinfo/capwap
>=20 > >
> > > Archives: http://lists.frascone= .com/pipermail/capwap
>=20 > >
> >=20 = _________________________________________________________________
>= =20 > To unsubscribe or modify your subscription options, please = visit:=20
> > http://lists.f= rascone.com/mailman/listinfo/capwap
>=20 >
> > Archives: http://lists.frascone= .com/pipermail/capwap=20
> >
>=20 = _________________________________________________________________
>= To=20 unsubscribe or modify your subscription options, please = visit:
> http://lists.f= rascone.com/mailman/listinfo/capwap
>
>=20 Archives: http://lists.frascone= .com/pipermail/capwap
>
____________________________________= _____________________________=20
To unsubscribe or modify your subscription options, please = visit:
http://lists.f= rascone.com/mailman/listinfo/capwap

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

<= /HTML> ------_=_NextPart_001_01C6E35E.F875F2C7-- --===============1123308397== 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 --===============1123308397==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Sep 28 21:04:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT6nT-0005ev-IJ for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 21:04:11 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT6nQ-0004am-3K for capwap-archive@lists.ietf.org; Thu, 28 Sep 2006 21:04:11 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 47C421448045 for ; Thu, 28 Sep 2006 18:04:03 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 9A21C43005F for ; Thu, 28 Sep 2006 17:42:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8AD5F398027 for ; Thu, 28 Sep 2006 17:42:40 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id C06BD398016 for ; Thu, 28 Sep 2006 17:42:37 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id k8T0gMls015965; Fri, 29 Sep 2006 09:42:22 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k8T0gN320938; Fri, 29 Sep 2006 09:42:23 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with SMTP id k8T0gNd03443; Fri, 29 Sep 2006 09:42:23 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Sep 2006 08:41:12 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F1F83@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbjOwaBxAxmTegASwKjGKmQD0OreAAB7o8QAAZYQgAAANHloA== From: "Saravanan Govindan" To: "Cheng Hong" , "Bob O'Hara (boohara)" , "Dorothy Stanley" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.591 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_40_50, HTML_MESSAGE, NORMAL_HTTP_TO_IP X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0096241993==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: f32befa15ef81303d41972a1284d3814 This is a multi-part message in MIME format. --===============0096241993== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E35F.FA7C3D0A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E35F.FA7C3D0A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Cheng Hong, Following from your note, there seem to be too many holes in the proposal to set a pre-established value to KeyRSC. I suggest we move forward by considering alternatives to this issue.=20 =20 Cheers, Saravanan =20 =20 =20 =20 _____ =20 From: Cheng Hong=20 Sent: Friday, September 29, 2006 8:34 AM To: Bob O'Hara (boohara); Dorothy Stanley Cc: Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com; Saravanan Govindan Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations =20 Hi Bob, =20 As Dorothy correctly pointed out below, setting the KeyRSC to a value closer to the current RSC would be better than setting it to a pre-defined value zero.=20 =20 It is true that 802.11i and 802.1X do not specify what is the KeyRSC value to be used, since they are trying to provide us a tool to correctly synchronize the RSC using the Msg 3. By mandating the KeyRSC to zero, we are just disabling the tool. It is not wrong, but just deprives the system a designed function. =20 As for the effectiveness of KeyRSC, setting it to a predefined value of 0 would pose a greater threat. In a simple example, if the RSC is currently 1000, and we are mandating the KeyRSC to be always zero, the attacker basically can safely replay the last 1000 packets to the STA without being detected. If the KeyRSC can be set to a closer value of the current RSC, say, 900, the number of possible replayed packets can be reduced to 10 percent, 100 packets.=20 =20 Therefore, I would say, setting the KeyRSC value to zero does place a bigger threat. Is that how the cisco products implemented? Maybe you could share with us some other implementation/testing data to prove otherwise. Or, you have some other considerations that could defend the replay attack? =20 cheers =20 Cheng Hong =20 =20 _____ =20 From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Friday, September 29, 2006 5:21 AM To: Dorothy Stanley Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations Dorothy, =20 The problem with this proposal is that it is no more effective than sending a value of zero for the KeyRSC. It doesn't eliminate any potential attacks. It doesn't add any functionality. However, it does add cost and complexity to the protocol. =20 -Bob =20 =20 =20 _____ =20 From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Thursday, September 28, 2006 1:17 PM To: Bob O'Hara (boohara) Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations All, Below is the text from 802.11REV-maD8.0 Clause 8.5.2, describing the Key RSC field.: "g) Key RSC. This field is 8 octets in length. It contains the receive sequence counter (RSC) for the GTK being installed in IEEE 802.11. It is used in Message 3 of the 4-Way Handshake and Message 1 of the Group Key Handshake, where it is used to synchronize the IEEE 802.11 replay state. It may also be used in the Michael MIC Failure Report frame, to report the TSC field value of the frame experiencing a MIC failure. It shall contain 0 in other messages. The Key RSC field gives the current message number for the GTK, to allow a STA to identify replayed MPDUs. If the Key RSC field value is less than 8 octets in length, the remaining octets shall be set to 0. The least significant octet of the TSC or PN should be in the first octet of the Key RSC field." The intent of adding this value in message 3 was to immediately minimize the number of=20 replayed frames that a STA would potentially process: "The Key RSC field gives the current message number for the GTK, to allow a STA to identify replayed MPDUs." Setting the value to 0 in Msg 3 does not provide the current sequence counter (in most cases not even close) of the GTK.. Perhaps the WTP could periodically/frequently notify the AC of its current GTK sequence counter, and the AC would use the most recently received value in the message 3 sent to new STAs. The RSC value would not be up to date at all times, but would be closer than "0", not require an "in-the-critical-path message exchange between the AC and WTP, and still be close to the intended use of the field. Dorothy On 9/28/06, Bob O'Hara (boohara) wrote:=20 Please understand that 802.11i specifies no behavior in this area for the 802.1X authenticator. Our choice to send a group key KeyRSC value of zero in the EAPOL-key frame requires no change to 802.11i or to 802.1X . It requires us to state this in the CAPWAP spec, if we want this behavior to be consistent across all implementations. The problem with what Bechet and Saranavan are asking is that either of three different things are required:=20 1: the WTP must communicate the group key TSC to the AC every time it is updated, or 2: the AC must request the current value of the group key TSC for the KeyRSC before constructing the EAPOL-key frame, or 3: the AC must send the KCK to the AC so that it can insert the KeyRSC value and also calculate the correct MIC, inserting that into the proper EAPOL-key frame. The first item requires a tremendous amount of additional CAPWAP=20 communication between WTP and AC, at least one new CAPWAP packet for every multicast frame sent by the WTP, if the packet is not acknowledged, or two new CAPWAP packets, if it is acknowledged. This is a very expensive addition to the protocol.=20 The second item requires new protocol between the AC and WTP during what can be a time critical portion of the 802.11 transition (handoff, roam) from one WTP to another. It also introduces a race condition that is=20 not present in the protocol today. Once the value for the KeyRSC is sent from the WTP to the AC, it is possible that the WTP can send another multicast frame encrypted with the group key. This puts the value of the sequence counter out of sync with the value that will be=20 shortly communicated to the client in the EAPOL-key frame from the AC. This will behave exactly the same as if a value of zero is sent in the EAPOL-key frame. The third item requires a new architecture split that is not required in our objectives. The new split is not splitting the MAC, but splitting the authenticator. Placing the KCK in the WTP is also a potential reduction in the security of the overall WLAN system, since these devices are normally not in a secured wiring closet, but exposed and=20 more easily compromised than the AC. The simplest to implement, least expensive, and most secure option is to use the protocol as it is now specified and have the AC send a value of zero in the KeyRSC field of the EAPOL-key frame.=20 -Bob -----Original Message----- From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] Sent: Wednesday, September 27, 2006 6:50 PM To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy;=20 Peter Nilsson J (LI/EAB) Cc: capwap@frascone.com Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi Pat and all, So, based on this, I would say that we have consensus that setting the=20 correct KeyRSC is an issue for the CAPWAP protocol design. So far, we have three option/solutions: 1) As proposed by Bob: Using a static value (0) for the KeyRSC. 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP=20 3) As suggested by Saravanana: Some exchange mechanism between WTP and AC Among the three, the first option seems the easiest. However, it requires a mandated Authenticator behavior(in this case AC) that is not=20 mandated by 802.11. Therefore, we have to specify that (e.g. as proposed by Bob: "We could include a note to the effect that the group KeyRSC should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11, because otherwise there is no interoperability. For example, AC provided by another vendor does not have to set KeyRSC to 0 to be compliant with CAPWAP and 802.11i. Another implication is that we don't really understand the impact of=20 mandating a static KeyRSC value. Although Bob provided an excellent analysis, I still have some doubts about the profoundness of the impact. If the KeyRSC value is as described of no use, why would it appear in the EAPOL frames in the first place? By mandating it to static value, what have we lost? Maybe some liaison letter to 802.1 or 802.11 could provide us a better understanding of the issue. For the last two options, I think they are both within CAPWAP's scope.=20 Further analysis could help us to decide which one is better (or someone could propose other solutions). cheers Cheng Hong > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com] > Sent: Thursday, September 28, 2006 1:39 AM > To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; > Peter Nilsson J (LI/EAB) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Bob's point is 802.11i works this way today. The AP (or in=20 > this case AC) can set the RSC to whatever value it wishes. > Bob used zero (0) as an example. Implementations could use > any other value, which would require some form of > communication to the WTP, as suggested by Behcet.=20 > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Cheng Hong [mailto: Hong.Cheng@sg.panasonic.com] > > Sent: Tuesday, September 26, 2006 6:03 PM > > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson > J (LI/EAB) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > Hi Bob, > > > > If I understand your description below correct, you are proposing a=20 > > solution (to the problem pointed out by > > Saravanan) by mandating the behavior of the AC to always set the > > KeyRSC in the 4-way handshake to zero. > > > > This is not a defined behavior according to the current=20 > > 802.11 standard. > > Are you suggesting that we CAPWAP WG should specifically > mandate that > > in our CAPWAP protocol spec, e.g. something like "a CAPWAP > compatible > > AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, > > since not all AC implementation have to follow what you described. > > > > Or, are you planning to take this issue to TGm for 802.11 standard > > revision? (since based on your description, there is essentially no > > use of the KeyRSC). > > > > cheers > > > > Cheng Hong > > > >=20 > > > > > > > -----Original Message----- > > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > > > Sent: Wednesday, September 27, 2006 2:32 AM=20 > > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i=20 > > > Considerations > > > > > > Charles, Peter, > > > > > > Below is an expansion of a snippet from a thread on this > > topic that I > > > sent to the list on July 25, 2006. I think this will be=20 > helpful to > > > understand why the exchange that Saranavan is requesting is not > > > necessary. In fact, there are several systems from several > > > manufacturers in the field using precursor protocols to=20 > CAPWAP that > > > are Wi-Fi certified for WPA2/802.11i operation using the > > protocol as > > > it is described below. > > > > > > BTW, this whole discussion is about the KeyRSC for the=20 > > group key, not > > > the pairwise key. This is so because the WTP and AC both > know the > > > initial sequence counter value for the pairwise key, since it has > > > never been used to send a frame. 802.11i requires the > first frame > > > sent on a key to use the sequence counter value of 1. See > > 8.3.2.6 c) > > > and > > > 8.3.3.4.3 c) in 802.11i for this requirement. > > > > > > The same is not true of the group key, i.e., after the WTP begins > > > operation, the AC will not know the value of the sequence > > counter for=20 > > > the group key when it needs to complete the EAPOL-key > > handshake with a > > > newly associated STA. > > > However, as you will see from the tutorial below, it is not > > necessary > > > for the AC and WTP to exchange any information about the > group key > > > KeyRSC for the protocol to operate as it is intended. > > > > > > 1. A value for the KeyRSC in the EAPOL-key frame is necessary to=20 > > > calculate the KeyMIC. > > > > > > 2. This value does not need to bear any specific > > relationship to the > > > RSC value maintained by the WTP. A value of zero in the=20 > EAPOL-key > > > frame for the group key will always work. > > > > > > 3. The client STA will use the value of KeyRSC received in the > > > EAPOL-key frame to validate frame using the KeyMIC.=20 > > > > > > 4. The client STA will also set its group key RSC to the value > > > received in KeyRSC, say, zero. > > > > > > 5. The value in the client STA's RSC will be compared against the=20 > > > sequence number in subsequent received frames to identify replay > > > attacks. Any frame received with a sequence counter value > > within the > > > replay window will be checked to have a valid MIC. If the=20 > > MIC is not > > > valid, the frame is dropped. > > > > > > 6. For any frame that is determined not to be a replay > attack frame > > > and meets all other validity and authenticity requirements,=20 > > the client > > > STA updates its RSC value to the sequence number in the received > > > frame, if the value is greater than its current RSC value. > > Only the > > > AP can meet these criteria as the source of a frame=20 > received by the > > > STA. > > > > > > 7. Please see item 6, immediately above, for the reason > that the AC > > > and WTP do not need to coordinate and exchange the RSC.=20 > > > > > > > > > The only possible attack mode is for the attacker to send > frames to > > > the client STA between the time of the EAPOL-key frame and > > the first=20 > > > frame encrypted with the group key. > > > During this time, the client will receive the frame and > proceed to > > > validate its MIC. This is a potential attack against the STA=20 > > > resources. But, the MIC validation is done in the STA's > > > 802.11 chip and consumes no more resources than receiving > any other > > > frame. Thus, the attack does not actually consume any STA=20 > > resources > > > beyond those of receiving a frame. > > > > > > This attack is not unique to the use of the value zero for > > the KeyRSC, > > > either. The same attack is available to an attacker at any other=20 > > > time, as well. It is no more nor less effective at either time. > > > > > > For these reasons, the protocol is not in need of any changes to > > > address the issue raised by Saranavan.=20 > > > > > > -Bob > > > -----Original Message----- > > > From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > > > Sent: Monday, September 25, 2006 11:37 AM=20 > > > To: Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations=20 > > > > > > This is a very interesting solution. The AC selects the > KeyRSC and > > > performs the 4-way handshake. The WTP sniffs the 4-way handshake > > > traffic and grabs the KeyRSC value and uses it to=20 > > initialize its own > > > counter. > > > > > > Pat/Bob: Is this how the Cisco implementation works? I > > have to agree > > > with Saravanan that I've yet to see a technical=20 > description of how > > > Cisco implements it. > > > > > > IMHO, this is somewhat hackish, and it would be cleaner to > > have the AC > > > generate the KeyRSC and include it in the AddMobile message=20 > > as Behcet > > > suggests. > > > > > > -- > > > t. charles clancy, ph.d. | tcc@umd.edu | > www.cs.umd.edu/~clancy > > > > > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > > > > > > > I think Saravanan has a point. We did a prototype > > impelementation of=20 > > > the > > > > protocol a year ago when it was still called LWAPP. The way > > > we solved > > > > this issue then was to let the WTP sniff on all CAPWAP data > > > messages=20 > > > > from the AC and when message 3 of the 4-way handshake or > > > message 1 of > > > > the groupkey handshake was sent the WTP inserted the correct RSC > > > before=20 > > > > sending it off to the supplicant. To avoid the sniffing on > > > all CAPWAP > > > > data messages we would need a mechanism with in CAPWAP to > > > handle these=20 > > > > two messages. > > > > > > > > Peter Nilsson > > > > > > > > -----Original Message----- > > > > From: Saravanan Govindan > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > Sent: den 22 september 2006 11:03 > > > > To: Margaret Wasserman > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > Hi Margaret, > > > > > > > > Thank you for reviewing the discussion on this issue. > > > > > > > > The issue here is the working of IEEE 802.11i when the 802.11i > > > > authenticator element is at the AC and the 802.11i crypto > > element is > > > at > > > > the WTP. Particularly, it is for the 4-way handshake between=20 > > > > authenticator and supplicant. > > > > > > > > Now, the 4-way handshake requires knowing the value of > > > KeyRSC sequence > > > > counter. The KeyRSC helps both authenticator and supplicant=20 > > > keep track > > > > of their exchanges. It serves to protect against threats by > > > tracking > > > > sequential frames. The KeyRSC is maintained at the at the > > point of > > > > encryption, i.e. just before transmission over the > > wireless channel. > > > > > > > > In the case of CAPWAP, the 4-way handshake is between the AC=20 > > > > (authenticator) and the wireless station (supplicant). > > > > > > > > The problem arises, when the authenticator is at the AC and > > > the crypto > > > > element (together with KeyRSC) is at the WTP. This is a=20 > > > fairly common > > > > design. Now in this case, the AC starts the 4-way > handshake but it > > > does > > > > not know the value of the KeyRSC. The KeyRSC is maintained=20 > > > by the WTP. > > > > > > > > Based on this, the current CAPWAP specification does not > > allow for a > > > way > > > > to conduct the 4-way handshake with the correct KeyRSC.=20 > > > > > > > > The functionality I would like to see is a way for the > > authenticator > > > > (AC) to use the correct prevailing value of KeyRSC > > > (maintained by the=20 > > > > WTP) in its 4-way handshake. > > > > > > > > One way to introduce this functionality in to CAPWAP is > > to have part > > > of > > > > the 4-way handshake be sent from AC to WTP. This will allow=20 > > > the 4-way > > > > handshake to use the correct value of the KeyRSC before > > > being sent to > > > > the wireless station. > > > > > > > > I hope this helps clarify my view on the issue.=20 > > > > > > > > Cheers, > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > > > > Sent: Thursday, September 21, 2006 8:26 PM=20 > > > > To: Saravanan Govindan > > > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > > > > > > > > > Hi again, > > > > > > > > Okay, I am even more confused than I thought I was...=20 > > > > > > > > Saravanan, you wrote: > > > > > > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > > > > > >> Pat,=20 > > > >> > > > >> The issue here is about how 802.11i exchanges are done when > > > >> authenticator is at the AC and crypto elements are at > > the WTP. This=20 > > > is > > > >> the requirement. > > > > > > > > And, in response, Pat Calhoun wrote: > > > > > > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote:=20 > > > >> The current specification allows the authenticator to > > > reside in the > > > >> AC, while the data packet crypto elements in the WTP. This > > > feature is=20 > > > >> already in the specification. > > > > > > > > Pat's message matches my reading of the specification. > > > > > > > > So, Saravanan, what functionality are you asking for=20 > that is not > > > > already supported by the specification? And why do you > > think it is > > > > necessary? it will not be helpful to my understanding to > > > re-send your=20 > > > > proposal or to cite the requirements document... Please > > summarize > > > > what functionality you think is missing from the current > > > specification > > > > and why you think that functionality is necessary to=20 > support IEEE > > > > 802.11i or any important use case. > > > > > > > > At some point, the chairs may need to make a consensus > > call on this > > > > issue, and I'd like to understand your view and make sure=20 > > > that it has > > > > been clearly communicated to the WG before we ask the WG to > > > decide on > > > > this issue. > > > > > > > > Thanks,=20 > > > > Margaret > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________=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 > > > > 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 > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > >=20 > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit:=20 > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit:=20 > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap=20 > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________=20 To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap =20 ------_=_NextPart_001_01C6E35F.FA7C3D0A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Cheng = Hong,


Following from your note, there seem to be too many holes in the = proposal to set a pre-established value to KeyRSC. I suggest we move forward by = considering alternatives to this issue.

 

Cheers,

=


Saravanan

 

 

 

 

From: Cheng = Hong
Sent: Friday, September = 29, 2006 8:34 AM
To: Bob O'Hara (boohara); Dorothy Stanley
Cc: Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com; Saravanan Govindan
Subject: RE: [Capwap] = Issue 43 - Explanation for 802.11i Considerations

 

Hi = Bob,

 

As Dorothy correctly pointed out = below, setting the KeyRSC to a value closer to the current RSC would be better = than setting it to a pre-defined value zero.

 

It is true that 802.11i and 802.1X = do not specify what is the KeyRSC value to be used, since they are trying to = provide us a tool to correctly synchronize the RSC using the Msg 3. By mandating = the KeyRSC to zero, we are just disabling the tool. It is not wrong, but = just deprives the system a designed function.

 

As for the effectiveness of KeyRSC, setting it to a predefined value of 0 would pose a greater threat. In a = simple example, if the RSC is currently 1000, and we are mandating the KeyRSC = to be always zero, the attacker basically can safely replay the last 1000 packets to the STA without being detected. If the KeyRSC can be set = to a closer value of the current RSC, say, 900, the number of = possible replayed packets can be reduced to 10 percent, 100 packets. =

 

Therefore, I would say, setting the = KeyRSC value to zero does place a bigger threat. Is that how the cisco products implemented? Maybe you could share with us some other = implementation/testing data to prove otherwise. Or, you have some other considerations that = could defend the replay attack?

 

cheers

 

Cheng = Hong

 

 

From: Bob O'Hara (boohara) = [mailto:boohara@cisco.com]
Sent: Friday, September = 29, 2006 5:21 AM
To: Dorothy Stanley
Cc: Cheng Hong; = Pat Calhoun (pacalhou); T. Charles Clancy; = Peter Nilsson J (LI/EAB); capwap@frascone.com
Subject: RE: [Capwap] = Issue 43 - Explanation for 802.11i Considerations

Dorothy,

 

The problem with this proposal is = that it is no more effective than sending a value of zero for the = KeyRSC.  It doesn't eliminate any potential attacks.  It doesn't add any functionality.  However, it does add cost and complexity = to the protocol. 

 -Bob
 

 

 

From: Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Thursday, September = 28, 2006 1:17 PM
To: Bob O'Hara (boohara)
Cc: Cheng Hong; = Pat Calhoun (pacalhou); T. Charles Clancy; = Peter Nilsson J (LI/EAB); capwap@frascone.com
Subject: Re: [Capwap] = Issue 43 - Explanation for 802.11i Considerations

All,

Below is the text from 802.11REV-maD8.0 Clause 8.5.2, describing the Key = RSC field.:

"g) Key RSC. This field is 8 = octets in length. It contains the receive sequence counter (RSC) for the
GTK being installed in IEEE 802.11. It is used in Message 3 of the 4-Way Handshake and
Message 1 of the Group Key Handshake, where it is used to synchronize = the IEEE 802.11 replay
state. It may also be used in the Michael MIC Failure Report frame, to = report the TSC field value of
the frame experiencing a MIC failure. It shall contain 0 in other = messages. The Key RSC field gives
the current message number for the GTK, to allow a STA to identify = replayed MPDUs. If the Key
RSC field value is less than 8 octets in length, the remaining octets = shall be set to 0. The least significant
octet of the TSC or PN should be in the first octet of the Key RSC = field."

The intent of adding this value in message 3 was to immediately minimize = the number of
replayed frames that a STA would potentially process: "The Key RSC = field gives
the current message number for the GTK, to allow a STA to identify = replayed MPDUs."
Setting the value to 0 in Msg 3 does not provide the current sequence = counter (in most cases
not even close) of the GTK..

Perhaps the WTP could periodically/frequently notify the AC of its = current GTK sequence counter, and the
AC would use the most recently received value in the message 3 sent to = new STAs. The RSC value
would not be  up to date at all times, but would be closer than "0", not require an "in-the-critical-path
message exchange between the AC and WTP, and still be close to the = intended use of the field.

Dorothy

On 9/28/06, Bob = O'Hara (boohara) <boohara@cisco.com> = wrote:

Please understand that 802.11i specifies no behavior in this = area for
the 802.1X authenticator.  Our choice to send a group key = KeyRSC value
of zero in the EAPOL-key frame requires no change to 802.11i or to
802.1X .  It requires us to state this in the CAPWAP spec, if = we want
this behavior to be consistent across all implementations.

The problem with what Bechet and Saranavan are asking is that either = of
three different things are required:
1: the WTP must communicate the group key TSC to the AC every time it = is
updated, or
2: the AC must request the current value of the group key TSC for = the
KeyRSC before constructing the EAPOL-key frame, or
3: the AC must send the KCK to the AC so  that it can insert = the KeyRSC
value and also calculate the correct MIC, inserting that into the = proper
EAPOL-key frame.

The first item requires a tremendous amount of additional CAPWAP
communication between WTP and AC, at least one new CAPWAP packet for
every multicast frame sent by the WTP, if the packet is not
acknowledged, or two new CAPWAP packets, if it is = acknowledged.  This is
a very expensive addition to the protocol.

The second item requires new protocol between the AC and WTP during = what
can be a time critical portion of the 802.11 transition (handoff, = roam)
from one WTP to another.  It also introduces a race condition = that is
not present in the protocol today.  Once the value for the = KeyRSC is
sent from the WTP to the AC, it is possible that the WTP can send
another multicast frame encrypted with the group key.  This = puts the
value of the sequence counter out of sync with the value that will be =
shortly communicated to the client in the EAPOL-key frame from the = AC.
This will behave exactly the same as if a value of zero is sent in = the
EAPOL-key frame.

The third item requires a new architecture split that is not required in =
our objectives.  The new split is not splitting the MAC, but = splitting
the authenticator.  Placing the KCK in the WTP is also a = potential
reduction in the security of the overall WLAN system, since these
devices are normally not in a secured wiring closet, but exposed and =
more easily compromised than the AC.

The simplest to implement, least expensive, and most secure option is = to
use the protocol as it is now specified and have the AC send a value = of
zero in the KeyRSC field of the EAPOL-key frame.

-Bob

-----Original Message-----
From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com]
Sent: Wednesday, September 27, 2006 6:50 PM
To: Pat Calhoun (pacalhou); = Bob O'Hara (boohara); T. Charles Clancy; =
Peter Nilsson J (LI/EAB)
Cc: capwap@frascone.com
Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i = Considerations

Hi Pat and all,

So, based on this, I would say that we have consensus that setting the =
correct KeyRSC is an issue for the CAPWAP protocol design.

So far, we have three option/solutions:

1) As proposed by Bob: Using a static value (0) for the KeyRSC.

2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP

3) As suggested by Saravanana: Some exchange mechanism between WTP = and
AC

Among the three, the first option seems the easiest. However, it
requires a mandated Authenticator behavior(in this case AC) that is not =
mandated by 802.11. Therefore, we have to specify that (e.g. as = proposed
by Bob: "We could include a note to the effect that the group = KeyRSC
should be zero in the EAPOL-key frame.") either in CAPWAP or = 802.11,
because otherwise there is no interoperability. For example, AC = provided
by another vendor does not have to set KeyRSC to 0 to be compliant = with
CAPWAP and 802.11i.

Another implication is that we don't really understand the impact of =
mandating a static KeyRSC value. Although Bob provided an excellent
analysis, I still have some doubts about the profoundness of the = impact.
If the KeyRSC value is as described of no use, why would it appear = in
the EAPOL frames in the first place? By mandating it to static = value,
what have we lost? Maybe some liaison letter to 802.1 or 802.11 = could
provide us a better understanding of the issue.

For the last two options, I think they are both within CAPWAP's scope. =
Further analysis could help us to decide which one  is better = (or
someone could propose other solutions).

cheers

Cheng Hong







> -----Original Message-----
> From: Pat Calhoun = (pacalhou) [mailto: pcalhoun@cisco.com]
> Sent: Thursday, September 28, 2006 1:39 AM
> To: Cheng Hong; Bob = O'Hara (boohara); T. Charles Clancy;
> Peter Nilsson J (LI/EAB)
> Cc: capwap@frascone.com
> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> Considerations
>
> Bob's point is 802.11i works this way today. The AP (or in
> this case AC) can set the RSC to whatever value it wishes.
> Bob used zero (0) as an example. Implementations could use
> any other value, which would require some form of
> communication to the WTP, as suggested by Behcet.
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
>
> > -----Original Message-----
> > From: Cheng Hong [mailto: Hong.Cheng@sg.panasonic.com]
> > Sent: Tuesday, September 26, 2006 6:03 PM
> > To: Bob O'Hara = (boohara); T. Charles Clancy; Peter Nilsson
> J (LI/EAB)
> > Cc: capwap@frascone.com
> > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > Considerations
> >
> > Hi Bob,
> >
> > If I understand your description below correct, you are = proposing a
> > solution (to the problem pointed out by
> > Saravanan) by mandating the behavior of the AC to always set = the
> > KeyRSC in the 4-way handshake to zero.
> >
> > This is not a defined behavior according to the current
> > 802.11 standard.
> > Are you suggesting that we CAPWAP WG should specifically
> mandate that
> > in our CAPWAP protocol spec, e.g. something like "a = CAPWAP
> compatible
> > AC MUST set KeyRSC to zero"? Otherwise, the problem still exists,
> > since not all AC implementation have to follow what you = described.
> >
> > Or, are you planning to take this issue to TGm for 802.11 = standard
> > revision? (since based on your description, there is = essentially no
> > use of the KeyRSC).
> >
> > cheers
> >
> > Cheng Hong
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Bob = O'Hara (boohara) [mailto:boohara@cisco.com]
> > > Sent: Wednesday, September 27, 2006 2:32 AM
> > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB)
> > > Cc: capwap@frascone.com
> > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i =
> > > Considerations
> > >
> > > Charles, Peter,
> > >
> > > Below is an expansion of a snippet from a thread on = this
> > topic that I
> > > sent to the list on July 25, 2006.  I think = this will be
> helpful to
> > > understand why the exchange that Saranavan is requesting = is not
> > > necessary.  In fact, there are several systems = from several
> > > manufacturers in the field using precursor protocols to =
> CAPWAP that
> > > are Wi-Fi certified for WPA2/802.11i operation using = the
> > protocol as
> > > it is described below.
> > >
> > > BTW, this whole discussion is about the KeyRSC for the =
> > group key, not
> > > the pairwise key.  This is so because the WTP = and AC both
> know the
> > > initial sequence counter value for the pairwise key, = since it has
> > > never been used to send a frame.   802.11i = requires the
> first frame
> > > sent on a key to use the sequence counter value of 1.  See
> > 8.3.2.6 c)
> > > and
> > > 8.3.3.4.3 c) in 802.11i for this requirement.
> > >
> > > The same is not true of the group key, i.e., after the = WTP begins
> > > operation, the AC will not know the value of the = sequence
> > counter for
> > > the group key when it needs to complete the EAPOL-key
> > handshake with a
> > > newly associated STA.
> > > However, as you will see from the tutorial below, it is = not
> > necessary
> > > for the AC and WTP to exchange any information about = the
> group key
> > > KeyRSC for the protocol to operate as it is intended.
> > >
> > > 1. A value for the KeyRSC in the EAPOL-key frame 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.  A value of = zero in the
> EAPOL-key
> > > frame for the group key will always work.
> > >
> > > 3. The client STA will use the value of KeyRSC received = in the
> > > EAPOL-key frame to validate frame using the KeyMIC.
> > >
> > > 4. The client STA will also set its group key RSC to the = value
> > > received in KeyRSC, say, zero.
> > >
> > > 5. The value in the client STA's RSC will be compared = against the
> > > sequence number in subsequent received frames to identify = replay
> > > attacks.  Any frame received with a sequence = counter value
> > within the
> > > replay window will be checked to have a valid = MIC.  If the
> > MIC is not
> > > valid, the frame is dropped.
> > >
> > > 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, if the value is greater than its current RSC = value.
> > Only the
> > > AP can meet these criteria as the source of a frame
> received by the
> > > STA.
> > >
> > > 7. Please see item 6, immediately above, for the = reason
> that the AC
> > > and WTP do not need to coordinate and exchange the RSC. =
> > >
> > >
> > > The only possible attack mode is for the attacker to = send
> frames to
> > > the client STA between the time of the EAPOL-key frame = and
> > the first
> > > frame encrypted with the group key.
> > > During this time, the client will receive the frame = and
> proceed to
> > > validate its MIC.  This is a potential attack = against the STA
> > > resources.  But, the MIC validation is done in = the STA's
> > > 802.11 chip and consumes no more resources than = receiving
> any other
> > > frame.  Thus, the attack does not actually = consume any STA
> > resources
> > > beyond those of receiving a frame.
> > >
> > > This attack is not unique to the use of the value zero = for
> > the KeyRSC,
> > > either.  The same attack is available to an = attacker at any other
> > > time, as well.  It is no more nor less = effective at either time.
> > >
> > > For these reasons, the protocol is not in need of any = changes to
> > > address the issue raised by Saranavan.
> > >
> > >  -Bob
> > > -----Original Message-----
> > > From: T. Charles Clancy [mailto:clancy@cs.umd.edu]
> > > Sent: Monday, September 25, 2006 11:37 AM
> > > To: Peter Nilsson J (LI/EAB)
> > > Cc: capwap@frascone.com
> > > Subject: Re: [Capwap] Issue 43 - Explanation for = 802.11i
> > > Considerations
> > >
> > > This is a very interesting solution.  The AC = selects the
> KeyRSC and
> > > performs the 4-way handshake.  The WTP sniffs = the 4-way handshake
> > > traffic and grabs the KeyRSC value and uses it to
> > initialize its own
> > > counter.
> > >
> > > Pat/Bob: Is this how the Cisco implementation works?  I
> > have to agree
> > > with Saravanan that I've yet to see a technical
> description of how
> > > Cisco implements it.
> > >
> > > IMHO, this is somewhat hackish, and it would be cleaner = to
> > have the AC
> > > generate the KeyRSC and include it in the AddMobile = message
> > as Behcet
> > > suggests.
> > >
> > > --
> > > t. charles clancy, ph.d.  |  tcc@umd.edu  |
> www.cs.umd.edu/~clancy
> > >
> > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote:
> > >
> > > > I think Saravanan has a point. We did a = prototype
> > impelementation of
> > > the
> > > > protocol a year ago when it was still called LWAPP. = The way
> > > we solved
> > > > this issue then was to let the WTP sniff on all = CAPWAP data
> > > messages
> > > > from the AC and when message 3 of the 4-way = handshake or
> > > message 1 of
> > > > the groupkey handshake was sent the WTP inserted the correct RSC
> > > before
> > > > sending it off to the supplicant. To avoid the = sniffing on
> > > all CAPWAP
> > > > data messages we would need a mechanism with in = CAPWAP to
> > > handle these
> > > > two messages.
> > > >
> > > > Peter Nilsson
> > > >
> > > > -----Original Message-----
> > > > From: Saravanan = Govindan
> > > [mailto:Saravanan.Govindan@sg= .panasonic.com]
> > > > Sent: den 22 september 2006 11:03
> > > > To: Margaret Wasserman
> > > > Cc: capwap@frascone.com
> > > > Subject: Re: [Capwap] Issue 43 - Explanation for = 802.11i
> > > Considerations
> > > >
> > > > Hi Margaret,
> > > >
> > > > Thank you for reviewing the discussion on this = issue.
> > > >
> > > > The issue here is the working of IEEE 802.11i when = the 802.11i
> > > > authenticator element is at the AC and the 802.11i = crypto
> > element is
> > > at
> > > > the WTP. Particularly, it is for the 4-way handshake between
> > > > authenticator and supplicant.
> > > >
> > > > Now, the 4-way handshake requires knowing the value = of
> > > KeyRSC sequence
> > > > counter. The KeyRSC helps both authenticator and = supplicant
> > > keep track
> > > > of their exchanges. It serves to protect against = threats by
> > > tracking
> > > > sequential frames. The KeyRSC is maintained at the = at the
> > point of
> > > > encryption, i.e. just before transmission over = the
> > wireless channel.
> > > >
> > > > In the case of CAPWAP, the 4-way handshake is = between the AC
> > > > (authenticator) and the wireless station = (supplicant).
> > > >
> > > > The problem arises, when the authenticator is at the = AC and
> > > the crypto
> > > > element (together with KeyRSC) is at the WTP. This = is a
> > > fairly common
> > > > design. Now in this case, the AC starts the = 4-way
> handshake but it
> > > does
> > > > not know the value of the KeyRSC. The KeyRSC is = maintained
> > > by the WTP.
> > > >
> > > > Based on this, the current CAPWAP specification does = not
> > allow for a
> > > way
> > > > to conduct the 4-way handshake with the correct = KeyRSC.
> > > >
> > > > The functionality I would like to see is a way for = the
> > authenticator
> > > > (AC) to use the correct prevailing value of = KeyRSC
> > > (maintained by the
> > > > WTP) in its 4-way handshake.
> > > >
> > > > One way to introduce this functionality in to CAPWAP = is
> > to have part
> > > of
> > > > the 4-way handshake be sent from AC to WTP. This = will allow
> > > the 4-way
> > > > handshake to use the correct value of the KeyRSC = before
> > > being sent to
> > > > the wireless station.
> > > >
> > > > I hope this helps clarify my view on the issue.
> > > >
> > > > Cheers,
> > > >
> > > > Saravanan
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Margaret Wasserman [mailto:margaret@thingmagic.com]
> > > > Sent: Thursday, September 21, 2006 8:26 PM
> > > > To: Saravanan = Govindan
> > > > Cc: Pat = Calhoun (pacalhou); capwap@frascone.com
> > > > Subject: Re: [Capwap] Issue 43 - Explanation for = 802.11i
> > > Considerations
> > > >
> > > >
> > > >
> > > > Hi again,
> > > >
> > > > Okay, I am even more confused than I thought I = was...
> > > >
> > > > Saravanan, you wrote:
> > > >
> > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote:
> > > >
> > > >> Pat,
> > > >>
> > > >> The issue here is about how 802.11i exchanges = are done when
> > > >> authenticator is at the AC and crypto elements = are at
> > the WTP. This
> > > is
> > > >> the requirement.
> > > >
> > > > And, in response, Pat = Calhoun wrote:
> > > >
> > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote:
> > > >> The current specification allows the = authenticator to
> > > reside in the
> > > >> AC, while the data packet crypto elements in the = WTP. This
> > > feature is
> > > >> already in the specification.
> > > >
> > > > Pat's message matches my reading of the = specification.
> > > >
> > > > So, Saravanan, what functionality are you asking for =
> that is not
> > > > already supported by the = specification?  And why do you
> > think it is
> > > > necessary?  it will not be helpful to my understanding to
> > > re-send your
> > > > proposal or to cite the requirements document...  Please
> > summarize
> > > > what functionality you think is missing from the = current
> > > specification
> > > > and why you think that functionality is necessary to =
> support IEEE
> > > > 802.11i or any important use case.
> > > >
> > > > At some point, the chairs may need to make a = consensus
> > call on this
> > > > issue, and I'd like to understand your view and make = sure
> > > that it has
> > > > been clearly communicated to the WG before we ask = the WG to
> > > decide on
> > > > this issue.
> > > >
> > > > Thanks,
> > > > Margaret
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> _________________________________________________________________ =
> > > > To unsubscribe or modify your subscription = options,
> please visit:
> > > > http://lists.f= rascone.com/mailman/listinfo/capwap
> > > >
> > > > Archives: http://lists.frascone= .com/pipermail/capwap
> > > >
> _________________________________________________________________ =
> > > > To unsubscribe or modify your subscription = options,
> please visit:
> > > > http://lists.f= rascone.com/mailman/listinfo/capwap
> > > >
> > > > Archives: http://lists.frascone= .com/pipermail/capwap
> > > >
> > > _________________________________________________________________
> > > To unsubscribe or modify your subscription options, = please visit:
> > > http://lists.f= rascone.com/mailman/listinfo/capwap
> > >
> > > Archives: http://lists.frascone= .com/pipermail/capwap
> > > _________________________________________________________________
> > > To unsubscribe or modify your subscription options, = please visit:
> > > http://lists.f= rascone.com/mailman/listinfo/capwap
> > >
> > > Archives: http://lists.frascone= .com/pipermail/capwap
> > >
> > = _________________________________________________________________
> > To unsubscribe or modify your subscription options, please = visit:
> > http://lists.f= rascone.com/mailman/listinfo/capwap
> >
> > Archives: http://lists.frascone= .com/pipermail/capwap
> >
> = _________________________________________________________________
> To unsubscribe or modify your subscription options, please = visit:
> http://lists.f= rascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone= .com/pipermail/capwap
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.f= rascone.com/mailman/listinfo/capwap

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

 

------_=_NextPart_001_01C6E35F.FA7C3D0A-- --===============0096241993== 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 --===============0096241993==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 29 12:35:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTLKQ-0005Rw-2t for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 12:35:10 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTLCF-0004fT-Fq for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 12:26:46 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 356E1144800F for ; Fri, 29 Sep 2006 09:26:35 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4C1E6430059 for ; Fri, 29 Sep 2006 09:10:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2E0171448018 for ; Fri, 29 Sep 2006 09:10:08 -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 D4DCB144800B for ; Fri, 29 Sep 2006 09:09:56 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Sep 2006 09:09:56 -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 k8TG9upw030816; Fri, 29 Sep 2006 09:09:56 -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 k8TG9t1E028023; Fri, 29 Sep 2006 09:09:55 -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); Fri, 29 Sep 2006 09:09:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Sep 2006 09:09:54 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC02188E2C@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbjOwaBxAxmTegASwKjGKmQD0OreAAB7o8QAAZYQgAAILorcA== From: "Bob O'Hara (boohara)" To: "Cheng Hong" , "Dorothy Stanley" X-OriginalArrivalTime: 29 Sep 2006 16:09:55.0006 (UTC) FILETIME=[B3C8B5E0:01C6E3E1] Authentication-Results: sj-dkim-2.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.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE, NORMAL_HTTP_TO_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com, Saravanan Govindan Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1739222654==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b083f4f2bdf728f0ea848ccc7744efa This is a multi-part message in MIME format. --===============1739222654== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E3E1.B38DA6A9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E3E1.B38DA6A9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am afraid that requesting design assistance from a competitor is very close to violation of U.S anti-trust laws. I will not describe how Cisco has designed any of its products and I cannot help you design yours. =20 Again, your proposal does not eliminate any attack mechanism and does not add any functionality to the protocol, only cost and complexity. A replayed frame will be discarded by the MAC, using the normal duplicate frame detection mechanisms. See section 8.3.3.3.2 of 802.11i (where the frame sequence number is part of the additional authenticated data) and section 9.2.9 of 802.11-1999 for the description of these functions. And PLEASE read 802.11 and 802.11i before again asserting that this proposal is necessary. =20 As I said several emails ago, the ONLY effect of using zero as the value for the KeyRSC is that the 802.11 chipset in the STA (client) will have to receive the frame, attempt to decrypt it, and validate the MIC. This must be done for EVERY frame received, whether it is a replayed frame or not. This set of functions is performed in the 802.11 STA chipset and does not consume any additional resources of the STA. So, the attack, if it can even be characterized as an attack, is no more effective at DOSing the STA than sending it any other frame. -Bob =20 =20 ________________________________ From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com]=20 Sent: Thursday, September 28, 2006 5:34 PM To: Bob O'Hara (boohara); Dorothy Stanley Cc: Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com; Saravanan Govindan Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi Bob, =20 As Dorothy correctly pointed out below, setting the KeyRSC to a value closer to the current RSC would be better than setting it to a pre-defined value zero.=20 =20 It is true that 802.11i and 802.1X do not specify what is the KeyRSC value to be used, since they are trying to provide us a tool to correctly synchronize the RSC using the Msg 3. By mandating the KeyRSC to zero, we are just disabling the tool. It is not wrong, but just deprives the system a designed function. =20 As for the effectiveness of KeyRSC, setting it to a predefined value of 0 would pose a greater threat. In a simple example, if the RSC is currently 1000, and we are mandating the KeyRSC to be always zero, the attacker basically can safely replay the last 1000 packets to the STA without being detected. If the KeyRSC can be set to a closer value of the current RSC, say, 900, the number of possible replayed packets can be reduced to 10 percent, 100 packets.=20 =20 Therefore, I would say, setting the KeyRSC value to zero does place a bigger threat. Is that how the cisco products implemented? Maybe you could share with us some other implementation/testing data to prove otherwise. Or, you have some other considerations that could defend the replay attack? =20 cheers =20 Cheng Hong =20 ________________________________ From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Friday, September 29, 2006 5:21 AM To: Dorothy Stanley Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations =09 =09 Dorothy, =20 The problem with this proposal is that it is no more effective than sending a value of zero for the KeyRSC. It doesn't eliminate any potential attacks. It doesn't add any functionality. However, it does add cost and complexity to the protocol. =20 -Bob =20 =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Thursday, September 28, 2006 1:17 PM To: Bob O'Hara (boohara) Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations =09 =09 All, =09 Below is the text from 802.11REV-maD8.0 Clause 8.5.2, describing the Key RSC field.: =09 "g) Key RSC. This field is 8 octets in length. It contains the receive sequence counter (RSC) for the GTK being installed in IEEE 802.11. It is used in Message 3 of the 4-Way Handshake and Message 1 of the Group Key Handshake, where it is used to synchronize the IEEE 802.11 replay state. It may also be used in the Michael MIC Failure Report frame, to report the TSC field value of the frame experiencing a MIC failure. It shall contain 0 in other messages. The Key RSC field gives the current message number for the GTK, to allow a STA to identify replayed MPDUs. If the Key RSC field value is less than 8 octets in length, the remaining octets shall be set to 0. The least significant octet of the TSC or PN should be in the first octet of the Key RSC field." =09 The intent of adding this value in message 3 was to immediately minimize the number of=20 replayed frames that a STA would potentially process: "The Key RSC field gives the current message number for the GTK, to allow a STA to identify replayed MPDUs." Setting the value to 0 in Msg 3 does not provide the current sequence counter (in most cases not even close) of the GTK.. =09 Perhaps the WTP could periodically/frequently notify the AC of its current GTK sequence counter, and the AC would use the most recently received value in the message 3 sent to new STAs. The RSC value would not be up to date at all times, but would be closer than "0", not require an "in-the-critical-path message exchange between the AC and WTP, and still be close to the intended use of the field. =09 Dorothy =09 =09 On 9/28/06, Bob O'Hara (boohara) wrote:=20 Please understand that 802.11i specifies no behavior in this area for the 802.1X authenticator. Our choice to send a group key KeyRSC value of zero in the EAPOL-key frame requires no change to 802.11i or to 802.1X . It requires us to state this in the CAPWAP spec, if we want this behavior to be consistent across all implementations. =09 The problem with what Bechet and Saranavan are asking is that either of three different things are required:=20 1: the WTP must communicate the group key TSC to the AC every time it is updated, or 2: the AC must request the current value of the group key TSC for the KeyRSC before constructing the EAPOL-key frame, or 3: the AC must send the KCK to the AC so that it can insert the KeyRSC value and also calculate the correct MIC, inserting that into the proper EAPOL-key frame. =09 The first item requires a tremendous amount of additional CAPWAP=20 communication between WTP and AC, at least one new CAPWAP packet for every multicast frame sent by the WTP, if the packet is not acknowledged, or two new CAPWAP packets, if it is acknowledged. This is a very expensive addition to the protocol.=20 =09 The second item requires new protocol between the AC and WTP during what can be a time critical portion of the 802.11 transition (handoff, roam) from one WTP to another. It also introduces a race condition that is=20 not present in the protocol today. Once the value for the KeyRSC is sent from the WTP to the AC, it is possible that the WTP can send another multicast frame encrypted with the group key. This puts the value of the sequence counter out of sync with the value that will be=20 shortly communicated to the client in the EAPOL-key frame from the AC. This will behave exactly the same as if a value of zero is sent in the EAPOL-key frame. =09 The third item requires a new architecture split that is not required in=20 our objectives. The new split is not splitting the MAC, but splitting the authenticator. Placing the KCK in the WTP is also a potential reduction in the security of the overall WLAN system, since these devices are normally not in a secured wiring closet, but exposed and=20 more easily compromised than the AC. =09 The simplest to implement, least expensive, and most secure option is to use the protocol as it is now specified and have the AC send a value of zero in the KeyRSC field of the EAPOL-key frame.=20 =09 -Bob =09 -----Original Message----- From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] Sent: Wednesday, September 27, 2006 6:50 PM To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy;=20 Peter Nilsson J (LI/EAB) Cc: capwap@frascone.com Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations =09 Hi Pat and all, =09 So, based on this, I would say that we have consensus that setting the=20 correct KeyRSC is an issue for the CAPWAP protocol design. =09 So far, we have three option/solutions: =09 1) As proposed by Bob: Using a static value (0) for the KeyRSC. =09 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP=20 =09 3) As suggested by Saravanana: Some exchange mechanism between WTP and AC =09 Among the three, the first option seems the easiest. However, it requires a mandated Authenticator behavior(in this case AC) that is not=20 mandated by 802.11. Therefore, we have to specify that (e.g. as proposed by Bob: "We could include a note to the effect that the group KeyRSC should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11, because otherwise there is no interoperability. For example, AC provided by another vendor does not have to set KeyRSC to 0 to be compliant with CAPWAP and 802.11i. =09 Another implication is that we don't really understand the impact of=20 mandating a static KeyRSC value. Although Bob provided an excellent analysis, I still have some doubts about the profoundness of the impact. If the KeyRSC value is as described of no use, why would it appear in the EAPOL frames in the first place? By mandating it to static value, what have we lost? Maybe some liaison letter to 802.1 or 802.11 could provide us a better understanding of the issue. =09 For the last two options, I think they are both within CAPWAP's scope.=20 Further analysis could help us to decide which one is better (or someone could propose other solutions). =09 cheers =09 Cheng Hong =09 =09 =09 =09 =09 =09 =09 > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com] > Sent: Thursday, September 28, 2006 1:39 AM > To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; > Peter Nilsson J (LI/EAB) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Bob's point is 802.11i works this way today. The AP (or in=20 > this case AC) can set the RSC to whatever value it wishes. > Bob used zero (0) as an example. Implementations could use > any other value, which would require some form of > communication to the WTP, as suggested by Behcet.=20 > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Cheng Hong [mailto: Hong.Cheng@sg.panasonic.com ] > > Sent: Tuesday, September 26, 2006 6:03 PM > > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson > J (LI/EAB) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > Hi Bob, > > > > If I understand your description below correct, you are proposing a=20 > > solution (to the problem pointed out by > > Saravanan) by mandating the behavior of the AC to always set the > > KeyRSC in the 4-way handshake to zero. > > > > This is not a defined behavior according to the current=20 > > 802.11 standard. > > Are you suggesting that we CAPWAP WG should specifically > mandate that > > in our CAPWAP protocol spec, e.g. something like "a CAPWAP > compatible > > AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, > > since not all AC implementation have to follow what you described. > > > > Or, are you planning to take this issue to TGm for 802.11 standard > > revision? (since based on your description, there is essentially no > > use of the KeyRSC). > > > > cheers > > > > Cheng Hong > > > >=20 > > > > > > > -----Original Message----- > > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > > > Sent: Wednesday, September 27, 2006 2:32 AM=20 > > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i=20 > > > Considerations > > > > > > Charles, Peter, > > > > > > Below is an expansion of a snippet from a thread on this > > topic that I > > > sent to the list on July 25, 2006. I think this will be=20 > helpful to > > > understand why the exchange that Saranavan is requesting is not > > > necessary. In fact, there are several systems from several > > > manufacturers in the field using precursor protocols to=20 > CAPWAP that > > > are Wi-Fi certified for WPA2/802.11i operation using the > > protocol as > > > it is described below. > > > > > > BTW, this whole discussion is about the KeyRSC for the=20 > > group key, not > > > the pairwise key. This is so because the WTP and AC both > know the > > > initial sequence counter value for the pairwise key, since it has > > > never been used to send a frame. 802.11i requires the > first frame > > > sent on a key to use the sequence counter value of 1. See > > 8.3.2.6 c) > > > and > > > 8.3.3.4.3 c) in 802.11i for this requirement. > > > > > > The same is not true of the group key, i.e., after the WTP begins > > > operation, the AC will not know the value of the sequence > > counter for=20 > > > the group key when it needs to complete the EAPOL-key > > handshake with a > > > newly associated STA. > > > However, as you will see from the tutorial below, it is not > > necessary > > > for the AC and WTP to exchange any information about the > group key > > > KeyRSC for the protocol to operate as it is intended. > > > > > > 1. A value for the KeyRSC in the EAPOL-key frame is necessary to=20 > > > calculate the KeyMIC. > > > > > > 2. This value does not need to bear any specific > > relationship to the > > > RSC value maintained by the WTP. A value of zero in the=20 > EAPOL-key > > > frame for the group key will always work. > > > > > > 3. The client STA will use the value of KeyRSC received in the > > > EAPOL-key frame to validate frame using the KeyMIC.=20 > > > > > > 4. The client STA will also set its group key RSC to the value > > > received in KeyRSC, say, zero. > > > > > > 5. The value in the client STA's RSC will be compared against the=20 > > > sequence number in subsequent received frames to identify replay > > > attacks. Any frame received with a sequence counter value > > within the > > > replay window will be checked to have a valid MIC. If the=20 > > MIC is not > > > valid, the frame is dropped. > > > > > > 6. For any frame that is determined not to be a replay > attack frame > > > and meets all other validity and authenticity requirements,=20 > > the client > > > STA updates its RSC value to the sequence number in the received > > > frame, if the value is greater than its current RSC value. > > Only the > > > AP can meet these criteria as the source of a frame=20 > received by the > > > STA. > > > > > > 7. Please see item 6, immediately above, for the reason > that the AC > > > and WTP do not need to coordinate and exchange the RSC.=20 > > > > > > > > > The only possible attack mode is for the attacker to send > frames to > > > the client STA between the time of the EAPOL-key frame and > > the first=20 > > > frame encrypted with the group key. > > > During this time, the client will receive the frame and > proceed to > > > validate its MIC. This is a potential attack against the STA=20 > > > resources. But, the MIC validation is done in the STA's > > > 802.11 chip and consumes no more resources than receiving > any other > > > frame. Thus, the attack does not actually consume any STA=20 > > resources > > > beyond those of receiving a frame. > > > > > > This attack is not unique to the use of the value zero for > > the KeyRSC, > > > either. The same attack is available to an attacker at any other=20 > > > time, as well. It is no more nor less effective at either time. > > > > > > For these reasons, the protocol is not in need of any changes to > > > address the issue raised by Saranavan.=20 > > > > > > -Bob > > > -----Original Message----- > > > From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > > > Sent: Monday, September 25, 2006 11:37 AM=20 > > > To: Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations=20 > > > > > > This is a very interesting solution. The AC selects the > KeyRSC and > > > performs the 4-way handshake. The WTP sniffs the 4-way handshake > > > traffic and grabs the KeyRSC value and uses it to=20 > > initialize its own > > > counter. > > > > > > Pat/Bob: Is this how the Cisco implementation works? I > > have to agree > > > with Saravanan that I've yet to see a technical=20 > description of how > > > Cisco implements it. > > > > > > IMHO, this is somewhat hackish, and it would be cleaner to > > have the AC > > > generate the KeyRSC and include it in the AddMobile message=20 > > as Behcet > > > suggests. > > > > > > -- > > > t. charles clancy, ph.d. | tcc@umd.edu | > www.cs.umd.edu/~clancy > > > > > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > > > > > > > I think Saravanan has a point. We did a prototype > > impelementation of=20 > > > the > > > > protocol a year ago when it was still called LWAPP. The way > > > we solved > > > > this issue then was to let the WTP sniff on all CAPWAP data > > > messages=20 > > > > from the AC and when message 3 of the 4-way handshake or > > > message 1 of > > > > the groupkey handshake was sent the WTP inserted the correct RSC > > > before=20 > > > > sending it off to the supplicant. To avoid the sniffing on > > > all CAPWAP > > > > data messages we would need a mechanism with in CAPWAP to > > > handle these=20 > > > > two messages. > > > > > > > > Peter Nilsson > > > > > > > > -----Original Message----- > > > > From: Saravanan Govindan > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > Sent: den 22 september 2006 11:03 > > > > To: Margaret Wasserman > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > Hi Margaret, > > > > > > > > Thank you for reviewing the discussion on this issue. > > > > > > > > The issue here is the working of IEEE 802.11i when the 802.11i > > > > authenticator element is at the AC and the 802.11i crypto > > element is > > > at > > > > the WTP. Particularly, it is for the 4-way handshake between=20 > > > > authenticator and supplicant. > > > > > > > > Now, the 4-way handshake requires knowing the value of > > > KeyRSC sequence > > > > counter. The KeyRSC helps both authenticator and supplicant=20 > > > keep track > > > > of their exchanges. It serves to protect against threats by > > > tracking > > > > sequential frames. The KeyRSC is maintained at the at the > > point of > > > > encryption, i.e. just before transmission over the > > wireless channel. > > > > > > > > In the case of CAPWAP, the 4-way handshake is between the AC=20 > > > > (authenticator) and the wireless station (supplicant). > > > > > > > > The problem arises, when the authenticator is at the AC and > > > the crypto > > > > element (together with KeyRSC) is at the WTP. This is a=20 > > > fairly common > > > > design. Now in this case, the AC starts the 4-way > handshake but it > > > does > > > > not know the value of the KeyRSC. The KeyRSC is maintained=20 > > > by the WTP. > > > > > > > > Based on this, the current CAPWAP specification does not > > allow for a > > > way > > > > to conduct the 4-way handshake with the correct KeyRSC.=20 > > > > > > > > The functionality I would like to see is a way for the > > authenticator > > > > (AC) to use the correct prevailing value of KeyRSC > > > (maintained by the=20 > > > > WTP) in its 4-way handshake. > > > > > > > > One way to introduce this functionality in to CAPWAP is > > to have part > > > of > > > > the 4-way handshake be sent from AC to WTP. This will allow=20 > > > the 4-way > > > > handshake to use the correct value of the KeyRSC before > > > being sent to > > > > the wireless station. > > > > > > > > I hope this helps clarify my view on the issue.=20 > > > > > > > > Cheers, > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > > > > Sent: Thursday, September 21, 2006 8:26 PM=20 > > > > To: Saravanan Govindan > > > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > > > > > > > > > Hi again, > > > > > > > > Okay, I am even more confused than I thought I was...=20 > > > > > > > > Saravanan, you wrote: > > > > > > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > > > > > >> Pat,=20 > > > >> > > > >> The issue here is about how 802.11i exchanges are done when > > > >> authenticator is at the AC and crypto elements are at > > the WTP. This=20 > > > is > > > >> the requirement. > > > > > > > > And, in response, Pat Calhoun wrote: > > > > > > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote:=20 > > > >> The current specification allows the authenticator to > > > reside in the > > > >> AC, while the data packet crypto elements in the WTP. This > > > feature is=20 > > > >> already in the specification. > > > > > > > > Pat's message matches my reading of the specification. > > > > > > > > So, Saravanan, what functionality are you asking for=20 > that is not > > > > already supported by the specification? And why do you > > think it is > > > > necessary? it will not be helpful to my understanding to > > > re-send your=20 > > > > proposal or to cite the requirements document... Please > > summarize > > > > what functionality you think is missing from the current > > > specification > > > > and why you think that functionality is necessary to=20 > support IEEE > > > > 802.11i or any important use case. > > > > > > > > At some point, the chairs may need to make a consensus > > call on this > > > > issue, and I'd like to understand your view and make sure=20 > > > that it has > > > > been clearly communicated to the WG before we ask the WG to > > > decide on > > > > this issue. > > > > > > > > Thanks,=20 > > > > Margaret > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________=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 > > > > 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 > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > >=20 > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit:=20 > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit:=20 > > 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 > =09 _________________________________________________________________=20 To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap =09 ------_=_NextPart_001_01C6E3E1.B38DA6A9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I am afraid that requesting design assistance = from a=20 competitor is very close to violation of U.S anti-trust laws.  I = will not=20 describe how Cisco has designed any of its products and I cannot help = you design=20 yours.
 
Again, your proposal does not eliminate any = attack=20 mechanism and does not add any functionality to the protocol, only cost = and=20 complexity.  A replayed frame will be discarded by the MAC, using = the=20 normal duplicate frame detection mechanisms.  See section=20 8.3.3.3.2 of 802.11i (where the frame sequence number is part = of the=20 additional authenticated data) and section 9.2.9 of 802.11-1999 for = the=20 description of these functions.  And PLEASE read 802.11 and 802.11i = before=20 again asserting that this proposal is necessary.
 
As I said several emails ago, the ONLY effect = of using zero=20 as the value for the KeyRSC is that the 802.11 chipset in the STA = (client) will=20 have to receive the frame, attempt to decrypt it, and validate the = MIC. =20 This must be done for EVERY frame received, whether it is a replayed = frame or=20 not.  This set of functions is performed in the 802.11 STA chipset = and does=20 not consume any additional resources of the STA.  So, the attack, = if it can=20 even be characterized as an attack, is no more effective at DOSing the = STA than=20 sending it any other frame.

 -Bob
 

 

From: Cheng Hong=20 [mailto:Hong.Cheng@sg.panasonic.com]
Sent: Thursday, = September 28,=20 2006 5:34 PM
To: Bob O'Hara (boohara); Dorothy = Stanley
Cc:=20 Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB);=20 capwap@frascone.com; Saravanan Govindan
Subject: RE: [Capwap] = Issue 43=20 - Explanation for 802.11i Considerations

Hi=20 Bob,
 
As=20 Dorothy correctly pointed out below, setting the KeyRSC to a value = closer to the=20 current RSC would be better than setting it to a pre-defined value zero. =
 
It is=20 true that 802.11i and 802.1X do not specify what is the KeyRSC value to = be used,=20 since they are trying to provide us a tool to correctly synchronize the = RSC=20 using the Msg 3. By mandating the KeyRSC to zero, we are just disabling = the=20 tool. It is not wrong, but just deprives the system a designed=20 function.
 
As for=20 the effectiveness of KeyRSC, setting it to a predefined value of 0 would = pose a=20 greater threat. In a simple example, if the RSC is currently 1000, and = we are=20 mandating the KeyRSC to be always zero, the attacker basically can = safely=20 replay the last 1000 packets to the STA without being detected. If = the=20 KeyRSC can be set to a closer value of the current RSC, say, 900, the = number of=20 possible replayed packets can be reduced to 10 percent, 100 = packets.=20
 
Therefore, I would say, setting the KeyRSC value to zero does = place a=20 bigger threat. Is that how the cisco products implemented? Maybe you = could share=20 with us some other implementation/testing data to prove otherwise. Or, = you have=20 some other considerations that could defend the replay=20 attack?
 
cheers
 
Cheng=20 Hong
 

From: Bob O'Hara (boohara)=20 [mailto:boohara@cisco.com]
Sent: Friday, September 29, 2006 = 5:21=20 AM
To: Dorothy Stanley
Cc: Cheng Hong; Pat Calhoun = (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB);=20 capwap@frascone.com
Subject: RE: [Capwap] Issue 43 - = Explanation for=20 802.11i Considerations

Dorothy,
 
The problem with this proposal is that it is = no more=20 effective than sending a value of zero for the KeyRSC.  It = doesn't=20 eliminate any potential attacks.  It doesn't add any=20 functionality.  However, it does add cost and = complexity to the=20 protocol. 

 -Bob
 

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Thursday, September = 28, 2006=20 1:17 PM
To: Bob O'Hara (boohara)
Cc: Cheng Hong; = Pat=20 Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB);=20 capwap@frascone.com
Subject: Re: [Capwap] Issue 43 - = Explanation for=20 802.11i Considerations

All,

Below is the text from 802.11REV-maD8.0 Clause = 8.5.2,=20 describing the Key RSC field.:

"g) Key=20 RSC. This field is 8 octets in length. It contains the receive = sequence=20 counter (RSC) for the
GTK being installed in IEEE 802.11. It is = used in=20 Message 3 of the 4-Way Handshake andMessage 1 of the=20 Group Key Handshake, where it is used to synchronize the IEEE 802.11=20 replay
state. It may also be used in the Michael = MIC=20 Failure Report frame, to report the TSC field value ofthe = frame=20 experiencing a MIC failure. It shall contain 0 in other messages. The = Key RSC=20 field gives
the current message number for the GTK, = to allow a=20 STA to identify replayed MPDUs. If the KeyRSC = field value is=20 less than 8 octets in length, the remaining octets shall be set to 0. = The=20 least significant
octet of the TSC or PN should be in the = first octet=20 of the Key RSC field."

The intent of adding this value = in=20 message 3 was to immediately minimize the number of
replayed = frames that a=20 STA would potentially process: "The Key RSC field gives
the current = message=20 number for the GTK, to allow a STA to identify replayed = MPDUs."
Setting the=20 value to 0 in Msg 3 does not provide the current sequence counter (in = most=20 cases
not even close) of the GTK..

Perhaps the WTP could=20 periodically/frequently notify the AC of its current GTK sequence = counter, and=20 the
AC would use the most recently received value in the message 3 = sent to=20 new STAs. The RSC value
would not be  up to date at all times, = but=20 would be closer than "0", not require an = "in-the-critical-path
message=20 exchange between the AC and WTP, and still be close to the intended = use of the=20 field.

Dorothy

On 9/28/06, Bob O'Hara=20 (boohara) <boohara@cisco.com>=20 wrote:=20
Please=20 understand that 802.11i specifies no behavior in this area = for
the 802.1X=20 authenticator.  Our choice to send a group key KeyRSC = value
of=20 zero in the EAPOL-key frame requires no change to 802.11i or = to
802.1X=20 .  It requires us to state this in the CAPWAP spec, if we=20 want
this behavior to be consistent across all=20 implementations.

The problem with what Bechet and Saranavan = are=20 asking is that either of
three different things are required: =
1: the=20 WTP must communicate the group key TSC to the AC every time it=20 is
updated, or
2: the AC must request the current value of the = group=20 key TSC for the
KeyRSC before constructing the EAPOL-key frame, = or
3:=20 the AC must send the KCK to the AC so  that it can insert = the=20 KeyRSC
value and also calculate the correct MIC, inserting that = into the=20 proper
EAPOL-key frame.

The first item requires a = tremendous=20 amount of additional CAPWAP
communication between WTP and AC, at = least=20 one new CAPWAP packet for
every multicast frame sent by the WTP, = if the=20 packet is not
acknowledged, or two new CAPWAP packets, if it is=20 acknowledged.  This is
a very expensive addition to the = protocol.

The second item requires new protocol between the = AC and=20 WTP during what
can be a time critical portion of the 802.11 = transition=20 (handoff, roam)
from one WTP to another.  It also = introduces a=20 race condition that is
not present in the protocol=20 today.  Once the value for the KeyRSC is
sent from the = WTP to=20 the AC, it is possible that the WTP can send
another multicast = frame=20 encrypted with the group key.  This puts the
value of = the=20 sequence counter out of sync with the value that will be
shortly = communicated to the client in the EAPOL-key frame from the = AC.
This will=20 behave exactly the same as if a value of zero is sent in = the
EAPOL-key=20 frame.

The third item requires a new architecture split that = is not=20 required in
our objectives.  The new split is not = splitting=20 the MAC, but splitting
the authenticator.  Placing the = KCK in=20 the WTP is also a potential
reduction in the security of the = overall WLAN=20 system, since these
devices are normally not in a secured wiring = closet,=20 but exposed and
more easily compromised than the AC.

The = simplest=20 to implement, least expensive, and most secure option is to
use = the=20 protocol as it is now specified and have the AC send a value = of
zero in=20 the KeyRSC field of the EAPOL-key frame. =

-Bob

-----Original=20 Message-----
From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com]
Sent:=20 Wednesday, September 27, 2006 6:50 PM
To: Pat Calhoun (pacalhou); = Bob=20 O'Hara (boohara); T. Charles Clancy;
Peter Nilsson J = (LI/EAB)
Cc: capwap@frascone.com
Subject: = RE:=20 [Capwap] Issue 43 - Explanation for 802.11i Considerations

Hi = Pat and=20 all,

So, based on this, I would say that we have consensus = that=20 setting the
correct KeyRSC is an issue for the CAPWAP protocol=20 design.

So far, we have three option/solutions:

1) As = proposed=20 by Bob: Using a static value (0) for the KeyRSC.

2) As = suggested by=20 Behcet: AC communicate a correct KeyRSC to WTP

3) As = suggested by=20 Saravanana: Some exchange mechanism between WTP = and
AC

Among the=20 three, the first option seems the easiest. However, it
requires a = mandated Authenticator behavior(in this case AC) that is not =
mandated by=20 802.11. Therefore, we have to specify that (e.g. as proposed
by = Bob: "We=20 could include a note to the effect that the group KeyRSC
should = be zero=20 in the EAPOL-key frame.") either in CAPWAP or 802.11,
because = otherwise=20 there is no interoperability. For example, AC provided
by another = vendor=20 does not have to set KeyRSC to 0 to be compliant with
CAPWAP and=20 802.11i.

Another implication is that we don't really = understand the=20 impact of
mandating a static KeyRSC value. Although Bob provided = an=20 excellent
analysis, I still have some doubts about the = profoundness of=20 the impact.
If the KeyRSC value is as described of no use, why = would it=20 appear in
the EAPOL frames in the first place? By mandating it to = static=20 value,
what have we lost? Maybe some liaison letter to 802.1 or = 802.11=20 could
provide us a better understanding of the issue.

For = the last=20 two options, I think they are both within CAPWAP's scope. =
Further=20 analysis could help us to decide which one  is better=20 (or
someone could propose other = solutions).

cheers

Cheng=20 Hong







> -----Original = Message-----
>=20 From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com]
> = Sent:=20 Thursday, September 28, 2006 1:39 AM
> To: Cheng Hong; Bob = O'Hara=20 (boohara); T. Charles Clancy;
> Peter Nilsson J = (LI/EAB)
> Cc:=20 capwap@frascone.com
>=20 Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
>=20 Considerations
>
> Bob's point is 802.11i works this way = today.=20 The AP (or in
> this case AC) can set the RSC to whatever = value it=20 wishes.
> Bob used zero (0) as an example. Implementations = could=20 use
> any other value, which would require some form = of
>=20 communication to the WTP, as suggested by Behcet.
>
> = Pat=20 Calhoun
> CTO, Wireless Networking Business Unit
> Cisco = Systems
>
>
>
> > -----Original=20 Message-----
> > From: Cheng Hong [mailto:=20 Hong.Cheng@sg.panasonic.com]
> > Sent: Tuesday, = September 26,=20 2006 6:03 PM
> > To: Bob O'Hara (boohara); T. Charles = Clancy; Peter=20 Nilsson
> J (LI/EAB)
> > Cc: capwap@frascone.com
> = >=20 Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> = >=20 Considerations
> >
> > Hi Bob,
> = >
> >=20 If I understand your description below correct, you are proposing a =
>=20 > solution (to the problem pointed out by
> > Saravanan) = by=20 mandating the behavior of the AC to always set the
> > = KeyRSC in=20 the 4-way handshake to zero.
> >
> > This is not a = defined=20 behavior according to the current
> > 802.11 = standard.
>=20 > Are you suggesting that we CAPWAP WG should = specifically
>=20 mandate that
> > in our CAPWAP protocol spec, e.g. = something like=20 "a CAPWAP
> compatible
> > AC MUST set KeyRSC to = zero"?=20 Otherwise, the problem still exists,
> > since not all AC=20 implementation have to follow what you described.
> = >
> >=20 Or, are you planning to take this issue to TGm for 802.11 = standard
>=20 > revision? (since based on your description, there is = essentially=20 no
> > use of the KeyRSC).
> >
> > = cheers
>=20 >
> > Cheng Hong
> >
> >
> = >
>=20 >
> > > -----Original Message-----
> > > = From:=20 Bob O'Hara (boohara) [mailto:boohara@cisco.com]
> = > >=20 Sent: Wednesday, September 27, 2006 2:32 AM
> > > To: = T.=20 Charles Clancy; Peter Nilsson J (LI/EAB)
> > > Cc: capwap@frascone.com
> = > >=20 Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> = > >=20 Considerations
> > >
> > > Charles, = Peter,
>=20 > >
> > > Below is an expansion of a snippet from = a thread=20 on this
> > topic that I
> > > sent to the list = on July=20 25, 2006.  I think this will be
> helpful = to
> >=20 > understand why the exchange that Saranavan is requesting is = not
>=20 > > necessary.  In fact, there are several systems = from=20 several
> > > manufacturers in the field using precursor = protocols to
> CAPWAP that
> > > are Wi-Fi = certified for=20 WPA2/802.11i operation using the
> > protocol as
> = > >=20 it is described below.
> > >
> > > BTW, this = whole=20 discussion is about the KeyRSC for the
> > group key, = not
>=20 > > the pairwise key.  This is so because the WTP = and AC=20 both
> know the
> > > initial sequence counter = value for=20 the pairwise key, since it has
> > > never been used to = send a=20 frame.   802.11i requires the
> first frame
> = >=20 > sent on a key to use the sequence counter value of=20 1.  See
> > 8.3.2.6=20 c)
> > > and
> > > 8.3.3.4.3 c) in 802.11i = for this=20 requirement.
> > >
> > > The same is not = true of the=20 group key, i.e., after the WTP begins
> > > operation, = the AC=20 will not know the value of the sequence
> > counter for =
>=20 > > the group key when it needs to complete the = EAPOL-key
> >=20 handshake with a
> > > newly associated STA.
> = > >=20 However, as you will see from the tutorial below, it is not
> = >=20 necessary
> > > for the AC and WTP to exchange any = information=20 about the
> group key
> > > KeyRSC for the = protocol to=20 operate as it is intended.
> > >
> > > 1. A = value=20 for the KeyRSC in the EAPOL-key frame is necessary to
> > = >=20 calculate the KeyMIC.
> > >
> > > 2. This = value does=20 not need to bear any specific
> > relationship to = the
> >=20 > RSC value maintained by the WTP.  A value of zero in = the=20
> EAPOL-key
> > > frame for the group key will = always=20 work.
> > >
> > > 3. The client STA will use = the=20 value of KeyRSC received in the
> > > EAPOL-key frame to = validate frame using the KeyMIC.
> > >
> > = > 4. The=20 client STA will also set its group key RSC to the value
> > = >=20 received in KeyRSC, say, zero.
> > >
> > > = 5. The=20 value in the client STA's RSC will be compared against the
> = >=20 > sequence number in subsequent received frames to identify=20 replay
> > > attacks.  Any frame received with = a=20 sequence counter value
> > within the
> > > = replay=20 window will be checked to have a valid MIC.  If the =
> >=20 MIC is not
> > > valid, the frame is dropped.
> = >=20 >
> > > 6. For any frame that is determined not to be = a=20 replay
> attack frame
> > > and meets all other = validity=20 and authenticity requirements,
> > the client
> > = >=20 STA updates its RSC value to the sequence number in the = received
>=20 > > frame, if the value is greater than its current RSC = value.
>=20 > Only the
> > > AP can meet these criteria as the = source of=20 a frame
> received by the
> > > STA.
> > = >
> > > 7. Please see item 6, immediately above, for = the=20 reason
> that the AC
> > > and WTP do not need to=20 coordinate and exchange the RSC.
> > >
> >=20 >
> > > The only possible attack mode is for the = attacker to=20 send
> frames to
> > > the client STA between the = time of=20 the EAPOL-key frame and
> > the first
> > > = frame=20 encrypted with the group key.
> > > During this time, = the client=20 will receive the frame and
> proceed to
> > > = validate its=20 MIC.  This is a potential attack against the STA
> = >=20 > resources.  But, the MIC validation is done in the=20 STA's
> > > 802.11 chip and consumes no more resources = than=20 receiving
> any other
> > > = frame.  Thus, the=20 attack does not actually consume any STA
> > = resources
>=20 > > beyond those of receiving a frame.
> > = >
> >=20 > This attack is not unique to the use of the value zero = for
> >=20 the KeyRSC,
> > > either.  The same attack is=20 available to an attacker at any other
> > > time, as=20 well.  It is no more nor less effective at either = time.
>=20 > >
> > > For these reasons, the protocol is not = in need=20 of any changes to
> > > address the issue raised by = Saranavan.=20
> > >
> > >  -Bob
> > = >=20 -----Original Message-----
> > > From: T. Charles Clancy = [mailto:clancy@cs.umd.edu]
>=20 > > Sent: Monday, September 25, 2006 11:37 AM
> > = > To:=20 Peter Nilsson J (LI/EAB)
> > > Cc: capwap@frascone.com
> = > >=20 Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> = > >=20 Considerations
> > >
> > > This is a very=20 interesting solution.  The AC selects the
> KeyRSC=20 and
> > > performs the 4-way handshake.  The = WTP=20 sniffs the 4-way handshake
> > > traffic and grabs the = KeyRSC=20 value and uses it to
> > initialize its own
> > = >=20 counter.
> > >
> > > Pat/Bob: Is this how = the Cisco=20 implementation works?  I
> > have to = agree
> >=20 > with Saravanan that I've yet to see a technical
> = description of=20 how
> > > Cisco implements it.
> > >
> = >=20 > IMHO, this is somewhat hackish, and it would be cleaner = to
> >=20 have the AC
> > > generate the KeyRSC and include it in = the=20 AddMobile message
> > as Behcet
> > >=20 suggests.
> > >
> > > --
> > > = t.=20 charles clancy, ph.d.  |  tcc@umd.edu  |
> www.cs.umd.edu/~clancy
>= >=20 >
> > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) = wrote:
> > >
> > > > I think Saravanan = has a=20 point. We did a prototype
> > impelementation of
> = > >=20 the
> > > > protocol a year ago when it was still = called=20 LWAPP. The way
> > > we solved
> > > > = this issue=20 then was to let the WTP sniff on all CAPWAP data
> > > = messages=20
> > > > from the AC and when message 3 of the 4-way=20 handshake or
> > > message 1 of
> > > > = the=20 groupkey handshake was sent the WTP inserted the correct RSC
> = >=20 > before
> > > > sending it off to the = supplicant. To=20 avoid the sniffing on
> > > all CAPWAP
> > > = >=20 data messages we would need a mechanism with in CAPWAP to
> = > >=20 handle these
> > > > two messages.
> > > = >
> > > > Peter Nilsson
> > > = >
>=20 > > > -----Original Message-----
> > > > = From:=20 Saravanan Govindan
> > > [mailto:Saravanan.Govindan@sg= .panasonic.com]
>=20 > > > Sent: den 22 september 2006 11:03
> > > = > To:=20 Margaret Wasserman
> > > > Cc: capwap@frascone.com
> = > >=20 > Subject: Re: [Capwap] Issue 43 - Explanation for = 802.11i
> >=20 > Considerations
> > > >
> > > > Hi = Margaret,
> > > >
> > > > Thank you = for=20 reviewing the discussion on this issue.
> > > = >
> >=20 > > The issue here is the working of IEEE 802.11i when the=20 802.11i
> > > > authenticator element is at the AC = and the=20 802.11i crypto
> > element is
> > > at
> = >=20 > > the WTP. Particularly, it is for the 4-way handshake = between=20
> > > > authenticator and supplicant.
> > = >=20 >
> > > > Now, the 4-way handshake requires = knowing the=20 value of
> > > KeyRSC sequence
> > > > = counter.=20 The KeyRSC helps both authenticator and supplicant
> > = > keep=20 track
> > > > of their exchanges. It serves to = protect=20 against threats by
> > > tracking
> > > > = sequential frames. The KeyRSC is maintained at the at the
> = > point=20 of
> > > > encryption, i.e. just before transmission = over=20 the
> > wireless channel.
> > > >
> = > >=20 > In the case of CAPWAP, the 4-way handshake is between the AC =
>=20 > > > (authenticator) and the wireless station=20 (supplicant).
> > > >
> > > > The = problem=20 arises, when the authenticator is at the AC and
> > > = the=20 crypto
> > > > element (together with KeyRSC) is at = the WTP.=20 This is a
> > > fairly common
> > > > = design.=20 Now in this case, the AC starts the 4-way
> handshake but = it
>=20 > > does
> > > > not know the value of the = KeyRSC. The=20 KeyRSC is maintained
> > > by the WTP.
> > = >=20 >
> > > > Based on this, the current CAPWAP = specification=20 does not
> > allow for a
> > > way
> > = >=20 > to conduct the 4-way handshake with the correct KeyRSC. =
> >=20 > >
> > > > The functionality I would like to = see is a=20 way for the
> > authenticator
> > > > (AC) = to use=20 the correct prevailing value of KeyRSC
> > > (maintained = by the=20
> > > > WTP) in its 4-way handshake.
> > = >=20 >
> > > > One way to introduce this functionality = in to=20 CAPWAP is
> > to have part
> > > of
> = > >=20 > the 4-way handshake be sent from AC to WTP. This will allow =
>=20 > > the 4-way
> > > > handshake to use the = correct=20 value of the KeyRSC before
> > > being sent to
> = > >=20 > the wireless station.
> > > >
> > > = > I=20 hope this helps clarify my view on the issue.
> > >=20 >
> > > > Cheers,
> > > >
> = > >=20 > Saravanan
> > > >
> > > >
> = >=20 > >
> > > >
> > > >
> = > >=20 >
> > > > -----Original Message-----
> > = >=20 > From: Margaret Wasserman [mailto:margaret@thingmagic.com]
&= gt;=20 > > > Sent: Thursday, September 21, 2006 8:26 PM
> = > >=20 > To: Saravanan Govindan
> > > > Cc: Pat Calhoun=20 (pacalhou); capwap@frascone.com
> = > >=20 > Subject: Re: [Capwap] Issue 43 - Explanation for = 802.11i
> >=20 > Considerations
> > > >
> > > = >
>=20 > > >
> > > > Hi again,
> > >=20 >
> > > > Okay, I am even more confused than I = thought I=20 was...
> > > >
> > > > Saravanan, you = wrote:
> > > >
> > > > On Sep 17, = 2006, at=20 10:24 PM, Saravanan Govindan wrote:
> > > >
> = > >=20 >> Pat,
> > > >>
> > > >> = The=20 issue here is about how 802.11i exchanges are done when
> > = >=20 >> authenticator is at the AC and crypto elements are = at
> >=20 the WTP. This
> > > is
> > > >> the=20 requirement.
> > > >
> > > > And, in = response,=20 Pat Calhoun wrote:
> > > >
> > > > On = Sep 18,=20 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote:
> > > = >>=20 The current specification allows the authenticator to
> > = >=20 reside in the
> > > >> AC, while the data packet = crypto=20 elements in the WTP. This
> > > feature is
> > = >=20 >> already in the specification.
> > > = >
> >=20 > > Pat's message matches my reading of the = specification.
>=20 > > >
> > > > So, Saravanan, what = functionality are=20 you asking for
> that is not
> > > > already = supported=20 by the specification?  And why do you
> > think = it=20 is
> > > > necessary?  it will not be = helpful to my=20 understanding to
> > > re-send your
> > > = >=20 proposal or to cite the requirements = document...  Please
>=20 > summarize
> > > > what functionality you think = is=20 missing from the current
> > > specification
> = > >=20 > and why you think that functionality is necessary to
> = support=20 IEEE
> > > > 802.11i or any important use = case.
> >=20 > >
> > > > At some point, the chairs may need = to make=20 a consensus
> > call on this
> > > > issue, = and I'd=20 like to understand your view and make sure
> > > that = it=20 has
> > > > been clearly communicated to the WG = before we ask=20 the WG to
> > > decide on
> > > > this=20 issue.
> > > >
> > > > Thanks, =
> >=20 > > Margaret
> > > >
> > > = >
>=20 > > >
> > > >
> > > >
> = >=20 > >
> > > >
>=20 _________________________________________________________________ =
>=20 > > > To unsubscribe or modify your subscription = options,
>=20 please visit:
> > > > http://lists.f= rascone.com/mailman/listinfo/capwap=20
> > > >
> > > > Archives: http://lists.frascone= .com/pipermail/capwap
>=20 > > >
>=20 _________________________________________________________________ =
>=20 > > > To unsubscribe or modify your subscription = options,
>=20 please visit:
> > > > http://lists.f= rascone.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.f= rascone.com/mailman/listinfo/capwap
>=20 > >
> > > Archives: http://lists.frascone= .com/pipermail/capwap
>=20 > >=20 = _________________________________________________________________
>= =20 > > To unsubscribe or modify your subscription options, please = visit:=20
> > > http://lists.f= rascone.com/mailman/listinfo/capwap
>=20 > >
> > > Archives: http://lists.frascone= .com/pipermail/capwap
>=20 > >
> >=20 = _________________________________________________________________
>= =20 > To unsubscribe or modify your subscription options, please = visit:=20
> > http://lists.f= rascone.com/mailman/listinfo/capwap
>=20 >
> > Archives: http://lists.frascone= .com/pipermail/capwap=20
> >
>=20 = _________________________________________________________________
>= To=20 unsubscribe or modify your subscription options, please = visit:
> http://lists.f= rascone.com/mailman/listinfo/capwap
>
>=20 Archives: http://lists.frascone= .com/pipermail/capwap
>
____________________________________= _____________________________=20
To unsubscribe or modify your subscription options, please = visit:
http://lists.f= rascone.com/mailman/listinfo/capwap

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

<= /HTML> ------_=_NextPart_001_01C6E3E1.B38DA6A9-- --===============1739222654== 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 --===============1739222654==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 29 13:16:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTLyS-0007cZ-6y for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 13:16:32 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTLyM-0004w5-Of for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 13:16:32 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id E16571448036 for ; Fri, 29 Sep 2006 10:16:08 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 41874430059 for ; Fri, 29 Sep 2006 09:50:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 06C63144803B for ; Fri, 29 Sep 2006 09:50:31 -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 0BBA6144804D for ; Fri, 29 Sep 2006 09:50:18 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so1051647pyu for ; Fri, 29 Sep 2006 09:50:18 -0700 (PDT) Received: by 10.35.21.1 with SMTP id y1mr999443pyi; Fri, 29 Sep 2006 09:50:17 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Fri, 29 Sep 2006 09:50:17 -0700 (PDT) Message-ID: <26140d940609290950w5be6fc3dk4cf5153d961b881f@mail.gmail.com> Date: Fri, 29 Sep 2006 12:50:17 -0400 From: "Michael Montemurro" To: "Bob O'Hara (boohara)" In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC02188E2C@xmb-sjc-237.amer.cisco.com> MIME-Version: 1.0 References: <17B8C6DE4E228348B4939BDA6B05A9DC02188E2C@xmb-sjc-237.amer.cisco.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.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: Saravanan Govindan , capwap@frascone.com, Cheng Hong Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0590927511==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 5ad972b4f487a18b25712571c4a63592 --===============0590927511== Content-Type: multipart/alternative; boundary="----=_Part_31885_6105742.1159548617664" ------=_Part_31885_6105742.1159548617664 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I still do not see what the problem is with section 11.3 of CAPWAP2. I follows consistently with what is in IEEE 802.11. If someone does not have suggested text changes, I recommend that we close this issue. Cheers, Mike On 9/29/06, Bob O'Hara (boohara) wrote: > > I am afraid that requesting design assistance from a competitor is very > close to violation of U.S anti-trust laws. I will not describe how Cisco > has designed any of its products and I cannot help you design yours. > > Again, your proposal does not eliminate any attack mechanism and does not > add any functionality to the protocol, only cost and complexity. A replayed > frame will be discarded by the MAC, using the normal duplicate frame > detection mechanisms. See section 8.3.3.3.2 of 802.11i (where the frame > sequence number is part of the additional authenticated data) and section > 9.2.9 of 802.11-1999 for the description of these functions. And PLEASE > read 802.11 and 802.11i before again asserting that this proposal is > necessary. > > As I said several emails ago, the ONLY effect of using zero as the value > for the KeyRSC is that the 802.11 chipset in the STA (client) will have to > receive the frame, attempt to decrypt it, and validate the MIC. This must > be done for EVERY frame received, whether it is a replayed frame or not. > This set of functions is performed in the 802.11 STA chipset and does not > consume any additional resources of the STA. So, the attack, if it can even > be characterized as an attack, is no more effective at DOSing the STA than > sending it any other frame. > > -Bob > > > > ------------------------------ > *From:* Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > *Sent:* Thursday, September 28, 2006 5:34 PM > *To:* Bob O'Hara (boohara); Dorothy Stanley > *Cc:* Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); > capwap@frascone.com; Saravanan Govindan > *Subject:* RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > > Hi Bob, > > As Dorothy correctly pointed out below, setting the KeyRSC to a value > closer to the current RSC would be better than setting it to a pre-defined > value zero. > > It is true that 802.11i and 802.1X do not specify what is the KeyRSC value > to be used, since they are trying to provide us a tool to correctly > synchronize the RSC using the Msg 3. By mandating the KeyRSC to zero, we are > just disabling the tool. It is not wrong, but just deprives the system a > designed function. > > As for the effectiveness of KeyRSC, setting it to a predefined value of 0 > would pose a greater threat. In a simple example, if the RSC is currently > 1000, and we are mandating the KeyRSC to be always zero, the attacker > basically can safely replay the last 1000 packets to the STA without being > detected. If the KeyRSC can be set to a closer value of the current RSC, > say, 900, the number of possible replayed packets can be reduced to 10 > percent, 100 packets. > > Therefore, I would say, setting the KeyRSC value to zero does place a > bigger threat. Is that how the cisco products implemented? Maybe you could > share with us some other implementation/testing data to prove otherwise. Or, > you have some other considerations that could defend the replay attack? > > cheers > > Cheng Hong > > > ------------------------------ > *From:* Bob O'Hara (boohara) [mailto:boohara@cisco.com] > *Sent:* Friday, September 29, 2006 5:21 AM > *To:* Dorothy Stanley > *Cc:* Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson > J (LI/EAB); capwap@frascone.com > *Subject:* RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > > Dorothy, > > The problem with this proposal is that it is no more effective than > sending a value of zero for the KeyRSC. It doesn't eliminate any potential > attacks. It doesn't add any functionality. However, it does add cost and > complexity to the protocol. > > -Bob > > > > ------------------------------ > *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > *Sent:* Thursday, September 28, 2006 1:17 PM > *To:* Bob O'Hara (boohara) > *Cc:* Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson > J (LI/EAB); capwap@frascone.com > *Subject:* Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > > All, > > Below is the text from 802.11REV-maD8.0 Clause 8.5.2, describing the Key > RSC field.: > > "g) Key RSC. This field is 8 octets in length. It contains the receive > sequence counter (RSC) for the > GTK being installed in IEEE 802.11. It is used in Message 3 of the 4-Way > Handshake and > Message 1 of the Group Key Handshake, where it is used to synchronize the > IEEE 802.11 replay > state. It may also be used in the Michael MIC Failure Report frame, to > report the TSC field value of > the frame experiencing a MIC failure. It shall contain 0 in other > messages. The Key RSC field gives > the current message number for the GTK, to allow a STA to identify > replayed MPDUs. If the Key > RSC field value is less than 8 octets in length, the remaining octets > shall be set to 0. The least significant > octet of the TSC or PN should be in the first octet of the Key RSC field." > > The intent of adding this value in message 3 was to immediately minimize > the number of > replayed frames that a STA would potentially process: "The Key RSC field > gives > the current message number for the GTK, to allow a STA to identify > replayed MPDUs." > Setting the value to 0 in Msg 3 does not provide the current sequence > counter (in most cases > not even close) of the GTK.. > > Perhaps the WTP could periodically/frequently notify the AC of its current > GTK sequence counter, and the > AC would use the most recently received value in the message 3 sent to new > STAs. The RSC value > would not be up to date at all times, but would be closer than "0", not > require an "in-the-critical-path > message exchange between the AC and WTP, and still be close to the > intended use of the field. > > Dorothy > > On 9/28/06, Bob O'Hara (boohara) wrote: > > > > Please understand that 802.11i specifies no behavior in this area for > > the 802.1X authenticator. Our choice to send a group key KeyRSC value > > of zero in the EAPOL-key frame requires no change to 802.11i or to > > 802.1X . It requires us to state this in the CAPWAP spec, if we want > > this behavior to be consistent across all implementations. > > > > The problem with what Bechet and Saranavan are asking is that either of > > three different things are required: > > 1: the WTP must communicate the group key TSC to the AC every time it is > > updated, or > > 2: the AC must request the current value of the group key TSC for the > > KeyRSC before constructing the EAPOL-key frame, or > > 3: the AC must send the KCK to the AC so that it can insert the KeyRSC > > value and also calculate the correct MIC, inserting that into the proper > > EAPOL-key frame. > > > > The first item requires a tremendous amount of additional CAPWAP > > communication between WTP and AC, at least one new CAPWAP packet for > > every multicast frame sent by the WTP, if the packet is not > > acknowledged, or two new CAPWAP packets, if it is acknowledged. This is > > a very expensive addition to the protocol. > > > > The second item requires new protocol between the AC and WTP during what > > can be a time critical portion of the 802.11 transition (handoff, roam) > > from one WTP to another. It also introduces a race condition that is > > not present in the protocol today. Once the value for the KeyRSC is > > sent from the WTP to the AC, it is possible that the WTP can send > > another multicast frame encrypted with the group key. This puts the > > value of the sequence counter out of sync with the value that will be > > shortly communicated to the client in the EAPOL-key frame from the AC. > > This will behave exactly the same as if a value of zero is sent in the > > EAPOL-key frame. > > > > The third item requires a new architecture split that is not required in > > > > our objectives. The new split is not splitting the MAC, but splitting > > the authenticator. Placing the KCK in the WTP is also a potential > > reduction in the security of the overall WLAN system, since these > > devices are normally not in a secured wiring closet, but exposed and > > more easily compromised than the AC. > > > > The simplest to implement, least expensive, and most secure option is to > > use the protocol as it is now specified and have the AC send a value of > > zero in the KeyRSC field of the EAPOL-key frame. > > > > -Bob > > > > -----Original Message----- > > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > > Sent: Wednesday, September 27, 2006 6:50 PM > > To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy; > > Peter Nilsson J (LI/EAB) > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > > > Hi Pat and all, > > > > So, based on this, I would say that we have consensus that setting the > > correct KeyRSC is an issue for the CAPWAP protocol design. > > > > So far, we have three option/solutions: > > > > 1) As proposed by Bob: Using a static value (0) for the KeyRSC. > > > > 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP > > > > 3) As suggested by Saravanana: Some exchange mechanism between WTP and > > AC > > > > Among the three, the first option seems the easiest. However, it > > requires a mandated Authenticator behavior(in this case AC) that is not > > mandated by 802.11. Therefore, we have to specify that (e.g. as proposed > > by Bob: "We could include a note to the effect that the group KeyRSC > > should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11, > > because otherwise there is no interoperability. For example, AC provided > > by another vendor does not have to set KeyRSC to 0 to be compliant with > > CAPWAP and 802.11i. > > > > Another implication is that we don't really understand the impact of > > mandating a static KeyRSC value. Although Bob provided an excellent > > analysis, I still have some doubts about the profoundness of the impact. > > If the KeyRSC value is as described of no use, why would it appear in > > the EAPOL frames in the first place? By mandating it to static value, > > what have we lost? Maybe some liaison letter to 802.1 or 802.11 could > > provide us a better understanding of the issue. > > > > For the last two options, I think they are both within CAPWAP's scope. > > Further analysis could help us to decide which one is better (or > > someone could propose other solutions). > > > > cheers > > > > Cheng Hong > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com] > > > Sent: Thursday, September 28, 2006 1:39 AM > > > To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; > > > Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > Bob's point is 802.11i works this way today. The AP (or in > > > this case AC) can set the RSC to whatever value it wishes. > > > Bob used zero (0) as an example. Implementations could use > > > any other value, which would require some form of > > > communication to the WTP, as suggested by Behcet. > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit > > > Cisco Systems > > > > > > > > > > > > > -----Original Message----- > > > > From: Cheng Hong [mailto: Hong.Cheng@sg.panasonic.com] > > > > Sent: Tuesday, September 26, 2006 6:03 PM > > > > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson > > > J (LI/EAB) > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > Considerations > > > > > > > > Hi Bob, > > > > > > > > If I understand your description below correct, you are proposing a > > > > solution (to the problem pointed out by > > > > Saravanan) by mandating the behavior of the AC to always set the > > > > KeyRSC in the 4-way handshake to zero. > > > > > > > > This is not a defined behavior according to the current > > > > 802.11 standard. > > > > Are you suggesting that we CAPWAP WG should specifically > > > mandate that > > > > in our CAPWAP protocol spec, e.g. something like "a CAPWAP > > > compatible > > > > AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, > > > > since not all AC implementation have to follow what you described. > > > > > > > > Or, are you planning to take this issue to TGm for 802.11 standard > > > > revision? (since based on your description, there is essentially no > > > > use of the KeyRSC). > > > > > > > > cheers > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > > > > > Sent: Wednesday, September 27, 2006 2:32 AM > > > > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB) > > > > > Cc: capwap@frascone.com > > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > > Considerations > > > > > > > > > > Charles, Peter, > > > > > > > > > > Below is an expansion of a snippet from a thread on this > > > > topic that I > > > > > sent to the list on July 25, 2006. I think this will be > > > helpful to > > > > > understand why the exchange that Saranavan is requesting is not > > > > > necessary. In fact, there are several systems from several > > > > > manufacturers in the field using precursor protocols to > > > CAPWAP that > > > > > are Wi-Fi certified for WPA2/802.11i operation using the > > > > protocol as > > > > > it is described below. > > > > > > > > > > BTW, this whole discussion is about the KeyRSC for the > > > > group key, not > > > > > the pairwise key. This is so because the WTP and AC both > > > know the > > > > > initial sequence counter value for the pairwise key, since it has > > > > > never been used to send a frame. 802.11i requires the > > > first frame > > > > > sent on a key to use the sequence counter value of 1. See > > > > 8.3.2.6 c) > > > > > and > > > > > 8.3.3.4.3 c) in 802.11i for this requirement. > > > > > > > > > > The same is not true of the group key, i.e., after the WTP begins > > > > > operation, the AC will not know the value of the sequence > > > > counter for > > > > > the group key when it needs to complete the EAPOL-key > > > > handshake with a > > > > > newly associated STA. > > > > > However, as you will see from the tutorial below, it is not > > > > necessary > > > > > for the AC and WTP to exchange any information about the > > > group key > > > > > KeyRSC for the protocol to operate as it is intended. > > > > > > > > > > 1. A value for the KeyRSC in the EAPOL-key frame 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. A value of zero in the > > > EAPOL-key > > > > > frame for the group key will always work. > > > > > > > > > > 3. The client STA will use the value of KeyRSC received in the > > > > > EAPOL-key frame to validate frame using the KeyMIC. > > > > > > > > > > 4. The client STA will also set its group key RSC to the value > > > > > received in KeyRSC, say, zero. > > > > > > > > > > 5. The value in the client STA's RSC will be compared against the > > > > > sequence number in subsequent received frames to identify replay > > > > > attacks. Any frame received with a sequence counter value > > > > within the > > > > > replay window will be checked to have a valid MIC. If the > > > > MIC is not > > > > > valid, the frame is dropped. > > > > > > > > > > 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, if the value is greater than its current RSC value. > > > > Only the > > > > > AP can meet these criteria as the source of a frame > > > received by the > > > > > STA. > > > > > > > > > > 7. Please see item 6, immediately above, for the reason > > > that the AC > > > > > and WTP do not need to coordinate and exchange the RSC. > > > > > > > > > > > > > > > The only possible attack mode is for the attacker to send > > > frames to > > > > > the client STA between the time of the EAPOL-key frame and > > > > the first > > > > > frame encrypted with the group key. > > > > > During this time, the client will receive the frame and > > > proceed to > > > > > validate its MIC. This is a potential attack against the STA > > > > > resources. But, the MIC validation is done in the STA's > > > > > 802.11 chip and consumes no more resources than receiving > > > any other > > > > > frame. Thus, the attack does not actually consume any STA > > > > resources > > > > > beyond those of receiving a frame. > > > > > > > > > > This attack is not unique to the use of the value zero for > > > > the KeyRSC, > > > > > either. The same attack is available to an attacker at any other > > > > > time, as well. It is no more nor less effective at either time. > > > > > > > > > > For these reasons, the protocol is not in need of any changes to > > > > > address the issue raised by Saranavan. > > > > > > > > > > -Bob > > > > > -----Original Message----- > > > > > From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > > > > > Sent: Monday, September 25, 2006 11:37 AM > > > > > To: Peter Nilsson J (LI/EAB) > > > > > Cc: capwap@frascone.com > > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > > Considerations > > > > > > > > > > This is a very interesting solution. The AC selects the > > > KeyRSC and > > > > > performs the 4-way handshake. The WTP sniffs the 4-way handshake > > > > > traffic and grabs the KeyRSC value and uses it to > > > > initialize its own > > > > > counter. > > > > > > > > > > Pat/Bob: Is this how the Cisco implementation works? I > > > > have to agree > > > > > with Saravanan that I've yet to see a technical > > > description of how > > > > > Cisco implements it. > > > > > > > > > > IMHO, this is somewhat hackish, and it would be cleaner to > > > > have the AC > > > > > generate the KeyRSC and include it in the AddMobile message > > > > as Behcet > > > > > suggests. > > > > > > > > > > -- > > > > > t. charles clancy, ph.d. | tcc@umd.edu | > > > www.cs.umd.edu/~clancy > > > > > > > > > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > > > > > > > > > > > I think Saravanan has a point. We did a prototype > > > > impelementation of > > > > > the > > > > > > protocol a year ago when it was still called LWAPP. The way > > > > > we solved > > > > > > this issue then was to let the WTP sniff on all CAPWAP data > > > > > messages > > > > > > from the AC and when message 3 of the 4-way handshake or > > > > > message 1 of > > > > > > the groupkey handshake was sent the WTP inserted the correct RSC > > > > > before > > > > > > sending it off to the supplicant. To avoid the sniffing on > > > > > all CAPWAP > > > > > > data messages we would need a mechanism with in CAPWAP to > > > > > handle these > > > > > > two messages. > > > > > > > > > > > > Peter Nilsson > > > > > > > > > > > > -----Original Message----- > > > > > > From: Saravanan Govindan > > > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > > > Sent: den 22 september 2006 11:03 > > > > > > To: Margaret Wasserman > > > > > > Cc: capwap@frascone.com > > > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > > Considerations > > > > > > > > > > > > Hi Margaret, > > > > > > > > > > > > Thank you for reviewing the discussion on this issue. > > > > > > > > > > > > The issue here is the working of IEEE 802.11i when the 802.11i > > > > > > authenticator element is at the AC and the 802.11i crypto > > > > element is > > > > > at > > > > > > the WTP. Particularly, it is for the 4-way handshake between > > > > > > authenticator and supplicant. > > > > > > > > > > > > Now, the 4-way handshake requires knowing the value of > > > > > KeyRSC sequence > > > > > > counter. The KeyRSC helps both authenticator and supplicant > > > > > keep track > > > > > > of their exchanges. It serves to protect against threats by > > > > > tracking > > > > > > sequential frames. The KeyRSC is maintained at the at the > > > > point of > > > > > > encryption, i.e. just before transmission over the > > > > wireless channel. > > > > > > > > > > > > In the case of CAPWAP, the 4-way handshake is between the AC > > > > > > (authenticator) and the wireless station (supplicant). > > > > > > > > > > > > The problem arises, when the authenticator is at the AC and > > > > > the crypto > > > > > > element (together with KeyRSC) is at the WTP. This is a > > > > > fairly common > > > > > > design. Now in this case, the AC starts the 4-way > > > handshake but it > > > > > does > > > > > > not know the value of the KeyRSC. The KeyRSC is maintained > > > > > by the WTP. > > > > > > > > > > > > Based on this, the current CAPWAP specification does not > > > > allow for a > > > > > way > > > > > > to conduct the 4-way handshake with the correct KeyRSC. > > > > > > > > > > > > The functionality I would like to see is a way for the > > > > authenticator > > > > > > (AC) to use the correct prevailing value of KeyRSC > > > > > (maintained by the > > > > > > WTP) in its 4-way handshake. > > > > > > > > > > > > One way to introduce this functionality in to CAPWAP is > > > > to have part > > > > > of > > > > > > the 4-way handshake be sent from AC to WTP. This will allow > > > > > the 4-way > > > > > > handshake to use the correct value of the KeyRSC before > > > > > being sent to > > > > > > the wireless station. > > > > > > > > > > > > I hope this helps clarify my view on the issue. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > > > > > > Sent: Thursday, September 21, 2006 8:26 PM > > > > > > To: Saravanan Govindan > > > > > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > > Considerations > > > > > > > > > > > > > > > > > > > > > > > > Hi again, > > > > > > > > > > > > Okay, I am even more confused than I thought I was... > > > > > > > > > > > > Saravanan, you wrote: > > > > > > > > > > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > > > > > > > > > >> Pat, > > > > > >> > > > > > >> The issue here is about how 802.11i exchanges are done when > > > > > >> authenticator is at the AC and crypto elements are at > > > > the WTP. This > > > > > is > > > > > >> the requirement. > > > > > > > > > > > > And, in response, Pat Calhoun wrote: > > > > > > > > > > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: > > > > > >> The current specification allows the authenticator to > > > > > reside in the > > > > > >> AC, while the data packet crypto elements in the WTP. This > > > > > feature is > > > > > >> already in the specification. > > > > > > > > > > > > Pat's message matches my reading of the specification. > > > > > > > > > > > > So, Saravanan, what functionality are you asking for > > > that is not > > > > > > already supported by the specification? And why do you > > > > think it is > > > > > > necessary? it will not be helpful to my understanding to > > > > > re-send your > > > > > > proposal or to cite the requirements document... Please > > > > summarize > > > > > > what functionality you think is missing from the current > > > > > specification > > > > > > and why you think that functionality is necessary to > > > support IEEE > > > > > > 802.11i or any important use case. > > > > > > > > > > > > At some point, the chairs may need to make a consensus > > > > call on this > > > > > > issue, and I'd like to understand your view and make sure > > > > > that it has > > > > > > been clearly communicated to the WG before we ask the WG to > > > > > decide on > > > > > > this issue. > > > > > > > > > > > > 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 > > > > > > > > > _________________________________________________________________ > > > > > > 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 > > > > > > > > > _________________________________________________________________ > > > > 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 > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_31885_6105742.1159548617664 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I still do not see what the problem is with section 11.3 of CAPWAP2. I follows consistently with what is in IEEE 802.11. If someone does not have suggested text changes, I recommend that we close this issue.
 
 
Cheers,
 
Mike


 
On 9/29/06, Bob O'Hara (boohara) <boohara@cisco.com> wrote:
I am afraid that requesting design assistance from a competitor is very close to violation of U.S anti-trust laws.  I will not describe how Cisco has designed any of its products and I cannot help you design yours.
 
Again, your proposal does not eliminate any attack mechanism and does not add any functionality to the protocol, only cost and complexity.  A replayed frame will be discarded by the MAC, using the normal duplicate frame detection mechanisms.  See section 8.3.3.3.2 of 802.11i (where the frame sequence number is part of the additional authenticated data) and section 9.2.9 of 802.11-1999 for the description of these functions.  And PLEASE read 802.11 and 802.11i before again asserting that this proposal is necessary.
 
As I said several emails ago, the ONLY effect of using zero as the value for the KeyRSC is that the 802.11 chipset in the STA (client) will have to receive the frame, attempt to decrypt it, and validate the MIC.  This must be done for EVERY frame received, whether it is a replayed frame or not.  This set of functions is performed in the 802.11 STA chipset and does not consume any additional resources of the STA.  So, the attack, if it can even be characterized as an attack, is no more effective at DOSing the STA than sending it any other frame.

 -Bob
 

 

From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com ]
Sent: Thursday, September 28, 2006 5:34 PM

To: Bob O'Hara (boohara); Dorothy Stanley
Cc: Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com; Saravanan Govindan
Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations

 
Hi Bob,
 
As Dorothy correctly pointed out below, setting the KeyRSC to a value closer to the current RSC would be better than setting it to a pre-defined value zero.
 
It is true that 802.11i and 802.1X do not specify what is the KeyRSC value to be used, since they are trying to provide us a tool to correctly synchronize the RSC using the Msg 3. By mandating the KeyRSC to zero, we are just disabling the tool. It is not wrong, but just deprives the system a designed function.
 
As for the effectiveness of KeyRSC, setting it to a predefined value of 0 would pose a greater threat. In a simple example, if the RSC is currently 1000, and we are mandating the KeyRSC to be always zero, the attacker basically can safely replay the last 1000 packets to the STA without being detected. If the KeyRSC can be set to a closer value of the current RSC, say, 900, the number of possible replayed packets can be reduced to 10 percent, 100 packets.
 
Therefore, I would say, setting the KeyRSC value to zero does place a bigger threat. Is that how the cisco products implemented? Maybe you could share with us some other implementation/testing data to prove otherwise. Or, you have some other considerations that could defend the replay attack?
 
cheers
 
Cheng Hong
 

From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]
Sent: Friday, September 29, 2006 5:21 AM
To: Dorothy Stanley
Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com
Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations

 
Dorothy,
 
The problem with this proposal is that it is no more effective than sending a value of zero for the KeyRSC.  It doesn't eliminate any potential attacks.  It doesn't add any functionality.  However, it does add cost and complexity to the protocol. 

 -Bob
 

 

From: Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Thursday, September 28, 2006 1:17 PM
To: Bob O'Hara (boohara)
Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

 
All,

Below is the text from 802.11REV-maD8.0 Clause 8.5.2, describing the Key RSC field.:

"g) Key RSC. This field is 8 octets in length. It contains the receive sequence counter (RSC) for the
GTK being installed in IEEE 802.11. It is used in Message 3 of the 4-Way Handshake and
Message 1 of the Group Key Handshake, where it is used to synchronize the IEEE 802.11 replay
state. It may also be used in the Michael MIC Failure Report frame, to report the TSC field value of
the frame experiencing a MIC failure. It shall contain 0 in other messages. The Key RSC field gives
the current message number for the GTK, to allow a STA to identify replayed MPDUs. If the Key
RSC field value is less than 8 octets in length, the remaining octets shall be set to 0. The least significant
octet of the TSC or PN should be in the first octet of the Key RSC field."

The intent of adding this value in message 3 was to immediately minimize the number of
replayed frames that a STA would potentially process: "The Key RSC field gives
the current message number for the GTK, to allow a STA to identify replayed MPDUs."
Setting the value to 0 in Msg 3 does not provide the current sequence counter (in most cases
not even close) of the GTK..

Perhaps the WTP could periodically/frequently notify the AC of its current GTK sequence counter, and the
AC would use the most recently received value in the message 3 sent to new STAs. The RSC value
would not be  up to date at all times, but would be closer than "0", not require an "in-the-critical-path
message exchange between the AC and WTP, and still be close to the intended use of the field.

Dorothy

On 9/28/06, Bob O'Hara (boohara) <boohara@cisco.com > wrote:
Please understand that 802.11i specifies no behavior in this area for
the 802.1X authenticator.  Our choice to send a group key KeyRSC value
of zero in the EAPOL-key frame requires no change to 802.11i or to
802.1X .  It requires us to state this in the CAPWAP spec, if we want
this behavior to be consistent across all implementations.

The problem with what Bechet and Saranavan are asking is that either of
three different things are required:
1: the WTP must communicate the group key TSC to the AC every time it is
updated, or
2: the AC must request the current value of the group key TSC for the
KeyRSC before constructing the EAPOL-key frame, or
3: the AC must send the KCK to the AC so  that it can insert the KeyRSC
value and also calculate the correct MIC, inserting that into the proper
EAPOL-key frame.

The first item requires a tremendous amount of additional CAPWAP
communication between WTP and AC, at least one new CAPWAP packet for
every multicast frame sent by the WTP, if the packet is not
acknowledged, or two new CAPWAP packets, if it is acknowledged.  This is
a very expensive addition to the protocol.

The second item requires new protocol between the AC and WTP during what
can be a time critical portion of the 802.11 transition (handoff, roam)
from one WTP to another.  It also introduces a race condition that is
not present in the protocol today.  Once the value for the KeyRSC is
sent from the WTP to the AC, it is possible that the WTP can send
another multicast frame encrypted with the group key.  This puts the
value of the sequence counter out of sync with the value that will be
shortly communicated to the client in the EAPOL-key frame from the AC.
This will behave exactly the same as if a value of zero is sent in the
EAPOL-key frame.

The third item requires a new architecture split that is not required in
our objectives.  The new split is not splitting the MAC, but splitting
the authenticator.  Placing the KCK in the WTP is also a potential
reduction in the security of the overall WLAN system, since these
devices are normally not in a secured wiring closet, but exposed and
more easily compromised than the AC.

The simplest to implement, least expensive, and most secure option is to
use the protocol as it is now specified and have the AC send a value of
zero in the KeyRSC field of the EAPOL-key frame.

-Bob

-----Original Message-----
From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com ]
Sent: Wednesday, September 27, 2006 6:50 PM
To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy;
Peter Nilsson J (LI/EAB)
Cc: capwap@frascone.com
Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Hi Pat and all,

So, based on this, I would say that we have consensus that setting the
correct KeyRSC is an issue for the CAPWAP protocol design.

So far, we have three option/solutions:

1) As proposed by Bob: Using a static value (0) for the KeyRSC.

2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP

3) As suggested by Saravanana: Some exchange mechanism between WTP and
AC

Among the three, the first option seems the easiest. However, it
requires a mandated Authenticator behavior(in this case AC) that is not
mandated by 802.11. Therefore, we have to specify that (e.g. as proposed
by Bob: "We could include a note to the effect that the group KeyRSC
should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11,
because otherwise there is no interoperability. For example, AC provided
by another vendor does not have to set KeyRSC to 0 to be compliant with
CAPWAP and 802.11i.

Another implication is that we don't really understand the impact of
mandating a static KeyRSC value. Although Bob provided an excellent
analysis, I still have some doubts about the profoundness of the impact.
If the KeyRSC value is as described of no use, why would it appear in
the EAPOL frames in the first place? By mandating it to static value,
what have we lost? Maybe some liaison letter to 802.1 or 802.11 could
provide us a better understanding of the issue.

For the last two options, I think they are both within CAPWAP's scope.
Further analysis could help us to decide which one  is better (or
someone could propose other solutions).

cheers

Cheng Hong







> -----Original Message-----
> From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com]
> Sent: Thursday, September 28, 2006 1:39 AM
> To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy;
> Peter Nilsson J (LI/EAB)
> Cc: capwap@frascone.com
> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> Considerations
>
> Bob's point is 802.11i works this way today. The AP (or in
> this case AC) can set the RSC to whatever value it wishes.
> Bob used zero (0) as an example. Implementations could use
> any other value, which would require some form of
> communication to the WTP, as suggested by Behcet.
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
>
> > -----Original Message-----
> > From: Cheng Hong [mailto: Hong.Cheng@sg.panasonic.com]
> > Sent: Tuesday, September 26, 2006 6:03 PM
> > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson
> J (LI/EAB)
> > Cc: capwap@frascone.com
> > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > Considerations
> >
> > Hi Bob,
> >
> > If I understand your description below correct, you are proposing a
> > solution (to the problem pointed out by
> > Saravanan) by mandating the behavior of the AC to always set the
> > KeyRSC in the 4-way handshake to zero.
> >
> > This is not a defined behavior according to the current
> > 802.11 standard.
> > Are you suggesting that we CAPWAP WG should specifically
> mandate that
> > in our CAPWAP protocol spec, e.g. something like "a CAPWAP
> compatible
> > AC MUST set KeyRSC to zero"? Otherwise, the problem still exists,
> > since not all AC implementation have to follow what you described.
> >
> > Or, are you planning to take this issue to TGm for 802.11 standard
> > revision? (since based on your description, there is essentially no
> > use of the KeyRSC).
> >
> > cheers
> >
> > Cheng Hong
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Bob O'Hara (boohara) [mailto: boohara@cisco.com]
> > > Sent: Wednesday, September 27, 2006 2:32 AM
> > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB)
> > > Cc: capwap@frascone.com
> > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > > Considerations
> > >
> > > Charles, Peter,
> > >
> > > Below is an expansion of a snippet from a thread on this
> > topic that I
> > > sent to the list on July 25, 2006.  I think this will be
> helpful to
> > > understand why the exchange that Saranavan is requesting is not
> > > necessary.  In fact, there are several systems from several
> > > manufacturers in the field using precursor protocols to
> CAPWAP that
> > > are Wi-Fi certified for WPA2/802.11i operation using the
> > protocol as
> > > it is described below.
> > >
> > > BTW, this whole discussion is about the KeyRSC for the
> > group key, not
> > > the pairwise key.  This is so because the WTP and AC both
> know the
> > > initial sequence counter value for the pairwise key, since it has
> > > never been used to send a frame.   802.11i requires the
> first frame
> > > sent on a key to use the sequence counter value of 1.  See
> > 8.3.2.6 c)
> > > and
> > > 8.3.3.4.3 c) in 802.11i for this requirement.
> > >
> > > The same is not true of the group key, i.e., after the WTP begins
> > > operation, the AC will not know the value of the sequence
> > counter for
> > > the group key when it needs to complete the EAPOL-key
> > handshake with a
> > > newly associated STA.
> > > However, as you will see from the tutorial below, it is not
> > necessary
> > > for the AC and WTP to exchange any information about the
> group key
> > > KeyRSC for the protocol to operate as it is intended.
> > >
> > > 1. A value for the KeyRSC in the EAPOL-key frame 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.  A value of zero in the
> EAPOL-key
> > > frame for the group key will always work.
> > >
> > > 3. The client STA will use the value of KeyRSC received in the
> > > EAPOL-key frame to validate frame using the KeyMIC.
> > >
> > > 4. The client STA will also set its group key RSC to the value
> > > received in KeyRSC, say, zero.
> > >
> > > 5. The value in the client STA's RSC will be compared against the
> > > sequence number in subsequent received frames to identify replay
> > > attacks.  Any frame received with a sequence counter value
> > within the
> > > replay window will be checked to have a valid MIC.  If the
> > MIC is not
> > > valid, the frame is dropped.
> > >
> > > 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, if the value is greater than its current RSC value.
> > Only the
> > > AP can meet these criteria as the source of a frame
> received by the
> > > STA.
> > >
> > > 7. Please see item 6, immediately above, for the reason
> that the AC
> > > and WTP do not need to coordinate and exchange the RSC.
> > >
> > >
> > > The only possible attack mode is for the attacker to send
> frames to
> > > the client STA between the time of the EAPOL-key frame and
> > the first
> > > frame encrypted with the group key.
> > > During this time, the client will receive the frame and
> proceed to
> > > validate its MIC.  This is a potential attack against the STA
> > > resources.  But, the MIC validation is done in the STA's
> > > 802.11 chip and consumes no more resources than receiving
> any other
> > > frame.  Thus, the attack does not actually consume any STA
> > resources
> > > beyond those of receiving a frame.
> > >
> > > This attack is not unique to the use of the value zero for
> > the KeyRSC,
> > > either.  The same attack is available to an attacker at any other
> > > time, as well.  It is no more nor less effective at either time.
> > >
> > > For these reasons, the protocol is not in need of any changes to
> > > address the issue raised by Saranavan.
> > >
> > >  -Bob
> > > -----Original Message-----
> > > From: T. Charles Clancy [mailto: clancy@cs.umd.edu]
> > > Sent: Monday, September 25, 2006 11:37 AM
> > > To: Peter Nilsson J (LI/EAB)
> > > Cc: capwap@frascone.com
> > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > > Considerations
> > >
> > > This is a very interesting solution.  The AC selects the
> KeyRSC and
> > > performs the 4-way handshake.  The WTP sniffs the 4-way handshake
> > > traffic and grabs the KeyRSC value and uses it to
> > initialize its own
> > > counter.
> > >
> > > Pat/Bob: Is this how the Cisco implementation works?  I
> > have to agree
> > > with Saravanan that I've yet to see a technical
> description of how
> > > Cisco implements it.
> > >
> > > IMHO, this is somewhat hackish, and it would be cleaner to
> > have the AC
> > > generate the KeyRSC and include it in the AddMobile message
> > as Behcet
> > > suggests.
> > >
> > > --
> > > t. charles clancy, ph.d.  |  tcc@umd.edu   |
> www.cs.umd.edu/~clancy
> > >
> > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote:
> > >
> > > > I think Saravanan has a point. We did a prototype
> > impelementation of
> > > the
> > > > protocol a year ago when it was still called LWAPP. The way
> > > we solved
> > > > this issue then was to let the WTP sniff on all CAPWAP data
> > > messages
> > > > from the AC and when message 3 of the 4-way handshake or
> > > message 1 of
> > > > the groupkey handshake was sent the WTP inserted the correct RSC
> > > before
> > > > sending it off to the supplicant. To avoid the sniffing on
> > > all CAPWAP
> > > > data messages we would need a mechanism with in CAPWAP to
> > > handle these
> > > > two messages.
> > > >
> > > > Peter Nilsson
> > > >
> > > > -----Original Message-----
> > > > From: Saravanan Govindan
> > > [mailto: Saravanan.Govindan@sg.panasonic.com]
> > > > Sent: den 22 september 2006 11:03
> > > > To: Margaret Wasserman
> > > > Cc: capwap@frascone.com
> > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > > Considerations
> > > >
> > > > Hi Margaret,
> > > >
> > > > Thank you for reviewing the discussion on this issue.
> > > >
> > > > The issue here is the working of IEEE 802.11i when the 802.11i
> > > > authenticator element is at the AC and the 802.11i crypto
> > element is
> > > at
> > > > the WTP. Particularly, it is for the 4-way handshake between
> > > > authenticator and supplicant.
> > > >
> > > > Now, the 4-way handshake requires knowing the value of
> > > KeyRSC sequence
> > > > counter. The KeyRSC helps both authenticator and supplicant
> > > keep track
> > > > of their exchanges. It serves to protect against threats by
> > > tracking
> > > > sequential frames. The KeyRSC is maintained at the at the
> > point of
> > > > encryption, i.e. just before transmission over the
> > wireless channel.
> > > >
> > > > In the case of CAPWAP, the 4-way handshake is between the AC
> > > > (authenticator) and the wireless station (supplicant).
> > > >
> > > > The problem arises, when the authenticator is at the AC and
> > > the crypto
> > > > element (together with KeyRSC) is at the WTP. This is a
> > > fairly common
> > > > design. Now in this case, the AC starts the 4-way
> handshake but it
> > > does
> > > > not know the value of the KeyRSC. The KeyRSC is maintained
> > > by the WTP.
> > > >
> > > > Based on this, the current CAPWAP specification does not
> > allow for a
> > > way
> > > > to conduct the 4-way handshake with the correct KeyRSC.
> > > >
> > > > The functionality I would like to see is a way for the
> > authenticator
> > > > (AC) to use the correct prevailing value of KeyRSC
> > > (maintained by the
> > > > WTP) in its 4-way handshake.
> > > >
> > > > One way to introduce this functionality in to CAPWAP is
> > to have part
> > > of
> > > > the 4-way handshake be sent from AC to WTP. This will allow
> > > the 4-way
> > > > handshake to use the correct value of the KeyRSC before
> > > being sent to
> > > > the wireless station.
> > > >
> > > > I hope this helps clarify my view on the issue.
> > > >
> > > > Cheers,
> > > >
> > > > Saravanan
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Margaret Wasserman [mailto: margaret@thingmagic.com]
> > > > Sent: Thursday, September 21, 2006 8:26 PM
> > > > To: Saravanan Govindan
> > > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com
> > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > > Considerations
> > > >
> > > >
> > > >
> > > > Hi again,
> > > >
> > > > Okay, I am even more confused than I thought I was...
> > > >
> > > > Saravanan, you wrote:
> > > >
> > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote:
> > > >
> > > >> Pat,
> > > >>
> > > >> The issue here is about how 802.11i exchanges are done when
> > > >> authenticator is at the AC and crypto elements are at
> > the WTP. This
> > > is
> > > >> the requirement.
> > > >
> > > > And, in response, Pat Calhoun wrote:
> > > >
> > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote:
> > > >> The current specification allows the authenticator to
> > > reside in the
> > > >> AC, while the data packet crypto elements in the WTP. This
> > > feature is
> > > >> already in the specification.
> > > >
> > > > Pat's message matches my reading of the specification.
> > > >
> > > > So, Saravanan, what functionality are you asking for
> that is not
> > > > already supported by the specification?  And why do you
> > think it is
> > > > necessary?  it will not be helpful to my understanding to
> > > re-send your
> > > > proposal or to cite the requirements document...  Please
> > summarize
> > > > what functionality you think is missing from the current
> > > specification
> > > > and why you think that functionality is necessary to
> support IEEE
> > > > 802.11i or any important use case.
> > > >
> > > > At some point, the chairs may need to make a consensus
> > call on this
> > > > issue, and I'd like to understand your view and make sure
> > > that it has
> > > > been clearly communicated to the WG before we ask the WG to
> > > decide on
> > > > this issue.
> > > >
> > > > 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
> > > >
> _________________________________________________________________
> > > > 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
> > >
> > _________________________________________________________________
> > 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


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

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


------=_Part_31885_6105742.1159548617664-- --===============0590927511== 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 --===============0590927511==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 29 15:10:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTNl1-0007Ki-RC for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 15:10:47 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTNkz-0002pU-Iu for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 15:10:47 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 279AE39809A for ; Fri, 29 Sep 2006 12:10:34 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id ADAE2430059 for ; Fri, 29 Sep 2006 12:07:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9B16D1448036 for ; Fri, 29 Sep 2006 12:07:22 -0700 (PDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by hermes.tigertech.net (Postfix) with ESMTP id EF2CF144803B for ; Fri, 29 Sep 2006 12:07:16 -0700 (PDT) Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id k8TJ6nle026883; Fri, 29 Sep 2006 15:06:50 -0400 (EDT) Date: Fri, 29 Sep 2006 15:06:49 -0400 (EDT) From: "T. Charles Clancy" To: Cheng Hong In-Reply-To: <5F09D220B62F79418461A978CA0921BD012F1F7F@pslexc01.psl.local> Message-ID: References: <5F09D220B62F79418461A978CA0921BD012F1F7F@pslexc01.psl.local> 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.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: capwap@frascone.com, Saravanan Govindan Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 39821207e2a2cade5c69c89d23fb80ee All, I'm glad to see we're finally arguing about the right issue. As discussed, the Cisco solution to the problem is "set it to zero". Certainly sniffing the value works as well. From a security standpoint either is just fine. We do have an interoperability issue, however, if a Cisco WTP were used with an AC that's randomly generating a KeyRSC and expecting the WTP to sniff it. So, I think some text is necessary to address the issue. What remains are two entrenched opinions about protocol flexibility vs simplicity, neither of which would significantly tilt the flexibility vs simplicity balance in either of direction. Let's flip a coin and move on to more important issues. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy On Fri, 29 Sep 2006, Cheng Hong wrote: > Hi Bob, > > As Dorothy correctly pointed out below, setting the KeyRSC to a value > closer to the current RSC would be better than setting it to a > pre-defined value zero. > > It is true that 802.11i and 802.1X do not specify what is the KeyRSC > value to be used, since they are trying to provide us a tool to > correctly synchronize the RSC using the Msg 3. By mandating the KeyRSC > to zero, we are just disabling the tool. It is not wrong, but just > deprives the system a designed function. > > As for the effectiveness of KeyRSC, setting it to a predefined value of > 0 would pose a greater threat. In a simple example, if the RSC is > currently 1000, and we are mandating the KeyRSC to be always zero, the > attacker basically can safely replay the last 1000 packets to the STA > without being detected. If the KeyRSC can be set to a closer value of > the current RSC, say, 900, the number of possible replayed packets can > be reduced to 10 percent, 100 packets. > > Therefore, I would say, setting the KeyRSC value to zero does place a > bigger threat. Is that how the cisco products implemented? Maybe you > could share with us some other implementation/testing data to prove > otherwise. Or, you have some other considerations that could defend the > replay attack? > > cheers > > Cheng Hong > > > > _____ > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > Sent: Friday, September 29, 2006 5:21 AM > To: Dorothy Stanley > Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson > J (LI/EAB); capwap@frascone.com > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > > Dorothy, > > The problem with this proposal is that it is no more effective than > sending a value of zero for the KeyRSC. It doesn't eliminate any > potential attacks. It doesn't add any functionality. However, it does > add cost and complexity to the protocol. > > -Bob > > > > > _____ > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > Sent: Thursday, September 28, 2006 1:17 PM > To: Bob O'Hara (boohara) > Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson > J (LI/EAB); capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > > All, > > Below is the text from 802.11REV-maD8.0 Clause 8.5.2, describing the Key > RSC field.: > > "g) Key RSC. This field is 8 octets in length. It contains the receive > sequence counter (RSC) for the > GTK being installed in IEEE 802.11. It is used in Message 3 of the 4-Way > Handshake and > Message 1 of the Group Key Handshake, where it is used to synchronize > the IEEE 802.11 replay > state. It may also be used in the Michael MIC Failure Report frame, to > report the TSC field value of > the frame experiencing a MIC failure. It shall contain 0 in other > messages. The Key RSC field gives > the current message number for the GTK, to allow a STA to identify > replayed MPDUs. If the Key > RSC field value is less than 8 octets in length, the remaining octets > shall be set to 0. The least significant > octet of the TSC or PN should be in the first octet of the Key RSC > field." > > The intent of adding this value in message 3 was to immediately minimize > the number of > replayed frames that a STA would potentially process: "The Key RSC field > gives > the current message number for the GTK, to allow a STA to identify > replayed MPDUs." > Setting the value to 0 in Msg 3 does not provide the current sequence > counter (in most cases > not even close) of the GTK.. > > Perhaps the WTP could periodically/frequently notify the AC of its > current GTK sequence counter, and the > AC would use the most recently received value in the message 3 sent to > new STAs. The RSC value > would not be up to date at all times, but would be closer than "0", not > require an "in-the-critical-path > message exchange between the AC and WTP, and still be close to the > intended use of the field. > > Dorothy > > > On 9/28/06, Bob O'Hara (boohara) wrote: > > Please understand that 802.11i specifies no behavior in this area for > the 802.1X authenticator. Our choice to send a group key KeyRSC value > of zero in the EAPOL-key frame requires no change to 802.11i or to > 802.1X . It requires us to state this in the CAPWAP spec, if we want > this behavior to be consistent across all implementations. > > The problem with what Bechet and Saranavan are asking is that either of > three different things are required: > 1: the WTP must communicate the group key TSC to the AC every time it is > updated, or > 2: the AC must request the current value of the group key TSC for the > KeyRSC before constructing the EAPOL-key frame, or > 3: the AC must send the KCK to the AC so that it can insert the KeyRSC > value and also calculate the correct MIC, inserting that into the proper > EAPOL-key frame. > > The first item requires a tremendous amount of additional CAPWAP > communication between WTP and AC, at least one new CAPWAP packet for > every multicast frame sent by the WTP, if the packet is not > acknowledged, or two new CAPWAP packets, if it is acknowledged. This is > a very expensive addition to the protocol. > > The second item requires new protocol between the AC and WTP during what > can be a time critical portion of the 802.11 transition (handoff, roam) > from one WTP to another. It also introduces a race condition that is > not present in the protocol today. Once the value for the KeyRSC is > sent from the WTP to the AC, it is possible that the WTP can send > another multicast frame encrypted with the group key. This puts the > value of the sequence counter out of sync with the value that will be > shortly communicated to the client in the EAPOL-key frame from the AC. > This will behave exactly the same as if a value of zero is sent in the > EAPOL-key frame. > > The third item requires a new architecture split that is not required in > > our objectives. The new split is not splitting the MAC, but splitting > the authenticator. Placing the KCK in the WTP is also a potential > reduction in the security of the overall WLAN system, since these > devices are normally not in a secured wiring closet, but exposed and > more easily compromised than the AC. > > The simplest to implement, least expensive, and most secure option is to > use the protocol as it is now specified and have the AC send a value of > zero in the KeyRSC field of the EAPOL-key frame. > > -Bob > > -----Original Message----- > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > Sent: Wednesday, September 27, 2006 6:50 PM > To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy; > Peter Nilsson J (LI/EAB) > Cc: capwap@frascone.com > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > Hi Pat and all, > > So, based on this, I would say that we have consensus that setting the > correct KeyRSC is an issue for the CAPWAP protocol design. > > So far, we have three option/solutions: > > 1) As proposed by Bob: Using a static value (0) for the KeyRSC. > > 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP > > 3) As suggested by Saravanana: Some exchange mechanism between WTP and > AC > > Among the three, the first option seems the easiest. However, it > requires a mandated Authenticator behavior(in this case AC) that is not > mandated by 802.11. Therefore, we have to specify that (e.g. as proposed > by Bob: "We could include a note to the effect that the group KeyRSC > should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11, > because otherwise there is no interoperability. For example, AC provided > by another vendor does not have to set KeyRSC to 0 to be compliant with > CAPWAP and 802.11i. > > Another implication is that we don't really understand the impact of > mandating a static KeyRSC value. Although Bob provided an excellent > analysis, I still have some doubts about the profoundness of the impact. > If the KeyRSC value is as described of no use, why would it appear in > the EAPOL frames in the first place? By mandating it to static value, > what have we lost? Maybe some liaison letter to 802.1 or 802.11 could > provide us a better understanding of the issue. > > For the last two options, I think they are both within CAPWAP's scope. > Further analysis could help us to decide which one is better (or > someone could propose other solutions). > > cheers > > Cheng Hong > > > > > > > >> -----Original Message----- >> From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com] >> Sent: Thursday, September 28, 2006 1:39 AM >> To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; >> Peter Nilsson J (LI/EAB) >> Cc: capwap@frascone.com >> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >> Considerations >> >> Bob's point is 802.11i works this way today. The AP (or in >> this case AC) can set the RSC to whatever value it wishes. >> Bob used zero (0) as an example. Implementations could use >> any other value, which would require some form of >> communication to the WTP, as suggested by Behcet. >> >> Pat Calhoun >> CTO, Wireless Networking Business Unit >> Cisco Systems >> >> >> >>> -----Original Message----- >>> From: Cheng Hong [mailto: > Hong.Cheng@sg.panasonic.com] >>> Sent: Tuesday, September 26, 2006 6:03 PM >>> To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson >> J (LI/EAB) >>> Cc: capwap@frascone.com >>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>> Considerations >>> >>> Hi Bob, >>> >>> If I understand your description below correct, you are proposing a >>> solution (to the problem pointed out by >>> Saravanan) by mandating the behavior of the AC to always set the >>> KeyRSC in the 4-way handshake to zero. >>> >>> This is not a defined behavior according to the current >>> 802.11 standard. >>> Are you suggesting that we CAPWAP WG should specifically >> mandate that >>> in our CAPWAP protocol spec, e.g. something like "a CAPWAP >> compatible >>> AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, >>> since not all AC implementation have to follow what you described. >>> >>> Or, are you planning to take this issue to TGm for 802.11 standard >>> revision? (since based on your description, there is essentially no >>> use of the KeyRSC). >>> >>> cheers >>> >>> Cheng Hong >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] >>>> Sent: Wednesday, September 27, 2006 2:32 AM >>>> To: T. Charles Clancy; Peter Nilsson J (LI/EAB) >>>> Cc: capwap@frascone.com >>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>> Considerations >>>> >>>> Charles, Peter, >>>> >>>> Below is an expansion of a snippet from a thread on this >>> topic that I >>>> sent to the list on July 25, 2006. I think this will be >> helpful to >>>> understand why the exchange that Saranavan is requesting is not >>>> necessary. In fact, there are several systems from several >>>> manufacturers in the field using precursor protocols to >> CAPWAP that >>>> are Wi-Fi certified for WPA2/802.11i operation using the >>> protocol as >>>> it is described below. >>>> >>>> BTW, this whole discussion is about the KeyRSC for the >>> group key, not >>>> the pairwise key. This is so because the WTP and AC both >> know the >>>> initial sequence counter value for the pairwise key, since it has >>>> never been used to send a frame. 802.11i requires the >> first frame >>>> sent on a key to use the sequence counter value of 1. See >>> 8.3.2.6 c) >>>> and >>>> 8.3.3.4.3 c) in 802.11i for this requirement. >>>> >>>> The same is not true of the group key, i.e., after the WTP begins >>>> operation, the AC will not know the value of the sequence >>> counter for >>>> the group key when it needs to complete the EAPOL-key >>> handshake with a >>>> newly associated STA. >>>> However, as you will see from the tutorial below, it is not >>> necessary >>>> for the AC and WTP to exchange any information about the >> group key >>>> KeyRSC for the protocol to operate as it is intended. >>>> >>>> 1. A value for the KeyRSC in the EAPOL-key frame 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. A value of zero in the >> EAPOL-key >>>> frame for the group key will always work. >>>> >>>> 3. The client STA will use the value of KeyRSC received in the >>>> EAPOL-key frame to validate frame using the KeyMIC. >>>> >>>> 4. The client STA will also set its group key RSC to the value >>>> received in KeyRSC, say, zero. >>>> >>>> 5. The value in the client STA's RSC will be compared against the >>>> sequence number in subsequent received frames to identify replay >>>> attacks. Any frame received with a sequence counter value >>> within the >>>> replay window will be checked to have a valid MIC. If the >>> MIC is not >>>> valid, the frame is dropped. >>>> >>>> 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, if the value is greater than its current RSC value. >>> Only the >>>> AP can meet these criteria as the source of a frame >> received by the >>>> STA. >>>> >>>> 7. Please see item 6, immediately above, for the reason >> that the AC >>>> and WTP do not need to coordinate and exchange the RSC. >>>> >>>> >>>> The only possible attack mode is for the attacker to send >> frames to >>>> the client STA between the time of the EAPOL-key frame and >>> the first >>>> frame encrypted with the group key. >>>> During this time, the client will receive the frame and >> proceed to >>>> validate its MIC. This is a potential attack against the STA >>>> resources. But, the MIC validation is done in the STA's >>>> 802.11 chip and consumes no more resources than receiving >> any other >>>> frame. Thus, the attack does not actually consume any STA >>> resources >>>> beyond those of receiving a frame. >>>> >>>> This attack is not unique to the use of the value zero for >>> the KeyRSC, >>>> either. The same attack is available to an attacker at any other >>>> time, as well. It is no more nor less effective at either time. >>>> >>>> For these reasons, the protocol is not in need of any changes to >>>> address the issue raised by Saranavan. >>>> >>>> -Bob >>>> -----Original Message----- >>>> From: T. Charles Clancy [mailto:clancy@cs.umd.edu] >>>> Sent: Monday, September 25, 2006 11:37 AM >>>> To: Peter Nilsson J (LI/EAB) >>>> Cc: capwap@frascone.com >>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>> Considerations >>>> >>>> This is a very interesting solution. The AC selects the >> KeyRSC and >>>> performs the 4-way handshake. The WTP sniffs the 4-way handshake >>>> traffic and grabs the KeyRSC value and uses it to >>> initialize its own >>>> counter. >>>> >>>> Pat/Bob: Is this how the Cisco implementation works? I >>> have to agree >>>> with Saravanan that I've yet to see a technical >> description of how >>>> Cisco implements it. >>>> >>>> IMHO, this is somewhat hackish, and it would be cleaner to >>> have the AC >>>> generate the KeyRSC and include it in the AddMobile message >>> as Behcet >>>> suggests. >>>> >>>> -- >>>> t. charles clancy, ph.d. | tcc@umd.edu | >> www.cs.umd.edu/~clancy >>>> >>>> On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: >>>> >>>>> I think Saravanan has a point. We did a prototype >>> impelementation of >>>> the >>>>> protocol a year ago when it was still called LWAPP. The way >>>> we solved >>>>> this issue then was to let the WTP sniff on all CAPWAP data >>>> messages >>>>> from the AC and when message 3 of the 4-way handshake or >>>> message 1 of >>>>> the groupkey handshake was sent the WTP inserted the correct RSC >>>> before >>>>> sending it off to the supplicant. To avoid the sniffing on >>>> all CAPWAP >>>>> data messages we would need a mechanism with in CAPWAP to >>>> handle these >>>>> two messages. >>>>> >>>>> Peter Nilsson >>>>> >>>>> -----Original Message----- >>>>> From: Saravanan Govindan >>>> [mailto:Saravanan.Govindan@sg.panasonic.com] >>>>> Sent: den 22 september 2006 11:03 >>>>> To: Margaret Wasserman >>>>> Cc: capwap@frascone.com >>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>> Considerations >>>>> >>>>> Hi Margaret, >>>>> >>>>> Thank you for reviewing the discussion on this issue. >>>>> >>>>> The issue here is the working of IEEE 802.11i when the 802.11i >>>>> authenticator element is at the AC and the 802.11i crypto >>> element is >>>> at >>>>> the WTP. Particularly, it is for the 4-way handshake between >>>>> authenticator and supplicant. >>>>> >>>>> Now, the 4-way handshake requires knowing the value of >>>> KeyRSC sequence >>>>> counter. The KeyRSC helps both authenticator and supplicant >>>> keep track >>>>> of their exchanges. It serves to protect against threats by >>>> tracking >>>>> sequential frames. The KeyRSC is maintained at the at the >>> point of >>>>> encryption, i.e. just before transmission over the >>> wireless channel. >>>>> >>>>> In the case of CAPWAP, the 4-way handshake is between the AC >>>>> (authenticator) and the wireless station (supplicant). >>>>> >>>>> The problem arises, when the authenticator is at the AC and >>>> the crypto >>>>> element (together with KeyRSC) is at the WTP. This is a >>>> fairly common >>>>> design. Now in this case, the AC starts the 4-way >> handshake but it >>>> does >>>>> not know the value of the KeyRSC. The KeyRSC is maintained >>>> by the WTP. >>>>> >>>>> Based on this, the current CAPWAP specification does not >>> allow for a >>>> way >>>>> to conduct the 4-way handshake with the correct KeyRSC. >>>>> >>>>> The functionality I would like to see is a way for the >>> authenticator >>>>> (AC) to use the correct prevailing value of KeyRSC >>>> (maintained by the >>>>> WTP) in its 4-way handshake. >>>>> >>>>> One way to introduce this functionality in to CAPWAP is >>> to have part >>>> of >>>>> the 4-way handshake be sent from AC to WTP. This will allow >>>> the 4-way >>>>> handshake to use the correct value of the KeyRSC before >>>> being sent to >>>>> the wireless station. >>>>> >>>>> I hope this helps clarify my view on the issue. >>>>> >>>>> Cheers, >>>>> >>>>> Saravanan >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Margaret Wasserman [mailto:margaret@thingmagic.com] >>>>> Sent: Thursday, September 21, 2006 8:26 PM >>>>> To: Saravanan Govindan >>>>> Cc: Pat Calhoun (pacalhou); capwap@frascone.com >>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>> Considerations >>>>> >>>>> >>>>> >>>>> Hi again, >>>>> >>>>> Okay, I am even more confused than I thought I was... >>>>> >>>>> Saravanan, you wrote: >>>>> >>>>> On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: >>>>> >>>>>> Pat, >>>>>> >>>>>> The issue here is about how 802.11i exchanges are done when >>>>>> authenticator is at the AC and crypto elements are at >>> the WTP. This >>>> is >>>>>> the requirement. >>>>> >>>>> And, in response, Pat Calhoun wrote: >>>>> >>>>> On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: >>>>>> The current specification allows the authenticator to >>>> reside in the >>>>>> AC, while the data packet crypto elements in the WTP. This >>>> feature is >>>>>> already in the specification. >>>>> >>>>> Pat's message matches my reading of the specification. >>>>> >>>>> So, Saravanan, what functionality are you asking for >> that is not >>>>> already supported by the specification? And why do you >>> think it is >>>>> necessary? it will not be helpful to my understanding to >>>> re-send your >>>>> proposal or to cite the requirements document... Please >>> summarize >>>>> what functionality you think is missing from the current >>>> specification >>>>> and why you think that functionality is necessary to >> support IEEE >>>>> 802.11i or any important use case. >>>>> >>>>> At some point, the chairs may need to make a consensus >>> call on this >>>>> issue, and I'd like to understand your view and make sure >>>> that it has >>>>> been clearly communicated to the WG before we ask the WG to >>>> decide on >>>>> this issue. >>>>> >>>>> 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 >>>>> >> _________________________________________________________________ >>>>> 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 >>>> >>> _________________________________________________________________ >>> 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 > > > > _________________________________________________________________ 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 Sep 29 16:32:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTP2B-0000MN-7P for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 16:32:35 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTP27-00079I-3k for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 16:32:35 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id B4F7C3980DF for ; Fri, 29 Sep 2006 13:32:29 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 13ECD430059 for ; Fri, 29 Sep 2006 13:28:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F342C1448010 for ; Fri, 29 Sep 2006 13:28:22 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by hermes.tigertech.net (Postfix) with ESMTP id 0614D1448035 for ; Fri, 29 Sep 2006 13:28:18 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so1073212nfb for ; Fri, 29 Sep 2006 13:28:17 -0700 (PDT) Received: by 10.49.41.12 with SMTP id t12mr1315375nfj; Fri, 29 Sep 2006 13:28:17 -0700 (PDT) Received: by 10.49.42.6 with HTTP; Fri, 29 Sep 2006 13:28:17 -0700 (PDT) Message-ID: <5bfe7a820609291328p521eb6easd0b38f3828df5ed6@mail.gmail.com> Date: Fri, 29 Sep 2006 13:28:17 -0700 From: "Dorothy Stanley" To: sujay , "Saravanan Govindan" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A202876BAF@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A202876BAF@xmb-sjc-235.amer.cisco.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=1.0 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Editorial - WTP Event Request X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============2053328727==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 --===============2053328727== Content-Type: multipart/alternative; boundary="----=_Part_18043_3453944.1159561697461" ------=_Part_18043_3453944.1159561697461 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, Below is the proposed resolution to issue 225 (also copied below). Comments welcome. Dorothy ----------------------------------------------------------------------------------------- Proposed resolution: Insert the following paragraph at the end of section 4.3 "CAPWAP Control Messages" "CAPWAP control messages sent from the WTP to the AC indicate that the WTP is operational, providing an implicit keep-alive mechanism for the WTP. The Echo Request/Echo Response Control channel management messages provide an explicit keep-alive mechanism when other CAPWAP control messages are not exchanged." Also - I notice that the message types in 4.3 are not the same as the message sections. Propose to update the 4.3 list to match the existing text sections: changeFirmware Management to Device Management, add missing Join, Control Channel Management bullet items. ------------------------------------------------------------------------------------------------ Issue 225: 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 From: Scott G Kelly [mailto:scott [at] 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)." > On 9/25/06, Pat Calhoun (pacalhou) wrote: > > I have created issue 225 to track this request. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > ------------------------------ > *From:* Pat Calhoun (pacalhou) > *Sent:* Monday, August 28, 2006 10:36 AM > *To:* sujay; Saravanan Govindan; capwap@frascone.com > *Subject:* Re: [Capwap] Editorial - WTP Event Request > > > I believe the quoted text is the agreed upon text. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > ------------------------------ > *From:* sujay [mailto:sujayg@huawei.com] > *Sent:* Sunday, August 27, 2006 11:18 PM > *To:* 'Saravanan Govindan'; capwap@frascone.com > *Subject:* Re: [Capwap] Editorial - WTP Event Request > > > Saravanan, > > > "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)." > > As the understanding is, arrival of *any* authenticated control message > obviates > the need for an 'echo request' message, to keep up the neighbour as up. > I wouldn't prefer the last statement..viz.. > "In cases where regular CAPWAP control messages are not exchanged, > explicit keep alive is used (see > Section 7)." > This kind of sounds making the keep alive and control message usage > mutually exclusive. Could we put > more simpler, " CAPWAP control messages MAY/SHOULD be treated equivalent > to an Echo request message > received(See Section 7)" , > Again noting; WTP event request message is just one of those possible > control messages. > > Regds, > Sujay G > My Location; > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=h&hl=en > > > This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! > > > > ------------------------------ > *From:* Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > *Sent:* Monday, August 28, 2006 8:54 AM > *To:* capwap@frascone.com > *Subject:* [Capwap] Editorial - WTP Event Request > > > > All, > > > > This is a follow-up on an earlier thread; > > > > http://lists.frascone.com/pipermail/capwap/msg03208.html > > > > Is the proposal ok for the next draft? > > > > Cheers, > > > Saravanan > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_18043_3453944.1159561697461 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
All,
 
Below is the proposed resolution to issue 225 (also copied below).
 
Comments welcome.
 
Dorothy
 
-----------------------------------------------------------------------------------------
Proposed resolution:
 
Insert the following paragraph at the end of section 4.3 "CAPWAP Control Messages"
 
"CAPWAP control messages sent from the WTP to the AC indicate that
the WTP is operational, providing an implicit keep-alive
mechanism for the WTP. The Echo Request/Echo Response Control channel
management messages provide an explicit keep-alive mechanism when other CAPWAP
control messages are not exchanged."
 
Also - I notice that the message types in 4.3 are not the same as the
message sections. Propose to update the 4.3 list to match the existing text sections:
changeFirmware Management to Device Management, add
missing Join, Control Channel Management bullet items.
 
------------------------------------------------------------------------------------------------
Issue 225:
 
 
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
From: Scott G Kelly [mailto:scott [at] 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)."
> 
 

On 9/25/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
I have created issue 225 to track this request.
 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

From: Pat Calhoun (pacalhou)
Sent: Monday, August 28, 2006 10:36 AM
To: sujay; Saravanan Govindan; capwap@frascone.com
Subject: Re: [Capwap] Editorial - WTP Event Request

 
I believe the quoted text is the agreed upon text.
 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

From: sujay [mailto:sujayg@huawei.com]
Sent: Sunday, August 27, 2006 11:18 PM
To: 'Saravanan Govindan'; capwap@frascone.com
Subject: Re: [Capwap] Editorial - WTP Event Request

 
Saravanan,
 
<snip> 
"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)."<snip/>
 
As the understanding is, arrival of *any* authenticated control message obviates
the need for an 'echo request' message, to keep up the neighbour as up.
 I wouldn't prefer the last statement..viz..
"In cases where regular CAPWAP control messages are not exchanged, explicit keep alive is used (see
Section 7)."
This kind of sounds making the keep alive and control message usage mutually exclusive. Could we put
more simpler, " CAPWAP control messages MAY/SHOULD  be treated equivalent to an Echo request message
received(See Section 7)" ,
Again noting; WTP event request message is just one of those possible control messages.
Regds,
Sujay G

My Location;
http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=h&hl=en



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

From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com ]
Sent: Monday, August 28, 2006 8:54 AM
To: capwap@frascone.com
Subject: [Capwap] Editorial - WTP Event Request

 

All,

 

This is a follow-up on an earlier thread;

 

http://lists.frascone.com/pipermail/capwap/msg03208.html

 

Is the proposal ok for the next draft?

 

Cheers,


Saravanan


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

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


------=_Part_18043_3453944.1159561697461-- --===============2053328727== 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 --===============2053328727==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 29 16:47:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTPGP-0000c0-Tt for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 16:47:17 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTPGN-00010t-JO for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 16:47:17 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 14D3F39804B for ; Fri, 29 Sep 2006 13:47:15 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3B91B430059 for ; Fri, 29 Sep 2006 13:44:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2E56339801B for ; Fri, 29 Sep 2006 13:44:28 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by zoidberg.tigertech.net (Postfix) with ESMTP id 28BCB398016 for ; Fri, 29 Sep 2006 13:43:30 -0700 (PDT) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 29 Sep 2006 13:43:30 -0700 X-IronPort-AV: i="4.09,238,1157353200"; d="scan'208"; a="44183889:sNHT101349852" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TKhTIt010803; Fri, 29 Sep 2006 16:43:30 -0400 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8TKhTQV008869; Fri, 29 Sep 2006 13:43:29 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Sep 2006 13:43:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Sep 2006 13:43:28 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2028E9C5D@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: Acbj+n3gq2SIRXsHSr+FYHXLAphX7wADQhOQ From: "Pat Calhoun (pacalhou)" To: "T. Charles Clancy" , "Cheng Hong" X-OriginalArrivalTime: 29 Sep 2006 20:43:29.0439 (UTC) FILETIME=[EB8C6AF0:01C6E407] Authentication-Results: rtp-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: Saravanan Govindan , capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: f65f15b96906f68e00334add0569fcf4 To be fair, one option requires that message 3 be created, and encrypted, in the WTP. This implies that encryption and authentication keys required to formulate message 3 be sent to the WTP. Seems to me simpler to include text that either states the value of zero is always used (simplest), or some configurable value be sent to the WTP (simpler). Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Friday, September 29, 2006 12:07 PM > To: Cheng Hong > Cc: Bob O'Hara (boohara); Dorothy Stanley; Pat Calhoun > (pacalhou); Peter Nilsson J (LI/EAB); capwap@frascone.com; > Saravanan Govindan > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > All, > > I'm glad to see we're finally arguing about the right issue. > As discussed, the Cisco solution to the problem is "set it to zero". > Certainly sniffing the value works as well. From a security > standpoint either is just fine. > > We do have an interoperability issue, however, if a Cisco WTP > were used with an AC that's randomly generating a KeyRSC and > expecting the WTP to sniff it. So, I think some text is > necessary to address the issue. > > What remains are two entrenched opinions about protocol > flexibility vs simplicity, neither of which would > significantly tilt the flexibility vs simplicity balance in > either of direction. Let's flip a coin and move on to more > important issues. > > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > On Fri, 29 Sep 2006, Cheng Hong wrote: > > > Hi Bob, > > > > As Dorothy correctly pointed out below, setting the KeyRSC > to a value > > closer to the current RSC would be better than setting it to a > > pre-defined value zero. > > > > It is true that 802.11i and 802.1X do not specify what is the KeyRSC > > value to be used, since they are trying to provide us a tool to > > correctly synchronize the RSC using the Msg 3. By mandating > the KeyRSC > > to zero, we are just disabling the tool. It is not wrong, but just > > deprives the system a designed function. > > > > As for the effectiveness of KeyRSC, setting it to a > predefined value of > > 0 would pose a greater threat. In a simple example, if the RSC is > > currently 1000, and we are mandating the KeyRSC to be > always zero, the > > attacker basically can safely replay the last 1000 packets > to the STA > > without being detected. If the KeyRSC can be set to a > closer value of > > the current RSC, say, 900, the number of possible replayed > packets can > > be reduced to 10 percent, 100 packets. > > > > Therefore, I would say, setting the KeyRSC value to zero > does place a > > bigger threat. Is that how the cisco products implemented? Maybe you > > could share with us some other implementation/testing data to prove > > otherwise. Or, you have some other considerations that > could defend the > > replay attack? > > > > cheers > > > > Cheng Hong > > > > > > > > _____ > > > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > > Sent: Friday, September 29, 2006 5:21 AM > > To: Dorothy Stanley > > Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; > Peter Nilsson > > J (LI/EAB); capwap@frascone.com > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > > > Dorothy, > > > > The problem with this proposal is that it is no more effective than > > sending a value of zero for the KeyRSC. It doesn't eliminate any > > potential attacks. It doesn't add any functionality. > However, it does > > add cost and complexity to the protocol. > > > > -Bob > > > > > > > > > > _____ > > > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > > Sent: Thursday, September 28, 2006 1:17 PM > > To: Bob O'Hara (boohara) > > Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; > Peter Nilsson > > J (LI/EAB); capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > > > All, > > > > Below is the text from 802.11REV-maD8.0 Clause 8.5.2, > describing the Key > > RSC field.: > > > > "g) Key RSC. This field is 8 octets in length. It contains > the receive > > sequence counter (RSC) for the > > GTK being installed in IEEE 802.11. It is used in Message 3 > of the 4-Way > > Handshake and > > Message 1 of the Group Key Handshake, where it is used to > synchronize > > the IEEE 802.11 replay > > state. It may also be used in the Michael MIC Failure > Report frame, to > > report the TSC field value of > > the frame experiencing a MIC failure. It shall contain 0 in other > > messages. The Key RSC field gives > > the current message number for the GTK, to allow a STA to identify > > replayed MPDUs. If the Key > > RSC field value is less than 8 octets in length, the > remaining octets > > shall be set to 0. The least significant > > octet of the TSC or PN should be in the first octet of the Key RSC > > field." > > > > The intent of adding this value in message 3 was to > immediately minimize > > the number of > > replayed frames that a STA would potentially process: "The > Key RSC field > > gives > > the current message number for the GTK, to allow a STA to identify > > replayed MPDUs." > > Setting the value to 0 in Msg 3 does not provide the > current sequence > > counter (in most cases > > not even close) of the GTK.. > > > > Perhaps the WTP could periodically/frequently notify the AC of its > > current GTK sequence counter, and the > > AC would use the most recently received value in the > message 3 sent to > > new STAs. The RSC value > > would not be up to date at all times, but would be closer > than "0", not > > require an "in-the-critical-path > > message exchange between the AC and WTP, and still be close to the > > intended use of the field. > > > > Dorothy > > > > > > On 9/28/06, Bob O'Hara (boohara) wrote: > > > > Please understand that 802.11i specifies no behavior in > this area for > > the 802.1X authenticator. Our choice to send a group key > KeyRSC value > > of zero in the EAPOL-key frame requires no change to 802.11i or to > > 802.1X . It requires us to state this in the CAPWAP spec, > if we want > > this behavior to be consistent across all implementations. > > > > The problem with what Bechet and Saranavan are asking is > that either of > > three different things are required: > > 1: the WTP must communicate the group key TSC to the AC > every time it is > > updated, or > > 2: the AC must request the current value of the group key > TSC for the > > KeyRSC before constructing the EAPOL-key frame, or > > 3: the AC must send the KCK to the AC so that it can > insert the KeyRSC > > value and also calculate the correct MIC, inserting that > into the proper > > EAPOL-key frame. > > > > The first item requires a tremendous amount of additional CAPWAP > > communication between WTP and AC, at least one new CAPWAP packet for > > every multicast frame sent by the WTP, if the packet is not > > acknowledged, or two new CAPWAP packets, if it is > acknowledged. This is > > a very expensive addition to the protocol. > > > > The second item requires new protocol between the AC and > WTP during what > > can be a time critical portion of the 802.11 transition > (handoff, roam) > > from one WTP to another. It also introduces a race > condition that is > > not present in the protocol today. Once the value for the KeyRSC is > > sent from the WTP to the AC, it is possible that the WTP can send > > another multicast frame encrypted with the group key. This puts the > > value of the sequence counter out of sync with the value > that will be > > shortly communicated to the client in the EAPOL-key frame > from the AC. > > This will behave exactly the same as if a value of zero is > sent in the > > EAPOL-key frame. > > > > The third item requires a new architecture split that is > not required in > > > > our objectives. The new split is not splitting the MAC, > but splitting > > the authenticator. Placing the KCK in the WTP is also a potential > > reduction in the security of the overall WLAN system, since these > > devices are normally not in a secured wiring closet, but exposed and > > more easily compromised than the AC. > > > > The simplest to implement, least expensive, and most secure > option is to > > use the protocol as it is now specified and have the AC > send a value of > > zero in the KeyRSC field of the EAPOL-key frame. > > > > -Bob > > > > -----Original Message----- > > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > > Sent: Wednesday, September 27, 2006 6:50 PM > > To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy; > > Peter Nilsson J (LI/EAB) > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > Hi Pat and all, > > > > So, based on this, I would say that we have consensus that > setting the > > correct KeyRSC is an issue for the CAPWAP protocol design. > > > > So far, we have three option/solutions: > > > > 1) As proposed by Bob: Using a static value (0) for the KeyRSC. > > > > 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP > > > > 3) As suggested by Saravanana: Some exchange mechanism > between WTP and > > AC > > > > Among the three, the first option seems the easiest. However, it > > requires a mandated Authenticator behavior(in this case AC) > that is not > > mandated by 802.11. Therefore, we have to specify that > (e.g. as proposed > > by Bob: "We could include a note to the effect that the group KeyRSC > > should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11, > > because otherwise there is no interoperability. For > example, AC provided > > by another vendor does not have to set KeyRSC to 0 to be > compliant with > > CAPWAP and 802.11i. > > > > Another implication is that we don't really understand the impact of > > mandating a static KeyRSC value. Although Bob provided an excellent > > analysis, I still have some doubts about the profoundness > of the impact. > > If the KeyRSC value is as described of no use, why would it > appear in > > the EAPOL frames in the first place? By mandating it to > static value, > > what have we lost? Maybe some liaison letter to 802.1 or > 802.11 could > > provide us a better understanding of the issue. > > > > For the last two options, I think they are both within > CAPWAP's scope. > > Further analysis could help us to decide which one is better (or > > someone could propose other solutions). > > > > cheers > > > > Cheng Hong > > > > > > > > > > > > > > > >> -----Original Message----- > >> From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com] > >> Sent: Thursday, September 28, 2006 1:39 AM > >> To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; > >> Peter Nilsson J (LI/EAB) > >> Cc: capwap@frascone.com > >> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > >> Considerations > >> > >> Bob's point is 802.11i works this way today. The AP (or in > >> this case AC) can set the RSC to whatever value it wishes. > >> Bob used zero (0) as an example. Implementations could use > >> any other value, which would require some form of > >> communication to the WTP, as suggested by Behcet. > >> > >> Pat Calhoun > >> CTO, Wireless Networking Business Unit > >> Cisco Systems > >> > >> > >> > >>> -----Original Message----- > >>> From: Cheng Hong [mailto: > > Hong.Cheng@sg.panasonic.com] > >>> Sent: Tuesday, September 26, 2006 6:03 PM > >>> To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson > >> J (LI/EAB) > >>> Cc: capwap@frascone.com > >>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > >>> Considerations > >>> > >>> Hi Bob, > >>> > >>> If I understand your description below correct, you are > proposing a > >>> solution (to the problem pointed out by > >>> Saravanan) by mandating the behavior of the AC to always set the > >>> KeyRSC in the 4-way handshake to zero. > >>> > >>> This is not a defined behavior according to the current > >>> 802.11 standard. > >>> Are you suggesting that we CAPWAP WG should specifically > >> mandate that > >>> in our CAPWAP protocol spec, e.g. something like "a CAPWAP > >> compatible > >>> AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, > >>> since not all AC implementation have to follow what you described. > >>> > >>> Or, are you planning to take this issue to TGm for 802.11 standard > >>> revision? (since based on your description, there is > essentially no > >>> use of the KeyRSC). > >>> > >>> cheers > >>> > >>> Cheng Hong > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > >>>> Sent: Wednesday, September 27, 2006 2:32 AM > >>>> To: T. Charles Clancy; Peter Nilsson J (LI/EAB) > >>>> Cc: capwap@frascone.com > >>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > >>>> Considerations > >>>> > >>>> Charles, Peter, > >>>> > >>>> Below is an expansion of a snippet from a thread on this > >>> topic that I > >>>> sent to the list on July 25, 2006. I think this will be > >> helpful to > >>>> understand why the exchange that Saranavan is requesting is not > >>>> necessary. In fact, there are several systems from several > >>>> manufacturers in the field using precursor protocols to > >> CAPWAP that > >>>> are Wi-Fi certified for WPA2/802.11i operation using the > >>> protocol as > >>>> it is described below. > >>>> > >>>> BTW, this whole discussion is about the KeyRSC for the > >>> group key, not > >>>> the pairwise key. This is so because the WTP and AC both > >> know the > >>>> initial sequence counter value for the pairwise key, since it has > >>>> never been used to send a frame. 802.11i requires the > >> first frame > >>>> sent on a key to use the sequence counter value of 1. See > >>> 8.3.2.6 c) > >>>> and > >>>> 8.3.3.4.3 c) in 802.11i for this requirement. > >>>> > >>>> The same is not true of the group key, i.e., after the WTP begins > >>>> operation, the AC will not know the value of the sequence > >>> counter for > >>>> the group key when it needs to complete the EAPOL-key > >>> handshake with a > >>>> newly associated STA. > >>>> However, as you will see from the tutorial below, it is not > >>> necessary > >>>> for the AC and WTP to exchange any information about the > >> group key > >>>> KeyRSC for the protocol to operate as it is intended. > >>>> > >>>> 1. A value for the KeyRSC in the EAPOL-key frame 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. A value of zero in the > >> EAPOL-key > >>>> frame for the group key will always work. > >>>> > >>>> 3. The client STA will use the value of KeyRSC received in the > >>>> EAPOL-key frame to validate frame using the KeyMIC. > >>>> > >>>> 4. The client STA will also set its group key RSC to the value > >>>> received in KeyRSC, say, zero. > >>>> > >>>> 5. The value in the client STA's RSC will be compared against the > >>>> sequence number in subsequent received frames to identify replay > >>>> attacks. Any frame received with a sequence counter value > >>> within the > >>>> replay window will be checked to have a valid MIC. If the > >>> MIC is not > >>>> valid, the frame is dropped. > >>>> > >>>> 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, if the value is greater than its current RSC value. > >>> Only the > >>>> AP can meet these criteria as the source of a frame > >> received by the > >>>> STA. > >>>> > >>>> 7. Please see item 6, immediately above, for the reason > >> that the AC > >>>> and WTP do not need to coordinate and exchange the RSC. > >>>> > >>>> > >>>> The only possible attack mode is for the attacker to send > >> frames to > >>>> the client STA between the time of the EAPOL-key frame and > >>> the first > >>>> frame encrypted with the group key. > >>>> During this time, the client will receive the frame and > >> proceed to > >>>> validate its MIC. This is a potential attack against the STA > >>>> resources. But, the MIC validation is done in the STA's > >>>> 802.11 chip and consumes no more resources than receiving > >> any other > >>>> frame. Thus, the attack does not actually consume any STA > >>> resources > >>>> beyond those of receiving a frame. > >>>> > >>>> This attack is not unique to the use of the value zero for > >>> the KeyRSC, > >>>> either. The same attack is available to an attacker at any other > >>>> time, as well. It is no more nor less effective at either time. > >>>> > >>>> For these reasons, the protocol is not in need of any changes to > >>>> address the issue raised by Saranavan. > >>>> > >>>> -Bob > >>>> -----Original Message----- > >>>> From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > >>>> Sent: Monday, September 25, 2006 11:37 AM > >>>> To: Peter Nilsson J (LI/EAB) > >>>> Cc: capwap@frascone.com > >>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > >>>> Considerations > >>>> > >>>> This is a very interesting solution. The AC selects the > >> KeyRSC and > >>>> performs the 4-way handshake. The WTP sniffs the 4-way handshake > >>>> traffic and grabs the KeyRSC value and uses it to > >>> initialize its own > >>>> counter. > >>>> > >>>> Pat/Bob: Is this how the Cisco implementation works? I > >>> have to agree > >>>> with Saravanan that I've yet to see a technical > >> description of how > >>>> Cisco implements it. > >>>> > >>>> IMHO, this is somewhat hackish, and it would be cleaner to > >>> have the AC > >>>> generate the KeyRSC and include it in the AddMobile message > >>> as Behcet > >>>> suggests. > >>>> > >>>> -- > >>>> t. charles clancy, ph.d. | tcc@umd.edu | > >> www.cs.umd.edu/~clancy > >>>> > >>>> On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > >>>> > >>>>> I think Saravanan has a point. We did a prototype > >>> impelementation of > >>>> the > >>>>> protocol a year ago when it was still called LWAPP. The way > >>>> we solved > >>>>> this issue then was to let the WTP sniff on all CAPWAP data > >>>> messages > >>>>> from the AC and when message 3 of the 4-way handshake or > >>>> message 1 of > >>>>> the groupkey handshake was sent the WTP inserted the correct RSC > >>>> before > >>>>> sending it off to the supplicant. To avoid the sniffing on > >>>> all CAPWAP > >>>>> data messages we would need a mechanism with in CAPWAP to > >>>> handle these > >>>>> two messages. > >>>>> > >>>>> Peter Nilsson > >>>>> > >>>>> -----Original Message----- > >>>>> From: Saravanan Govindan > >>>> [mailto:Saravanan.Govindan@sg.panasonic.com] > >>>>> Sent: den 22 september 2006 11:03 > >>>>> To: Margaret Wasserman > >>>>> Cc: capwap@frascone.com > >>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > >>>> Considerations > >>>>> > >>>>> Hi Margaret, > >>>>> > >>>>> Thank you for reviewing the discussion on this issue. > >>>>> > >>>>> The issue here is the working of IEEE 802.11i when the 802.11i > >>>>> authenticator element is at the AC and the 802.11i crypto > >>> element is > >>>> at > >>>>> the WTP. Particularly, it is for the 4-way handshake between > >>>>> authenticator and supplicant. > >>>>> > >>>>> Now, the 4-way handshake requires knowing the value of > >>>> KeyRSC sequence > >>>>> counter. The KeyRSC helps both authenticator and supplicant > >>>> keep track > >>>>> of their exchanges. It serves to protect against threats by > >>>> tracking > >>>>> sequential frames. The KeyRSC is maintained at the at the > >>> point of > >>>>> encryption, i.e. just before transmission over the > >>> wireless channel. > >>>>> > >>>>> In the case of CAPWAP, the 4-way handshake is between the AC > >>>>> (authenticator) and the wireless station (supplicant). > >>>>> > >>>>> The problem arises, when the authenticator is at the AC and > >>>> the crypto > >>>>> element (together with KeyRSC) is at the WTP. This is a > >>>> fairly common > >>>>> design. Now in this case, the AC starts the 4-way > >> handshake but it > >>>> does > >>>>> not know the value of the KeyRSC. The KeyRSC is maintained > >>>> by the WTP. > >>>>> > >>>>> Based on this, the current CAPWAP specification does not > >>> allow for a > >>>> way > >>>>> to conduct the 4-way handshake with the correct KeyRSC. > >>>>> > >>>>> The functionality I would like to see is a way for the > >>> authenticator > >>>>> (AC) to use the correct prevailing value of KeyRSC > >>>> (maintained by the > >>>>> WTP) in its 4-way handshake. > >>>>> > >>>>> One way to introduce this functionality in to CAPWAP is > >>> to have part > >>>> of > >>>>> the 4-way handshake be sent from AC to WTP. This will allow > >>>> the 4-way > >>>>> handshake to use the correct value of the KeyRSC before > >>>> being sent to > >>>>> the wireless station. > >>>>> > >>>>> I hope this helps clarify my view on the issue. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> Saravanan > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Margaret Wasserman [mailto:margaret@thingmagic.com] > >>>>> Sent: Thursday, September 21, 2006 8:26 PM > >>>>> To: Saravanan Govindan > >>>>> Cc: Pat Calhoun (pacalhou); capwap@frascone.com > >>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > >>>> Considerations > >>>>> > >>>>> > >>>>> > >>>>> Hi again, > >>>>> > >>>>> Okay, I am even more confused than I thought I was... > >>>>> > >>>>> Saravanan, you wrote: > >>>>> > >>>>> On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > >>>>> > >>>>>> Pat, > >>>>>> > >>>>>> The issue here is about how 802.11i exchanges are done when > >>>>>> authenticator is at the AC and crypto elements are at > >>> the WTP. This > >>>> is > >>>>>> the requirement. > >>>>> > >>>>> And, in response, Pat Calhoun wrote: > >>>>> > >>>>> On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: > >>>>>> The current specification allows the authenticator to > >>>> reside in the > >>>>>> AC, while the data packet crypto elements in the WTP. This > >>>> feature is > >>>>>> already in the specification. > >>>>> > >>>>> Pat's message matches my reading of the specification. > >>>>> > >>>>> So, Saravanan, what functionality are you asking for > >> that is not > >>>>> already supported by the specification? And why do you > >>> think it is > >>>>> necessary? it will not be helpful to my understanding to > >>>> re-send your > >>>>> proposal or to cite the requirements document... Please > >>> summarize > >>>>> what functionality you think is missing from the current > >>>> specification > >>>>> and why you think that functionality is necessary to > >> support IEEE > >>>>> 802.11i or any important use case. > >>>>> > >>>>> At some point, the chairs may need to make a consensus > >>> call on this > >>>>> issue, and I'd like to understand your view and make sure > >>>> that it has > >>>>> been clearly communicated to the WG before we ask the WG to > >>>> decide on > >>>>> this issue. > >>>>> > >>>>> 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 > >>>>> > >> _________________________________________________________________ > >>>>> 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 > >>>> > >>> _________________________________________________________________ > >>> 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 > > > > > > > > > _________________________________________________________________ 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 Sep 29 17:06:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTPZT-0003qn-OI for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 17:06:59 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTPZS-0004vV-59 for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 17:06:59 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3D0E83980D4 for ; Fri, 29 Sep 2006 14:06:57 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2551F430059 for ; Fri, 29 Sep 2006 14:01:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E813F1448039 for ; Fri, 29 Sep 2006 14:01:54 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by hermes.tigertech.net (Postfix) with ESMTP id 34931144800F for ; Fri, 29 Sep 2006 14:01:51 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so1079630nfb for ; Fri, 29 Sep 2006 14:01:50 -0700 (PDT) Received: by 10.49.41.12 with SMTP id t12mr1358230nfj; Fri, 29 Sep 2006 14:01:50 -0700 (PDT) Received: by 10.49.42.6 with HTTP; Fri, 29 Sep 2006 14:01:49 -0700 (PDT) Message-ID: <5bfe7a820609291401gaf4c8bdx6984024ea656cfab@mail.gmail.com> Date: Fri, 29 Sep 2006 14:01:49 -0700 From: "Dorothy Stanley" To: "Michael Montemurro" In-Reply-To: <26140d940606300703q64dfb8ffg86a7c8037c61d00b@mail.gmail.com> MIME-Version: 1.0 References: <000501c69908$d83974b0$6007120a@china.huawei.com> <26140d940606300703q64dfb8ffg86a7c8037c61d00b@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.9 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_60_70, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Duplcate IPv6 Address message Element X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1671397428==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab --===============1671397428== Content-Type: multipart/alternative; boundary="----=_Part_18571_6454033.1159563709617" ------=_Part_18571_6454033.1159563709617 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, Issue 147 is: *As DAD ( Duplicate address detection ) is the integral part of IPv6 protocol so no other host/WTP with same IPv6 address can join the network, therefore section 4.4.20 for duplicate IPv6 address message element is NOT required in CAPWAP and can be deleted ?* The proposed resolution to issue 147 is to delete the Duplicate IPv6 Address message element, 4.4.20. Comments please. Thanks, Dorothy On 6/30/06, Michael Montemurro wrote: > > Sachin, > > I created issue 147 to track this. > > Mike > > > On 6/26/06, Sachin Dutta wrote: > > > Hi All, > > > > > > > > As DAD ( Duplicate address detection ) is the integral part of IPv6 > > protocol so no other host/WTP with same IPv6 address can join the network, > > therefore *section 4.4.20 *for duplicate IPv6 address message element is > > *NOT required in CAPWAP* and can be deleted ? > > > > * * > > > > Regards > > > > Sachin > > > > > > > > _________________________________________________________________ > > 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_18571_6454033.1159563709617 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
All,
 
Issue 147 is:
 
As DAD ( Duplicate address detection ) is the integral part of IPv6 protocol
so no other host/WTP with same IPv6 address can join the network, therefore
section 4.4.20 for duplicate IPv6 address message element is NOT required in
CAPWAP and can be deleted ?
 
The proposed resolution to issue 147 is to
delete the Duplicate IPv6 Address message element, 4.4.20.
 
Comments please.
 
Thanks,
 
Dorothy


On 6/30/06, Michael Montemurro <montemurro.michael@gmail.com> wrote:
Sachin,
 
I created issue 147 to track this.
 
Mike

 
On 6/26/06, Sachin Dutta < sachind@huawei.com> wrote:

Hi All,

 

As DAD ( Duplicate address detection ) is the integral part of IPv6 protocol so no other host/WTP with same IPv6 address can join the network, therefore section 4.4.20 for duplicate IPv6 address message element is NOT required in CAPWAP and can be deleted ?

 

Regards

Sachin

 


_________________________________________________________________
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_18571_6454033.1159563709617-- --===============1671397428== 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 --===============1671397428==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 29 17:28:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTPuE-0007NT-Sh for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 17:28:26 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTPuB-0007W6-L1 for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 17:28:26 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 7AFA5144803B for ; Fri, 29 Sep 2006 14:28:17 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 363A9430059 for ; Fri, 29 Sep 2006 14:22:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2BD78398023 for ; Fri, 29 Sep 2006 14:22:03 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by zoidberg.tigertech.net (Postfix) with ESMTP id B9F79398046 for ; Fri, 29 Sep 2006 14:21:52 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so1083241nfb for ; Fri, 29 Sep 2006 14:21:51 -0700 (PDT) Received: by 10.49.43.2 with SMTP id v2mr2231194nfj; Fri, 29 Sep 2006 14:21:51 -0700 (PDT) Received: by 10.49.42.6 with HTTP; Fri, 29 Sep 2006 14:21:51 -0700 (PDT) Message-ID: <5bfe7a820609291421j4e2147c5w828b42d7fa494497@mail.gmail.com> Date: Fri, 29 Sep 2006 14:21:51 -0700 From: "Dorothy Stanley" To: "Michael Montemurro" MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.288 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_10_20, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: capwap@frascone.com Subject: [Capwap] Proposed resolution to Issue 177 WTP Reboot Statistics belongs in the Join/was Re: A commentary on CAPWAP-01 operations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1683059389==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.9 (/) X-Scan-Signature: 8b46f883d051ec9bb02ad32011a213d1 --===============1683059389== Content-Type: multipart/alternative; boundary="----=_Part_18884_28545677.1159564911303" ------=_Part_18884_28545677.1159564911303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, Issue 177, "WTP Reboot Statistics belongs in the Join" is listed below: *29) WTP Reboot Statistics belongs in the Join, and the reasons listed are not clear enough. Doesn't really matter whether this is included in the configuration or the join, but if the WG agrees to move it. We can clarify some of the reasons, as long as it provides value.* Believing that there may be times when it is desirable for the WTP to provide information to the AC about its stability, the proposed resolution to Issue 177 is to insert the following text at the end of Section 6.1 "Join Request": The following message element may be included in the Join Request message: - WTP Reboot Statistics, see Section 4.4.44. Comments please, Thanks, Dorothy On 6/30/06, Michael Montemurro wrote: > > David, Pat, > > I created issues 150-198 to deal with the points in David's email. Happy > hunting! > > Mike > > > On 6/27/06, Pat Calhoun (pacalhou) wrote: > > > > Going through David's lengthy document, he has raised an interesting > > number of points that I believe require issues to be created. At one > > point I'm paraphrasing Dave's comments in order to be brief, and > > introducing my own numbering scheme. > > > > 1) Can message elements be in any order? (I believe they should be) > > > > Yes, and I suspect we need to include text to make it more > > obvious. > > > > > > 2) Are all specified message elements required? (The obvious answer is > > "yes", but this document doesn't discuss versioning. For example, what > > if in a new version of CAPWAP an additional message element was to be > > added. Would a new message type be created and the additional message > > element added to it, or the existing type reused?) > > > > This is a great question, and one that does need to be addressed > > in the spec. In the Diameter protocol we dealt with this issue by > > including a "Mandatory to implement" bit. If any AVP was received, whose > > bit was set, yet was not recognized, then the request had to be > > rejected. > > > > We could consider something similar here, but I believe with the > > firmware download component of the protocol it may be less of an issue - > > although not guaranteed. I would hope (and expect) that as the CAPWAP > > protocol extends, the AC would push new firmware to the WTP. This does > > require that the initial part of the state machine be fairly static, and > > this could be an area where the "Mandatory to implement" bit could be > > useful as it would allow the AC to fall back to older protocol behavior. > > > > > > 3) CAPWAP-01 doesn't do a good job of indicating which message elements > > can be repeated. > > > > Another good point. When we list the message elements, we should > > note whether the frequently is 0-1 (meaning absent or once), 1 (only > > once) or 0+ (meaning any number of them could be present. > > > > > > 4) Can "additional" message elements be added to a message? (I believe > > so for reporting capabilities, statistics, and events. For > > configuration, there is nothing in the protocol that says what happens > > when one end gets an configuration element it doesn't know about. > > Should it be ignored, and the other elements processed, or should the > > complete operation failed?) > > > > The "Mandatory to implement" bit above could address this issue. > > If an unrecognized message element is found to have the bit set, then > > the whole message needs to be rejected. If the bit is not set, the > > message element may be safely ignored. > > > > > > 5) The config has a concept of "default value" for each configuration > > attribute. However, the default values are not clearly specified. This > > needs to be resolved to be able to support "default values". > > > > Another good point raised by David. > > > > > > 6) the documentation of which "binding specific" message elements are to > > be included with CAPWAP messages is not consistent, and is difficult to > > follow. > > > > Has this been addressed in the latest (-02) document? > > > > > > 7) There are some message elements that cause "actions". This approach > > to protocol design is problematic and should be eliminated. > > > > Could you be more specific as well as provide guidance on what you > > would like to see? > > > > > > 8) The message types are inconsistently named, and do not follow the > > conventions of well designed protocols. Can the operations be named > > consistently with the following terminology: > > 1) request/response (used to get/set/perform action) > > 2) report/ack (use to tell the other side something) > > > > Could you provide your thoughts on which messages fall within > > which one of your categories? > > > > > > 9) Many of the configuration items, and status items are not listed in > > one section with definitions. (Well make it two sections - one for > > CAPWAP and the other which is "binding" specific.) For example, not all > > of the time period lengths are identified and specified in section 4.5. > > > > Unfortunately, the document has gone back and forth a few times > > and before we opt to change the structure of the document, I'd like to > > ensure that we have broad agreement on what we want - with the > > understanding that we will never make everyone happy. > > > > > > 10) each operation should have listed in which states it can be sent and > > received > > > > I do not understand your comment. > > > > > > 11) All strings, such as WTP location, should be changed from US-ASCII > > encoding to UTF-8 encoding. > > > > Agreed. > > > > 12) The term "mobile" is not really accurate when describing wireless > > interfaces, since wireless does not imply mobile. Can we just use > > the techie term "STA" instead. > > > > I agree we should use the term Station, or STA for short. > > > > > > 13) The WTP Descriptor message element contains too much information, > > lacks clarity on the WTP encryption field and includes version numbers, > > which should be in string form. > > > > To the first point, I disagree. I think there is value in knowing > > everything about the WTP. The AC vendors can expose whatever information > > > > they want, but I don't believe anything is unnecessary. > > > > To the second point, this is one of those areas where the concept > > of the technology binding creates complexity. Given that we cannot > > simply discuss 802.11i at this point, the only thing we can do is punt > > to another section in the technology binding section. That said, I agree > > with Dave that the 802.11 binding section is too light in this area. > > However, I would much prefer that instead of trying to address this > > specific issue, we discuss whether we should even be supporting the mode > > of operation where 802.11i is performed in the AC - especially with the > > introduction of DTLS to secure the data plane. Right now, it just feels > > like we have too many options and I am worried that interoperability > > will be severely impacted (not to mention protocol complexity). > > > > To the last point, I have no issues with including text stating > > that the version numbers should be in string form. > > > > > > 14) The WTP Descriptor information is not required at Join time. > > > > Well, as far as I can tell, I think there's value in knowing > > whether the WTP can even be supported by the AC. So the more info is > > provided by the WTP, the better the AC can determine whether it should > > just ignore the WTP or not. This could be done because it knows that the > > firmware running on the WTP is not compatible, and it has no new > > firmware to download. > > > > > > 15) Are the values in the WTP Frame Encryption a capabilities bit, or an > > enum? > > > > Looks like an enum to me. Not sure what Dave would prefer the text > > to read. There are various other similar comments throughout, which I > > will not repeat here. > > > > > > 16) The Discovery Response is broken. The AC SHOULD NOT be providing any > > info to a WTP (or something that claims to be a WTP). Also, the AC > > should tell the WTP what to do next, with choices: 1) Ok to try to join, > > > > 2) don't try to join, 3) try discover on a list of > > returned ACs) > > > > I don't believe there is an issue with sending the AC's > > information to the WTP, but would solicit input from the list. That > > said, some of the information in the AC Descriptor is required, such as > > the current load on the AC. No point is trying to join if he AC > > indicates it's already at max capacity. > > I believe if the AC does not return the response, then it implies > > (2). Otherwise, it is (1). (3) is handled during the join or configure > > process, which I believe is right. > > > > > > 17) Is AC Name text? > > > > Yes, and same with WTP Name. > > > > > > 18) Primary Discovery are not required. > > > > Disagree. Required for failover. > > > > > > 19) The text does not make it clear that the contents of the WTP > > Location is informative only, and as Dave calls it, a "scratchpad". > > > > Well, to be honest, I thought the example "next to the fridge" > > made it clear that the information did not derive from any scientific > > formula. The description also states this is a user-defined. I believe > > this should be good enough. > > > > > > 20) Session is not required > > > > I believe you may be correct that with the transition to DTLS, > > this is no longer required. > > > > > > 21) need to send "common name" as found in the WTP CERT so that the AC > > can verify > > > > The protocol currently relies on the MAC address being the key > > that binds the certificate to the WTP. I don't see a need to change > > this. > > > > > > 22) Result code in Join Response is not sufficient, for instance WTP HW > > not supported. > > > > Well, the protocol does not require this because the Discovery > > Response would never be sent (as the protocol stands today). > > > > > > 23) AC IPv4/IPv6 Addr discusses clustering, which is unnecessary. > > > > Agreed. > > > > > > 24) Change Echo to Keepalive or heartbeat. > > > > I call it potato.... > > > > > > 25) What if all of the message elements do not fit within a single > > CAPWAP control frame. > > > > We should address this. > > > > > > 26) AC Name with Index is all messed up... > > > > Not really. You simply include more than one, and the index field > > is clearly the priority. Don't understand the Multi-AC comment. No > > inter-AC protocol implied here. > > > > > > 27) WTP Board Data belongs in the Join, not configure. > > > > Agreed, but wonder even more why we are duplicating this > > information across both the WTP Descriptor and the WTP Board Data > > message elements. > > > > > > 28) The WTP Static IPv4 Address should not have the Static bit, but > > instead state that 0.0.0.0 means a static address is not to be used. > > > > I don't have an issue with this request, but in the end we have > > the same function. The reason why I state this is that we can refine > > this protocol until the cows come home, and at one point we need to draw > > a line in the sand. > > > > > > 29) WTP Reboot Statistics belongs in the Join, and the reasons listed > > are not clear enough. > > > > Doesn't really matter whether this is included in the > > configuration or the join, but if the WG agrees to move it. We can > > clarify some of the reasons, as long as it provides value. > > > > > > 30) The IEEE 802.11 WTP Radio Configuration message element's BSSID > > field should be an array. > > > > Disagree. > > > > > > 30) The IEEE 802.11 WTP Radio Configuration message element's Country > > Code is not clear enough. > > > > The text points to the actual MIB element in the 802.11-1999 > > standard, which very clearly defines the contents of the field. I don't > > think there's value in replicating the format of this field in the > > CAPWAP standard. > > > > > > 31) There seems like an awful lot of additional configuration message > > elements that need to be specified here! > > > > Having built a protocol based on this, it's not clear to me what's > > > > missing. I think it would be useful if you provided concrete details on > > what's missing. > > > > > > 32) Configuration Status is just plain broken because any configuration > > change operation may fail and there is no response to the > > configuration changes specified in this command. > > > > There certainly is - I guess I don't understand the concern. > > > > > > 33) Use of Change State Event should instead be Radio Admin State. > > > > Perhaps the two are not described properly. The first is used by > > the WTP to inform the AC that something has occurred with a radio. The > > second is used by the AC to enable/disable a radio. > > > > > > 34) Report Timer needs to be in section 4.5 or 11 > > > > ok > > > > > > 35) Should Idle Timeout be per radio, or per WTP, and should the value > > be defined in section 4.5 or 11. > > > > Per WTP, and yes. I believe it is fine as it is. > > > > > > 36) WTP Fallback isn't well defined, and should be removed. > > > > Disagree. I believe it is necessary to create enough resiliency in > > the protocol/service. > > > > > > 37) How are the "Rate Set" and "Supported Rates" encoded. > > > > This was fixed in the -02 > > > > > > 38) AC Timestamp doesn't belong in the configuration, but instead in the > > join. > > > > Not sure this really matters.... > > > > > > 39) Add MAC ACL Entry - this is so strange and is being managed like no > > other configuration data. > > > > I do not understand the comment > > > > > > 40) Decryption Error Report Period is not defined in section 4.5 or 11 > > > > ok, and note that the information has been moved to the IEEE > > 802.11 RSNA Error Report From Mobile > > > > > > 41) Configuration Update Response. today, there are primarily two types > > of configuration models. The first is when config is changed, it is only > > changed in the volatile copy (the memory or running). An explicit > > command is needed to save the config to nonvolatile storage. The second > > model has config both running (volatile) and saved (nonvolatile) config > > changed when a config change is made. And there might be a special > > command to have a config change apply to only one. In this case, there > > is no need for a "save config to nonvolatile" command. It is not clear > > what is suppose to be supported here in CAPWAP, and how does CAPWAP > > support devices with no or very limited nonvolatile storage for config! > > > > CAPWAP does not support WTPs with no nonvolatile storage. The > > protocol has the AC push configs to the WTP, which saves them at the > > time they are received. I do not believe anything else is required. > > > > > > 42) Configuration Update Response includes the Result Code message > > element, which includes values that do not appear to be relevant for > > this message, and there are plenty of other failure cases > > > > ok, but note that we are sharing a common message element. Any > > suggestions on how to address your issue? > > > > > > 43) Change State Event Report. This seems a little silly to be sent in > > the "configure" state. It seems only appropriate for the "run" state. > > Some might argue that even in the "run" state it shouldn't be sent after > > a "config update" request that changes the operational state. However, > > in the "run" state, it may take a while to have the operational state > > change to follow the admin state. Thus, I think it is OK in the "run" > > state after config changes." > > > > I believe this was addressed in -02. > > > > > > 44) Clear Config Request. this operation has several problems, which > > include: > > 1) currently, the CAPWAP-01 spec says that this can only be done in > > the "run" state. This is silly. It should also be possible in the > > "configure" state. > > I wonder why the AC would even consider clearing the WTP's state > > before it even knows how it is configured. > > > > 2) the value of "manufacturing defaults" is not defined, and a poor > > term to use, since it implies that that each manufacturer can have > > different values. If so, then the AC will have no knowledge of the > > config on the WTP! The problem of "default config values" has already be > > > > mentioned above. After each config attribute has been defined with a > > default value, then the proper term would be "CAPWAP config defaults". > > Yes, you've raised this point already, and I agree that it does > > need to be addressed. > > > > 3) This operation is not defined to have a response. This is broken, > > since any config change can fail. Also, it is not defined what happens > > next. Does this cause the WTP to reboot an start a "clean discovery"? > > This was addressed in -02 > > > > > > 45) Image Data Request. Yes, there are actually three different "Image > > Data Request" messages. Which one is determined by which of the > > three message elements is contained. This is completely silly! There > > should be three separate operations! Additionally, how does the WTP know > > which image to get? The AC should be making that decision. > > > > I believe the WTP is the only device that knows what it's filename > > > > should be. Why would an AC vendor know about file naming conventions > > used by the WTP vendors? I believe your other issues are discussed in > > the next items. > > > > > > 46) Image Data Response. this is silly. This operation can fail! There > > needs to be message element that indicates the result. > > > > How so? This is only used to send firmware to the WTP. Not clear > > what could fail... Reading the image from flash? > > > > > > 47) Image Data Request. when starting over again at the WTP start state, > > > > the WTP shouldn't use the "normal" discovery process, but instead "fast > > track" a connection back to the AC that just downloaded the image. With > > a little more work, we could probably figure out a way to reuse > > > > the old DTLS session. > > > > To what gain? What is so expensive about the discovery, and what > > happened if the AC was not longer reachable? > > > > > > 48) opcode - if this is here, might as well also have a value that > > indicates last block of the image file, instead of looking at the block > > size. > > > > But we're just changing for the sake of changing - the protocol > > works as-is. > > > > > > 49) since this operation does not have the block number as a parameter, > > the WTP must determine the block number via the CAPWAP message header > > sequence number. NOTE: DTLS does not provide in-order delivery of > > packets. Also, this requires the WTP to remember state. This message > > element should be re-engineered to have the following subfields: > > [edited] > > > > The control header includes a sequence number, and while we can > > change the current protocol to match your recommendations, the protocol > > does work. If it ain't broken... > > > > > > 50) Image Data Response. this is silly. This operation can fail! For > > example, the WTP can run out of space to store the block, or > > there could be a failure in writing the block to storage. (Or as "Image > > Data Request"(9.1a) is presently specified, the checksum match could > > fail.) There needs to be message element that indicates the result.) > > Note: don't need a block number field, since request and responses are > > paired. > > > > We can include a result code > > > > > > 51) Image Data Request. silly beyond belief > > > > Beauty is in the eye of the beholder ;-). Seriously, the protocol > > does work, so what exactly are you looking for? > > > > > > 52) Image Data Response. This is silly. This operation can fail! There > > needs to be message element that indicates the result. > > > > See above comment. > > > > 53) Reset Request. ... > > > > The comment is irrelevant now that Clear Config has changed. > > > > > > 54) Reset Response. this is silly. This operation can fail! There needs > > to be message element that indicates the result. > > > > I sense a trend. I will stop including these messages from now on. > > > > > > 55)Duplicate IPv4 Address. how often is this reported if the condition > > remains? > > > > Only required once, I think, but we may want to include some text > > covering that. > > > > > > 56) the list of events seems understated! > > > > Text and conditions please > > > > > > 57) Data Transfer Request. Nice to have - remove. > > > > Disagree. Providing diagnostics capabilities is required. > > > > > > 58) Mobile Config Request. the actual details of how this works on both > > splitMAC and especially localMAC are not well specified. That is, only > > the figures and text in sections 11.1.1 and 11.1.2 provide any clue as > > to events that would cause an AC to send this message type. Also, there > > are restrictions on combinations of parameters that can be included in > > the message. > > > > I wonder whether other folks agree that more details are required. > > > > > > 59) it doesn't say if one message can be used to update more than one > > STA. It should be able. > > > > No, otherwise you end up with the problem of associating specific > > message elements with a given mobile. One mobile per request. > > > > > > 60) IEEE 802.11 Mobile. shouldn't the STA MAC address be included so > > this message element can be matched with a (4.4.8)Add Mobile message > > element? > > > > I believe this is to your previous point, but the protocol assumes > > one mobile per request. > > > > > > 61) IEEE 802.11 Update Mobile QoS. s this for data traffic to the AC? If > > so, then why is this an 802.11 message element > > > > Intended to be a way to push policies to the WTP to prioritize > > mobile traffic. > > > > > > 62) IEEE 802.11 WLAN Config Request. why is a new message type that is > > 802.11 specific needed to modify 802.11 WLANs? It seems like the > > existing "(8.4)Configuration Update Request" message could be used. > > > > To be more specific only. > > > > > > 63) note here there are information elements to create, delete, and > > modify WLANs. However, for message type "(10.1)Mobile Config Request", > > there is only add and delete (and the "add" used to modify). > > > > Correct. The protocol requires the AC to resend a new add with a > > different policy. No specific reason, but if this is deemed > > inconsistent, we could change it. > > > > > > 64) IEEE 802.11 Assigned WTP BSSID. The mapping of WLAN IDs to BSSIDs > > seems like it needs a little more work > > > > What exactly would you like to see? > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > -----Original Message----- > > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > > Sent: Thursday, June 22, 2006 4:31 PM > > > To: capwap@frascone.com > > > Subject: [Capwap] A commentary on CAPWAP-01 operations > > > > > > HI, > > > > > > I've attached a long file that summarizes the operations in > > > CAPWAP-01. > > > > > > 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 > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_18884_28545677.1159564911303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
All,
 
Issue 177, "WTP Reboot Statistics belongs in the Join"
is listed below:
29) WTP Reboot Statistics belongs in the Join, and the reasons listed
are not clear enough.

<PRC> Doesn't really matter whether this is included in the
configuration or the join, but if the WG agrees to move it. We can
clarify some of the reasons, as long as it provides value.
Believing that there may be times when it is desirable for the WTP to provide
information to the AC about its stability, the proposed resolution to Issue 177 is
to insert the following text at the end of
Section 6.1 "Join Request":
 
The following message element may be included in the Join Request message:
- WTP Reboot Statistics, see Section 4.4.44.
 
Comments please,
 
Thanks,
 
Dorothy

 
On 6/30/06, Michael Montemurro <montemurro.michael@gmail.com> wrote:
David, Pat,
 
I created issues 150-198 to deal with the points in David's email. Happy hunting!
 
Mike

 
On 6/27/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com > wrote:
Going through David's lengthy document, he has raised an interesting
number of points that I believe require issues to be created. At one
point I'm paraphrasing Dave's comments in order to be brief, and
introducing my own numbering scheme.

1) Can message elements be in any order? (I believe they should be)

<PRC> Yes, and I suspect we need to include text to make it more
obvious.


2) Are all specified message elements required? (The obvious answer is
"yes", but this document doesn't discuss versioning. For example, what
if in a new version of CAPWAP an additional message element was to be
added. Would a new message type be created and the additional message
element added to it, or the existing type reused?)

<PRC> This is a great question, and one that does need to be addressed
in the spec. In the Diameter protocol we dealt with this issue by
including a "Mandatory to implement" bit. If any AVP was received, whose
bit was set, yet was not recognized, then the request had to be
rejected.

<PRC> We could consider something similar here, but I believe with the
firmware download component of the protocol it may be less of an issue -
although not guaranteed. I would hope (and expect) that as the CAPWAP
protocol extends, the AC would push new firmware to the WTP. This does
require that the initial part of the state machine be fairly static, and
this could be an area where the "Mandatory to implement" bit could be
useful as it would allow the AC to fall back to older protocol behavior.

3) CAPWAP-01 doesn't do a good job of indicating which message elements
can be repeated.

<PRC> Another good point. When we list the message elements, we should
note whether the frequently is 0-1 (meaning absent or once), 1 (only
once) or 0+ (meaning any number of them could be present.


4) Can "additional" message elements be added to a message? (I believe
so for reporting capabilities, statistics, and     events. For
configuration, there is nothing in the protocol that says what happens
when one end gets an configuration     element it doesn't know about.
Should it be ignored, and the other elements processed, or should the
complete operation     failed?)

<PRC> The "Mandatory to implement" bit above could address this issue.
If an unrecognized message element is found to have the bit set, then
the whole message needs to be rejected. If the bit is not set, the
message element may be safely ignored.


5) The config has a concept of "default value" for each configuration
attribute. However, the default values are not clearly specified. This
needs to be resolved to be able to support "default values".

<PRC> Another good point raised by David.


6) the documentation of which "binding specific" message elements are to
be included with CAPWAP messages is not consistent, and is difficult to
follow.

<PRC> Has this been addressed in the latest (-02) document?


7) There are some message elements that cause "actions". This approach
to protocol design is problematic and should be eliminated.

<PRC> Could you be more specific as well as provide guidance on what you
would like to see?


8) The message types are inconsistently named, and do not follow the
conventions of well designed protocols. Can the operations be named
consistently with the following terminology:
  1) request/response (used to get/set/perform action)
  2) report/ack (use to tell the other side something)

<PRC> Could you provide your thoughts on which messages fall within
which one of your categories?


9) Many of the configuration items, and status items are not listed in
one section with definitions. (Well make it two sections - one for
CAPWAP and the other which is "binding" specific.) For example, not all
of the time period lengths are identified and specified in section 4.5.

<PRC> Unfortunately, the document has gone back and forth a few times
and before we opt to change the structure of the document, I'd like to
ensure that we have broad agreement on what we want - with the
understanding that we will never make everyone happy.


10) each operation should have listed in which states it can be sent and
received

<PRC> I do not understand your comment.


11) All strings, such as WTP location, should be changed from US-ASCII
encoding to UTF-8 encoding.

<PRC> Agreed.

12) The term "mobile" is not really accurate when describing wireless
interfaces, since wireless does not imply      mobile. Can we just use
the techie term "STA" instead.

<PRC> I agree we should use the term Station, or STA for short.


13) The WTP Descriptor message element contains too much information,
lacks clarity on the WTP encryption field and includes version numbers,
which should be in string form.

<PRC> To the first point, I disagree. I think there is value in knowing
everything about the WTP. The AC vendors can expose whatever information
they want, but I don't believe anything is unnecessary.

<PRC> To the second point, this is one of those areas where the concept
of the technology binding creates complexity. Given that we cannot
simply discuss 802.11i at this point, the only thing we can do is punt
to another section in the technology binding section. That said, I agree
with Dave that the 802.11 binding section is too light in this area.
However, I would much prefer that instead of trying to address this
specific issue, we discuss whether we should even be supporting the mode
of operation where 802.11i is performed in the AC - especially with the
introduction of DTLS to secure the data plane. Right now, it just feels
like we have too many options and I am worried that interoperability
will be severely impacted (not to mention protocol complexity).

<PRC> To the last point, I have no issues with including text stating
that the version numbers should be in string form.


14) The WTP Descriptor information is not required at Join time.

<PRC> Well, as far as I can tell, I think there's value in knowing
whether the WTP can even be supported by the AC. So the more info is
provided by the WTP, the better the AC can determine whether it should
just ignore the WTP or not. This could be done because it knows that the
firmware running on the WTP is not compatible, and it has no new
firmware to download.


15) Are the values in the WTP Frame Encryption a capabilities bit, or an
enum?

<PRC> Looks like an enum to me. Not sure what Dave would prefer the text
to read. There are various other similar comments throughout, which I
will not repeat here.


16) The Discovery Response is broken. The AC SHOULD NOT be providing any
info to a WTP (or something that claims to be a WTP). Also, the AC
should tell the WTP what to do next, with choices: 1) Ok to try to join,
2) don't try to join, 3) try                     discover on a list of
returned ACs)

<PRC> I don't believe there is an issue with sending the AC's
information to the WTP, but would solicit input from the list. That
said, some of the information in the AC Descriptor is required, such as
the current load on the AC. No point is trying to join if he AC
indicates it's already at max capacity.
<PRC> I believe if the AC does not return the response, then it implies
(2). Otherwise, it is (1). (3) is handled during the join or configure
process, which I believe is right.


17) Is AC Name text?

<PRC> Yes, and same with WTP Name.


18) Primary Discovery are not required.

<PRC> Disagree. Required for failover.


19) The text does not make it clear that the contents of the WTP
Location is informative only, and as Dave calls it, a "scratchpad".

<PRC> Well, to be honest, I thought the example "next to the fridge"
made it clear that the information did not derive from any scientific
formula. The description also states this is a user-defined. I believe
this should be good enough.


20) Session is not required

<PRC> I believe you may be correct that with the transition to DTLS,
this is no longer required.


21) need to send "common name" as found in the WTP CERT so that the AC
can verify

<PRC> The protocol currently relies on the MAC address being the key
that binds the certificate to the WTP. I don't see a need to change
this.


22) Result code in Join Response is not sufficient, for instance WTP HW
not supported.

<PRC> Well, the protocol does not require this because the Discovery
Response would never be sent (as the protocol stands today).


23) AC IPv4/IPv6 Addr discusses clustering, which is unnecessary.

<PRC> Agreed.


24) Change Echo to Keepalive or heartbeat.

<PRC> I call it potato....


25) What if all of the message elements do not fit within a single
CAPWAP control frame.

<PRC> We should address this.


26) AC Name with Index is all messed up...

<PRC> Not really. You simply include more than one, and the index field
is clearly the priority. Don't understand the Multi-AC comment. No
inter-AC protocol implied here.


27) WTP Board Data belongs in the Join, not configure.

<PRC> Agreed, but wonder even more why we are duplicating this
information across both the WTP Descriptor and the WTP Board Data
message elements.


28) The WTP Static IPv4 Address should not have the Static bit, but
instead state that 0.0.0.0 means a static address is not to be used.

<PRC> I don't have an issue with this request, but in the end we have
the same function. The reason why I state this is that we can refine
this protocol until the cows come home, and at one point we need to draw
a line in the sand.


29) WTP Reboot Statistics belongs in the Join, and the reasons listed
are not clear enough.

<PRC> Doesn't really matter whether this is included in the
configuration or the join, but if the WG agrees to move it. We can
clarify some of the reasons, as long as it provides value.


30) The IEEE 802.11 WTP Radio Configuration message element's BSSID
field should be an array.

<PRC> Disagree.


30) The IEEE 802.11 WTP Radio Configuration message element's Country
Code is not clear enough.

<PRC> The text points to the actual MIB element in the 802.11-1999
standard, which very clearly defines the contents of the field. I don't
think there's value in replicating the format of this field in the
CAPWAP standard.


31) There seems like an awful lot of additional configuration message
elements that need to be specified here!

<PRC> Having built a protocol based on this, it's not clear to me what's
missing. I think it would be useful if you provided concrete details on
what's missing.


32) Configuration Status is just plain broken because any configuration
change operation may fail and there is no           response to the
configuration changes specified in this command.

<PRC> There certainly is - I guess I don't understand the concern.


33) Use of Change State Event should instead be Radio Admin State.

<PRC> Perhaps the two are not described properly. The first is used by
the WTP to inform the AC that something has occurred with a radio. The
second is used by the AC to enable/disable a radio.


34) Report Timer needs to be in section 4.5 or 11

<PRC> ok


35) Should Idle Timeout be per radio, or per WTP, and should the value
be defined in section 4.5 or 11.

<PRC> Per WTP, and yes. I believe it is fine as it is.


36) WTP Fallback isn't well defined, and should be removed.

<PRC> Disagree. I believe it is necessary to create enough resiliency in
the protocol/service.


37) How are the "Rate Set" and "Supported Rates" encoded.

<PRC> This was fixed in the -02


38) AC Timestamp doesn't belong in the configuration, but instead in the
join.

<PRC> Not sure this really matters....


39) Add MAC ACL Entry - this is so strange and is being managed like no
other configuration data.

<PRC> I do not understand the comment


40) Decryption Error Report Period is not defined in section 4.5 or 11

<PRC> ok, and note that the information has been moved to the IEEE
802.11 RSNA Error Report From Mobile


41) Configuration Update Response. today, there are primarily two types
of configuration models. The first is when config is changed, it is only
changed in the volatile copy (the memory or running). An explicit
command is needed to save the config to nonvolatile storage. The second
model has config both running (volatile) and saved (nonvolatile) config
changed when a config change is made. And there might be a special
command to have a config change apply to only one. In this case, there
is no need for a "save config to nonvolatile" command. It is not clear
what is suppose to be supported here in CAPWAP, and how does CAPWAP
support devices with no or very limited nonvolatile storage for config!

<PRC> CAPWAP does not support WTPs with no nonvolatile storage. The
protocol has the AC push configs to the WTP, which saves them at the
time they are received. I do not believe anything else is required.


42) Configuration Update Response includes the Result Code message
element, which includes values that do not appear to be relevant for
this message, and there are plenty of other failure cases

<PRC> ok, but note that we are sharing a common message element. Any
suggestions on how to address your issue?


43) Change State Event Report. This seems a little silly to be sent in
the "configure" state. It seems only appropriate for the "run" state.
Some might argue that even in the "run" state it shouldn't be sent after
a "config update" request that changes the operational state. However,
in the "run" state, it may take a while to have the operational state
change to follow the admin state. Thus, I think it is OK in the "run"
state after config changes."

<PRC> I believe this was addressed in -02.


44) Clear Config Request. this operation has several problems, which
include:
   1) currently, the CAPWAP-01 spec says that this can only be done in
the "run" state. This is silly. It should also be possible in the
"configure" state.
<PRC> I wonder why the AC would even consider clearing the WTP's state
before it even knows how it is configured.

   2) the value of "manufacturing defaults" is not defined, and a poor
term to use, since it implies that that each manufacturer can have
different values. If so, then the AC will have no knowledge of the
config on the WTP! The problem of "default config values" has already be
mentioned above. After each config attribute has been defined with a
default value, then the proper term would be "CAPWAP config defaults".
<PRC> Yes, you've raised this point already, and I agree that it does
need to be addressed.

   3) This operation is not defined to have a response. This is broken,
since any config change can fail. Also, it is not defined what happens
next. Does this cause the WTP to reboot an start a "clean discovery"?
<PRC> This was addressed in -02


45) Image Data Request. Yes, there are actually three different "Image
Data Request" messages. Which one is determined          by which of the
three message elements is contained. This is completely silly! There
should be three separate operations! Additionally, how does the WTP know
which image to get? The AC should be making that decision.

<PRC> I believe the WTP is the only device that knows what it's filename
should be. Why would an AC vendor know about file naming conventions
used by the WTP vendors? I believe your other issues are discussed in
the next items.


46) Image Data Response. this is silly. This operation can fail! There
needs to be message element that indicates the          result.

<PRC> How so? This is only used to send firmware to the WTP. Not clear
what could fail... Reading the image from flash?


47) Image Data Request. when starting over again at the WTP start state,
the WTP shouldn't use the "normal" discovery process, but instead "fast
track" a connection back to the AC that just downloaded the image. With
a little more          work, we could probably figure out a way to reuse
the old DTLS session.

<PRC> To what gain? What is so expensive about the discovery, and what
happened if the AC was not longer reachable?


48) opcode - if this is here, might as well also have a value that
indicates last block of the image file, instead of looking at the block
size.

<PRC> But we're just changing for the sake of changing - the protocol
works as-is.


49) since this operation does not have the block number as a parameter,
the WTP must determine the block number via the CAPWAP message header
sequence number.  NOTE: DTLS does not provide in-order delivery of
packets. Also, this requires the WTP to remember state. This message
element should be re-engineered to have the following subfields:
[edited]

<PRC> The control header includes a sequence number, and while we can
change the current protocol to match your recommendations, the protocol
does work. If it ain't broken...


50) Image Data Response. this is silly. This operation can fail!  For
example, the WTP can run out of space to store          the block, or
there could be a failure in writing the block to storage. (Or as "Image
Data Request"(9.1a) is presently specified, the checksum match could
fail.) There needs to be message element that indicates the result.)
Note: don't need a block number field, since request and responses are
paired.

<PRC> We can include a result code


51) Image Data Request. silly beyond belief

<PRC> Beauty is in the eye of the beholder ;-). Seriously, the protocol
does work, so what exactly are you looking for?


52) Image Data Response. This is silly. This operation can fail! There
needs to be message element that indicates the          result.

<PRC> See above comment.

53) Reset Request. ...

<PRC> The comment is irrelevant now that Clear Config has changed.


54) Reset Response. this is silly. This operation can fail! There needs
to be message element that indicates the          result.

<PRC> I sense a trend. I will stop including these messages from now on.


55)Duplicate IPv4 Address. how often is this reported if the condition
remains?

<PRC> Only required once, I think, but we may want to include some text
covering that.


56) the list of events seems understated!

<PRC> Text and conditions please


57) Data Transfer Request. Nice to have - remove.

<PRC> Disagree. Providing diagnostics capabilities is required.


58) Mobile Config Request. the actual details of how this works on both
splitMAC and especially localMAC are not well specified. That is, only
the figures and text in sections 11.1.1 and 11.1.2 provide any clue as
to events that would cause an AC to send this message type. Also, there
are restrictions on combinations of parameters that can be included in
the message.

<PRC> I wonder whether other folks agree that more details are required.


59) it doesn't say if one message can be used to update more than one
STA. It should be able.

<PRC> No, otherwise you end up with the problem of associating specific
message elements with a given mobile. One mobile per request.


60) IEEE 802.11 Mobile. shouldn't the STA MAC address be included so
this message element can be matched with a (4.4.8)Add Mobile message
element?

<PRC> I believe this is to your previous point, but the protocol assumes
one mobile per request.


61) IEEE 802.11 Update Mobile QoS. s this for data traffic to the AC? If
so, then why is this an 802.11 message element

<PRC> Intended to be a way to push policies to the WTP to prioritize
mobile traffic.


62) IEEE 802.11 WLAN Config Request. why is a new message type that is
802.11 specific needed to modify 802.11 WLANs? It seems like the
existing "(8.4)Configuration Update Request" message could be used.

<PRC> To be more specific only.


63) note here there are information elements to create, delete, and
modify WLANs. However, for message type "(10.1)Mobile Config Request",
there is only add and delete (and the "add" used to modify).

<PRC> Correct. The protocol requires the AC to resend a new add with a
different policy. No specific reason, but if this is deemed
inconsistent, we could change it.


64) IEEE 802.11 Assigned WTP BSSID. The mapping of WLAN IDs to BSSIDs
seems like it needs a little more work

<PRC> What exactly would you like to see?


Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems



> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: Thursday, June 22, 2006 4:31 PM
> To: capwap@frascone.com
> Subject: [Capwap] A commentary on CAPWAP-01 operations
>
> HI,
>
> I've attached a long file that summarizes the operations in
> CAPWAP-01.
>
> 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

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

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


------=_Part_18884_28545677.1159564911303-- --===============1683059389== 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 --===============1683059389==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 29 17:39:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTQ4i-0002Vd-3F for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 17:39:16 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTQ4e-0000ls-6D for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 17:39:15 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id DE9B61448041 for ; Fri, 29 Sep 2006 14:38:59 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7BC9B430059 for ; Fri, 29 Sep 2006 14:33:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5E2BA144803F for ; Fri, 29 Sep 2006 14:33:50 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by hermes.tigertech.net (Postfix) with ESMTP id B76F6144803B for ; Fri, 29 Sep 2006 14:33:46 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so1085179nfb for ; Fri, 29 Sep 2006 14:33:45 -0700 (PDT) Received: by 10.48.48.18 with SMTP id v18mr2249422nfv; Fri, 29 Sep 2006 14:33:45 -0700 (PDT) Received: by 10.49.42.6 with HTTP; Fri, 29 Sep 2006 14:33:45 -0700 (PDT) Message-ID: <5bfe7a820609291433w7a6ef0e1g9086172c593fab19@mail.gmail.com> Date: Fri, 29 Sep 2006 14:33:45 -0700 From: "Dorothy Stanley" To: "Michael Montemurro" 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.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_20_30, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: capwap@frascone.com Subject: [Capwap] Proposed Resolution to Issue 170 "Result code in Join Response is not sufficient" /was Re: A commentary on CAPWAP-01 operations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1350211254==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.1 (+) X-Scan-Signature: 3c84bd88e6bbcc6464f782162bb7ae94 --===============1350211254== Content-Type: multipart/alternative; boundary="----=_Part_19052_9116103.1159565625042" ------=_Part_19052_9116103.1159565625042 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, Issue 170 is listed below: ** *22) Result code in Join Response is not sufficient, for instance WTP HW not supported. Well, the protocol does not require this because the Discovery Response would never be sent (as the protocol stands today).* The proposed resolution to Issue 170 is: If Discover Request/Response messages are sent, then the current Result codes are sufficient. But if the Discover Request/Response messages are not sent - they are indicated as optional in the text, then the commenter is correct. Insert the following result code value at the end of 4.4.28: 8 Failure (Join Failure, WTP Hardware not supported) Comments welcome. Thanks, Dorothy On 6/30/06, Michael Montemurro wrote: > > David, Pat, > > I created issues 150-198 to deal with the points in David's email. Happy > hunting! > > Mike > > > On 6/27/06, Pat Calhoun (pacalhou) wrote: > > > > Going through David's lengthy document, he has raised an interesting > > number of points that I believe require issues to be created. At one > > point I'm paraphrasing Dave's comments in order to be brief, and > > introducing my own numbering scheme. > > > > 1) Can message elements be in any order? (I believe they should be) > > > > Yes, and I suspect we need to include text to make it more > > obvious. > > > > > > 2) Are all specified message elements required? (The obvious answer is > > "yes", but this document doesn't discuss versioning. For example, what > > if in a new version of CAPWAP an additional message element was to be > > added. Would a new message type be created and the additional message > > element added to it, or the existing type reused?) > > > > This is a great question, and one that does need to be addressed > > in the spec. In the Diameter protocol we dealt with this issue by > > including a "Mandatory to implement" bit. If any AVP was received, whose > > bit was set, yet was not recognized, then the request had to be > > rejected. > > > > We could consider something similar here, but I believe with the > > firmware download component of the protocol it may be less of an issue - > > although not guaranteed. I would hope (and expect) that as the CAPWAP > > protocol extends, the AC would push new firmware to the WTP. This does > > require that the initial part of the state machine be fairly static, and > > this could be an area where the "Mandatory to implement" bit could be > > useful as it would allow the AC to fall back to older protocol behavior. > > > > > > 3) CAPWAP-01 doesn't do a good job of indicating which message elements > > can be repeated. > > > > Another good point. When we list the message elements, we should > > note whether the frequently is 0-1 (meaning absent or once), 1 (only > > once) or 0+ (meaning any number of them could be present. > > > > > > 4) Can "additional" message elements be added to a message? (I believe > > so for reporting capabilities, statistics, and events. For > > configuration, there is nothing in the protocol that says what happens > > when one end gets an configuration element it doesn't know about. > > Should it be ignored, and the other elements processed, or should the > > complete operation failed?) > > > > The "Mandatory to implement" bit above could address this issue. > > If an unrecognized message element is found to have the bit set, then > > the whole message needs to be rejected. If the bit is not set, the > > message element may be safely ignored. > > > > > > 5) The config has a concept of "default value" for each configuration > > attribute. However, the default values are not clearly specified. This > > needs to be resolved to be able to support "default values". > > > > Another good point raised by David. > > > > > > 6) the documentation of which "binding specific" message elements are to > > be included with CAPWAP messages is not consistent, and is difficult to > > follow. > > > > Has this been addressed in the latest (-02) document? > > > > > > 7) There are some message elements that cause "actions". This approach > > to protocol design is problematic and should be eliminated. > > > > Could you be more specific as well as provide guidance on what you > > would like to see? > > > > > > 8) The message types are inconsistently named, and do not follow the > > conventions of well designed protocols. Can the operations be named > > consistently with the following terminology: > > 1) request/response (used to get/set/perform action) > > 2) report/ack (use to tell the other side something) > > > > Could you provide your thoughts on which messages fall within > > which one of your categories? > > > > > > 9) Many of the configuration items, and status items are not listed in > > one section with definitions. (Well make it two sections - one for > > CAPWAP and the other which is "binding" specific.) For example, not all > > of the time period lengths are identified and specified in section 4.5. > > > > Unfortunately, the document has gone back and forth a few times > > and before we opt to change the structure of the document, I'd like to > > ensure that we have broad agreement on what we want - with the > > understanding that we will never make everyone happy. > > > > > > 10) each operation should have listed in which states it can be sent and > > received > > > > I do not understand your comment. > > > > > > 11) All strings, such as WTP location, should be changed from US-ASCII > > encoding to UTF-8 encoding. > > > > Agreed. > > > > 12) The term "mobile" is not really accurate when describing wireless > > interfaces, since wireless does not imply mobile. Can we just use > > the techie term "STA" instead. > > > > I agree we should use the term Station, or STA for short. > > > > > > 13) The WTP Descriptor message element contains too much information, > > lacks clarity on the WTP encryption field and includes version numbers, > > which should be in string form. > > > > To the first point, I disagree. I think there is value in knowing > > everything about the WTP. The AC vendors can expose whatever information > > > > they want, but I don't believe anything is unnecessary. > > > > To the second point, this is one of those areas where the concept > > of the technology binding creates complexity. Given that we cannot > > simply discuss 802.11i at this point, the only thing we can do is punt > > to another section in the technology binding section. That said, I agree > > with Dave that the 802.11 binding section is too light in this area. > > However, I would much prefer that instead of trying to address this > > specific issue, we discuss whether we should even be supporting the mode > > of operation where 802.11i is performed in the AC - especially with the > > introduction of DTLS to secure the data plane. Right now, it just feels > > like we have too many options and I am worried that interoperability > > will be severely impacted (not to mention protocol complexity). > > > > To the last point, I have no issues with including text stating > > that the version numbers should be in string form. > > > > > > 14) The WTP Descriptor information is not required at Join time. > > > > Well, as far as I can tell, I think there's value in knowing > > whether the WTP can even be supported by the AC. So the more info is > > provided by the WTP, the better the AC can determine whether it should > > just ignore the WTP or not. This could be done because it knows that the > > firmware running on the WTP is not compatible, and it has no new > > firmware to download. > > > > > > 15) Are the values in the WTP Frame Encryption a capabilities bit, or an > > enum? > > > > Looks like an enum to me. Not sure what Dave would prefer the text > > to read. There are various other similar comments throughout, which I > > will not repeat here. > > > > > > 16) The Discovery Response is broken. The AC SHOULD NOT be providing any > > info to a WTP (or something that claims to be a WTP). Also, the AC > > should tell the WTP what to do next, with choices: 1) Ok to try to join, > > > > 2) don't try to join, 3) try discover on a list of > > returned ACs) > > > > I don't believe there is an issue with sending the AC's > > information to the WTP, but would solicit input from the list. That > > said, some of the information in the AC Descriptor is required, such as > > the current load on the AC. No point is trying to join if he AC > > indicates it's already at max capacity. > > I believe if the AC does not return the response, then it implies > > (2). Otherwise, it is (1). (3) is handled during the join or configure > > process, which I believe is right. > > > > > > 17) Is AC Name text? > > > > Yes, and same with WTP Name. > > > > > > 18) Primary Discovery are not required. > > > > Disagree. Required for failover. > > > > > > 19) The text does not make it clear that the contents of the WTP > > Location is informative only, and as Dave calls it, a "scratchpad". > > > > Well, to be honest, I thought the example "next to the fridge" > > made it clear that the information did not derive from any scientific > > formula. The description also states this is a user-defined. I believe > > this should be good enough. > > > > > > 20) Session is not required > > > > I believe you may be correct that with the transition to DTLS, > > this is no longer required. > > > > > > 21) need to send "common name" as found in the WTP CERT so that the AC > > can verify > > > > The protocol currently relies on the MAC address being the key > > that binds the certificate to the WTP. I don't see a need to change > > this. > > > > > > 22) Result code in Join Response is not sufficient, for instance WTP HW > > not supported. > > > > Well, the protocol does not require this because the Discovery > > Response would never be sent (as the protocol stands today). > > > > > > 23) AC IPv4/IPv6 Addr discusses clustering, which is unnecessary. > > > > Agreed. > > > > > > 24) Change Echo to Keepalive or heartbeat. > > > > I call it potato.... > > > > > > 25) What if all of the message elements do not fit within a single > > CAPWAP control frame. > > > > We should address this. > > > > > > 26) AC Name with Index is all messed up... > > > > Not really. You simply include more than one, and the index field > > is clearly the priority. Don't understand the Multi-AC comment. No > > inter-AC protocol implied here. > > > > > > 27) WTP Board Data belongs in the Join, not configure. > > > > Agreed, but wonder even more why we are duplicating this > > information across both the WTP Descriptor and the WTP Board Data > > message elements. > > > > > > 28) The WTP Static IPv4 Address should not have the Static bit, but > > instead state that 0.0.0.0 means a static address is not to be used. > > > > I don't have an issue with this request, but in the end we have > > the same function. The reason why I state this is that we can refine > > this protocol until the cows come home, and at one point we need to draw > > a line in the sand. > > > > > > 29) WTP Reboot Statistics belongs in the Join, and the reasons listed > > are not clear enough. > > > > Doesn't really matter whether this is included in the > > configuration or the join, but if the WG agrees to move it. We can > > clarify some of the reasons, as long as it provides value. > > > > > > 30) The IEEE 802.11 WTP Radio Configuration message element's BSSID > > field should be an array. > > > > Disagree. > > > > > > 30) The IEEE 802.11 WTP Radio Configuration message element's Country > > Code is not clear enough. > > > > The text points to the actual MIB element in the 802.11-1999 > > standard, which very clearly defines the contents of the field. I don't > > think there's value in replicating the format of this field in the > > CAPWAP standard. > > > > > > 31) There seems like an awful lot of additional configuration message > > elements that need to be specified here! > > > > Having built a protocol based on this, it's not clear to me what's > > > > missing. I think it would be useful if you provided concrete details on > > what's missing. > > > > > > 32) Configuration Status is just plain broken because any configuration > > change operation may fail and there is no response to the > > configuration changes specified in this command. > > > > There certainly is - I guess I don't understand the concern. > > > > > > 33) Use of Change State Event should instead be Radio Admin State. > > > > Perhaps the two are not described properly. The first is used by > > the WTP to inform the AC that something has occurred with a radio. The > > second is used by the AC to enable/disable a radio. > > > > > > 34) Report Timer needs to be in section 4.5 or 11 > > > > ok > > > > > > 35) Should Idle Timeout be per radio, or per WTP, and should the value > > be defined in section 4.5 or 11. > > > > Per WTP, and yes. I believe it is fine as it is. > > > > > > 36) WTP Fallback isn't well defined, and should be removed. > > > > Disagree. I believe it is necessary to create enough resiliency in > > the protocol/service. > > > > > > 37) How are the "Rate Set" and "Supported Rates" encoded. > > > > This was fixed in the -02 > > > > > > 38) AC Timestamp doesn't belong in the configuration, but instead in the > > join. > > > > Not sure this really matters.... > > > > > > 39) Add MAC ACL Entry - this is so strange and is being managed like no > > other configuration data. > > > > I do not understand the comment > > > > > > 40) Decryption Error Report Period is not defined in section 4.5 or 11 > > > > ok, and note that the information has been moved to the IEEE > > 802.11 RSNA Error Report From Mobile > > > > > > 41) Configuration Update Response. today, there are primarily two types > > of configuration models. The first is when config is changed, it is only > > changed in the volatile copy (the memory or running). An explicit > > command is needed to save the config to nonvolatile storage. The second > > model has config both running (volatile) and saved (nonvolatile) config > > changed when a config change is made. And there might be a special > > command to have a config change apply to only one. In this case, there > > is no need for a "save config to nonvolatile" command. It is not clear > > what is suppose to be supported here in CAPWAP, and how does CAPWAP > > support devices with no or very limited nonvolatile storage for config! > > > > CAPWAP does not support WTPs with no nonvolatile storage. The > > protocol has the AC push configs to the WTP, which saves them at the > > time they are received. I do not believe anything else is required. > > > > > > 42) Configuration Update Response includes the Result Code message > > element, which includes values that do not appear to be relevant for > > this message, and there are plenty of other failure cases > > > > ok, but note that we are sharing a common message element. Any > > suggestions on how to address your issue? > > > > > > 43) Change State Event Report. This seems a little silly to be sent in > > the "configure" state. It seems only appropriate for the "run" state. > > Some might argue that even in the "run" state it shouldn't be sent after > > a "config update" request that changes the operational state. However, > > in the "run" state, it may take a while to have the operational state > > change to follow the admin state. Thus, I think it is OK in the "run" > > state after config changes." > > > > I believe this was addressed in -02. > > > > > > 44) Clear Config Request. this operation has several problems, which > > include: > > 1) currently, the CAPWAP-01 spec says that this can only be done in > > the "run" state. This is silly. It should also be possible in the > > "configure" state. > > I wonder why the AC would even consider clearing the WTP's state > > before it even knows how it is configured. > > > > 2) the value of "manufacturing defaults" is not defined, and a poor > > term to use, since it implies that that each manufacturer can have > > different values. If so, then the AC will have no knowledge of the > > config on the WTP! The problem of "default config values" has already be > > > > mentioned above. After each config attribute has been defined with a > > default value, then the proper term would be "CAPWAP config defaults". > > Yes, you've raised this point already, and I agree that it does > > need to be addressed. > > > > 3) This operation is not defined to have a response. This is broken, > > since any config change can fail. Also, it is not defined what happens > > next. Does this cause the WTP to reboot an start a "clean discovery"? > > This was addressed in -02 > > > > > > 45) Image Data Request. Yes, there are actually three different "Image > > Data Request" messages. Which one is determined by which of the > > three message elements is contained. This is completely silly! There > > should be three separate operations! Additionally, how does the WTP know > > which image to get? The AC should be making that decision. > > > > I believe the WTP is the only device that knows what it's filename > > > > should be. Why would an AC vendor know about file naming conventions > > used by the WTP vendors? I believe your other issues are discussed in > > the next items. > > > > > > 46) Image Data Response. this is silly. This operation can fail! There > > needs to be message element that indicates the result. > > > > How so? This is only used to send firmware to the WTP. Not clear > > what could fail... Reading the image from flash? > > > > > > 47) Image Data Request. when starting over again at the WTP start state, > > > > the WTP shouldn't use the "normal" discovery process, but instead "fast > > track" a connection back to the AC that just downloaded the image. With > > a little more work, we could probably figure out a way to reuse > > > > the old DTLS session. > > > > To what gain? What is so expensive about the discovery, and what > > happened if the AC was not longer reachable? > > > > > > 48) opcode - if this is here, might as well also have a value that > > indicates last block of the image file, instead of looking at the block > > size. > > > > But we're just changing for the sake of changing - the protocol > > works as-is. > > > > > > 49) since this operation does not have the block number as a parameter, > > the WTP must determine the block number via the CAPWAP message header > > sequence number. NOTE: DTLS does not provide in-order delivery of > > packets. Also, this requires the WTP to remember state. This message > > element should be re-engineered to have the following subfields: > > [edited] > > > > The control header includes a sequence number, and while we can > > change the current protocol to match your recommendations, the protocol > > does work. If it ain't broken... > > > > > > 50) Image Data Response. this is silly. This operation can fail! For > > example, the WTP can run out of space to store the block, or > > there could be a failure in writing the block to storage. (Or as "Image > > Data Request"(9.1a) is presently specified, the checksum match could > > fail.) There needs to be message element that indicates the result.) > > Note: don't need a block number field, since request and responses are > > paired. > > > > We can include a result code > > > > > > 51) Image Data Request. silly beyond belief > > > > Beauty is in the eye of the beholder ;-). Seriously, the protocol > > does work, so what exactly are you looking for? > > > > > > 52) Image Data Response. This is silly. This operation can fail! There > > needs to be message element that indicates the result. > > > > See above comment. > > > > 53) Reset Request. ... > > > > The comment is irrelevant now that Clear Config has changed. > > > > > > 54) Reset Response. this is silly. This operation can fail! There needs > > to be message element that indicates the result. > > > > I sense a trend. I will stop including these messages from now on. > > > > > > 55)Duplicate IPv4 Address. how often is this reported if the condition > > remains? > > > > Only required once, I think, but we may want to include some text > > covering that. > > > > > > 56) the list of events seems understated! > > > > Text and conditions please > > > > > > 57) Data Transfer Request. Nice to have - remove. > > > > Disagree. Providing diagnostics capabilities is required. > > > > > > 58) Mobile Config Request. the actual details of how this works on both > > splitMAC and especially localMAC are not well specified. That is, only > > the figures and text in sections 11.1.1 and 11.1.2 provide any clue as > > to events that would cause an AC to send this message type. Also, there > > are restrictions on combinations of parameters that can be included in > > the message. > > > > I wonder whether other folks agree that more details are required. > > > > > > 59) it doesn't say if one message can be used to update more than one > > STA. It should be able. > > > > No, otherwise you end up with the problem of associating specific > > message elements with a given mobile. One mobile per request. > > > > > > 60) IEEE 802.11 Mobile. shouldn't the STA MAC address be included so > > this message element can be matched with a (4.4.8)Add Mobile message > > element? > > > > I believe this is to your previous point, but the protocol assumes > > one mobile per request. > > > > > > 61) IEEE 802.11 Update Mobile QoS. s this for data traffic to the AC? If > > so, then why is this an 802.11 message element > > > > Intended to be a way to push policies to the WTP to prioritize > > mobile traffic. > > > > > > 62) IEEE 802.11 WLAN Config Request. why is a new message type that is > > 802.11 specific needed to modify 802.11 WLANs? It seems like the > > existing "(8.4)Configuration Update Request" message could be used. > > > > To be more specific only. > > > > > > 63) note here there are information elements to create, delete, and > > modify WLANs. However, for message type "(10.1)Mobile Config Request", > > there is only add and delete (and the "add" used to modify). > > > > Correct. The protocol requires the AC to resend a new add with a > > different policy. No specific reason, but if this is deemed > > inconsistent, we could change it. > > > > > > 64) IEEE 802.11 Assigned WTP BSSID. The mapping of WLAN IDs to BSSIDs > > seems like it needs a little more work > > > > What exactly would you like to see? > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > -----Original Message----- > > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > > Sent: Thursday, June 22, 2006 4:31 PM > > > To: capwap@frascone.com > > > Subject: [Capwap] A commentary on CAPWAP-01 operations > > > > > > HI, > > > > > > I've attached a long file that summarizes the operations in > > > CAPWAP-01. > > > > > > 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 > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_19052_9116103.1159565625042 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
All,
 
Issue 170 is listed below:
 
22) Result code in Join Response is not sufficient, for instance WTP HW
not supported.

<PRC> Well, the protocol does not require this because the Discovery
Response would never be sent (as the protocol stands today).
 
The proposed resolution to Issue 170 is:
 
If  Discover Request/Response messages are sent, then the current
Result codes are sufficient. But if the Discover Request/Response messages
are not sent - they are indicated as optional in the text, then the commenter
is correct.
 
Insert the following result code value at the end of 4.4.28:
 
8  Failure (Join Failure, WTP Hardware not supported)
 
 
Comments welcome.
 
Thanks,
 
Dorothy

 
On 6/30/06, Michael Montemurro <montemurro.michael@gmail.com> wrote:
David, Pat,
 
I created issues 150-198 to deal with the points in David's email. Happy hunting!
 
Mike

 
On 6/27/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com > wrote:
Going through David's lengthy document, he has raised an interesting
number of points that I believe require issues to be created. At one
point I'm paraphrasing Dave's comments in order to be brief, and
introducing my own numbering scheme.

1) Can message elements be in any order? (I believe they should be)

<PRC> Yes, and I suspect we need to include text to make it more
obvious.


2) Are all specified message elements required? (The obvious answer is
"yes", but this document doesn't discuss versioning. For example, what
if in a new version of CAPWAP an additional message element was to be
added. Would a new message type be created and the additional message
element added to it, or the existing type reused?)

<PRC> This is a great question, and one that does need to be addressed
in the spec. In the Diameter protocol we dealt with this issue by
including a "Mandatory to implement" bit. If any AVP was received, whose
bit was set, yet was not recognized, then the request had to be
rejected.

<PRC> We could consider something similar here, but I believe with the
firmware download component of the protocol it may be less of an issue -
although not guaranteed. I would hope (and expect) that as the CAPWAP
protocol extends, the AC would push new firmware to the WTP. This does
require that the initial part of the state machine be fairly static, and
this could be an area where the "Mandatory to implement" bit could be
useful as it would allow the AC to fall back to older protocol behavior.

3) CAPWAP-01 doesn't do a good job of indicating which message elements
can be repeated.

<PRC> Another good point. When we list the message elements, we should
note whether the frequently is 0-1 (meaning absent or once), 1 (only
once) or 0+ (meaning any number of them could be present.


4) Can "additional" message elements be added to a message? (I believe
so for reporting capabilities, statistics, and     events. For
configuration, there is nothing in the protocol that says what happens
when one end gets an configuration     element it doesn't know about.
Should it be ignored, and the other elements processed, or should the
complete operation     failed?)

<PRC> The "Mandatory to implement" bit above could address this issue.
If an unrecognized message element is found to have the bit set, then
the whole message needs to be rejected. If the bit is not set, the
message element may be safely ignored.


5) The config has a concept of "default value" for each configuration
attribute. However, the default values are not clearly specified. This
needs to be resolved to be able to support "default values".

<PRC> Another good point raised by David.


6) the documentation of which "binding specific" message elements are to
be included with CAPWAP messages is not consistent, and is difficult to
follow.

<PRC> Has this been addressed in the latest (-02) document?


7) There are some message elements that cause "actions". This approach
to protocol design is problematic and should be eliminated.

<PRC> Could you be more specific as well as provide guidance on what you
would like to see?


8) The message types are inconsistently named, and do not follow the
conventions of well designed protocols. Can the operations be named
consistently with the following terminology:
  1) request/response (used to get/set/perform action)
  2) report/ack (use to tell the other side something)

<PRC> Could you provide your thoughts on which messages fall within
which one of your categories?


9) Many of the configuration items, and status items are not listed in
one section with definitions. (Well make it two sections - one for
CAPWAP and the other which is "binding" specific.) For example, not all
of the time period lengths are identified and specified in section 4.5.

<PRC> Unfortunately, the document has gone back and forth a few times
and before we opt to change the structure of the document, I'd like to
ensure that we have broad agreement on what we want - with the
understanding that we will never make everyone happy.


10) each operation should have listed in which states it can be sent and
received

<PRC> I do not understand your comment.


11) All strings, such as WTP location, should be changed from US-ASCII
encoding to UTF-8 encoding.

<PRC> Agreed.

12) The term "mobile" is not really accurate when describing wireless
interfaces, since wireless does not imply      mobile. Can we just use
the techie term "STA" instead.

<PRC> I agree we should use the term Station, or STA for short.


13) The WTP Descriptor message element contains too much information,
lacks clarity on the WTP encryption field and includes version numbers,
which should be in string form.

<PRC> To the first point, I disagree. I think there is value in knowing
everything about the WTP. The AC vendors can expose whatever information
they want, but I don't believe anything is unnecessary.

<PRC> To the second point, this is one of those areas where the concept
of the technology binding creates complexity. Given that we cannot
simply discuss 802.11i at this point, the only thing we can do is punt
to another section in the technology binding section. That said, I agree
with Dave that the 802.11 binding section is too light in this area.
However, I would much prefer that instead of trying to address this
specific issue, we discuss whether we should even be supporting the mode
of operation where 802.11i is performed in the AC - especially with the
introduction of DTLS to secure the data plane. Right now, it just feels
like we have too many options and I am worried that interoperability
will be severely impacted (not to mention protocol complexity).

<PRC> To the last point, I have no issues with including text stating
that the version numbers should be in string form.


14) The WTP Descriptor information is not required at Join time.

<PRC> Well, as far as I can tell, I think there's value in knowing
whether the WTP can even be supported by the AC. So the more info is
provided by the WTP, the better the AC can determine whether it should
just ignore the WTP or not. This could be done because it knows that the
firmware running on the WTP is not compatible, and it has no new
firmware to download.


15) Are the values in the WTP Frame Encryption a capabilities bit, or an
enum?

<PRC> Looks like an enum to me. Not sure what Dave would prefer the text
to read. There are various other similar comments throughout, which I
will not repeat here.


16) The Discovery Response is broken. The AC SHOULD NOT be providing any
info to a WTP (or something that claims to be a WTP). Also, the AC
should tell the WTP what to do next, with choices: 1) Ok to try to join,
2) don't try to join, 3) try                     discover on a list of
returned ACs)

<PRC> I don't believe there is an issue with sending the AC's
information to the WTP, but would solicit input from the list. That
said, some of the information in the AC Descriptor is required, such as
the current load on the AC. No point is trying to join if he AC
indicates it's already at max capacity.
<PRC> I believe if the AC does not return the response, then it implies
(2). Otherwise, it is (1). (3) is handled during the join or configure
process, which I believe is right.


17) Is AC Name text?

<PRC> Yes, and same with WTP Name.


18) Primary Discovery are not required.

<PRC> Disagree. Required for failover.


19) The text does not make it clear that the contents of the WTP
Location is informative only, and as Dave calls it, a "scratchpad".

<PRC> Well, to be honest, I thought the example "next to the fridge"
made it clear that the information did not derive from any scientific
formula. The description also states this is a user-defined. I believe
this should be good enough.


20) Session is not required

<PRC> I believe you may be correct that with the transition to DTLS,
this is no longer required.


21) need to send "common name" as found in the WTP CERT so that the AC
can verify

<PRC> The protocol currently relies on the MAC address being the key
that binds the certificate to the WTP. I don't see a need to change
this.


22) Result code in Join Response is not sufficient, for instance WTP HW
not supported.

<PRC> Well, the protocol does not require this because the Discovery
Response would never be sent (as the protocol stands today).


23) AC IPv4/IPv6 Addr discusses clustering, which is unnecessary.

<PRC> Agreed.


24) Change Echo to Keepalive or heartbeat.

<PRC> I call it potato....


25) What if all of the message elements do not fit within a single
CAPWAP control frame.

<PRC> We should address this.


26) AC Name with Index is all messed up...

<PRC> Not really. You simply include more than one, and the index field
is clearly the priority. Don't understand the Multi-AC comment. No
inter-AC protocol implied here.


27) WTP Board Data belongs in the Join, not configure.

<PRC> Agreed, but wonder even more why we are duplicating this
information across both the WTP Descriptor and the WTP Board Data
message elements.


28) The WTP Static IPv4 Address should not have the Static bit, but
instead state that 0.0.0.0 means a static address is not to be used.

<PRC> I don't have an issue with this request, but in the end we have
the same function. The reason why I state this is that we can refine
this protocol until the cows come home, and at one point we need to draw
a line in the sand.


29) WTP Reboot Statistics belongs in the Join, and the reasons listed
are not clear enough.

<PRC> Doesn't really matter whether this is included in the
configuration or the join, but if the WG agrees to move it. We can
clarify some of the reasons, as long as it provides value.


30) The IEEE 802.11 WTP Radio Configuration message element's BSSID
field should be an array.

<PRC> Disagree.


30) The IEEE 802.11 WTP Radio Configuration message element's Country
Code is not clear enough.

<PRC> The text points to the actual MIB element in the 802.11-1999
standard, which very clearly defines the contents of the field. I don't
think there's value in replicating the format of this field in the
CAPWAP standard.


31) There seems like an awful lot of additional configuration message
elements that need to be specified here!

<PRC> Having built a protocol based on this, it's not clear to me what's
missing. I think it would be useful if you provided concrete details on
what's missing.


32) Configuration Status is just plain broken because any configuration
change operation may fail and there is no           response to the
configuration changes specified in this command.

<PRC> There certainly is - I guess I don't understand the concern.


33) Use of Change State Event should instead be Radio Admin State.

<PRC> Perhaps the two are not described properly. The first is used by
the WTP to inform the AC that something has occurred with a radio. The
second is used by the AC to enable/disable a radio.


34) Report Timer needs to be in section 4.5 or 11

<PRC> ok


35) Should Idle Timeout be per radio, or per WTP, and should the value
be defined in section 4.5 or 11.

<PRC> Per WTP, and yes. I believe it is fine as it is.


36) WTP Fallback isn't well defined, and should be removed.

<PRC> Disagree. I believe it is necessary to create enough resiliency in
the protocol/service.


37) How are the "Rate Set" and "Supported Rates" encoded.

<PRC> This was fixed in the -02


38) AC Timestamp doesn't belong in the configuration, but instead in the
join.

<PRC> Not sure this really matters....


39) Add MAC ACL Entry - this is so strange and is being managed like no
other configuration data.

<PRC> I do not understand the comment


40) Decryption Error Report Period is not defined in section 4.5 or 11

<PRC> ok, and note that the information has been moved to the IEEE
802.11 RSNA Error Report From Mobile


41) Configuration Update Response. today, there are primarily two types
of configuration models. The first is when config is changed, it is only
changed in the volatile copy (the memory or running). An explicit
command is needed to save the config to nonvolatile storage. The second
model has config both running (volatile) and saved (nonvolatile) config
changed when a config change is made. And there might be a special
command to have a config change apply to only one. In this case, there
is no need for a "save config to nonvolatile" command. It is not clear
what is suppose to be supported here in CAPWAP, and how does CAPWAP
support devices with no or very limited nonvolatile storage for config!

<PRC> CAPWAP does not support WTPs with no nonvolatile storage. The
protocol has the AC push configs to the WTP, which saves them at the
time they are received. I do not believe anything else is required.


42) Configuration Update Response includes the Result Code message
element, which includes values that do not appear to be relevant for
this message, and there are plenty of other failure cases

<PRC> ok, but note that we are sharing a common message element. Any
suggestions on how to address your issue?


43) Change State Event Report. This seems a little silly to be sent in
the "configure" state. It seems only appropriate for the "run" state.
Some might argue that even in the "run" state it shouldn't be sent after
a "config update" request that changes the operational state. However,
in the "run" state, it may take a while to have the operational state
change to follow the admin state. Thus, I think it is OK in the "run"
state after config changes."

<PRC> I believe this was addressed in -02.


44) Clear Config Request. this operation has several problems, which
include:
   1) currently, the CAPWAP-01 spec says that this can only be done in
the "run" state. This is silly. It should also be possible in the
"configure" state.
<PRC> I wonder why the AC would even consider clearing the WTP's state
before it even knows how it is configured.

   2) the value of "manufacturing defaults" is not defined, and a poor
term to use, since it implies that that each manufacturer can have
different values. If so, then the AC will have no knowledge of the
config on the WTP! The problem of "default config values" has already be
mentioned above. After each config attribute has been defined with a
default value, then the proper term would be "CAPWAP config defaults".
<PRC> Yes, you've raised this point already, and I agree that it does
need to be addressed.

   3) This operation is not defined to have a response. This is broken,
since any config change can fail. Also, it is not defined what happens
next. Does this cause the WTP to reboot an start a "clean discovery"?
<PRC> This was addressed in -02


45) Image Data Request. Yes, there are actually three different "Image
Data Request" messages. Which one is determined          by which of the
three message elements is contained. This is completely silly! There
should be three separate operations! Additionally, how does the WTP know
which image to get? The AC should be making that decision.

<PRC> I believe the WTP is the only device that knows what it's filename
should be. Why would an AC vendor know about file naming conventions
used by the WTP vendors? I believe your other issues are discussed in
the next items.


46) Image Data Response. this is silly. This operation can fail! There
needs to be message element that indicates the          result.

<PRC> How so? This is only used to send firmware to the WTP. Not clear
what could fail... Reading the image from flash?


47) Image Data Request. when starting over again at the WTP start state,
the WTP shouldn't use the "normal" discovery process, but instead "fast
track" a connection back to the AC that just downloaded the image. With
a little more          work, we could probably figure out a way to reuse
the old DTLS session.

<PRC> To what gain? What is so expensive about the discovery, and what
happened if the AC was not longer reachable?


48) opcode - if this is here, might as well also have a value that
indicates last block of the image file, instead of looking at the block
size.

<PRC> But we're just changing for the sake of changing - the protocol
works as-is.


49) since this operation does not have the block number as a parameter,
the WTP must determine the block number via the CAPWAP message header
sequence number.  NOTE: DTLS does not provide in-order delivery of
packets. Also, this requires the WTP to remember state. This message
element should be re-engineered to have the following subfields:
[edited]

<PRC> The control header includes a sequence number, and while we can
change the current protocol to match your recommendations, the protocol
does work. If it ain't broken...


50) Image Data Response. this is silly. This operation can fail!  For
example, the WTP can run out of space to store          the block, or
there could be a failure in writing the block to storage. (Or as "Image
Data Request"(9.1a) is presently specified, the checksum match could
fail.) There needs to be message element that indicates the result.)
Note: don't need a block number field, since request and responses are
paired.

<PRC> We can include a result code


51) Image Data Request. silly beyond belief

<PRC> Beauty is in the eye of the beholder ;-). Seriously, the protocol
does work, so what exactly are you looking for?


52) Image Data Response. This is silly. This operation can fail! There
needs to be message element that indicates the          result.

<PRC> See above comment.

53) Reset Request. ...

<PRC> The comment is irrelevant now that Clear Config has changed.


54) Reset Response. this is silly. This operation can fail! There needs
to be message element that indicates the          result.

<PRC> I sense a trend. I will stop including these messages from now on.


55)Duplicate IPv4 Address. how often is this reported if the condition
remains?

<PRC> Only required once, I think, but we may want to include some text
covering that.


56) the list of events seems understated!

<PRC> Text and conditions please


57) Data Transfer Request. Nice to have - remove.

<PRC> Disagree. Providing diagnostics capabilities is required.


58) Mobile Config Request. the actual details of how this works on both
splitMAC and especially localMAC are not well specified. That is, only
the figures and text in sections 11.1.1 and 11.1.2 provide any clue as
to events that would cause an AC to send this message type. Also, there
are restrictions on combinations of parameters that can be included in
the message.

<PRC> I wonder whether other folks agree that more details are required.


59) it doesn't say if one message can be used to update more than one
STA. It should be able.

<PRC> No, otherwise you end up with the problem of associating specific
message elements with a given mobile. One mobile per request.


60) IEEE 802.11 Mobile. shouldn't the STA MAC address be included so
this message element can be matched with a (4.4.8)Add Mobile message
element?

<PRC> I believe this is to your previous point, but the protocol assumes
one mobile per request.


61) IEEE 802.11 Update Mobile QoS. s this for data traffic to the AC? If
so, then why is this an 802.11 message element

<PRC> Intended to be a way to push policies to the WTP to prioritize
mobile traffic.


62) IEEE 802.11 WLAN Config Request. why is a new message type that is
802.11 specific needed to modify 802.11 WLANs? It seems like the
existing "(8.4)Configuration Update Request" message could be used.

<PRC> To be more specific only.


63) note here there are information elements to create, delete, and
modify WLANs. However, for message type "(10.1)Mobile Config Request",
there is only add and delete (and the "add" used to modify).

<PRC> Correct. The protocol requires the AC to resend a new add with a
different policy. No specific reason, but if this is deemed
inconsistent, we could change it.


64) IEEE 802.11 Assigned WTP BSSID. The mapping of WLAN IDs to BSSIDs
seems like it needs a little more work

<PRC> What exactly would you like to see?


Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems



> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: Thursday, June 22, 2006 4:31 PM
> To: capwap@frascone.com
> Subject: [Capwap] A commentary on CAPWAP-01 operations
>
> HI,
>
> I've attached a long file that summarizes the operations in
> CAPWAP-01.
>
> 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

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

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


------=_Part_19052_9116103.1159565625042-- --===============1350211254== 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 --===============1350211254==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 29 17:48:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTQDv-0002uV-ST for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 17:48:47 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTQDr-00032u-I1 for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 17:48:47 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 63FAC144800D for ; Fri, 29 Sep 2006 14:48:39 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id DA114430059 for ; Fri, 29 Sep 2006 14:40:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id CAD5439803B for ; Fri, 29 Sep 2006 14:40:59 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by zoidberg.tigertech.net (Postfix) with ESMTP id 69EBE398043 for ; Fri, 29 Sep 2006 14:40:55 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so1086330nfb for ; Fri, 29 Sep 2006 14:40:54 -0700 (PDT) Received: by 10.49.91.6 with SMTP id t6mr5847265nfl; Fri, 29 Sep 2006 14:40:53 -0700 (PDT) Received: by 10.49.42.6 with HTTP; Fri, 29 Sep 2006 14:40:53 -0700 (PDT) Message-ID: <5bfe7a820609291440w4c386cd6jdc94e996513d380d@mail.gmail.com> Date: Fri, 29 Sep 2006 14:40:53 -0700 From: "Dorothy Stanley" To: "Michael Montemurro" MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.288 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_10_20, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: capwap@frascone.com Subject: [Capwap] Proposed Resolution to Issue 163 "WTP Descriptor information is not required at Join time" /was Re: A commentary on CAPWAP-01 operations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0623437111==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.9 (/) X-Scan-Signature: ad122f56a92d6ccd133117ee8a4b1ff3 --===============0623437111== Content-Type: multipart/alternative; boundary="----=_Part_19153_11458739.1159566053931" ------=_Part_19153_11458739.1159566053931 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, Issue 163 "WTP Descriptor information is not required at Join time" is listed below: *14) The WTP Descriptor information is not required at Join time. Well, as far as I can tell, I think there's value in knowing whether the WTP can even be supported by the AC. So the more info is provided by the WTP, the better the AC can determine whether it should just ignore the WTP or not. This could be done because it knows that the firmware running on the WTP is not compatible, and it has no new firmware to download.* ** The proposed resolution to Issue 163 is: Close with no change to the draft. The WTP descriptor element is included in the optional Discover Request message and the Join Request to indicate the WTP info to the AC. If the Discover Request is not sent, then the Join Request is the first message in which the AC receives this information. Comments welcome. Thanks, Dorothy On 6/30/06, Michael Montemurro wrote: > > David, Pat, > > I created issues 150-198 to deal with the points in David's email. Happy > hunting! > > Mike > > > On 6/27/06, Pat Calhoun (pacalhou) wrote: > > > > Going through David's lengthy document, he has raised an interesting > > number of points that I believe require issues to be created. At one > > point I'm paraphrasing Dave's comments in order to be brief, and > > introducing my own numbering scheme. > > > > 1) Can message elements be in any order? (I believe they should be) > > > > Yes, and I suspect we need to include text to make it more > > obvious. > > > > > > 2) Are all specified message elements required? (The obvious answer is > > "yes", but this document doesn't discuss versioning. For example, what > > if in a new version of CAPWAP an additional message element was to be > > added. Would a new message type be created and the additional message > > element added to it, or the existing type reused?) > > > > This is a great question, and one that does need to be addressed > > in the spec. In the Diameter protocol we dealt with this issue by > > including a "Mandatory to implement" bit. If any AVP was received, whose > > bit was set, yet was not recognized, then the request had to be > > rejected. > > > > We could consider something similar here, but I believe with the > > firmware download component of the protocol it may be less of an issue - > > although not guaranteed. I would hope (and expect) that as the CAPWAP > > protocol extends, the AC would push new firmware to the WTP. This does > > require that the initial part of the state machine be fairly static, and > > this could be an area where the "Mandatory to implement" bit could be > > useful as it would allow the AC to fall back to older protocol behavior. > > > > > > 3) CAPWAP-01 doesn't do a good job of indicating which message elements > > can be repeated. > > > > Another good point. When we list the message elements, we should > > note whether the frequently is 0-1 (meaning absent or once), 1 (only > > once) or 0+ (meaning any number of them could be present. > > > > > > 4) Can "additional" message elements be added to a message? (I believe > > so for reporting capabilities, statistics, and events. For > > configuration, there is nothing in the protocol that says what happens > > when one end gets an configuration element it doesn't know about. > > Should it be ignored, and the other elements processed, or should the > > complete operation failed?) > > > > The "Mandatory to implement" bit above could address this issue. > > If an unrecognized message element is found to have the bit set, then > > the whole message needs to be rejected. If the bit is not set, the > > message element may be safely ignored. > > > > > > 5) The config has a concept of "default value" for each configuration > > attribute. However, the default values are not clearly specified. This > > needs to be resolved to be able to support "default values". > > > > Another good point raised by David. > > > > > > 6) the documentation of which "binding specific" message elements are to > > be included with CAPWAP messages is not consistent, and is difficult to > > follow. > > > > Has this been addressed in the latest (-02) document? > > > > > > 7) There are some message elements that cause "actions". This approach > > to protocol design is problematic and should be eliminated. > > > > Could you be more specific as well as provide guidance on what you > > would like to see? > > > > > > 8) The message types are inconsistently named, and do not follow the > > conventions of well designed protocols. Can the operations be named > > consistently with the following terminology: > > 1) request/response (used to get/set/perform action) > > 2) report/ack (use to tell the other side something) > > > > Could you provide your thoughts on which messages fall within > > which one of your categories? > > > > > > 9) Many of the configuration items, and status items are not listed in > > one section with definitions. (Well make it two sections - one for > > CAPWAP and the other which is "binding" specific.) For example, not all > > of the time period lengths are identified and specified in section 4.5. > > > > Unfortunately, the document has gone back and forth a few times > > and before we opt to change the structure of the document, I'd like to > > ensure that we have broad agreement on what we want - with the > > understanding that we will never make everyone happy. > > > > > > 10) each operation should have listed in which states it can be sent and > > received > > > > I do not understand your comment. > > > > > > 11) All strings, such as WTP location, should be changed from US-ASCII > > encoding to UTF-8 encoding. > > > > Agreed. > > > > 12) The term "mobile" is not really accurate when describing wireless > > interfaces, since wireless does not imply mobile. Can we just use > > the techie term "STA" instead. > > > > I agree we should use the term Station, or STA for short. > > > > > > 13) The WTP Descriptor message element contains too much information, > > lacks clarity on the WTP encryption field and includes version numbers, > > which should be in string form. > > > > To the first point, I disagree. I think there is value in knowing > > everything about the WTP. The AC vendors can expose whatever information > > > > they want, but I don't believe anything is unnecessary. > > > > To the second point, this is one of those areas where the concept > > of the technology binding creates complexity. Given that we cannot > > simply discuss 802.11i at this point, the only thing we can do is punt > > to another section in the technology binding section. That said, I agree > > with Dave that the 802.11 binding section is too light in this area. > > However, I would much prefer that instead of trying to address this > > specific issue, we discuss whether we should even be supporting the mode > > of operation where 802.11i is performed in the AC - especially with the > > introduction of DTLS to secure the data plane. Right now, it just feels > > like we have too many options and I am worried that interoperability > > will be severely impacted (not to mention protocol complexity). > > > > To the last point, I have no issues with including text stating > > that the version numbers should be in string form. > > > > > > 14) The WTP Descriptor information is not required at Join time. > > > > Well, as far as I can tell, I think there's value in knowing > > whether the WTP can even be supported by the AC. So the more info is > > provided by the WTP, the better the AC can determine whether it should > > just ignore the WTP or not. This could be done because it knows that the > > firmware running on the WTP is not compatible, and it has no new > > firmware to download. > > > > > > 15) Are the values in the WTP Frame Encryption a capabilities bit, or an > > enum? > > > > Looks like an enum to me. Not sure what Dave would prefer the text > > to read. There are various other similar comments throughout, which I > > will not repeat here. > > > > > > 16) The Discovery Response is broken. The AC SHOULD NOT be providing any > > info to a WTP (or something that claims to be a WTP). Also, the AC > > should tell the WTP what to do next, with choices: 1) Ok to try to join, > > > > 2) don't try to join, 3) try discover on a list of > > returned ACs) > > > > I don't believe there is an issue with sending the AC's > > information to the WTP, but would solicit input from the list. That > > said, some of the information in the AC Descriptor is required, such as > > the current load on the AC. No point is trying to join if he AC > > indicates it's already at max capacity. > > I believe if the AC does not return the response, then it implies > > (2). Otherwise, it is (1). (3) is handled during the join or configure > > process, which I believe is right. > > > > > > 17) Is AC Name text? > > > > Yes, and same with WTP Name. > > > > > > 18) Primary Discovery are not required. > > > > Disagree. Required for failover. > > > > > > 19) The text does not make it clear that the contents of the WTP > > Location is informative only, and as Dave calls it, a "scratchpad". > > > > Well, to be honest, I thought the example "next to the fridge" > > made it clear that the information did not derive from any scientific > > formula. The description also states this is a user-defined. I believe > > this should be good enough. > > > > > > 20) Session is not required > > > > I believe you may be correct that with the transition to DTLS, > > this is no longer required. > > > > > > 21) need to send "common name" as found in the WTP CERT so that the AC > > can verify > > > > The protocol currently relies on the MAC address being the key > > that binds the certificate to the WTP. I don't see a need to change > > this. > > > > > > 22) Result code in Join Response is not sufficient, for instance WTP HW > > not supported. > > > > Well, the protocol does not require this because the Discovery > > Response would never be sent (as the protocol stands today). > > > > > > 23) AC IPv4/IPv6 Addr discusses clustering, which is unnecessary. > > > > Agreed. > > > > > > 24) Change Echo to Keepalive or heartbeat. > > > > I call it potato.... > > > > > > 25) What if all of the message elements do not fit within a single > > CAPWAP control frame. > > > > We should address this. > > > > > > 26) AC Name with Index is all messed up... > > > > Not really. You simply include more than one, and the index field > > is clearly the priority. Don't understand the Multi-AC comment. No > > inter-AC protocol implied here. > > > > > > 27) WTP Board Data belongs in the Join, not configure. > > > > Agreed, but wonder even more why we are duplicating this > > information across both the WTP Descriptor and the WTP Board Data > > message elements. > > > > > > 28) The WTP Static IPv4 Address should not have the Static bit, but > > instead state that 0.0.0.0 means a static address is not to be used. > > > > I don't have an issue with this request, but in the end we have > > the same function. The reason why I state this is that we can refine > > this protocol until the cows come home, and at one point we need to draw > > a line in the sand. > > > > > > 29) WTP Reboot Statistics belongs in the Join, and the reasons listed > > are not clear enough. > > > > Doesn't really matter whether this is included in the > > configuration or the join, but if the WG agrees to move it. We can > > clarify some of the reasons, as long as it provides value. > > > > > > 30) The IEEE 802.11 WTP Radio Configuration message element's BSSID > > field should be an array. > > > > Disagree. > > > > > > 30) The IEEE 802.11 WTP Radio Configuration message element's Country > > Code is not clear enough. > > > > The text points to the actual MIB element in the 802.11-1999 > > standard, which very clearly defines the contents of the field. I don't > > think there's value in replicating the format of this field in the > > CAPWAP standard. > > > > > > 31) There seems like an awful lot of additional configuration message > > elements that need to be specified here! > > > > Having built a protocol based on this, it's not clear to me what's > > > > missing. I think it would be useful if you provided concrete details on > > what's missing. > > > > > > 32) Configuration Status is just plain broken because any configuration > > change operation may fail and there is no response to the > > configuration changes specified in this command. > > > > There certainly is - I guess I don't understand the concern. > > > > > > 33) Use of Change State Event should instead be Radio Admin State. > > > > Perhaps the two are not described properly. The first is used by > > the WTP to inform the AC that something has occurred with a radio. The > > second is used by the AC to enable/disable a radio. > > > > > > 34) Report Timer needs to be in section 4.5 or 11 > > > > ok > > > > > > 35) Should Idle Timeout be per radio, or per WTP, and should the value > > be defined in section 4.5 or 11. > > > > Per WTP, and yes. I believe it is fine as it is. > > > > > > 36) WTP Fallback isn't well defined, and should be removed. > > > > Disagree. I believe it is necessary to create enough resiliency in > > the protocol/service. > > > > > > 37) How are the "Rate Set" and "Supported Rates" encoded. > > > > This was fixed in the -02 > > > > > > 38) AC Timestamp doesn't belong in the configuration, but instead in the > > join. > > > > Not sure this really matters.... > > > > > > 39) Add MAC ACL Entry - this is so strange and is being managed like no > > other configuration data. > > > > I do not understand the comment > > > > > > 40) Decryption Error Report Period is not defined in section 4.5 or 11 > > > > ok, and note that the information has been moved to the IEEE > > 802.11 RSNA Error Report From Mobile > > > > > > 41) Configuration Update Response. today, there are primarily two types > > of configuration models. The first is when config is changed, it is only > > changed in the volatile copy (the memory or running). An explicit > > command is needed to save the config to nonvolatile storage. The second > > model has config both running (volatile) and saved (nonvolatile) config > > changed when a config change is made. And there might be a special > > command to have a config change apply to only one. In this case, there > > is no need for a "save config to nonvolatile" command. It is not clear > > what is suppose to be supported here in CAPWAP, and how does CAPWAP > > support devices with no or very limited nonvolatile storage for config! > > > > CAPWAP does not support WTPs with no nonvolatile storage. The > > protocol has the AC push configs to the WTP, which saves them at the > > time they are received. I do not believe anything else is required. > > > > > > 42) Configuration Update Response includes the Result Code message > > element, which includes values that do not appear to be relevant for > > this message, and there are plenty of other failure cases > > > > ok, but note that we are sharing a common message element. Any > > suggestions on how to address your issue? > > > > > > 43) Change State Event Report. This seems a little silly to be sent in > > the "configure" state. It seems only appropriate for the "run" state. > > Some might argue that even in the "run" state it shouldn't be sent after > > a "config update" request that changes the operational state. However, > > in the "run" state, it may take a while to have the operational state > > change to follow the admin state. Thus, I think it is OK in the "run" > > state after config changes." > > > > I believe this was addressed in -02. > > > > > > 44) Clear Config Request. this operation has several problems, which > > include: > > 1) currently, the CAPWAP-01 spec says that this can only be done in > > the "run" state. This is silly. It should also be possible in the > > "configure" state. > > I wonder why the AC would even consider clearing the WTP's state > > before it even knows how it is configured. > > > > 2) the value of "manufacturing defaults" is not defined, and a poor > > term to use, since it implies that that each manufacturer can have > > different values. If so, then the AC will have no knowledge of the > > config on the WTP! The problem of "default config values" has already be > > > > mentioned above. After each config attribute has been defined with a > > default value, then the proper term would be "CAPWAP config defaults". > > Yes, you've raised this point already, and I agree that it does > > need to be addressed. > > > > 3) This operation is not defined to have a response. This is broken, > > since any config change can fail. Also, it is not defined what happens > > next. Does this cause the WTP to reboot an start a "clean discovery"? > > This was addressed in -02 > > > > > > 45) Image Data Request. Yes, there are actually three different "Image > > Data Request" messages. Which one is determined by which of the > > three message elements is contained. This is completely silly! There > > should be three separate operations! Additionally, how does the WTP know > > which image to get? The AC should be making that decision. > > > > I believe the WTP is the only device that knows what it's filename > > > > should be. Why would an AC vendor know about file naming conventions > > used by the WTP vendors? I believe your other issues are discussed in > > the next items. > > > > > > 46) Image Data Response. this is silly. This operation can fail! There > > needs to be message element that indicates the result. > > > > How so? This is only used to send firmware to the WTP. Not clear > > what could fail... Reading the image from flash? > > > > > > 47) Image Data Request. when starting over again at the WTP start state, > > > > the WTP shouldn't use the "normal" discovery process, but instead "fast > > track" a connection back to the AC that just downloaded the image. With > > a little more work, we could probably figure out a way to reuse > > > > the old DTLS session. > > > > To what gain? What is so expensive about the discovery, and what > > happened if the AC was not longer reachable? > > > > > > 48) opcode - if this is here, might as well also have a value that > > indicates last block of the image file, instead of looking at the block > > size. > > > > But we're just changing for the sake of changing - the protocol > > works as-is. > > > > > > 49) since this operation does not have the block number as a parameter, > > the WTP must determine the block number via the CAPWAP message header > > sequence number. NOTE: DTLS does not provide in-order delivery of > > packets. Also, this requires the WTP to remember state. This message > > element should be re-engineered to have the following subfields: > > [edited] > > > > The control header includes a sequence number, and while we can > > change the current protocol to match your recommendations, the protocol > > does work. If it ain't broken... > > > > > > 50) Image Data Response. this is silly. This operation can fail! For > > example, the WTP can run out of space to store the block, or > > there could be a failure in writing the block to storage. (Or as "Image > > Data Request"(9.1a) is presently specified, the checksum match could > > fail.) There needs to be message element that indicates the result.) > > Note: don't need a block number field, since request and responses are > > paired. > > > > We can include a result code > > > > > > 51) Image Data Request. silly beyond belief > > > > Beauty is in the eye of the beholder ;-). Seriously, the protocol > > does work, so what exactly are you looking for? > > > > > > 52) Image Data Response. This is silly. This operation can fail! There > > needs to be message element that indicates the result. > > > > See above comment. > > > > 53) Reset Request. ... > > > > The comment is irrelevant now that Clear Config has changed. > > > > > > 54) Reset Response. this is silly. This operation can fail! There needs > > to be message element that indicates the result. > > > > I sense a trend. I will stop including these messages from now on. > > > > > > 55)Duplicate IPv4 Address. how often is this reported if the condition > > remains? > > > > Only required once, I think, but we may want to include some text > > covering that. > > > > > > 56) the list of events seems understated! > > > > Text and conditions please > > > > > > 57) Data Transfer Request. Nice to have - remove. > > > > Disagree. Providing diagnostics capabilities is required. > > > > > > 58) Mobile Config Request. the actual details of how this works on both > > splitMAC and especially localMAC are not well specified. That is, only > > the figures and text in sections 11.1.1 and 11.1.2 provide any clue as > > to events that would cause an AC to send this message type. Also, there > > are restrictions on combinations of parameters that can be included in > > the message. > > > > I wonder whether other folks agree that more details are required. > > > > > > 59) it doesn't say if one message can be used to update more than one > > STA. It should be able. > > > > No, otherwise you end up with the problem of associating specific > > message elements with a given mobile. One mobile per request. > > > > > > 60) IEEE 802.11 Mobile. shouldn't the STA MAC address be included so > > this message element can be matched with a (4.4.8)Add Mobile message > > element? > > > > I believe this is to your previous point, but the protocol assumes > > one mobile per request. > > > > > > 61) IEEE 802.11 Update Mobile QoS. s this for data traffic to the AC? If > > so, then why is this an 802.11 message element > > > > Intended to be a way to push policies to the WTP to prioritize > > mobile traffic. > > > > > > 62) IEEE 802.11 WLAN Config Request. why is a new message type that is > > 802.11 specific needed to modify 802.11 WLANs? It seems like the > > existing "(8.4)Configuration Update Request" message could be used. > > > > To be more specific only. > > > > > > 63) note here there are information elements to create, delete, and > > modify WLANs. However, for message type "(10.1)Mobile Config Request", > > there is only add and delete (and the "add" used to modify). > > > > Correct. The protocol requires the AC to resend a new add with a > > different policy. No specific reason, but if this is deemed > > inconsistent, we could change it. > > > > > > 64) IEEE 802.11 Assigned WTP BSSID. The mapping of WLAN IDs to BSSIDs > > seems like it needs a little more work > > > > What exactly would you like to see? > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > -----Original Message----- > > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > > Sent: Thursday, June 22, 2006 4:31 PM > > > To: capwap@frascone.com > > > Subject: [Capwap] A commentary on CAPWAP-01 operations > > > > > > HI, > > > > > > I've attached a long file that summarizes the operations in > > > CAPWAP-01. > > > > > > 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 > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_19153_11458739.1159566053931 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
All,
 
Issue 163 "WTP Descriptor information is not required at Join time"  is listed below:

14) The WTP Descriptor information is not required at Join time.

<PRC> Well, as far as I can tell, I think there's value in knowing
whether the WTP can even be supported by the AC. So the more info is
provided by the WTP, the better the AC can determine whether it should
just ignore the WTP or not. This could be done because it knows that the
firmware running on the WTP is not compatible, and it has no new
firmware to download.
 
The proposed resolution to Issue 163 is:
 
Close with no change to the draft. The WTP descriptor element is included
in the optional Discover Request message and the Join Request to
indicate the WTP info to the AC. If the Discover Request is not sent, then
the Join Request is the first message in which the AC receives this information.
 
Comments welcome.
 
Thanks,
 
Dorothy
 
On 6/30/06, Michael Montemurro <montemurro.michael@gmail.com> wrote:
David, Pat,
 
I created issues 150-198 to deal with the points in David's email. Happy hunting!
 
Mike

 
On 6/27/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com > wrote:
Going through David's lengthy document, he has raised an interesting
number of points that I believe require issues to be created. At one
point I'm paraphrasing Dave's comments in order to be brief, and
introducing my own numbering scheme.

1) Can message elements be in any order? (I believe they should be)

<PRC> Yes, and I suspect we need to include text to make it more
obvious.


2) Are all specified message elements required? (The obvious answer is
"yes", but this document doesn't discuss versioning. For example, what
if in a new version of CAPWAP an additional message element was to be
added. Would a new message type be created and the additional message
element added to it, or the existing type reused?)

<PRC> This is a great question, and one that does need to be addressed
in the spec. In the Diameter protocol we dealt with this issue by
including a "Mandatory to implement" bit. If any AVP was received, whose
bit was set, yet was not recognized, then the request had to be
rejected.

<PRC> We could consider something similar here, but I believe with the
firmware download component of the protocol it may be less of an issue -
although not guaranteed. I would hope (and expect) that as the CAPWAP
protocol extends, the AC would push new firmware to the WTP. This does
require that the initial part of the state machine be fairly static, and
this could be an area where the "Mandatory to implement" bit could be
useful as it would allow the AC to fall back to older protocol behavior.

3) CAPWAP-01 doesn't do a good job of indicating which message elements
can be repeated.

<PRC> Another good point. When we list the message elements, we should
note whether the frequently is 0-1 (meaning absent or once), 1 (only
once) or 0+ (meaning any number of them could be present.


4) Can "additional" message elements be added to a message? (I believe
so for reporting capabilities, statistics, and     events. For
configuration, there is nothing in the protocol that says what happens
when one end gets an configuration     element it doesn't know about.
Should it be ignored, and the other elements processed, or should the
complete operation     failed?)

<PRC> The "Mandatory to implement" bit above could address this issue.
If an unrecognized message element is found to have the bit set, then
the whole message needs to be rejected. If the bit is not set, the
message element may be safely ignored.


5) The config has a concept of "default value" for each configuration
attribute. However, the default values are not clearly specified. This
needs to be resolved to be able to support "default values".

<PRC> Another good point raised by David.


6) the documentation of which "binding specific" message elements are to
be included with CAPWAP messages is not consistent, and is difficult to
follow.

<PRC> Has this been addressed in the latest (-02) document?


7) There are some message elements that cause "actions". This approach
to protocol design is problematic and should be eliminated.

<PRC> Could you be more specific as well as provide guidance on what you
would like to see?


8) The message types are inconsistently named, and do not follow the
conventions of well designed protocols. Can the operations be named
consistently with the following terminology:
  1) request/response (used to get/set/perform action)
  2) report/ack (use to tell the other side something)

<PRC> Could you provide your thoughts on which messages fall within
which one of your categories?


9) Many of the configuration items, and status items are not listed in
one section with definitions. (Well make it two sections - one for
CAPWAP and the other which is "binding" specific.) For example, not all
of the time period lengths are identified and specified in section 4.5.

<PRC> Unfortunately, the document has gone back and forth a few times
and before we opt to change the structure of the document, I'd like to
ensure that we have broad agreement on what we want - with the
understanding that we will never make everyone happy.


10) each operation should have listed in which states it can be sent and
received

<PRC> I do not understand your comment.


11) All strings, such as WTP location, should be changed from US-ASCII
encoding to UTF-8 encoding.

<PRC> Agreed.

12) The term "mobile" is not really accurate when describing wireless
interfaces, since wireless does not imply      mobile. Can we just use
the techie term "STA" instead.

<PRC> I agree we should use the term Station, or STA for short.


13) The WTP Descriptor message element contains too much information,
lacks clarity on the WTP encryption field and includes version numbers,
which should be in string form.

<PRC> To the first point, I disagree. I think there is value in knowing
everything about the WTP. The AC vendors can expose whatever information
they want, but I don't believe anything is unnecessary.

<PRC> To the second point, this is one of those areas where the concept
of the technology binding creates complexity. Given that we cannot
simply discuss 802.11i at this point, the only thing we can do is punt
to another section in the technology binding section. That said, I agree
with Dave that the 802.11 binding section is too light in this area.
However, I would much prefer that instead of trying to address this
specific issue, we discuss whether we should even be supporting the mode
of operation where 802.11i is performed in the AC - especially with the
introduction of DTLS to secure the data plane. Right now, it just feels
like we have too many options and I am worried that interoperability
will be severely impacted (not to mention protocol complexity).

<PRC> To the last point, I have no issues with including text stating
that the version numbers should be in string form.


14) The WTP Descriptor information is not required at Join time.

<PRC> Well, as far as I can tell, I think there's value in knowing
whether the WTP can even be supported by the AC. So the more info is
provided by the WTP, the better the AC can determine whether it should
just ignore the WTP or not. This could be done because it knows that the
firmware running on the WTP is not compatible, and it has no new
firmware to download.


15) Are the values in the WTP Frame Encryption a capabilities bit, or an
enum?

<PRC> Looks like an enum to me. Not sure what Dave would prefer the text
to read. There are various other similar comments throughout, which I
will not repeat here.


16) The Discovery Response is broken. The AC SHOULD NOT be providing any
info to a WTP (or something that claims to be a WTP). Also, the AC
should tell the WTP what to do next, with choices: 1) Ok to try to join,
2) don't try to join, 3) try                     discover on a list of
returned ACs)

<PRC> I don't believe there is an issue with sending the AC's
information to the WTP, but would solicit input from the list. That
said, some of the information in the AC Descriptor is required, such as
the current load on the AC. No point is trying to join if he AC
indicates it's already at max capacity.
<PRC> I believe if the AC does not return the response, then it implies
(2). Otherwise, it is (1). (3) is handled during the join or configure
process, which I believe is right.


17) Is AC Name text?

<PRC> Yes, and same with WTP Name.


18) Primary Discovery are not required.

<PRC> Disagree. Required for failover.


19) The text does not make it clear that the contents of the WTP
Location is informative only, and as Dave calls it, a "scratchpad".

<PRC> Well, to be honest, I thought the example "next to the fridge"
made it clear that the information did not derive from any scientific
formula. The description also states this is a user-defined. I believe
this should be good enough.


20) Session is not required

<PRC> I believe you may be correct that with the transition to DTLS,
this is no longer required.


21) need to send "common name" as found in the WTP CERT so that the AC
can verify

<PRC> The protocol currently relies on the MAC address being the key
that binds the certificate to the WTP. I don't see a need to change
this.


22) Result code in Join Response is not sufficient, for instance WTP HW
not supported.

<PRC> Well, the protocol does not require this because the Discovery
Response would never be sent (as the protocol stands today).


23) AC IPv4/IPv6 Addr discusses clustering, which is unnecessary.

<PRC> Agreed.


24) Change Echo to Keepalive or heartbeat.

<PRC> I call it potato....


25) What if all of the message elements do not fit within a single
CAPWAP control frame.

<PRC> We should address this.


26) AC Name with Index is all messed up...

<PRC> Not really. You simply include more than one, and the index field
is clearly the priority. Don't understand the Multi-AC comment. No
inter-AC protocol implied here.


27) WTP Board Data belongs in the Join, not configure.

<PRC> Agreed, but wonder even more why we are duplicating this
information across both the WTP Descriptor and the WTP Board Data
message elements.


28) The WTP Static IPv4 Address should not have the Static bit, but
instead state that 0.0.0.0 means a static address is not to be used.

<PRC> I don't have an issue with this request, but in the end we have
the same function. The reason why I state this is that we can refine
this protocol until the cows come home, and at one point we need to draw
a line in the sand.


29) WTP Reboot Statistics belongs in the Join, and the reasons listed
are not clear enough.

<PRC> Doesn't really matter whether this is included in the
configuration or the join, but if the WG agrees to move it. We can
clarify some of the reasons, as long as it provides value.


30) The IEEE 802.11 WTP Radio Configuration message element's BSSID
field should be an array.

<PRC> Disagree.


30) The IEEE 802.11 WTP Radio Configuration message element's Country
Code is not clear enough.

<PRC> The text points to the actual MIB element in the 802.11-1999
standard, which very clearly defines the contents of the field. I don't
think there's value in replicating the format of this field in the
CAPWAP standard.


31) There seems like an awful lot of additional configuration message
elements that need to be specified here!

<PRC> Having built a protocol based on this, it's not clear to me what's
missing. I think it would be useful if you provided concrete details on
what's missing.


32) Configuration Status is just plain broken because any configuration
change operation may fail and there is no           response to the
configuration changes specified in this command.

<PRC> There certainly is - I guess I don't understand the concern.


33) Use of Change State Event should instead be Radio Admin State.

<PRC> Perhaps the two are not described properly. The first is used by
the WTP to inform the AC that something has occurred with a radio. The
second is used by the AC to enable/disable a radio.


34) Report Timer needs to be in section 4.5 or 11

<PRC> ok


35) Should Idle Timeout be per radio, or per WTP, and should the value
be defined in section 4.5 or 11.

<PRC> Per WTP, and yes. I believe it is fine as it is.


36) WTP Fallback isn't well defined, and should be removed.

<PRC> Disagree. I believe it is necessary to create enough resiliency in
the protocol/service.


37) How are the "Rate Set" and "Supported Rates" encoded.

<PRC> This was fixed in the -02


38) AC Timestamp doesn't belong in the configuration, but instead in the
join.

<PRC> Not sure this really matters....


39) Add MAC ACL Entry - this is so strange and is being managed like no
other configuration data.

<PRC> I do not understand the comment


40) Decryption Error Report Period is not defined in section 4.5 or 11

<PRC> ok, and note that the information has been moved to the IEEE
802.11 RSNA Error Report From Mobile


41) Configuration Update Response. today, there are primarily two types
of configuration models. The first is when config is changed, it is only
changed in the volatile copy (the memory or running). An explicit
command is needed to save the config to nonvolatile storage. The second
model has config both running (volatile) and saved (nonvolatile) config
changed when a config change is made. And there might be a special
command to have a config change apply to only one. In this case, there
is no need for a "save config to nonvolatile" command. It is not clear
what is suppose to be supported here in CAPWAP, and how does CAPWAP
support devices with no or very limited nonvolatile storage for config!

<PRC> CAPWAP does not support WTPs with no nonvolatile storage. The
protocol has the AC push configs to the WTP, which saves them at the
time they are received. I do not believe anything else is required.


42) Configuration Update Response includes the Result Code message
element, which includes values that do not appear to be relevant for
this message, and there are plenty of other failure cases

<PRC> ok, but note that we are sharing a common message element. Any
suggestions on how to address your issue?


43) Change State Event Report. This seems a little silly to be sent in
the "configure" state. It seems only appropriate for the "run" state.
Some might argue that even in the "run" state it shouldn't be sent after
a "config update" request that changes the operational state. However,
in the "run" state, it may take a while to have the operational state
change to follow the admin state. Thus, I think it is OK in the "run"
state after config changes."

<PRC> I believe this was addressed in -02.


44) Clear Config Request. this operation has several problems, which
include:
   1) currently, the CAPWAP-01 spec says that this can only be done in
the "run" state. This is silly. It should also be possible in the
"configure" state.
<PRC> I wonder why the AC would even consider clearing the WTP's state
before it even knows how it is configured.

   2) the value of "manufacturing defaults" is not defined, and a poor
term to use, since it implies that that each manufacturer can have
different values. If so, then the AC will have no knowledge of the
config on the WTP! The problem of "default config values" has already be
mentioned above. After each config attribute has been defined with a
default value, then the proper term would be "CAPWAP config defaults".
<PRC> Yes, you've raised this point already, and I agree that it does
need to be addressed.

   3) This operation is not defined to have a response. This is broken,
since any config change can fail. Also, it is not defined what happens
next. Does this cause the WTP to reboot an start a "clean discovery"?
<PRC> This was addressed in -02


45) Image Data Request. Yes, there are actually three different "Image
Data Request" messages. Which one is determined          by which of the
three message elements is contained. This is completely silly! There
should be three separate operations! Additionally, how does the WTP know
which image to get? The AC should be making that decision.

<PRC> I believe the WTP is the only device that knows what it's filename
should be. Why would an AC vendor know about file naming conventions
used by the WTP vendors? I believe your other issues are discussed in
the next items.


46) Image Data Response. this is silly. This operation can fail! There
needs to be message element that indicates the          result.

<PRC> How so? This is only used to send firmware to the WTP. Not clear
what could fail... Reading the image from flash?


47) Image Data Request. when starting over again at the WTP start state,
the WTP shouldn't use the "normal" discovery process, but instead "fast
track" a connection back to the AC that just downloaded the image. With
a little more          work, we could probably figure out a way to reuse
the old DTLS session.

<PRC> To what gain? What is so expensive about the discovery, and what
happened if the AC was not longer reachable?


48) opcode - if this is here, might as well also have a value that
indicates last block of the image file, instead of looking at the block
size.

<PRC> But we're just changing for the sake of changing - the protocol
works as-is.


49) since this operation does not have the block number as a parameter,
the WTP must determine the block number via the CAPWAP message header
sequence number.  NOTE: DTLS does not provide in-order delivery of
packets. Also, this requires the WTP to remember state. This message
element should be re-engineered to have the following subfields:
[edited]

<PRC> The control header includes a sequence number, and while we can
change the current protocol to match your recommendations, the protocol
does work. If it ain't broken...


50) Image Data Response. this is silly. This operation can fail!  For
example, the WTP can run out of space to store          the block, or
there could be a failure in writing the block to storage. (Or as "Image
Data Request"(9.1a) is presently specified, the checksum match could
fail.) There needs to be message element that indicates the result.)
Note: don't need a block number field, since request and responses are
paired.

<PRC> We can include a result code


51) Image Data Request. silly beyond belief

<PRC> Beauty is in the eye of the beholder ;-). Seriously, the protocol
does work, so what exactly are you looking for?


52) Image Data Response. This is silly. This operation can fail! There
needs to be message element that indicates the          result.

<PRC> See above comment.

53) Reset Request. ...

<PRC> The comment is irrelevant now that Clear Config has changed.


54) Reset Response. this is silly. This operation can fail! There needs
to be message element that indicates the          result.

<PRC> I sense a trend. I will stop including these messages from now on.


55)Duplicate IPv4 Address. how often is this reported if the condition
remains?

<PRC> Only required once, I think, but we may want to include some text
covering that.


56) the list of events seems understated!

<PRC> Text and conditions please


57) Data Transfer Request. Nice to have - remove.

<PRC> Disagree. Providing diagnostics capabilities is required.


58) Mobile Config Request. the actual details of how this works on both
splitMAC and especially localMAC are not well specified. That is, only
the figures and text in sections 11.1.1 and 11.1.2 provide any clue as
to events that would cause an AC to send this message type. Also, there
are restrictions on combinations of parameters that can be included in
the message.

<PRC> I wonder whether other folks agree that more details are required.


59) it doesn't say if one message can be used to update more than one
STA. It should be able.

<PRC> No, otherwise you end up with the problem of associating specific
message elements with a given mobile. One mobile per request.


60) IEEE 802.11 Mobile. shouldn't the STA MAC address be included so
this message element can be matched with a (4.4.8)Add Mobile message
element?

<PRC> I believe this is to your previous point, but the protocol assumes
one mobile per request.


61) IEEE 802.11 Update Mobile QoS. s this for data traffic to the AC? If
so, then why is this an 802.11 message element

<PRC> Intended to be a way to push policies to the WTP to prioritize
mobile traffic.


62) IEEE 802.11 WLAN Config Request. why is a new message type that is
802.11 specific needed to modify 802.11 WLANs? It seems like the
existing "(8.4)Configuration Update Request" message could be used.

<PRC> To be more specific only.


63) note here there are information elements to create, delete, and
modify WLANs. However, for message type "(10.1)Mobile Config Request",
there is only add and delete (and the "add" used to modify).

<PRC> Correct. The protocol requires the AC to resend a new add with a
different policy. No specific reason, but if this is deemed
inconsistent, we could change it.


64) IEEE 802.11 Assigned WTP BSSID. The mapping of WLAN IDs to BSSIDs
seems like it needs a little more work

<PRC> What exactly would you like to see?


Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems



> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: Thursday, June 22, 2006 4:31 PM
> To: capwap@frascone.com
> Subject: [Capwap] A commentary on CAPWAP-01 operations
>
> HI,
>
> I've attached a long file that summarizes the operations in
> CAPWAP-01.
>
> 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

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

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


------=_Part_19153_11458739.1159566053931-- --===============0623437111== 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 --===============0623437111==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 29 17:57:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTQMg-0008GE-1C for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 17:57:50 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTQMc-0005IV-QZ for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 17:57:50 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 6C7051448050 for ; Fri, 29 Sep 2006 14:57:42 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id CAF53430059 for ; Fri, 29 Sep 2006 14:53:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B1FBD144800D for ; Fri, 29 Sep 2006 14:53:01 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by hermes.tigertech.net (Postfix) with ESMTP id 21C81144800F for ; Fri, 29 Sep 2006 14:52:58 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so1088252nfb for ; Fri, 29 Sep 2006 14:52:58 -0700 (PDT) Received: by 10.49.8.15 with SMTP id l15mr2261827nfi; Fri, 29 Sep 2006 14:52:58 -0700 (PDT) Received: by 10.49.42.6 with HTTP; Fri, 29 Sep 2006 14:52:58 -0700 (PDT) Message-ID: <5bfe7a820609291452m53ca6a8aw3187b688df330232@mail.gmail.com> Date: Fri, 29 Sep 2006 14:52:58 -0700 From: "Dorothy Stanley" To: "Michael Montemurro" 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.0 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_50_60, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: Behcet Sarikaya , capwap@frascone.com Subject: [Capwap] Proposed Resolution to Issue 145 "Need additional detail for how a STA session is created" /was:Re: Packet flows for new STA session X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1826777634==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd --===============1826777634== Content-Type: multipart/alternative; boundary="----=_Part_19281_7932036.1159566778078" ------=_Part_19281_7932036.1159566778078 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, Issue 145 is listed below: *There is a lot of detail missing in CAPWAP describing how a STA session is created for both splitMAC and localMAC. It would be quite useful if someone would take figures 5 and 7 and add the detail.* The proposed resolution to Issue 145 is: Close with no change to the text. Figures 5 and 7 are intended to provide an illustration of the division of labor in the local and split-MAC cases, rather than a comprehensive description of session establishment. The lists of message elements are included in the text. Comments welcome, Thanks, Dorothy On 6/30/06, Michael Montemurro wrote: > > David, > > I created issue number 145 to track this issue. > > Cheers, > > Mike > > > On 6/23/06, Behcet Sarikaya wrote: > > > > Hi David, > > Roaming with key caching and other new developments is a work item for > > possible rechartering. I think the present text is OK. > > > > Regards, > > > > > > --behcet > > > > > > ----- Original Message ---- > > From: David T. Perkins < dperkins@dsperkins.com> > > To: capwap@frascone.com > > Sent: Friday, June 23, 2006 1:16:46 PM > > Subject: [Capwap] Packet flows for new STA session > > > > HI, > > > > There is a lot of detail missing in CAPWAP describing > > how a STA session is created for both splitMAC and > > localMAC. It would be quite useful if someone would > > take figures 5 and 7 and add the detail. > > > > 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 > > > > > > > > _________________________________________________________________ > > 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_19281_7932036.1159566778078 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
All,
 
Issue 145  is listed below:
There is a lot of detail missing in CAPWAP describing
how a STA session is created for both splitMAC and
localMAC. It would be quite useful if someone would
take figures 5 and 7 and add the detail.
The proposed resolution to Issue 145 is:
Close with no change to the text. Figures 5 and 7 are
intended to provide an illustration of the division of

labor in the local and split-MAC cases, rather than
a comprehensive description of session establishment.
The lists of message elements are included in the text.
Comments welcome,
Thanks,
Dorothy
On 6/30/06, Michael Montemurro <montemurro.michael@gmail.com> wrote:
David,
 
I created issue number 145 to track this issue.
 
Cheers,
 
Mike

 
On 6/23/06, Behcet Sarikaya <behcetsarikaya@yahoo.com > wrote:
Hi David,
  Roaming with key caching and other new developments is a work item for possible rechartering. I think the present text is OK.

Regards,
 

--behcet


----- Original Message ----
From: David T. Perkins < dperkins@dsperkins.com>
To: capwap@frascone.com
Sent: Friday, June 23, 2006 1:16:46 PM
Subject: [Capwap] Packet flows for new STA session

HI,

There is a lot of detail missing in CAPWAP describing
how a STA session is created for both splitMAC and
localMAC. It would be quite useful if someone would
take figures 5 and 7 and add the detail.

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
 


_________________________________________________________________
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_19281_7932036.1159566778078-- --===============1826777634== 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 --===============1826777634==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Sep 29 21:20:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTTWc-0007Af-Gm for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 21:20:18 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTTWW-0002no-9o for capwap-archive@lists.ietf.org; Fri, 29 Sep 2006 21:20:18 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4D30E398031 for ; Fri, 29 Sep 2006 18:19:59 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B8E18430059 for ; Fri, 29 Sep 2006 18:16:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A4C03398031 for ; Fri, 29 Sep 2006 18:16:53 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id F20AC39801D for ; Fri, 29 Sep 2006 18:16:48 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id k8U1GUBo011217; Sat, 30 Sep 2006 10:16:30 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k8U1GUQ20128; Sat, 30 Sep 2006 10:16:30 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with SMTP id k8U1GTl03033; Sat, 30 Sep 2006 10:16:29 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 30 Sep 2006 09:15:18 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F21A4@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbjOwaBxAxmTegASwKjGKmQD0OreAAB7o8QAAZYQgAAILorcAATiGkA From: "Saravanan Govindan" To: "Bob O'Hara (boohara)" , "Cheng Hong" , "Dorothy Stanley" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: fc33afc280b74ce7916a8c9e6ab57db8 Bringing in the government to deviate from technical discussion is not prod= uctive. = I still do not understand why a protocol standard should specify parameter = values. We should consider other options for this. Saravanan ________________________________________ From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] = Sent: Saturday, September 30, 2006 12:10 AM To: Cheng Hong; Dorothy Stanley Cc: Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); ca= pwap@frascone.com; Saravanan Govindan Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations I am afraid that requesting design assistance from a competitor is very clo= se to violation of U.S anti-trust laws.=A0 I will not describe how Cisco ha= s designed any of its products and I cannot help you design yours. =A0 Again, your proposal does not eliminate any attack mechanism and does not a= dd any functionality to the protocol, only cost and complexity.=A0 A replay= ed frame will be discarded by the MAC, using the normal duplicate frame det= ection mechanisms.=A0 See section 8.3.3.3.2 of 802.11i (where the frame seq= uence number is part of the additional authenticated data) and section 9.2.= 9 of 802.11-1999=A0for the description of these functions.=A0 And PLEASE re= ad 802.11 and 802.11i before again asserting that this proposal is necessar= y. =A0 As I said several emails ago, the ONLY effect of using zero as the value fo= r the KeyRSC is that the 802.11 chipset in the STA (client) will have to re= ceive the frame, attempt to decrypt it, and validate the MIC.=A0 This must = be done for EVERY frame received, whether it is a replayed frame or not.=A0= This set of functions is performed in the 802.11 STA chipset and does not = consume any additional resources of the STA.=A0 So, the attack, if it can e= ven be characterized as an attack, is no more effective at DOSing the STA t= han sending it any other frame. =A0-Bob =A0 = =A0 ________________________________________ From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] = Sent: Thursday, September 28, 2006 5:34 PM To: Bob O'Hara (boohara); Dorothy Stanley Cc: Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); ca= pwap@frascone.com; Saravanan Govindan Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi Bob, =A0 As Dorothy correctly pointed out below, setting the KeyRSC to a value close= r to the current RSC would be better than setting it to a pre-defined value= zero. = =A0 It is true that 802.11i and 802.1X do not specify what is the KeyRSC value = to be used, since they are trying to provide us a tool to correctly synchro= nize the RSC using the Msg 3. By mandating the KeyRSC to zero, we are just = disabling the tool. It is not wrong, but just deprives the system a designe= d function. =A0 As for the effectiveness of KeyRSC, setting it to a predefined value of 0 w= ould pose a greater threat. In a simple example, if the RSC is currently 10= 00, and we are mandating the KeyRSC to be always=A0zero, the attacker basic= ally can safely replay the last 1000 packets to the STA without being detec= ted.=A0If the KeyRSC can be set to a closer value of the current RSC, say, = 900, the number of possible=A0replayed packets can be reduced to 10 percent= , 100 packets. = =A0 Therefore, I would say, setting the KeyRSC value to zero does place a bigge= r threat. Is that how the cisco products implemented? Maybe you could share= with us some other implementation/testing data to prove otherwise. Or, you= have some other considerations that could defend the replay attack? =A0 cheers =A0 Cheng Hong =A0 ________________________________________ From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] = Sent: Friday, September 29, 2006 5:21 AM To: Dorothy Stanley Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J = (LI/EAB); capwap@frascone.com Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations Dorothy, =A0 The problem with this proposal is that it is no more effective than sending= a value of zero for the KeyRSC.=A0=A0It doesn't eliminate any potential at= tacks.=A0 It doesn't add any functionality.=A0=A0However, it does=A0add cos= t and complexity to the protocol.=A0 = =A0-Bob =A0 = =A0 ________________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com] = Sent: Thursday, September 28, 2006 1:17 PM To: Bob O'Hara (boohara) Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J = (LI/EAB); capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations All, Below is the text from 802.11REV-maD8.0 Clause 8.5.2, describing the Key RS= C field.: "g) Key RSC. This field is 8 octets in length. It contains the receive sequ= ence counter (RSC) for the GTK being installed in IEEE 802.11. It is used in Message 3 of the 4-Way Ha= ndshake and Message 1 of the Group Key Handshake, where it is used to synchronize the I= EEE 802.11 replay state. It may also be used in the Michael MIC Failure Report frame, to repo= rt the TSC field value of the frame experiencing a MIC failure. It shall contain 0 in other messages.= The Key RSC field gives the current message number for the GTK, to allow a STA to identify replayed= MPDUs. If the Key RSC field value is less than 8 octets in length, the remaining octets shall= be set to 0. The least significant octet of the TSC or PN should be in the first octet of the Key RSC field." The intent of adding this value in message 3 was to immediately minimize th= e number of = replayed frames that a STA would potentially process: "The Key RSC field gi= ves the current message number for the GTK, to allow a STA to identify replayed= MPDUs." Setting the value to 0 in Msg 3 does not provide the current sequence count= er (in most cases not even close) of the GTK.. Perhaps the WTP could periodically/frequently notify the AC of its current = GTK sequence counter, and the AC would use the most recently received value in the message 3 sent to new = STAs. The RSC value would not be=A0 up to date at all times, but would be closer than "0", not = require an "in-the-critical-path message exchange between the AC and WTP, and still be close to the intended= use of the field. Dorothy On 9/28/06, Bob O'Hara (boohara) wrote: = Please understand that 802.11i specifies no behavior in this area for the 802.1X authenticator.=A0=A0Our choice to send a group key KeyRSC value of zero in the EAPOL-key frame requires no change to 802.11i or to 802.1X .=A0=A0It requires us to state this in the CAPWAP spec, if we want this behavior to be consistent across all implementations. The problem with what Bechet and Saranavan are asking is that either of three different things are required: = 1: the WTP must communicate the group key TSC to the AC every time it is updated, or 2: the AC must request the current value of the group key TSC for the KeyRSC before constructing the EAPOL-key frame, or 3: the AC must send the KCK to the AC so=A0=A0that it can insert the KeyRSC value and also calculate the correct MIC, inserting that into the proper EAPOL-key frame. The first item requires a tremendous amount of additional CAPWAP = communication between WTP and AC, at least one new CAPWAP packet for every multicast frame sent by the WTP, if the packet is not acknowledged, or two new CAPWAP packets, if it is acknowledged.=A0=A0This is a very expensive addition to the protocol. = The second item requires new protocol between the AC and WTP during what can be a time critical portion of the 802.11 transition (handoff, roam) from one WTP to another.=A0=A0It also introduces a race condition that is = not present in the protocol today.=A0=A0Once the value for the KeyRSC is sent from the WTP to the AC, it is possible that the WTP can send another multicast frame encrypted with the group key.=A0=A0This puts the value of the sequence counter out of sync with the value that will be = shortly communicated to the client in the EAPOL-key frame from the AC. This will behave exactly the same as if a value of zero is sent in the EAPOL-key frame. The third item requires a new architecture split that is not required in = our objectives.=A0=A0The new split is not splitting the MAC, but splitting the authenticator.=A0=A0Placing the KCK in the WTP is also a potential reduction in the security of the overall WLAN system, since these devices are normally not in a secured wiring closet, but exposed and = more easily compromised than the AC. The simplest to implement, least expensive, and most secure option is to use the protocol as it is now specified and have the AC send a value of zero in the KeyRSC field of the EAPOL-key frame. = -Bob -----Original Message----- From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] Sent: Wednesday, September 27, 2006 6:50 PM To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy; = Peter Nilsson J (LI/EAB) Cc: capwap@frascone.com Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi Pat and all, So, based on this, I would say that we have consensus that setting the = correct KeyRSC is an issue for the CAPWAP protocol design. So far, we have three option/solutions: 1) As proposed by Bob: Using a static value (0) for the KeyRSC. 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP = 3) As suggested by Saravanana: Some exchange mechanism between WTP and AC Among the three, the first option seems the easiest. However, it requires a mandated Authenticator behavior(in this case AC) that is not = mandated by 802.11. Therefore, we have to specify that (e.g. as proposed by Bob: "We could include a note to the effect that the group KeyRSC should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11, because otherwise there is no interoperability. For example, AC provided by another vendor does not have to set KeyRSC to 0 to be compliant with CAPWAP and 802.11i. Another implication is that we don't really understand the impact of = mandating a static KeyRSC value. Although Bob provided an excellent analysis, I still have some doubts about the profoundness of the impact. If the KeyRSC value is as described of no use, why would it appear in the EAPOL frames in the first place? By mandating it to static value, what have we lost? Maybe some liaison letter to 802.1 or 802.11 could provide us a better understanding of the issue. For the last two options, I think they are both within CAPWAP's scope. = Further analysis could help us to decide which one=A0=A0is better (or someone could propose other solutions). cheers Cheng Hong > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com] > Sent: Thursday, September 28, 2006 1:39 AM > To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; > Peter Nilsson J (LI/EAB) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Bob's point is 802.11i works this way today. The AP (or in = > this case AC) can set the RSC to whatever value it wishes. > Bob used zero (0) as an example. Implementations could use > any other value, which would require some form of > communication to the WTP, as suggested by Behcet. = > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Cheng Hong [mailto: Hong.Cheng@sg.panasonic.com] > > Sent: Tuesday, September 26, 2006 6:03 PM > > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson > J (LI/EAB) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > Hi Bob, > > > > If I understand your description below correct, you are proposing a = > > solution (to the problem pointed out by > > Saravanan) by mandating the behavior of the AC to always set the > > KeyRSC in the 4-way handshake to zero. > > > > This is not a defined behavior according to the current = > > 802.11 standard. > > Are you suggesting that we CAPWAP WG should specifically > mandate that > > in our CAPWAP protocol spec, e.g. something like "a CAPWAP > compatible > > AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, > > since not all AC implementation have to follow what you described. > > > > Or, are you planning to take this issue to TGm for 802.11 standard > > revision? (since based on your description, there is essentially no > > use of the KeyRSC). > > > > cheers > > > > Cheng Hong > > > > = > > > > > > > -----Original Message----- > > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > > > Sent: Wednesday, September 27, 2006 2:32 AM = > > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i = > > > Considerations > > > > > > Charles, Peter, > > > > > > Below is an expansion of a snippet from a thread on this > > topic that I > > > sent to the list on July 25, 2006.=A0=A0I think this will be = > helpful to > > > understand why the exchange that Saranavan is requesting is not > > > necessary.=A0=A0In fact, there are several systems from several > > > manufacturers in the field using precursor protocols to = > CAPWAP that > > > are Wi-Fi certified for WPA2/802.11i operation using the > > protocol as > > > it is described below. > > > > > > BTW, this whole discussion is about the KeyRSC for the = > > group key, not > > > the pairwise key.=A0=A0This is so because the WTP and AC both > know the > > > initial sequence counter value for the pairwise key, since it has > > > never been used to send a frame.=A0=A0 802.11i requires the > first frame > > > sent on a key to use the sequence counter value of 1.=A0=A0See > > 8.3.2.6 c) > > > and > > > 8.3.3.4.3 c) in 802.11i for this requirement. > > > > > > The same is not true of the group key, i.e., after the WTP begins > > > operation, the AC will not know the value of the sequence > > counter for = > > > the group key when it needs to complete the EAPOL-key > > handshake with a > > > newly associated STA. > > > However, as you will see from the tutorial below, it is not > > necessary > > > for the AC and WTP to exchange any information about the > group key > > > KeyRSC for the protocol to operate as it is intended. > > > > > > 1. A value for the KeyRSC in the EAPOL-key frame 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.=A0=A0A value of zero in the = > EAPOL-key > > > frame for the group key will always work. > > > > > > 3. The client STA will use the value of KeyRSC received in the > > > EAPOL-key frame to validate frame using the KeyMIC. = > > > > > > 4. The client STA will also set its group key RSC to the value > > > received in KeyRSC, say, zero. > > > > > > 5. The value in the client STA's RSC will be compared against the = > > > sequence number in subsequent received frames to identify replay > > > attacks.=A0=A0Any frame received with a sequence counter value > > within the > > > replay window will be checked to have a valid MIC.=A0=A0If the = > > MIC is not > > > valid, the frame is dropped. > > > > > > 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, if the value is greater than its current RSC value. > > Only the > > > AP can meet these criteria as the source of a frame = > received by the > > > STA. > > > > > > 7. Please see item 6, immediately above, for the reason > that the AC > > > and WTP do not need to coordinate and exchange the RSC. = > > > > > > > > > The only possible attack mode is for the attacker to send > frames to > > > the client STA between the time of the EAPOL-key frame and > > the first = > > > frame encrypted with the group key. > > > During this time, the client will receive the frame and > proceed to > > > validate its MIC.=A0=A0This is a potential attack against the STA = > > > resources.=A0=A0But, the MIC validation is done in the STA's > > > 802.11 chip and consumes no more resources than receiving > any other > > > frame.=A0=A0Thus, the attack does not actually consume any STA = > > resources > > > beyond those of receiving a frame. > > > > > > This attack is not unique to the use of the value zero for > > the KeyRSC, > > > either.=A0=A0The same attack is available to an attacker at any other = > > > time, as well.=A0=A0It is no more nor less effective at either time. > > > > > > For these reasons, the protocol is not in need of any changes to > > > address the issue raised by Saranavan. = > > > > > >=A0=A0-Bob > > > -----Original Message----- > > > From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > > > Sent: Monday, September 25, 2006 11:37 AM = > > > To: Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations = > > > > > > This is a very interesting solution.=A0=A0The AC selects the > KeyRSC and > > > performs the 4-way handshake.=A0=A0The WTP sniffs the 4-way handshake > > > traffic and grabs the KeyRSC value and uses it to = > > initialize its own > > > counter. > > > > > > Pat/Bob: Is this how the Cisco implementation works?=A0=A0I > > have to agree > > > with Saravanan that I've yet to see a technical = > description of how > > > Cisco implements it. > > > > > > IMHO, this is somewhat hackish, and it would be cleaner to > > have the AC > > > generate the KeyRSC and include it in the AddMobile message = > > as Behcet > > > suggests. > > > > > > -- > > > t. charles clancy, ph.d.=A0=A0|=A0=A0tcc@umd.edu=A0=A0| > www.cs.umd.edu/~clancy > > > > > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > > > > > > > I think Saravanan has a point. We did a prototype > > impelementation of = > > > the > > > > protocol a year ago when it was still called LWAPP. The way > > > we solved > > > > this issue then was to let the WTP sniff on all CAPWAP data > > > messages = > > > > from the AC and when message 3 of the 4-way handshake or > > > message 1 of > > > > the groupkey handshake was sent the WTP inserted the correct RSC > > > before = > > > > sending it off to the supplicant. To avoid the sniffing on > > > all CAPWAP > > > > data messages we would need a mechanism with in CAPWAP to > > > handle these = > > > > two messages. > > > > > > > > Peter Nilsson > > > > > > > > -----Original Message----- > > > > From: Saravanan Govindan > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > Sent: den 22 september 2006 11:03 > > > > To: Margaret Wasserman > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > Hi Margaret, > > > > > > > > Thank you for reviewing the discussion on this issue. > > > > > > > > The issue here is the working of IEEE 802.11i when the 802.11i > > > > authenticator element is at the AC and the 802.11i crypto > > element is > > > at > > > > the WTP. Particularly, it is for the 4-way handshake between = > > > > authenticator and supplicant. > > > > > > > > Now, the 4-way handshake requires knowing the value of > > > KeyRSC sequence > > > > counter. The KeyRSC helps both authenticator and supplicant = > > > keep track > > > > of their exchanges. It serves to protect against threats by > > > tracking > > > > sequential frames. The KeyRSC is maintained at the at the > > point of > > > > encryption, i.e. just before transmission over the > > wireless channel. > > > > > > > > In the case of CAPWAP, the 4-way handshake is between the AC = > > > > (authenticator) and the wireless station (supplicant). > > > > > > > > The problem arises, when the authenticator is at the AC and > > > the crypto > > > > element (together with KeyRSC) is at the WTP. This is a = > > > fairly common > > > > design. Now in this case, the AC starts the 4-way > handshake but it > > > does > > > > not know the value of the KeyRSC. The KeyRSC is maintained = > > > by the WTP. > > > > > > > > Based on this, the current CAPWAP specification does not > > allow for a > > > way > > > > to conduct the 4-way handshake with the correct KeyRSC. = > > > > > > > > The functionality I would like to see is a way for the > > authenticator > > > > (AC) to use the correct prevailing value of KeyRSC > > > (maintained by the = > > > > WTP) in its 4-way handshake. > > > > > > > > One way to introduce this functionality in to CAPWAP is > > to have part > > > of > > > > the 4-way handshake be sent from AC to WTP. This will allow = > > > the 4-way > > > > handshake to use the correct value of the KeyRSC before > > > being sent to > > > > the wireless station. > > > > > > > > I hope this helps clarify my view on the issue. = > > > > > > > > Cheers, > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > = > > > > > > > > -----Original Message----- > > > > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > > > > Sent: Thursday, September 21, 2006 8:26 PM = > > > > To: Saravanan Govindan > > > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > > > > > > > > > Hi again, > > > > > > > > Okay, I am even more confused than I thought I was... = > > > > > > > > Saravanan, you wrote: > > > > > > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > > > > > >> Pat, = > > > >> > > > >> The issue here is about how 802.11i exchanges are done when > > > >> authenticator is at the AC and crypto elements are at > > the WTP. This = > > > is > > > >> the requirement. > > > > > > > > And, in response, Pat Calhoun wrote: > > > > > > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: = > > > >> The current specification allows the authenticator to > > > reside in the > > > >> AC, while the data packet crypto elements in the WTP. This > > > feature is = > > > >> already in the specification. > > > > > > > > Pat's message matches my reading of the specification. > > > > > > > > So, Saravanan, what functionality are you asking for = > that is not > > > > already supported by the specification?=A0=A0And why do you > > think it is > > > > necessary?=A0=A0it will not be helpful to my understanding to > > > re-send your = > > > > proposal or to cite the requirements document...=A0=A0Please > > summarize > > > > what functionality you think is missing from the current > > > specification > > > > and why you think that functionality is necessary to = > support IEEE > > > > 802.11i or any important use case. > > > > > > > > At some point, the chairs may need to make a consensus > > call on this > > > > issue, and I'd like to understand your view and make sure = > > > that it has > > > > been clearly communicated to the WG before we ask the WG to > > > decide on > > > > this issue. > > > > > > > > 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 > > > > > _________________________________________________________________ = > > > > 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 > > > > > _________________________________________________________________ > > 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 _________________________________________________________________ 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 Sep 30 12:05:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GThLB-0005sa-Ij for capwap-archive@lists.ietf.org; Sat, 30 Sep 2006 12:05:25 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GThL5-00073H-83 for capwap-archive@lists.ietf.org; Sat, 30 Sep 2006 12:05:25 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3FD24398045 for ; Sat, 30 Sep 2006 09:05:07 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id DA07543005A for ; Sat, 30 Sep 2006 09:02:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BF8D9431126 for ; Sat, 30 Sep 2006 09:02:10 -0700 (PDT) X-Greylist-Status: Sender first seen 9 days 07:15:00 ago Received: from thingmagic.com (unknown [204.9.221.19]) by hermes.tigertech.net (Postfix) with ESMTP id 674BE431117 for ; Sat, 30 Sep 2006 09:02:06 -0700 (PDT) Received: from [66.30.121.250] (account margaret HELO [192.168.2.3]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1336213; Sat, 30 Sep 2006 12:02:05 -0400 In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2028E9C5D@xmb-sjc-235.amer.cisco.com> References: <4FF84B0BC277FF45AA27FE969DD956A2028E9C5D@xmb-sjc-235.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <460EF4EE-47FB-44D8-9273-4B5FBBDD2400@thingmagic.com> From: Margaret Wasserman Date: Sat, 30 Sep 2006 12:00:15 -0400 To: Pat Calhoun (pacalhou) X-Mailer: Apple Mail (2.752.2) 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: Saravanan Govindan , Cheng Hong , capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: e61164d90a5bf7123da65dce5444794e Could one of you explain to me what the implications would be of the AC always using an RSC value of 0 to compute the MIC in message 3 of the 4-way handshake? Would this reduce/eliminate the value of the RSC as a security mechanism? Does it imply something about how the WTP needs to behave? Something about how the supplicant needs to behave? Thanks, Margaret On Sep 29, 2006, at 4:43 PM, Pat Calhoun (pacalhou) wrote: > To be fair, one option requires that message 3 be created, and > encrypted, in the WTP. This implies that encryption and authentication > keys required to formulate message 3 be sent to the WTP. > > Seems to me simpler to include text that either states the value of > zero > is always used (simplest), or some configurable value be sent to > the WTP > (simpler). > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > >> -----Original Message----- >> From: T. Charles Clancy [mailto:clancy@cs.umd.edu] >> Sent: Friday, September 29, 2006 12:07 PM >> To: Cheng Hong >> Cc: Bob O'Hara (boohara); Dorothy Stanley; Pat Calhoun >> (pacalhou); Peter Nilsson J (LI/EAB); capwap@frascone.com; >> Saravanan Govindan >> Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i >> Considerations >> >> All, >> >> I'm glad to see we're finally arguing about the right issue. >> As discussed, the Cisco solution to the problem is "set it to zero". >> Certainly sniffing the value works as well. From a security >> standpoint either is just fine. >> >> We do have an interoperability issue, however, if a Cisco WTP >> were used with an AC that's randomly generating a KeyRSC and >> expecting the WTP to sniff it. So, I think some text is >> necessary to address the issue. >> >> What remains are two entrenched opinions about protocol >> flexibility vs simplicity, neither of which would >> significantly tilt the flexibility vs simplicity balance in >> either of direction. Let's flip a coin and move on to more >> important issues. >> >> -- >> t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy >> >> On Fri, 29 Sep 2006, Cheng Hong wrote: >> >>> Hi Bob, >>> >>> As Dorothy correctly pointed out below, setting the KeyRSC >> to a value >>> closer to the current RSC would be better than setting it to a >>> pre-defined value zero. >>> >>> It is true that 802.11i and 802.1X do not specify what is the KeyRSC >>> value to be used, since they are trying to provide us a tool to >>> correctly synchronize the RSC using the Msg 3. By mandating >> the KeyRSC >>> to zero, we are just disabling the tool. It is not wrong, but just >>> deprives the system a designed function. >>> >>> As for the effectiveness of KeyRSC, setting it to a >> predefined value of >>> 0 would pose a greater threat. In a simple example, if the RSC is >>> currently 1000, and we are mandating the KeyRSC to be >> always zero, the >>> attacker basically can safely replay the last 1000 packets >> to the STA >>> without being detected. If the KeyRSC can be set to a >> closer value of >>> the current RSC, say, 900, the number of possible replayed >> packets can >>> be reduced to 10 percent, 100 packets. >>> >>> Therefore, I would say, setting the KeyRSC value to zero >> does place a >>> bigger threat. Is that how the cisco products implemented? Maybe you >>> could share with us some other implementation/testing data to prove >>> otherwise. Or, you have some other considerations that >> could defend the >>> replay attack? >>> >>> cheers >>> >>> Cheng Hong >>> >>> >>> >>> _____ >>> >>> From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] >>> Sent: Friday, September 29, 2006 5:21 AM >>> To: Dorothy Stanley >>> Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; >> Peter Nilsson >>> J (LI/EAB); capwap@frascone.com >>> Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i >> Considerations >>> >>> >>> Dorothy, >>> >>> The problem with this proposal is that it is no more effective than >>> sending a value of zero for the KeyRSC. It doesn't eliminate any >>> potential attacks. It doesn't add any functionality. >> However, it does >>> add cost and complexity to the protocol. >>> >>> -Bob >>> >>> >>> >>> >>> _____ >>> >>> From: Dorothy Stanley [mailto:dstanley1389@gmail.com] >>> Sent: Thursday, September 28, 2006 1:17 PM >>> To: Bob O'Hara (boohara) >>> Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; >> Peter Nilsson >>> J (LI/EAB); capwap@frascone.com >>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >> Considerations >>> >>> >>> All, >>> >>> Below is the text from 802.11REV-maD8.0 Clause 8.5.2, >> describing the Key >>> RSC field.: >>> >>> "g) Key RSC. This field is 8 octets in length. It contains >> the receive >>> sequence counter (RSC) for the >>> GTK being installed in IEEE 802.11. It is used in Message 3 >> of the 4-Way >>> Handshake and >>> Message 1 of the Group Key Handshake, where it is used to >> synchronize >>> the IEEE 802.11 replay >>> state. It may also be used in the Michael MIC Failure >> Report frame, to >>> report the TSC field value of >>> the frame experiencing a MIC failure. It shall contain 0 in other >>> messages. The Key RSC field gives >>> the current message number for the GTK, to allow a STA to identify >>> replayed MPDUs. If the Key >>> RSC field value is less than 8 octets in length, the >> remaining octets >>> shall be set to 0. The least significant >>> octet of the TSC or PN should be in the first octet of the Key RSC >>> field." >>> >>> The intent of adding this value in message 3 was to >> immediately minimize >>> the number of >>> replayed frames that a STA would potentially process: "The >> Key RSC field >>> gives >>> the current message number for the GTK, to allow a STA to identify >>> replayed MPDUs." >>> Setting the value to 0 in Msg 3 does not provide the >> current sequence >>> counter (in most cases >>> not even close) of the GTK.. >>> >>> Perhaps the WTP could periodically/frequently notify the AC of its >>> current GTK sequence counter, and the >>> AC would use the most recently received value in the >> message 3 sent to >>> new STAs. The RSC value >>> would not be up to date at all times, but would be closer >> than "0", not >>> require an "in-the-critical-path >>> message exchange between the AC and WTP, and still be close to the >>> intended use of the field. >>> >>> Dorothy >>> >>> >>> On 9/28/06, Bob O'Hara (boohara) wrote: >>> >>> Please understand that 802.11i specifies no behavior in >> this area for >>> the 802.1X authenticator. Our choice to send a group key >> KeyRSC value >>> of zero in the EAPOL-key frame requires no change to 802.11i or to >>> 802.1X . It requires us to state this in the CAPWAP spec, >> if we want >>> this behavior to be consistent across all implementations. >>> >>> The problem with what Bechet and Saranavan are asking is >> that either of >>> three different things are required: >>> 1: the WTP must communicate the group key TSC to the AC >> every time it is >>> updated, or >>> 2: the AC must request the current value of the group key >> TSC for the >>> KeyRSC before constructing the EAPOL-key frame, or >>> 3: the AC must send the KCK to the AC so that it can >> insert the KeyRSC >>> value and also calculate the correct MIC, inserting that >> into the proper >>> EAPOL-key frame. >>> >>> The first item requires a tremendous amount of additional CAPWAP >>> communication between WTP and AC, at least one new CAPWAP packet for >>> every multicast frame sent by the WTP, if the packet is not >>> acknowledged, or two new CAPWAP packets, if it is >> acknowledged. This is >>> a very expensive addition to the protocol. >>> >>> The second item requires new protocol between the AC and >> WTP during what >>> can be a time critical portion of the 802.11 transition >> (handoff, roam) >>> from one WTP to another. It also introduces a race >> condition that is >>> not present in the protocol today. Once the value for the KeyRSC is >>> sent from the WTP to the AC, it is possible that the WTP can send >>> another multicast frame encrypted with the group key. This puts the >>> value of the sequence counter out of sync with the value >> that will be >>> shortly communicated to the client in the EAPOL-key frame >> from the AC. >>> This will behave exactly the same as if a value of zero is >> sent in the >>> EAPOL-key frame. >>> >>> The third item requires a new architecture split that is >> not required in >>> >>> our objectives. The new split is not splitting the MAC, >> but splitting >>> the authenticator. Placing the KCK in the WTP is also a potential >>> reduction in the security of the overall WLAN system, since these >>> devices are normally not in a secured wiring closet, but exposed and >>> more easily compromised than the AC. >>> >>> The simplest to implement, least expensive, and most secure >> option is to >>> use the protocol as it is now specified and have the AC >> send a value of >>> zero in the KeyRSC field of the EAPOL-key frame. >>> >>> -Bob >>> >>> -----Original Message----- >>> From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] >>> Sent: Wednesday, September 27, 2006 6:50 PM >>> To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy; >>> Peter Nilsson J (LI/EAB) >>> Cc: capwap@frascone.com >>> Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i >> Considerations >>> >>> Hi Pat and all, >>> >>> So, based on this, I would say that we have consensus that >> setting the >>> correct KeyRSC is an issue for the CAPWAP protocol design. >>> >>> So far, we have three option/solutions: >>> >>> 1) As proposed by Bob: Using a static value (0) for the KeyRSC. >>> >>> 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP >>> >>> 3) As suggested by Saravanana: Some exchange mechanism >> between WTP and >>> AC >>> >>> Among the three, the first option seems the easiest. However, it >>> requires a mandated Authenticator behavior(in this case AC) >> that is not >>> mandated by 802.11. Therefore, we have to specify that >> (e.g. as proposed >>> by Bob: "We could include a note to the effect that the group KeyRSC >>> should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11, >>> because otherwise there is no interoperability. For >> example, AC provided >>> by another vendor does not have to set KeyRSC to 0 to be >> compliant with >>> CAPWAP and 802.11i. >>> >>> Another implication is that we don't really understand the impact of >>> mandating a static KeyRSC value. Although Bob provided an excellent >>> analysis, I still have some doubts about the profoundness >> of the impact. >>> If the KeyRSC value is as described of no use, why would it >> appear in >>> the EAPOL frames in the first place? By mandating it to >> static value, >>> what have we lost? Maybe some liaison letter to 802.1 or >> 802.11 could >>> provide us a better understanding of the issue. >>> >>> For the last two options, I think they are both within >> CAPWAP's scope. >>> Further analysis could help us to decide which one is better (or >>> someone could propose other solutions). >>> >>> cheers >>> >>> Cheng Hong >>> >>> >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com] >>>> Sent: Thursday, September 28, 2006 1:39 AM >>>> To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; >>>> Peter Nilsson J (LI/EAB) >>>> Cc: capwap@frascone.com >>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>> Considerations >>>> >>>> Bob's point is 802.11i works this way today. The AP (or in >>>> this case AC) can set the RSC to whatever value it wishes. >>>> Bob used zero (0) as an example. Implementations could use >>>> any other value, which would require some form of >>>> communication to the WTP, as suggested by Behcet. >>>> >>>> Pat Calhoun >>>> CTO, Wireless Networking Business Unit >>>> Cisco Systems >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Cheng Hong [mailto: >>> Hong.Cheng@sg.panasonic.com] >>>>> Sent: Tuesday, September 26, 2006 6:03 PM >>>>> To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson >>>> J (LI/EAB) >>>>> Cc: capwap@frascone.com >>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>>> Considerations >>>>> >>>>> Hi Bob, >>>>> >>>>> If I understand your description below correct, you are >> proposing a >>>>> solution (to the problem pointed out by >>>>> Saravanan) by mandating the behavior of the AC to always set the >>>>> KeyRSC in the 4-way handshake to zero. >>>>> >>>>> This is not a defined behavior according to the current >>>>> 802.11 standard. >>>>> Are you suggesting that we CAPWAP WG should specifically >>>> mandate that >>>>> in our CAPWAP protocol spec, e.g. something like "a CAPWAP >>>> compatible >>>>> AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, >>>>> since not all AC implementation have to follow what you described. >>>>> >>>>> Or, are you planning to take this issue to TGm for 802.11 standard >>>>> revision? (since based on your description, there is >> essentially no >>>>> use of the KeyRSC). >>>>> >>>>> cheers >>>>> >>>>> Cheng Hong >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] >>>>>> Sent: Wednesday, September 27, 2006 2:32 AM >>>>>> To: T. Charles Clancy; Peter Nilsson J (LI/EAB) >>>>>> Cc: capwap@frascone.com >>>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>>>> Considerations >>>>>> >>>>>> Charles, Peter, >>>>>> >>>>>> Below is an expansion of a snippet from a thread on this >>>>> topic that I >>>>>> sent to the list on July 25, 2006. I think this will be >>>> helpful to >>>>>> understand why the exchange that Saranavan is requesting is not >>>>>> necessary. In fact, there are several systems from several >>>>>> manufacturers in the field using precursor protocols to >>>> CAPWAP that >>>>>> are Wi-Fi certified for WPA2/802.11i operation using the >>>>> protocol as >>>>>> it is described below. >>>>>> >>>>>> BTW, this whole discussion is about the KeyRSC for the >>>>> group key, not >>>>>> the pairwise key. This is so because the WTP and AC both >>>> know the >>>>>> initial sequence counter value for the pairwise key, since it has >>>>>> never been used to send a frame. 802.11i requires the >>>> first frame >>>>>> sent on a key to use the sequence counter value of 1. See >>>>> 8.3.2.6 c) >>>>>> and >>>>>> 8.3.3.4.3 c) in 802.11i for this requirement. >>>>>> >>>>>> The same is not true of the group key, i.e., after the WTP begins >>>>>> operation, the AC will not know the value of the sequence >>>>> counter for >>>>>> the group key when it needs to complete the EAPOL-key >>>>> handshake with a >>>>>> newly associated STA. >>>>>> However, as you will see from the tutorial below, it is not >>>>> necessary >>>>>> for the AC and WTP to exchange any information about the >>>> group key >>>>>> KeyRSC for the protocol to operate as it is intended. >>>>>> >>>>>> 1. A value for the KeyRSC in the EAPOL-key frame 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. A value of zero in the >>>> EAPOL-key >>>>>> frame for the group key will always work. >>>>>> >>>>>> 3. The client STA will use the value of KeyRSC received in the >>>>>> EAPOL-key frame to validate frame using the KeyMIC. >>>>>> >>>>>> 4. The client STA will also set its group key RSC to the value >>>>>> received in KeyRSC, say, zero. >>>>>> >>>>>> 5. The value in the client STA's RSC will be compared against the >>>>>> sequence number in subsequent received frames to identify replay >>>>>> attacks. Any frame received with a sequence counter value >>>>> within the >>>>>> replay window will be checked to have a valid MIC. If the >>>>> MIC is not >>>>>> valid, the frame is dropped. >>>>>> >>>>>> 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, if the value is greater than its current RSC value. >>>>> Only the >>>>>> AP can meet these criteria as the source of a frame >>>> received by the >>>>>> STA. >>>>>> >>>>>> 7. Please see item 6, immediately above, for the reason >>>> that the AC >>>>>> and WTP do not need to coordinate and exchange the RSC. >>>>>> >>>>>> >>>>>> The only possible attack mode is for the attacker to send >>>> frames to >>>>>> the client STA between the time of the EAPOL-key frame and >>>>> the first >>>>>> frame encrypted with the group key. >>>>>> During this time, the client will receive the frame and >>>> proceed to >>>>>> validate its MIC. This is a potential attack against the STA >>>>>> resources. But, the MIC validation is done in the STA's >>>>>> 802.11 chip and consumes no more resources than receiving >>>> any other >>>>>> frame. Thus, the attack does not actually consume any STA >>>>> resources >>>>>> beyond those of receiving a frame. >>>>>> >>>>>> This attack is not unique to the use of the value zero for >>>>> the KeyRSC, >>>>>> either. The same attack is available to an attacker at any other >>>>>> time, as well. It is no more nor less effective at either time. >>>>>> >>>>>> For these reasons, the protocol is not in need of any changes to >>>>>> address the issue raised by Saranavan. >>>>>> >>>>>> -Bob >>>>>> -----Original Message----- >>>>>> From: T. Charles Clancy [mailto:clancy@cs.umd.edu] >>>>>> Sent: Monday, September 25, 2006 11:37 AM >>>>>> To: Peter Nilsson J (LI/EAB) >>>>>> Cc: capwap@frascone.com >>>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>>>> Considerations >>>>>> >>>>>> This is a very interesting solution. The AC selects the >>>> KeyRSC and >>>>>> performs the 4-way handshake. The WTP sniffs the 4-way handshake >>>>>> traffic and grabs the KeyRSC value and uses it to >>>>> initialize its own >>>>>> counter. >>>>>> >>>>>> Pat/Bob: Is this how the Cisco implementation works? I >>>>> have to agree >>>>>> with Saravanan that I've yet to see a technical >>>> description of how >>>>>> Cisco implements it. >>>>>> >>>>>> IMHO, this is somewhat hackish, and it would be cleaner to >>>>> have the AC >>>>>> generate the KeyRSC and include it in the AddMobile message >>>>> as Behcet >>>>>> suggests. >>>>>> >>>>>> -- >>>>>> t. charles clancy, ph.d. | tcc@umd.edu | >>>> www.cs.umd.edu/~clancy >>>>>> >>>>>> On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: >>>>>> >>>>>>> I think Saravanan has a point. We did a prototype >>>>> impelementation of >>>>>> the >>>>>>> protocol a year ago when it was still called LWAPP. The way >>>>>> we solved >>>>>>> this issue then was to let the WTP sniff on all CAPWAP data >>>>>> messages >>>>>>> from the AC and when message 3 of the 4-way handshake or >>>>>> message 1 of >>>>>>> the groupkey handshake was sent the WTP inserted the correct RSC >>>>>> before >>>>>>> sending it off to the supplicant. To avoid the sniffing on >>>>>> all CAPWAP >>>>>>> data messages we would need a mechanism with in CAPWAP to >>>>>> handle these >>>>>>> two messages. >>>>>>> >>>>>>> Peter Nilsson >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Saravanan Govindan >>>>>> [mailto:Saravanan.Govindan@sg.panasonic.com] >>>>>>> Sent: den 22 september 2006 11:03 >>>>>>> To: Margaret Wasserman >>>>>>> Cc: capwap@frascone.com >>>>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>>>> Considerations >>>>>>> >>>>>>> Hi Margaret, >>>>>>> >>>>>>> Thank you for reviewing the discussion on this issue. >>>>>>> >>>>>>> The issue here is the working of IEEE 802.11i when the 802.11i >>>>>>> authenticator element is at the AC and the 802.11i crypto >>>>> element is >>>>>> at >>>>>>> the WTP. Particularly, it is for the 4-way handshake between >>>>>>> authenticator and supplicant. >>>>>>> >>>>>>> Now, the 4-way handshake requires knowing the value of >>>>>> KeyRSC sequence >>>>>>> counter. The KeyRSC helps both authenticator and supplicant >>>>>> keep track >>>>>>> of their exchanges. It serves to protect against threats by >>>>>> tracking >>>>>>> sequential frames. The KeyRSC is maintained at the at the >>>>> point of >>>>>>> encryption, i.e. just before transmission over the >>>>> wireless channel. >>>>>>> >>>>>>> In the case of CAPWAP, the 4-way handshake is between the AC >>>>>>> (authenticator) and the wireless station (supplicant). >>>>>>> >>>>>>> The problem arises, when the authenticator is at the AC and >>>>>> the crypto >>>>>>> element (together with KeyRSC) is at the WTP. This is a >>>>>> fairly common >>>>>>> design. Now in this case, the AC starts the 4-way >>>> handshake but it >>>>>> does >>>>>>> not know the value of the KeyRSC. The KeyRSC is maintained >>>>>> by the WTP. >>>>>>> >>>>>>> Based on this, the current CAPWAP specification does not >>>>> allow for a >>>>>> way >>>>>>> to conduct the 4-way handshake with the correct KeyRSC. >>>>>>> >>>>>>> The functionality I would like to see is a way for the >>>>> authenticator >>>>>>> (AC) to use the correct prevailing value of KeyRSC >>>>>> (maintained by the >>>>>>> WTP) in its 4-way handshake. >>>>>>> >>>>>>> One way to introduce this functionality in to CAPWAP is >>>>> to have part >>>>>> of >>>>>>> the 4-way handshake be sent from AC to WTP. This will allow >>>>>> the 4-way >>>>>>> handshake to use the correct value of the KeyRSC before >>>>>> being sent to >>>>>>> the wireless station. >>>>>>> >>>>>>> I hope this helps clarify my view on the issue. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Saravanan >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Margaret Wasserman [mailto:margaret@thingmagic.com] >>>>>>> Sent: Thursday, September 21, 2006 8:26 PM >>>>>>> To: Saravanan Govindan >>>>>>> Cc: Pat Calhoun (pacalhou); capwap@frascone.com >>>>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>>>> Considerations >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi again, >>>>>>> >>>>>>> Okay, I am even more confused than I thought I was... >>>>>>> >>>>>>> Saravanan, you wrote: >>>>>>> >>>>>>> On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: >>>>>>> >>>>>>>> Pat, >>>>>>>> >>>>>>>> The issue here is about how 802.11i exchanges are done when >>>>>>>> authenticator is at the AC and crypto elements are at >>>>> the WTP. This >>>>>> is >>>>>>>> the requirement. >>>>>>> >>>>>>> And, in response, Pat Calhoun wrote: >>>>>>> >>>>>>> On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: >>>>>>>> The current specification allows the authenticator to >>>>>> reside in the >>>>>>>> AC, while the data packet crypto elements in the WTP. This >>>>>> feature is >>>>>>>> already in the specification. >>>>>>> >>>>>>> Pat's message matches my reading of the specification. >>>>>>> >>>>>>> So, Saravanan, what functionality are you asking for >>>> that is not >>>>>>> already supported by the specification? And why do you >>>>> think it is >>>>>>> necessary? it will not be helpful to my understanding to >>>>>> re-send your >>>>>>> proposal or to cite the requirements document... Please >>>>> summarize >>>>>>> what functionality you think is missing from the current >>>>>> specification >>>>>>> and why you think that functionality is necessary to >>>> support IEEE >>>>>>> 802.11i or any important use case. >>>>>>> >>>>>>> At some point, the chairs may need to make a consensus >>>>> call on this >>>>>>> issue, and I'd like to understand your view and make sure >>>>>> that it has >>>>>>> been clearly communicated to the WG before we ask the WG to >>>>>> decide on >>>>>>> this issue. >>>>>>> >>>>>>> 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 >>>>>>> >>>> _________________________________________________________________ >>>>>>> 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 >>>>>> >>>>> _________________________________________________________________ >>>>> 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 >>> >>> >>> >>> >> > _________________________________________________________________ > 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 Sep 30 19:14:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTo2Y-0000Lf-Ui for capwap-archive@lists.ietf.org; Sat, 30 Sep 2006 19:14:38 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTo2W-00051w-Js for capwap-archive@lists.ietf.org; Sat, 30 Sep 2006 19:14:38 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 492FA39801F for ; Sat, 30 Sep 2006 16:14:35 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9392E43005A for ; Sat, 30 Sep 2006 16:11:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 64166431A57 for ; Sat, 30 Sep 2006 16:11:18 -0700 (PDT) Received: from mcfeely.cs.umd.edu (mcfeely.cs.umd.edu [128.8.128.218]) by hermes.tigertech.net (Postfix) with ESMTP id BF3C7431A3C for ; Sat, 30 Sep 2006 16:11:11 -0700 (PDT) Received: from mcfeely.cs.umd.edu (localhost [127.0.0.1]) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id k8UNB9Uw022669; Sat, 30 Sep 2006 19:11:09 -0400 Received: (from apache@localhost) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id k8UNB40x022664; Sat, 30 Sep 2006 19:11:04 -0400 X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to clancy@cs.umd.edu using -f Received: from 216.147.130.68 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Sat, 30 Sep 2006 19:11:04 -0400 (EDT) Message-ID: <58582.216.147.130.68.1159657864.squirrel@webmail.cs.umd.edu> In-Reply-To: <460EF4EE-47FB-44D8-9273-4B5FBBDD2400@thingmagic.com> References: <4FF84B0BC277FF45AA27FE969DD956A2028E9C5D@xmb-sjc-235.amer.cisco.com> <460EF4EE-47FB-44D8-9273-4B5FBBDD2400@thingmagic.com> Date: Sat, 30 Sep 2006 19:11:04 -0400 (EDT) From: "Charles Clancy" To: "Margaret Wasserman" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: 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.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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: 9d5866e4c615ceea0db8f42c46495d22 I've reread the thread and reread the relevent portions of 11i. I think my statements before were partially inaccurate. The security and overhead ramifications are not insignificant. We can: 1. Set the KeyRSC to a static value. This increases the risk of replay attacks of multicast/broadcast packets encrypted with the group key between the time the client authenticates and when the first legitimate group key-encrypted packet is transmitted. 2. Periodically transmit the KeyRSC from the WTP to the AC. This would allow for fewer packets to be replayed, but would not completely prevent replay attacks. Probabalistically, it would weaken their effectiveness. The added price is more protocol overhead. 3. Have the WTP request the GTK prior to initiating the 4-way handshake. This would eliminate replay attacks, but add one round trip to the authentication process. This could possibly be optimized by having the WTP detect EAPOL message 1 being sent to the STA, and immediately transmit it to the AC before it needs it for EAPOL message 3. Transporting the KCK to the WTP breaks the security model, and should not be considered a viable option. None of the approaches affect the STA operation, or require any changes to 802.11. Here's a question: what happens if the newly authenticated STA tries to transmit a GTK-encrypted packet using RSC=0? Would it get dropped? Is this a problem, particularly for protocols such as DHCP? -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy On Sat, September 30, 2006 12:00 pm, Margaret Wasserman wrote: > > > Could one of you explain to me what the implications would be of the > AC always using an RSC value of 0 to compute the MIC in message 3 of > the 4-way handshake? > > Would this reduce/eliminate the value of the RSC as a security > mechanism? Does it imply something about how the WTP needs to > behave? Something about how the supplicant needs to behave? > > Thanks, > Margaret > > > On Sep 29, 2006, at 4:43 PM, Pat Calhoun (pacalhou) wrote: > >> To be fair, one option requires that message 3 be created, and >> encrypted, in the WTP. This implies that encryption and authentication >> keys required to formulate message 3 be sent to the WTP. >> >> Seems to me simpler to include text that either states the value of >> zero >> is always used (simplest), or some configurable value be sent to >> the WTP >> (simpler). >> >> Pat Calhoun >> CTO, Wireless Networking Business Unit >> Cisco Systems >> >> >> >>> -----Original Message----- >>> From: T. Charles Clancy [mailto:clancy@cs.umd.edu] >>> Sent: Friday, September 29, 2006 12:07 PM >>> To: Cheng Hong >>> Cc: Bob O'Hara (boohara); Dorothy Stanley; Pat Calhoun >>> (pacalhou); Peter Nilsson J (LI/EAB); capwap@frascone.com; >>> Saravanan Govindan >>> Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i >>> Considerations >>> >>> All, >>> >>> I'm glad to see we're finally arguing about the right issue. >>> As discussed, the Cisco solution to the problem is "set it to zero". >>> Certainly sniffing the value works as well. From a security >>> standpoint either is just fine. >>> >>> We do have an interoperability issue, however, if a Cisco WTP >>> were used with an AC that's randomly generating a KeyRSC and >>> expecting the WTP to sniff it. So, I think some text is >>> necessary to address the issue. >>> >>> What remains are two entrenched opinions about protocol >>> flexibility vs simplicity, neither of which would >>> significantly tilt the flexibility vs simplicity balance in >>> either of direction. Let's flip a coin and move on to more >>> important issues. >>> >>> -- >>> t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy >>> >>> On Fri, 29 Sep 2006, Cheng Hong wrote: >>> >>>> Hi Bob, >>>> >>>> As Dorothy correctly pointed out below, setting the KeyRSC >>> to a value >>>> closer to the current RSC would be better than setting it to a >>>> pre-defined value zero. >>>> >>>> It is true that 802.11i and 802.1X do not specify what is the KeyRSC >>>> value to be used, since they are trying to provide us a tool to >>>> correctly synchronize the RSC using the Msg 3. By mandating >>> the KeyRSC >>>> to zero, we are just disabling the tool. It is not wrong, but just >>>> deprives the system a designed function. >>>> >>>> As for the effectiveness of KeyRSC, setting it to a >>> predefined value of >>>> 0 would pose a greater threat. In a simple example, if the RSC is >>>> currently 1000, and we are mandating the KeyRSC to be >>> always zero, the >>>> attacker basically can safely replay the last 1000 packets >>> to the STA >>>> without being detected. If the KeyRSC can be set to a >>> closer value of >>>> the current RSC, say, 900, the number of possible replayed >>> packets can >>>> be reduced to 10 percent, 100 packets. >>>> >>>> Therefore, I would say, setting the KeyRSC value to zero >>> does place a >>>> bigger threat. Is that how the cisco products implemented? Maybe you >>>> could share with us some other implementation/testing data to prove >>>> otherwise. Or, you have some other considerations that >>> could defend the >>>> replay attack? >>>> >>>> cheers >>>> >>>> Cheng Hong >>>> >>>> >>>> >>>> _____ >>>> >>>> From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] >>>> Sent: Friday, September 29, 2006 5:21 AM >>>> To: Dorothy Stanley >>>> Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; >>> Peter Nilsson >>>> J (LI/EAB); capwap@frascone.com >>>> Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i >>> Considerations >>>> >>>> >>>> Dorothy, >>>> >>>> The problem with this proposal is that it is no more effective than >>>> sending a value of zero for the KeyRSC. It doesn't eliminate any >>>> potential attacks. It doesn't add any functionality. >>> However, it does >>>> add cost and complexity to the protocol. >>>> >>>> -Bob >>>> >>>> >>>> >>>> >>>> _____ >>>> >>>> From: Dorothy Stanley [mailto:dstanley1389@gmail.com] >>>> Sent: Thursday, September 28, 2006 1:17 PM >>>> To: Bob O'Hara (boohara) >>>> Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; >>> Peter Nilsson >>>> J (LI/EAB); capwap@frascone.com >>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>> Considerations >>>> >>>> >>>> All, >>>> >>>> Below is the text from 802.11REV-maD8.0 Clause 8.5.2, >>> describing the Key >>>> RSC field.: >>>> >>>> "g) Key RSC. This field is 8 octets in length. It contains >>> the receive >>>> sequence counter (RSC) for the >>>> GTK being installed in IEEE 802.11. It is used in Message 3 >>> of the 4-Way >>>> Handshake and >>>> Message 1 of the Group Key Handshake, where it is used to >>> synchronize >>>> the IEEE 802.11 replay >>>> state. It may also be used in the Michael MIC Failure >>> Report frame, to >>>> report the TSC field value of >>>> the frame experiencing a MIC failure. It shall contain 0 in other >>>> messages. The Key RSC field gives >>>> the current message number for the GTK, to allow a STA to identify >>>> replayed MPDUs. If the Key >>>> RSC field value is less than 8 octets in length, the >>> remaining octets >>>> shall be set to 0. The least significant >>>> octet of the TSC or PN should be in the first octet of the Key RSC >>>> field." >>>> >>>> The intent of adding this value in message 3 was to >>> immediately minimize >>>> the number of >>>> replayed frames that a STA would potentially process: "The >>> Key RSC field >>>> gives >>>> the current message number for the GTK, to allow a STA to identify >>>> replayed MPDUs." >>>> Setting the value to 0 in Msg 3 does not provide the >>> current sequence >>>> counter (in most cases >>>> not even close) of the GTK.. >>>> >>>> Perhaps the WTP could periodically/frequently notify the AC of its >>>> current GTK sequence counter, and the >>>> AC would use the most recently received value in the >>> message 3 sent to >>>> new STAs. The RSC value >>>> would not be up to date at all times, but would be closer >>> than "0", not >>>> require an "in-the-critical-path >>>> message exchange between the AC and WTP, and still be close to the >>>> intended use of the field. >>>> >>>> Dorothy >>>> >>>> >>>> On 9/28/06, Bob O'Hara (boohara) wrote: >>>> >>>> Please understand that 802.11i specifies no behavior in >>> this area for >>>> the 802.1X authenticator. Our choice to send a group key >>> KeyRSC value >>>> of zero in the EAPOL-key frame requires no change to 802.11i or to >>>> 802.1X . It requires us to state this in the CAPWAP spec, >>> if we want >>>> this behavior to be consistent across all implementations. >>>> >>>> The problem with what Bechet and Saranavan are asking is >>> that either of >>>> three different things are required: >>>> 1: the WTP must communicate the group key TSC to the AC >>> every time it is >>>> updated, or >>>> 2: the AC must request the current value of the group key >>> TSC for the >>>> KeyRSC before constructing the EAPOL-key frame, or >>>> 3: the AC must send the KCK to the AC so that it can >>> insert the KeyRSC >>>> value and also calculate the correct MIC, inserting that >>> into the proper >>>> EAPOL-key frame. >>>> >>>> The first item requires a tremendous amount of additional CAPWAP >>>> communication between WTP and AC, at least one new CAPWAP packet for >>>> every multicast frame sent by the WTP, if the packet is not >>>> acknowledged, or two new CAPWAP packets, if it is >>> acknowledged. This is >>>> a very expensive addition to the protocol. >>>> >>>> The second item requires new protocol between the AC and >>> WTP during what >>>> can be a time critical portion of the 802.11 transition >>> (handoff, roam) >>>> from one WTP to another. It also introduces a race >>> condition that is >>>> not present in the protocol today. Once the value for the KeyRSC is >>>> sent from the WTP to the AC, it is possible that the WTP can send >>>> another multicast frame encrypted with the group key. This puts the >>>> value of the sequence counter out of sync with the value >>> that will be >>>> shortly communicated to the client in the EAPOL-key frame >>> from the AC. >>>> This will behave exactly the same as if a value of zero is >>> sent in the >>>> EAPOL-key frame. >>>> >>>> The third item requires a new architecture split that is >>> not required in >>>> >>>> our objectives. The new split is not splitting the MAC, >>> but splitting >>>> the authenticator. Placing the KCK in the WTP is also a potential >>>> reduction in the security of the overall WLAN system, since these >>>> devices are normally not in a secured wiring closet, but exposed and >>>> more easily compromised than the AC. >>>> >>>> The simplest to implement, least expensive, and most secure >>> option is to >>>> use the protocol as it is now specified and have the AC >>> send a value of >>>> zero in the KeyRSC field of the EAPOL-key frame. >>>> >>>> -Bob >>>> >>>> -----Original Message----- >>>> From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] >>>> Sent: Wednesday, September 27, 2006 6:50 PM >>>> To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy; >>>> Peter Nilsson J (LI/EAB) >>>> Cc: capwap@frascone.com >>>> Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i >>> Considerations >>>> >>>> Hi Pat and all, >>>> >>>> So, based on this, I would say that we have consensus that >>> setting the >>>> correct KeyRSC is an issue for the CAPWAP protocol design. >>>> >>>> So far, we have three option/solutions: >>>> >>>> 1) As proposed by Bob: Using a static value (0) for the KeyRSC. >>>> >>>> 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP >>>> >>>> 3) As suggested by Saravanana: Some exchange mechanism >>> between WTP and >>>> AC >>>> >>>> Among the three, the first option seems the easiest. However, it >>>> requires a mandated Authenticator behavior(in this case AC) >>> that is not >>>> mandated by 802.11. Therefore, we have to specify that >>> (e.g. as proposed >>>> by Bob: "We could include a note to the effect that the group KeyRSC >>>> should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11, >>>> because otherwise there is no interoperability. For >>> example, AC provided >>>> by another vendor does not have to set KeyRSC to 0 to be >>> compliant with >>>> CAPWAP and 802.11i. >>>> >>>> Another implication is that we don't really understand the impact of >>>> mandating a static KeyRSC value. Although Bob provided an excellent >>>> analysis, I still have some doubts about the profoundness >>> of the impact. >>>> If the KeyRSC value is as described of no use, why would it >>> appear in >>>> the EAPOL frames in the first place? By mandating it to >>> static value, >>>> what have we lost? Maybe some liaison letter to 802.1 or >>> 802.11 could >>>> provide us a better understanding of the issue. >>>> >>>> For the last two options, I think they are both within >>> CAPWAP's scope. >>>> Further analysis could help us to decide which one is better (or >>>> someone could propose other solutions). >>>> >>>> cheers >>>> >>>> Cheng Hong >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com] >>>>> Sent: Thursday, September 28, 2006 1:39 AM >>>>> To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; >>>>> Peter Nilsson J (LI/EAB) >>>>> Cc: capwap@frascone.com >>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>>> Considerations >>>>> >>>>> Bob's point is 802.11i works this way today. The AP (or in >>>>> this case AC) can set the RSC to whatever value it wishes. >>>>> Bob used zero (0) as an example. Implementations could use >>>>> any other value, which would require some form of >>>>> communication to the WTP, as suggested by Behcet. >>>>> >>>>> Pat Calhoun >>>>> CTO, Wireless Networking Business Unit >>>>> Cisco Systems >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Cheng Hong [mailto: >>>> Hong.Cheng@sg.panasonic.com] >>>>>> Sent: Tuesday, September 26, 2006 6:03 PM >>>>>> To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson >>>>> J (LI/EAB) >>>>>> Cc: capwap@frascone.com >>>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>>>> Considerations >>>>>> >>>>>> Hi Bob, >>>>>> >>>>>> If I understand your description below correct, you are >>> proposing a >>>>>> solution (to the problem pointed out by >>>>>> Saravanan) by mandating the behavior of the AC to always set the >>>>>> KeyRSC in the 4-way handshake to zero. >>>>>> >>>>>> This is not a defined behavior according to the current >>>>>> 802.11 standard. >>>>>> Are you suggesting that we CAPWAP WG should specifically >>>>> mandate that >>>>>> in our CAPWAP protocol spec, e.g. something like "a CAPWAP >>>>> compatible >>>>>> AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, >>>>>> since not all AC implementation have to follow what you described. >>>>>> >>>>>> Or, are you planning to take this issue to TGm for 802.11 standard >>>>>> revision? (since based on your description, there is >>> essentially no >>>>>> use of the KeyRSC). >>>>>> >>>>>> cheers >>>>>> >>>>>> Cheng Hong >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] >>>>>>> Sent: Wednesday, September 27, 2006 2:32 AM >>>>>>> To: T. Charles Clancy; Peter Nilsson J (LI/EAB) >>>>>>> Cc: capwap@frascone.com >>>>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>>>>> Considerations >>>>>>> >>>>>>> Charles, Peter, >>>>>>> >>>>>>> Below is an expansion of a snippet from a thread on this >>>>>> topic that I >>>>>>> sent to the list on July 25, 2006. I think this will be >>>>> helpful to >>>>>>> understand why the exchange that Saranavan is requesting is not >>>>>>> necessary. In fact, there are several systems from several >>>>>>> manufacturers in the field using precursor protocols to >>>>> CAPWAP that >>>>>>> are Wi-Fi certified for WPA2/802.11i operation using the >>>>>> protocol as >>>>>>> it is described below. >>>>>>> >>>>>>> BTW, this whole discussion is about the KeyRSC for the >>>>>> group key, not >>>>>>> the pairwise key. This is so because the WTP and AC both >>>>> know the >>>>>>> initial sequence counter value for the pairwise key, since it has >>>>>>> never been used to send a frame. 802.11i requires the >>>>> first frame >>>>>>> sent on a key to use the sequence counter value of 1. See >>>>>> 8.3.2.6 c) >>>>>>> and >>>>>>> 8.3.3.4.3 c) in 802.11i for this requirement. >>>>>>> >>>>>>> The same is not true of the group key, i.e., after the WTP begins >>>>>>> operation, the AC will not know the value of the sequence >>>>>> counter for >>>>>>> the group key when it needs to complete the EAPOL-key >>>>>> handshake with a >>>>>>> newly associated STA. >>>>>>> However, as you will see from the tutorial below, it is not >>>>>> necessary >>>>>>> for the AC and WTP to exchange any information about the >>>>> group key >>>>>>> KeyRSC for the protocol to operate as it is intended. >>>>>>> >>>>>>> 1. A value for the KeyRSC in the EAPOL-key frame 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. A value of zero in the >>>>> EAPOL-key >>>>>>> frame for the group key will always work. >>>>>>> >>>>>>> 3. The client STA will use the value of KeyRSC received in the >>>>>>> EAPOL-key frame to validate frame using the KeyMIC. >>>>>>> >>>>>>> 4. The client STA will also set its group key RSC to the value >>>>>>> received in KeyRSC, say, zero. >>>>>>> >>>>>>> 5. The value in the client STA's RSC will be compared against the >>>>>>> sequence number in subsequent received frames to identify replay >>>>>>> attacks. Any frame received with a sequence counter value >>>>>> within the >>>>>>> replay window will be checked to have a valid MIC. If the >>>>>> MIC is not >>>>>>> valid, the frame is dropped. >>>>>>> >>>>>>> 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, if the value is greater than its current RSC value. >>>>>> Only the >>>>>>> AP can meet these criteria as the source of a frame >>>>> received by the >>>>>>> STA. >>>>>>> >>>>>>> 7. Please see item 6, immediately above, for the reason >>>>> that the AC >>>>>>> and WTP do not need to coordinate and exchange the RSC. >>>>>>> >>>>>>> >>>>>>> The only possible attack mode is for the attacker to send >>>>> frames to >>>>>>> the client STA between the time of the EAPOL-key frame and >>>>>> the first >>>>>>> frame encrypted with the group key. >>>>>>> During this time, the client will receive the frame and >>>>> proceed to >>>>>>> validate its MIC. This is a potential attack against the STA >>>>>>> resources. But, the MIC validation is done in the STA's >>>>>>> 802.11 chip and consumes no more resources than receiving >>>>> any other >>>>>>> frame. Thus, the attack does not actually consume any STA >>>>>> resources >>>>>>> beyond those of receiving a frame. >>>>>>> >>>>>>> This attack is not unique to the use of the value zero for >>>>>> the KeyRSC, >>>>>>> either. The same attack is available to an attacker at any other >>>>>>> time, as well. It is no more nor less effective at either time. >>>>>>> >>>>>>> For these reasons, the protocol is not in need of any changes to >>>>>>> address the issue raised by Saranavan. >>>>>>> >>>>>>> -Bob >>>>>>> -----Original Message----- >>>>>>> From: T. Charles Clancy [mailto:clancy@cs.umd.edu] >>>>>>> Sent: Monday, September 25, 2006 11:37 AM >>>>>>> To: Peter Nilsson J (LI/EAB) >>>>>>> Cc: capwap@frascone.com >>>>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>>>>> Considerations >>>>>>> >>>>>>> This is a very interesting solution. The AC selects the >>>>> KeyRSC and >>>>>>> performs the 4-way handshake. The WTP sniffs the 4-way handshake >>>>>>> traffic and grabs the KeyRSC value and uses it to >>>>>> initialize its own >>>>>>> counter. >>>>>>> >>>>>>> Pat/Bob: Is this how the Cisco implementation works? I >>>>>> have to agree >>>>>>> with Saravanan that I've yet to see a technical >>>>> description of how >>>>>>> Cisco implements it. >>>>>>> >>>>>>> IMHO, this is somewhat hackish, and it would be cleaner to >>>>>> have the AC >>>>>>> generate the KeyRSC and include it in the AddMobile message >>>>>> as Behcet >>>>>>> suggests. >>>>>>> >>>>>>> -- >>>>>>> t. charles clancy, ph.d. | tcc@umd.edu | >>>>> www.cs.umd.edu/~clancy >>>>>>> >>>>>>> On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: >>>>>>> >>>>>>>> I think Saravanan has a point. We did a prototype >>>>>> impelementation of >>>>>>> the >>>>>>>> protocol a year ago when it was still called LWAPP. The way >>>>>>> we solved >>>>>>>> this issue then was to let the WTP sniff on all CAPWAP data >>>>>>> messages >>>>>>>> from the AC and when message 3 of the 4-way handshake or >>>>>>> message 1 of >>>>>>>> the groupkey handshake was sent the WTP inserted the correct RSC >>>>>>> before >>>>>>>> sending it off to the supplicant. To avoid the sniffing on >>>>>>> all CAPWAP >>>>>>>> data messages we would need a mechanism with in CAPWAP to >>>>>>> handle these >>>>>>>> two messages. >>>>>>>> >>>>>>>> Peter Nilsson >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Saravanan Govindan >>>>>>> [mailto:Saravanan.Govindan@sg.panasonic.com] >>>>>>>> Sent: den 22 september 2006 11:03 >>>>>>>> To: Margaret Wasserman >>>>>>>> Cc: capwap@frascone.com >>>>>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>>>>> Considerations >>>>>>>> >>>>>>>> Hi Margaret, >>>>>>>> >>>>>>>> Thank you for reviewing the discussion on this issue. >>>>>>>> >>>>>>>> The issue here is the working of IEEE 802.11i when the 802.11i >>>>>>>> authenticator element is at the AC and the 802.11i crypto >>>>>> element is >>>>>>> at >>>>>>>> the WTP. Particularly, it is for the 4-way handshake between >>>>>>>> authenticator and supplicant. >>>>>>>> >>>>>>>> Now, the 4-way handshake requires knowing the value of >>>>>>> KeyRSC sequence >>>>>>>> counter. The KeyRSC helps both authenticator and supplicant >>>>>>> keep track >>>>>>>> of their exchanges. It serves to protect against threats by >>>>>>> tracking >>>>>>>> sequential frames. The KeyRSC is maintained at the at the >>>>>> point of >>>>>>>> encryption, i.e. just before transmission over the >>>>>> wireless channel. >>>>>>>> >>>>>>>> In the case of CAPWAP, the 4-way handshake is between the AC >>>>>>>> (authenticator) and the wireless station (supplicant). >>>>>>>> >>>>>>>> The problem arises, when the authenticator is at the AC and >>>>>>> the crypto >>>>>>>> element (together with KeyRSC) is at the WTP. This is a >>>>>>> fairly common >>>>>>>> design. Now in this case, the AC starts the 4-way >>>>> handshake but it >>>>>>> does >>>>>>>> not know the value of the KeyRSC. The KeyRSC is maintained >>>>>>> by the WTP. >>>>>>>> >>>>>>>> Based on this, the current CAPWAP specification does not >>>>>> allow for a >>>>>>> way >>>>>>>> to conduct the 4-way handshake with the correct KeyRSC. >>>>>>>> >>>>>>>> The functionality I would like to see is a way for the >>>>>> authenticator >>>>>>>> (AC) to use the correct prevailing value of KeyRSC >>>>>>> (maintained by the >>>>>>>> WTP) in its 4-way handshake. >>>>>>>> >>>>>>>> One way to introduce this functionality in to CAPWAP is >>>>>> to have part >>>>>>> of >>>>>>>> the 4-way handshake be sent from AC to WTP. This will allow >>>>>>> the 4-way >>>>>>>> handshake to use the correct value of the KeyRSC before >>>>>>> being sent to >>>>>>>> the wireless station. >>>>>>>> >>>>>>>> I hope this helps clarify my view on the issue. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Saravanan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Margaret Wasserman [mailto:margaret@thingmagic.com] >>>>>>>> Sent: Thursday, September 21, 2006 8:26 PM >>>>>>>> To: Saravanan Govindan >>>>>>>> Cc: Pat Calhoun (pacalhou); capwap@frascone.com >>>>>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>>>>> Considerations >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi again, >>>>>>>> >>>>>>>> Okay, I am even more confused than I thought I was... >>>>>>>> >>>>>>>> Saravanan, you wrote: >>>>>>>> >>>>>>>> On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: >>>>>>>> >>>>>>>>> Pat, >>>>>>>>> >>>>>>>>> The issue here is about how 802.11i exchanges are done when >>>>>>>>> authenticator is at the AC and crypto elements are at >>>>>> the WTP. This >>>>>>> is >>>>>>>>> the requirement. >>>>>>>> >>>>>>>> And, in response, Pat Calhoun wrote: >>>>>>>> >>>>>>>> On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: >>>>>>>>> The current specification allows the authenticator to >>>>>>> reside in the >>>>>>>>> AC, while the data packet crypto elements in the WTP. This >>>>>>> feature is >>>>>>>>> already in the specification. >>>>>>>> >>>>>>>> Pat's message matches my reading of the specification. >>>>>>>> >>>>>>>> So, Saravanan, what functionality are you asking for >>>>> that is not >>>>>>>> already supported by the specification? And why do you >>>>>> think it is >>>>>>>> necessary? it will not be helpful to my understanding to >>>>>>> re-send your >>>>>>>> proposal or to cite the requirements document... Please >>>>>> summarize >>>>>>>> what functionality you think is missing from the current >>>>>>> specification >>>>>>>> and why you think that functionality is necessary to >>>>> support IEEE >>>>>>>> 802.11i or any important use case. >>>>>>>> >>>>>>>> At some point, the chairs may need to make a consensus >>>>>> call on this >>>>>>>> issue, and I'd like to understand your view and make sure >>>>>>> that it has >>>>>>>> been clearly communicated to the WG before we ask the WG to >>>>>>> decide on >>>>>>>> this issue. >>>>>>>> >>>>>>>> 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 >>>>>>>> >>>>> _________________________________________________________________ >>>>>>>> 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 >>>>>>> >>>>>> _________________________________________________________________ >>>>>> 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 >>>> >>>> >>>> >>>> >>> >> _________________________________________________________________ >> 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