From xml-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 1 05:40:19 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B2EE3A6BF8 for ; Tue, 1 Jul 2008 05:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHcFJElrqRJf for ; Tue, 1 Jul 2008 05:40:18 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 9B1803A6CE0 for ; Tue, 1 Jul 2008 05:30:43 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B40B9430650 for ; Tue, 1 Jul 2008 05:30:54 -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: xml-owner@frascone.com X-No-Archive: yes Message-ID: Date: Tue, 01 Jul 2008 05:30:18 -0700 Precedence: bulk X-BeenThere: xml@frascone.com X-Mailman-Version: 2.1.9 List-Id: Diameter XML Dictionary Design Team List -- CLOSED -- ARCHIVES ONLY X-List-Administrivia: yes To: capwap-archive@lists.ietf.org Errors-To: xml-bounces+capwap-archive=lists.ietf.org@frascone.com 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, xml-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 Tue Jul 1 11:43:41 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F4013A6BB8 for ; Tue, 1 Jul 2008 11:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXKs1GCZtRfW for ; Tue, 1 Jul 2008 11:43:40 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 538733A6BB7 for ; Tue, 1 Jul 2008 11:43:40 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2E18C1C40F85 for ; Tue, 1 Jul 2008 11:43:51 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 420A4440121 for ; Tue, 1 Jul 2008 11:43:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id CFE6334AC017 for ; Tue, 1 Jul 2008 11:43:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 40A1C3808025 for ; Tue, 1 Jul 2008 11:43:40 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 1 Jul 2008 11:43:40 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so17976wfc.11 for ; Tue, 01 Jul 2008 11:43:40 -0700 (PDT) Received: by 10.142.213.10 with SMTP id l10mr2195219wfg.163.1214937819983; Tue, 01 Jul 2008 11:43:39 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Tue, 1 Jul 2008 11:43:39 -0700 (PDT) Message-ID: Date: Tue, 1 Jul 2008 11:43:39 -0700 From: "Yong Zhang" To: capwap@frascone.com MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [Capwap] New Issue 134: Image Data to Reset state machine 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 This change is OK for me. Yong Message: 2 Date: Mon, 30 Jun 2008 10:25:57 -0700 From: "Pat Calhoun (pacalhou)" Subject: [Capwap] New Issue 134: Image Data to Reset state machine issue To: Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20607B53C@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset="us-ascii" All, Yong has raised an issue to me privately that needs to be addressed in the base spec. Basically, the state machine transition from the Image Data to Reset state does not include a case where it occurs when the image was successfully transferred. I believe most (if not all) implementors would have done the right thing, but it is a good idea to be specific. The new text is: Image Data to Reset (k): This state transition is used to reset the DTLS connection prior to restarting the WTP after an image download. [...] AC: The AC enters the Reset state either when the image transfer has successfully completed, an error occurs during the image download process or if the ImageDataStartTimer timer expires. 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 Jul 1 11:45:57 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B31843A6BBD for ; Tue, 1 Jul 2008 11:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XsO4uA6A4-9 for ; Tue, 1 Jul 2008 11:45:56 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 6978B3A6BB6 for ; Tue, 1 Jul 2008 11:45:56 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7C7711C40F57 for ; Tue, 1 Jul 2008 11:46:06 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 8DF26440121 for ; Tue, 1 Jul 2008 11:45:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id F37D03808055 for ; Tue, 1 Jul 2008 11:45:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3AFB3380806E for ; Tue, 1 Jul 2008 11:45:29 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from yx-out-1718.google.com (yx-out-1718.google.com [74.125.44.152]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 1 Jul 2008 11:45:28 -0700 (PDT) Received: by yx-out-1718.google.com with SMTP id 3so5936yxi.80 for ; Tue, 01 Jul 2008 11:45:28 -0700 (PDT) Received: by 10.142.158.17 with SMTP id g17mr2627063wfe.24.1214937927831; Tue, 01 Jul 2008 11:45:27 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Tue, 1 Jul 2008 11:45:27 -0700 (PDT) Message-ID: Date: Tue, 1 Jul 2008 11:45:27 -0700 From: "Yong Zhang" To: capwap@frascone.com MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [Capwap] New issue 135: Incorrect Reset to DTLS Teardown state transition 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 This change is OK for me. Yong ----------------------------- Message: 3 Date: Mon, 30 Jun 2008 10:26:33 -0700 From: "Pat Calhoun (pacalhou)" Subject: [Capwap] New issue 135: Incorrect Reset to DTLS Teardown state transition To: Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20607B53E@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset="us-ascii" All, Yong raised an issue to me privately where the state transition is currently incorrect as it states that the WTP receives the Reset Response, while it should be the AC. So while changing the text, I needed to make a change to make sure that the AC is the one that initiates the DTLSShutdown when it receives the Reset Response. This would avoid a race condition where both the WTP and the AC attempt to shutdown the session at the same time, and it also ensures that the orderly cleanup occurs after the AC has received the Reset Response. The new text is: Reset to DTLS Teardown (s): This transition occurs when the CAPWAP reset is complete, to terminate the DTLS session. WTP: This state transition occurs when the WTP transmits a Reset Response message. The WTP does not invoke the DTLSShutdown command (see Section 2.3.2.1). AC: This state transition occurs when the AC Receives a Reset Response message. This causes the AC to initiate the DTLSShutdown command (see Section 2.3.2.1). 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 Jul 1 11:48:26 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1873A6BA3 for ; Tue, 1 Jul 2008 11:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRBoWpNrnDO3 for ; Tue, 1 Jul 2008 11:48:25 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 1A9353A6994 for ; Tue, 1 Jul 2008 11:48:25 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 00A0E1C40F52 for ; Tue, 1 Jul 2008 11:48:36 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 69D5E440121 for ; Tue, 1 Jul 2008 11:47:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 861103708004 for ; Tue, 1 Jul 2008 11:47:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5E75B380804C for ; Tue, 1 Jul 2008 11:47:19 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from yx-out-1718.google.com (yx-out-1718.google.com [74.125.44.157]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 1 Jul 2008 11:47:18 -0700 (PDT) Received: by yx-out-1718.google.com with SMTP id 3so6283yxi.80 for ; Tue, 01 Jul 2008 11:47:18 -0700 (PDT) Received: by 10.142.180.11 with SMTP id c11mr2611877wff.159.1214938037715; Tue, 01 Jul 2008 11:47:17 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Tue, 1 Jul 2008 11:47:17 -0700 (PDT) Message-ID: Date: Tue, 1 Jul 2008 11:47:17 -0700 From: "Yong Zhang" To: capwap@frascone.com MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [Capwap] New Issue 136: The AC State Machine never gets from Join to Image 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 This change is OK for me. Yong ------------------------------ Message: 4 Date: Mon, 30 Jun 2008 17:17:02 -0700 From: "Pat Calhoun (pacalhou)" Subject: [Capwap] New Issue 136: The AC State Machine never gets from Join to Image Data To: "Yong Zhang" , Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20607B86F@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset="us-ascii" Interesting catch. Yes, you are correct that the text was misleading, and required one to guess. This does need to be fixed, and I've created a new issue 136 to deal with it. The approach you propose is a reasonable one, but it uncovered another issue which is that the ChangeStatePendingTimer was never stopped, which is a bug, so I have fixed that as well. The new text would look like: Join to Configure (g): This state transition is used by the WTP and the AC to exchange configuration information. [...] AC: This state transition occurs when it receives the Configuration Status message from the WTP (see Section 8.2), which MAY include specific message elements to override the WTP's configuration. The AC transmits the Configuration Status Response message (see Section 8.3) and starts the ChangeStatePendingTimer timer (see Section 4.7). Configure to Data Check (m): This state transition occurs when the WTP and AC confirm the configuration. [...] AC: This state transition occurs when the AC receives the Change State Event Request message (see Section 8.6) from the WTP. The AC responds with a Change State Event Response message (see Section 8.7). The AC MUST start the DataCheckTimer timer and stops the ChangeStatePendingTimer timer (see Section 4.7). 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 Jul 1 13:02:48 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6093A6BA1 for ; Tue, 1 Jul 2008 13:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qr9Tsurk3WMg for ; Tue, 1 Jul 2008 13:02:47 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 61EBA3A67A2 for ; Tue, 1 Jul 2008 13:02:47 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3F15B43A031 for ; Tue, 1 Jul 2008 13:02:58 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 50AD8440124 for ; Tue, 1 Jul 2008 13:02:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id F1604370801B for ; Tue, 1 Jul 2008 13:02:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 36F4434AC08B for ; Tue, 1 Jul 2008 13:02:43 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 1 Jul 2008 13:02:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,732,1204531200"; d="scan'208";a="47377268" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 01 Jul 2008 13:02:42 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m61K2gKN001953 for ; Tue, 1 Jul 2008 13:02:42 -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.13.8/8.13.8) with ESMTP id m61K2ghl027045 for ; Tue, 1 Jul 2008 20:02:42 GMT 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, 1 Jul 2008 13:02:42 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Jul 2008 13:02:27 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20607BBDC@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Issue 137: ResponseTimeout is unnecessary Thread-Index: AcjbtWLgwrOkbOm0RLSvl3p4YB5tOQ== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 01 Jul 2008 20:02:42.0481 (UTC) FILETIME=[6BD60210:01C8DBB5] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Capwap] New Issue 137: ResponseTimeout 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 All, Yong has raised another issue to me privately, for which I have created Issue 137. Somehow when we transitioned to the new retransmission scheme, the ResponseTimeout timer was never removed from the draft. There is one mention of the timer being started in the FSM, but there is no mention of what happens when the timer expires - because it is not used. I would recommend removing the ResponseTimeout timer, as well as the reference in the "Join to Configure" state transition. Comments? 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 Jul 1 13:06:08 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A46E03A6BAD for ; Tue, 1 Jul 2008 13:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6Fu4cPqoiYx for ; Tue, 1 Jul 2008 13:06:07 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D94CD3A6BA1 for ; Tue, 1 Jul 2008 13:06:07 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B42141C40FA5 for ; Tue, 1 Jul 2008 13:06:18 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 9F5C8440124 for ; Tue, 1 Jul 2008 13:06:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E1C6934AC09D for ; Tue, 1 Jul 2008 13:05:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id DF18434AC072 for ; Tue, 1 Jul 2008 13:05:46 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 1 Jul 2008 13:05:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,732,1204531200"; d="scan'208";a="47379186" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 01 Jul 2008 13:05:46 -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/8.12.11) with ESMTP id m61K5jMK007410 for ; Tue, 1 Jul 2008 13:05:45 -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.13.8/8.13.8) with ESMTP id m61K5jIl024819 for ; Tue, 1 Jul 2008 20:05:45 GMT 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.1830); Tue, 1 Jul 2008 13:05:45 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Jul 2008 13:05:14 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20607BBDF@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Issue 138: Inconsistent values for enable/disable in section 4.6.34 Thread-Index: AcjbtcZDN2lw9BmyRcKD+Y8/XHhdgA== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 01 Jul 2008 20:05:45.0747 (UTC) FILETIME=[D9122E30:01C8DBB5] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Capwap] New Issue 138: Inconsistent values for enable/disable in section 4.6.34 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 All, Yong has raised another issue, but I'm not sure that this one will have the required consensus as it will break compatibility with existing implementations that conform to -10. Section 4.6.34 uses 1 for disable and 2 for enable, while the rest of the spec uses the inverse. This inconsistency could be confusing for people using #DEFINEs. Is there agreement to inversing these values, with the understanding that it would create a backward compatibility issue with -10? 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 Jul 1 13:37:38 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17443A6BD3 for ; Tue, 1 Jul 2008 13:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0p-BSNqT0ie for ; Tue, 1 Jul 2008 13:37:33 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 8D77C3A6784 for ; Tue, 1 Jul 2008 13:37:33 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 714301751996 for ; Tue, 1 Jul 2008 13:37:44 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 6CA35440159 for ; Tue, 1 Jul 2008 13:37:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3954E3808010 for ; Tue, 1 Jul 2008 13:37:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id EE16A3808027 for ; Tue, 1 Jul 2008 13:36:42 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.158]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 1 Jul 2008 13:36:32 -0700 (PDT) Received: by yw-out-1718.google.com with SMTP id 6so13159ywa.80 for ; Tue, 01 Jul 2008 13:36:31 -0700 (PDT) Received: by 10.142.166.1 with SMTP id o1mr2647558wfe.345.1214944590392; Tue, 01 Jul 2008 13:36:30 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Tue, 1 Jul 2008 13:36:30 -0700 (PDT) Message-ID: Date: Tue, 1 Jul 2008 13:36:30 -0700 From: "Yong Zhang" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A205FDD776@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <4FF84B0BC277FF45AA27FE969DD956A205F5CDE6@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A205FDD776@xmb-sjc-235.amer.cisco.com> Cc: capwap@frascone.com Subject: Re: [Capwap] New Issue 106: WaitJoin may be 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 This change is OK for me. Yong On Thu, Jun 26, 2008 at 4:53 AM, Pat Calhoun (pacalhou) wrote: > I believe you may be correct that there is a technical issue. > > Originally, the WaitJoin was used to timeout if the WTP did not sent the > Join Request, or the AC did not send the Join Response. However, when > DTLS was introduced, we started to rely on the WaitDTLS timer. It seems > like we've started to rely much more on the WaitDTLS timer in the latter > drafts, to the point where I believe that we could simply remove the > WaitJoin timer and have little impact to the state machine. > > From what I can tell, the "Join to DTLS Teardown (e)" state transition > currently triggers if the WaitJoin timer expires, and we would have to > change this to WaitDTLS instead. Further, the "DTLS Connect to Join (d)" > state transition would simply need to have its reference to WaitJoin > removed. > > So since it appears as if the WaitDTLS timers are initialized properly, > the timeout triggers are properly defined, and it is well specified in > its handling during the Join Request/Response in section 6.1 and 6.2, > this change would have mimimal impact. > > Thoughts? > > PatC > > -----Original Message----- > From: Yong Zhang [mailto:yozhang@gmail.com] > Sent: Friday, June 20, 2008 11:19 AM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: Re: [Capwap] WaitDTLS/WaitJoin timers > indraft-ietf-capwap-protocol-specification-10.txt > > This info is clear. But in the spec., the WaitDTLS covers the WaitJoin. > WairDTLS timer is not cleared after the DTLS session is esatblished, but > it is only cleared after the Join REQ/RESP are received. (6.1/2 > describes this). > > Thanks! > > Yong > > On Fri, Jun 20, 2008 at 10:55 AM, Pat Calhoun (pacalhou) > wrote: >> The intent for both timers is: >> >> WaitDTLS: This timer is used to make sure that the DTLS session is >> established within the required timeframe. If the DTLS session isn't >> setup, perhaps because either party is not responding, then the timer >> will trigger and the state will change. >> >> WaitJoin: Once the DTLS session has been established, we need to >> protect against a WTP that opts to NOT send a Join Request. So in this > >> instance, the WaitJoin would trigger, and the state would once more > change. >> >> PatC >> >> -----Original Message----- >> From: Yong Zhang [mailto:yozhang@gmail.com] >> Sent: Friday, June 20, 2008 9:54 AM >> To: capwap@frascone.com >> Subject: [Capwap] WaitDTLS/WaitJoin timers >> indraft-ietf-capwap-protocol-specification-10.txt >> >> WaitDTLS by its name should be DTLS session setup related, but this >> spec. (6.1/2) requires it deactivated after the Join Req/Resp are >> received. >> >> WaitJoin seems no use in this case?? >> >> Also the WaitDTLS timer is started earlier than WaitJoin timer, >> however, the default value for these two timers (4.7.15/16) are all >> 60s. if WaitJoin has some other use, it need to have a less value than > >> WaitDTLS to work. >> >> Yong >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap >> > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 1 13:39:13 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30B203A6784 for ; Tue, 1 Jul 2008 13:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWSEJCzfHVKj for ; Tue, 1 Jul 2008 13:39:12 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 430743A6994 for ; Tue, 1 Jul 2008 13:39:12 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 28F5E1C4048A for ; Tue, 1 Jul 2008 13:39:23 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 410E944015E for ; Tue, 1 Jul 2008 13:39:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id A2E333708039 for ; Tue, 1 Jul 2008 13:39:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 695BF380802C for ; Tue, 1 Jul 2008 13:37:52 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.158]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 1 Jul 2008 13:37:52 -0700 (PDT) Received: by yw-out-1718.google.com with SMTP id 6so13320ywa.80 for ; Tue, 01 Jul 2008 13:37:43 -0700 (PDT) Received: by 10.142.254.8 with SMTP id b8mr2668789wfi.58.1214944663062; Tue, 01 Jul 2008 13:37:43 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Tue, 1 Jul 2008 13:37:43 -0700 (PDT) Message-ID: Date: Tue, 1 Jul 2008 13:37:43 -0700 From: "Yong Zhang" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A205FDD77A@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <4FF84B0BC277FF45AA27FE969DD956A205FDD77A@xmb-sjc-235.amer.cisco.com> Cc: capwap@frascone.com Subject: Re: [Capwap] New Issue 107: ImageDataStartTimer is not specified correctly 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 This change is OK for me. Yong On Thu, Jun 26, 2008 at 5:11 AM, Pat Calhoun (pacalhou) wrote: > Yes, I believe you are once again correct. The issue was created when > the Image Data Request/Response became bi-directional, and the timers > were not adjusted correctly. The proper fix is, I believe, to make use > of the timer on both the AC and the WTP: > > > 2.3. CAPWAP State Machine Definition > [...] > Image Data to Image Data (j): The Image Data state is used by the > WTP and the AC during the firmware download phase. > > WTP: The WTP enters the Image Data state when it receives an > Image Data Response message indicating that the AC has more > data to send. This state transition also occurs when the WTP > receives the subsequent Image Data Requests, at which time it > resets the ImageDataStartTimer time to ensure it receives the > next expected Image Data Request from the AC. > > AC: This state transition occurs when the AC receives the Image > Data Response message from the WTP while already in the Image > Data state. The AC disables the ImageDataStartTimer timer. > > Image Data to Reset (k): This state transition is used to reset the > DTLS connection prior to restarting the WTP after an image > download. > > WTP: When an image download completes, or if the > ImageDataStartTimer timer expires, the WTP enters the Reset > state. The WTP MAY also transition to this state upon > receiving an Image Data Response message from the AC (see > Section 9.1.2) indicating a failure. > > AC: The AC enters the Reset state when an error occurs during the > image download process or if the ImageDataStartTimer timer > expires. > > 4.7.8. ImageDataStartTimer > > The number of seconds the AC or WTP will wait for its peer to > transmit the > Image Data Request. > > > PatC > -----Original Message----- > From: Yong Zhang [mailto:yozhang@gmail.com] > Sent: Monday, June 23, 2008 11:15 AM > To: capwap@frascone.com > Subject: [Capwap] ImageDataStartTimer > indraft-ietf-capwap-protocol-specification-10.txt > > I have a question on this ImageDataStartTimer. What's the purpose of it? > > Is it used to define the AC waiting time for the first WTP image data > req after it sends the join resp? After the first image data req is > received from WTP, this timer will be no use any more after the AC > start image data push to WTP? > > Refer to figure 4/6 in chapter 9, the WTP will only send the first image > data req message, then it will receive image data req from AC, and reply > with image data resp. > > Page 24 Join to Image Data (f): AC: ImageDataStartTimer is started after > the AC receives the Image Data Request message from the WTP > > Page 25 Image Data to Image Data (j):AC This state transition occurs > when the AC receives the Image > Data Request message from the WTP while already in the Image > Data state. The AC resets the ImageDataStartTimer timer. > > Here you want to say the first Image data req from WTP, or the > image data response from WTP for AC's image data req? If it is the first > one, there is no image data req from WTP when the FSM is in Image Data > state. > > Reset timer is the timer to be restarted or canceled? > > Thanks! > > Yong > > > > > > In this spec., most of req messages are send by WTP. The image data req > is an exception, which is mainly used by AC. > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 1 13:44:45 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBB703A67A2 for ; Tue, 1 Jul 2008 13:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfOYOy18ui4r for ; Tue, 1 Jul 2008 13:44:45 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 143ED3A6994 for ; Tue, 1 Jul 2008 13:44:45 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D2E701C40F64 for ; Tue, 1 Jul 2008 13:44:55 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 9FF2D440157 for ; Tue, 1 Jul 2008 13:43:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 72FC83708004 for ; Tue, 1 Jul 2008 13:43:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 83F8E3708021 for ; Tue, 1 Jul 2008 13:43:35 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.155]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 1 Jul 2008 13:43:35 -0700 (PDT) Received: by yw-out-1718.google.com with SMTP id 6so14254ywa.80 for ; Tue, 01 Jul 2008 13:43:34 -0700 (PDT) Received: by 10.142.218.6 with SMTP id q6mr2674204wfg.19.1214945014069; Tue, 01 Jul 2008 13:43:34 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Tue, 1 Jul 2008 13:43:34 -0700 (PDT) Message-ID: Date: Tue, 1 Jul 2008 13:43:34 -0700 From: "Yong Zhang" To: capwap@frascone.com MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [Capwap] [capwap] New Issue 102: Join to Image Data state transition issue on 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 This changes for issue 102 and issue 136 are OK for me. Yong ---------- Forwarded message ---------- From: "Pat Calhoun (pacalhou)" To: Date: Wed, 18 Jun 2008 22:29:25 -0700 Subject: [Capwap] New Issue 102: Join to Image Data state transition issueon the AC The original issue stated: In page 24/25. it is said: AC: join -> image data happens when the AC receives the image data request from WTP. AC: join -> configure happens immediately after the AC transmits the join resp. Does the WTP only send the image data request after it receives the join resp? If so, the AC will not be able to go into the image data state. Did I miss something here? You raise a very real ommision in the text. I am making a change that has the least impact to the spec, and no impact to the state machine: 2.3. CAPWAP State Machine Definition [...] Join to Image Data (f): This state transition is used by the WTP and the AC to download executable firmware. [...] AC: This state transition occurs when the AC receives the Image Data Request message from the WTP, after having sent its Join Response to the WTP. The AC MUST transmit an Image Data Response message (see Section 9.1.2) to the WTP, which includes a portion of the firmware. The AC MUST start the ImageDataStartTimer timer (see Section 4.7). N _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 2 17:37:51 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52733A6A50 for ; Wed, 2 Jul 2008 17:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kf48Btv8xG0 for ; Wed, 2 Jul 2008 17:37:50 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D08DF3A6987 for ; Wed, 2 Jul 2008 17:37:50 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4AAC31C40FB1 for ; Wed, 2 Jul 2008 17:38:00 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 9954E44007E for ; Wed, 2 Jul 2008 17:37:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 743EA34AC08B for ; Wed, 2 Jul 2008 17:37:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0FB4434AC071 for ; Wed, 2 Jul 2008 17:37:49 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 2 Jul 2008 17:37:48 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so638071wfc.11 for ; Wed, 02 Jul 2008 17:37:48 -0700 (PDT) Received: by 10.142.171.6 with SMTP id t6mr3310413wfe.209.1215045468732; Wed, 02 Jul 2008 17:37:48 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Wed, 2 Jul 2008 17:37:48 -0700 (PDT) Message-ID: Date: Wed, 2 Jul 2008 17:37:48 -0700 From: "Yong Zhang" To: capwap@frascone.com MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [Capwap] New Issue 137: ResponseTimeout 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 This change is OK for me. Yong ------------------------------ Message: 4 Date: Tue, 1 Jul 2008 13:02:27 -0700 From: "Pat Calhoun (pacalhou)" Subject: [Capwap] New Issue 137: ResponseTimeout is unnecessary To: Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20607BBDC@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset="us-ascii" All, Yong has raised another issue to me privately, for which I have created Issue 137. Somehow when we transitioned to the new retransmission scheme, the ResponseTimeout timer was never removed from the draft. There is one mention of the timer being started in the FSM, but there is no mention of what happens when the timer expires - because it is not used. I would recommend removing the ResponseTimeout timer, as well as the reference in the "Join to Configure" state transition. Comments? 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 Wed Jul 2 17:39:15 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EF183A6A28 for ; Wed, 2 Jul 2008 17:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cS25ZHpBVuGw for ; Wed, 2 Jul 2008 17:39:14 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id A45573A6987 for ; Wed, 2 Jul 2008 17:39:14 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5987F1C40F94 for ; Wed, 2 Jul 2008 17:39:24 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 0D65A440102 for ; Wed, 2 Jul 2008 17:38:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C6BCA34AC092 for ; Wed, 2 Jul 2008 17:38:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id AFAD434AC084 for ; Wed, 2 Jul 2008 17:38:55 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 2 Jul 2008 17:38:55 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so638423wfc.11 for ; Wed, 02 Jul 2008 17:38:55 -0700 (PDT) Received: by 10.142.187.2 with SMTP id k2mr3323351wff.8.1215045535459; Wed, 02 Jul 2008 17:38:55 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Wed, 2 Jul 2008 17:38:55 -0700 (PDT) Message-ID: Date: Wed, 2 Jul 2008 17:38:55 -0700 From: "Yong Zhang" To: capwap@frascone.com MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [Capwap] New Issue 138: Inconsistent values for enable/disable in section 4.6.34 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 This change is OK for me. Yong ------------------------------ Message: 5 Date: Tue, 1 Jul 2008 13:05:14 -0700 From: "Pat Calhoun (pacalhou)" Subject: [Capwap] New Issue 138: Inconsistent values for enable/disable in section 4.6.34 To: Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20607BBDF@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset="us-ascii" All, Yong has raised another issue, but I'm not sure that this one will have the required consensus as it will break compatibility with existing implementations that conform to -10. Section 4.6.34 uses 1 for disable and 2 for enable, while the rest of the spec uses the inverse. This inconsistency could be confusing for people using #DEFINEs. Is there agreement to inversing these values, with the understanding that it would create a backward compatibility issue with -10? 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 Thu Jul 3 11:31:58 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDBE83A6D23 for ; Thu, 3 Jul 2008 11:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IljdXA6TTnVK for ; Thu, 3 Jul 2008 11:31:58 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 687F83A6AD8 for ; Thu, 3 Jul 2008 11:31:00 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 510651C40F8A for ; Thu, 3 Jul 2008 11:31:09 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id DD520440131 for ; Thu, 3 Jul 2008 11:30:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id B94FE34AC003 for ; Thu, 3 Jul 2008 11:30:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E0EAD34AC06A for ; Thu, 3 Jul 2008 11:30:57 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from yx-out-1718.google.com (yx-out-1718.google.com [74.125.44.154]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 3 Jul 2008 11:30:57 -0700 (PDT) Received: by yx-out-1718.google.com with SMTP id 3so284079yxi.80 for ; Thu, 03 Jul 2008 11:30:57 -0700 (PDT) Received: by 10.142.158.17 with SMTP id g17mr47482wfe.212.1215109856474; Thu, 03 Jul 2008 11:30:56 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Thu, 3 Jul 2008 11:30:56 -0700 (PDT) Message-ID: Date: Thu, 3 Jul 2008 11:30:56 -0700 From: "Yong Zhang" To: capwap@frascone.com MIME-Version: 1.0 Content-Disposition: inline Subject: [Capwap] question on the discovery phase 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 I have some question on the role of discovery in the capwap. Is it used to find the AC, or used to find the best AC? If static config AC or DHCP mode are used to get the AC list. Does the WTP need to go into the Discovery phase? Discovery response will provide some live load status of the AC such as current connected WTPs, and STAs. >From the following: Discovery to Discovery (#): In the Discovery state, the WTP determines which AC to connect to. WTP: This transition occurs when the DiscoveryInterval timer expires. If the WTP is configured with a list of ACs, it transmits a Discovery Request message to every AC from which it has not received a Discovery Response message. For every transition to this event, the WTP increments the DiscoveryCount counter. See Section 5.1 for more information on how the WTP knows the ACs to which it should transmit the Discovery Request messages. The WTP restarts the DiscoveryInterval timer whenever it transmits Discovery Request messages. It looks like the WTP will send Disocovery REQ to the AC's one by one? In the case of more than 1 AC, how to deal with DiscoveryCount (its definition in 4.8.2 is for a single AC). MaxDiscoveries (4.8.6) is the for the sum of all AC's, or apply it for each AC? Thanks! Yong _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 3 11:48:13 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 492EA3A684E for ; Thu, 3 Jul 2008 11:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4OnaNr9Hgdq for ; Thu, 3 Jul 2008 11:48:11 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 5BACF3A67E9 for ; Thu, 3 Jul 2008 11:48:11 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4ACCA1C40F40 for ; Thu, 3 Jul 2008 11:48:20 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id A8CF6440149 for ; Thu, 3 Jul 2008 11:48:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0E82F34AC02B for ; Thu, 3 Jul 2008 11:48:10 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 364F734AC051 for ; Thu, 3 Jul 2008 11:48:09 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from yx-out-1718.google.com (yx-out-1718.google.com [74.125.44.157]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 3 Jul 2008 11:48:08 -0700 (PDT) Received: by yx-out-1718.google.com with SMTP id 3so287298yxi.80 for ; Thu, 03 Jul 2008 11:48:08 -0700 (PDT) Received: by 10.142.229.5 with SMTP id b5mr53128wfh.50.1215110887539; Thu, 03 Jul 2008 11:48:07 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Thu, 3 Jul 2008 11:48:07 -0700 (PDT) Message-ID: Date: Thu, 3 Jul 2008 11:48:07 -0700 From: "Yong Zhang" To: capwap@frascone.com MIME-Version: 1.0 Content-Disposition: inline Subject: [Capwap] FSM issues 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 1. waitDTLS is not started in the 2.3.1 CAPWAP Proto State Transitions, although it is said in CAPWAP/DTLS interface chapter. 2. Join REQ need to be send at here. DTLS Connect to Join (d): This transition occurs when the DTLS Session is successfully established. WTP: This state transition occurs when the WTP receives the DTLSEstablished notification (see Section 2.3.2.2), indicating that the DTLS session was successfully established. When this notification is received, the FailedDTLSSessionCount counter is set to zero. 3. Data Check to DTLS Teardown (n): This transition occurs when the WTP does not complete the Data Check exchange. WTP: This state transition occurs if the WTP does not receive the Change State Event Response message before a CAPWAP transmission timeout occurs. Does the above need to be change to something like RetransmitCount counter has reached the MaxRetransmit variable? Since we do not use transmission timeout timer. 4. Run to Run (q): AC Clear Config Response: The AC receives a Clear Configuration Response message from the WTP (see Section 8.9). Need to add Clear Configuration REQ send. 5. Run to DTLS Teardown (p) maybe need to add echo failure case. "transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7)." This can cover WTP, but not AC. Yong _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 3 12:00:27 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5C983A677E for ; Thu, 3 Jul 2008 12:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2Ivsgvqsk4r for ; Thu, 3 Jul 2008 12:00:26 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id B94023A690C for ; Thu, 3 Jul 2008 12:00:13 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A542D1C40F88 for ; Thu, 3 Jul 2008 12:00:22 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 63052440149 for ; Thu, 3 Jul 2008 12:00:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 081B534AC04D for ; Thu, 3 Jul 2008 12:00:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 08DFA34AC02B for ; Thu, 3 Jul 2008 12:00:10 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from yx-out-1718.google.com (yx-out-1718.google.com [74.125.44.156]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 3 Jul 2008 12:00:09 -0700 (PDT) Received: by yx-out-1718.google.com with SMTP id 3so289530yxi.80 for ; Thu, 03 Jul 2008 12:00:09 -0700 (PDT) Received: by 10.142.127.10 with SMTP id z10mr49213wfc.288.1215111608458; Thu, 03 Jul 2008 12:00:08 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Thu, 3 Jul 2008 12:00:08 -0700 (PDT) Message-ID: Date: Thu, 3 Jul 2008 12:00:08 -0700 From: "Yong Zhang" To: capwap@frascone.com MIME-Version: 1.0 Content-Disposition: inline Subject: [Capwap] ME issues 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 I saw some place define the me len use ">", and some place use ">=". Maybe we should unify them into one format. 4.6.4 > 0 to >= 1 4.6.5 > 2 to >= 2 Here is an error!! 4.6.7 Num of Entries: The number of instances of the Type/MAC Addresses fields in the array. This value MUST NOT exceed 1024. 1024 should be 255. NOT exceed 255 mean it can be 255. 4.6.9 same as 4.6.7 4.6.18 same as 4.6.7 4.6.31 >0 to >=1 4.6.36 >=1 to >=6 this is an error. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 3 13:02:24 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9615C3A680E for ; Thu, 3 Jul 2008 13:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sblp9U3LVNnH for ; Thu, 3 Jul 2008 13:02:23 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 9774C3A67E4 for ; Thu, 3 Jul 2008 13:02:23 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6F519439FEC for ; Thu, 3 Jul 2008 13:02:32 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 9FE0A4400F6 for ; Thu, 3 Jul 2008 13:02:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 55A763808005 for ; Thu, 3 Jul 2008 13:02:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id BE87C36480B0 for ; Thu, 3 Jul 2008 13:02:06 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 3 Jul 2008 13:02:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,744,1204502400"; d="scan'208";a="48536985" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 03 Jul 2008 20:02:04 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m63K242a028474; Thu, 3 Jul 2008 13:02: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.13.8/8.13.8) with ESMTP id m63K24gM005474; Thu, 3 Jul 2008 20:02:04 GMT 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, 3 Jul 2008 13:02:04 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Jul 2008 13:02:03 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D12FC@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] question on the discovery phase Thread-Index: AcjdOvcSWjXTjBc7S26KR0SVSVzFcQAC7/ig References: From: "Pat Calhoun (pacalhou)" To: "Yong Zhang" , X-OriginalArrivalTime: 03 Jul 2008 20:02:04.0563 (UTC) FILETIME=[AA0FAE30:01C8DD47] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Capwap] question on the discovery phase 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 Hi Yong, > I have some question on the role of discovery in the capwap. Is it used to find the AC, or used to find the best AC? > If static config AC or DHCP mode are used to get the AC list. Does the WTP need to go into the Discovery phase? The Discovery process is optional. If a WTP has a pre-configured list of ACs it needs to communicate with, it has no need to perform a discovery. However, there are possible issues with not doing a Discovery, since an AC could be at maximum capacity, and may refuse the Join, which would cause the WTP to try another AC. The Discovery process allows the WTP to get more information about the ACs before it attempts to setup the DTLS session. Section 3.3 of the spec says: The AC discovery phase allows the WTP to determine which ACs are available, and chose the best AC with which to establish a CAPWAP session. The discovery phase occurs when the WTP enters the optional Discovery state. A WTP does not need to complete the AC Discovery phase if it uses a pre-configured AC. This section details the mechanism used by a WTP to dynamically discover candidate ACs. > It looks like the WTP will send Disocovery REQ to the AC's one by one? The WTP needs to send a Discovery to each of the ACs that it knows about - and how it knows about it can be through various techniques, from static configuration to DHCP/DNS to having the AC provide a list. Section 3.3 of the spec goes into much more detail on the actual discovery process. The state transition included below also shows that when the Discovery phase is (re-)entered, a Discovery Request is sent to all ACs - not just one. > In the case of more than 1 AC, how to deal with DiscoveryCount (its definition in 4.8.2 is for a single AC). > MaxDiscoveries (4.8.6) is the for the sum of all AC's, or apply it for each AC? The spec is pretty clear, I think, about this: Discovery to Discovery (#): In the Discovery state, the WTP determines which AC to connect to. WTP: This transition occurs when the DiscoveryInterval timer expires. If the WTP is configured with a list of ACs, it transmits a Discovery Request message to every AC from which it has not received a Discovery Response message. For every transition to this event, the WTP increments the DiscoveryCount counter. Basically, everytime the Discovery state is entered, the WTP sends a Discovery Request to the ACs it doesn't have a response from, and increments the counter. PatC -----Original Message----- From: Yong Zhang [mailto:yozhang@gmail.com] Sent: Thursday, July 03, 2008 11:31 AM To: capwap@frascone.com Subject: [Capwap] question on the discovery phase I have some question on the role of discovery in the capwap. Is it used to find the AC, or used to find the best AC? If static config AC or DHCP mode are used to get the AC list. Does the WTP need to go into the Discovery phase? Discovery response will provide some live load status of the AC such as current connected WTPs, and STAs. >From the following: Discovery to Discovery (#): In the Discovery state, the WTP determines which AC to connect to. WTP: This transition occurs when the DiscoveryInterval timer expires. If the WTP is configured with a list of ACs, it transmits a Discovery Request message to every AC from which it has not received a Discovery Response message. For every transition to this event, the WTP increments the DiscoveryCount counter. See Section 5.1 for more information on how the WTP knows the ACs to which it should transmit the Discovery Request messages. The WTP restarts the DiscoveryInterval timer whenever it transmits Discovery Request messages. It looks like the WTP will send Disocovery REQ to the AC's one by one? In the case of more than 1 AC, how to deal with DiscoveryCount (its definition in 4.8.2 is for a single AC). MaxDiscoveries (4.8.6) is the for the sum of all AC's, or apply it for each AC? Thanks! Yong _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 3 13:22:36 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08F8B3A6822 for ; Thu, 3 Jul 2008 13:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaVgnLocUFmc for ; Thu, 3 Jul 2008 13:22:34 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id CC16A3A67E2 for ; Thu, 3 Jul 2008 13:22:34 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AE88D439FDD for ; Thu, 3 Jul 2008 13:22:43 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 05DD14400E3 for ; Thu, 3 Jul 2008 13:22:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id BF4173610007 for ; Thu, 3 Jul 2008 13:22:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5A8E93648094 for ; Thu, 3 Jul 2008 13:22:29 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.68.10.87 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 3 Jul 2008 13:22:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,744,1204502400"; d="scan'208";a="35464658" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 03 Jul 2008 20:22:24 +0000 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/8.12.11) with ESMTP id m63KMONx005710; Thu, 3 Jul 2008 13:22:24 -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.13.8/8.13.8) with ESMTP id m63KMOc6016712; Thu, 3 Jul 2008 20:22:24 GMT 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); Thu, 3 Jul 2008 13:22:24 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Jul 2008 13:22:23 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D131F@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] FSM issues Thread-Index: AcjdPWDxKGW20NHnTkSd6Qkk1e8nGgACs9vA References: From: "Pat Calhoun (pacalhou)" To: "Yong Zhang" , X-OriginalArrivalTime: 03 Jul 2008 20:22:24.0712 (UTC) FILETIME=[8153A480:01C8DD4A] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Capwap] FSM issues 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 I have created issue 139 to track these issues. > 1. waitDTLS is not started in the 2.3.1 CAPWAP Proto State Transitions, although it is said in CAPWAP/DTLS interface > chapter. Yes, you are correct. The description for the StartDTLS command is clear that the WaitDTLS timer needs to be started, but it would be worth including this in the state transition description, as all of the other timers are also included in that section. Idle to DTLS Setup (3): This transition occurs to establish a secure DTLS session with the peer. WTP: The WTP initiates this transition by invoking the DTLSStart command(see Section 2.3.2.1), which starts the DTLS session establishment with the chosen AC and the WaitDTLS timer is started (see Section 4.7). When the discovery phase is bypassed, it is assumed the WTP has locally configured ACs. > 2. Join REQ need to be send at here. > > DTLS Connect to Join (d): This transition occurs when the DTLS > Session is successfully established. > > WTP: This state transition occurs when the WTP receives the > DTLSEstablished notification (see Section 2.3.2.2), indicating > that the DTLS session was successfully established. When this > notification is received, the FailedDTLSSessionCount counter is > set to zero. Yes, this was a strange omission - an obvious thing to do, but it needs to be very clear. DTLS Connect to Join (d): This transition occurs when the DTLS Session is successfully established. WTP: This state transition occurs when the WTP receives the DTLSEstablished notification (see Section 2.3.2.2), indicating that the DTLS session was successfully established. When this notification is received, the FailedDTLSSessionCount counter is set to zero. The WTP enters the Join state by transmiting the Join Request to the AC. > 3. > Data Check to DTLS Teardown (n): This transition occurs when the WTP > does not complete the Data Check exchange. > > WTP: This state transition occurs if the WTP does not receive the > Change State Event Response message before a CAPWAP > transmission timeout occurs. > > Does the above need to be change to something like RetransmitCount > counter has reached the MaxRetransmit variable? Since we do not use transmission timeout timer. Yes, good point. I am including the same text we have in other state transitions. Data Check to DTLS Teardown (n): This transition occurs when the WTP does not complete the Data Check exchange. WTP: This state transition occurs if the WTP does not receive the Change State Event Response message before a CAPWAP retransmission timeout occurs. The WTP also transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7). > 4. Run to Run (q): AC > > Clear Config Response: The AC receives a Clear Configuration > Response message from the WTP (see Section 8.9). > > Need to add Clear Configuration REQ send. I'm not sure that I understand what you are saying. This event occurs when the response is received. The Request was sent some time ago, hence why the response was received. The receive of the Clear Config Request is handled in the WTP section, and is present already. > 5. Run to DTLS Teardown (p) maybe need to add echo failure case. > > "transitions to this state if the underlying reliable > transport's RetransmitCount counter has reached the > MaxRetransmit variable (see Section 4.7)." > > This can cover WTP, but not AC. The echo would cause a retransmission timeout, which makes use of the RetransmitCount counter. I guess I'm not sure that I understand the issue you are trying to raise. Both the WTP and the AC can transmit requests, so it is possible that either side timeouts, forcing this state transition. PatC -----Original Message----- From: Yong Zhang [mailto:yozhang@gmail.com] Sent: Thursday, July 03, 2008 11:48 AM To: capwap@frascone.com Subject: [Capwap] FSM issues 1. waitDTLS is not started in the 2.3.1 CAPWAP Proto State Transitions, although it is said in CAPWAP/DTLS interface chapter. 2. Join REQ need to be send at here. DTLS Connect to Join (d): This transition occurs when the DTLS Session is successfully established. WTP: This state transition occurs when the WTP receives the DTLSEstablished notification (see Section 2.3.2.2), indicating that the DTLS session was successfully established. When this notification is received, the FailedDTLSSessionCount counter is set to zero. 3. Data Check to DTLS Teardown (n): This transition occurs when the WTP does not complete the Data Check exchange. WTP: This state transition occurs if the WTP does not receive the Change State Event Response message before a CAPWAP transmission timeout occurs. Does the above need to be change to something like RetransmitCount counter has reached the MaxRetransmit variable? Since we do not use transmission timeout timer. 4. Run to Run (q): AC Clear Config Response: The AC receives a Clear Configuration Response message from the WTP (see Section 8.9). Need to add Clear Configuration REQ send. 5. Run to DTLS Teardown (p) maybe need to add echo failure case. "transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7)." This can cover WTP, but not AC. Yong _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 3 13:31:12 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 352393A6AA2 for ; Thu, 3 Jul 2008 13:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggyba0tnNmuE for ; Thu, 3 Jul 2008 13:31:11 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 5B52C3A6915 for ; Thu, 3 Jul 2008 13:31:11 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 344C2439FA9 for ; Thu, 3 Jul 2008 13:31:20 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id AAB544400EB for ; Thu, 3 Jul 2008 13:31:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id A950C3648096 for ; Thu, 3 Jul 2008 13:31:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C47F23610008 for ; Thu, 3 Jul 2008 13:30:40 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 3 Jul 2008 13:30:40 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so1022126wfc.11 for ; Thu, 03 Jul 2008 13:30:40 -0700 (PDT) Received: by 10.143.30.10 with SMTP id h10mr67678wfj.7.1215117040167; Thu, 03 Jul 2008 13:30:40 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Thu, 3 Jul 2008 13:30:40 -0700 (PDT) Message-ID: Date: Thu, 3 Jul 2008 13:30:40 -0700 From: "Yong Zhang" To: capwap@frascone.com In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Subject: Re: [Capwap] ME issues 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 4.6.36 >=1 to >=6 this is an error. 1(reason) + 1(length) + 2(me type) + 2(me len) 4.6.37 len should be 4. 4.6.40 should be >= 22 4 (Vendor ID) + 4+4+1 (Model Number) + 4+4+1(Serial Number) 4.6.47 >0 to >=1 4.6.34 should define the "State" use a similar way used by 4.6.50 define the 'Static" 4.8.5 IdleTimeout is a timer. maybe need to be put into 4.7 4.7.11 ResponseTimeout, and 4.7.16 WaitJoin can be removed, since they are not used any more. 6.2 Join Response Should MUST ME be defined earlier than MAY ME? 8.9 Clear Config Response: The Clear Configuration Request message MUST include the following message element. o Result Code, see Section 4.6.35 Shoule be RESPONSE here. 9.1 Figure 7. Is this a reasonable case? If images are same, the WTP will go into Configure state. 9.1.1 The decision that new firmware is to be downloaded to the WTP can occur in one of two ways: When the WTP joins the AC, the Join Response message includes the Image Identifier message element, which informs the WTP of the firmware it is expected to run. if the WTP does not currently have the requested firmware version, it transmits an Image Data Request message, with the appropriate Image Identifier message element. If the WTP already has the requested firmware, it simply resets. Remove "If the WTP already has the requested firmware, it simply resets."? 9.6 Data transfer req What's the use of Data transfer mode 4.6.17? The Data Transfer Data has the mode field. 9.7 Data Transfer Response Upon receipt of a Data Transfer Response message, the WTP transmits more information, if more information is available. What's this meaning of this? If the crash data or memory dump is too large, WTP will segment them, and transfer them using multiple Data transfer req messages. The AC should maintain the data offset by itself? Or you want to say, the WTP will first sent crash dump. It will send the memory dump after it receives the response? Yong On Thu, Jul 3, 2008 at 12:00 PM, Yong Zhang wrote: > I saw some place define the me len use ">", and some place use ">=". > Maybe we should unify them into one format. > > > 4.6.4 > 0 to >= 1 > > 4.6.5 > 2 to >= 2 Here is an error!! > > 4.6.7 > > Num of Entries: The number of instances of the Type/MAC Addresses > fields in the array. This value MUST NOT exceed 1024. > > 1024 should be 255. NOT exceed 255 mean it can be 255. > > 4.6.9 same as 4.6.7 > 4.6.18 same as 4.6.7 > > 4.6.31 >0 to >=1 > > 4.6.36 >=1 to >=6 this is an error. > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 3 13:32:37 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDF153A6ACA for ; Thu, 3 Jul 2008 13:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6G4Mvfx-s7H for ; Thu, 3 Jul 2008 13:32:37 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 0DB343A6AA2 for ; Thu, 3 Jul 2008 13:32:37 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DE1D21C40F5E for ; Thu, 3 Jul 2008 13:32:45 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id F418A4400EB for ; Thu, 3 Jul 2008 13:32:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4D4773648079 for ; Thu, 3 Jul 2008 13:32:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 7AD963610007 for ; Thu, 3 Jul 2008 13:31:48 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 3 Jul 2008 13:31:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,744,1204502400"; d="scan'208";a="48551892" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 03 Jul 2008 20:31:48 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m63KVmmI020548; Thu, 3 Jul 2008 13:31:48 -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.13.8/8.13.8) with ESMTP id m63KVkfh028860; Thu, 3 Jul 2008 20:31:48 GMT 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.1830); Thu, 3 Jul 2008 13:31:47 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Jul 2008 13:31:47 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D1333@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] ME issues Thread-Index: AcjdPwsFm+7OX3ysQLq0bE1evPX/pAAC9zWg References: From: "Pat Calhoun (pacalhou)" To: "Yong Zhang" , X-OriginalArrivalTime: 03 Jul 2008 20:31:47.0854 (UTC) FILETIME=[D0FC4AE0:01C8DD4B] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Capwap] ME issues 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 I have created issue 140 to track this. > 4.6.4 > 0 to >= 1 I think in the end, unless there is an error, it doesn't matter. However, if you believe it reads better, then OK. > > 4.6.5 > 2 to >= 2 Here is an error!! Yes, this is an issue that I have fixed. > > 4.6.7 > > Num of Entries: The number of instances of the Type/MAC Addresses > fields in the array. This value MUST NOT exceed 1024. > > 1024 should be 255. NOT exceed 255 mean it can be 255. > > 4.6.9 same as 4.6.7 > 4.6.18 same as 4.6.7 Oh right - being it is a one octet field, 255 is the max. I have made the change. > > 4.6.31 >0 to >=1 It means the same thing, but if you believe it helps, ok. > > 4.6.36 >=1 to >=6 this is an error. I agree - this needs to be fixed. PatC -----Original Message----- From: Yong Zhang [mailto:yozhang@gmail.com] Sent: Thursday, July 03, 2008 12:00 PM To: capwap@frascone.com Subject: [Capwap] ME issues I saw some place define the me len use ">", and some place use ">=". Maybe we should unify them into one format. 4.6.4 > 0 to >= 1 4.6.5 > 2 to >= 2 Here is an error!! 4.6.7 Num of Entries: The number of instances of the Type/MAC Addresses fields in the array. This value MUST NOT exceed 1024. 1024 should be 255. NOT exceed 255 mean it can be 255. 4.6.9 same as 4.6.7 4.6.18 same as 4.6.7 4.6.31 >0 to >=1 4.6.36 >=1 to >=6 this is an error. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 3 13:40:56 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13D53A6932 for ; Thu, 3 Jul 2008 13:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HL-yTC+LQ44Z for ; Thu, 3 Jul 2008 13:40:55 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 6C04B3A68B2 for ; Thu, 3 Jul 2008 13:40:55 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4B4641C40F6C for ; Thu, 3 Jul 2008 13:41:04 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 3FCBF4400EB for ; Thu, 3 Jul 2008 13:40:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 1BD6E3610004 for ; Thu, 3 Jul 2008 13:40:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2D7823610007 for ; Thu, 3 Jul 2008 13:40:53 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 3 Jul 2008 13:40:53 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so1025585wfc.11 for ; Thu, 03 Jul 2008 13:40:52 -0700 (PDT) Received: by 10.142.11.2 with SMTP id 2mr65875wfk.72.1215117652820; Thu, 03 Jul 2008 13:40:52 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Thu, 3 Jul 2008 13:40:52 -0700 (PDT) Message-ID: Date: Thu, 3 Jul 2008 13:40:52 -0700 From: "Yong Zhang" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2060D131F@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <4FF84B0BC277FF45AA27FE969DD956A2060D131F@xmb-sjc-235.amer.cisco.com> Cc: capwap@frascone.com Subject: Re: [Capwap] FSM issues 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 >> 4. Run to Run (q): AC >> >> Clear Config Response: The AC receives a Clear Configuration >> Response message from the WTP (see Section 8.9). >> >> Need to add Clear Configuration REQ send. > I'm not sure that I understand what you are saying. This event occurs > when the response is received. The Request was sent some time ago, hence > why the response was received. The receive of the Clear Config Request > is handled in the WTP section, and is present already. Refer to other messages description in AC RUN state: Ac need to send out the REQ, and AC need to receive RESP. Just WTP clear Config Response also has the problem. >> 5. Run to DTLS Teardown (p) maybe need to add echo failure case. >> >> "transitions to this state if the underlying reliable >> transport's RetransmitCount counter has reached the >> MaxRetransmit variable (see Section 4.7)." >> >> This can cover WTP, but not AC. > The echo would cause a retransmission timeout, which makes use of the > RetransmitCount counter. I guess I'm not sure that I understand the > issue you are trying to raise. Both the WTP and the AC can transmit > requests, so it is possible that either side timeouts, forcing this > state transition. > I only see the WTP sends REQ, and AC recvs RESP. Where is it said that AC also sends ECHO REQ? On Thu, Jul 3, 2008 at 1:22 PM, Pat Calhoun (pacalhou) wrote: > I have created issue 139 to track these issues. > >> 1. waitDTLS is not started in the 2.3.1 CAPWAP Proto State > Transitions, although it is said in CAPWAP/DTLS interface >> chapter. > Yes, you are correct. The description for the StartDTLS command is clear > that the WaitDTLS timer needs to be started, but it would be worth > including this in the state transition description, as all of the other > timers are also included in that section. > > > Idle to DTLS Setup (3): This transition occurs to establish a secure > DTLS session with the peer. > > WTP: The WTP initiates this transition by invoking the DTLSStart > command(see Section 2.3.2.1), which starts the DTLS session > establishment with the chosen AC and the WaitDTLS timer is > started (see Section 4.7). When the discovery phase is > bypassed, it is assumed the WTP has locally configured ACs. > > >> 2. Join REQ need to be send at here. >> >> DTLS Connect to Join (d): This transition occurs when the DTLS >> Session is successfully established. >> >> WTP: This state transition occurs when the WTP receives the >> DTLSEstablished notification (see Section 2.3.2.2), indicating >> that the DTLS session was successfully established. When this >> notification is received, the FailedDTLSSessionCount counter > is >> set to zero. > Yes, this was a strange omission - an obvious thing to do, but it needs > to be very clear. > > > DTLS Connect to Join (d): This transition occurs when the DTLS > Session is successfully established. > > WTP: This state transition occurs when the WTP receives the > DTLSEstablished notification (see Section 2.3.2.2), indicating > that the DTLS session was successfully established. When this > notification is received, the FailedDTLSSessionCount counter is > set to zero. The WTP enters the Join state by transmiting the > Join Request to the AC. > > >> 3. >> Data Check to DTLS Teardown (n): This transition occurs when the WTP >> does not complete the Data Check exchange. >> >> WTP: This state transition occurs if the WTP does not receive > the >> Change State Event Response message before a CAPWAP >> transmission timeout occurs. >> >> Does the above need to be change to something like > RetransmitCount >> counter has reached the MaxRetransmit variable? Since we do not use > transmission timeout timer. > Yes, good point. I am including the same text we have in other state > transitions. > > > Data Check to DTLS Teardown (n): This transition occurs when the WTP > does not complete the Data Check exchange. > > WTP: This state transition occurs if the WTP does not receive the > Change State Event Response message before a CAPWAP > retransmission timeout occurs. The WTP also transitions to > this state if the underlying reliable transport's > RetransmitCount counter has reached the MaxRetransmit variable > (see Section 4.7). > > >> 4. Run to Run (q): AC >> >> Clear Config Response: The AC receives a Clear Configuration >> Response message from the WTP (see Section 8.9). >> >> Need to add Clear Configuration REQ send. > I'm not sure that I understand what you are saying. This event occurs > when the response is received. The Request was sent some time ago, hence > why the response was received. The receive of the Clear Config Request > is handled in the WTP section, and is present already. > >> 5. Run to DTLS Teardown (p) maybe need to add echo failure case. >> >> "transitions to this state if the underlying reliable >> transport's RetransmitCount counter has reached the >> MaxRetransmit variable (see Section 4.7)." >> >> This can cover WTP, but not AC. > The echo would cause a retransmission timeout, which makes use of the > RetransmitCount counter. I guess I'm not sure that I understand the > issue you are trying to raise. Both the WTP and the AC can transmit > requests, so it is possible that either side timeouts, forcing this > state transition. > > PatC > > -----Original Message----- > From: Yong Zhang [mailto:yozhang@gmail.com] > Sent: Thursday, July 03, 2008 11:48 AM > To: capwap@frascone.com > Subject: [Capwap] FSM issues > > 1. waitDTLS is not started in the 2.3.1 CAPWAP Proto State Transitions, > although it is said in CAPWAP/DTLS interface chapter. > > 2. Join REQ need to be send at here. > > DTLS Connect to Join (d): This transition occurs when the DTLS > Session is successfully established. > > WTP: This state transition occurs when the WTP receives the > DTLSEstablished notification (see Section 2.3.2.2), indicating > that the DTLS session was successfully established. When this > notification is received, the FailedDTLSSessionCount counter is > set to zero. > > 3. > Data Check to DTLS Teardown (n): This transition occurs when the WTP > does not complete the Data Check exchange. > > WTP: This state transition occurs if the WTP does not receive the > Change State Event Response message before a CAPWAP > transmission timeout occurs. > > Does the above need to be change to something like RetransmitCount > counter has reached the MaxRetransmit variable? Since we do not use > transmission timeout timer. > > 4. Run to Run (q): AC > > Clear Config Response: The AC receives a Clear Configuration > Response message from the WTP (see Section 8.9). > > Need to add Clear Configuration REQ send. > > 5. Run to DTLS Teardown (p) maybe need to add echo failure case. > > "transitions to this state if the underlying reliable > transport's RetransmitCount counter has reached the > MaxRetransmit variable (see Section 4.7)." > > This can cover WTP, but not AC. > > > Yong > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 3 13:56:56 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AECD73A6812 for ; Thu, 3 Jul 2008 13:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERLgFVn+Ba3u for ; Thu, 3 Jul 2008 13:56:55 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 9FEF43A679F for ; Thu, 3 Jul 2008 13:56:55 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 82D6C1C40F9C for ; Thu, 3 Jul 2008 13:57:04 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 193754400BE for ; Thu, 3 Jul 2008 13:56:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D149836480A5 for ; Thu, 3 Jul 2008 13:56:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id DA7353648079 for ; Thu, 3 Jul 2008 13:56:52 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.152]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 3 Jul 2008 13:56:52 -0700 (PDT) Received: by yw-out-1718.google.com with SMTP id 6so406016ywa.80 for ; Thu, 03 Jul 2008 13:56:51 -0700 (PDT) Received: by 10.142.239.13 with SMTP id m13mr63823wfh.218.1215118610586; Thu, 03 Jul 2008 13:56:50 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Thu, 3 Jul 2008 13:56:50 -0700 (PDT) Message-ID: Date: Thu, 3 Jul 2008 13:56:50 -0700 From: "Yong Zhang" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2060D12FC@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <4FF84B0BC277FF45AA27FE969DD956A2060D12FC@xmb-sjc-235.amer.cisco.com> Cc: capwap@frascone.com Subject: Re: [Capwap] question on the discovery phase 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 I see. Thanks for the explanation. Yong On Thu, Jul 3, 2008 at 1:02 PM, Pat Calhoun (pacalhou) wrote: > Hi Yong, > >> I have some question on the role of discovery in the capwap. Is it > used to find the AC, or used to find the best AC? >> If static config AC or DHCP mode are used to get the AC list. Does the > WTP need to go into the Discovery phase? > > The Discovery process is optional. If a WTP has a pre-configured list of > ACs it needs to communicate with, it has no need to perform a discovery. > However, there are possible issues with not doing a Discovery, since an > AC could be at maximum capacity, and may refuse the Join, which would > cause the WTP to try another AC. The Discovery process allows the WTP to > get more information about the ACs before it attempts to setup the DTLS > session. Section 3.3 of the spec says: > > The AC discovery phase allows the WTP to determine which ACs are > available, and chose the best AC with which to establish a CAPWAP > session. The discovery phase occurs when the WTP enters the optional > Discovery state. A WTP does not need to complete the AC Discovery > phase if it uses a pre-configured AC. This section details the > mechanism used by a WTP to dynamically discover candidate ACs. > >> It looks like the WTP will send Disocovery REQ to the AC's one by one? > The WTP needs to send a Discovery to each of the ACs that it knows about > - and how it knows about it can be through various techniques, from > static configuration to DHCP/DNS to having the AC provide a list. > Section 3.3 of the spec goes into much more detail on the actual > discovery process. The state transition included below also shows that > when the Discovery phase is (re-)entered, a Discovery Request is sent to > all ACs - not just one. > >> In the case of more than 1 AC, how to deal with DiscoveryCount (its > definition in 4.8.2 is for a single AC). >> MaxDiscoveries (4.8.6) is the for the sum of all AC's, or apply it for > each AC? > The spec is pretty clear, I think, about this: > > Discovery to Discovery (#): In the Discovery state, the WTP > determines which AC to connect to. > > WTP: This transition occurs when the DiscoveryInterval timer > expires. If the WTP is configured with a list of ACs, it > transmits a Discovery Request message to every AC from which it > has not received a Discovery Response message. For every > transition to this event, the WTP increments the DiscoveryCount > counter. > > Basically, everytime the Discovery state is entered, the WTP sends a > Discovery Request to the ACs it doesn't have a response from, and > increments the counter. > > PatC > > -----Original Message----- > From: Yong Zhang [mailto:yozhang@gmail.com] > Sent: Thursday, July 03, 2008 11:31 AM > To: capwap@frascone.com > Subject: [Capwap] question on the discovery phase > > I have some question on the role of discovery in the capwap. Is it used > to find the AC, or used to find the best AC? > > If static config AC or DHCP mode are used to get the AC list. Does the > WTP need to go into the Discovery phase? > > Discovery response will provide some live load status of the AC such as > current connected WTPs, and STAs. > > >From the following: > > Discovery to Discovery (#): In the Discovery state, the WTP > determines which AC to connect to. > > WTP: This transition occurs when the DiscoveryInterval timer > expires. If the WTP is configured with a list of ACs, it > transmits a Discovery Request message to every AC from which it > has not received a Discovery Response message. For every > transition to this event, the WTP increments the DiscoveryCount > counter. See Section 5.1 for more information on how the WTP > knows the ACs to which it should transmit the Discovery Request > messages. The WTP restarts the DiscoveryInterval timer > whenever it transmits Discovery Request messages. > > It looks like the WTP will send Disocovery REQ to the AC's one by one? > > In the case of more than 1 AC, how to deal with DiscoveryCount (its > definition in 4.8.2 is for a single AC). MaxDiscoveries (4.8.6) is the > for the sum of all AC's, or apply it for each AC? > > Thanks! > > Yong > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 3 14:12:03 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60D4D3A68B4 for ; Thu, 3 Jul 2008 14:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsoTjHv9BDSh for ; Thu, 3 Jul 2008 14:12:02 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 513F13A68C0 for ; Thu, 3 Jul 2008 14:11:49 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 235CE439FE0 for ; Thu, 3 Jul 2008 14:11:58 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 679BA4400B5 for ; Thu, 3 Jul 2008 14:11:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2E5E336480A1 for ; Thu, 3 Jul 2008 14:11:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4CC2D3648094 for ; Thu, 3 Jul 2008 14:11:41 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 3 Jul 2008 14:11:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,744,1204502400"; d="scan'208";a="62716113" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 03 Jul 2008 21:11:03 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m63LB3O8014481; Thu, 3 Jul 2008 14:11:03 -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.13.8/8.13.8) with ESMTP id m63LAxJB028892; Thu, 3 Jul 2008 21:11:03 GMT 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, 3 Jul 2008 14:11:03 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Jul 2008 14:11:02 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D1378@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More ME issues Thread-Index: AcjdS8Es2k7un2ttTzKXrxxRKJZF7gAAGi/w References: From: "Pat Calhoun (pacalhou)" To: "Yong Zhang" , X-OriginalArrivalTime: 03 Jul 2008 21:11:03.0257 (UTC) FILETIME=[4CEA4490:01C8DD51] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Capwap] More ME issues 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 I have created Issue 141 to track these issues. > 4.6.36 >=1 to >=6 this is an error. > > 1(reason) + 1(length) + 2(me type) + 2(me len) You raised this already in issue 140, so I am claiming it is a duplicate and rejecting this one. > 4.6.37 len should be 4. Yes, this is a bug. It needs to be 4. > 4.6.40 should be >= 22 > > 4 (Vendor ID) + 4+4+1 (Model Number) + 4+4+1(Serial Number) No, the correct value is in fact 14 since the Vendor ID is only presence once, not once for each sub-element. The sub-element mentions that two board elements MUST be present, which is 14 octets. > 4.6.47 >0 to >=1 Again, I don't see a problem here, but will make the change if you think it is clearer. > 4.6.34 should define the "State" use a similar way used by 4.6.50 define the 'Static" This would break interoperability, as it would change the values used. I'd like to make sure that no one objects to break -10 compatibility. This is a fairly small nit. > 4.8.5 IdleTimeout is a timer. maybe need to be put into 4.7 Yes, that probably makes sense. > 4.7.11 ResponseTimeout, and 4.7.16 WaitJoin can be removed, since they are not used any more. PAT WAITING ON YONG's RESPONSE. > 6.2 Join Response > Should MUST ME be defined earlier than MAY ME? This doesn't really break anything. I'm not sure we need to address this. > 8.9 Clear Config Response: > > The Clear Configuration Request message MUST include the following > message element. > > o Result Code, see Section 4.6.35 > > Shoule be RESPONSE here. Correct. This is a valid editorial issue. > 9.1 Figure 7. Is this a reasonable case? > > If images are same, the WTP will go into Configure state. No, actually the text was not providing enough information. The text is now: Figure 7 provides an example in which the WTP has the image specified by the AC in its non-volative storage, but is not its current running image. In this case, the WTP opts to NOT download the firmware and immediately reset to the requested image. > 9.1.1 > > The decision that new firmware is to be downloaded to the WTP can > occur in one of two ways: > > When the WTP joins the AC, the Join Response message includes the > Image Identifier message element, which informs the WTP of the > firmware it is expected to run. if the WTP does not currently have > the requested firmware version, it transmits an Image Data Request > message, with the appropriate Image Identifier message element. > If the WTP already has the requested firmware, it simply resets. > > Remove "If the WTP already has the requested firmware, it simply resets."? Again, the text was not sufficient. It now reads: If the WTP already has the requested firmware in its non-volatile flash, but is not its currently running image, it simply resets to run the proper firmware. > 9.6 Data transfer req > > What's the use of Data transfer mode 4.6.17? The Data Transfer Data has the mode field. That is very repetitive, and unnecessary. I would propose removing the mode from 4.6.16, and simply using the message element defined in 4.6.17. I checked, and it is ONLY used during the data transfer request, so I do not see any harm. However, this breaks -10, and is only repetitive. I want to make sure that there are no concerns in making this change from others in the WG. > 9.7 Data Transfer Response > > Upon receipt of a Data Transfer Response message, the WTP transmits > more information, if more information is available. > > What's this meaning of this? If the crash data or memory dump is too large, WTP will segment them, and transfer them > using multiple Data transfer req messages. > The AC should maintain the > data offset by itself? Or you want to say, the WTP will first sent > crash dump. It will send the memory > dump after it receives the response? Yes, this is a series of back and forth, where the WTP will, if necessary, break the information to be sent across multiple packets. The CAPWAP transmission layer will ensure it is reassembled in the proper order. Maybe I'm not understanding the question you are asking. PatC -----Original Message----- From: Yong Zhang [mailto:yozhang@gmail.com] Sent: Thursday, July 03, 2008 1:31 PM To: capwap@frascone.com Subject: Re: [Capwap] ME issues 4.6.36 >=1 to >=6 this is an error. 1(reason) + 1(length) + 2(me type) + 2(me len) 4.6.37 len should be 4. 4.6.40 should be >= 22 4 (Vendor ID) + 4+4+1 (Model Number) + 4+4+1(Serial Number) 4.6.47 >0 to >=1 4.6.34 should define the "State" use a similar way used by 4.6.50 define the 'Static" 4.8.5 IdleTimeout is a timer. maybe need to be put into 4.7 4.7.11 ResponseTimeout, and 4.7.16 WaitJoin can be removed, since they are not used any more. 6.2 Join Response Should MUST ME be defined earlier than MAY ME? 8.9 Clear Config Response: The Clear Configuration Request message MUST include the following message element. o Result Code, see Section 4.6.35 Shoule be RESPONSE here. 9.1 Figure 7. Is this a reasonable case? If images are same, the WTP will go into Configure state. 9.1.1 The decision that new firmware is to be downloaded to the WTP can occur in one of two ways: When the WTP joins the AC, the Join Response message includes the Image Identifier message element, which informs the WTP of the firmware it is expected to run. if the WTP does not currently have the requested firmware version, it transmits an Image Data Request message, with the appropriate Image Identifier message element. If the WTP already has the requested firmware, it simply resets. Remove "If the WTP already has the requested firmware, it simply resets."? 9.6 Data transfer req What's the use of Data transfer mode 4.6.17? The Data Transfer Data has the mode field. 9.7 Data Transfer Response Upon receipt of a Data Transfer Response message, the WTP transmits more information, if more information is available. What's this meaning of this? If the crash data or memory dump is too large, WTP will segment them, and transfer them using multiple Data transfer req messages. The AC should maintain the data offset by itself? Or you want to say, the WTP will first sent crash dump. It will send the memory dump after it receives the response? Yong On Thu, Jul 3, 2008 at 12:00 PM, Yong Zhang wrote: > I saw some place define the me len use ">", and some place use ">=". > Maybe we should unify them into one format. > > > 4.6.4 > 0 to >= 1 > > 4.6.5 > 2 to >= 2 Here is an error!! > > 4.6.7 > > Num of Entries: The number of instances of the Type/MAC Addresses > fields in the array. This value MUST NOT exceed 1024. > > 1024 should be 255. NOT exceed 255 mean it can be 255. > > 4.6.9 same as 4.6.7 > 4.6.18 same as 4.6.7 > > 4.6.31 >0 to >=1 > > 4.6.36 >=1 to >=6 this is an error. > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 3 14:27:43 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCD93A67CE for ; Thu, 3 Jul 2008 14:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ClJLfMlmfE4 for ; Thu, 3 Jul 2008 14:27:41 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id BF05C3A6B37 for ; Thu, 3 Jul 2008 14:27:41 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 93C631C40F8D for ; Thu, 3 Jul 2008 14:27:50 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 3E2974400F3 for ; Thu, 3 Jul 2008 14:27:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 15E893610004 for ; Thu, 3 Jul 2008 14:27:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E1E6B3808001 for ; Thu, 3 Jul 2008 14:27:37 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 3 Jul 2008 14:27:37 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so1040827wfc.11 for ; Thu, 03 Jul 2008 14:27:37 -0700 (PDT) Received: by 10.143.18.16 with SMTP id v16mr71278wfi.41.1215120457306; Thu, 03 Jul 2008 14:27:37 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Thu, 3 Jul 2008 14:27:37 -0700 (PDT) Message-ID: Date: Thu, 3 Jul 2008 14:27:37 -0700 From: "Yong Zhang" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2060D1378@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <4FF84B0BC277FF45AA27FE969DD956A2060D1378@xmb-sjc-235.amer.cisco.com> Cc: capwap@frascone.com Subject: Re: [Capwap] More ME issues 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 >> 6.2 Join Response >> Should MUST ME be defined earlier than MAY ME? > This doesn't really break anything. I'm not sure we need to address > this. I saw other message definitions always put MUST MEs in the beginning. > 9.7 Data Transfer Response > > Upon receipt of a Data Transfer Response message, the WTP transmits > more information, if more information is available. > > What's this meaning of this? If the crash data or memory dump is too large, WTP will segment them, and transfer them > using multiple Data transfer req messages. > The AC should maintain the > data offset by itself? Or you want to say, the WTP will first sent > crash dump. It will send the memory > dump after it receives the response? Yes, this is a series of back and forth, where the WTP will, if necessary, break the information to be sent across multiple packets. The CAPWAP transmission layer will ensure it is reassembled in the proper order. Maybe I'm not understanding the question you are asking. then how the AC knows it has received all the debug data from the WTP? Yong On Thu, Jul 3, 2008 at 2:11 PM, Pat Calhoun (pacalhou) wrote: > I have created Issue 141 to track these issues. > >> 4.6.36 >=1 to >=6 this is an error. >> >> 1(reason) + 1(length) + 2(me type) + 2(me len) > You raised this already in issue 140, so I am claiming it is a duplicate > and rejecting this one. > >> 4.6.37 len should be 4. > Yes, this is a bug. It needs to be 4. > >> 4.6.40 should be >= 22 >> >> 4 (Vendor ID) + 4+4+1 (Model Number) + 4+4+1(Serial Number) > > No, the correct value is in fact 14 since the Vendor ID is only presence > once, not once for each sub-element. The sub-element mentions that two > board elements MUST be present, which is 14 octets. > >> 4.6.47 >0 to >=1 > Again, I don't see a problem here, but will make the change if you think > it is clearer. > >> 4.6.34 should define the "State" use a similar way used by 4.6.50 > define the 'Static" > This would break interoperability, as it would change the values used. > I'd like to make sure that no one objects to break -10 compatibility. > This is a fairly small nit. > >> 4.8.5 IdleTimeout is a timer. maybe need to be put into 4.7 > Yes, that probably makes sense. > >> 4.7.11 ResponseTimeout, and 4.7.16 WaitJoin can be removed, since they > are not used any more. > PAT WAITING ON YONG's RESPONSE. > >> 6.2 Join Response >> Should MUST ME be defined earlier than MAY ME? > This doesn't really break anything. I'm not sure we need to address > this. > > >> 8.9 Clear Config Response: >> >> The Clear Configuration Request message MUST include the following >> message element. >> >> o Result Code, see Section 4.6.35 >> >> Shoule be RESPONSE here. > Correct. This is a valid editorial issue. > >> 9.1 Figure 7. Is this a reasonable case? >> >> If images are same, the WTP will go into Configure state. > > No, actually the text was not providing enough information. The text is > now: > > Figure 7 provides an example in which the WTP has the image specified > by the AC in its non-volative storage, but is not its current running > image. In this case, the WTP opts to NOT download the firmware and > immediately reset to the requested image. > > >> 9.1.1 >> >> The decision that new firmware is to be downloaded to the WTP can >> occur in one of two ways: >> >> When the WTP joins the AC, the Join Response message includes > the >> Image Identifier message element, which informs the WTP of the >> firmware it is expected to run. if the WTP does not currently > have >> the requested firmware version, it transmits an Image Data > Request >> message, with the appropriate Image Identifier message element. >> If the WTP already has the requested firmware, it simply resets. >> >> Remove "If the WTP already has the requested firmware, it simply > resets."? > Again, the text was not sufficient. It now reads: > > > If the WTP already has > the requested firmware in its non-volatile flash, but is > not its > currently running image, it simply resets to run the > proper firmware. > > >> 9.6 Data transfer req >> >> What's the use of Data transfer mode 4.6.17? The Data Transfer Data > has the mode field. > That is very repetitive, and unnecessary. I would propose removing the > mode from 4.6.16, and simply using the message element defined in > 4.6.17. I checked, and it is ONLY used during the data transfer request, > so I do not see any harm. However, this breaks -10, and is only > repetitive. I want to make sure that there are no concerns in making > this change from others in the WG. > >> 9.7 Data Transfer Response >> >> Upon receipt of a Data Transfer Response message, the WTP transmits >> more information, if more information is available. >> >> What's this meaning of this? If the crash data or memory dump is too > large, WTP will segment them, and transfer them >> using multiple Data transfer req messages. >> The AC should maintain the >> data offset by itself? Or you want to say, the WTP will first sent >> crash dump. It will send the memory >> dump after it receives the response? > Yes, this is a series of back and forth, where the WTP will, if > necessary, break the information to be sent across multiple packets. The > CAPWAP transmission layer will ensure it is reassembled in the proper > order. Maybe I'm not understanding the question you are asking. > > PatC > > -----Original Message----- > From: Yong Zhang [mailto:yozhang@gmail.com] > Sent: Thursday, July 03, 2008 1:31 PM > To: capwap@frascone.com > Subject: Re: [Capwap] ME issues > > 4.6.36 >=1 to >=6 this is an error. > > 1(reason) + 1(length) + 2(me type) + 2(me len) > > 4.6.37 len should be 4. > > 4.6.40 should be >= 22 > > 4 (Vendor ID) + 4+4+1 (Model Number) + 4+4+1(Serial Number) > > 4.6.47 >0 to >=1 > > 4.6.34 should define the "State" use a similar way used by 4.6.50 define > the 'Static" > > > 4.8.5 IdleTimeout is a timer. maybe need to be put into 4.7 > > 4.7.11 ResponseTimeout, and 4.7.16 WaitJoin can be removed, since they > are not used any more. > > 6.2 Join Response > Should MUST ME be defined earlier than MAY ME? > > 8.9 Clear Config Response: > > The Clear Configuration Request message MUST include the following > message element. > > o Result Code, see Section 4.6.35 > > Shoule be RESPONSE here. > > 9.1 Figure 7. Is this a reasonable case? > > If images are same, the WTP will go into Configure state. > > 9.1.1 > > The decision that new firmware is to be downloaded to the WTP can > occur in one of two ways: > > When the WTP joins the AC, the Join Response message includes the > Image Identifier message element, which informs the WTP of the > firmware it is expected to run. if the WTP does not currently have > the requested firmware version, it transmits an Image Data Request > message, with the appropriate Image Identifier message element. > If the WTP already has the requested firmware, it simply resets. > > Remove "If the WTP already has the requested firmware, it simply > resets."? > > 9.6 Data transfer req > > What's the use of Data transfer mode 4.6.17? The Data Transfer Data has > the mode field. > > 9.7 Data Transfer Response > > Upon receipt of a Data Transfer Response message, the WTP transmits > more information, if more information is available. > > What's this meaning of this? If the crash data or memory dump is too > large, WTP will segment them, and transfer them using multiple Data > transfer req messages. > The AC should maintain the > data offset by itself? Or you want to say, the WTP will first sent > crash dump. It will send the memory > dump after it receives the response? > > Yong > > On Thu, Jul 3, 2008 at 12:00 PM, Yong Zhang wrote: >> I saw some place define the me len use ">", and some place use ">=". >> Maybe we should unify them into one format. >> >> >> 4.6.4 > 0 to >= 1 >> >> 4.6.5 > 2 to >= 2 Here is an error!! >> >> 4.6.7 >> >> Num of Entries: The number of instances of the Type/MAC Addresses >> fields in the array. This value MUST NOT exceed 1024. >> >> 1024 should be 255. NOT exceed 255 mean it can be 255. >> >> 4.6.9 same as 4.6.7 >> 4.6.18 same as 4.6.7 >> >> 4.6.31 >0 to >=1 >> >> 4.6.36 >=1 to >=6 this is an error. >> > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 3 14:41:21 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BF073A6883 for ; Thu, 3 Jul 2008 14:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2KUUigFoXIC for ; Thu, 3 Jul 2008 14:41:20 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 5DCE53A67FA for ; Thu, 3 Jul 2008 14:41:20 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 323951C40F67 for ; Thu, 3 Jul 2008 14:41:29 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 321674400E7 for ; Thu, 3 Jul 2008 14:41:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E39473648094 for ; Thu, 3 Jul 2008 14:41:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E5EFF3610004 for ; Thu, 3 Jul 2008 14:41:16 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.152]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 3 Jul 2008 14:41:16 -0700 (PDT) Received: by yw-out-1718.google.com with SMTP id 6so413892ywa.80 for ; Thu, 03 Jul 2008 14:41:16 -0700 (PDT) Received: by 10.142.188.4 with SMTP id l4mr68815wff.183.1215121275324; Thu, 03 Jul 2008 14:41:15 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Thu, 3 Jul 2008 14:41:15 -0700 (PDT) Message-ID: Date: Thu, 3 Jul 2008 14:41:15 -0700 From: "Yong Zhang" To: "Pat Calhoun (pacalhou)" MIME-Version: 1.0 Content-Disposition: inline Cc: capwap@frascone.com Subject: [Capwap] UDP IANA port 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 I saw from the mail archive that UDP ports had been allocated by IANA, but the spec. doc. is not updated. Yong The CAPWAP control port at the AC is the well known UDP port [to be IANA assigned]. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From c.schmitt@a-n-a.de Sat Jul 5 06:49:31 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A321A3A6869; Sat, 5 Jul 2008 06:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -60.384 X-Spam-Level: X-Spam-Status: No, score=-60.384 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qM-oFJ9cdXxO; Sat, 5 Jul 2008 06:49:30 -0700 (PDT) Received: from pc-59-1-104-200.cm.vtr.net (pc-59-1-104-200.cm.vtr.net [200.104.1.59]) by core3.amsl.com (Postfix) with SMTP id D7E2B3A6839; Sat, 5 Jul 2008 06:49:11 -0700 (PDT) X-Originating-IP: 6.44.168.84 by smtp.200.104.1.59; Sat, 05 Jul 2008 09:49:21 -0500 Message-ID: From: "Jose Mcgraw" Reply-To: "Jose Mcgraw" To: atompub-archive@megatron.ietf.org Subject: Famous replica watches rolex Cartier Bvlgari Date: Sat, 05 Jul 2008 09:49:21 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Prestige Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://Laverneruhiro.blogspot.com/ As you are probably aware of, Prestige Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Prestige Replicas today! http://Laverneruhiro.blogspot.com/ From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Jul 6 06:34:09 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E5D13A68BA for ; Sun, 6 Jul 2008 06:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtoyrHc6uVLM for ; Sun, 6 Jul 2008 06:34:08 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 8885E3A680C for ; Sun, 6 Jul 2008 06:34:08 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2C0A7430E8A for ; Sun, 6 Jul 2008 06:34:12 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 91D994400ED for ; Sun, 6 Jul 2008 06:34:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5BE4134AC058 for ; Sun, 6 Jul 2008 06:34:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 18D6734AC024 for ; Sun, 6 Jul 2008 06:34:02 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from exchange.tm.thingmagic.com (vpn.thingmagic.com [204.9.221.19]) by mx1.tigertech.net (Postfix) with ESMTP for ; Sun, 6 Jul 2008 06:34:01 -0700 (PDT) Received: from [192.168.1.106] (72.224.232.175) by exchange.tm.thingmagic.com (10.0.0.9) with Microsoft SMTP Server (TLS) id 8.1.278.0; Sun, 6 Jul 2008 09:34:00 -0400 In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20607BBDF@xmb-sjc-235.amer.cisco.com> References: <4FF84B0BC277FF45AA27FE969DD956A20607BBDF@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 (Apple Message framework v753.1) Message-ID: From: Margaret Wasserman Date: Sun, 6 Jul 2008 09:33:58 -0400 To: Pat Calhoun X-Mailer: Apple Mail (2.753.1) Cc: capwap@frascone.com Subject: Re: [Capwap] New Issue 138: Inconsistent values for enable/disable in section 4.6.34 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 Personally, I am a bit queasy about the idea of swapping these values in a new version of the draft. However, I agree that the current situation is far from ideal... So, I do support this change, but I wish we could come up with a better answer. Margaret On Jul 1, 2008, at 4:05 PM, Pat Calhoun (pacalhou) wrote: > All, > > Yong has raised another issue, but I'm not sure that this one will > have > the required > consensus as it will break compatibility with existing implementations > that conform to > -10. > > Section 4.6.34 uses 1 for disable and 2 for enable, while the rest of > the spec uses the > inverse. This inconsistency could be confusing for people using > #DEFINEs. Is there > agreement to inversing these values, with the understanding that it > would create a > backward compatibility issue with -10? > > PatC > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/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 Jul 6 08:54:13 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41F8F3A68BA for ; Sun, 6 Jul 2008 08:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KnV810Dbmmw for ; Sun, 6 Jul 2008 08:54:12 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 1C2593A6826 for ; Sun, 6 Jul 2008 08:54:12 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 201D7432631 for ; Sun, 6 Jul 2008 08:54:16 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 5591B440127 for ; Sun, 6 Jul 2008 08:54:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2656D34AC05C for ; Sun, 6 Jul 2008 08:54:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 7A57834AC055 for ; Sun, 6 Jul 2008 08:54:03 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Sun, 6 Jul 2008 08:54:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,311,1212364800"; d="scan'208,217";a="123022319" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 06 Jul 2008 15:53:58 +0000 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/8.12.11) with ESMTP id m66FrwWE014668; Sun, 6 Jul 2008 08:53:58 -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.13.8/8.13.8) with ESMTP id m66FrwUF002505; Sun, 6 Jul 2008 15:53:58 GMT 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.1830); Sun, 6 Jul 2008 08:53:58 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 6 Jul 2008 08:53:58 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2048211EB@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New Issue 138: Inconsistent values for enable/disable in section 4.6.34 Thread-Index: AcjfbPrQQsBbUdM5TnGkvkytcE+5FQAE4WX4 From: "Pat Calhoun (pacalhou)" To: "Margaret Wasserman" X-OriginalArrivalTime: 06 Jul 2008 15:53:58.0644 (UTC) FILETIME=[8099F340:01C8DF80] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] New Issue 138: Inconsistent values for enable/disable in section 4.6.34 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="===============1015506498==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============1015506498== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8DF80.8050F1D4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8DF80.8050F1D4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One possible optimization, which is editorial but world provide more = consistency, is to define CAPWAP-ENABLE and CAPWAP-DISABLE and use that = terminology throughout the docs. PatC -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com] Sent: Sunday, July 06, 2008 06:34 AM Pacific Standard Time To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Re: [Capwap] New Issue 138: Inconsistent values for = enable/disable in section 4.6.34 Personally, I am a bit queasy about the idea of swapping these values =20 in a new version of the draft. However, I agree that the current =20 situation is far from ideal... So, I do support this change, but I wish we could come up with a =20 better answer. Margaret On Jul 1, 2008, at 4:05 PM, Pat Calhoun (pacalhou) wrote: > All, > > Yong has raised another issue, but I'm not sure that this one will =20 > have > the required > consensus as it will break compatibility with existing implementations > that conform to > -10. > > Section 4.6.34 uses 1 for disable and 2 for enable, while the rest of > the spec uses the > inverse. This inconsistency could be confusing for people using > #DEFINEs. Is there > agreement to inversing these values, with the understanding that it > would create a > backward compatibility issue with -10? > > PatC > _________________________________________________________________ > 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_01C8DF80.8050F1D4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Capwap] New Issue 138: Inconsistent values for = enable/disable in section 4.6.34

One possible optimization, which is editorial but = world provide more consistency, is to define CAPWAP-ENABLE and = CAPWAP-DISABLE and use that terminology throughout the docs.


PatC

 -----Original Message-----
From:   Margaret Wasserman [mailto:margaret@thingmagic.com]
Sent:   Sunday, July 06, 2008 06:34 AM Pacific Standard = Time
To:     Pat Calhoun (pacalhou)
Cc:     capwap@frascone.com
Subject:        Re: [Capwap] New = Issue 138: Inconsistent values for enable/disable in section 4.6.34

Personally, I am a bit queasy about the idea of swapping these = values 
in a new version of the draft.  However, I agree that the = current 
situation is far from ideal...

So, I do support this change, but I wish we could come up with = a 
better answer.

Margaret


On Jul 1, 2008, at 4:05 PM, Pat Calhoun (pacalhou) wrote:

> All,
>
> Yong has raised another issue, but I'm not sure that this one = will 
> have
> the required
> consensus as it will break compatibility with existing = implementations
> that conform to
> -10.
>
> Section 4.6.34 uses 1 for disable and 2 for enable, while the rest = of
> the spec uses the
> inverse. This inconsistency could be confusing for people using
> #DEFINEs. Is there
> agreement to inversing these values, with the understanding that = it
> would create a
> backward compatibility issue with -10?
>
> PatC
> = _________________________________________________________________
> 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_01C8DF80.8050F1D4-- --===============1015506498== 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 --===============1015506498==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Jul 6 08:57:35 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8B3B3A68C9 for ; Sun, 6 Jul 2008 08:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CTTIve9Dv0V for ; Sun, 6 Jul 2008 08:57:35 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 0D8F83A6837 for ; Sun, 6 Jul 2008 08:57:35 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 31955432692 for ; Sun, 6 Jul 2008 08:57:39 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 44FCA4400ED for ; Sun, 6 Jul 2008 08:57:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 1F92A34AC055 for ; Sun, 6 Jul 2008 08:57:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0A25D34AC03D for ; Sun, 6 Jul 2008 08:57:30 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Sender first seen 19 days 21:53:52 ago / dynamic or unknown reverse DNS) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by mx1.tigertech.net (Postfix) with ESMTP for ; Sun, 6 Jul 2008 08:57:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,311,1212379200"; d="scan'208";a="113772764" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 06 Jul 2008 11:57:28 -0400 X-IronPort-AV: E=Sophos;i="4.30,311,1212379200"; d="scan'208";a="223407748" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 06 Jul 2008 11:57:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 6 Jul 2008 17:57:12 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New Issue 138: Inconsistent values for enable/disablein section 4.6.34 Thread-Index: AcjfbPwpqJ8yTntZTT6JujYObvCQ4wAE5Qgg References: <4FF84B0BC277FF45AA27FE969DD956A20607BBDF@xmb-sjc-235.amer.cisco.com> From: "Romascanu, Dan (Dan)" To: "Margaret Wasserman" , "Pat Calhoun" Cc: capwap@frascone.com Subject: Re: [Capwap] New Issue 138: Inconsistent values for enable/disablein section 4.6.34 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 I missed this. I agree with Yong's comment. I support the change with all inconvenience caused to existing implementations. Dan > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Sunday, July 06, 2008 4:34 PM > To: Pat Calhoun > Cc: capwap@frascone.com > Subject: Re: [Capwap] New Issue 138: Inconsistent values for > enable/disablein section 4.6.34 > > Personally, I am a bit queasy about the idea of swapping > these values in a new version of the draft. However, I agree > that the current situation is far from ideal... > > So, I do support this change, but I wish we could come up > with a better answer. > > Margaret > > > On Jul 1, 2008, at 4:05 PM, Pat Calhoun (pacalhou) wrote: > > > All, > > > > Yong has raised another issue, but I'm not sure that this one will > > have the required consensus as it will break compatibility with > > existing implementations that conform to -10. > > > > Section 4.6.34 uses 1 for disable and 2 for enable, while > the rest of > > the spec uses the inverse. This inconsistency could be > confusing for > > people using #DEFINEs. Is there agreement to inversing > these values, > > with the understanding that it would create a backward > compatibility > > issue with -10? > > > > PatC > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/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 Jul 7 04:07:58 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E390028C157 for ; Mon, 7 Jul 2008 04:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9O7rO8BeQcx for ; Mon, 7 Jul 2008 04:07:57 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id DFD6628C151 for ; Mon, 7 Jul 2008 04:07:57 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4481E430DB3 for ; Mon, 7 Jul 2008 04:08:04 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 2FB1C44012E for ; Mon, 7 Jul 2008 04:07:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0507534AC016 for ; Mon, 7 Jul 2008 04:07:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2E9C334AC055 for ; Mon, 7 Jul 2008 04:07:54 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 04:07:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,315,1212364800"; d="scan'208";a="49432064" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 07 Jul 2008 11:07:49 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m67B7nLE006865; Mon, 7 Jul 2008 04:07:49 -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.13.8/8.13.8) with ESMTP id m67B7nx6018902; Mon, 7 Jul 2008 11:07:49 GMT 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.1830); Mon, 7 Jul 2008 04:07:49 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 04:07:48 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D15BB@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New Issue 138: Inconsistent values for enable/disable in section 4.6.34 Thread-Index: AcjfbPrQQsBbUdM5TnGkvkytcE+5FQAtJOtw References: <4FF84B0BC277FF45AA27FE969DD956A20607BBDF@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Margaret Wasserman" X-OriginalArrivalTime: 07 Jul 2008 11:07:49.0731 (UTC) FILETIME=[B18B7B30:01C8E021] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] New Issue 138: Inconsistent values for enable/disable in section 4.6.34 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 Ok, I've gone ahead with the change, which is now consistent with other uses of enable/disable and looks like: 4.6.34. Radio Operational State [...] State: An 8-bit boolean value representing the state of the radio. The following enumerated values are supported: 0 - Reserved 1 - Enabled 2 - Disabled PatC -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com] Sent: Sunday, July 06, 2008 6:34 AM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Re: [Capwap] New Issue 138: Inconsistent values for enable/disable in section 4.6.34 Personally, I am a bit queasy about the idea of swapping these values in a new version of the draft. However, I agree that the current situation is far from ideal... So, I do support this change, but I wish we could come up with a better answer. Margaret On Jul 1, 2008, at 4:05 PM, Pat Calhoun (pacalhou) wrote: > All, > > Yong has raised another issue, but I'm not sure that this one will > have the required consensus as it will break compatibility with > existing implementations that conform to -10. > > Section 4.6.34 uses 1 for disable and 2 for enable, while the rest of > the spec uses the inverse. This inconsistency could be confusing for > people using #DEFINEs. Is there agreement to inversing these values, > with the understanding that it would create a backward compatibility > issue with -10? > > PatC > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 7 04:21:11 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B14728C199 for ; Mon, 7 Jul 2008 04:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1--PQo7eGAF for ; Mon, 7 Jul 2008 04:21:09 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id CF7173A6A9C for ; Mon, 7 Jul 2008 04:21:09 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 393DA430E30 for ; Mon, 7 Jul 2008 04:21:16 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 7E77544012B for ; Mon, 7 Jul 2008 04:21:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 10DDB34AC05C for ; Mon, 7 Jul 2008 04:21:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E4FD434AC02A for ; Mon, 7 Jul 2008 04:21:05 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 04:21:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,315,1212364800"; d="scan'208";a="123304527" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 07 Jul 2008 11:21:05 +0000 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/8.12.11) with ESMTP id m67BL5nc021765; Mon, 7 Jul 2008 04:21:05 -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.13.8/8.13.8) with ESMTP id m67BL5Ip012277; Mon, 7 Jul 2008 11:21:05 GMT 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, 7 Jul 2008 04:21:04 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 04:21:03 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D15BC@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] FSM issues Thread-Index: AcjdTRmoWlSHp4GXRh6WsrNPedjeHwC1apfw References: <4FF84B0BC277FF45AA27FE969DD956A2060D131F@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Yong Zhang" X-OriginalArrivalTime: 07 Jul 2008 11:21:04.0841 (UTC) FILETIME=[8B77A390:01C8E023] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] FSM issues 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 4. Run to Run. I now understand the point you are trying to make. The text for Clear Configuration Request/Response is not consistent with the other commands in this section. I am proposing the following changes, which does not change any behavior, but only creates more consistency in the text: Run to Run (q): This is the normal state of operation. WTP: This is the WTP's normal state of operation. There are many events that result this state transition: [...] Clear Config Request: The WTP receives a Clear Configuration Request message (see Section 8.8) and MUST generate a corresponding Clear Configuration Response message (see Section 8.9). The WTP MUST reset its configuration back to manufacturer defaults. [...] AC: This is the AC's normal state of operation: [...] Clear Config Response: The AC sends a Clear Configuration Request message (see Section 8.8) to the WTP to clear its configuration. The AC receives a Clear Configuration Response message from the WTP (see Section 8.9). 5. Unfortunately, I'm still not understanding the issue you are trying to raise. I am not claiming that the AC sends echo requests, I am simply stating that requests (in general) can be transmitted by either the WTP or the AC, while certain requests may have restrictions which are clearly documented in the spec. So regardless of whether a request is an echo request, or any other request, the retransmission, and subsequent timeout, is the same. Therefore there is no need to add a specific clause for echo requests timing out. PatC -----Original Message----- From: Yong Zhang [mailto:yozhang@gmail.com] Sent: Thursday, July 03, 2008 1:41 PM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Re: [Capwap] FSM issues >> 4. Run to Run (q): AC >> >> Clear Config Response: The AC receives a Clear Configuration >> Response message from the WTP (see Section 8.9). >> >> Need to add Clear Configuration REQ send. > I'm not sure that I understand what you are saying. This event occurs > when the response is received. The Request was sent some time ago, > hence why the response was received. The receive of the Clear Config > Request is handled in the WTP section, and is present already. Refer to other messages description in AC RUN state: Ac need to send out the REQ, and AC need to receive RESP. Just WTP clear Config Response also has the problem. >> 5. Run to DTLS Teardown (p) maybe need to add echo failure case. >> >> "transitions to this state if the underlying reliable >> transport's RetransmitCount counter has reached the >> MaxRetransmit variable (see Section 4.7)." >> >> This can cover WTP, but not AC. > The echo would cause a retransmission timeout, which makes use of the > RetransmitCount counter. I guess I'm not sure that I understand the > issue you are trying to raise. Both the WTP and the AC can transmit > requests, so it is possible that either side timeouts, forcing this > state transition. > I only see the WTP sends REQ, and AC recvs RESP. Where is it said that AC also sends ECHO REQ? On Thu, Jul 3, 2008 at 1:22 PM, Pat Calhoun (pacalhou) wrote: > I have created issue 139 to track these issues. > >> 1. waitDTLS is not started in the 2.3.1 CAPWAP Proto State > Transitions, although it is said in CAPWAP/DTLS interface >> chapter. > Yes, you are correct. The description for the StartDTLS command is > clear that the WaitDTLS timer needs to be started, but it would be > worth including this in the state transition description, as all of > the other timers are also included in that section. > > > Idle to DTLS Setup (3): This transition occurs to establish a secure > DTLS session with the peer. > > WTP: The WTP initiates this transition by invoking the DTLSStart > command(see Section 2.3.2.1), which starts the DTLS session > establishment with the chosen AC and the WaitDTLS timer is > started (see Section 4.7). When the discovery phase is > bypassed, it is assumed the WTP has locally configured ACs. > > >> 2. Join REQ need to be send at here. >> >> DTLS Connect to Join (d): This transition occurs when the DTLS >> Session is successfully established. >> >> WTP: This state transition occurs when the WTP receives the >> DTLSEstablished notification (see Section 2.3.2.2), indicating >> that the DTLS session was successfully established. When this >> notification is received, the FailedDTLSSessionCount counter > is >> set to zero. > Yes, this was a strange omission - an obvious thing to do, but it > needs to be very clear. > > > DTLS Connect to Join (d): This transition occurs when the DTLS > Session is successfully established. > > WTP: This state transition occurs when the WTP receives the > DTLSEstablished notification (see Section 2.3.2.2), indicating > that the DTLS session was successfully established. When this > notification is received, the FailedDTLSSessionCount counter is > set to zero. The WTP enters the Join state by transmiting the > Join Request to the AC. > > >> 3. >> Data Check to DTLS Teardown (n): This transition occurs when the WTP >> does not complete the Data Check exchange. >> >> WTP: This state transition occurs if the WTP does not receive > the >> Change State Event Response message before a CAPWAP >> transmission timeout occurs. >> >> Does the above need to be change to something like > RetransmitCount >> counter has reached the MaxRetransmit variable? Since we do not use > transmission timeout timer. > Yes, good point. I am including the same text we have in other state > transitions. > > > Data Check to DTLS Teardown (n): This transition occurs when the WTP > does not complete the Data Check exchange. > > WTP: This state transition occurs if the WTP does not receive the > Change State Event Response message before a CAPWAP > retransmission timeout occurs. The WTP also transitions to > this state if the underlying reliable transport's > RetransmitCount counter has reached the MaxRetransmit variable > (see Section 4.7). > > >> 4. Run to Run (q): AC >> >> Clear Config Response: The AC receives a Clear Configuration >> Response message from the WTP (see Section 8.9). >> >> Need to add Clear Configuration REQ send. > I'm not sure that I understand what you are saying. This event occurs > when the response is received. The Request was sent some time ago, > hence why the response was received. The receive of the Clear Config > Request is handled in the WTP section, and is present already. > >> 5. Run to DTLS Teardown (p) maybe need to add echo failure case. >> >> "transitions to this state if the underlying reliable >> transport's RetransmitCount counter has reached the >> MaxRetransmit variable (see Section 4.7)." >> >> This can cover WTP, but not AC. > The echo would cause a retransmission timeout, which makes use of the > RetransmitCount counter. I guess I'm not sure that I understand the > issue you are trying to raise. Both the WTP and the AC can transmit > requests, so it is possible that either side timeouts, forcing this > state transition. > > PatC > > -----Original Message----- > From: Yong Zhang [mailto:yozhang@gmail.com] > Sent: Thursday, July 03, 2008 11:48 AM > To: capwap@frascone.com > Subject: [Capwap] FSM issues > > 1. waitDTLS is not started in the 2.3.1 CAPWAP Proto State > Transitions, although it is said in CAPWAP/DTLS interface chapter. > > 2. Join REQ need to be send at here. > > DTLS Connect to Join (d): This transition occurs when the DTLS > Session is successfully established. > > WTP: This state transition occurs when the WTP receives the > DTLSEstablished notification (see Section 2.3.2.2), indicating > that the DTLS session was successfully established. When this > notification is received, the FailedDTLSSessionCount counter is > set to zero. > > 3. > Data Check to DTLS Teardown (n): This transition occurs when the WTP > does not complete the Data Check exchange. > > WTP: This state transition occurs if the WTP does not receive the > Change State Event Response message before a CAPWAP > transmission timeout occurs. > > Does the above need to be change to something like RetransmitCount > counter has reached the MaxRetransmit variable? Since we do not use > transmission timeout timer. > > 4. Run to Run (q): AC > > Clear Config Response: The AC receives a Clear Configuration > Response message from the WTP (see Section 8.9). > > Need to add Clear Configuration REQ send. > > 5. Run to DTLS Teardown (p) maybe need to add echo failure case. > > "transitions to this state if the underlying reliable > transport's RetransmitCount counter has reached the > MaxRetransmit variable (see Section 4.7)." > > This can cover WTP, but not AC. > > > Yong > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 7 04:27:51 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD06D3A6A9A for ; Mon, 7 Jul 2008 04:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVeBiXOOYePF for ; Mon, 7 Jul 2008 04:27:50 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id C43FD3A6A94 for ; Mon, 7 Jul 2008 04:27:50 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 39580430DDA for ; Mon, 7 Jul 2008 04:27:57 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id E945E44012B for ; Mon, 7 Jul 2008 04:27:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C387F34AC02A for ; Mon, 7 Jul 2008 04:27:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D7FE634AC030 for ; Mon, 7 Jul 2008 04:27:46 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 04:27:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,315,1212364800"; d="scan'208";a="49440104" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 07 Jul 2008 11:27:46 +0000 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/8.12.11) with ESMTP id m67BRk4i032688; Mon, 7 Jul 2008 04:27:46 -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.13.8/8.13.8) with ESMTP id m67BRkIF027024; Mon, 7 Jul 2008 11:27:46 GMT 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.1830); Mon, 7 Jul 2008 04:27:46 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 04:27:45 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D15C0@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Issue 106: WaitJoin may be unnecessary Thread-Index: AcjbuiZ3xpoLTquBTRyKk+KGoxo8NQEaboWg References: <4FF84B0BC277FF45AA27FE969DD956A205F5CDE6@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A205FDD776@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Yong Zhang" X-OriginalArrivalTime: 07 Jul 2008 11:27:46.0360 (UTC) FILETIME=[7ACA9380:01C8E024] Authentication-Results: sj-dkim-4; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] New Issue 106: WaitJoin may be 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 All, Here is the actual text handling this change, which I have reviewed with Yong and he has responded that he is OK with the change. The AC in the spec was using the WaitJoin timer, so I had to make a couple of changes to two state transisions to make sure that the AC was making proper use of the WaitDTLS timer: Idle to DTLS Setup (3): This transition occurs to establish a secure DTLS session with the peer. WTP: The WTP initiates this transition by invoking the DTLSStart command(see Section 2.3.2.1), which starts the DTLS session establishment with the chosen AC and the WaitDTLS timer is started (see Section 4.7). When the discovery phase is bypassed, it is assumed the WTP has locally configured ACs. AC: Upon entering the Idle state from the Start state, the newly created Listener thread automatically transitions to the DTLS Setup and invokes the DTLSListen command (see Section 2.3.2.1), and the WaitDTLS timer is started (see Section 4.7). <===== THE TIMER IS STARTED Join to DTLS Teardown (e): This transition occurs when the join process failed. WTP: This state transition occurs when the WTP receives a Join Response message with a Result Code message element containing an error, if the Image Identifier provided by the AC in the Join Response message differs from the WTP's currently running firmware version and the WTP has the requested image in its non-volatile memory, or if the WaitDTLS timer expires. This causes the WTP to initiate the DTLSShutdown command (see Section 2.3.2.1). This transition also occurs if the WTP receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect. AC: This state transition occurs either if the WaitDTLS timer <=== THE TIMER EXPIRES expires or if the AC transmits a Join Response message with a Result Code message element containing an error. This causes the AC to initiate the DTLSShutdown command (see Section 2.3.2.1). This transition also occurs if the AC receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect. PatC -----Original Message----- From: Yong Zhang [mailto:yozhang@gmail.com] Sent: Tuesday, July 01, 2008 1:37 PM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Re: New Issue 106: WaitJoin may be unnecessary This change is OK for me. Yong On Thu, Jun 26, 2008 at 4:53 AM, Pat Calhoun (pacalhou) wrote: > I believe you may be correct that there is a technical issue. > > Originally, the WaitJoin was used to timeout if the WTP did not sent > the Join Request, or the AC did not send the Join Response. However, > when DTLS was introduced, we started to rely on the WaitDTLS timer. It > seems like we've started to rely much more on the WaitDTLS timer in > the latter drafts, to the point where I believe that we could simply > remove the WaitJoin timer and have little impact to the state machine. > > From what I can tell, the "Join to DTLS Teardown (e)" state transition > currently triggers if the WaitJoin timer expires, and we would have to > change this to WaitDTLS instead. Further, the "DTLS Connect to Join (d)" > state transition would simply need to have its reference to WaitJoin > removed. > > So since it appears as if the WaitDTLS timers are initialized > properly, the timeout triggers are properly defined, and it is well > specified in its handling during the Join Request/Response in section > 6.1 and 6.2, this change would have mimimal impact. > > Thoughts? > > PatC > > -----Original Message----- > From: Yong Zhang [mailto:yozhang@gmail.com] > Sent: Friday, June 20, 2008 11:19 AM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: Re: [Capwap] WaitDTLS/WaitJoin timers > indraft-ietf-capwap-protocol-specification-10.txt > > This info is clear. But in the spec., the WaitDTLS covers the WaitJoin. > WairDTLS timer is not cleared after the DTLS session is esatblished, > but it is only cleared after the Join REQ/RESP are received. (6.1/2 > describes this). > > Thanks! > > Yong > > On Fri, Jun 20, 2008 at 10:55 AM, Pat Calhoun (pacalhou) > wrote: >> The intent for both timers is: >> >> WaitDTLS: This timer is used to make sure that the DTLS session is >> established within the required timeframe. If the DTLS session isn't >> setup, perhaps because either party is not responding, then the timer >> will trigger and the state will change. >> >> WaitJoin: Once the DTLS session has been established, we need to >> protect against a WTP that opts to NOT send a Join Request. So in >> this > >> instance, the WaitJoin would trigger, and the state would once more > change. >> >> PatC >> >> -----Original Message----- >> From: Yong Zhang [mailto:yozhang@gmail.com] >> Sent: Friday, June 20, 2008 9:54 AM >> To: capwap@frascone.com >> Subject: [Capwap] WaitDTLS/WaitJoin timers >> indraft-ietf-capwap-protocol-specification-10.txt >> >> WaitDTLS by its name should be DTLS session setup related, but this >> spec. (6.1/2) requires it deactivated after the Join Req/Resp are >> received. >> >> WaitJoin seems no use in this case?? >> >> Also the WaitDTLS timer is started earlier than WaitJoin timer, >> however, the default value for these two timers (4.7.15/16) are all >> 60s. if WaitJoin has some other use, it need to have a less value >> than > >> WaitDTLS to work. >> >> Yong >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap >> > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 7 04:34:44 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D760E28C1C9 for ; Mon, 7 Jul 2008 04:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMM9gVyDkQPM for ; Mon, 7 Jul 2008 04:34:44 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 1540528C1A4 for ; Mon, 7 Jul 2008 04:34:44 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8632D430E24 for ; Mon, 7 Jul 2008 04:34:50 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 1BDEA440125 for ; Mon, 7 Jul 2008 04:34:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4833D34AC03D for ; Mon, 7 Jul 2008 04:34:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5B70634AC02A for ; Mon, 7 Jul 2008 04:34:39 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 04:34:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,315,1212364800"; d="scan'208";a="123308314" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 07 Jul 2008 11:34:39 +0000 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/8.12.11) with ESMTP id m67BYdMT023679; Mon, 7 Jul 2008 04:34:39 -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.13.8/8.13.8) with ESMTP id m67BYdOB007826; Mon, 7 Jul 2008 11:34:39 GMT 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, 7 Jul 2008 04:34:39 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 04:34:38 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D15C1@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UDP IANA port Thread-Index: AcjdVYmHF2jMyAZ8SrOiP0Byc+qPOgCz3nag References: From: "Pat Calhoun (pacalhou)" To: "Yong Zhang" X-OriginalArrivalTime: 07 Jul 2008 11:34:39.0063 (UTC) FILETIME=[70C80E70:01C8E025] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] UDP IANA port 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 Yes, I had applied for the UDP ports and was planning on making the change after IETF Last Call, but we can make the change now given that I need to rev the spec anyhow. I have created issue 142 to track this request. Here is the new text: 3.1. UDP Transport [...] CAPWAP protocol control packets sent from the WTP to the AC use the CAPWAP control channel, as defined in Section 1.4. The CAPWAP control port at the AC is the well known UDP port 5246. The CAPWAP control port at the WTP can be any port selected by the WTP. CAPWAP protocol data packets sent from the WTP to the AC use the CAPWAP data channel, as defined in Section 1.4. The CAPWAP data port at the AC is the well known UDP port 5247. The CAPWAP data port at the WTP can be any port selected by the WTP. I guess this ALSO means that I have to REMOVE the following text in the IANA considerations section: A separate UDP port for data channel communications is (currently) the selected demultiplexing mechanism, and a port must be assigned for this purpose in Section 3.1. The UDP port numbers are listed by IANA at http://www.iana.org/assignments/port-numbers. PatC -----Original Message----- From: Yong Zhang [mailto:yozhang@gmail.com] Sent: Thursday, July 03, 2008 2:41 PM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: UDP IANA port I saw from the mail archive that UDP ports had been allocated by IANA, but the spec. doc. is not updated. Yong The CAPWAP control port at the AC is the well known UDP port [to be IANA assigned]. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 7 08:17:11 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E69663A69EC for ; Mon, 7 Jul 2008 08:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9twLTmYsFew7 for ; Mon, 7 Jul 2008 08:17:11 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 03E993A6A3C for ; Mon, 7 Jul 2008 08:17:09 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CA5554328BE for ; Mon, 7 Jul 2008 08:17:16 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 800A044012B for ; Mon, 7 Jul 2008 06:42:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 229E334AC029 for ; Mon, 7 Jul 2008 06:42:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0F08134AC05D for ; Mon, 7 Jul 2008 06:42:24 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (64.102.122.149 whitelisted by list.dnswl.org 9.2) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 06:42:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,316,1212364800"; d="scan'208,223";a="13397808" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 07 Jul 2008 13:42:15 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m67DgFWC008171; Mon, 7 Jul 2008 09:42:15 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m67DgFkE003255; Mon, 7 Jul 2008 13:42:15 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jul 2008 09:42:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 09:42:16 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB2107EDAB83@xmb-rtp-20a.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Fwd: Last Call: draft-ietf-capwap-dhc-ac-option (CAPWAPAccess Controller DHCP Option) to Proposed Standard Thread-Index: AcjaqhViqshp/U/pSn+dw2UjOxggwgFjQZWA From: "Bernie Volz (volz)" To: "DHC WG" X-OriginalArrivalTime: 07 Jul 2008 13:42:15.0537 (UTC) FILETIME=[44654610:01C8E037] Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Mailman-Approved-At: Mon, 07 Jul 2008 08:17:03 -0700 Cc: capwap@frascone.com Subject: Re: [Capwap] [dhcwg] Fwd: Last Call: draft-ietf-capwap-dhc-ac-option (CAPWAPAccess Controller DHCP Option) to Proposed Standard 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 >From a DHCP option definition perspective, I see no issues. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ralph Droms (rdroms) Sent: Monday, June 30, 2008 8:08 AM To: DHC WG Subject: [dhcwg] Fwd: Last Call: draft-ietf-capwap-dhc-ac-option (CAPWAPAccess Controller DHCP Option) to Proposed Standard Please review this document, especially for DHCP-related issues, and comment to ietf@ietf.org - Ralph Begin forwarded message: > From: The IESG > Date: June 30, 2008 8:04:37 AM EDT > To: IETF-Announce > Cc: capwap@frascone.com > Subject: Last Call: draft-ietf-capwap-dhc-ac-option (CAPWAP Access > Controller DHCP Option) to Proposed Standard > Reply-To: ietf@ietf.org > > The IESG has received a request from the Control And Provisioning of > Wireless Access Points WG (capwap) to consider the following document: > > - 'CAPWAP Access Controller DHCP Option ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the > ietf@ietf.org mailing lists by 2008-07-14. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-capwap-dhc-ac-option-01.t xt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag= 16353&rfc_flag=0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 7 09:16:37 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1DEC3A6AE0 for ; Mon, 7 Jul 2008 09:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wetgOmGr0yTJ for ; Mon, 7 Jul 2008 09:16:36 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 247BE3A6ADF for ; Mon, 7 Jul 2008 09:16:17 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F360D432BE7 for ; Mon, 7 Jul 2008 09:16:23 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 8028A44002B for ; Mon, 7 Jul 2008 09:16:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3D8CE34AC05D for ; Mon, 7 Jul 2008 09:16:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3298934AC05B for ; Mon, 7 Jul 2008 09:16:09 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 09:16:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,317,1212364800"; d="scan'208";a="63242194" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 07 Jul 2008 16:14:02 +0000 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/8.12.11) with ESMTP id m67GE25G030924; Mon, 7 Jul 2008 09:14:02 -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.13.8/8.13.8) with ESMTP id m67GE1kU024399; Mon, 7 Jul 2008 16:14:02 GMT 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.1830); Mon, 7 Jul 2008 09:14:01 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 09:13:59 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D1661@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More ME issues Thread-Index: AcjdU6CzP/Yt9/j3THOPyauVXmh3IwC0gi/A References: <4FF84B0BC277FF45AA27FE969DD956A2060D1378@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Yong Zhang" X-OriginalArrivalTime: 07 Jul 2008 16:14:01.0795 (UTC) FILETIME=[7825F930:01C8E04C] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] More ME issues 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 > >> 6.2 Join Response > >> Should MUST ME be defined earlier than MAY ME? > > This doesn't really break anything. I'm not sure we need to address > > this. > I saw other message definitions always put MUST MEs in the beginning. Well, I think this is really a nice to have, but while looking at the issue you are pointing out, I *just* noticed that there is a cut/paste error in this section since the text includes: One of the following message elements MUST be included in the Discovery Response Message: Clearly, that should have been a Join Response, so since I'm add it, I will reorder the text to make sure that it is consistent with the rest of the message definitions, and fix the cut/paste error. > > > 9.7 Data Transfer Response > > > > Upon receipt of a Data Transfer Response message, the WTP transmits > > more information, if more information is available. > > > > What's this meaning of this? If the crash data or memory dump is too > large, WTP will segment them, and transfer them > > using multiple Data transfer req messages. > > The AC should maintain the > > data offset by itself? Or you want to say, the WTP will first sent > > crash dump. It will send the memory > > dump after it receives the response? > Yes, this is a series of back and forth, where the WTP will, if necessary, break the information to be sent across > multiple packets. The CAPWAP transmission layer will ensure it is reassembled in the proper order. Maybe I'm not > understanding the question you are asking. > > then how the AC knows it has received all the debug data from the WTP? I see the point you are raising, and this is something we fixed for the image transfer. Because of the scope of the issue, I will create a separate issue to track this one. So let's continue this conversation in a separate thread, which I will initiate shortly. PatC > > Yong On Thu, Jul 3, 2008 at 2:11 PM, Pat Calhoun (pacalhou) wrote: > I have created Issue 141 to track these issues. > >> 4.6.36 >=1 to >=6 this is an error. >> >> 1(reason) + 1(length) + 2(me type) + 2(me len) > You raised this already in issue 140, so I am claiming it is a > duplicate and rejecting this one. > >> 4.6.37 len should be 4. > Yes, this is a bug. It needs to be 4. > >> 4.6.40 should be >= 22 >> >> 4 (Vendor ID) + 4+4+1 (Model Number) + 4+4+1(Serial Number) > > No, the correct value is in fact 14 since the Vendor ID is only > presence once, not once for each sub-element. The sub-element mentions > that two board elements MUST be present, which is 14 octets. > >> 4.6.47 >0 to >=1 > Again, I don't see a problem here, but will make the change if you > think it is clearer. > >> 4.6.34 should define the "State" use a similar way used by 4.6.50 > define the 'Static" > This would break interoperability, as it would change the values used. > I'd like to make sure that no one objects to break -10 compatibility. > This is a fairly small nit. > >> 4.8.5 IdleTimeout is a timer. maybe need to be put into 4.7 > Yes, that probably makes sense. > >> 4.7.11 ResponseTimeout, and 4.7.16 WaitJoin can be removed, since >> they > are not used any more. > PAT WAITING ON YONG's RESPONSE. > >> 6.2 Join Response >> Should MUST ME be defined earlier than MAY ME? > This doesn't really break anything. I'm not sure we need to address > this. > > >> 8.9 Clear Config Response: >> >> The Clear Configuration Request message MUST include the following >> message element. >> >> o Result Code, see Section 4.6.35 >> >> Shoule be RESPONSE here. > Correct. This is a valid editorial issue. > >> 9.1 Figure 7. Is this a reasonable case? >> >> If images are same, the WTP will go into Configure state. > > No, actually the text was not providing enough information. The text > is > now: > > Figure 7 provides an example in which the WTP has the image specified > by the AC in its non-volative storage, but is not its current running > image. In this case, the WTP opts to NOT download the firmware and > immediately reset to the requested image. > > >> 9.1.1 >> >> The decision that new firmware is to be downloaded to the WTP can >> occur in one of two ways: >> >> When the WTP joins the AC, the Join Response message includes > the >> Image Identifier message element, which informs the WTP of the >> firmware it is expected to run. if the WTP does not currently > have >> the requested firmware version, it transmits an Image Data > Request >> message, with the appropriate Image Identifier message element. >> If the WTP already has the requested firmware, it simply resets. >> >> Remove "If the WTP already has the requested firmware, it simply > resets."? > Again, the text was not sufficient. It now reads: > > > If the WTP already has > the requested firmware in its non-volatile flash, but > is not its > currently running image, it simply resets to run the > proper firmware. > > >> 9.6 Data transfer req >> >> What's the use of Data transfer mode 4.6.17? The Data Transfer Data > has the mode field. > That is very repetitive, and unnecessary. I would propose removing the > mode from 4.6.16, and simply using the message element defined in > 4.6.17. I checked, and it is ONLY used during the data transfer > request, so I do not see any harm. However, this breaks -10, and is > only repetitive. I want to make sure that there are no concerns in > making this change from others in the WG. > >> 9.7 Data Transfer Response >> >> Upon receipt of a Data Transfer Response message, the WTP transmits >> more information, if more information is available. >> >> What's this meaning of this? If the crash data or memory dump is too > large, WTP will segment them, and transfer them >> using multiple Data transfer req messages. >> The AC should maintain the >> data offset by itself? Or you want to say, the WTP will first sent >> crash dump. It will send the memory >> dump after it receives the response? > Yes, this is a series of back and forth, where the WTP will, if > necessary, break the information to be sent across multiple packets. > The CAPWAP transmission layer will ensure it is reassembled in the > proper order. Maybe I'm not understanding the question you are asking. > > PatC > > -----Original Message----- > From: Yong Zhang [mailto:yozhang@gmail.com] > Sent: Thursday, July 03, 2008 1:31 PM > To: capwap@frascone.com > Subject: Re: [Capwap] ME issues > > 4.6.36 >=1 to >=6 this is an error. > > 1(reason) + 1(length) + 2(me type) + 2(me len) > > 4.6.37 len should be 4. > > 4.6.40 should be >= 22 > > 4 (Vendor ID) + 4+4+1 (Model Number) + 4+4+1(Serial Number) > > 4.6.47 >0 to >=1 > > 4.6.34 should define the "State" use a similar way used by 4.6.50 > define the 'Static" > > > 4.8.5 IdleTimeout is a timer. maybe need to be put into 4.7 > > 4.7.11 ResponseTimeout, and 4.7.16 WaitJoin can be removed, since they > are not used any more. > > 6.2 Join Response > Should MUST ME be defined earlier than MAY ME? > > 8.9 Clear Config Response: > > The Clear Configuration Request message MUST include the following > message element. > > o Result Code, see Section 4.6.35 > > Shoule be RESPONSE here. > > 9.1 Figure 7. Is this a reasonable case? > > If images are same, the WTP will go into Configure state. > > 9.1.1 > > The decision that new firmware is to be downloaded to the WTP can > occur in one of two ways: > > When the WTP joins the AC, the Join Response message includes the > Image Identifier message element, which informs the WTP of the > firmware it is expected to run. if the WTP does not currently have > the requested firmware version, it transmits an Image Data Request > message, with the appropriate Image Identifier message element. > If the WTP already has the requested firmware, it simply resets. > > Remove "If the WTP already has the requested firmware, it simply > resets."? > > 9.6 Data transfer req > > What's the use of Data transfer mode 4.6.17? The Data Transfer Data > has the mode field. > > 9.7 Data Transfer Response > > Upon receipt of a Data Transfer Response message, the WTP transmits > more information, if more information is available. > > What's this meaning of this? If the crash data or memory dump is too > large, WTP will segment them, and transfer them using multiple Data > transfer req messages. > The AC should maintain the > data offset by itself? Or you want to say, the WTP will first sent > crash dump. It will send the memory > dump after it receives the response? > > Yong > > On Thu, Jul 3, 2008 at 12:00 PM, Yong Zhang wrote: >> I saw some place define the me len use ">", and some place use ">=". >> Maybe we should unify them into one format. >> >> >> 4.6.4 > 0 to >= 1 >> >> 4.6.5 > 2 to >= 2 Here is an error!! >> >> 4.6.7 >> >> Num of Entries: The number of instances of the Type/MAC Addresses >> fields in the array. This value MUST NOT exceed 1024. >> >> 1024 should be 255. NOT exceed 255 mean it can be 255. >> >> 4.6.9 same as 4.6.7 >> 4.6.18 same as 4.6.7 >> >> 4.6.31 >0 to >=1 >> >> 4.6.36 >=1 to >=6 this is an error. >> > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 7 09:49:06 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5538D3A68D7 for ; Mon, 7 Jul 2008 09:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jcGMe58Kuss for ; Mon, 7 Jul 2008 09:49:05 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 028263A6A1C for ; Mon, 7 Jul 2008 09:49:05 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0433F432BEB for ; Mon, 7 Jul 2008 09:49:12 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 11F8F4400AF for ; Mon, 7 Jul 2008 09:48:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C522534AC023 for ; Mon, 7 Jul 2008 09:48:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 735C734AC002 for ; Mon, 7 Jul 2008 09:48:56 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.185]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 09:48:56 -0700 (PDT) Received: by rn-out-0910.google.com with SMTP id j71so464044rne.12 for ; Mon, 07 Jul 2008 09:48:55 -0700 (PDT) Received: by 10.142.173.14 with SMTP id v14mr1392047wfe.74.1215449335190; Mon, 07 Jul 2008 09:48:55 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Mon, 7 Jul 2008 09:48:55 -0700 (PDT) Message-ID: Date: Mon, 7 Jul 2008 09:48:55 -0700 From: "Yong Zhang" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2060D15BC@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <4FF84B0BC277FF45AA27FE969DD956A2060D131F@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D15BC@xmb-sjc-235.amer.cisco.com> Cc: capwap@frascone.com Subject: Re: [Capwap] FSM issues 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 I want to say for 5 is that: Only WTP sends echo request. So if the WTP is dead, the AC will not be able to receive the echo req, and this will trigger a failure event in AC side after some time. We need to add this event to FSM. Since AC does not send the req, " the retransmission, and subsequent timeout, ..." will not be used. Yong On Mon, Jul 7, 2008 at 4:21 AM, Pat Calhoun (pacalhou) wrote: > 4. Run to Run. I now understand the point you are trying to make. The > text for Clear Configuration Request/Response is not consistent with the > other commands in this section. I am proposing the following changes, > which does not change any behavior, but only creates more consistency in > the text: > > > Run to Run (q): This is the normal state of operation. > > WTP: This is the WTP's normal state of operation. There are many > events that result this state transition: > [...] > Clear Config Request: The WTP receives a Clear Configuration > Request message (see Section 8.8) and MUST generate a > corresponding Clear Configuration Response message (see > Section 8.9). The WTP MUST reset its configuration back to > manufacturer defaults. > [...] > AC: This is the AC's normal state of operation: > [...] > Clear Config Response: The AC sends a Clear Configuration > Request message (see Section 8.8) to the WTP to clear its > configuration. The AC receives a Clear Configuration > Response message from the WTP (see Section 8.9). > > > 5. Unfortunately, I'm still not understanding the issue you are trying > to raise. I am not claiming that the AC sends echo requests, I am simply > stating that requests (in general) can be transmitted by either the WTP > or the AC, while certain requests may have restrictions which are > clearly documented in the spec. So regardless of whether a request is an > echo request, or any other request, the retransmission, and subsequent > timeout, is the same. Therefore there is no need to add a specific > clause for echo requests timing out. > > PatC > -----Original Message----- > From: Yong Zhang [mailto:yozhang@gmail.com] > Sent: Thursday, July 03, 2008 1:41 PM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: Re: [Capwap] FSM issues > >>> 4. Run to Run (q): AC >>> >>> Clear Config Response: The AC receives a Clear Configuration >>> Response message from the WTP (see Section 8.9). >>> >>> Need to add Clear Configuration REQ send. >> I'm not sure that I understand what you are saying. This event occurs >> when the response is received. The Request was sent some time ago, >> hence why the response was received. The receive of the Clear Config >> Request is handled in the WTP section, and is present already. > > Refer to other messages description in AC RUN state: Ac need to send out > the REQ, and AC need to receive RESP. > Just WTP clear Config Response also has the problem. > > >>> 5. Run to DTLS Teardown (p) maybe need to add echo failure case. >>> >>> "transitions to this state if the underlying reliable >>> transport's RetransmitCount counter has reached the >>> MaxRetransmit variable (see Section 4.7)." >>> >>> This can cover WTP, but not AC. >> The echo would cause a retransmission timeout, which makes use of the >> RetransmitCount counter. I guess I'm not sure that I understand the >> issue you are trying to raise. Both the WTP and the AC can transmit >> requests, so it is possible that either side timeouts, forcing this >> state transition. >> > > I only see the WTP sends REQ, and AC recvs RESP. Where is it said that > AC also sends ECHO REQ? > > > On Thu, Jul 3, 2008 at 1:22 PM, Pat Calhoun (pacalhou) > wrote: >> I have created issue 139 to track these issues. >> >>> 1. waitDTLS is not started in the 2.3.1 CAPWAP Proto State >> Transitions, although it is said in CAPWAP/DTLS interface >>> chapter. >> Yes, you are correct. The description for the StartDTLS command is >> clear that the WaitDTLS timer needs to be started, but it would be >> worth including this in the state transition description, as all of >> the other timers are also included in that section. >> >> >> Idle to DTLS Setup (3): This transition occurs to establish a > secure >> DTLS session with the peer. >> >> WTP: The WTP initiates this transition by invoking the DTLSStart >> command(see Section 2.3.2.1), which starts the DTLS session >> establishment with the chosen AC and the WaitDTLS timer is >> started (see Section 4.7). When the discovery phase is >> bypassed, it is assumed the WTP has locally configured ACs. >> >> >>> 2. Join REQ need to be send at here. >>> >>> DTLS Connect to Join (d): This transition occurs when the DTLS >>> Session is successfully established. >>> >>> WTP: This state transition occurs when the WTP receives the >>> DTLSEstablished notification (see Section 2.3.2.2), > indicating >>> that the DTLS session was successfully established. When > this >>> notification is received, the FailedDTLSSessionCount counter >> is >>> set to zero. >> Yes, this was a strange omission - an obvious thing to do, but it >> needs to be very clear. >> >> >> DTLS Connect to Join (d): This transition occurs when the DTLS >> Session is successfully established. >> >> WTP: This state transition occurs when the WTP receives the >> DTLSEstablished notification (see Section 2.3.2.2), indicating >> that the DTLS session was successfully established. When this >> notification is received, the FailedDTLSSessionCount counter > is >> set to zero. The WTP enters the Join state by transmiting the >> Join Request to the AC. >> >> >>> 3. >>> Data Check to DTLS Teardown (n): This transition occurs when the WTP >>> does not complete the Data Check exchange. >>> >>> WTP: This state transition occurs if the WTP does not receive >> the >>> Change State Event Response message before a CAPWAP >>> transmission timeout occurs. >>> >>> Does the above need to be change to something like >> RetransmitCount >>> counter has reached the MaxRetransmit variable? Since we do not use >> transmission timeout timer. >> Yes, good point. I am including the same text we have in other state >> transitions. >> >> >> Data Check to DTLS Teardown (n): This transition occurs when the > WTP >> does not complete the Data Check exchange. >> >> WTP: This state transition occurs if the WTP does not receive > the >> Change State Event Response message before a CAPWAP >> retransmission timeout occurs. The WTP also transitions to >> this state if the underlying reliable transport's >> RetransmitCount counter has reached the MaxRetransmit variable >> (see Section 4.7). >> >> >>> 4. Run to Run (q): AC >>> >>> Clear Config Response: The AC receives a Clear Configuration >>> Response message from the WTP (see Section 8.9). >>> >>> Need to add Clear Configuration REQ send. >> I'm not sure that I understand what you are saying. This event occurs >> when the response is received. The Request was sent some time ago, >> hence why the response was received. The receive of the Clear Config >> Request is handled in the WTP section, and is present already. >> >>> 5. Run to DTLS Teardown (p) maybe need to add echo failure case. >>> >>> "transitions to this state if the underlying reliable >>> transport's RetransmitCount counter has reached the >>> MaxRetransmit variable (see Section 4.7)." >>> >>> This can cover WTP, but not AC. >> The echo would cause a retransmission timeout, which makes use of the >> RetransmitCount counter. I guess I'm not sure that I understand the >> issue you are trying to raise. Both the WTP and the AC can transmit >> requests, so it is possible that either side timeouts, forcing this >> state transition. >> >> PatC >> >> -----Original Message----- >> From: Yong Zhang [mailto:yozhang@gmail.com] >> Sent: Thursday, July 03, 2008 11:48 AM >> To: capwap@frascone.com >> Subject: [Capwap] FSM issues >> >> 1. waitDTLS is not started in the 2.3.1 CAPWAP Proto State >> Transitions, although it is said in CAPWAP/DTLS interface chapter. >> >> 2. Join REQ need to be send at here. >> >> DTLS Connect to Join (d): This transition occurs when the DTLS >> Session is successfully established. >> >> WTP: This state transition occurs when the WTP receives the >> DTLSEstablished notification (see Section 2.3.2.2), indicating >> that the DTLS session was successfully established. When this >> notification is received, the FailedDTLSSessionCount counter > is >> set to zero. >> >> 3. >> Data Check to DTLS Teardown (n): This transition occurs when the WTP >> does not complete the Data Check exchange. >> >> WTP: This state transition occurs if the WTP does not receive > the >> Change State Event Response message before a CAPWAP >> transmission timeout occurs. >> >> Does the above need to be change to something like RetransmitCount > >> counter has reached the MaxRetransmit variable? Since we do not use >> transmission timeout timer. >> >> 4. Run to Run (q): AC >> >> Clear Config Response: The AC receives a Clear Configuration >> Response message from the WTP (see Section 8.9). >> >> Need to add Clear Configuration REQ send. >> >> 5. Run to DTLS Teardown (p) maybe need to add echo failure case. >> >> "transitions to this state if the underlying reliable >> transport's RetransmitCount counter has reached the >> MaxRetransmit variable (see Section 4.7)." >> >> This can cover WTP, but not AC. >> >> >> Yong >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap >> > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 7 09:53:04 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EC7D3A6AC1 for ; Mon, 7 Jul 2008 09:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqzdfV-YI8uF for ; Mon, 7 Jul 2008 09:53:03 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 4E3353A6ABD for ; Mon, 7 Jul 2008 09:53:03 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 513554330F2 for ; Mon, 7 Jul 2008 09:53:10 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 34F8D4400AF for ; Mon, 7 Jul 2008 09:53:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0EBF334AC01D for ; Mon, 7 Jul 2008 09:53:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 483E234AC002 for ; Mon, 7 Jul 2008 09:52:59 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 09:52:59 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so2584172wfc.11 for ; Mon, 07 Jul 2008 09:52:59 -0700 (PDT) Received: by 10.143.2.19 with SMTP id e19mr1388222wfi.90.1215449577982; Mon, 07 Jul 2008 09:52:57 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Mon, 7 Jul 2008 09:52:57 -0700 (PDT) Message-ID: Date: Mon, 7 Jul 2008 09:52:57 -0700 From: "Yong Zhang" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2060D15C0@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <4FF84B0BC277FF45AA27FE969DD956A205F5CDE6@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A205FDD776@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D15C0@xmb-sjc-235.amer.cisco.com> Cc: capwap@frascone.com Subject: Re: [Capwap] New Issue 106: WaitJoin may be 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 This is OK. But I found another issue. We did not process the WaitDTLS timer expire event in the several DTLS states. Yong On Mon, Jul 7, 2008 at 4:27 AM, Pat Calhoun (pacalhou) wrote: > All, > > Here is the actual text handling this change, which I have reviewed with > Yong and he has responded that he is OK with the change. The AC in the > spec was using the WaitJoin timer, so I had to make a couple of changes > to two state transisions to make sure that the AC was making proper use > of the WaitDTLS timer: > > > Idle to DTLS Setup (3): This transition occurs to establish a secure > DTLS session with the peer. > > WTP: The WTP initiates this transition by invoking the DTLSStart > command(see Section 2.3.2.1), which starts the DTLS session > establishment with the chosen AC and the WaitDTLS timer is > started (see Section 4.7). When the discovery phase is > bypassed, it is assumed the WTP has locally configured ACs. > > AC: Upon entering the Idle state from the Start state, the newly > created Listener thread automatically transitions to the DTLS > Setup and invokes the DTLSListen command (see Section 2.3.2.1), > and the WaitDTLS timer is started (see Section 4.7). <===== > THE TIMER IS STARTED > > > Join to DTLS Teardown (e): This transition occurs when the join > process failed. > > WTP: This state transition occurs when the WTP receives a Join > Response message with a Result Code message element containing > an error, if the Image Identifier provided by the AC in the > Join Response message differs from the WTP's currently running > firmware version and the WTP has the requested image in its > non-volatile memory, or if the WaitDTLS timer expires. This > causes the WTP to initiate the DTLSShutdown command (see > Section 2.3.2.1). This transition also occurs if the WTP > receives one of the following DTLS notifications: DTLSAborted, > DTLSReassemblyFailure or DTLSPeerDisconnect. > > AC: This state transition occurs either if the WaitDTLS timer > <=== THE TIMER EXPIRES > expires or if the AC transmits a Join Response message with a > Result Code message element containing an error. This causes > the AC to initiate the DTLSShutdown command (see > Section 2.3.2.1). This transition also occurs if the AC > receives one of the following DTLS notifications: DTLSAborted, > DTLSReassemblyFailure or DTLSPeerDisconnect. > > > PatC > -----Original Message----- > From: Yong Zhang [mailto:yozhang@gmail.com] > Sent: Tuesday, July 01, 2008 1:37 PM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: Re: New Issue 106: WaitJoin may be unnecessary > > This change is OK for me. > > Yong > > On Thu, Jun 26, 2008 at 4:53 AM, Pat Calhoun (pacalhou) > wrote: >> I believe you may be correct that there is a technical issue. >> >> Originally, the WaitJoin was used to timeout if the WTP did not sent >> the Join Request, or the AC did not send the Join Response. However, >> when DTLS was introduced, we started to rely on the WaitDTLS timer. It > >> seems like we've started to rely much more on the WaitDTLS timer in >> the latter drafts, to the point where I believe that we could simply >> remove the WaitJoin timer and have little impact to the state machine. >> >> From what I can tell, the "Join to DTLS Teardown (e)" state transition > >> currently triggers if the WaitJoin timer expires, and we would have to > >> change this to WaitDTLS instead. Further, the "DTLS Connect to Join > (d)" >> state transition would simply need to have its reference to WaitJoin >> removed. >> >> So since it appears as if the WaitDTLS timers are initialized >> properly, the timeout triggers are properly defined, and it is well >> specified in its handling during the Join Request/Response in section >> 6.1 and 6.2, this change would have mimimal impact. >> >> Thoughts? >> >> PatC >> >> -----Original Message----- >> From: Yong Zhang [mailto:yozhang@gmail.com] >> Sent: Friday, June 20, 2008 11:19 AM >> To: Pat Calhoun (pacalhou) >> Cc: capwap@frascone.com >> Subject: Re: [Capwap] WaitDTLS/WaitJoin timers >> indraft-ietf-capwap-protocol-specification-10.txt >> >> This info is clear. But in the spec., the WaitDTLS covers the > WaitJoin. >> WairDTLS timer is not cleared after the DTLS session is esatblished, >> but it is only cleared after the Join REQ/RESP are received. (6.1/2 >> describes this). >> >> Thanks! >> >> Yong >> >> On Fri, Jun 20, 2008 at 10:55 AM, Pat Calhoun (pacalhou) >> wrote: >>> The intent for both timers is: >>> >>> WaitDTLS: This timer is used to make sure that the DTLS session is >>> established within the required timeframe. If the DTLS session isn't >>> setup, perhaps because either party is not responding, then the timer > >>> will trigger and the state will change. >>> >>> WaitJoin: Once the DTLS session has been established, we need to >>> protect against a WTP that opts to NOT send a Join Request. So in >>> this >> >>> instance, the WaitJoin would trigger, and the state would once more >> change. >>> >>> PatC >>> >>> -----Original Message----- >>> From: Yong Zhang [mailto:yozhang@gmail.com] >>> Sent: Friday, June 20, 2008 9:54 AM >>> To: capwap@frascone.com >>> Subject: [Capwap] WaitDTLS/WaitJoin timers >>> indraft-ietf-capwap-protocol-specification-10.txt >>> >>> WaitDTLS by its name should be DTLS session setup related, but this >>> spec. (6.1/2) requires it deactivated after the Join Req/Resp are >>> received. >>> >>> WaitJoin seems no use in this case?? >>> >>> Also the WaitDTLS timer is started earlier than WaitJoin timer, >>> however, the default value for these two timers (4.7.15/16) are all >>> 60s. if WaitJoin has some other use, it need to have a less value >>> than >> >>> WaitDTLS to work. >>> >>> Yong >>> _________________________________________________________________ >>> To unsubscribe or modify your subscription options, please visit: >>> http://lists.frascone.com/mailman/listinfo/capwap >>> >>> Archives: http://lists.frascone.com/pipermail/capwap >>> >> > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 7 09:53:47 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1BB3A6ABD for ; Mon, 7 Jul 2008 09:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSfSPOxV8+WS for ; Mon, 7 Jul 2008 09:53:46 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 32A2E3A6AA5 for ; Mon, 7 Jul 2008 09:53:46 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 441264330E8 for ; Mon, 7 Jul 2008 09:53:53 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id C7CAE4400AF for ; Mon, 7 Jul 2008 09:53:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2F38734AC03F for ; Mon, 7 Jul 2008 09:53:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E15A734AC01D for ; Mon, 7 Jul 2008 09:53:40 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 09:53:40 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so2584535wfc.11 for ; Mon, 07 Jul 2008 09:53:40 -0700 (PDT) Received: by 10.142.222.21 with SMTP id u21mr1386318wfg.323.1215449620558; Mon, 07 Jul 2008 09:53:40 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Mon, 7 Jul 2008 09:53:40 -0700 (PDT) Message-ID: Date: Mon, 7 Jul 2008 09:53:40 -0700 From: "Yong Zhang" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2060D15C1@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <4FF84B0BC277FF45AA27FE969DD956A2060D15C1@xmb-sjc-235.amer.cisco.com> Cc: capwap@frascone.com Subject: Re: [Capwap] UDP IANA port 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 This is OK for me. On Mon, Jul 7, 2008 at 4:34 AM, Pat Calhoun (pacalhou) wrote: > Yes, I had applied for the UDP ports and was planning on making the > change after IETF Last Call, but we can make the change now given that I > need to rev the spec anyhow. I have created issue 142 to track this > request. Here is the new text: > > > 3.1. UDP Transport > [...] > CAPWAP protocol control packets sent from the WTP to the AC use the > CAPWAP control channel, as defined in Section 1.4. The CAPWAP > control port at the AC is the well known UDP port 5246. The CAPWAP > control port at the WTP can be any port selected by the WTP. > > CAPWAP protocol data packets sent from the WTP to the AC use the > CAPWAP data channel, as defined in Section 1.4. The CAPWAP data port > at the AC is the well known UDP port 5247. The CAPWAP data port at > the WTP can be any port selected by the WTP. > > > I guess this ALSO means that I have to REMOVE the following text in the > IANA considerations section: > > A separate UDP port for data channel communications is (currently) > the selected demultiplexing mechanism, and a port must be assigned > for this purpose in Section 3.1. The UDP port numbers are listed by > IANA at http://www.iana.org/assignments/port-numbers. > > > PatC > -----Original Message----- > From: Yong Zhang [mailto:yozhang@gmail.com] > Sent: Thursday, July 03, 2008 2:41 PM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: UDP IANA port > > I saw from the mail archive that UDP ports had been allocated by IANA, > but the spec. doc. is not updated. > > Yong > > The CAPWAP control port at the AC is the well known UDP port [to be IANA > assigned]. > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 7 10:03:38 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CEAA3A6ABC for ; Mon, 7 Jul 2008 10:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9uZ2w3FHPKN for ; Mon, 7 Jul 2008 10:03:37 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 33BFE3A6AE9 for ; Mon, 7 Jul 2008 10:03:37 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 408574332C8 for ; Mon, 7 Jul 2008 10:03:44 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 8773044011B for ; Mon, 7 Jul 2008 10:03:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5FD6B34AC002 for ; Mon, 7 Jul 2008 10:03:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id CAFE334AC011 for ; Mon, 7 Jul 2008 10:03:34 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 10:03:34 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so2588978wfc.11 for ; Mon, 07 Jul 2008 10:03:34 -0700 (PDT) Received: by 10.142.47.6 with SMTP id u6mr1389581wfu.300.1215450214434; Mon, 07 Jul 2008 10:03:34 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Mon, 7 Jul 2008 10:03:34 -0700 (PDT) Message-ID: Date: Mon, 7 Jul 2008 10:03:34 -0700 From: "Yong Zhang" To: capwap@frascone.com MIME-Version: 1.0 Content-Disposition: inline Subject: [Capwap] 802.11 binding doc. issues 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 1. 6.1 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 7 10:04:46 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB15B3A6AF4 for ; Mon, 7 Jul 2008 10:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viM2wzzn+wdW for ; Mon, 7 Jul 2008 10:04:46 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 5CD6F3A6ABC for ; Mon, 7 Jul 2008 10:04:42 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5EB98433364 for ; Mon, 7 Jul 2008 10:04:49 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id A1BCC440111 for ; Mon, 7 Jul 2008 10:04:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5EC1534AC01D for ; Mon, 7 Jul 2008 10:04:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C80DF34AC00B for ; Mon, 7 Jul 2008 10:04:39 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 10:04:39 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id h29so1618907wxd.11 for ; Mon, 07 Jul 2008 10:04:39 -0700 (PDT) Received: by 10.142.12.14 with SMTP id 14mr1393934wfl.147.1215450278470; Mon, 07 Jul 2008 10:04:38 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Mon, 7 Jul 2008 10:04:38 -0700 (PDT) Message-ID: Date: Mon, 7 Jul 2008 10:04:38 -0700 From: "Yong Zhang" To: capwap@frascone.com In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Subject: Re: [Capwap] 802.11 binding doc. issues 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 1. 6.1 The len should be >=52? _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 7 10:30:53 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CCA53A6A1C for ; Mon, 7 Jul 2008 10:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjvCHMj9EjAa for ; Mon, 7 Jul 2008 10:30:52 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id B71993A68D7 for ; Mon, 7 Jul 2008 10:30:52 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CFC0143363B for ; Mon, 7 Jul 2008 10:30:59 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 3900D440111 for ; Mon, 7 Jul 2008 10:30:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E920534AC013 for ; Mon, 7 Jul 2008 10:30:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 46BCA34AC055 for ; Mon, 7 Jul 2008 10:30:47 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.231]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 10:30:46 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id h29so1627783wxd.11 for ; Mon, 07 Jul 2008 10:30:46 -0700 (PDT) Received: by 10.143.2.19 with SMTP id e19mr1405822wfi.90.1215451845453; Mon, 07 Jul 2008 10:30:45 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Mon, 7 Jul 2008 10:30:45 -0700 (PDT) Message-ID: Date: Mon, 7 Jul 2008 10:30:45 -0700 From: "Yong Zhang" To: capwap@frascone.com In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Subject: Re: [Capwap] 802.11 binding doc. issues 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 6.1 The len should be >=52? 4 + 4 + 32 + 4 + 4 + 4 = 52 (assume SSID to be at least 1 byte) We have a key length field, however, "Key: A 32 byte Session Key to use to provide data privacy. " 6.2 len = 5 6.3 len = 8 6.6 This is used to include only one IE? If it is, should we remove the "..." in the figure? Also the len is bigger than 4. The minimal len of IE is 1 ? 6.13 len >= 14 I am not sure the minimal size of supported rates. Here assume it is one. 6.14 Here the 802.1p tag is defined with 2 bytes, but other places only use 1 byte. Only the 3 least significant bits are used. 6.15. I am not familiar with the keys. How do you get the length value? The minimal length of Key is 5 bytes? 6.16 len is 80 6.21 len is 40 same issue on Key as 6.1 6.22 "tag packets" is bit value? Can I set the tag the packet with both 1p and DSCP? If I can, we need to add a value 3. Immediately following the above header is the following data structure. This data structure will be repeated five times; once for every QoS profile. The order of the QoS profiles are Voice, Video, Best Effort and Background. Here should be "four times". Are the above mandatory? If they are, the ME len is ( 2 + 8 * 4) = 34. 7.4. IEEE80211OFDMControl The WTP per radio MAC Operation configuration, defined in Section 6.10. OFDM 8. Technology Specific Message Element Values I do not know which capwap ME is talking about at here. How to use the defined value here? Yong _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 7 10:46:47 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB473A69ED for ; Mon, 7 Jul 2008 10:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIq+NGDjtJe0 for ; Mon, 7 Jul 2008 10:46:46 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D303928C113 for ; Mon, 7 Jul 2008 10:46:45 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0A866433BFA for ; Mon, 7 Jul 2008 10:46:53 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 4C415440114 for ; Mon, 7 Jul 2008 10:46:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E9BA134AC02B for ; Mon, 7 Jul 2008 10:46:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 33DD734AC015 for ; Mon, 7 Jul 2008 10:46:33 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 10:46:33 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so2605551wfc.11 for ; Mon, 07 Jul 2008 10:46:32 -0700 (PDT) Received: by 10.142.237.20 with SMTP id k20mr1414830wfh.146.1215452792543; Mon, 07 Jul 2008 10:46:32 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Mon, 7 Jul 2008 10:46:32 -0700 (PDT) Message-ID: Date: Mon, 7 Jul 2008 10:46:32 -0700 From: "Yong Zhang" To: capwap@frascone.com In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Subject: Re: [Capwap] 802.11 binding doc. issues 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 3.2. IEEE 802.11 WLAN Configuration Response Can we put MUST ME earlier than MAY ME for this message in the message definition? On Mon, Jul 7, 2008 at 10:30 AM, Yong Zhang wrote: > 6.1 > > The len should be >=52? > > 4 + 4 + 32 + 4 + 4 + 4 = 52 (assume SSID to be at least 1 byte) > > We have a key length field, however, > > "Key: A 32 byte Session Key to use to provide data privacy. " > > 6.2 > > len = 5 > > 6.3 > > len = 8 > > 6.6 > > This is used to include only one IE? If it is, should we remove the > "..." in the figure? > > Also the len is bigger than 4. The minimal len of IE is 1 ? > > 6.13 > > len >= 14 > > I am not sure the minimal size of supported rates. Here assume it is one. > > 6.14 > > Here the 802.1p tag is defined with 2 bytes, but other places only use > 1 byte. Only the 3 least > significant bits are used. > > 6.15. > > I am not familiar with the keys. How do you get the length value? The > minimal length of Key is 5 bytes? > > 6.16 > > len is 80 > > > 6.21 > > len is 40 > > same issue on Key as 6.1 > > 6.22 > > "tag packets" is bit value? Can I set the tag the packet with both 1p > and DSCP? If I can, we need to add a > value 3. > > Immediately following the above header is the following data > structure. This data structure will be repeated five times; once > for every QoS profile. The order of the QoS profiles are Voice, > Video, Best Effort and Background. > > Here should be "four times". > > Are the above mandatory? If they are, the ME len is ( 2 + 8 * 4) = 34. > > > 7.4. IEEE80211OFDMControl > > The WTP per radio MAC Operation configuration, defined in > Section 6.10. > > OFDM > > > 8. Technology Specific Message Element Values > > I do not know which capwap ME is talking about at here. How to use the > defined value here? > > Yong > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 7 10:57:34 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FB013A6824 for ; Mon, 7 Jul 2008 10:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOb7xt0ViwQT for ; Mon, 7 Jul 2008 10:57:33 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 4CC4C3A67E3 for ; Mon, 7 Jul 2008 10:57:33 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 828DF433C18 for ; Mon, 7 Jul 2008 10:57:40 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 9240C44011B for ; Mon, 7 Jul 2008 10:57:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 56FD134AC062 for ; Mon, 7 Jul 2008 10:57:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0813B34AC002 for ; Mon, 7 Jul 2008 10:57:14 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 10:57:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,317,1212364800"; d="scan'208";a="49630457" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 07 Jul 2008 17:57:09 +0000 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/8.12.11) with ESMTP id m67Hv9X4029345 for ; Mon, 7 Jul 2008 10:57: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.13.8/8.13.8) with ESMTP id m67Hv9kR022537 for ; Mon, 7 Jul 2008 17:57:09 GMT 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, 7 Jul 2008 10:57:09 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 10:57:08 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D174C@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 143: Data Transfer Request is too ambiguous Thread-Index: AcjgWt/dnHO5VZt3RBu4YFnzy1B6UA== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 07 Jul 2008 17:57:09.0410 (UTC) FILETIME=[E0411820:01C8E05A] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Capwap] Issue 143: Data Transfer Request is too ambiguous 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 All, Yong has raised a series of questions about the use of the Data Transfer Request/Response which are pointing out that the text is simply too ambiguous. I looked at the text again, and I agree that it needs work. Some time ago we had agreed to clean up the Image Transfer exchanges to allow the AC to know the size of the data being transfered, etc. We also agreed to include figures to help provide more clarity on how the exchange occurred. Clearly, we need something similar for the Data Transfer section. Furthermore, I have found a bug that the Data Transfer Request currently states that it cannot be sent by the AC, which is incorrect. The AC is supposed to send this in order to request the information to begin with. Please see the following proposed text to handle this issue. Note that this will "sort-of" break compatibility with -10 but I doubt we will see any issues because -10 had no way for the AC to initiate the request. 2.3.1. CAPWAP Protocol State Transitions [...] Run to Run (q): This is the normal state of operation. WTP: This is the WTP's normal state of operation. There are many events that result this state transition: [...] Data Transfer: The WTP sends a Data Transfer Request or Data Transfer Response message to the AC (see Section 9.6). The WTP receives a Data Transfer Request or Data Transfer Response message from the AC (see Section 9.6). Upon receipt of a Data Transfer Request, the WTP transmits a Data Transfer Response to the AC. [...] AC: This is the AC's normal state of operation: [...] Data Transfer: The AC sends a Data Transfer Request or Data Transfer Response message to the WTP (see Section 9.6). The AC receives a Data Transfer Request or Data Transfer Response message from the WTP (see Section 9.6). Upon receipt of a Data Transfer Request, the AC transmits a Data Transfer Response to the WTP. 4.6.16. Data Transfer Data The Data Transfer Data message element is used by the WTP to provide information to the AC for debugging purposes. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Type | Data Length | Data .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 16 for Data Transfer Data Length: >= 3 Data Type: An 8-bit value representing the transfer Data Type. The following enumerated values are supported: 1 - Transfer data is included 2 - Last Transfer Data Block is included (EOF) 5 - An error occurred. Transfer is aborted Data Length: Length of data field, with a maximum size of 65535. Data: Debug information. 9.6. Data Transfer This section describes the data transfer procedures used by the CAPWAP protocol. The data transfer mechanism is used to upload information available at the WTP to the AC, such as crash or debug information. The data transfer messages can only be exchanged while in the Run state. Figure 10 provides an example of an AC that requests that the WTP transfer its latest crash file. Once the WTP acknowledges that it has information to send, via the Data Transfer Response, it transmits its own Data Transfer Request. Upon receipt, the AC responds with a Data Transfer Response, and the exchange continues until the WTP transmits a Data Transfer Data message element that indicates an End of File (EOF). WTP AC Data Transfer Request (Data Transfer Mode = Crash Data) <------------------------------------------------------ Data Transfer Response (Result Code = Success) --------------------------------------------------------> Data Transfer Request (Data Transfer Data = Data) --------------------------------------------------------> Data Transfer Response (Result Code = Success) <------------------------------------------------------ ..... Data Transfer Request (Data Transfer Data = EOF) <------------------------------------------------------ Data Transfer Response (Result Code = Success) --------------------------------------------------------> Figure 10: WTP Data Transfer Case 1 Figure 11 provides an example of an AC that requests that the WTP transfer its latest crash file. However, in this example, the WTP does not have any crash information to send, and therefore sends a Data Transfer Response with a Result Code indicating the error. WTP AC Data Transfer Request (Data Transfer Mode = Crash Data) <------------------------------------------------------ Data Transfer Response (Result Code = Data Transfer Error (No Information to Transfer)) --------------------------------------------------------> Figure 11: WTP Data Transfer Case 2 9.6.1. Data Transfer Request The Data Transfer Request message is used to deliver debug information from the WTP to the AC. The Data Transfer Request messages can be sent either by the AC or the WTP. When sent by the AC, it is used to request that data be transmitted from the WTP to the AC, and includes the Data Transfer Mode message element, which specifies the information desired by the AC. The Data Transfer Request is sent by the WTP in order to transfer actual data to the AC, through the Data Transfer Data message element. Given that the CAPWAP protocol minimizes the need for WTPs to be directly managed, the Data Transfer Request is an important troubleshooting tool used by the AC to retrieve information that may be available on the WTP. For instance, some WTPs implementations may store crash information to help manufacturers identify software faults. The Data Transfer Request message can be used to send such information from the WTP to the AC. Another possible use would be to allow a remote debugger function in the WTP to use the Data Transfer Request message to send console output to the AC for debugging purposes. When the WTP or AC receives a Data Transfer Request message it responds to the WTP with a Data Transfer Response message. The AC MAY log the information received through the Data Transfer Data message element. The Data Transfer Request message is sent by the WTP or AC when in the Run State. When sent by the AC, the Data Transfer Request message MUST contain the following message elements: o Data Transfer Mode, see Section 4.6.17 When sent by the WTP, the Data Transfer Request message MUST contain the following message elements: o Data Transfer Data, see Section 4.6.16 Regardless of whether the Data Transfer Request is sent by the AC or WTP, the following message elements MAY be included in the Data Transfer Request message: o Vendor Specific Payload, see Section 4.6.39 9.6.2. Data Transfer Response The Data Transfer Response message acknowledges the Data Transfer Request message. A Data Transfer Response message is sent in response to a received Data Transfer Request message. Its purpose is to acknowledge receipt of the Data Transfer Request message. When sent by the WTP, the Result Code message element is used to indicate whether the data transfer requested by the AC can be completed. When sent by the AC, the Result Code message element is used to indicate receipt of the data transfered in the Data Transfer Request message. The Data Transfer Response message is sent by the WTP or AC when in the Run State. The following message element MUST be included in the Data Transfer Response message. o Result Code, see Section 4.6.35 The following message elements MAY be included in the Data Transfer Response message: o Vendor Specific Payload, see Section 4.6.39 Upon receipt of a Data Transfer Response message, the WTP transmits more information, if more information is available. 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 Mon Jul 7 11:25:46 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 820BA3A6A35 for ; Mon, 7 Jul 2008 11:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMljhQkCKWvt for ; Mon, 7 Jul 2008 11:25:45 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2C15F28C0F4 for ; Mon, 7 Jul 2008 11:25:45 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 61EFD433D13 for ; Mon, 7 Jul 2008 11:25:52 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 8CFD14400CE for ; Mon, 7 Jul 2008 11:25:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 1B05434AC033 for ; Mon, 7 Jul 2008 11:25:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 61DAA34AC03D for ; Mon, 7 Jul 2008 11:25:28 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from yx-out-1718.google.com (yx-out-1718.google.com [74.125.44.158]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 11:25:28 -0700 (PDT) Received: by yx-out-1718.google.com with SMTP id 3so426502yxi.80 for ; Mon, 07 Jul 2008 11:25:27 -0700 (PDT) Received: by 10.142.158.17 with SMTP id g17mr1436573wfe.17.1215455126851; Mon, 07 Jul 2008 11:25:26 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Mon, 7 Jul 2008 11:25:26 -0700 (PDT) Message-ID: Date: Mon, 7 Jul 2008 11:25:26 -0700 From: "Yong Zhang" To: capwap@frascone.com MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [Capwap] Issue 143: Data Transfer Request is too ambiguous 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 There are two issues here: 1. 4.6.16. Data Transfer Data The Data Transfer Data message element is used by the WTP to provide information to the AC for debugging purposes. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Type | Data Length | Data .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Length/Data bit fields are not correct in the above fig. 2. Figure 10. It's WTP send EOF. If the Data Transfer Mode/data are used in different messages, I think it would be better to keep the mode info in the Data Transfer Data ME. It will be easier when you need to analyze the capwap messages. Yong ------------------------------ Message: 7 Date: Mon, 7 Jul 2008 10:57:08 -0700 From: "Pat Calhoun (pacalhou)" Subject: [Capwap] Issue 143: Data Transfer Request is too ambiguous To: Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D174C@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset="us-ascii" All, Yong has raised a series of questions about the use of the Data Transfer Request/Response which are pointing out that the text is simply too ambiguous. I looked at the text again, and I agree that it needs work. Some time ago we had agreed to clean up the Image Transfer exchanges to allow the AC to know the size of the data being transfered, etc. We also agreed to include figures to help provide more clarity on how the exchange occurred. Clearly, we need something similar for the Data Transfer section. Furthermore, I have found a bug that the Data Transfer Request currently states that it cannot be sent by the AC, which is incorrect. The AC is supposed to send this in order to request the information to begin with. Please see the following proposed text to handle this issue. Note that this will "sort-of" break compatibility with -10 but I doubt we will see any issues because -10 had no way for the AC to initiate the request. 2.3.1. CAPWAP Protocol State Transitions [...] Run to Run (q): This is the normal state of operation. WTP: This is the WTP's normal state of operation. There are many events that result this state transition: [...] Data Transfer: The WTP sends a Data Transfer Request or Data Transfer Response message to the AC (see Section 9.6). The WTP receives a Data Transfer Request or Data Transfer Response message from the AC (see Section 9.6). Upon receipt of a Data Transfer Request, the WTP transmits a Data Transfer Response to the AC. [...] AC: This is the AC's normal state of operation: [...] Data Transfer: The AC sends a Data Transfer Request or Data Transfer Response message to the WTP (see Section 9.6). The AC receives a Data Transfer Request or Data Transfer Response message from the WTP (see Section 9.6). Upon receipt of a Data Transfer Request, the AC transmits a Data Transfer Response to the WTP. 4.6.16. Data Transfer Data The Data Transfer Data message element is used by the WTP to provide information to the AC for debugging purposes. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Type | Data Length | Data .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 16 for Data Transfer Data Length: >= 3 Data Type: An 8-bit value representing the transfer Data Type. The following enumerated values are supported: 1 - Transfer data is included 2 - Last Transfer Data Block is included (EOF) 5 - An error occurred. Transfer is aborted Data Length: Length of data field, with a maximum size of 65535. Data: Debug information. 9.6. Data Transfer This section describes the data transfer procedures used by the CAPWAP protocol. The data transfer mechanism is used to upload information available at the WTP to the AC, such as crash or debug information. The data transfer messages can only be exchanged while in the Run state. Figure 10 provides an example of an AC that requests that the WTP transfer its latest crash file. Once the WTP acknowledges that it has information to send, via the Data Transfer Response, it transmits its own Data Transfer Request. Upon receipt, the AC responds with a Data Transfer Response, and the exchange continues until the WTP transmits a Data Transfer Data message element that indicates an End of File (EOF). WTP AC Data Transfer Request (Data Transfer Mode = Crash Data) <------------------------------------------------------ Data Transfer Response (Result Code = Success) --------------------------------------------------------> Data Transfer Request (Data Transfer Data = Data) --------------------------------------------------------> Data Transfer Response (Result Code = Success) <------------------------------------------------------ ..... Data Transfer Request (Data Transfer Data = EOF) <------------------------------------------------------ Data Transfer Response (Result Code = Success) --------------------------------------------------------> Figure 10: WTP Data Transfer Case 1 Figure 11 provides an example of an AC that requests that the WTP transfer its latest crash file. However, in this example, the WTP does not have any crash information to send, and therefore sends a Data Transfer Response with a Result Code indicating the error. WTP AC Data Transfer Request (Data Transfer Mode = Crash Data) <------------------------------------------------------ Data Transfer Response (Result Code = Data Transfer Error (No Information to Transfer)) --------------------------------------------------------> Figure 11: WTP Data Transfer Case 2 9.6.1. Data Transfer Request The Data Transfer Request message is used to deliver debug information from the WTP to the AC. The Data Transfer Request messages can be sent either by the AC or the WTP. When sent by the AC, it is used to request that data be transmitted from the WTP to the AC, and includes the Data Transfer Mode message element, which specifies the information desired by the AC. The Data Transfer Request is sent by the WTP in order to transfer actual data to the AC, through the Data Transfer Data message element. Given that the CAPWAP protocol minimizes the need for WTPs to be directly managed, the Data Transfer Request is an important troubleshooting tool used by the AC to retrieve information that may be available on the WTP. For instance, some WTPs implementations may store crash information to help manufacturers identify software faults. The Data Transfer Request message can be used to send such information from the WTP to the AC. Another possible use would be to allow a remote debugger function in the WTP to use the Data Transfer Request message to send console output to the AC for debugging purposes. When the WTP or AC receives a Data Transfer Request message it responds to the WTP with a Data Transfer Response message. The AC MAY log the information received through the Data Transfer Data message element. The Data Transfer Request message is sent by the WTP or AC when in the Run State. When sent by the AC, the Data Transfer Request message MUST contain the following message elements: o Data Transfer Mode, see Section 4.6.17 When sent by the WTP, the Data Transfer Request message MUST contain the following message elements: o Data Transfer Data, see Section 4.6.16 Regardless of whether the Data Transfer Request is sent by the AC or WTP, the following message elements MAY be included in the Data Transfer Request message: o Vendor Specific Payload, see Section 4.6.39 9.6.2. Data Transfer Response The Data Transfer Response message acknowledges the Data Transfer Request message. A Data Transfer Response message is sent in response to a received Data Transfer Request message. Its purpose is to acknowledge receipt of the Data Transfer Request message. When sent by the WTP, the Result Code message element is used to indicate whether the data transfer requested by the AC can be completed. When sent by the AC, the Result Code message element is used to indicate receipt of the data transfered in the Data Transfer Request message. The Data Transfer Response message is sent by the WTP or AC when in the Run State. The following message element MUST be included in the Data Transfer Response message. o Result Code, see Section 4.6.35 The following message elements MAY be included in the Data Transfer Response message: o Vendor Specific Payload, see Section 4.6.39 Upon receipt of a Data Transfer Response message, the WTP transmits more information, if more information is available. 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 Mon Jul 7 12:13:43 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7085A3A6A81 for ; Mon, 7 Jul 2008 12:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Y8qj+E51B3w for ; Mon, 7 Jul 2008 12:13:41 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 85ED33A67F7 for ; Mon, 7 Jul 2008 12:13:41 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DA3D7433DDB for ; Mon, 7 Jul 2008 12:13:48 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id D245644010A for ; Mon, 7 Jul 2008 12:13:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4639434AC011 for ; Mon, 7 Jul 2008 12:13:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4D41634AC013 for ; Mon, 7 Jul 2008 12:13:28 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 12:13:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,317,1212364800"; d="scan'208";a="123497994" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 07 Jul 2008 19:13:21 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m67JDLFR008862; Mon, 7 Jul 2008 12:13:21 -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.13.8/8.13.8) with ESMTP id m67JDLS0028745; Mon, 7 Jul 2008 19:13:21 GMT 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.1830); Mon, 7 Jul 2008 12:13:21 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 12:13:20 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D17DD@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 143: Data Transfer Request is too ambiguous Thread-Index: AcjgXukVixx2VsLyQESoyzsbV0sH7AABnvBQ References: From: "Pat Calhoun (pacalhou)" To: "Yong Zhang" , X-OriginalArrivalTime: 07 Jul 2008 19:13:21.0722 (UTC) FILETIME=[859089A0:01C8E065] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Capwap] Issue 143: Data Transfer Request is too ambiguous 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 Thanks for the feedback. Yes, you caught two bugs. To address your open issue below, how about: 4.6.16. Data Transfer Data The Data Transfer Data message element is used by the WTP to provide information to the AC for debugging purposes. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Type | Data Mode | Data Length | Data .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 16 for Data Transfer Data Length: >= 3 Data Type: An 8-bit value representing the transfer Data Type. The following enumerated values are supported: 1 - Transfer data is included 2 - Last Transfer Data Block is included (EOF) 5 - An error occurred. Transfer is aborted Data Mode: An 8-bit value the type of information being transmitted. The following enumerated values are supported: 0 - Reserved 1 - WTP Crash Data 2 - WTP Memory Dump Data Length: Length of data field, with a maximum size of 65535. Data: Data being transferred from the WTP to the AC, whose type is identified via the Data Mode field. 4.6.17. Data Transfer Mode The Data Transfer Mode message element is used by the WTP to indicate the type of data transfer information it is sending to the AC for debugging purposes. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Data Mode | +-+-+-+-+-+-+-+-+ Type: 17 for Data Transfer Mode Length: 1 Data Mode: An 8-bit value the type of information being requested. The following enumerated values are supported: 0 - Reserved 1 - WTP Crash Data 2 - WTP Memory Dump PatC -----Original Message----- From: Yong Zhang [mailto:yozhang@gmail.com] Sent: Monday, July 07, 2008 11:25 AM To: capwap@frascone.com Subject: Re: [Capwap] Issue 143: Data Transfer Request is too ambiguous There are two issues here: 1. 4.6.16. Data Transfer Data The Data Transfer Data message element is used by the WTP to provide information to the AC for debugging purposes. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Type | Data Length | Data .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Length/Data bit fields are not correct in the above fig. 2. Figure 10. It's WTP send EOF. If the Data Transfer Mode/data are used in different messages, I think it would be better to keep the mode info in the Data Transfer Data ME. It will be easier when you need to analyze the capwap messages. Yong ------------------------------ Message: 7 Date: Mon, 7 Jul 2008 10:57:08 -0700 From: "Pat Calhoun (pacalhou)" Subject: [Capwap] Issue 143: Data Transfer Request is too ambiguous To: Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D174C@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset="us-ascii" All, Yong has raised a series of questions about the use of the Data Transfer Request/Response which are pointing out that the text is simply too ambiguous. I looked at the text again, and I agree that it needs work. Some time ago we had agreed to clean up the Image Transfer exchanges to allow the AC to know the size of the data being transfered, etc. We also agreed to include figures to help provide more clarity on how the exchange occurred. Clearly, we need something similar for the Data Transfer section. Furthermore, I have found a bug that the Data Transfer Request currently states that it cannot be sent by the AC, which is incorrect. The AC is supposed to send this in order to request the information to begin with. Please see the following proposed text to handle this issue. Note that this will "sort-of" break compatibility with -10 but I doubt we will see any issues because -10 had no way for the AC to initiate the request. 2.3.1. CAPWAP Protocol State Transitions [...] Run to Run (q): This is the normal state of operation. WTP: This is the WTP's normal state of operation. There are many events that result this state transition: [...] Data Transfer: The WTP sends a Data Transfer Request or Data Transfer Response message to the AC (see Section 9.6). The WTP receives a Data Transfer Request or Data Transfer Response message from the AC (see Section 9.6). Upon receipt of a Data Transfer Request, the WTP transmits a Data Transfer Response to the AC. [...] AC: This is the AC's normal state of operation: [...] Data Transfer: The AC sends a Data Transfer Request or Data Transfer Response message to the WTP (see Section 9.6). The AC receives a Data Transfer Request or Data Transfer Response message from the WTP (see Section 9.6). Upon receipt of a Data Transfer Request, the AC transmits a Data Transfer Response to the WTP. 4.6.16. Data Transfer Data The Data Transfer Data message element is used by the WTP to provide information to the AC for debugging purposes. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Type | Data Length | Data .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 16 for Data Transfer Data Length: >= 3 Data Type: An 8-bit value representing the transfer Data Type. The following enumerated values are supported: 1 - Transfer data is included 2 - Last Transfer Data Block is included (EOF) 5 - An error occurred. Transfer is aborted Data Length: Length of data field, with a maximum size of 65535. Data: Debug information. 9.6. Data Transfer This section describes the data transfer procedures used by the CAPWAP protocol. The data transfer mechanism is used to upload information available at the WTP to the AC, such as crash or debug information. The data transfer messages can only be exchanged while in the Run state. Figure 10 provides an example of an AC that requests that the WTP transfer its latest crash file. Once the WTP acknowledges that it has information to send, via the Data Transfer Response, it transmits its own Data Transfer Request. Upon receipt, the AC responds with a Data Transfer Response, and the exchange continues until the WTP transmits a Data Transfer Data message element that indicates an End of File (EOF). WTP AC Data Transfer Request (Data Transfer Mode = Crash Data) <------------------------------------------------------ Data Transfer Response (Result Code = Success) --------------------------------------------------------> Data Transfer Request (Data Transfer Data = Data) --------------------------------------------------------> Data Transfer Response (Result Code = Success) <------------------------------------------------------ ..... Data Transfer Request (Data Transfer Data = EOF) <------------------------------------------------------ Data Transfer Response (Result Code = Success) --------------------------------------------------------> Figure 10: WTP Data Transfer Case 1 Figure 11 provides an example of an AC that requests that the WTP transfer its latest crash file. However, in this example, the WTP does not have any crash information to send, and therefore sends a Data Transfer Response with a Result Code indicating the error. WTP AC Data Transfer Request (Data Transfer Mode = Crash Data) <------------------------------------------------------ Data Transfer Response (Result Code = Data Transfer Error (No Information to Transfer)) --------------------------------------------------------> Figure 11: WTP Data Transfer Case 2 9.6.1. Data Transfer Request The Data Transfer Request message is used to deliver debug information from the WTP to the AC. The Data Transfer Request messages can be sent either by the AC or the WTP. When sent by the AC, it is used to request that data be transmitted from the WTP to the AC, and includes the Data Transfer Mode message element, which specifies the information desired by the AC. The Data Transfer Request is sent by the WTP in order to transfer actual data to the AC, through the Data Transfer Data message element. Given that the CAPWAP protocol minimizes the need for WTPs to be directly managed, the Data Transfer Request is an important troubleshooting tool used by the AC to retrieve information that may be available on the WTP. For instance, some WTPs implementations may store crash information to help manufacturers identify software faults. The Data Transfer Request message can be used to send such information from the WTP to the AC. Another possible use would be to allow a remote debugger function in the WTP to use the Data Transfer Request message to send console output to the AC for debugging purposes. When the WTP or AC receives a Data Transfer Request message it responds to the WTP with a Data Transfer Response message. The AC MAY log the information received through the Data Transfer Data message element. The Data Transfer Request message is sent by the WTP or AC when in the Run State. When sent by the AC, the Data Transfer Request message MUST contain the following message elements: o Data Transfer Mode, see Section 4.6.17 When sent by the WTP, the Data Transfer Request message MUST contain the following message elements: o Data Transfer Data, see Section 4.6.16 Regardless of whether the Data Transfer Request is sent by the AC or WTP, the following message elements MAY be included in the Data Transfer Request message: o Vendor Specific Payload, see Section 4.6.39 9.6.2. Data Transfer Response The Data Transfer Response message acknowledges the Data Transfer Request message. A Data Transfer Response message is sent in response to a received Data Transfer Request message. Its purpose is to acknowledge receipt of the Data Transfer Request message. When sent by the WTP, the Result Code message element is used to indicate whether the data transfer requested by the AC can be completed. When sent by the AC, the Result Code message element is used to indicate receipt of the data transfered in the Data Transfer Request message. The Data Transfer Response message is sent by the WTP or AC when in the Run State. The following message element MUST be included in the Data Transfer Response message. o Result Code, see Section 4.6.35 The following message elements MAY be included in the Data Transfer Response message: o Vendor Specific Payload, see Section 4.6.39 Upon receipt of a Data Transfer Response message, the WTP transmits more information, if more information is available. PatC ------------------------------ _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 7 13:16:58 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7A443A6834 for ; Mon, 7 Jul 2008 13:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reGC6Jg27GgS for ; Mon, 7 Jul 2008 13:16:57 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 388AD3A680F for ; Mon, 7 Jul 2008 13:16:57 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 89C121C40F50 for ; Mon, 7 Jul 2008 13:17:04 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id BA9DF440120 for ; Mon, 7 Jul 2008 13:16:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id B5F9034AC056 for ; Mon, 7 Jul 2008 13:16:46 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id CBEB73610002 for ; Mon, 7 Jul 2008 13:16:39 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 13:16:39 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so2658134wfc.11 for ; Mon, 07 Jul 2008 13:16:38 -0700 (PDT) Received: by 10.142.125.4 with SMTP id x4mr1467213wfc.349.1215461798269; Mon, 07 Jul 2008 13:16:38 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Mon, 7 Jul 2008 13:16:38 -0700 (PDT) Message-ID: Date: Mon, 7 Jul 2008 13:16:38 -0700 From: "Yong Zhang" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2060D17DD@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <4FF84B0BC277FF45AA27FE969DD956A2060D17DD@xmb-sjc-235.amer.cisco.com> Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 143: Data Transfer Request is too ambiguous 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 Data Length need to be 16 bits. (Data Transfer Data ME figure need to be changed) ME len >= 5. Yong On Mon, Jul 7, 2008 at 12:13 PM, Pat Calhoun (pacalhou) wrote: > Thanks for the feedback. Yes, you caught two bugs. > > To address your open issue below, how about: > > 4.6.16. Data Transfer Data > > The Data Transfer Data message element is used by the WTP to provide > information to the AC for debugging purposes. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data Type | Data Mode | Data Length | Data .... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: 16 for Data Transfer Data > > Length: >= 3 > > Data Type: An 8-bit value representing the transfer Data Type. The > following enumerated values are supported: > > 1 - Transfer data is included > > 2 - Last Transfer Data Block is included (EOF) > > 5 - An error occurred. Transfer is aborted > > Data Mode: An 8-bit value the type of information being > transmitted. The following enumerated values are supported: > > 0 - Reserved > > 1 - WTP Crash Data > > 2 - WTP Memory Dump > > Data Length: Length of data field, with a maximum size of 65535. > > Data: Data being transferred from the WTP to the AC, whose type is > identified via the Data Mode field. > > 4.6.17. Data Transfer Mode > > The Data Transfer Mode message element is used by the WTP to indicate > the type of data transfer information it is sending to the AC for > debugging purposes. > > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | Data Mode | > +-+-+-+-+-+-+-+-+ > > Type: 17 for Data Transfer Mode > > Length: 1 > > Data Mode: An 8-bit value the type of information being requested. > The following enumerated values are supported: > > 0 - Reserved > > 1 - WTP Crash Data > > 2 - WTP Memory Dump > > > PatC > -----Original Message----- > From: Yong Zhang [mailto:yozhang@gmail.com] > Sent: Monday, July 07, 2008 11:25 AM > To: capwap@frascone.com > Subject: Re: [Capwap] Issue 143: Data Transfer Request is too ambiguous > > There are two issues here: > > 1. 4.6.16. Data Transfer Data > > The Data Transfer Data message element is used by the WTP to provide > information to the AC for debugging purposes. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data Type | Data Length | Data .... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Data Length/Data bit fields are not correct in the above fig. > > 2. Figure 10. It's WTP send EOF. > > > If the Data Transfer Mode/data are used in different messages, I think > it would be better to keep the mode info in the Data Transfer Data ME. > It will be easier when you need to analyze the capwap messages. > > > Yong > > ------------------------------ > > Message: 7 > Date: Mon, 7 Jul 2008 10:57:08 -0700 > From: "Pat Calhoun (pacalhou)" > Subject: [Capwap] Issue 143: Data Transfer Request is too ambiguous > To: > Message-ID: > > <4FF84B0BC277FF45AA27FE969DD956A2060D174C@xmb-sjc-235.amer.cisco.com> > Content-Type: text/plain; charset="us-ascii" > > All, > > Yong has raised a series of questions about the use of the Data Transfer > Request/Response which are pointing out that the text is simply too > ambiguous. I looked at the text again, and I agree that it needs work. > Some time ago we had agreed to clean up the Image Transfer exchanges to > allow the AC to know the size of the data being transfered, etc. We also > agreed to include figures to help provide more clarity on how the > exchange occurred. > > Clearly, we need something similar for the Data Transfer section. > Furthermore, I have found a bug that the Data Transfer Request currently > states that it cannot be sent by the AC, which is incorrect. The AC is > supposed to send this in order to request the information to begin with. > > > Please see the following proposed text to handle this issue. Note that > this will "sort-of" break compatibility with -10 but I doubt we will see > any issues because -10 had no way for the AC to initiate the request. > > > 2.3.1. CAPWAP Protocol State Transitions [...] > Run to Run (q): This is the normal state of operation. > > WTP: This is the WTP's normal state of operation. There are many > events that result this state transition: > [...] > Data Transfer: The WTP sends a Data Transfer Request or Data > Transfer Response message to the AC (see Section 9.6). The > WTP receives a Data Transfer Request or Data Transfer > Response message from the AC (see Section 9.6). Upon > receipt of a Data Transfer Request, the WTP transmits a Data > Transfer Response to the AC. > [...] > AC: This is the AC's normal state of operation: > [...] > Data Transfer: The AC sends a Data Transfer Request or Data > Transfer Response message to the WTP (see Section 9.6). The > AC receives a Data Transfer Request or Data Transfer > Response message from the WTP (see Section 9.6). Upon > receipt of a Data Transfer Request, the AC transmits a Data > Transfer Response to the WTP. > 4.6.16. Data Transfer Data > > The Data Transfer Data message element is used by the WTP to provide > information to the AC for debugging purposes. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data Type | Data Length | Data .... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: 16 for Data Transfer Data > > Length: >= 3 > > Data Type: An 8-bit value representing the transfer Data Type. The > following enumerated values are supported: > > 1 - Transfer data is included > > 2 - Last Transfer Data Block is included (EOF) > > 5 - An error occurred. Transfer is aborted > > Data Length: Length of data field, with a maximum size of 65535. > > Data: Debug information. > > > 9.6. Data Transfer > > This section describes the data transfer procedures used by the > CAPWAP protocol. The data transfer mechanism is used to upload > information available at the WTP to the AC, such as crash or debug > information. The data transfer messages can only be exchanged while > in the Run state. > > Figure 10 provides an example of an AC that requests that the WTP > transfer its latest crash file. Once the WTP acknowledges that it > has information to send, via the Data Transfer Response, it transmits > its own Data Transfer Request. Upon receipt, the AC responds with a > Data Transfer Response, and the exchange continues until the WTP > transmits a Data Transfer Data message element that indicates an End > of File (EOF). > > WTP AC > > Data Transfer Request (Data Transfer Mode = Crash Data) > <------------------------------------------------------ > > Data Transfer Response (Result Code = Success) > --------------------------------------------------------> > > Data Transfer Request (Data Transfer Data = Data) > --------------------------------------------------------> > > Data Transfer Response (Result Code = Success) > <------------------------------------------------------ > > ..... > > Data Transfer Request (Data Transfer Data = EOF) > <------------------------------------------------------ > > Data Transfer Response (Result Code = Success) > --------------------------------------------------------> > > > Figure 10: WTP Data Transfer Case 1 > > Figure 11 provides an example of an AC that requests that the WTP > transfer its latest crash file. However, in this example, the WTP > does not have any crash information to send, and therefore sends a > Data Transfer Response with a Result Code indicating the error. > > WTP AC > > Data Transfer Request (Data Transfer Mode = Crash Data) > <------------------------------------------------------ > > Data Transfer Response (Result Code = Data Transfer > Error (No Information to Transfer)) > --------------------------------------------------------> > > > Figure 11: WTP Data Transfer Case 2 > > 9.6.1. Data Transfer Request > > The Data Transfer Request message is used to deliver debug > information from the WTP to the AC. > > The Data Transfer Request messages can be sent either by the AC or > the WTP. When sent by the AC, it is used to request that data be > transmitted from the WTP to the AC, and includes the Data Transfer > Mode message element, which specifies the information desired by the > AC. The Data Transfer Request is sent by the WTP in order to > transfer actual data to the AC, through the Data Transfer Data > message element. > > Given that the CAPWAP protocol minimizes the need for WTPs to be > directly managed, the Data Transfer Request is an important > troubleshooting tool used by the AC to retrieve information that may > be available on the WTP. For instance, some WTPs implementations may > store crash information to help manufacturers identify software > faults. The Data Transfer Request message can be used to send such > information from the WTP to the AC. Another possible use would be to > allow a remote debugger function in the WTP to use the Data Transfer > Request message to send console output to the AC for debugging > purposes. > > When the WTP or AC receives a Data Transfer Request message it > responds to the WTP with a Data Transfer Response message. The AC > MAY log the information received through the Data Transfer Data > message element. > > The Data Transfer Request message is sent by the WTP or AC when in > the Run State. > > When sent by the AC, the Data Transfer Request message MUST contain > the following message elements: > > o Data Transfer Mode, see Section 4.6.17 > > When sent by the WTP, the Data Transfer Request message MUST contain > the following message elements: > > o Data Transfer Data, see Section 4.6.16 > > Regardless of whether the Data Transfer Request is sent by the AC or > WTP, the following message elements MAY be included in the Data > Transfer Request message: > > o Vendor Specific Payload, see Section 4.6.39 > > 9.6.2. Data Transfer Response > > The Data Transfer Response message acknowledges the Data Transfer > Request message. > > A Data Transfer Response message is sent in response to a received > Data Transfer Request message. Its purpose is to acknowledge receipt > of the Data Transfer Request message. When sent by the WTP, the > Result Code message element is used to indicate whether the data > transfer requested by the AC can be completed. When sent by the AC, > the Result Code message element is used to indicate receipt of the > data transfered in the Data Transfer Request message. > > The Data Transfer Response message is sent by the WTP or AC when in > the Run State. > > The following message element MUST be included in the Data Transfer > Response message. > > o Result Code, see Section 4.6.35 > > The following message elements MAY be included in the Data Transfer > Response message: > > o Vendor Specific Payload, see Section 4.6.39 > > Upon receipt of a Data Transfer Response message, the WTP transmits > more information, if more information is available. > > > PatC > > > ------------------------------ > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 7 14:32:55 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8BD828C25D for ; Mon, 7 Jul 2008 14:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgwaE6Kwxh9A for ; Mon, 7 Jul 2008 14:32:54 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 7B01828C299 for ; Mon, 7 Jul 2008 14:32:45 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 10BB01C40F6F for ; Mon, 7 Jul 2008 14:32:53 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 805C644010B for ; Mon, 7 Jul 2008 14:32:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5FF7F34AC002 for ; Mon, 7 Jul 2008 14:32:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id AB2C034AC04D for ; Mon, 7 Jul 2008 14:32:39 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 14:32:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,318,1212364800"; d="scan'208";a="49754047" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 07 Jul 2008 21:32:31 +0000 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/8.12.11) with ESMTP id m67LWV7a006670; Mon, 7 Jul 2008 14:32:31 -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.13.8/8.13.8) with ESMTP id m67LWVvA004585; Mon, 7 Jul 2008 21:32:31 GMT 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.1830); Mon, 7 Jul 2008 14:32:30 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 14:32:29 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D18D7@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] FSM issues Thread-Index: AcjgUV1XslakisRxQii12u/tZYFbOAACaHAw References: <4FF84B0BC277FF45AA27FE969DD956A2060D131F@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D15BC@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Yong Zhang" X-OriginalArrivalTime: 07 Jul 2008 21:32:30.0764 (UTC) FILETIME=[F5FB3EC0:01C8E078] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] FSM issues 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 Ah, I see. Yes, this does need to be mentioned, thanks for pointing that out. The issue being raised here is that the Echo Request is used by a WTP to keep its session alive with the AC. However, if the AC doesn't receive an Echo Request in a certain amount of time, it needs to consider the WTP dead (this text is already covered in section 7.2). Note that this does not break interoperability with -10. The older spec was ambiguous in how the AC would timeout a WTP, and I suspect that most people at least implemented what's being described below. The change is specifically around being clear when the EchoInterval is set/reset in the actual FSM. It was mentioned already in the description of the Echo Request and Echo Response messages, but it does need to also be mentioned in the FSM. The only new change is the mention of the EchoInterval timer being reset on the WTP when it transmits a request to the AC while in the Run state. Similarly, the AC resets its own EchoInterval timer when it receives a request from the WTP. This language is necessary in order to fulfill the language from section 4.5: 4.5. 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 Control Channel Management Echo Request and Echo Response messages provide an explicit keep-alive mechanism when other CAPWAP control messages are not exchanged. Here is the new proposed text. Note that the text in section 4.6.14 is only the mention of how the EchoInterval is set on the AC. No other changes are made: Run to Run (q): This is the normal state of operation. WTP: This is the WTP's normal state of operation. The WTP resets its EchoInterval timer whenever it transmits a request to the AC. There are many events that result this state transition: [...] Echo Request: The WTP sends an Echo Request message (Section 7.1) or receives the corresponding Echo Response message, (see Section 7.2) from the AC. When the WTP receives the Echo Response, it resets its EchoInterval timer (see Section 4.7.7). [...] AC: This is the AC's normal state of operation. Note that the receipt of any Request from the WTP causes the AC to reset its EchoInterval timer (see Section 4.7.7). [...] Echo Request: The AC receives an Echo Request message (see Section 7.1), to which it MUST respond with an Echo Response message(see Section 7.2). Run to DTLS Teardown (p): This state transition occurs when an error has occurred in the DTLS stack, causing the DTLS session to be torn down. [...] AC: The AC enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The AC transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7). This state transition also occurs when the AC's EchoInterval timer expires (see Section 4.7.7). 4.6.14. CAPWAP Timers The CAPWAP Timers message element is used by an AC to configure CAPWAP timers on a WTP. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discovery | Echo Request | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [...] Echo Request: The number of seconds between WTP Echo Request CAPWAP messages. This value is used to configure the EchoInterval timer (see Section 4.7.7). The AC sets its EchoInterval timer to this value, plus the maximum retransmission time as described in Section 4.5.3. PatC -----Original Message----- From: Yong Zhang [mailto:yozhang@gmail.com] Sent: Monday, July 07, 2008 9:49 AM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Re: [Capwap] FSM issues I want to say for 5 is that: Only WTP sends echo request. So if the WTP is dead, the AC will not be able to receive the echo req, and this will trigger a failure event in AC side after some time. We need to add this event to FSM. Since AC does not send the req, " the retransmission, and subsequent timeout, ..." will not be used. Yong On Mon, Jul 7, 2008 at 4:21 AM, Pat Calhoun (pacalhou) wrote: > 4. Run to Run. I now understand the point you are trying to make. The > text for Clear Configuration Request/Response is not consistent with > the other commands in this section. I am proposing the following > changes, which does not change any behavior, but only creates more > consistency in the text: > > > Run to Run (q): This is the normal state of operation. > > WTP: This is the WTP's normal state of operation. There are many > events that result this state transition: > [...] > Clear Config Request: The WTP receives a Clear Configuration > Request message (see Section 8.8) and MUST generate a > corresponding Clear Configuration Response message (see > Section 8.9). The WTP MUST reset its configuration back to > manufacturer defaults. > [...] > AC: This is the AC's normal state of operation: > [...] > Clear Config Response: The AC sends a Clear Configuration > Request message (see Section 8.8) to the WTP to clear its > configuration. The AC receives a Clear Configuration > Response message from the WTP (see Section 8.9). > > > 5. Unfortunately, I'm still not understanding the issue you are trying > to raise. I am not claiming that the AC sends echo requests, I am > simply stating that requests (in general) can be transmitted by either > the WTP or the AC, while certain requests may have restrictions which > are clearly documented in the spec. So regardless of whether a request > is an echo request, or any other request, the retransmission, and > subsequent timeout, is the same. Therefore there is no need to add a > specific clause for echo requests timing out. > > PatC > -----Original Message----- > From: Yong Zhang [mailto:yozhang@gmail.com] > Sent: Thursday, July 03, 2008 1:41 PM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: Re: [Capwap] FSM issues > >>> 4. Run to Run (q): AC >>> >>> Clear Config Response: The AC receives a Clear Configuration >>> Response message from the WTP (see Section 8.9). >>> >>> Need to add Clear Configuration REQ send. >> I'm not sure that I understand what you are saying. This event occurs >> when the response is received. The Request was sent some time ago, >> hence why the response was received. The receive of the Clear Config >> Request is handled in the WTP section, and is present already. > > Refer to other messages description in AC RUN state: Ac need to send > out the REQ, and AC need to receive RESP. > Just WTP clear Config Response also has the problem. > > >>> 5. Run to DTLS Teardown (p) maybe need to add echo failure case. >>> >>> "transitions to this state if the underlying reliable >>> transport's RetransmitCount counter has reached the >>> MaxRetransmit variable (see Section 4.7)." >>> >>> This can cover WTP, but not AC. >> The echo would cause a retransmission timeout, which makes use of the >> RetransmitCount counter. I guess I'm not sure that I understand the >> issue you are trying to raise. Both the WTP and the AC can transmit >> requests, so it is possible that either side timeouts, forcing this >> state transition. >> > > I only see the WTP sends REQ, and AC recvs RESP. Where is it said > that AC also sends ECHO REQ? > > > On Thu, Jul 3, 2008 at 1:22 PM, Pat Calhoun (pacalhou) > wrote: >> I have created issue 139 to track these issues. >> >>> 1. waitDTLS is not started in the 2.3.1 CAPWAP Proto State >> Transitions, although it is said in CAPWAP/DTLS interface >>> chapter. >> Yes, you are correct. The description for the StartDTLS command is >> clear that the WaitDTLS timer needs to be started, but it would be >> worth including this in the state transition description, as all of >> the other timers are also included in that section. >> >> >> Idle to DTLS Setup (3): This transition occurs to establish a > secure >> DTLS session with the peer. >> >> WTP: The WTP initiates this transition by invoking the DTLSStart >> command(see Section 2.3.2.1), which starts the DTLS session >> establishment with the chosen AC and the WaitDTLS timer is >> started (see Section 4.7). When the discovery phase is >> bypassed, it is assumed the WTP has locally configured ACs. >> >> >>> 2. Join REQ need to be send at here. >>> >>> DTLS Connect to Join (d): This transition occurs when the DTLS >>> Session is successfully established. >>> >>> WTP: This state transition occurs when the WTP receives the >>> DTLSEstablished notification (see Section 2.3.2.2), > indicating >>> that the DTLS session was successfully established. When > this >>> notification is received, the FailedDTLSSessionCount counter >> is >>> set to zero. >> Yes, this was a strange omission - an obvious thing to do, but it >> needs to be very clear. >> >> >> DTLS Connect to Join (d): This transition occurs when the DTLS >> Session is successfully established. >> >> WTP: This state transition occurs when the WTP receives the >> DTLSEstablished notification (see Section 2.3.2.2), indicating >> that the DTLS session was successfully established. When this >> notification is received, the FailedDTLSSessionCount counter > is >> set to zero. The WTP enters the Join state by transmiting the >> Join Request to the AC. >> >> >>> 3. >>> Data Check to DTLS Teardown (n): This transition occurs when the WTP >>> does not complete the Data Check exchange. >>> >>> WTP: This state transition occurs if the WTP does not receive >> the >>> Change State Event Response message before a CAPWAP >>> transmission timeout occurs. >>> >>> Does the above need to be change to something like >> RetransmitCount >>> counter has reached the MaxRetransmit variable? Since we do not >>> use >> transmission timeout timer. >> Yes, good point. I am including the same text we have in other state >> transitions. >> >> >> Data Check to DTLS Teardown (n): This transition occurs when the > WTP >> does not complete the Data Check exchange. >> >> WTP: This state transition occurs if the WTP does not receive > the >> Change State Event Response message before a CAPWAP >> retransmission timeout occurs. The WTP also transitions to >> this state if the underlying reliable transport's >> RetransmitCount counter has reached the MaxRetransmit variable >> (see Section 4.7). >> >> >>> 4. Run to Run (q): AC >>> >>> Clear Config Response: The AC receives a Clear Configuration >>> Response message from the WTP (see Section 8.9). >>> >>> Need to add Clear Configuration REQ send. >> I'm not sure that I understand what you are saying. This event occurs >> when the response is received. The Request was sent some time ago, >> hence why the response was received. The receive of the Clear Config >> Request is handled in the WTP section, and is present already. >> >>> 5. Run to DTLS Teardown (p) maybe need to add echo failure case. >>> >>> "transitions to this state if the underlying reliable >>> transport's RetransmitCount counter has reached the >>> MaxRetransmit variable (see Section 4.7)." >>> >>> This can cover WTP, but not AC. >> The echo would cause a retransmission timeout, which makes use of the >> RetransmitCount counter. I guess I'm not sure that I understand the >> issue you are trying to raise. Both the WTP and the AC can transmit >> requests, so it is possible that either side timeouts, forcing this >> state transition. >> >> PatC >> >> -----Original Message----- >> From: Yong Zhang [mailto:yozhang@gmail.com] >> Sent: Thursday, July 03, 2008 11:48 AM >> To: capwap@frascone.com >> Subject: [Capwap] FSM issues >> >> 1. waitDTLS is not started in the 2.3.1 CAPWAP Proto State >> Transitions, although it is said in CAPWAP/DTLS interface chapter. >> >> 2. Join REQ need to be send at here. >> >> DTLS Connect to Join (d): This transition occurs when the DTLS >> Session is successfully established. >> >> WTP: This state transition occurs when the WTP receives the >> DTLSEstablished notification (see Section 2.3.2.2), indicating >> that the DTLS session was successfully established. When this >> notification is received, the FailedDTLSSessionCount counter > is >> set to zero. >> >> 3. >> Data Check to DTLS Teardown (n): This transition occurs when the WTP >> does not complete the Data Check exchange. >> >> WTP: This state transition occurs if the WTP does not receive > the >> Change State Event Response message before a CAPWAP >> transmission timeout occurs. >> >> Does the above need to be change to something like >> RetransmitCount > >> counter has reached the MaxRetransmit variable? Since we do not use >> transmission timeout timer. >> >> 4. Run to Run (q): AC >> >> Clear Config Response: The AC receives a Clear Configuration >> Response message from the WTP (see Section 8.9). >> >> Need to add Clear Configuration REQ send. >> >> 5. Run to DTLS Teardown (p) maybe need to add echo failure case. >> >> "transitions to this state if the underlying reliable >> transport's RetransmitCount counter has reached the >> MaxRetransmit variable (see Section 4.7)." >> >> This can cover WTP, but not AC. >> >> >> Yong >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap >> > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 7 14:37:06 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE23328C248 for ; Mon, 7 Jul 2008 14:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mjz55kmz-Z3B for ; Mon, 7 Jul 2008 14:37:05 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 4B9E728C299 for ; Mon, 7 Jul 2008 14:36:43 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E23201C40F8D for ; Mon, 7 Jul 2008 14:36:50 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 29C4E44010B for ; Mon, 7 Jul 2008 14:36:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id EDDE934AC002 for ; Mon, 7 Jul 2008 14:36:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E713D34AC023 for ; Mon, 7 Jul 2008 14:36:34 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 14:36:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,318,1212364800"; d="scan'208";a="63381512" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 07 Jul 2008 21:36:34 +0000 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/8.12.11) with ESMTP id m67LaYTo023387; Mon, 7 Jul 2008 14:36:34 -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.13.8/8.13.8) with ESMTP id m67LaYEp026400; Mon, 7 Jul 2008 21:36:34 GMT 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, 7 Jul 2008 14:36:34 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 14:36:33 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D18DF@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 143: Data Transfer Request is too ambiguous Thread-Index: AcjgbmloiD8xu6ENQg+mTfKZsBVVtwACwjfg References: <4FF84B0BC277FF45AA27FE969DD956A2060D17DD@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Yong Zhang" X-OriginalArrivalTime: 07 Jul 2008 21:36:34.0480 (UTC) FILETIME=[873F5B00:01C8E079] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 143: Data Transfer Request is too ambiguous 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 Thanks Yong. Are you OK with the proposal with the change you mentioned? PatC -----Original Message----- From: Yong Zhang [mailto:yozhang@gmail.com] Sent: Monday, July 07, 2008 1:17 PM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 143: Data Transfer Request is too ambiguous Data Length need to be 16 bits. (Data Transfer Data ME figure need to be changed) ME len >= 5. Yong On Mon, Jul 7, 2008 at 12:13 PM, Pat Calhoun (pacalhou) wrote: > Thanks for the feedback. Yes, you caught two bugs. > > To address your open issue below, how about: > > 4.6.16. Data Transfer Data > > The Data Transfer Data message element is used by the WTP to provide > information to the AC for debugging purposes. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data Type | Data Mode | Data Length | Data .... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: 16 for Data Transfer Data > > Length: >= 3 > > Data Type: An 8-bit value representing the transfer Data Type. The > following enumerated values are supported: > > 1 - Transfer data is included > > 2 - Last Transfer Data Block is included (EOF) > > 5 - An error occurred. Transfer is aborted > > Data Mode: An 8-bit value the type of information being > transmitted. The following enumerated values are supported: > > 0 - Reserved > > 1 - WTP Crash Data > > 2 - WTP Memory Dump > > Data Length: Length of data field, with a maximum size of 65535. > > Data: Data being transferred from the WTP to the AC, whose type is > identified via the Data Mode field. > > 4.6.17. Data Transfer Mode > > The Data Transfer Mode message element is used by the WTP to indicate > the type of data transfer information it is sending to the AC for > debugging purposes. > > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | Data Mode | > +-+-+-+-+-+-+-+-+ > > Type: 17 for Data Transfer Mode > > Length: 1 > > Data Mode: An 8-bit value the type of information being requested. > The following enumerated values are supported: > > 0 - Reserved > > 1 - WTP Crash Data > > 2 - WTP Memory Dump > > > PatC > -----Original Message----- > From: Yong Zhang [mailto:yozhang@gmail.com] > Sent: Monday, July 07, 2008 11:25 AM > To: capwap@frascone.com > Subject: Re: [Capwap] Issue 143: Data Transfer Request is too > ambiguous > > There are two issues here: > > 1. 4.6.16. Data Transfer Data > > The Data Transfer Data message element is used by the WTP to provide > information to the AC for debugging purposes. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data Type | Data Length | Data .... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Data Length/Data bit fields are not correct in the above fig. > > 2. Figure 10. It's WTP send EOF. > > > If the Data Transfer Mode/data are used in different messages, I think > it would be better to keep the mode info in the Data Transfer Data ME. > It will be easier when you need to analyze the capwap messages. > > > Yong > > ------------------------------ > > Message: 7 > Date: Mon, 7 Jul 2008 10:57:08 -0700 > From: "Pat Calhoun (pacalhou)" > Subject: [Capwap] Issue 143: Data Transfer Request is too ambiguous > To: > Message-ID: > > <4FF84B0BC277FF45AA27FE969DD956A2060D174C@xmb-sjc-235.amer.cisco.com> > Content-Type: text/plain; charset="us-ascii" > > All, > > Yong has raised a series of questions about the use of the Data > Transfer Request/Response which are pointing out that the text is > simply too ambiguous. I looked at the text again, and I agree that it needs work. > Some time ago we had agreed to clean up the Image Transfer exchanges > to allow the AC to know the size of the data being transfered, etc. We > also agreed to include figures to help provide more clarity on how the > exchange occurred. > > Clearly, we need something similar for the Data Transfer section. > Furthermore, I have found a bug that the Data Transfer Request > currently states that it cannot be sent by the AC, which is incorrect. > The AC is supposed to send this in order to request the information to begin with. > > > Please see the following proposed text to handle this issue. Note that > this will "sort-of" break compatibility with -10 but I doubt we will > see any issues because -10 had no way for the AC to initiate the request. > > > 2.3.1. CAPWAP Protocol State Transitions [...] Run to Run (q): This > is the normal state of operation. > > WTP: This is the WTP's normal state of operation. There are many > events that result this state transition: > [...] > Data Transfer: The WTP sends a Data Transfer Request or Data > Transfer Response message to the AC (see Section 9.6). The > WTP receives a Data Transfer Request or Data Transfer > Response message from the AC (see Section 9.6). Upon > receipt of a Data Transfer Request, the WTP transmits a Data > Transfer Response to the AC. > [...] > AC: This is the AC's normal state of operation: > [...] > Data Transfer: The AC sends a Data Transfer Request or Data > Transfer Response message to the WTP (see Section 9.6). The > AC receives a Data Transfer Request or Data Transfer > Response message from the WTP (see Section 9.6). Upon > receipt of a Data Transfer Request, the AC transmits a Data > Transfer Response to the WTP. > 4.6.16. Data Transfer Data > > The Data Transfer Data message element is used by the WTP to provide > information to the AC for debugging purposes. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data Type | Data Length | Data .... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: 16 for Data Transfer Data > > Length: >= 3 > > Data Type: An 8-bit value representing the transfer Data Type. The > following enumerated values are supported: > > 1 - Transfer data is included > > 2 - Last Transfer Data Block is included (EOF) > > 5 - An error occurred. Transfer is aborted > > Data Length: Length of data field, with a maximum size of 65535. > > Data: Debug information. > > > 9.6. Data Transfer > > This section describes the data transfer procedures used by the > CAPWAP protocol. The data transfer mechanism is used to upload > information available at the WTP to the AC, such as crash or debug > information. The data transfer messages can only be exchanged while > in the Run state. > > Figure 10 provides an example of an AC that requests that the WTP > transfer its latest crash file. Once the WTP acknowledges that it > has information to send, via the Data Transfer Response, it transmits > its own Data Transfer Request. Upon receipt, the AC responds with a > Data Transfer Response, and the exchange continues until the WTP > transmits a Data Transfer Data message element that indicates an End > of File (EOF). > > WTP AC > > Data Transfer Request (Data Transfer Mode = Crash Data) > <------------------------------------------------------ > > Data Transfer Response (Result Code = Success) > --------------------------------------------------------> > > Data Transfer Request (Data Transfer Data = Data) > --------------------------------------------------------> > > Data Transfer Response (Result Code = Success) > <------------------------------------------------------ > > ..... > > Data Transfer Request (Data Transfer Data = EOF) > <------------------------------------------------------ > > Data Transfer Response (Result Code = Success) > --------------------------------------------------------> > > > Figure 10: WTP Data Transfer Case 1 > > Figure 11 provides an example of an AC that requests that the WTP > transfer its latest crash file. However, in this example, the WTP > does not have any crash information to send, and therefore sends a > Data Transfer Response with a Result Code indicating the error. > > WTP AC > > Data Transfer Request (Data Transfer Mode = Crash Data) > <------------------------------------------------------ > > Data Transfer Response (Result Code = Data Transfer > Error (No Information to Transfer)) > --------------------------------------------------------> > > > Figure 11: WTP Data Transfer Case 2 > > 9.6.1. Data Transfer Request > > The Data Transfer Request message is used to deliver debug > information from the WTP to the AC. > > The Data Transfer Request messages can be sent either by the AC or > the WTP. When sent by the AC, it is used to request that data be > transmitted from the WTP to the AC, and includes the Data Transfer > Mode message element, which specifies the information desired by the > AC. The Data Transfer Request is sent by the WTP in order to > transfer actual data to the AC, through the Data Transfer Data > message element. > > Given that the CAPWAP protocol minimizes the need for WTPs to be > directly managed, the Data Transfer Request is an important > troubleshooting tool used by the AC to retrieve information that may > be available on the WTP. For instance, some WTPs implementations may > store crash information to help manufacturers identify software > faults. The Data Transfer Request message can be used to send such > information from the WTP to the AC. Another possible use would be to > allow a remote debugger function in the WTP to use the Data Transfer > Request message to send console output to the AC for debugging > purposes. > > When the WTP or AC receives a Data Transfer Request message it > responds to the WTP with a Data Transfer Response message. The AC > MAY log the information received through the Data Transfer Data > message element. > > The Data Transfer Request message is sent by the WTP or AC when in > the Run State. > > When sent by the AC, the Data Transfer Request message MUST contain > the following message elements: > > o Data Transfer Mode, see Section 4.6.17 > > When sent by the WTP, the Data Transfer Request message MUST contain > the following message elements: > > o Data Transfer Data, see Section 4.6.16 > > Regardless of whether the Data Transfer Request is sent by the AC or > WTP, the following message elements MAY be included in the Data > Transfer Request message: > > o Vendor Specific Payload, see Section 4.6.39 > > 9.6.2. Data Transfer Response > > The Data Transfer Response message acknowledges the Data Transfer > Request message. > > A Data Transfer Response message is sent in response to a received > Data Transfer Request message. Its purpose is to acknowledge receipt > of the Data Transfer Request message. When sent by the WTP, the > Result Code message element is used to indicate whether the data > transfer requested by the AC can be completed. When sent by the AC, > the Result Code message element is used to indicate receipt of the > data transfered in the Data Transfer Request message. > > The Data Transfer Response message is sent by the WTP or AC when in > the Run State. > > The following message element MUST be included in the Data Transfer > Response message. > > o Result Code, see Section 4.6.35 > > The following message elements MAY be included in the Data Transfer > Response message: > > o Vendor Specific Payload, see Section 4.6.39 > > Upon receipt of a Data Transfer Response message, the WTP transmits > more information, if more information is available. > > > PatC > > > ------------------------------ > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/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 Jul 7 14:48:03 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 979BB3A67CE for ; Mon, 7 Jul 2008 14:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXaJi5oKMms0 for ; Mon, 7 Jul 2008 14:48:02 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 4294F3A6B64 for ; Mon, 7 Jul 2008 14:47:53 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DA21F1C40F49 for ; Mon, 7 Jul 2008 14:48:00 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 3B49544007D for ; Mon, 7 Jul 2008 14:47:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id EC1AE34AC023 for ; Mon, 7 Jul 2008 14:47:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id F0A6234AC021 for ; Mon, 7 Jul 2008 14:47:46 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 14:47:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,318,1212364800"; d="scan'208";a="63384365" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 07 Jul 2008 21:47:27 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m67LlRBW028270; Mon, 7 Jul 2008 14:47:27 -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.13.8/8.13.8) with ESMTP id m67LlRU9021223; Mon, 7 Jul 2008 21:47:27 GMT 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.1830); Mon, 7 Jul 2008 14:47:27 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 14:47:26 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D18EF@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Issue 106: WaitJoin may be unnecessary Thread-Index: AcjgUeoVMWxOFXpaQyG7UAhCDN0xnQAKJWhQ References: <4FF84B0BC277FF45AA27FE969DD956A205F5CDE6@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A205FDD776@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D15C0@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Yong Zhang" X-OriginalArrivalTime: 07 Jul 2008 21:47:27.0442 (UTC) FILETIME=[0C717320:01C8E07B] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] New Issue 106: WaitJoin may be 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 Got it - and while this information is available in other places in the spec, it needs to be clear in the FSM state transition descriptions as well. The change below is to add specific text about the state transitions occuring when the WaitDTLS timer expires. The last change below mentions that the WaitDTLS timer is stopped when the 'DTLS Connect to Join' state transition occurs. This is not new, as it is mentioned in the Join Request in section 6.1, but having it in the FSM will help implementors by not needing to find this out only when reading later in the spec. 2.3.1. CAPWAP Protocol State Transitions [...] DTLS Setup to Idle ($): This transition occurs when the DTLS connection setup fails. WTP: The WTP initiates this state transition when it receives a DTLSEstablishFail notification from DTLS (see Section 2.3.2.2), and the FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter have not reached the value of the MaxFailedDTLSSessionRetry variable (see Section 4.8). This error notification aborts the secure DTLS session establishment. When this notification is received, the FailedDTLSSessionCount counter is incremented. This state transition also occurs if the WaitDTLS timer has expired. [...] Authorize to DTLS Teardown (b): This transition occurs to notify the DTLS stack that the session should be aborted. WTP: This state transition occurs when the WTP was unable to authorize the AC, using the AC credentials. The WTP then aborts the DTLS session by invoking the DTLSAbortSession command (see Section 2.3.2.1). This state transition also occurs if the WaitDTLS timer has expired. AC: This state transition occurs when the AC was unable to authorize the WTP, using the WTP credentials. The AC then aborts the DTLS session by invoking the DTLSAbortSession command (see Section 2.3.2.1). This state transition also occurs if the WaitDTLS timer has expired. [...] DTLS Connect to DTLS Teardown (c): This transition occurs when the DTLS Session failed to be established. WTP: This state transition occurs when the WTP receives either a DTLSAborted or DTLSAuthenticateFail notification (see Section 2.3.2.2), indicating that the DTLS session was not successfully established. When this transition occurs due to the DTLSAuthenticateFail notification, the FailedDTLSAuthFailCount is incremented, otherwise the FailedDTLSSessionCount counter is incremented. This state transition also occurs if the WaitDTLS timer has expired. AC: This state transition occurs when the AC receives either a DTLSAborted or DTLSAuthenticateFail notification (see Section 2.3.2.2), indicating that the DTLS session was not successfully established, and both of the FailedDTLSAuthFailCount and FailedDTLSSessionCount counters have not reached the value of the MaxFailedDTLSSessionRetry variable (see Section 4.8). This state transition also occurs if the WaitDTLS timer has expired. [...] DTLS Connect to Join (d): This transition occurs when the DTLS Session is successfully established. WTP: This state transition occurs when the WTP receives the DTLSEstablished notification (see Section 2.3.2.2), indicating that the DTLS session was successfully established. When this notification is received, the FailedDTLSSessionCount counter is set to zero. The WTP enters the Join state by transmiting the Join Request to the AC. The WTP stops the WaitDTLS timer. AC: This state transition occurs when the AC receives the DTLSEstablished notification (see Section 2.3.2.2), indicating that the DTLS session was successfully established. When this notification is received, the FailedDTLSSessionCount counter is set to zero. The AC stops the WaitDTLS timer. PatC -----Original Message----- From: Yong Zhang [mailto:yozhang@gmail.com] Sent: Monday, July 07, 2008 9:53 AM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Re: New Issue 106: WaitJoin may be unnecessary This is OK. But I found another issue. We did not process the WaitDTLS timer expire event in the several DTLS states. Yong On Mon, Jul 7, 2008 at 4:27 AM, Pat Calhoun (pacalhou) wrote: > All, > > Here is the actual text handling this change, which I have reviewed > with Yong and he has responded that he is OK with the change. The AC > in the spec was using the WaitJoin timer, so I had to make a couple of > changes to two state transisions to make sure that the AC was making > proper use of the WaitDTLS timer: > > > Idle to DTLS Setup (3): This transition occurs to establish a secure > DTLS session with the peer. > > WTP: The WTP initiates this transition by invoking the DTLSStart > command(see Section 2.3.2.1), which starts the DTLS session > establishment with the chosen AC and the WaitDTLS timer is > started (see Section 4.7). When the discovery phase is > bypassed, it is assumed the WTP has locally configured ACs. > > AC: Upon entering the Idle state from the Start state, the newly > created Listener thread automatically transitions to the DTLS > Setup and invokes the DTLSListen command (see Section 2.3.2.1), > and the WaitDTLS timer is started (see Section 4.7). <===== > THE TIMER IS STARTED > > > Join to DTLS Teardown (e): This transition occurs when the join > process failed. > > WTP: This state transition occurs when the WTP receives a Join > Response message with a Result Code message element containing > an error, if the Image Identifier provided by the AC in the > Join Response message differs from the WTP's currently running > firmware version and the WTP has the requested image in its > non-volatile memory, or if the WaitDTLS timer expires. This > causes the WTP to initiate the DTLSShutdown command (see > Section 2.3.2.1). This transition also occurs if the WTP > receives one of the following DTLS notifications: DTLSAborted, > DTLSReassemblyFailure or DTLSPeerDisconnect. > > AC: This state transition occurs either if the WaitDTLS timer > <=== THE TIMER EXPIRES > expires or if the AC transmits a Join Response message with a > Result Code message element containing an error. This causes > the AC to initiate the DTLSShutdown command (see > Section 2.3.2.1). This transition also occurs if the AC > receives one of the following DTLS notifications: DTLSAborted, > DTLSReassemblyFailure or DTLSPeerDisconnect. > > > PatC > -----Original Message----- > From: Yong Zhang [mailto:yozhang@gmail.com] > Sent: Tuesday, July 01, 2008 1:37 PM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: Re: New Issue 106: WaitJoin may be unnecessary > > This change is OK for me. > > Yong > > On Thu, Jun 26, 2008 at 4:53 AM, Pat Calhoun (pacalhou) > wrote: >> I believe you may be correct that there is a technical issue. >> >> Originally, the WaitJoin was used to timeout if the WTP did not sent >> the Join Request, or the AC did not send the Join Response. However, >> when DTLS was introduced, we started to rely on the WaitDTLS timer. >> It > >> seems like we've started to rely much more on the WaitDTLS timer in >> the latter drafts, to the point where I believe that we could simply >> remove the WaitJoin timer and have little impact to the state machine. >> >> From what I can tell, the "Join to DTLS Teardown (e)" state >> transition > >> currently triggers if the WaitJoin timer expires, and we would have >> to > >> change this to WaitDTLS instead. Further, the "DTLS Connect to Join > (d)" >> state transition would simply need to have its reference to WaitJoin >> removed. >> >> So since it appears as if the WaitDTLS timers are initialized >> properly, the timeout triggers are properly defined, and it is well >> specified in its handling during the Join Request/Response in section >> 6.1 and 6.2, this change would have mimimal impact. >> >> Thoughts? >> >> PatC >> >> -----Original Message----- >> From: Yong Zhang [mailto:yozhang@gmail.com] >> Sent: Friday, June 20, 2008 11:19 AM >> To: Pat Calhoun (pacalhou) >> Cc: capwap@frascone.com >> Subject: Re: [Capwap] WaitDTLS/WaitJoin timers >> indraft-ietf-capwap-protocol-specification-10.txt >> >> This info is clear. But in the spec., the WaitDTLS covers the > WaitJoin. >> WairDTLS timer is not cleared after the DTLS session is esatblished, >> but it is only cleared after the Join REQ/RESP are received. (6.1/2 >> describes this). >> >> Thanks! >> >> Yong >> >> On Fri, Jun 20, 2008 at 10:55 AM, Pat Calhoun (pacalhou) >> wrote: >>> The intent for both timers is: >>> >>> WaitDTLS: This timer is used to make sure that the DTLS session is >>> established within the required timeframe. If the DTLS session isn't >>> setup, perhaps because either party is not responding, then the >>> timer > >>> will trigger and the state will change. >>> >>> WaitJoin: Once the DTLS session has been established, we need to >>> protect against a WTP that opts to NOT send a Join Request. So in >>> this >> >>> instance, the WaitJoin would trigger, and the state would once more >> change. >>> >>> PatC >>> >>> -----Original Message----- >>> From: Yong Zhang [mailto:yozhang@gmail.com] >>> Sent: Friday, June 20, 2008 9:54 AM >>> To: capwap@frascone.com >>> Subject: [Capwap] WaitDTLS/WaitJoin timers >>> indraft-ietf-capwap-protocol-specification-10.txt >>> >>> WaitDTLS by its name should be DTLS session setup related, but this >>> spec. (6.1/2) requires it deactivated after the Join Req/Resp are >>> received. >>> >>> WaitJoin seems no use in this case?? >>> >>> Also the WaitDTLS timer is started earlier than WaitJoin timer, >>> however, the default value for these two timers (4.7.15/16) are all >>> 60s. if WaitJoin has some other use, it need to have a less value >>> than >> >>> WaitDTLS to work. >>> >>> Yong >>> _________________________________________________________________ >>> To unsubscribe or modify your subscription options, please visit: >>> http://lists.frascone.com/mailman/listinfo/capwap >>> >>> Archives: http://lists.frascone.com/pipermail/capwap >>> >> > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 7 14:59:07 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D45853A69D9 for ; Mon, 7 Jul 2008 14:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRDUYz7NrqXv for ; Mon, 7 Jul 2008 14:59:07 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 1AB753A6781 for ; Mon, 7 Jul 2008 14:59:07 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BBE381C40FA5 for ; Mon, 7 Jul 2008 14:59:14 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 9A87044007D for ; Mon, 7 Jul 2008 14:59:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 796FB34AC017 for ; Mon, 7 Jul 2008 14:59:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 9C18A34AC021 for ; Mon, 7 Jul 2008 14:58:56 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 14:58:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,318,1212364800"; d="scan'208";a="123569336" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 07 Jul 2008 21:58:56 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m67LwurK023253 for ; Mon, 7 Jul 2008 14:58: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.13.8/8.13.8) with ESMTP id m67LwuKj003009 for ; Mon, 7 Jul 2008 21:58:56 GMT 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, 7 Jul 2008 14:58:55 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 14:58:55 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D1905@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Issue 144: Invalid reference to message element field Thread-Index: AcjgfKZfeYReC/cKQSeQ7ARrPAMVtw== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 07 Jul 2008 21:58:55.0812 (UTC) FILETIME=[A6BE6040:01C8E07C] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Capwap] New Issue 144: Invalid reference to message element 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Yong has raised another issue. The following message elements have a Num of Entries field, which references a Type field, which does not exist in the message element. The 'Type' field needs to be 'Length': 4.6.7. Add MAC ACL Entry 4.6.9. Add Static MAC ACL Entry 4.6.20. Delete MAC ACL Entry 4.6.22. Delete Static MAC ACL Entry So the following text: Num of Entries: The number of instances of the Type/MAC Addresses fields in the array. This field MUST NOT exceed the value of 255. Needs to be modified to: Num of Entries: The number of instances of the Length/MAC Addresses fields in the array. This field MUST NOT exceed the value of 255. 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 Mon Jul 7 15:28:49 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CAF128C300 for ; Mon, 7 Jul 2008 15:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKB2oJrnrUBD for ; Mon, 7 Jul 2008 15:28:48 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 7A08F28C2FD for ; Mon, 7 Jul 2008 15:28:48 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2572A1C40F84 for ; Mon, 7 Jul 2008 15:28:56 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 676054400CB for ; Mon, 7 Jul 2008 15:28:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 49E8634AC015 for ; Mon, 7 Jul 2008 15:28:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id BC6AC34AC023 for ; Mon, 7 Jul 2008 15:28:44 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 15:28:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,318,1212364800"; d="scan'208";a="49778167" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 07 Jul 2008 22:28:44 +0000 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/8.12.11) with ESMTP id m67MSiTl032182; Mon, 7 Jul 2008 15:28:44 -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.13.8/8.13.8) with ESMTP id m67MSirA007963; Mon, 7 Jul 2008 22:28:44 GMT 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, 7 Jul 2008 15:28:44 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 15:28:43 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D1930@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] 802.11 binding doc. issues Thread-Index: AcjgWXBZpaIy7726S32Np5p5+KNqMAAI1rlQ References: From: "Pat Calhoun (pacalhou)" To: "Yong Zhang" , X-OriginalArrivalTime: 07 Jul 2008 22:28:44.0085 (UTC) FILETIME=[D0A32E50:01C8E080] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Capwap] 802.11 binding doc. issues 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 Created issue 145 to track this one. Responses below. PatC On Mon, Jul 7, 2008 at 10:30 AM, Yong Zhang wrote: > 3.2. IEEE 802.11 WLAN Configuration Response > > Can we put MUST ME earlier than MAY ME for this message in the message definition? Done. We now have consistency in ordering across both docs. > > > 6.1 > > The len should be >=52? > > 4 + 4 + 32 + 4 + 4 + 4 = 52 (assume SSID to be at least 1 byte) > > We have a key length field, however, > > "Key: A 32 byte Session Key to use to provide data privacy. " Yes, that is correct and I have fixed this. > > 6.2 > > len = 5 No, this is not correct. The Antenna Selection field will be of length 'Antenna Count'. > > 6.3 > > len = 8 Correct. > > 6.6 > > This is used to include only one IE? If it is, should we remove the > "..." in the figure? > > Also the len is bigger than 4. The minimal len of IE is 1 ? No, the ... Implies the length of the field is variable and may be greater than 1. I think the length is fine. > > 6.13 > > len >= 14 > > I am not sure the minimal size of supported rates. Here assume it is one. Correct. > > 6.14 > > Here the 802.1p tag is defined with 2 bytes, but other places only use > 1 byte. Only the 3 least > significant bits are used. We had agreed to leave this as is to minimize backward compatibility issues, as per Margaret's request. > > 6.15. > > I am not familiar with the keys. How do you get the length value? The > minimal length of Key is 5 bytes? Depends on the crypto used. The 802.11 spec is clear about this. > > 6.16 > > len is 80 Yes > > > 6.21 > > len is 40 > > same issue on Key as 6.1 Correct > > 6.22 > > "tag packets" is bit value? Can I set the tag the packet with both 1p > and DSCP? If I can, we need to add a value 3. > > Immediately following the above header is the following data > structure. This data structure will be repeated five times; once > for every QoS profile. The order of the QoS profiles are Voice, > Video, Best Effort and Background. > > Here should be "four times". > > Are the above mandatory? If they are, the ME len is ( 2 + 8 * 4) = 34. Correct - and no, only one or the other is possible at this point. > > > 7.4. IEEE80211OFDMControl > > The WTP per radio MAC Operation configuration, defined in > Section 6.10. > > OFDM Not sure what your comment is. > > > 8. Technology Specific Message Element Values > > I do not know which capwap ME is talking about at here. How to use the > defined value here? Interesting. This was an xml bug in my source code. I have fixed it and the new text is: 8.1. WTP Descriptor Message Element, Encryption Capabilities Field: IEEE 802.11 uses the following values: 4 - Encrypt AES-CCMP 128: WTP supports AES-CCMP, as defined in [IEEE.802-11.2007]. 5 - Encrypt TKIP-MIC: WTP supports TKIP and Michael, as defined in [IEEE.802-11.2007] and [WPA], respectively. 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 Mon Jul 7 18:48:11 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C8A128C3B2 for ; Mon, 7 Jul 2008 18:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQCrEuflt2jI for ; Mon, 7 Jul 2008 18:48:09 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id B3E3A28C3B7 for ; Mon, 7 Jul 2008 18:48:09 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B931A439FE3 for ; Mon, 7 Jul 2008 18:48:17 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 6BD7B4400CC for ; Mon, 7 Jul 2008 18:48:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4397D34AC021 for ; Mon, 7 Jul 2008 18:48:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 7131534AC024 for ; Mon, 7 Jul 2008 18:48:07 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 18:48:07 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so2757377wfc.11 for ; Mon, 07 Jul 2008 18:48:07 -0700 (PDT) Received: by 10.142.179.12 with SMTP id b12mr1579354wff.282.1215481686708; Mon, 07 Jul 2008 18:48:06 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Mon, 7 Jul 2008 18:48:06 -0700 (PDT) Message-ID: Date: Mon, 7 Jul 2008 18:48:06 -0700 From: "Yong Zhang" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2060D18DF@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <4FF84B0BC277FF45AA27FE969DD956A2060D17DD@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D18DF@xmb-sjc-235.amer.cisco.com> Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 143: Data Transfer Request is too ambiguous 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 This is Ok for me, Did you fix the second issue: 2. Figure 10. It's WTP send EOF. Yong On Mon, Jul 7, 2008 at 2:36 PM, Pat Calhoun (pacalhou) wrote: > Thanks Yong. Are you OK with the proposal with the change you mentioned? > > PatC > > -----Original Message----- > From: Yong Zhang [mailto:yozhang@gmail.com] > Sent: Monday, July 07, 2008 1:17 PM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 143: Data Transfer Request is too ambiguous > > Data Length need to be 16 bits. (Data Transfer Data ME figure need to > be changed) > > ME len >= 5. > > Yong > > On Mon, Jul 7, 2008 at 12:13 PM, Pat Calhoun (pacalhou) > wrote: >> Thanks for the feedback. Yes, you caught two bugs. >> >> To address your open issue below, how about: >> >> 4.6.16. Data Transfer Data >> >> The Data Transfer Data message element is used by the WTP to provide >> information to the AC for debugging purposes. >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Data Type | Data Mode | Data Length | Data .... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Type: 16 for Data Transfer Data >> >> Length: >= 3 >> >> Data Type: An 8-bit value representing the transfer Data Type. > The >> following enumerated values are supported: >> >> 1 - Transfer data is included >> >> 2 - Last Transfer Data Block is included (EOF) >> >> 5 - An error occurred. Transfer is aborted >> >> Data Mode: An 8-bit value the type of information being >> transmitted. The following enumerated values are supported: >> >> 0 - Reserved >> >> 1 - WTP Crash Data >> >> 2 - WTP Memory Dump >> >> Data Length: Length of data field, with a maximum size of 65535. >> >> Data: Data being transferred from the WTP to the AC, whose type is >> identified via the Data Mode field. >> >> 4.6.17. Data Transfer Mode >> >> The Data Transfer Mode message element is used by the WTP to > indicate >> the type of data transfer information it is sending to the AC for >> debugging purposes. >> >> 0 >> 0 1 2 3 4 5 6 7 >> +-+-+-+-+-+-+-+-+ >> | Data Mode | >> +-+-+-+-+-+-+-+-+ >> >> Type: 17 for Data Transfer Mode >> >> Length: 1 >> >> Data Mode: An 8-bit value the type of information being requested. >> The following enumerated values are supported: >> >> 0 - Reserved >> >> 1 - WTP Crash Data >> >> 2 - WTP Memory Dump >> >> >> PatC >> -----Original Message----- >> From: Yong Zhang [mailto:yozhang@gmail.com] >> Sent: Monday, July 07, 2008 11:25 AM >> To: capwap@frascone.com >> Subject: Re: [Capwap] Issue 143: Data Transfer Request is too >> ambiguous >> >> There are two issues here: >> >> 1. 4.6.16. Data Transfer Data >> >> The Data Transfer Data message element is used by the WTP to provide > >> information to the AC for debugging purposes. >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Data Type | Data Length | Data .... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Data Length/Data bit fields are not correct in the above fig. >> >> 2. Figure 10. It's WTP send EOF. >> >> >> If the Data Transfer Mode/data are used in different messages, I think > >> it would be better to keep the mode info in the Data Transfer Data ME. >> It will be easier when you need to analyze the capwap messages. >> >> >> Yong >> >> ------------------------------ >> >> Message: 7 >> Date: Mon, 7 Jul 2008 10:57:08 -0700 >> From: "Pat Calhoun (pacalhou)" >> Subject: [Capwap] Issue 143: Data Transfer Request is too ambiguous >> To: >> Message-ID: >> >> <4FF84B0BC277FF45AA27FE969DD956A2060D174C@xmb-sjc-235.amer.cisco.com> >> Content-Type: text/plain; charset="us-ascii" >> >> All, >> >> Yong has raised a series of questions about the use of the Data >> Transfer Request/Response which are pointing out that the text is >> simply too ambiguous. I looked at the text again, and I agree that it > needs work. >> Some time ago we had agreed to clean up the Image Transfer exchanges >> to allow the AC to know the size of the data being transfered, etc. We > >> also agreed to include figures to help provide more clarity on how the > >> exchange occurred. >> >> Clearly, we need something similar for the Data Transfer section. >> Furthermore, I have found a bug that the Data Transfer Request >> currently states that it cannot be sent by the AC, which is incorrect. > >> The AC is supposed to send this in order to request the information to > begin with. >> >> >> Please see the following proposed text to handle this issue. Note that > >> this will "sort-of" break compatibility with -10 but I doubt we will >> see any issues because -10 had no way for the AC to initiate the > request. >> >> >> 2.3.1. CAPWAP Protocol State Transitions [...] Run to Run (q): This > >> is the normal state of operation. >> >> WTP: This is the WTP's normal state of operation. There are many >> events that result this state transition: >> [...] >> Data Transfer: The WTP sends a Data Transfer Request or Data >> Transfer Response message to the AC (see Section 9.6). The >> WTP receives a Data Transfer Request or Data Transfer >> Response message from the AC (see Section 9.6). Upon >> receipt of a Data Transfer Request, the WTP transmits a Data >> Transfer Response to the AC. >> [...] >> AC: This is the AC's normal state of operation: >> [...] >> Data Transfer: The AC sends a Data Transfer Request or Data >> Transfer Response message to the WTP (see Section 9.6). The >> AC receives a Data Transfer Request or Data Transfer >> Response message from the WTP (see Section 9.6). Upon >> receipt of a Data Transfer Request, the AC transmits a Data >> Transfer Response to the WTP. >> 4.6.16. Data Transfer Data >> >> The Data Transfer Data message element is used by the WTP to provide > >> information to the AC for debugging purposes. >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Data Type | Data Length | Data .... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Type: 16 for Data Transfer Data >> >> Length: >= 3 >> >> Data Type: An 8-bit value representing the transfer Data Type. The >> following enumerated values are supported: >> >> 1 - Transfer data is included >> >> 2 - Last Transfer Data Block is included (EOF) >> >> 5 - An error occurred. Transfer is aborted >> >> Data Length: Length of data field, with a maximum size of 65535. >> >> Data: Debug information. >> >> >> 9.6. Data Transfer >> >> This section describes the data transfer procedures used by the >> CAPWAP protocol. The data transfer mechanism is used to upload >> information available at the WTP to the AC, such as crash or debug >> information. The data transfer messages can only be exchanged while >> in the Run state. >> >> Figure 10 provides an example of an AC that requests that the WTP >> transfer its latest crash file. Once the WTP acknowledges that it >> has information to send, via the Data Transfer Response, it transmits > >> its own Data Transfer Request. Upon receipt, the AC responds with a >> Data Transfer Response, and the exchange continues until the WTP >> transmits a Data Transfer Data message element that indicates an End >> of File (EOF). >> >> WTP AC >> >> Data Transfer Request (Data Transfer Mode = Crash Data) >> <------------------------------------------------------ >> >> Data Transfer Response (Result Code = Success) >> --------------------------------------------------------> >> >> Data Transfer Request (Data Transfer Data = Data) >> --------------------------------------------------------> >> >> Data Transfer Response (Result Code = Success) >> <------------------------------------------------------ >> >> ..... >> >> Data Transfer Request (Data Transfer Data = EOF) >> <------------------------------------------------------ >> >> Data Transfer Response (Result Code = Success) >> --------------------------------------------------------> >> >> >> Figure 10: WTP Data Transfer Case 1 >> >> Figure 11 provides an example of an AC that requests that the WTP >> transfer its latest crash file. However, in this example, the WTP >> does not have any crash information to send, and therefore sends a >> Data Transfer Response with a Result Code indicating the error. >> >> WTP AC >> >> Data Transfer Request (Data Transfer Mode = Crash Data) >> <------------------------------------------------------ >> >> Data Transfer Response (Result Code = Data Transfer >> Error (No Information to Transfer)) >> --------------------------------------------------------> >> >> >> Figure 11: WTP Data Transfer Case 2 >> >> 9.6.1. Data Transfer Request >> >> The Data Transfer Request message is used to deliver debug >> information from the WTP to the AC. >> >> The Data Transfer Request messages can be sent either by the AC or >> the WTP. When sent by the AC, it is used to request that data be >> transmitted from the WTP to the AC, and includes the Data Transfer >> Mode message element, which specifies the information desired by the >> AC. The Data Transfer Request is sent by the WTP in order to >> transfer actual data to the AC, through the Data Transfer Data >> message element. >> >> Given that the CAPWAP protocol minimizes the need for WTPs to be >> directly managed, the Data Transfer Request is an important >> troubleshooting tool used by the AC to retrieve information that may >> be available on the WTP. For instance, some WTPs implementations may > >> store crash information to help manufacturers identify software >> faults. The Data Transfer Request message can be used to send such >> information from the WTP to the AC. Another possible use would be to > >> allow a remote debugger function in the WTP to use the Data Transfer >> Request message to send console output to the AC for debugging >> purposes. >> >> When the WTP or AC receives a Data Transfer Request message it >> responds to the WTP with a Data Transfer Response message. The AC >> MAY log the information received through the Data Transfer Data >> message element. >> >> The Data Transfer Request message is sent by the WTP or AC when in >> the Run State. >> >> When sent by the AC, the Data Transfer Request message MUST contain >> the following message elements: >> >> o Data Transfer Mode, see Section 4.6.17 >> >> When sent by the WTP, the Data Transfer Request message MUST contain > >> the following message elements: >> >> o Data Transfer Data, see Section 4.6.16 >> >> Regardless of whether the Data Transfer Request is sent by the AC or > >> WTP, the following message elements MAY be included in the Data >> Transfer Request message: >> >> o Vendor Specific Payload, see Section 4.6.39 >> >> 9.6.2. Data Transfer Response >> >> The Data Transfer Response message acknowledges the Data Transfer >> Request message. >> >> A Data Transfer Response message is sent in response to a received >> Data Transfer Request message. Its purpose is to acknowledge receipt > >> of the Data Transfer Request message. When sent by the WTP, the >> Result Code message element is used to indicate whether the data >> transfer requested by the AC can be completed. When sent by the AC, >> the Result Code message element is used to indicate receipt of the >> data transfered in the Data Transfer Request message. >> >> The Data Transfer Response message is sent by the WTP or AC when in >> the Run State. >> >> The following message element MUST be included in the Data Transfer >> Response message. >> >> o Result Code, see Section 4.6.35 >> >> The following message elements MAY be included in the Data Transfer >> Response message: >> >> o Vendor Specific Payload, see Section 4.6.39 >> >> Upon receipt of a Data Transfer Response message, the WTP transmits >> more information, if more information is available. >> >> >> PatC >> >> >> ------------------------------ >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/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 Jul 7 18:48:59 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA67728C3B7 for ; Mon, 7 Jul 2008 18:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nejLnnOeVVtq for ; Mon, 7 Jul 2008 18:48:58 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 536FF28C3B2 for ; Mon, 7 Jul 2008 18:48:58 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 64A6B439FC8 for ; Mon, 7 Jul 2008 18:49:06 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 649C44400CC for ; Mon, 7 Jul 2008 18:48:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3545434AC024 for ; Mon, 7 Jul 2008 18:48:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C9C9D34AC021 for ; Mon, 7 Jul 2008 18:48:55 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.153]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 18:48:55 -0700 (PDT) Received: by yw-out-1718.google.com with SMTP id 6so1057641ywa.80 for ; Mon, 07 Jul 2008 18:48:55 -0700 (PDT) Received: by 10.142.222.21 with SMTP id u21mr1580511wfg.323.1215481734640; Mon, 07 Jul 2008 18:48:54 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Mon, 7 Jul 2008 18:48:54 -0700 (PDT) Message-ID: Date: Mon, 7 Jul 2008 18:48:54 -0700 From: "Yong Zhang" To: "Pat Calhoun (pacalhou)" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <4FF84B0BC277FF45AA27FE969DD956A2060D131F@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D15BC@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D18D7@xmb-sjc-235.amer.cisco.com> Cc: capwap@frascone.com Subject: Re: [Capwap] FSM issues 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 This is OK for me. Yong > > On Mon, Jul 7, 2008 at 2:32 PM, Pat Calhoun (pacalhou) > wrote: >> Ah, I see. Yes, this does need to be mentioned, thanks for pointing that >> out. The issue being raised here is that the Echo Request is used by a >> WTP to keep its session alive with the AC. However, if the AC doesn't >> receive an Echo Request in a certain amount of time, it needs to >> consider the WTP dead (this text is already covered in section 7.2). >> >> Note that this does not break interoperability with -10. The older spec >> was ambiguous in how the AC would timeout a WTP, and I suspect that most >> people at least implemented what's being described below. The change is >> specifically around being clear when the EchoInterval is set/reset in >> the actual FSM. It was mentioned already in the description of the Echo >> Request and Echo Response messages, but it does need to also be >> mentioned in the FSM. >> >> The only new change is the mention of the EchoInterval timer being reset >> on the WTP when it transmits a request to the AC while in the Run state. >> Similarly, the AC resets its own EchoInterval timer when it receives a >> request from the WTP. This language is necessary in order to fulfill the >> language from section 4.5: >> >> >> 4.5. 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 Control Channel Management Echo Request and Echo >> Response messages provide an explicit keep-alive mechanism when other >> CAPWAP control messages are not exchanged. >> >> >> Here is the new proposed text. Note that the text in section 4.6.14 is >> only the mention of how the EchoInterval is set on the AC. No other >> changes are made: >> >> >> Run to Run (q): This is the normal state of operation. >> >> WTP: This is the WTP's normal state of operation. The WTP resets >> its EchoInterval timer whenever it transmits a request to the >> AC. There are many events that result this state transition: >> [...] >> Echo Request: The WTP sends an Echo Request message >> (Section 7.1) or receives the corresponding Echo Response >> message, (see Section 7.2) from the AC. When the WTP >> receives the Echo Response, it resets its EchoInterval timer >> (see Section 4.7.7). >> [...] >> AC: This is the AC's normal state of operation. Note that the >> receipt of any Request from the WTP causes the AC to reset its >> EchoInterval timer (see Section 4.7.7). >> [...] >> Echo Request: The AC receives an Echo Request message (see >> Section 7.1), to which it MUST respond with an Echo Response >> message(see Section 7.2). >> >> Run to DTLS Teardown (p): This state transition occurs when an error >> has occurred in the DTLS stack, causing the DTLS session to be >> torn down. >> [...] >> AC: The AC enters this state when it receives one of the >> following DTLS notifications: DTLSAborted, >> DTLSReassemblyFailure or DTLSPeerDisconnect (see >> Section 2.3.2.2). The WTP MAY tear down the DTLS session if it >> receives frequent DTLSDecapFailure notifications. The AC >> transitions to this state if the underlying reliable >> transport's RetransmitCount counter has reached the >> MaxRetransmit variable (see Section 4.7). This state >> transition also occurs when the AC's EchoInterval timer expires >> (see Section 4.7.7). >> >> 4.6.14. CAPWAP Timers >> >> The CAPWAP Timers message element is used by an AC to configure >> CAPWAP timers on a WTP. >> >> 0 1 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Discovery | Echo Request | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> [...] >> Echo Request: The number of seconds between WTP Echo Request CAPWAP >> messages. This value is used to configure the EchoInterval timer >> (see Section 4.7.7). The AC sets its EchoInterval timer to this >> value, plus the maximum retransmission time as described in >> Section 4.5.3. >> >> >> PatC >> >> -----Original Message----- >> From: Yong Zhang [mailto:yozhang@gmail.com] >> Sent: Monday, July 07, 2008 9:49 AM >> To: Pat Calhoun (pacalhou) >> Cc: capwap@frascone.com >> Subject: Re: [Capwap] FSM issues >> >> I want to say for 5 is that: >> >> Only WTP sends echo request. So if the WTP is dead, the AC will not be >> able to receive the echo req, and this will trigger a failure event in >> AC side after some time. We need to add this event to FSM. >> >> Since AC does not send the req, " the retransmission, and subsequent >> timeout, ..." will not be used. >> >> Yong >> >> On Mon, Jul 7, 2008 at 4:21 AM, Pat Calhoun (pacalhou) >> wrote: >>> 4. Run to Run. I now understand the point you are trying to make. The >>> text for Clear Configuration Request/Response is not consistent with >>> the other commands in this section. I am proposing the following >>> changes, which does not change any behavior, but only creates more >>> consistency in the text: >>> >>> >>> Run to Run (q): This is the normal state of operation. >>> >>> WTP: This is the WTP's normal state of operation. There are >> many >>> events that result this state transition: >>> [...] >>> Clear Config Request: The WTP receives a Clear Configuration >>> Request message (see Section 8.8) and MUST generate a >>> corresponding Clear Configuration Response message (see >>> Section 8.9). The WTP MUST reset its configuration back to >>> manufacturer defaults. >>> [...] >>> AC: This is the AC's normal state of operation: >>> [...] >>> Clear Config Response: The AC sends a Clear Configuration >>> Request message (see Section 8.8) to the WTP to clear its >>> configuration. The AC receives a Clear Configuration >>> Response message from the WTP (see Section 8.9). >>> >>> >>> 5. Unfortunately, I'm still not understanding the issue you are trying >> >>> to raise. I am not claiming that the AC sends echo requests, I am >>> simply stating that requests (in general) can be transmitted by either >> >>> the WTP or the AC, while certain requests may have restrictions which >>> are clearly documented in the spec. So regardless of whether a request >> >>> is an echo request, or any other request, the retransmission, and >>> subsequent timeout, is the same. Therefore there is no need to add a >>> specific clause for echo requests timing out. >>> >>> PatC >>> -----Original Message----- >>> From: Yong Zhang [mailto:yozhang@gmail.com] >>> Sent: Thursday, July 03, 2008 1:41 PM >>> To: Pat Calhoun (pacalhou) >>> Cc: capwap@frascone.com >>> Subject: Re: [Capwap] FSM issues >>> >>>>> 4. Run to Run (q): AC >>>>> >>>>> Clear Config Response: The AC receives a Clear Configuration >>>>> Response message from the WTP (see Section 8.9). >>>>> >>>>> Need to add Clear Configuration REQ send. >>>> I'm not sure that I understand what you are saying. This event occurs >> >>>> when the response is received. The Request was sent some time ago, >>>> hence why the response was received. The receive of the Clear Config >>>> Request is handled in the WTP section, and is present already. >>> >>> Refer to other messages description in AC RUN state: Ac need to send >>> out the REQ, and AC need to receive RESP. >>> Just WTP clear Config Response also has the problem. >>> >>> >>>>> 5. Run to DTLS Teardown (p) maybe need to add echo failure case. >>>>> >>>>> "transitions to this state if the underlying reliable >>>>> transport's RetransmitCount counter has reached the >>>>> MaxRetransmit variable (see Section 4.7)." >>>>> >>>>> This can cover WTP, but not AC. >>>> The echo would cause a retransmission timeout, which makes use of the >> >>>> RetransmitCount counter. I guess I'm not sure that I understand the >>>> issue you are trying to raise. Both the WTP and the AC can transmit >>>> requests, so it is possible that either side timeouts, forcing this >>>> state transition. >>>> >>> >>> I only see the WTP sends REQ, and AC recvs RESP. Where is it said >>> that AC also sends ECHO REQ? >>> >>> >>> On Thu, Jul 3, 2008 at 1:22 PM, Pat Calhoun (pacalhou) >>> wrote: >>>> I have created issue 139 to track these issues. >>>> >>>>> 1. waitDTLS is not started in the 2.3.1 CAPWAP Proto State >>>> Transitions, although it is said in CAPWAP/DTLS interface >>>>> chapter. >>>> Yes, you are correct. The description for the StartDTLS command is >>>> clear that the WaitDTLS timer needs to be started, but it would be >>>> worth including this in the state transition description, as all of >>>> the other timers are also included in that section. >>>> >>>> >>>> Idle to DTLS Setup (3): This transition occurs to establish a >>> secure >>>> DTLS session with the peer. >>>> >>>> WTP: The WTP initiates this transition by invoking the >> DTLSStart >>>> command(see Section 2.3.2.1), which starts the DTLS session >>>> establishment with the chosen AC and the WaitDTLS timer is >>>> started (see Section 4.7). When the discovery phase is >>>> bypassed, it is assumed the WTP has locally configured ACs. >>>> >>>> >>>>> 2. Join REQ need to be send at here. >>>>> >>>>> DTLS Connect to Join (d): This transition occurs when the DTLS >>>>> Session is successfully established. >>>>> >>>>> WTP: This state transition occurs when the WTP receives the >>>>> DTLSEstablished notification (see Section 2.3.2.2), >>> indicating >>>>> that the DTLS session was successfully established. When >>> this >>>>> notification is received, the FailedDTLSSessionCount counter >>>> is >>>>> set to zero. >>>> Yes, this was a strange omission - an obvious thing to do, but it >>>> needs to be very clear. >>>> >>>> >>>> DTLS Connect to Join (d): This transition occurs when the DTLS >>>> Session is successfully established. >>>> >>>> WTP: This state transition occurs when the WTP receives the >>>> DTLSEstablished notification (see Section 2.3.2.2), >> indicating >>>> that the DTLS session was successfully established. When >> this >>>> notification is received, the FailedDTLSSessionCount counter >>> is >>>> set to zero. The WTP enters the Join state by transmiting >> the >>>> Join Request to the AC. >>>> >>>> >>>>> 3. >>>>> Data Check to DTLS Teardown (n): This transition occurs when the >> WTP >>>>> does not complete the Data Check exchange. >>>>> >>>>> WTP: This state transition occurs if the WTP does not receive >>>> the >>>>> Change State Event Response message before a CAPWAP >>>>> transmission timeout occurs. >>>>> >>>>> Does the above need to be change to something like >>>> RetransmitCount >>>>> counter has reached the MaxRetransmit variable? Since we do not >>>>> use >>>> transmission timeout timer. >>>> Yes, good point. I am including the same text we have in other state >>>> transitions. >>>> >>>> >>>> Data Check to DTLS Teardown (n): This transition occurs when the >>> WTP >>>> does not complete the Data Check exchange. >>>> >>>> WTP: This state transition occurs if the WTP does not receive >>> the >>>> Change State Event Response message before a CAPWAP >>>> retransmission timeout occurs. The WTP also transitions to >>>> this state if the underlying reliable transport's >>>> RetransmitCount counter has reached the MaxRetransmit >> variable >>>> (see Section 4.7). >>>> >>>> >>>>> 4. Run to Run (q): AC >>>>> >>>>> Clear Config Response: The AC receives a Clear Configuration >>>>> Response message from the WTP (see Section 8.9). >>>>> >>>>> Need to add Clear Configuration REQ send. >>>> I'm not sure that I understand what you are saying. This event occurs >> >>>> when the response is received. The Request was sent some time ago, >>>> hence why the response was received. The receive of the Clear Config >>>> Request is handled in the WTP section, and is present already. >>>> >>>>> 5. Run to DTLS Teardown (p) maybe need to add echo failure case. >>>>> >>>>> "transitions to this state if the underlying reliable >>>>> transport's RetransmitCount counter has reached the >>>>> MaxRetransmit variable (see Section 4.7)." >>>>> >>>>> This can cover WTP, but not AC. >>>> The echo would cause a retransmission timeout, which makes use of the >> >>>> RetransmitCount counter. I guess I'm not sure that I understand the >>>> issue you are trying to raise. Both the WTP and the AC can transmit >>>> requests, so it is possible that either side timeouts, forcing this >>>> state transition. >>>> >>>> PatC >>>> >>>> -----Original Message----- >>>> From: Yong Zhang [mailto:yozhang@gmail.com] >>>> Sent: Thursday, July 03, 2008 11:48 AM >>>> To: capwap@frascone.com >>>> Subject: [Capwap] FSM issues >>>> >>>> 1. waitDTLS is not started in the 2.3.1 CAPWAP Proto State >>>> Transitions, although it is said in CAPWAP/DTLS interface chapter. >>>> >>>> 2. Join REQ need to be send at here. >>>> >>>> DTLS Connect to Join (d): This transition occurs when the DTLS >>>> Session is successfully established. >>>> >>>> WTP: This state transition occurs when the WTP receives the >>>> DTLSEstablished notification (see Section 2.3.2.2), >> indicating >>>> that the DTLS session was successfully established. When >> this >>>> notification is received, the FailedDTLSSessionCount counter >>> is >>>> set to zero. >>>> >>>> 3. >>>> Data Check to DTLS Teardown (n): This transition occurs when the WTP >>>> does not complete the Data Check exchange. >>>> >>>> WTP: This state transition occurs if the WTP does not receive >>> the >>>> Change State Event Response message before a CAPWAP >>>> transmission timeout occurs. >>>> >>>> Does the above need to be change to something like >>>> RetransmitCount >>> >>>> counter has reached the MaxRetransmit variable? Since we do not use >>>> transmission timeout timer. >>>> >>>> 4. Run to Run (q): AC >>>> >>>> Clear Config Response: The AC receives a Clear Configuration >>>> Response message from the WTP (see Section 8.9). >>>> >>>> Need to add Clear Configuration REQ send. >>>> >>>> 5. Run to DTLS Teardown (p) maybe need to add echo failure case. >>>> >>>> "transitions to this state if the underlying reliable >>>> transport's RetransmitCount counter has reached the >>>> MaxRetransmit variable (see Section 4.7)." >>>> >>>> This can cover WTP, but not AC. >>>> >>>> >>>> Yong >>>> _________________________________________________________________ >>>> To unsubscribe or modify your subscription options, please visit: >>>> http://lists.frascone.com/mailman/listinfo/capwap >>>> >>>> Archives: http://lists.frascone.com/pipermail/capwap >>>> >>> >> > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 7 18:51:08 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E858C28C392 for ; Mon, 7 Jul 2008 18:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQ7RbAmlGPMR for ; Mon, 7 Jul 2008 18:51:07 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id F065328C3B2 for ; Mon, 7 Jul 2008 18:50:47 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1AA84439FCA for ; Mon, 7 Jul 2008 18:50:56 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id D34CB4400CC for ; Mon, 7 Jul 2008 18:50:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 9828534AC025 for ; Mon, 7 Jul 2008 18:50:45 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 71B8034AC021 for ; Mon, 7 Jul 2008 18:50:43 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 18:50:43 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so2758177wfc.11 for ; Mon, 07 Jul 2008 18:50:43 -0700 (PDT) Received: by 10.142.229.5 with SMTP id b5mr1585040wfh.50.1215481842457; Mon, 07 Jul 2008 18:50:42 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Mon, 7 Jul 2008 18:50:42 -0700 (PDT) Message-ID: Date: Mon, 7 Jul 2008 18:50:42 -0700 From: "Yong Zhang" To: "Pat Calhoun (pacalhou)" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <4FF84B0BC277FF45AA27FE969DD956A205F5CDE6@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A205FDD776@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D15C0@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D18EF@xmb-sjc-235.amer.cisco.com> Cc: capwap@frascone.com Subject: Re: [Capwap] New Issue 106: WaitJoin may be 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 On Mon, Jul 7, 2008 at 6:50 PM, Yong Zhang wrote: > This is OK for me. > > Yong > > On Mon, Jul 7, 2008 at 2:47 PM, Pat Calhoun (pacalhou) > wrote: >> Got it - and while this information is available in other places in the >> spec, it needs to be clear in the FSM state transition descriptions as >> well. The change below is to add specific text about the state >> transitions occuring when the WaitDTLS timer expires. The last change >> below mentions that the WaitDTLS timer is stopped when the 'DTLS Connect >> to Join' state transition occurs. This is not new, as it is mentioned in >> the Join Request in section 6.1, but having it in the FSM will help >> implementors by not needing to find this out only when reading later in >> the spec. >> >> >> 2.3.1. CAPWAP Protocol State Transitions >> [...] >> DTLS Setup to Idle ($): This transition occurs when the DTLS >> connection setup fails. >> >> WTP: The WTP initiates this state transition when it receives a >> DTLSEstablishFail notification from DTLS (see Section 2.3.2.2), >> and the FailedDTLSSessionCount or the FailedDTLSAuthFailCount >> counter have not reached the value of the >> MaxFailedDTLSSessionRetry variable (see Section 4.8). This >> error notification aborts the secure DTLS session >> establishment. When this notification is received, the >> FailedDTLSSessionCount counter is incremented. This state >> transition also occurs if the WaitDTLS timer has expired. >> [...] >> Authorize to DTLS Teardown (b): This transition occurs to notify the >> DTLS stack that the session should be aborted. >> >> WTP: This state transition occurs when the WTP was unable to >> authorize the AC, using the AC credentials. The WTP then >> aborts the DTLS session by invoking the DTLSAbortSession >> command (see Section 2.3.2.1). This state transition also >> occurs if the WaitDTLS timer has expired. >> >> AC: This state transition occurs when the AC was unable to >> authorize the WTP, using the WTP credentials. The AC then >> aborts the DTLS session by invoking the DTLSAbortSession >> command (see Section 2.3.2.1). This state transition also >> occurs if the WaitDTLS timer has expired. >> [...] >> DTLS Connect to DTLS Teardown (c): This transition occurs when the >> DTLS Session failed to be established. >> >> WTP: This state transition occurs when the WTP receives either a >> DTLSAborted or DTLSAuthenticateFail notification (see >> Section 2.3.2.2), indicating that the DTLS session was not >> successfully established. When this transition occurs due to >> the DTLSAuthenticateFail notification, the >> FailedDTLSAuthFailCount is incremented, otherwise the >> FailedDTLSSessionCount counter is incremented. This state >> transition also occurs if the WaitDTLS timer has expired. >> >> AC: This state transition occurs when the AC receives either a >> DTLSAborted or DTLSAuthenticateFail notification (see >> Section 2.3.2.2), indicating that the DTLS session was not >> successfully established, and both of the >> FailedDTLSAuthFailCount and FailedDTLSSessionCount counters >> have not reached the value of the MaxFailedDTLSSessionRetry >> variable (see Section 4.8). This state transition also occurs >> if the WaitDTLS timer has expired. >> [...] >> DTLS Connect to Join (d): This transition occurs when the DTLS >> Session is successfully established. >> >> WTP: This state transition occurs when the WTP receives the >> DTLSEstablished notification (see Section 2.3.2.2), indicating >> that the DTLS session was successfully established. When this >> notification is received, the FailedDTLSSessionCount counter is >> set to zero. The WTP enters the Join state by transmiting the >> Join Request to the AC. The WTP stops the WaitDTLS timer. >> >> AC: This state transition occurs when the AC receives the >> DTLSEstablished notification (see Section 2.3.2.2), indicating >> that the DTLS session was successfully established. When this >> notification is received, the FailedDTLSSessionCount counter is >> set to zero. The AC stops the WaitDTLS timer. >> >> >> PatC >> -----Original Message----- >> From: Yong Zhang [mailto:yozhang@gmail.com] >> Sent: Monday, July 07, 2008 9:53 AM >> To: Pat Calhoun (pacalhou) >> Cc: capwap@frascone.com >> Subject: Re: New Issue 106: WaitJoin may be unnecessary >> >> This is OK. But I found another issue. We did not process the WaitDTLS >> timer expire event in the several DTLS states. >> >> Yong >> >> On Mon, Jul 7, 2008 at 4:27 AM, Pat Calhoun (pacalhou) >> wrote: >>> All, >>> >>> Here is the actual text handling this change, which I have reviewed >>> with Yong and he has responded that he is OK with the change. The AC >>> in the spec was using the WaitJoin timer, so I had to make a couple of >> >>> changes to two state transisions to make sure that the AC was making >>> proper use of the WaitDTLS timer: >>> >>> >>> Idle to DTLS Setup (3): This transition occurs to establish a >> secure >>> DTLS session with the peer. >>> >>> WTP: The WTP initiates this transition by invoking the DTLSStart >>> command(see Section 2.3.2.1), which starts the DTLS session >>> establishment with the chosen AC and the WaitDTLS timer is >>> started (see Section 4.7). When the discovery phase is >>> bypassed, it is assumed the WTP has locally configured ACs. >>> >>> AC: Upon entering the Idle state from the Start state, the newly >>> created Listener thread automatically transitions to the DTLS >>> Setup and invokes the DTLSListen command (see Section >> 2.3.2.1), >>> and the WaitDTLS timer is started (see Section 4.7). <===== >>> THE TIMER IS STARTED >>> >>> >>> Join to DTLS Teardown (e): This transition occurs when the join >>> process failed. >>> >>> WTP: This state transition occurs when the WTP receives a Join >>> Response message with a Result Code message element containing >>> an error, if the Image Identifier provided by the AC in the >>> Join Response message differs from the WTP's currently running >>> firmware version and the WTP has the requested image in its >>> non-volatile memory, or if the WaitDTLS timer expires. This >>> causes the WTP to initiate the DTLSShutdown command (see >>> Section 2.3.2.1). This transition also occurs if the WTP >>> receives one of the following DTLS notifications: DTLSAborted, >>> DTLSReassemblyFailure or DTLSPeerDisconnect. >>> >>> AC: This state transition occurs either if the WaitDTLS timer >>> <=== THE TIMER EXPIRES >>> expires or if the AC transmits a Join Response message with a >>> Result Code message element containing an error. This causes >>> the AC to initiate the DTLSShutdown command (see >>> Section 2.3.2.1). This transition also occurs if the AC >>> receives one of the following DTLS notifications: DTLSAborted, >>> DTLSReassemblyFailure or DTLSPeerDisconnect. >>> >>> >>> PatC >>> -----Original Message----- >>> From: Yong Zhang [mailto:yozhang@gmail.com] >>> Sent: Tuesday, July 01, 2008 1:37 PM >>> To: Pat Calhoun (pacalhou) >>> Cc: capwap@frascone.com >>> Subject: Re: New Issue 106: WaitJoin may be unnecessary >>> >>> This change is OK for me. >>> >>> Yong >>> >>> On Thu, Jun 26, 2008 at 4:53 AM, Pat Calhoun (pacalhou) >>> wrote: >>>> I believe you may be correct that there is a technical issue. >>>> >>>> Originally, the WaitJoin was used to timeout if the WTP did not sent >>>> the Join Request, or the AC did not send the Join Response. However, >>>> when DTLS was introduced, we started to rely on the WaitDTLS timer. >>>> It >>> >>>> seems like we've started to rely much more on the WaitDTLS timer in >>>> the latter drafts, to the point where I believe that we could simply >>>> remove the WaitJoin timer and have little impact to the state >> machine. >>>> >>>> From what I can tell, the "Join to DTLS Teardown (e)" state >>>> transition >>> >>>> currently triggers if the WaitJoin timer expires, and we would have >>>> to >>> >>>> change this to WaitDTLS instead. Further, the "DTLS Connect to Join >>> (d)" >>>> state transition would simply need to have its reference to WaitJoin >>>> removed. >>>> >>>> So since it appears as if the WaitDTLS timers are initialized >>>> properly, the timeout triggers are properly defined, and it is well >>>> specified in its handling during the Join Request/Response in section >>>> 6.1 and 6.2, this change would have mimimal impact. >>>> >>>> Thoughts? >>>> >>>> PatC >>>> >>>> -----Original Message----- >>>> From: Yong Zhang [mailto:yozhang@gmail.com] >>>> Sent: Friday, June 20, 2008 11:19 AM >>>> To: Pat Calhoun (pacalhou) >>>> Cc: capwap@frascone.com >>>> Subject: Re: [Capwap] WaitDTLS/WaitJoin timers >>>> indraft-ietf-capwap-protocol-specification-10.txt >>>> >>>> This info is clear. But in the spec., the WaitDTLS covers the >>> WaitJoin. >>>> WairDTLS timer is not cleared after the DTLS session is esatblished, >>>> but it is only cleared after the Join REQ/RESP are received. (6.1/2 >>>> describes this). >>>> >>>> Thanks! >>>> >>>> Yong >>>> >>>> On Fri, Jun 20, 2008 at 10:55 AM, Pat Calhoun (pacalhou) >>>> wrote: >>>>> The intent for both timers is: >>>>> >>>>> WaitDTLS: This timer is used to make sure that the DTLS session is >>>>> established within the required timeframe. If the DTLS session isn't >> >>>>> setup, perhaps because either party is not responding, then the >>>>> timer >>> >>>>> will trigger and the state will change. >>>>> >>>>> WaitJoin: Once the DTLS session has been established, we need to >>>>> protect against a WTP that opts to NOT send a Join Request. So in >>>>> this >>>> >>>>> instance, the WaitJoin would trigger, and the state would once more >>>> change. >>>>> >>>>> PatC >>>>> >>>>> -----Original Message----- >>>>> From: Yong Zhang [mailto:yozhang@gmail.com] >>>>> Sent: Friday, June 20, 2008 9:54 AM >>>>> To: capwap@frascone.com >>>>> Subject: [Capwap] WaitDTLS/WaitJoin timers >>>>> indraft-ietf-capwap-protocol-specification-10.txt >>>>> >>>>> WaitDTLS by its name should be DTLS session setup related, but this >>>>> spec. (6.1/2) requires it deactivated after the Join Req/Resp are >>>>> received. >>>>> >>>>> WaitJoin seems no use in this case?? >>>>> >>>>> Also the WaitDTLS timer is started earlier than WaitJoin timer, >>>>> however, the default value for these two timers (4.7.15/16) are all >>>>> 60s. if WaitJoin has some other use, it need to have a less value >>>>> than >>>> >>>>> WaitDTLS to work. >>>>> >>>>> Yong >>>>> _________________________________________________________________ >>>>> To unsubscribe or modify your subscription options, please visit: >>>>> http://lists.frascone.com/mailman/listinfo/capwap >>>>> >>>>> Archives: http://lists.frascone.com/pipermail/capwap >>>>> >>>> >>> >> > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 7 18:53:48 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94D4028C3B7 for ; Mon, 7 Jul 2008 18:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMCatqjKW2FN for ; Mon, 7 Jul 2008 18:53:47 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 923D128C3BF for ; Mon, 7 Jul 2008 18:53:47 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A11CE439FCA for ; Mon, 7 Jul 2008 18:53:55 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 8C3D84400CC for ; Mon, 7 Jul 2008 18:53:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5BA2C34AC02E for ; Mon, 7 Jul 2008 18:53:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id BB9D634AC019 for ; Mon, 7 Jul 2008 18:53:45 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 7 Jul 2008 18:53:45 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so2759038wfc.11 for ; Mon, 07 Jul 2008 18:53:45 -0700 (PDT) Received: by 10.142.246.19 with SMTP id t19mr576795wfh.221.1215482025294; Mon, 07 Jul 2008 18:53:45 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Mon, 7 Jul 2008 18:53:45 -0700 (PDT) Message-ID: Date: Mon, 7 Jul 2008 18:53:45 -0700 From: "Yong Zhang" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2060D1930@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <4FF84B0BC277FF45AA27FE969DD956A2060D1930@xmb-sjc-235.amer.cisco.com> Cc: capwap@frascone.com Subject: Re: [Capwap] 802.11 binding doc. issues 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 > > 6.22 > > "tag packets" is bit value? Can I set the tag the packet with both 1p > and DSCP? If I can, we need to add a value 3. > > Immediately following the above header is the following data > structure. This data structure will be repeated five times; once > for every QoS profile. The order of the QoS profiles are Voice, > Video, Best Effort and Background. > > Here should be "four times". > > Are the above mandatory? If they are, the ME len is ( 2 + 8 * 4) = 34. Correct - and no, only one or the other is possible at this point. Can you tell me what prevent the taging of both 1p and dscp? > > > 7.4. IEEE80211OFDMControl > > The WTP per radio MAC Operation configuration, defined in > Section 6.10. > > OFDM Not sure what your comment is. The title is OFDM, and the content is for MAC oper. Yong On Mon, Jul 7, 2008 at 3:28 PM, Pat Calhoun (pacalhou) wrote: > Created issue 145 to track this one. Responses below. > > PatC > > On Mon, Jul 7, 2008 at 10:30 AM, Yong Zhang wrote: >> 3.2. IEEE 802.11 WLAN Configuration Response >> >> Can we put MUST ME earlier than MAY ME for this message in the message > definition? > > Done. We now have consistency in ordering across both docs. > >> >> >> 6.1 >> >> The len should be >=52? >> >> 4 + 4 + 32 + 4 + 4 + 4 = 52 (assume SSID to be at least 1 byte) >> >> We have a key length field, however, >> >> "Key: A 32 byte Session Key to use to provide data privacy. " > > Yes, that is correct and I have fixed this. > >> >> 6.2 >> >> len = 5 > No, this is not correct. The Antenna Selection field will be of length > 'Antenna Count'. > >> >> 6.3 >> >> len = 8 > > Correct. > >> >> 6.6 >> >> This is used to include only one IE? If it is, should we remove the >> "..." in the figure? >> >> Also the len is bigger than 4. The minimal len of IE is 1 ? > > No, the ... Implies the length of the field is variable and may be > greater than 1. I think the length is fine. > >> >> 6.13 >> >> len >= 14 >> >> I am not sure the minimal size of supported rates. Here assume it is > one. > Correct. > >> >> 6.14 >> >> Here the 802.1p tag is defined with 2 bytes, but other places only use >> 1 byte. Only the 3 least >> significant bits are used. > We had agreed to leave this as is to minimize backward compatibility > issues, as per Margaret's request. > >> >> 6.15. >> >> I am not familiar with the keys. How do you get the length value? The >> minimal length of Key is 5 bytes? > Depends on the crypto used. The 802.11 spec is clear about this. > >> >> 6.16 >> >> len is 80 > Yes > >> >> >> 6.21 >> >> len is 40 >> >> same issue on Key as 6.1 > Correct > >> >> 6.22 >> >> "tag packets" is bit value? Can I set the tag the packet with both 1p >> and DSCP? If I can, we need to add a value 3. >> >> Immediately following the above header is the following data >> structure. This data structure will be repeated five times; once >> for every QoS profile. The order of the QoS profiles are Voice, >> Video, Best Effort and Background. >> >> Here should be "four times". >> >> Are the above mandatory? If they are, the ME len is ( 2 + 8 * 4) = 34. > Correct - and no, only one or the other is possible at this point. > >> >> >> 7.4. IEEE80211OFDMControl >> >> The WTP per radio MAC Operation configuration, defined in >> Section 6.10. >> >> OFDM > > Not sure what your comment is. > >> >> >> 8. Technology Specific Message Element Values >> >> I do not know which capwap ME is talking about at here. How to use the > >> defined value here? > > Interesting. This was an xml bug in my source code. I have fixed it and > the new text is: > > 8.1. WTP Descriptor Message Element, Encryption Capabilities Field: > > IEEE 802.11 uses the following values: > > 4 - Encrypt AES-CCMP 128: WTP supports AES-CCMP, as defined in > [IEEE.802-11.2007]. > > 5 - Encrypt TKIP-MIC: WTP supports TKIP and Michael, as defined in > [IEEE.802-11.2007] and [WPA], respectively. > > > 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 Jul 8 05:51:34 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B77E3A6A79 for ; Tue, 8 Jul 2008 05:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksSjaZ9V7A00 for ; Tue, 8 Jul 2008 05:51:32 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 512D33A67DD for ; Tue, 8 Jul 2008 05:51:32 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 776D4432133 for ; Tue, 8 Jul 2008 05:51:41 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id D90D744012C for ; Tue, 8 Jul 2008 05:51:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id ADD6434AC049 for ; Tue, 8 Jul 2008 05:51:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 62C3134AC058 for ; Tue, 8 Jul 2008 05:51:28 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 8 Jul 2008 05:51:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,323,1212364800"; d="scan'208";a="63580116" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 08 Jul 2008 12:51:24 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m68CpNJh028873; Tue, 8 Jul 2008 05:51:23 -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.13.8/8.13.8) with ESMTP id m68CpORn003706; Tue, 8 Jul 2008 12:51:24 GMT 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, 8 Jul 2008 05:51:23 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 05:51:21 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D1A99@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 143: Data Transfer Request is too ambiguous Thread-Index: AcjgnLXgzWkM4krlTPexzC3EWsMJOAAXJfkg References: <4FF84B0BC277FF45AA27FE969DD956A2060D17DD@xmb-sjc-235.amer.cisco.com><4FF84B0BC277FF45AA27FE969DD956A2060D18DF@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Yong Zhang" X-OriginalArrivalTime: 08 Jul 2008 12:51:23.0843 (UTC) FILETIME=[53DB7930:01C8E0F9] Authentication-Results: sj-dkim-4; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 143: Data Transfer Request is too ambiguous 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 Yes, I did. PatC -----Original Message----- From: Yong Zhang [mailto:yozhang@gmail.com] Sent: Monday, July 07, 2008 6:48 PM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 143: Data Transfer Request is too ambiguous This is Ok for me, Did you fix the second issue: 2. Figure 10. It's WTP send EOF. Yong On Mon, Jul 7, 2008 at 2:36 PM, Pat Calhoun (pacalhou) wrote: > Thanks Yong. Are you OK with the proposal with the change you mentioned? > > PatC > > -----Original Message----- > From: Yong Zhang [mailto:yozhang@gmail.com] > Sent: Monday, July 07, 2008 1:17 PM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 143: Data Transfer Request is too > ambiguous > > Data Length need to be 16 bits. (Data Transfer Data ME figure need to > be changed) > > ME len >= 5. > > Yong > > On Mon, Jul 7, 2008 at 12:13 PM, Pat Calhoun (pacalhou) > wrote: >> Thanks for the feedback. Yes, you caught two bugs. >> >> To address your open issue below, how about: >> >> 4.6.16. Data Transfer Data >> >> The Data Transfer Data message element is used by the WTP to provide >> information to the AC for debugging purposes. >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Data Type | Data Mode | Data Length | Data .... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Type: 16 for Data Transfer Data >> >> Length: >= 3 >> >> Data Type: An 8-bit value representing the transfer Data Type. > The >> following enumerated values are supported: >> >> 1 - Transfer data is included >> >> 2 - Last Transfer Data Block is included (EOF) >> >> 5 - An error occurred. Transfer is aborted >> >> Data Mode: An 8-bit value the type of information being >> transmitted. The following enumerated values are supported: >> >> 0 - Reserved >> >> 1 - WTP Crash Data >> >> 2 - WTP Memory Dump >> >> Data Length: Length of data field, with a maximum size of 65535. >> >> Data: Data being transferred from the WTP to the AC, whose type is >> identified via the Data Mode field. >> >> 4.6.17. Data Transfer Mode >> >> The Data Transfer Mode message element is used by the WTP to > indicate >> the type of data transfer information it is sending to the AC for >> debugging purposes. >> >> 0 >> 0 1 2 3 4 5 6 7 >> +-+-+-+-+-+-+-+-+ >> | Data Mode | >> +-+-+-+-+-+-+-+-+ >> >> Type: 17 for Data Transfer Mode >> >> Length: 1 >> >> Data Mode: An 8-bit value the type of information being requested. >> The following enumerated values are supported: >> >> 0 - Reserved >> >> 1 - WTP Crash Data >> >> 2 - WTP Memory Dump >> >> >> PatC >> -----Original Message----- >> From: Yong Zhang [mailto:yozhang@gmail.com] >> Sent: Monday, July 07, 2008 11:25 AM >> To: capwap@frascone.com >> Subject: Re: [Capwap] Issue 143: Data Transfer Request is too >> ambiguous >> >> There are two issues here: >> >> 1. 4.6.16. Data Transfer Data >> >> The Data Transfer Data message element is used by the WTP to provide > >> information to the AC for debugging purposes. >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Data Type | Data Length | Data .... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Data Length/Data bit fields are not correct in the above fig. >> >> 2. Figure 10. It's WTP send EOF. >> >> >> If the Data Transfer Mode/data are used in different messages, I >> think > >> it would be better to keep the mode info in the Data Transfer Data ME. >> It will be easier when you need to analyze the capwap messages. >> >> >> Yong >> >> ------------------------------ >> >> Message: 7 >> Date: Mon, 7 Jul 2008 10:57:08 -0700 >> From: "Pat Calhoun (pacalhou)" >> Subject: [Capwap] Issue 143: Data Transfer Request is too ambiguous >> To: >> Message-ID: >> >> <4FF84B0BC277FF45AA27FE969DD956A2060D174C@xmb-sjc-235.amer.cisco.com> >> Content-Type: text/plain; charset="us-ascii" >> >> All, >> >> Yong has raised a series of questions about the use of the Data >> Transfer Request/Response which are pointing out that the text is >> simply too ambiguous. I looked at the text again, and I agree that it > needs work. >> Some time ago we had agreed to clean up the Image Transfer exchanges >> to allow the AC to know the size of the data being transfered, etc. >> We > >> also agreed to include figures to help provide more clarity on how >> the > >> exchange occurred. >> >> Clearly, we need something similar for the Data Transfer section. >> Furthermore, I have found a bug that the Data Transfer Request >> currently states that it cannot be sent by the AC, which is incorrect. > >> The AC is supposed to send this in order to request the information >> to > begin with. >> >> >> Please see the following proposed text to handle this issue. Note >> that > >> this will "sort-of" break compatibility with -10 but I doubt we will >> see any issues because -10 had no way for the AC to initiate the > request. >> >> >> 2.3.1. CAPWAP Protocol State Transitions [...] Run to Run (q): >> This > >> is the normal state of operation. >> >> WTP: This is the WTP's normal state of operation. There are many >> events that result this state transition: >> [...] >> Data Transfer: The WTP sends a Data Transfer Request or Data >> Transfer Response message to the AC (see Section 9.6). The >> WTP receives a Data Transfer Request or Data Transfer >> Response message from the AC (see Section 9.6). Upon >> receipt of a Data Transfer Request, the WTP transmits a Data >> Transfer Response to the AC. >> [...] >> AC: This is the AC's normal state of operation: >> [...] >> Data Transfer: The AC sends a Data Transfer Request or Data >> Transfer Response message to the WTP (see Section 9.6). The >> AC receives a Data Transfer Request or Data Transfer >> Response message from the WTP (see Section 9.6). Upon >> receipt of a Data Transfer Request, the AC transmits a Data >> Transfer Response to the WTP. >> 4.6.16. Data Transfer Data >> >> The Data Transfer Data message element is used by the WTP to provide > >> information to the AC for debugging purposes. >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Data Type | Data Length | Data .... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Type: 16 for Data Transfer Data >> >> Length: >= 3 >> >> Data Type: An 8-bit value representing the transfer Data Type. The >> following enumerated values are supported: >> >> 1 - Transfer data is included >> >> 2 - Last Transfer Data Block is included (EOF) >> >> 5 - An error occurred. Transfer is aborted >> >> Data Length: Length of data field, with a maximum size of 65535. >> >> Data: Debug information. >> >> >> 9.6. Data Transfer >> >> This section describes the data transfer procedures used by the >> CAPWAP protocol. The data transfer mechanism is used to upload >> information available at the WTP to the AC, such as crash or debug >> information. The data transfer messages can only be exchanged while >> in the Run state. >> >> Figure 10 provides an example of an AC that requests that the WTP >> transfer its latest crash file. Once the WTP acknowledges that it >> has information to send, via the Data Transfer Response, it transmits > >> its own Data Transfer Request. Upon receipt, the AC responds with a >> Data Transfer Response, and the exchange continues until the WTP >> transmits a Data Transfer Data message element that indicates an End >> of File (EOF). >> >> WTP AC >> >> Data Transfer Request (Data Transfer Mode = Crash Data) >> <------------------------------------------------------ >> >> Data Transfer Response (Result Code = Success) >> --------------------------------------------------------> >> >> Data Transfer Request (Data Transfer Data = Data) >> --------------------------------------------------------> >> >> Data Transfer Response (Result Code = Success) >> <------------------------------------------------------ >> >> ..... >> >> Data Transfer Request (Data Transfer Data = EOF) >> <------------------------------------------------------ >> >> Data Transfer Response (Result Code = Success) >> --------------------------------------------------------> >> >> >> Figure 10: WTP Data Transfer Case 1 >> >> Figure 11 provides an example of an AC that requests that the WTP >> transfer its latest crash file. However, in this example, the WTP >> does not have any crash information to send, and therefore sends a >> Data Transfer Response with a Result Code indicating the error. >> >> WTP AC >> >> Data Transfer Request (Data Transfer Mode = Crash Data) >> <------------------------------------------------------ >> >> Data Transfer Response (Result Code = Data Transfer >> Error (No Information to Transfer)) >> --------------------------------------------------------> >> >> >> Figure 11: WTP Data Transfer Case 2 >> >> 9.6.1. Data Transfer Request >> >> The Data Transfer Request message is used to deliver debug >> information from the WTP to the AC. >> >> The Data Transfer Request messages can be sent either by the AC or >> the WTP. When sent by the AC, it is used to request that data be >> transmitted from the WTP to the AC, and includes the Data Transfer >> Mode message element, which specifies the information desired by the >> AC. The Data Transfer Request is sent by the WTP in order to >> transfer actual data to the AC, through the Data Transfer Data >> message element. >> >> Given that the CAPWAP protocol minimizes the need for WTPs to be >> directly managed, the Data Transfer Request is an important >> troubleshooting tool used by the AC to retrieve information that may >> be available on the WTP. For instance, some WTPs implementations may > >> store crash information to help manufacturers identify software >> faults. The Data Transfer Request message can be used to send such >> information from the WTP to the AC. Another possible use would be to > >> allow a remote debugger function in the WTP to use the Data Transfer >> Request message to send console output to the AC for debugging >> purposes. >> >> When the WTP or AC receives a Data Transfer Request message it >> responds to the WTP with a Data Transfer Response message. The AC >> MAY log the information received through the Data Transfer Data >> message element. >> >> The Data Transfer Request message is sent by the WTP or AC when in >> the Run State. >> >> When sent by the AC, the Data Transfer Request message MUST contain >> the following message elements: >> >> o Data Transfer Mode, see Section 4.6.17 >> >> When sent by the WTP, the Data Transfer Request message MUST contain > >> the following message elements: >> >> o Data Transfer Data, see Section 4.6.16 >> >> Regardless of whether the Data Transfer Request is sent by the AC or > >> WTP, the following message elements MAY be included in the Data >> Transfer Request message: >> >> o Vendor Specific Payload, see Section 4.6.39 >> >> 9.6.2. Data Transfer Response >> >> The Data Transfer Response message acknowledges the Data Transfer >> Request message. >> >> A Data Transfer Response message is sent in response to a received >> Data Transfer Request message. Its purpose is to acknowledge receipt > >> of the Data Transfer Request message. When sent by the WTP, the >> Result Code message element is used to indicate whether the data >> transfer requested by the AC can be completed. When sent by the AC, >> the Result Code message element is used to indicate receipt of the >> data transfered in the Data Transfer Request message. >> >> The Data Transfer Response message is sent by the WTP or AC when in >> the Run State. >> >> The following message element MUST be included in the Data Transfer >> Response message. >> >> o Result Code, see Section 4.6.35 >> >> The following message elements MAY be included in the Data Transfer >> Response message: >> >> o Vendor Specific Payload, see Section 4.6.39 >> >> Upon receipt of a Data Transfer Response message, the WTP transmits >> more information, if more information is available. >> >> >> PatC >> >> >> ------------------------------ >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/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 Jul 8 05:56:02 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC75E3A68BB for ; Tue, 8 Jul 2008 05:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtpXq2gMw6Yh for ; Tue, 8 Jul 2008 05:55:58 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 98B743A688C for ; Tue, 8 Jul 2008 05:55:58 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0B4B2432276 for ; Tue, 8 Jul 2008 05:56:08 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 0B1FD440114 for ; Tue, 8 Jul 2008 05:55:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D2B4034AC058 for ; Tue, 8 Jul 2008 05:55:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2038334AC05D for ; Tue, 8 Jul 2008 05:55:55 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 8 Jul 2008 05:55:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,323,1212364800"; d="scan'208";a="63581268" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 08 Jul 2008 12:55:54 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m68Ctsl0029995; Tue, 8 Jul 2008 05:55:54 -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.13.8/8.13.8) with ESMTP id m68CtsAP007966; Tue, 8 Jul 2008 12:55:54 GMT 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, 8 Jul 2008 05:55:54 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 05:55:51 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D1A9A@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 145: 802.11 binding doc. Issues (DECISION REQUIRED) Thread-Index: AcjgnXYTasttdnvVTEGsFAPa9NxYtQAW/JHw References: <4FF84B0BC277FF45AA27FE969DD956A2060D1930@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Yong Zhang" X-OriginalArrivalTime: 08 Jul 2008 12:55:54.0209 (UTC) FILETIME=[F5020D10:01C8E0F9] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap@frascone.com Subject: [Capwap] Issue 145: 802.11 binding doc. Issues (DECISION REQUIRED) 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 Nothing preventing, except that we agreed a long time ago to only fix bugs, not add new features. All of the issues we've been discussing have been fixes - this is clearly not a fix. However, since it is a small change from a value to a bit field, let's see what others think. This change would allow the WTP to use both L2 and L3 QoS marking. Just to be clear: 6.22. IEEE 802.11 WTP Quality of Service [...] Tag Packets: A value indicating whether CAPWAP packets should be tagged for QoS purposes. The following values are currently supported: 0 - Untagged 1 - 802.1p 2 - DSCP 6.22. IEEE 802.11 WTP Quality of Service [...] Tag Packets: A bit field indicating whether CAPWAP packets should be tagged for QoS purposes. The following values are currently supported: 0 - Untagged 1 - 802.1p 2 - DSCP Any disagreement on moving forward with this change? PatC -----Original Message----- From: Yong Zhang [mailto:yozhang@gmail.com] Sent: Monday, July 07, 2008 6:54 PM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Re: [Capwap] 802.11 binding doc. issues > > 6.22 > > "tag packets" is bit value? Can I set the tag the packet with both 1p > and DSCP? If I can, we need to add a value 3. > > Immediately following the above header is the following data > structure. This data structure will be repeated five times; once > for every QoS profile. The order of the QoS profiles are Voice, > Video, Best Effort and Background. > > Here should be "four times". > > Are the above mandatory? If they are, the ME len is ( 2 + 8 * 4) = 34. Correct - and no, only one or the other is possible at this point. Can you tell me what prevent the taging of both 1p and dscp? > > > 7.4. IEEE80211OFDMControl > > The WTP per radio MAC Operation configuration, defined in > Section 6.10. > > OFDM Not sure what your comment is. The title is OFDM, and the content is for MAC oper. Yong On Mon, Jul 7, 2008 at 3:28 PM, Pat Calhoun (pacalhou) wrote: > Created issue 145 to track this one. Responses below. > > PatC > > On Mon, Jul 7, 2008 at 10:30 AM, Yong Zhang wrote: >> 3.2. IEEE 802.11 WLAN Configuration Response >> >> Can we put MUST ME earlier than MAY ME for this message in the >> message > definition? > > Done. We now have consistency in ordering across both docs. > >> >> >> 6.1 >> >> The len should be >=52? >> >> 4 + 4 + 32 + 4 + 4 + 4 = 52 (assume SSID to be at least 1 byte) >> >> We have a key length field, however, >> >> "Key: A 32 byte Session Key to use to provide data privacy. " > > Yes, that is correct and I have fixed this. > >> >> 6.2 >> >> len = 5 > No, this is not correct. The Antenna Selection field will be of length > 'Antenna Count'. > >> >> 6.3 >> >> len = 8 > > Correct. > >> >> 6.6 >> >> This is used to include only one IE? If it is, should we remove the >> "..." in the figure? >> >> Also the len is bigger than 4. The minimal len of IE is 1 ? > > No, the ... Implies the length of the field is variable and may be > greater than 1. I think the length is fine. > >> >> 6.13 >> >> len >= 14 >> >> I am not sure the minimal size of supported rates. Here assume it is > one. > Correct. > >> >> 6.14 >> >> Here the 802.1p tag is defined with 2 bytes, but other places only >> use >> 1 byte. Only the 3 least >> significant bits are used. > We had agreed to leave this as is to minimize backward compatibility > issues, as per Margaret's request. > >> >> 6.15. >> >> I am not familiar with the keys. How do you get the length value? The >> minimal length of Key is 5 bytes? > Depends on the crypto used. The 802.11 spec is clear about this. > >> >> 6.16 >> >> len is 80 > Yes > >> >> >> 6.21 >> >> len is 40 >> >> same issue on Key as 6.1 > Correct > >> >> 6.22 >> >> "tag packets" is bit value? Can I set the tag the packet with both 1p >> and DSCP? If I can, we need to add a value 3. >> >> Immediately following the above header is the following data >> structure. This data structure will be repeated five times; once >> for every QoS profile. The order of the QoS profiles are Voice, >> Video, Best Effort and Background. >> >> Here should be "four times". >> >> Are the above mandatory? If they are, the ME len is ( 2 + 8 * 4) = 34. > Correct - and no, only one or the other is possible at this point. > >> >> >> 7.4. IEEE80211OFDMControl >> >> The WTP per radio MAC Operation configuration, defined in >> Section 6.10. >> >> OFDM > > Not sure what your comment is. > >> >> >> 8. Technology Specific Message Element Values >> >> I do not know which capwap ME is talking about at here. How to use >> the > >> defined value here? > > Interesting. This was an xml bug in my source code. I have fixed it > and the new text is: > > 8.1. WTP Descriptor Message Element, Encryption Capabilities Field: > > IEEE 802.11 uses the following values: > > 4 - Encrypt AES-CCMP 128: WTP supports AES-CCMP, as defined in > [IEEE.802-11.2007]. > > 5 - Encrypt TKIP-MIC: WTP supports TKIP and Michael, as defined in > [IEEE.802-11.2007] and [WPA], respectively. > > > 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 Jul 8 08:18:09 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2599E3A6867 for ; Tue, 8 Jul 2008 08:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aehXqMzc-XdW for ; Tue, 8 Jul 2008 08:18:05 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 064DA3A6810 for ; Tue, 8 Jul 2008 08:18:05 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 94C5543328F for ; Tue, 8 Jul 2008 08:18:14 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 0413144000F for ; Tue, 8 Jul 2008 08:18:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id CF96E34AC058 for ; Tue, 8 Jul 2008 08:18:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 217E834AC077 for ; Tue, 8 Jul 2008 08:17:50 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from yx-out-1718.google.com (yx-out-1718.google.com [74.125.44.157]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 8 Jul 2008 08:17:47 -0700 (PDT) Received: by yx-out-1718.google.com with SMTP id 3so555059yxi.80 for ; Tue, 08 Jul 2008 08:17:47 -0700 (PDT) Received: by 10.143.36.15 with SMTP id o15mr1841828wfj.36.1215530266453; Tue, 08 Jul 2008 08:17:46 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Tue, 8 Jul 2008 08:17:46 -0700 (PDT) Message-ID: Date: Tue, 8 Jul 2008 08:17:46 -0700 From: "Yong Zhang" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2060D1A9A@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <4FF84B0BC277FF45AA27FE969DD956A2060D1930@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1A9A@xmb-sjc-235.amer.cisco.com> Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 145: 802.11 binding doc. Issues (DECISION REQUIRED) 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 Qos Old and New are same. Did you get the one for 7.4 IEEE80211OFDMControl? >> 7.4. IEEE80211OFDMControl >> >> The WTP per radio MAC Operation configuration, defined in >> Section 6.10. >> >> OFDM > > Not sure what your comment is. > > The title is OFDM, and the content is for MAC oper. > On Tue, Jul 8, 2008 at 5:55 AM, Pat Calhoun (pacalhou) wrote: > Nothing preventing, except that we agreed a long time ago to only fix > bugs, not add new features. All of the issues we've been discussing have > been fixes - this is clearly not a fix. However, since it is a small > change from a value to a bit field, let's see what others think. This > change would allow the WTP to use both L2 and L3 QoS marking. > > Just to be clear: > > 6.22. IEEE 802.11 WTP Quality of Service > [...] > Tag Packets: A value indicating whether CAPWAP packets should be > tagged for QoS purposes. The following values are currently > supported: > > 0 - Untagged > > 1 - 802.1p > > 2 - DSCP > > > > 6.22. IEEE 802.11 WTP Quality of Service > [...] > Tag Packets: A bit field indicating whether CAPWAP packets should > be > tagged for QoS purposes. The following values are currently > supported: > > 0 - Untagged > > 1 - 802.1p > > 2 - DSCP > > > Any disagreement on moving forward with this change? > > PatC > > -----Original Message----- > From: Yong Zhang [mailto:yozhang@gmail.com] > Sent: Monday, July 07, 2008 6:54 PM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: Re: [Capwap] 802.11 binding doc. issues > >> >> 6.22 >> >> "tag packets" is bit value? Can I set the tag the packet with both 1p >> and DSCP? If I can, we need to add a value 3. >> >> Immediately following the above header is the following data >> structure. This data structure will be repeated five times; once >> for every QoS profile. The order of the QoS profiles are Voice, >> Video, Best Effort and Background. >> >> Here should be "four times". >> >> Are the above mandatory? If they are, the ME len is ( 2 + 8 * 4) = 34. > Correct - and no, only one or the other is possible at this point. > > Can you tell me what prevent the taging of both 1p and dscp? > >> >> >> 7.4. IEEE80211OFDMControl >> >> The WTP per radio MAC Operation configuration, defined in >> Section 6.10. >> >> OFDM > > Not sure what your comment is. > > The title is OFDM, and the content is for MAC oper. > > Yong > > > On Mon, Jul 7, 2008 at 3:28 PM, Pat Calhoun (pacalhou) > wrote: >> Created issue 145 to track this one. Responses below. >> >> PatC >> >> On Mon, Jul 7, 2008 at 10:30 AM, Yong Zhang wrote: >>> 3.2. IEEE 802.11 WLAN Configuration Response >>> >>> Can we put MUST ME earlier than MAY ME for this message in the >>> message >> definition? >> >> Done. We now have consistency in ordering across both docs. >> >>> >>> >>> 6.1 >>> >>> The len should be >=52? >>> >>> 4 + 4 + 32 + 4 + 4 + 4 = 52 (assume SSID to be at least 1 byte) >>> >>> We have a key length field, however, >>> >>> "Key: A 32 byte Session Key to use to provide data privacy. " >> >> Yes, that is correct and I have fixed this. >> >>> >>> 6.2 >>> >>> len = 5 >> No, this is not correct. The Antenna Selection field will be of length > >> 'Antenna Count'. >> >>> >>> 6.3 >>> >>> len = 8 >> >> Correct. >> >>> >>> 6.6 >>> >>> This is used to include only one IE? If it is, should we remove the >>> "..." in the figure? >>> >>> Also the len is bigger than 4. The minimal len of IE is 1 ? >> >> No, the ... Implies the length of the field is variable and may be >> greater than 1. I think the length is fine. >> >>> >>> 6.13 >>> >>> len >= 14 >>> >>> I am not sure the minimal size of supported rates. Here assume it is >> one. >> Correct. >> >>> >>> 6.14 >>> >>> Here the 802.1p tag is defined with 2 bytes, but other places only >>> use >>> 1 byte. Only the 3 least >>> significant bits are used. >> We had agreed to leave this as is to minimize backward compatibility >> issues, as per Margaret's request. >> >>> >>> 6.15. >>> >>> I am not familiar with the keys. How do you get the length value? The > >>> minimal length of Key is 5 bytes? >> Depends on the crypto used. The 802.11 spec is clear about this. >> >>> >>> 6.16 >>> >>> len is 80 >> Yes >> >>> >>> >>> 6.21 >>> >>> len is 40 >>> >>> same issue on Key as 6.1 >> Correct >> >>> >>> 6.22 >>> >>> "tag packets" is bit value? Can I set the tag the packet with both 1p > >>> and DSCP? If I can, we need to add a value 3. >>> >>> Immediately following the above header is the following data >>> structure. This data structure will be repeated five times; > once >>> for every QoS profile. The order of the QoS profiles are Voice, >>> Video, Best Effort and Background. >>> >>> Here should be "four times". >>> >>> Are the above mandatory? If they are, the ME len is ( 2 + 8 * 4) = > 34. >> Correct - and no, only one or the other is possible at this point. >> >>> >>> >>> 7.4. IEEE80211OFDMControl >>> >>> The WTP per radio MAC Operation configuration, defined in >>> Section 6.10. >>> >>> OFDM >> >> Not sure what your comment is. >> >>> >>> >>> 8. Technology Specific Message Element Values >>> >>> I do not know which capwap ME is talking about at here. How to use >>> the >> >>> defined value here? >> >> Interesting. This was an xml bug in my source code. I have fixed it >> and the new text is: >> >> 8.1. WTP Descriptor Message Element, Encryption Capabilities Field: >> >> IEEE 802.11 uses the following values: >> >> 4 - Encrypt AES-CCMP 128: WTP supports AES-CCMP, as defined in >> [IEEE.802-11.2007]. >> >> 5 - Encrypt TKIP-MIC: WTP supports TKIP and Michael, as defined in >> [IEEE.802-11.2007] and [WPA], respectively. >> >> >> 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 Jul 8 08:22:11 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 311243A6950 for ; Tue, 8 Jul 2008 08:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J57vxy4iYQtg for ; Tue, 8 Jul 2008 08:22:10 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 08ADC3A686C for ; Tue, 8 Jul 2008 08:22:10 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B06D243323B for ; Tue, 8 Jul 2008 08:22:19 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 4E23344000F for ; Tue, 8 Jul 2008 08:22:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id DFFA134AC06E for ; Tue, 8 Jul 2008 08:22:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 420C634AC061 for ; Tue, 8 Jul 2008 08:22:05 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.68.10.87 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 8 Jul 2008 08:22:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,323,1212364800"; d="scan'208";a="35896092" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 08 Jul 2008 15:21:58 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m68FLw2J015317; Tue, 8 Jul 2008 08:21:58 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m68FLw7R005019; Tue, 8 Jul 2008 15:21:58 GMT 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.1830); Tue, 8 Jul 2008 08:21:58 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 08:21:57 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D1B1E@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 145: 802.11 binding doc. Issues (DECISION REQUIRED) Thread-Index: AcjhDc2Cl5EYjUPcTLOJx6lZJb9NUAAABoJA References: <4FF84B0BC277FF45AA27FE969DD956A2060D1930@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1A9A@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Yong Zhang" X-OriginalArrivalTime: 08 Jul 2008 15:21:58.0360 (UTC) FILETIME=[5CD95D80:01C8E10E] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 145: 802.11 binding doc. Issues (DECISION REQUIRED) 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 > Qos Old and New are same. No, the new text states it is a bit field, which means that both 1 and 2 can be set at the same time. > Did you get the one for 7.4 IEEE80211OFDMControl? > > >> 7.4. IEEE80211OFDMControl > >> > >> The WTP per radio MAC Operation configuration, defined in > >> Section 6.10. > >> > >> OFDM > > > > Not sure what your comment is. > > > > The title is OFDM, and the content is for MAC oper. > > Right, the text should have been The WTP per radio OFDM MAC Operation configuration, defined in Section 6.10 PatC On Tue, Jul 8, 2008 at 5:55 AM, Pat Calhoun (pacalhou) wrote: > Nothing preventing, except that we agreed a long time ago to only fix > bugs, not add new features. All of the issues we've been discussing > have been fixes - this is clearly not a fix. However, since it is a > small change from a value to a bit field, let's see what others think. > This change would allow the WTP to use both L2 and L3 QoS marking. > > Just to be clear: > > 6.22. IEEE 802.11 WTP Quality of Service [...] > Tag Packets: A value indicating whether CAPWAP packets should be > tagged for QoS purposes. The following values are currently > supported: > > 0 - Untagged > > 1 - 802.1p > > 2 - DSCP > > > > 6.22. IEEE 802.11 WTP Quality of Service [...] > Tag Packets: A bit field indicating whether CAPWAP packets should > be > tagged for QoS purposes. The following values are currently > supported: > > 0 - Untagged > > 1 - 802.1p > > 2 - DSCP > > > Any disagreement on moving forward with this change? > > PatC > > -----Original Message----- > From: Yong Zhang [mailto:yozhang@gmail.com] > Sent: Monday, July 07, 2008 6:54 PM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: Re: [Capwap] 802.11 binding doc. issues > >> >> 6.22 >> >> "tag packets" is bit value? Can I set the tag the packet with both 1p >> and DSCP? If I can, we need to add a value 3. >> >> Immediately following the above header is the following data >> structure. This data structure will be repeated five times; once >> for every QoS profile. The order of the QoS profiles are Voice, >> Video, Best Effort and Background. >> >> Here should be "four times". >> >> Are the above mandatory? If they are, the ME len is ( 2 + 8 * 4) = 34. > Correct - and no, only one or the other is possible at this point. > > Can you tell me what prevent the taging of both 1p and dscp? > >> >> >> 7.4. IEEE80211OFDMControl >> >> The WTP per radio MAC Operation configuration, defined in >> Section 6.10. >> >> OFDM > > Not sure what your comment is. > > The title is OFDM, and the content is for MAC oper. > > Yong > > > On Mon, Jul 7, 2008 at 3:28 PM, Pat Calhoun (pacalhou) > wrote: >> Created issue 145 to track this one. Responses below. >> >> PatC >> >> On Mon, Jul 7, 2008 at 10:30 AM, Yong Zhang wrote: >>> 3.2. IEEE 802.11 WLAN Configuration Response >>> >>> Can we put MUST ME earlier than MAY ME for this message in the >>> message >> definition? >> >> Done. We now have consistency in ordering across both docs. >> >>> >>> >>> 6.1 >>> >>> The len should be >=52? >>> >>> 4 + 4 + 32 + 4 + 4 + 4 = 52 (assume SSID to be at least 1 byte) >>> >>> We have a key length field, however, >>> >>> "Key: A 32 byte Session Key to use to provide data privacy. " >> >> Yes, that is correct and I have fixed this. >> >>> >>> 6.2 >>> >>> len = 5 >> No, this is not correct. The Antenna Selection field will be of >> length > >> 'Antenna Count'. >> >>> >>> 6.3 >>> >>> len = 8 >> >> Correct. >> >>> >>> 6.6 >>> >>> This is used to include only one IE? If it is, should we remove the >>> "..." in the figure? >>> >>> Also the len is bigger than 4. The minimal len of IE is 1 ? >> >> No, the ... Implies the length of the field is variable and may be >> greater than 1. I think the length is fine. >> >>> >>> 6.13 >>> >>> len >= 14 >>> >>> I am not sure the minimal size of supported rates. Here assume it is >> one. >> Correct. >> >>> >>> 6.14 >>> >>> Here the 802.1p tag is defined with 2 bytes, but other places only >>> use >>> 1 byte. Only the 3 least >>> significant bits are used. >> We had agreed to leave this as is to minimize backward compatibility >> issues, as per Margaret's request. >> >>> >>> 6.15. >>> >>> I am not familiar with the keys. How do you get the length value? >>> The > >>> minimal length of Key is 5 bytes? >> Depends on the crypto used. The 802.11 spec is clear about this. >> >>> >>> 6.16 >>> >>> len is 80 >> Yes >> >>> >>> >>> 6.21 >>> >>> len is 40 >>> >>> same issue on Key as 6.1 >> Correct >> >>> >>> 6.22 >>> >>> "tag packets" is bit value? Can I set the tag the packet with both >>> 1p > >>> and DSCP? If I can, we need to add a value 3. >>> >>> Immediately following the above header is the following data >>> structure. This data structure will be repeated five times; > once >>> for every QoS profile. The order of the QoS profiles are Voice, >>> Video, Best Effort and Background. >>> >>> Here should be "four times". >>> >>> Are the above mandatory? If they are, the ME len is ( 2 + 8 * 4) = > 34. >> Correct - and no, only one or the other is possible at this point. >> >>> >>> >>> 7.4. IEEE80211OFDMControl >>> >>> The WTP per radio MAC Operation configuration, defined in >>> Section 6.10. >>> >>> OFDM >> >> Not sure what your comment is. >> >>> >>> >>> 8. Technology Specific Message Element Values >>> >>> I do not know which capwap ME is talking about at here. How to use >>> the >> >>> defined value here? >> >> Interesting. This was an xml bug in my source code. I have fixed it >> and the new text is: >> >> 8.1. WTP Descriptor Message Element, Encryption Capabilities Field: >> >> IEEE 802.11 uses the following values: >> >> 4 - Encrypt AES-CCMP 128: WTP supports AES-CCMP, as defined in >> [IEEE.802-11.2007]. >> >> 5 - Encrypt TKIP-MIC: WTP supports TKIP and Michael, as defined in >> [IEEE.802-11.2007] and [WPA], respectively. >> >> >> 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 Jul 8 08:27:24 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2F63A6869 for ; Tue, 8 Jul 2008 08:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FF1XUcKTuXqd for ; Tue, 8 Jul 2008 08:27:23 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id CCFCB3A681A for ; Tue, 8 Jul 2008 08:27:23 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8AEA4433188 for ; Tue, 8 Jul 2008 08:27:33 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id AC0C544000F for ; Tue, 8 Jul 2008 08:27:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3B11734AC071 for ; Tue, 8 Jul 2008 08:27:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 7446134AC072 for ; Tue, 8 Jul 2008 08:27:18 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 8 Jul 2008 08:27:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,323,1212364800"; d="scan'208";a="50140390" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 08 Jul 2008 15:27:13 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m68FRDaa028997 for ; Tue, 8 Jul 2008 08:27:13 -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.13.8/8.13.8) with ESMTP id m68FRC8C016782 for ; Tue, 8 Jul 2008 15:27:13 GMT 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, 8 Jul 2008 08:27:13 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 08:26:46 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D1B22@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 146: Invalid reference to boolean term Thread-Index: AcjhDwi25sbCrR3XQ9mM+A0VUEnMlA== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 08 Jul 2008 15:27:13.0000 (UTC) FILETIME=[18639E80:01C8E10F] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Capwap] Issue 146: Invalid reference to boolean term 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 All, During a change to 4.6.34, we agreed to keep the value zero (0) Reserved to maintain compatibility with -10. However, the text continues to refer to this field as a boolean value. Clearly, the values defined makes this a non-boolean since enabled is 1 and disabled is 2. The current text states: State: An 8-bit boolean value representing the state of the radio. The following enumerated values are supported: 0 - Reserved 1 - Enabled 2 - Disabled I would propose removing the term boolean from the text. Lastly, in section 4.6.50, we are again using enabled and disabled, and the text reads: 4.6.50. WTP Static IP Address Information [...] Static: An 8-bit boolean stating whether the WTP should use a static IP address or not. A value of zero disables the static IP address, while a value of one enables it. In order to make sure that we have complete consistency, I would propose changin the text to: State: An 8-bit value stating whether the WTP should use a static IP address or not. The following enumerated values are supported: 0 - Reserved 1 - Enabled 2 - Disabled 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 Jul 8 08:31:16 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A969E3A693E for ; Tue, 8 Jul 2008 08:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4DEMYRkaNEn for ; Tue, 8 Jul 2008 08:31:15 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id E1C8E3A681A for ; Tue, 8 Jul 2008 08:31:15 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A05C9433143 for ; Tue, 8 Jul 2008 08:31:25 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id EEDF444000F for ; Tue, 8 Jul 2008 08:31:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 9CCAC34AC017 for ; Tue, 8 Jul 2008 08:31:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id AAFAF34AC02D for ; Tue, 8 Jul 2008 08:31:12 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.237]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 8 Jul 2008 08:31:12 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id h29so1922742wxd.11 for ; Tue, 08 Jul 2008 08:31:12 -0700 (PDT) Received: by 10.142.49.4 with SMTP id w4mr1842492wfw.194.1215531071404; Tue, 08 Jul 2008 08:31:11 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Tue, 8 Jul 2008 08:31:11 -0700 (PDT) Message-ID: Date: Tue, 8 Jul 2008 08:31:11 -0700 From: "Yong Zhang" To: capwap@frascone.com MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [Capwap] New Issue 144: Invalid reference to 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This change is OK for me. Yong ------------------------------ Message: 2 Date: Mon, 7 Jul 2008 14:58:55 -0700 From: "Pat Calhoun (pacalhou)" Subject: [Capwap] New Issue 144: Invalid reference to message element field To: Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D1905@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset="us-ascii" Yong has raised another issue. The following message elements have a Num of Entries field, which references a Type field, which does not exist in the message element. The 'Type' field needs to be 'Length': 4.6.7. Add MAC ACL Entry 4.6.9. Add Static MAC ACL Entry 4.6.20. Delete MAC ACL Entry 4.6.22. Delete Static MAC ACL Entry So the following text: Num of Entries: The number of instances of the Type/MAC Addresses fields in the array. This field MUST NOT exceed the value of 255. Needs to be modified to: Num of Entries: The number of instances of the Length/MAC Addresses fields in the array. This field MUST NOT exceed the value of 255. 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 Jul 8 08:44:32 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A98883A6A38 for ; Tue, 8 Jul 2008 08:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEI9SeV-u1la for ; Tue, 8 Jul 2008 08:44:31 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 967A83A67E5 for ; Tue, 8 Jul 2008 08:44:31 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 58F424331AC for ; Tue, 8 Jul 2008 08:44:41 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id C92EC44012C for ; Tue, 8 Jul 2008 08:44:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8372234AC05B for ; Tue, 8 Jul 2008 08:44:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D34DF34AC0A4 for ; Tue, 8 Jul 2008 08:43:59 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 8 Jul 2008 08:43:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,323,1212364800"; d="scan'208";a="63639502" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 08 Jul 2008 15:43:59 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m68Fhx53001096 for ; Tue, 8 Jul 2008 08:43:59 -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.13.8/8.13.8) with ESMTP id m68FhxdZ024977 for ; Tue, 8 Jul 2008 15:43:59 GMT 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.1830); Tue, 8 Jul 2008 08:43:22 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 08:42:31 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D1B42@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Issue 147: Timer Issues Thread-Index: AcjhETvd2AYV/os6RPCFDqV6zcYYkQ== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 08 Jul 2008 15:43:22.0257 (UTC) FILETIME=[5A1C8010:01C8E111] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Capwap] New Issue 147: Timer Issues 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 All, Yong has sent me the following two issues he has found as he finished his review of the two specs. The first issue is an issue - we need to include the timer in the state machine. The second one is also correct as the default value is of the DataChannelKeepAlive, which is 30, so the default value needs to be 60. 4.7.6. DTLSSessionDelete The minimum time, in seconds, a WTP MUST wait for DTLS session deletion. Default: 5 There is no other place talked about this timer. Do you need to put it into FSM? 4.7.3. DataChannelDeadInterval The minimum time, in seconds, a WTP MUST wait without having received a Data Channel Keep Alive packet before the destination for the Data Channel Keep Alive packets may be considered dead. The value of this timer MUST be no less than 2*DataChannelKeepAlive seconds and no greater that 240 seconds. Default: 5 We have set the default of DataChannelKeepAlive to be 30. So here we need to set DataChannelDeadInterval to be 60. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 8 08:50:40 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BC2D3A686C for ; Tue, 8 Jul 2008 08:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdKGcLeZNlrp for ; Tue, 8 Jul 2008 08:50:38 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 9C89E3A6803 for ; Tue, 8 Jul 2008 08:50:38 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3C1374330CD for ; Tue, 8 Jul 2008 08:50:48 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 3ADE6440115 for ; Tue, 8 Jul 2008 08:50:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 7457734AC04D for ; Tue, 8 Jul 2008 08:50:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8E7DA34AC058 for ; Tue, 8 Jul 2008 08:50:29 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.68.10.87 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 8 Jul 2008 08:50:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,323,1212364800"; d="scan'208";a="35906565" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 08 Jul 2008 15:50:25 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m68FoPO2012375 for ; Tue, 8 Jul 2008 08:50:25 -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.13.8/8.13.8) with ESMTP id m68FoPZj028861 for ; Tue, 8 Jul 2008 15:50:25 GMT 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, 8 Jul 2008 08:50:25 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 08:50:16 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D1B4F@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2060D1B42@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New Issue 147: Timer Issues Thread-Index: AcjhETvd2AYV/os6RPCFDqV6zcYYkQAAGqZw References: <4FF84B0BC277FF45AA27FE969DD956A2060D1B42@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 08 Jul 2008 15:50:25.0748 (UTC) FILETIME=[56881940:01C8E112] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Capwap] New Issue 147: Timer Issues 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 OK, so the fixes are fairly straightforward. All state transitions to the DTLSTeardown need to have the DTLSSessionDelete timer started. If the timer expires, then we DTLSTeardown to Idle or Dead (WTP or AC, respectively) state transitions occurs. This ensures that the state machine doesn't get stuck in the DTLSTeardown state. My apologies for lots of text here - it would be hard to read if I just pulled the sentence that I added. So the only change is the sentence referencing the timer in each of the state transitions below: Authorize to DTLS Teardown (b): This transition occurs to notify the DTLS stack that the session should be aborted. WTP: This state transition occurs when the WTP was unable to authorize the AC, using the AC credentials. The WTP then aborts the DTLS session by invoking the DTLSAbortSession command (see Section 2.3.2.1). This state transition also occurs if the WaitDTLS timer has expired. The WTP starts the DTLSSessionDelete timer (see Section 4.7.6). AC: This state transition occurs when the AC was unable to authorize the WTP, using the WTP credentials. The AC then aborts the DTLS session by invoking the DTLSAbortSession command (see Section 2.3.2.1). This state transition also occurs if the WaitDTLS timer has expired. The AC starts the DTLSSessionDelete timer (see Section 4.7.6). DTLS Connect to DTLS Teardown (c): This transition occurs when the DTLS Session failed to be established. WTP: This state transition occurs when the WTP receives either a DTLSAborted or DTLSAuthenticateFail notification (see Section 2.3.2.2), indicating that the DTLS session was not successfully established. When this transition occurs due to the DTLSAuthenticateFail notification, the FailedDTLSAuthFailCount is incremented, otherwise the FailedDTLSSessionCount counter is incremented. This state transition also occurs if the WaitDTLS timer has expired. The WTP starts the DTLSSessionDelete timer (see Section 4.7.6). AC: This state transition occurs when the AC receives either a DTLSAborted or DTLSAuthenticateFail notification (see Section 2.3.2.2), indicating that the DTLS session was not successfully established, and both of the FailedDTLSAuthFailCount and FailedDTLSSessionCount counters have not reached the value of the MaxFailedDTLSSessionRetry variable (see Section 4.8). This state transition also occurs if the WaitDTLS timer has expired. The AC starts the DTLSSessionDelete timer (see Section 4.7.6). [...] Join to DTLS Teardown (e): This transition occurs when the join process failed. WTP: This state transition occurs when the WTP receives a Join Response message with a Result Code message element containing an error, if the Image Identifier provided by the AC in the Join Response message differs from the WTP's currently running firmware version and the WTP has the requested image in its non-volatile memory, or if the WaitDTLS timer expires. This causes the WTP to initiate the DTLSShutdown command (see Section 2.3.2.1). This transition also occurs if the WTP receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect. The WTP starts the DTLSSessionDelete timer (see Section 4.7.6). AC: This state transition occurs either if the WaitDTLS timer expires or if the AC transmits a Join Response message with a Result Code message element containing an error. This causes the AC to initiate the DTLSShutdown command (see Section 2.3.2.1). This transition also occurs if the AC receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect. The AC starts the DTLSSessionDelete timer (see Section 4.7.6). [...] Configure to DTLS Teardown (i): This transition occurs when the configuration process aborts due to a DTLS error. WTP: The WTP enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The WTP starts the DTLSSessionDelete timer (see Section 4.7.6). AC: The AC enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The AC MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The AC starts the DTLSSessionDelete timer (see Section 4.7.6). [...] Image Data to DTLS Teardown (l): This transition occurs when the firmware download process aborts due to a DTLS error. WTP: The WTP enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The WTP starts the DTLSSessionDelete timer (see Section 4.7.6). AC: The AC enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The AC MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The AC starts the DTLSSessionDelete timer (see Section 4.7.6). [...] Data Check to DTLS Teardown (n): This transition occurs when the WTP does not complete the Data Check exchange. WTP: This state transition occurs if the WTP does not receive the Change State Event Response message before a CAPWAP retransmission timeout occurs. The WTP also transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7). The WTP starts the DTLSSessionDelete timer (see Section 4.7.6). AC: The AC enters this state when the DataCheckTimer timer expires (see Section 4.7). The AC starts the DTLSSessionDelete timer (see Section 4.7.6). [...] Run to DTLS Teardown (p): This state transition occurs when an error has occurred in the DTLS stack, causing the DTLS session to be torn down. WTP: The WTP enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The WTP also transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7). The WTP starts the DTLSSessionDelete timer (see Section 4.7.6). AC: The AC enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The AC MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The AC transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7). This state transition also occurs when the AC's EchoInterval timer (see Section 4.7.7) or DTLSSessionDelete timer (see Section 4.7.6) expires. [...] Reset to DTLS Teardown (s): This transition occurs when the CAPWAP reset is complete, to terminate the DTLS session. WTP: This state transition occurs when the WTP transmits a Reset Response message. The WTP does not invoke the DTLSShutdown command (see Section 2.3.2.1). The WTP starts the DTLSSessionDelete timer (see Section 4.7.6). AC: This state transition occurs when the AC receives a Reset Response message. This causes the AC to initiate the DTLSShutdown command (see Section 2.3.2.1). The AC starts the DTLSSessionDelete timer (see Section 4.7.6). [...] DTLS Teardown to Idle (t): This transition occurs when the DTLS session has been shutdown. WTP: This state transition occurs when the WTP has successfully cleaned up all resources associated with the control plane DTLS session, or if the DTLSSessionDelete timer (see Section 4.7.6) expires. The data plane DTLS session is also shutdown, and all resources released, if a DTLS session was established for the data plane. Any timers set for the current instance of the state machine are also cleared. AC: This is an invalid state transition for the AC. [...] DTLS Teardown to Dead (w): This transition occurs when the DTLS session has been shutdown. WTP: This is an invalid state transition for the WTP. AC: This state transition occurs when the AC has successfully cleaned up all resources associated with the control plane DTLS session , or if the DTLSSessionDelete timer (see Section 4.7.6) expires. The data plane DTLS session is also shutdown, and all resources released, if a DTLS session was established for the data plane. Any timers set for the current instance of the state machine are also cleared. The AC's Service thread is terminated. [...] 4.7.3. DataChannelDeadInterval The minimum time, in seconds, a WTP MUST wait without having received a Data Channel Keep Alive packet before the destination for the Data Channel Keep Alive packets may be considered dead. The value of this timer MUST be no less than 2*DataChannelKeepAlive seconds and no greater that 240 seconds. Default: 60 This are the last of the changes from Yong's review. After I've received the OK, I will submit the drafts for publication, and the chairs can go ahead with another WG last call. PatC -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Tuesday, July 08, 2008 8:43 AM To: capwap@frascone.com Subject: [Capwap] New Issue 147: Timer Issues All, Yong has sent me the following two issues he has found as he finished his review of the two specs. The first issue is an issue - we need to include the timer in the state machine. The second one is also correct as the default value is of the DataChannelKeepAlive, which is 30, so the default value needs to be 60. 4.7.6. DTLSSessionDelete The minimum time, in seconds, a WTP MUST wait for DTLS session deletion. Default: 5 There is no other place talked about this timer. Do you need to put it into FSM? 4.7.3. DataChannelDeadInterval The minimum time, in seconds, a WTP MUST wait without having received a Data Channel Keep Alive packet before the destination for the Data Channel Keep Alive packets may be considered dead. The value of this timer MUST be no less than 2*DataChannelKeepAlive seconds and no greater that 240 seconds. Default: 5 We have set the default of DataChannelKeepAlive to be 30. So here we need to set DataChannelDeadInterval to be 60. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 8 09:04:34 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CCE328C0EC for ; Tue, 8 Jul 2008 09:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWn3YC1XlJQw for ; Tue, 8 Jul 2008 09:04:33 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 09A953A681A for ; Tue, 8 Jul 2008 09:04:33 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CB8EA43361E for ; Tue, 8 Jul 2008 09:04:42 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 593FB4400E3 for ; Tue, 8 Jul 2008 09:04:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id DAEE334AC0CC for ; Tue, 8 Jul 2008 09:04:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 7CA9C34AC0B6 for ; Tue, 8 Jul 2008 09:03:08 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 8 Jul 2008 09:03:08 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id h29so1933780wxd.11 for ; Tue, 08 Jul 2008 09:03:07 -0700 (PDT) Received: by 10.142.223.4 with SMTP id v4mr1854908wfg.107.1215532986708; Tue, 08 Jul 2008 09:03:06 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Tue, 8 Jul 2008 09:03:06 -0700 (PDT) Message-ID: Date: Tue, 8 Jul 2008 09:03:06 -0700 From: "Yong Zhang" To: capwap@frascone.com MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [Capwap] Issue 146: Invalid reference to boolean term 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 This change is OK for me. Yong ------------------------------ Message: 2 Date: Tue, 8 Jul 2008 08:26:46 -0700 From: "Pat Calhoun (pacalhou)" Subject: [Capwap] Issue 146: Invalid reference to boolean term To: Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D1B22@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset="us-ascii" All, During a change to 4.6.34, we agreed to keep the value zero (0) Reserved to maintain compatibility with -10. However, the text continues to refer to this field as a boolean value. Clearly, the values defined makes this a non-boolean since enabled is 1 and disabled is 2. The current text states: State: An 8-bit boolean value representing the state of the radio. The following enumerated values are supported: 0 - Reserved 1 - Enabled 2 - Disabled I would propose removing the term boolean from the text. Lastly, in section 4.6.50, we are again using enabled and disabled, and the text reads: 4.6.50. WTP Static IP Address Information [...] Static: An 8-bit boolean stating whether the WTP should use a static IP address or not. A value of zero disables the static IP address, while a value of one enables it. In order to make sure that we have complete consistency, I would propose changin the text to: State: An 8-bit value stating whether the WTP should use a static IP address or not. The following enumerated values are supported: 0 - Reserved 1 - Enabled 2 - Disabled 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 Jul 8 09:05:17 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5822428C190 for ; Tue, 8 Jul 2008 09:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9Y2dhgsCRbu for ; Tue, 8 Jul 2008 09:05:15 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id C305028C18D for ; Tue, 8 Jul 2008 09:05:15 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 418584335AC for ; Tue, 8 Jul 2008 09:05:25 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 8F8F44400E0 for ; Tue, 8 Jul 2008 09:04:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 44B8F34AC110 for ; Tue, 8 Jul 2008 09:04:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 908B93610004 for ; Tue, 8 Jul 2008 09:03:42 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 8 Jul 2008 09:03:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,323,1212364800"; d="scan'208";a="50159108" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 08 Jul 2008 16:03:42 +0000 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/8.12.11) with ESMTP id m68G3gUe027628 for ; Tue, 8 Jul 2008 09:03:42 -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.13.8/8.13.8) with ESMTP id m68G3fOf011590 for ; Tue, 8 Jul 2008 16:03:42 GMT 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, 8 Jul 2008 09:03:41 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 09:03:08 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D1B6B@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2060D1B4F@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New Issue 147: Timer Issues Thread-Index: AcjhETvd2AYV/os6RPCFDqV6zcYYkQAAGqZwAACVz+A= References: <4FF84B0BC277FF45AA27FE969DD956A2060D1B42@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1B4F@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 08 Jul 2008 16:03:41.0308 (UTC) FILETIME=[30B8EBC0:01C8E114] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Capwap] New Issue 147: Timer Issues 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 Sorry, I made a mistake on the AC portion of the Run to DTLS Teardown state transition below. It should be start the timer, while the text below refered to the timer expiring. The new text is: Run to DTLS Teardown (p): This state transition occurs when an error has occurred in the DTLS stack, causing the DTLS session to be torn down. [...] AC: The AC enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The AC MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The AC transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7). This state transition also occurs when the AC's EchoInterval timer (see Section 4.7.7) expires. The AC starts the DTLSSessionDelete timer (see Section 4.7.6). -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Tuesday, July 08, 2008 8:50 AM To: capwap@frascone.com Subject: Re: [Capwap] New Issue 147: Timer Issues OK, so the fixes are fairly straightforward. All state transitions to the DTLSTeardown need to have the DTLSSessionDelete timer started. If the timer expires, then we DTLSTeardown to Idle or Dead (WTP or AC, respectively) state transitions occurs. This ensures that the state machine doesn't get stuck in the DTLSTeardown state. My apologies for lots of text here - it would be hard to read if I just pulled the sentence that I added. So the only change is the sentence referencing the timer in each of the state transitions below: Authorize to DTLS Teardown (b): This transition occurs to notify the DTLS stack that the session should be aborted. WTP: This state transition occurs when the WTP was unable to authorize the AC, using the AC credentials. The WTP then aborts the DTLS session by invoking the DTLSAbortSession command (see Section 2.3.2.1). This state transition also occurs if the WaitDTLS timer has expired. The WTP starts the DTLSSessionDelete timer (see Section 4.7.6). AC: This state transition occurs when the AC was unable to authorize the WTP, using the WTP credentials. The AC then aborts the DTLS session by invoking the DTLSAbortSession command (see Section 2.3.2.1). This state transition also occurs if the WaitDTLS timer has expired. The AC starts the DTLSSessionDelete timer (see Section 4.7.6). DTLS Connect to DTLS Teardown (c): This transition occurs when the DTLS Session failed to be established. WTP: This state transition occurs when the WTP receives either a DTLSAborted or DTLSAuthenticateFail notification (see Section 2.3.2.2), indicating that the DTLS session was not successfully established. When this transition occurs due to the DTLSAuthenticateFail notification, the FailedDTLSAuthFailCount is incremented, otherwise the FailedDTLSSessionCount counter is incremented. This state transition also occurs if the WaitDTLS timer has expired. The WTP starts the DTLSSessionDelete timer (see Section 4.7.6). AC: This state transition occurs when the AC receives either a DTLSAborted or DTLSAuthenticateFail notification (see Section 2.3.2.2), indicating that the DTLS session was not successfully established, and both of the FailedDTLSAuthFailCount and FailedDTLSSessionCount counters have not reached the value of the MaxFailedDTLSSessionRetry variable (see Section 4.8). This state transition also occurs if the WaitDTLS timer has expired. The AC starts the DTLSSessionDelete timer (see Section 4.7.6). [...] Join to DTLS Teardown (e): This transition occurs when the join process failed. WTP: This state transition occurs when the WTP receives a Join Response message with a Result Code message element containing an error, if the Image Identifier provided by the AC in the Join Response message differs from the WTP's currently running firmware version and the WTP has the requested image in its non-volatile memory, or if the WaitDTLS timer expires. This causes the WTP to initiate the DTLSShutdown command (see Section 2.3.2.1). This transition also occurs if the WTP receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect. The WTP starts the DTLSSessionDelete timer (see Section 4.7.6). AC: This state transition occurs either if the WaitDTLS timer expires or if the AC transmits a Join Response message with a Result Code message element containing an error. This causes the AC to initiate the DTLSShutdown command (see Section 2.3.2.1). This transition also occurs if the AC receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect. The AC starts the DTLSSessionDelete timer (see Section 4.7.6). [...] Configure to DTLS Teardown (i): This transition occurs when the configuration process aborts due to a DTLS error. WTP: The WTP enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The WTP starts the DTLSSessionDelete timer (see Section 4.7.6). AC: The AC enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The AC MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The AC starts the DTLSSessionDelete timer (see Section 4.7.6). [...] Image Data to DTLS Teardown (l): This transition occurs when the firmware download process aborts due to a DTLS error. WTP: The WTP enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The WTP starts the DTLSSessionDelete timer (see Section 4.7.6). AC: The AC enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The AC MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The AC starts the DTLSSessionDelete timer (see Section 4.7.6). [...] Data Check to DTLS Teardown (n): This transition occurs when the WTP does not complete the Data Check exchange. WTP: This state transition occurs if the WTP does not receive the Change State Event Response message before a CAPWAP retransmission timeout occurs. The WTP also transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7). The WTP starts the DTLSSessionDelete timer (see Section 4.7.6). AC: The AC enters this state when the DataCheckTimer timer expires (see Section 4.7). The AC starts the DTLSSessionDelete timer (see Section 4.7.6). [...] Run to DTLS Teardown (p): This state transition occurs when an error has occurred in the DTLS stack, causing the DTLS session to be torn down. WTP: The WTP enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The WTP also transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7). The WTP starts the DTLSSessionDelete timer (see Section 4.7.6). AC: The AC enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The AC MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The AC transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7). This state transition also occurs when the AC's EchoInterval timer (see Section 4.7.7) or DTLSSessionDelete timer (see Section 4.7.6) expires. [...] Reset to DTLS Teardown (s): This transition occurs when the CAPWAP reset is complete, to terminate the DTLS session. WTP: This state transition occurs when the WTP transmits a Reset Response message. The WTP does not invoke the DTLSShutdown command (see Section 2.3.2.1). The WTP starts the DTLSSessionDelete timer (see Section 4.7.6). AC: This state transition occurs when the AC receives a Reset Response message. This causes the AC to initiate the DTLSShutdown command (see Section 2.3.2.1). The AC starts the DTLSSessionDelete timer (see Section 4.7.6). [...] DTLS Teardown to Idle (t): This transition occurs when the DTLS session has been shutdown. WTP: This state transition occurs when the WTP has successfully cleaned up all resources associated with the control plane DTLS session, or if the DTLSSessionDelete timer (see Section 4.7.6) expires. The data plane DTLS session is also shutdown, and all resources released, if a DTLS session was established for the data plane. Any timers set for the current instance of the state machine are also cleared. AC: This is an invalid state transition for the AC. [...] DTLS Teardown to Dead (w): This transition occurs when the DTLS session has been shutdown. WTP: This is an invalid state transition for the WTP. AC: This state transition occurs when the AC has successfully cleaned up all resources associated with the control plane DTLS session , or if the DTLSSessionDelete timer (see Section 4.7.6) expires. The data plane DTLS session is also shutdown, and all resources released, if a DTLS session was established for the data plane. Any timers set for the current instance of the state machine are also cleared. The AC's Service thread is terminated. [...] 4.7.3. DataChannelDeadInterval The minimum time, in seconds, a WTP MUST wait without having received a Data Channel Keep Alive packet before the destination for the Data Channel Keep Alive packets may be considered dead. The value of this timer MUST be no less than 2*DataChannelKeepAlive seconds and no greater that 240 seconds. Default: 60 This are the last of the changes from Yong's review. After I've received the OK, I will submit the drafts for publication, and the chairs can go ahead with another WG last call. PatC -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Tuesday, July 08, 2008 8:43 AM To: capwap@frascone.com Subject: [Capwap] New Issue 147: Timer Issues All, Yong has sent me the following two issues he has found as he finished his review of the two specs. The first issue is an issue - we need to include the timer in the state machine. The second one is also correct as the default value is of the DataChannelKeepAlive, which is 30, so the default value needs to be 60. 4.7.6. DTLSSessionDelete The minimum time, in seconds, a WTP MUST wait for DTLS session deletion. Default: 5 There is no other place talked about this timer. Do you need to put it into FSM? 4.7.3. DataChannelDeadInterval The minimum time, in seconds, a WTP MUST wait without having received a Data Channel Keep Alive packet before the destination for the Data Channel Keep Alive packets may be considered dead. The value of this timer MUST be no less than 2*DataChannelKeepAlive seconds and no greater that 240 seconds. Default: 5 We have set the default of DataChannelKeepAlive to be 30. So here we need to set DataChannelDeadInterval to be 60. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Jul 8 10:43:08 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6065E3A6909 for ; Tue, 8 Jul 2008 10:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKqL8aePp--p for ; Tue, 8 Jul 2008 10:43:07 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 689583A68D9 for ; Tue, 8 Jul 2008 10:43:07 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F3EAC433DC5 for ; Tue, 8 Jul 2008 10:43:14 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id CAE3E440114 for ; Tue, 8 Jul 2008 10:42:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8A77134AC08C for ; Tue, 8 Jul 2008 10:42:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3362234AC0A3 for ; Tue, 8 Jul 2008 10:42:12 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 8 Jul 2008 10:42:12 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so3058182wfc.11 for ; Tue, 08 Jul 2008 10:42:11 -0700 (PDT) Received: by 10.142.82.6 with SMTP id f6mr1902925wfb.43.1215538931757; Tue, 08 Jul 2008 10:42:11 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Tue, 8 Jul 2008 10:42:11 -0700 (PDT) Message-ID: Date: Tue, 8 Jul 2008 10:42:11 -0700 From: "Yong Zhang" To: capwap@frascone.com MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [Capwap] New Issue 147: Timer Issues (Pat Calhoun (pacalhou)) 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 Here in AC should be start the DTLSSessionDelete timer, right? Run to DTLS Teardown (p): This state transition occurs when an error has occurred in the DTLS stack, causing the DTLS session to be torn down. WTP: The WTP enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The WTP also transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7). The WTP starts the DTLSSessionDelete timer (see Section 4.7.6). AC: The AC enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The AC MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The AC transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7). This state transition also occurs when the AC's EchoInterval timer (see Section 4.7.7) or DTLSSessionDelete timer (see Section 4.7.6) expires. [...] _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 8 13:32:08 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F3273A6869 for ; Tue, 8 Jul 2008 13:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkQmRBy9t1QF for ; Tue, 8 Jul 2008 13:32:07 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 6D6263A6B19 for ; Tue, 8 Jul 2008 13:32:07 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A72F9439FC8 for ; Tue, 8 Jul 2008 13:32:17 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 73591440113 for ; Tue, 8 Jul 2008 13:32:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3180234AC08E for ; Tue, 8 Jul 2008 13:32:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id B3C9934AC09F for ; Tue, 8 Jul 2008 13:31:47 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 8 Jul 2008 13:31:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,326,1212364800"; d="scan'208";a="50315203" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 08 Jul 2008 20:31:35 +0000 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/8.12.11) with ESMTP id m68KVZF3012096; Tue, 8 Jul 2008 13:31:35 -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.13.8/8.13.8) with ESMTP id m68KVY5b024228; Tue, 8 Jul 2008 20:31:35 GMT 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, 8 Jul 2008 13:31:34 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 13:30:35 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D1D99@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New Issue 147: Timer Issues (Pat Calhoun (pacalhou)) Thread-Index: AcjhIiEeeC5h61+bT9y7WnI6qYDnogAF1FmQ References: From: "Pat Calhoun (pacalhou)" To: "Yong Zhang" , X-OriginalArrivalTime: 08 Jul 2008 20:31:34.0680 (UTC) FILETIME=[9D32D980:01C8E139] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Capwap] New Issue 147: Timer Issues (Pat Calhoun (pacalhou)) 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 Yes, I sent this fix already. PatC -----Original Message----- From: Yong Zhang [mailto:yozhang@gmail.com] Sent: Tuesday, July 08, 2008 10:42 AM To: capwap@frascone.com Subject: Re: [Capwap] New Issue 147: Timer Issues (Pat Calhoun (pacalhou)) Here in AC should be start the DTLSSessionDelete timer, right? Run to DTLS Teardown (p): This state transition occurs when an error has occurred in the DTLS stack, causing the DTLS session to be torn down. WTP: The WTP enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The WTP also transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7). The WTP starts the DTLSSessionDelete timer (see Section 4.7.6). AC: The AC enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The AC MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The AC transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7). This state transition also occurs when the AC's EchoInterval timer (see Section 4.7.7) or DTLSSessionDelete timer (see Section 4.7.6) expires. [...] _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 8 15:02:33 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 212253A694E for ; Tue, 8 Jul 2008 15:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11A-CJ7LUHPm for ; Tue, 8 Jul 2008 15:02:32 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 491673A677E for ; Tue, 8 Jul 2008 15:02:32 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8B44C433D62 for ; Tue, 8 Jul 2008 15:02:38 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 9FF80440125 for ; Tue, 8 Jul 2008 15:01:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 1BAE434AC072 for ; Tue, 8 Jul 2008 15:01:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 99F5934AC002 for ; Tue, 8 Jul 2008 15:01:50 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.72 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 8 Jul 2008 15:01:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,326,1212364800"; d="scan'208";a="85884454" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 08 Jul 2008 22:01:46 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m68M1jgk006626 for ; Tue, 8 Jul 2008 15:01:45 -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.13.8/8.13.8) with ESMTP id m68M1jjn019287 for ; Tue, 8 Jul 2008 22:01:46 GMT Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jul 2008 15:01:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 15:01:44 -0700 Message-ID: <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com> In-Reply-To: <458C3B75.6090006@cs.umd.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: crypto algorithms for DTLS thread-index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1Hiw References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com> <458C3B75.6090006@cs.umd.edu> From: "Abhijit Choudhury (achoudhu)" To: X-OriginalArrivalTime: 08 Jul 2008 22:01:45.0849 (UTC) FILETIME=[3681B690:01C8E146] Authentication-Results: sj-dkim-4; header.From=achoudhu@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Capwap] crypto algorithms for 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 Folks, The issue of using AES-GCM as a cipher-suite for CAPWAP/DTLS was discussed in the list about a year ago. (Please refer to CAPWAP issue 7 (http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue7) Due to the use of DTLS, we were stuck with TLS ciphersuites. To use GCM we would require a TLS GCM ciphersuite. We discussed this at an ad-hoc meeting, and decided to defer this feature, as GCM was not a TLS ciphersuite, and there was no document to reference. However, since that time, use of AES-GCM has been approved in the TLS working group, and we have an approved draft https://datatracker.ietf.org/idtracker/draft-ietf-tls-rsa-aes-gcm/ As noted in the original email, there is a lot of momentum behind this crypto algorithm, and it results in significant improvements in throughput in either HW or SW implementations. Could we address this issue in the current spec and make AES-GCM an ciphersuite that can be used with CAPWAP/DTLS ? 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 Tue Jul 8 15:42:02 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FA473A69F1 for ; Tue, 8 Jul 2008 15:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOcOOUDFwqLa for ; Tue, 8 Jul 2008 15:42:01 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id AD5EC3A687A for ; Tue, 8 Jul 2008 15:42:01 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 40E861C40546 for ; Tue, 8 Jul 2008 15:42:12 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 49D0E440115 for ; Tue, 8 Jul 2008 15:42:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 24FFC34AC063 for ; Tue, 8 Jul 2008 15:42:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id A17D934AC060 for ; Tue, 8 Jul 2008 15:42:01 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from mail.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by mx1.tigertech.net (Postfix) with SMTP for ; Tue, 8 Jul 2008 15:42:01 -0700 (PDT) Received: from aruba-mx2.arubanetworks.com ([10.1.1.83]) by mail.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jul 2008 15:42:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 15:41:51 -0700 Message-ID: <6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com> In-Reply-To: <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS Thread-Index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JA= References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com> From: "Scott Kelly" To: "Abhijit Choudhury (achoudhu)" X-OriginalArrivalTime: 08 Jul 2008 22:42:00.0933 (UTC) FILETIME=[D6024950:01C8E14B] Cc: capwap Subject: Re: [Capwap] crypto algorithms for 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 Hi Abhijit, > > Folks, > > The issue of using AES-GCM as a cipher-suite for CAPWAP/DTLS > was discussed in the list about a year ago. (Please refer > to CAPWAP issue 7 > (http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue7) > > Due to the use of DTLS, we were stuck with TLS ciphersuites. > To use GCM we would require a TLS GCM ciphersuite. We discussed this > at an ad-hoc meeting, and decided to defer this feature, as > GCM was not > a TLS ciphersuite, and there was no document to reference. > > However, since that time, use of AES-GCM has been approved in the > TLS working group, and we have an approved draft > https://datatracker.ietf.org/idtracker/draft-ietf-tls-rsa-aes-gcm/ > > As noted in the original email, there is a lot of momentum > behind this crypto algorithm, and it results in significant > improvements in throughput in either HW or SW implementations. > > Could we address this issue in the current spec and make > AES-GCM an ciphersuite that can be used with CAPWAP/DTLS ? I have no objections to adding support for AES-GCM as a MAY. The original proposal suggested making it mandatory to implement, but given the current lack of support in commodity crypto HW, I don't think this would be appropriate at this time. --Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 8 15:43:29 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7613A6B25 for ; Tue, 8 Jul 2008 15:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BnA55KJAJpn for ; Tue, 8 Jul 2008 15:43:29 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 092623A6839 for ; Tue, 8 Jul 2008 15:43:29 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 980431C40F68 for ; Tue, 8 Jul 2008 15:43:39 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 2CEFE440115 for ; Tue, 8 Jul 2008 15:43:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id EBA7434AC070 for ; Tue, 8 Jul 2008 15:43:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 494A334AC004 for ; Tue, 8 Jul 2008 15:43:16 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from yx-out-1718.google.com (yx-out-1718.google.com [74.125.44.157]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 8 Jul 2008 15:43:15 -0700 (PDT) Received: by yx-out-1718.google.com with SMTP id 3so644964yxi.80 for ; Tue, 08 Jul 2008 15:43:15 -0700 (PDT) Received: by 10.142.232.20 with SMTP id e20mr2007446wfh.134.1215556994506; Tue, 08 Jul 2008 15:43:14 -0700 (PDT) Received: by 10.143.3.6 with HTTP; Tue, 8 Jul 2008 15:43:14 -0700 (PDT) Message-ID: Date: Tue, 8 Jul 2008 15:43:14 -0700 From: "Yong Zhang" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2060D1D99@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <4FF84B0BC277FF45AA27FE969DD956A2060D1D99@xmb-sjc-235.amer.cisco.com> Cc: capwap@frascone.com Subject: Re: [Capwap] New Issue 147: Timer Issues (Pat Calhoun (pacalhou)) 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 This change is OK for me. Yong On Tue, Jul 8, 2008 at 1:30 PM, Pat Calhoun (pacalhou) wrote: > Yes, I sent this fix already. > > PatC > > -----Original Message----- > From: Yong Zhang [mailto:yozhang@gmail.com] > Sent: Tuesday, July 08, 2008 10:42 AM > To: capwap@frascone.com > Subject: Re: [Capwap] New Issue 147: Timer Issues (Pat Calhoun > (pacalhou)) > > Here in AC should be start the DTLSSessionDelete timer, right? > > Run to DTLS Teardown (p): This state transition occurs when an error > has occurred in the DTLS stack, causing the DTLS session to be > torn down. > > WTP: The WTP enters this state when it receives one of the > following DTLS notifications: DTLSAborted, > DTLSReassemblyFailure or DTLSPeerDisconnect (see > Section 2.3.2.2). The WTP MAY tear down the DTLS session if it > receives frequent DTLSDecapFailure notifications. The WTP also > transitions to this state if the underlying reliable > transport's RetransmitCount counter has reached the > MaxRetransmit variable (see Section 4.7). The WTP starts the > DTLSSessionDelete timer (see Section 4.7.6). > > AC: The AC enters this state when it receives one of the > following DTLS notifications: DTLSAborted, > DTLSReassemblyFailure or DTLSPeerDisconnect (see > Section 2.3.2.2). The AC MAY tear down the DTLS session if it > receives frequent DTLSDecapFailure notifications. The AC > transitions to this state if the underlying reliable > transport's RetransmitCount counter has reached the > MaxRetransmit variable (see Section 4.7). This state > transition also occurs when the AC's EchoInterval timer (see > Section 4.7.7) or DTLSSessionDelete timer (see Section 4.7.6) > expires. > [...] > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 8 15:57:46 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB0D13A6935 for ; Tue, 8 Jul 2008 15:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJUBE5MKTucz for ; Tue, 8 Jul 2008 15:57:37 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id DEBC53A6839 for ; Tue, 8 Jul 2008 15:57:37 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7EFAE1C40F83 for ; Tue, 8 Jul 2008 15:57:48 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 6813744011B for ; Tue, 8 Jul 2008 15:57:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 286D934AC00D for ; Tue, 8 Jul 2008 15:57:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0B4FE34AC075 for ; Tue, 8 Jul 2008 15:57:36 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 8 Jul 2008 15:57:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,326,1212364800"; d="scan'208";a="63814619" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 08 Jul 2008 22:57:30 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m68MvUgG030051; Tue, 8 Jul 2008 15:57:30 -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.13.8/8.13.8) with ESMTP id m68MvU3m012230; Tue, 8 Jul 2008 22:57:30 GMT 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, 8 Jul 2008 15:57:30 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 15:56:59 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> In-Reply-To: <6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS Thread-Index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gA== References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com> From: "Pat Calhoun (pacalhou)" To: "Scott Kelly" , "Abhijit Choudhury (achoudhu)" X-OriginalArrivalTime: 08 Jul 2008 22:57:30.0169 (UTC) FILETIME=[FFE07290:01C8E14D] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: capwap Subject: Re: [Capwap] crypto algorithms for 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 CAPWAP Chairs, I am done with the edits, and ready to submit the spec for the WG Last Call. This is a new feature, and we had agreed to defer to the next version of the protocol. However, the IETF has completed the long pole, and the change, as a MAY, is fairly minor. What would you recommend? PatC -----Original Message----- From: Scott Kelly [mailto:skelly@arubanetworks.com] Sent: Tuesday, July 08, 2008 3:42 PM To: Abhijit Choudhury (achoudhu) Cc: capwap Subject: Re: [Capwap] crypto algorithms for DTLS Hi Abhijit, > > Folks, > > The issue of using AES-GCM as a cipher-suite for CAPWAP/DTLS was > discussed in the list about a year ago. (Please refer to CAPWAP issue > 7 > (http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue7) > > Due to the use of DTLS, we were stuck with TLS ciphersuites. > To use GCM we would require a TLS GCM ciphersuite. We discussed this > at an ad-hoc meeting, and decided to defer this feature, as GCM was > not a TLS ciphersuite, and there was no document to reference. > > However, since that time, use of AES-GCM has been approved in the TLS > working group, and we have an approved draft > https://datatracker.ietf.org/idtracker/draft-ietf-tls-rsa-aes-gcm/ > > As noted in the original email, there is a lot of momentum behind this > crypto algorithm, and it results in significant improvements in > throughput in either HW or SW implementations. > > Could we address this issue in the current spec and make AES-GCM an > ciphersuite that can be used with CAPWAP/DTLS ? I have no objections to adding support for AES-GCM as a MAY. The original proposal suggested making it mandatory to implement, but given the current lack of support in commodity crypto HW, I don't think this would be appropriate at this time. --Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 8 16:05:37 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3F863A6935 for ; Tue, 8 Jul 2008 16:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gO80tDm3E+vR for ; Tue, 8 Jul 2008 16:05:37 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id EC7DF3A6839 for ; Tue, 8 Jul 2008 16:05:36 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 921A81C40F6C for ; Tue, 8 Jul 2008 16:05:47 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 53ACE44013E for ; Tue, 8 Jul 2008 16:05:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2222E34AC070 for ; Tue, 8 Jul 2008 16:05:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 834F234AC061 for ; Tue, 8 Jul 2008 16:05:36 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 8 Jul 2008 16:05:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,326,1212364800"; d="scan'208";a="63817577" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 08 Jul 2008 23:05:36 +0000 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/8.12.11) with ESMTP id m68N5aGe003533; Tue, 8 Jul 2008 16:05:36 -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.13.8/8.13.8) with ESMTP id m68N5a2x007150; Tue, 8 Jul 2008 23:05:36 GMT 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, 8 Jul 2008 16:05:35 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 16:05:31 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS Thread-Index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbA References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Scott Kelly" , "Abhijit Choudhury (achoudhu)" X-OriginalArrivalTime: 08 Jul 2008 23:05:35.0940 (UTC) FILETIME=[216B3840:01C8E14F] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap Subject: Re: [Capwap] crypto algorithms for 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 Oh, and just to make sure, if we were to go ahead with this, the following cipher suites would be added: TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_DH_RSA_WITH_AES_256_GCM_SHA384 Right? PatC -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Tuesday, July 08, 2008 3:57 PM To: Scott Kelly; Abhijit Choudhury (achoudhu) Cc: capwap Subject: Re: [Capwap] crypto algorithms for DTLS CAPWAP Chairs, I am done with the edits, and ready to submit the spec for the WG Last Call. This is a new feature, and we had agreed to defer to the next version of the protocol. However, the IETF has completed the long pole, and the change, as a MAY, is fairly minor. What would you recommend? PatC -----Original Message----- From: Scott Kelly [mailto:skelly@arubanetworks.com] Sent: Tuesday, July 08, 2008 3:42 PM To: Abhijit Choudhury (achoudhu) Cc: capwap Subject: Re: [Capwap] crypto algorithms for DTLS Hi Abhijit, > > Folks, > > The issue of using AES-GCM as a cipher-suite for CAPWAP/DTLS was > discussed in the list about a year ago. (Please refer to CAPWAP issue > 7 > (http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue7) > > Due to the use of DTLS, we were stuck with TLS ciphersuites. > To use GCM we would require a TLS GCM ciphersuite. We discussed this > at an ad-hoc meeting, and decided to defer this feature, as GCM was > not a TLS ciphersuite, and there was no document to reference. > > However, since that time, use of AES-GCM has been approved in the TLS > working group, and we have an approved draft > https://datatracker.ietf.org/idtracker/draft-ietf-tls-rsa-aes-gcm/ > > As noted in the original email, there is a lot of momentum behind this > crypto algorithm, and it results in significant improvements in > throughput in either HW or SW implementations. > > Could we address this issue in the current spec and make AES-GCM an > ciphersuite that can be used with CAPWAP/DTLS ? I have no objections to adding support for AES-GCM as a MAY. The original proposal suggested making it mandatory to implement, but given the current lack of support in commodity crypto HW, I don't think this would be appropriate at this time. --Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Jul 8 16:17:45 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE3BF28C36D for ; Tue, 8 Jul 2008 16:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsmxTsVfZMIv for ; Tue, 8 Jul 2008 16:17:44 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 948D928C29F for ; Tue, 8 Jul 2008 16:17:44 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3ED1E1C40546 for ; Tue, 8 Jul 2008 16:17:52 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id E2D2D44011B for ; Tue, 8 Jul 2008 16:17:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id B623334AC075 for ; Tue, 8 Jul 2008 16:17:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4BAC534AC070 for ; Tue, 8 Jul 2008 16:17:41 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.233 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 8 Jul 2008 16:17:41 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m68NHQbu026164; Wed, 9 Jul 2008 02:17:33 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jul 2008 02:17:31 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jul 2008 18:17:29 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 18:17:28 -0500 Message-ID: <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS Thread-Index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4A= References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com><4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> From: To: , , X-OriginalArrivalTime: 08 Jul 2008 23:17:29.0535 (UTC) FILETIME=[CAC12CF0:01C8E150] X-Nokia-AV: Clean Cc: capwap@frascone.com Subject: Re: [Capwap] crypto algorithms for 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 Hi All, Are there any objections in the WG to adding the following cipher suites: TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_DH_RSA_WITH_AES_256_GCM_SHA384 to the base spec as a MAY? If not, based on the list discussion and approved draft status of draft-ietf-tls-rsa-aes-gcm-03.txt, I support including these cipher suites as a MAY in the next(last) WGLC. Best Regards, Dorothy > -----Original Message----- > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Tuesday, July 08, 2008 4:06 PM > To: Scott Kelly; Abhijit Choudhury (achoudhu) > Cc: capwap > Subject: Re: [Capwap] crypto algorithms for DTLS > > Oh, and just to make sure, if we were to go ahead with this, > the following cipher suites would be added: > > TLS_RSA_WITH_AES_128_GCM_SHA256 > TLS_DH_RSA_WITH_AES_256_GCM_SHA384 > > Right? > > PatC > > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Tuesday, July 08, 2008 3:57 PM > To: Scott Kelly; Abhijit Choudhury (achoudhu) > Cc: capwap > Subject: Re: [Capwap] crypto algorithms for DTLS > > CAPWAP Chairs, > > I am done with the edits, and ready to submit the spec for > the WG Last Call. This is a new feature, and we had agreed to > defer to the next version of the protocol. However, the IETF > has completed the long pole, and the change, as a MAY, is > fairly minor. What would you recommend? > > PatC > > -----Original Message----- > From: Scott Kelly [mailto:skelly@arubanetworks.com] > Sent: Tuesday, July 08, 2008 3:42 PM > To: Abhijit Choudhury (achoudhu) > Cc: capwap > Subject: Re: [Capwap] crypto algorithms for DTLS > > Hi Abhijit, > > > > > Folks, > > > > The issue of using AES-GCM as a cipher-suite for CAPWAP/DTLS was > > discussed in the list about a year ago. (Please refer to > CAPWAP issue > > > 7 > > (http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue7) > > > > Due to the use of DTLS, we were stuck with TLS ciphersuites. > > To use GCM we would require a TLS GCM ciphersuite. We > discussed this > > at an ad-hoc meeting, and decided to defer this feature, as GCM was > > not a TLS ciphersuite, and there was no document to reference. > > > > However, since that time, use of AES-GCM has been approved > in the TLS > > working group, and we have an approved draft > > https://datatracker.ietf.org/idtracker/draft-ietf-tls-rsa-aes-gcm/ > > > > As noted in the original email, there is a lot of momentum > behind this > > > crypto algorithm, and it results in significant improvements in > > throughput in either HW or SW implementations. > > > > Could we address this issue in the current spec and make AES-GCM an > > ciphersuite that can be used with CAPWAP/DTLS ? > > I have no objections to adding support for AES-GCM as a MAY. > The original proposal suggested making it mandatory to > implement, but given the current lack of support in commodity > crypto HW, I don't think this would be appropriate at this time. > > --Scott > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/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 Jul 9 11:01:04 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814AF3A6A22 for ; Wed, 9 Jul 2008 11:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLvkje8xcmCS for ; Wed, 9 Jul 2008 11:01:03 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 7A08F3A6959 for ; Wed, 9 Jul 2008 11:01:03 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 458A41C40F5E for ; Wed, 9 Jul 2008 11:01:16 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 5E7BA440130 for ; Wed, 9 Jul 2008 11:01:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 40DC834AC0AA for ; Wed, 9 Jul 2008 11:00:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3C8D034AC086 for ; Wed, 9 Jul 2008 11:00:40 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.68.10.87 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 9 Jul 2008 11:00:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,332,1212364800"; d="scan'208";a="36119260" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 09 Jul 2008 18:00:38 +0000 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/8.12.11) with ESMTP id m69I0cKm017536; Wed, 9 Jul 2008 11:00:38 -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.13.8/8.13.8) with ESMTP id m69I0cM7029767; Wed, 9 Jul 2008 18:00:38 GMT Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 11:00:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 11:00:28 -0700 Message-ID: <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED1ED@xmb-sjc-223.amer.cisco.com> In-Reply-To: <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS thread-index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4AAJxBJoA== References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com><4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> From: "Abhijit Choudhury (achoudhu)" To: , "Pat Calhoun (pacalhou)" , , "Joseph Salowey (jsalowey)" X-OriginalArrivalTime: 09 Jul 2008 18:00:31.0967 (UTC) FILETIME=[ADD056F0:01C8E1ED] Authentication-Results: sj-dkim-2; header.From=achoudhu@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] crypto algorithms for 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 I'm okay with adding AES-GCM support as a MAY. However, I'd suggest we add the following ciphers: TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 Also, in the current spec, shouldn't we be specifying DHE instead of DH in the cipher suite recommendations. Scott, Charles, Joe: any thoughts on this ? Thanks, Abhijit -----Original Message----- From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] Sent: Tuesday, July 08, 2008 4:17 PM To: Pat Calhoun (pacalhou); skelly@arubanetworks.com; Abhijit Choudhury (achoudhu) Cc: capwap@frascone.com Subject: RE: [Capwap] crypto algorithms for DTLS Hi All, Are there any objections in the WG to adding the following cipher suites: TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_DH_RSA_WITH_AES_256_GCM_SHA384 to the base spec as a MAY? If not, based on the list discussion and approved draft status of draft-ietf-tls-rsa-aes-gcm-03.txt, I support including these cipher suites as a MAY in the next(last) WGLC. Best Regards, Dorothy > -----Original Message----- > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Tuesday, July 08, 2008 4:06 PM > To: Scott Kelly; Abhijit Choudhury (achoudhu) > Cc: capwap > Subject: Re: [Capwap] crypto algorithms for DTLS > > Oh, and just to make sure, if we were to go ahead with this, the > following cipher suites would be added: > > TLS_RSA_WITH_AES_128_GCM_SHA256 > TLS_DH_RSA_WITH_AES_256_GCM_SHA384 > > Right? > > PatC > > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Tuesday, July 08, 2008 3:57 PM > To: Scott Kelly; Abhijit Choudhury (achoudhu) > Cc: capwap > Subject: Re: [Capwap] crypto algorithms for DTLS > > CAPWAP Chairs, > > I am done with the edits, and ready to submit the spec for the WG Last > Call. This is a new feature, and we had agreed to defer to the next > version of the protocol. However, the IETF has completed the long > pole, and the change, as a MAY, is fairly minor. What would you > recommend? > > PatC > > -----Original Message----- > From: Scott Kelly [mailto:skelly@arubanetworks.com] > Sent: Tuesday, July 08, 2008 3:42 PM > To: Abhijit Choudhury (achoudhu) > Cc: capwap > Subject: Re: [Capwap] crypto algorithms for DTLS > > Hi Abhijit, > > > > > Folks, > > > > The issue of using AES-GCM as a cipher-suite for CAPWAP/DTLS was > > discussed in the list about a year ago. (Please refer to > CAPWAP issue > > > 7 > > (http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue7) > > > > Due to the use of DTLS, we were stuck with TLS ciphersuites. > > To use GCM we would require a TLS GCM ciphersuite. We > discussed this > > at an ad-hoc meeting, and decided to defer this feature, as GCM was > > not a TLS ciphersuite, and there was no document to reference. > > > > However, since that time, use of AES-GCM has been approved > in the TLS > > working group, and we have an approved draft > > https://datatracker.ietf.org/idtracker/draft-ietf-tls-rsa-aes-gcm/ > > > > As noted in the original email, there is a lot of momentum > behind this > > > crypto algorithm, and it results in significant improvements in > > throughput in either HW or SW implementations. > > > > Could we address this issue in the current spec and make AES-GCM an > > ciphersuite that can be used with CAPWAP/DTLS ? > > I have no objections to adding support for AES-GCM as a MAY. > The original proposal suggested making it mandatory to implement, but > given the current lack of support in commodity crypto HW, I don't > think this would be appropriate at this time. > > --Scott > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/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 Jul 9 11:10:56 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D15E63A6820 for ; Wed, 9 Jul 2008 11:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8FGSlCOFEHH for ; Wed, 9 Jul 2008 11:10:55 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 75F433A6901 for ; Wed, 9 Jul 2008 11:10:55 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5A6221C40F9B for ; Wed, 9 Jul 2008 11:11:08 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 56221440139 for ; Wed, 9 Jul 2008 11:10:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 1825534AC164 for ; Wed, 9 Jul 2008 11:10:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 296F034AC2A3 for ; Wed, 9 Jul 2008 11:08:10 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from mail.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by mx1.tigertech.net (Postfix) with SMTP for ; Wed, 9 Jul 2008 11:08:08 -0700 (PDT) Received: from aruba-mx2.arubanetworks.com ([10.1.1.83]) by mail.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jul 2008 11:08:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 11:07:55 -0700 Message-ID: <6F22142CC0DEBE478C659612F9CFCA50019052D2@aruba-mx2.arubanetworks.com> In-Reply-To: <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED1ED@xmb-sjc-223.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS Thread-Index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4AAJxBJoAAAu+tg References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com><4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED1ED@xmb-sjc-223.amer.cisco.com> From: "Scott Kelly" To: "Abhijit Choudhury (achoudhu)" , , "Pat Calhoun (pacalhou)" , "Joseph Salowey (jsalowey)" X-OriginalArrivalTime: 09 Jul 2008 18:08:07.0403 (UTC) FILETIME=[BD465BB0:01C8E1EE] Cc: capwap@frascone.com Subject: Re: [Capwap] crypto algorithms for 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 Hi Abhijit, Yes, it should be DHE - this has come up several times now, but keeps falling through the cracks somehow. --Scott > -----Original Message----- > From: Abhijit Choudhury (achoudhu) [mailto:achoudhu@cisco.com] > Sent: Wednesday, July 09, 2008 11:00 AM > To: Dorothy.Gellert@nokia.com; Pat Calhoun (pacalhou); Scott > Kelly; Joseph Salowey (jsalowey) > Cc: capwap@frascone.com > Subject: RE: [Capwap] crypto algorithms for DTLS > > I'm okay with adding AES-GCM support as a MAY. > However, I'd suggest we add the following ciphers: > > TLS_RSA_WITH_AES_128_GCM_SHA256 > TLS_RSA_WITH_AES_256_GCM_SHA384 > > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 > > > Also, in the current spec, shouldn't we be specifying > DHE instead of DH in the cipher suite recommendations. > > Scott, Charles, Joe: any thoughts on this ? > > Thanks, > Abhijit > > > > -----Original Message----- > From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] > Sent: Tuesday, July 08, 2008 4:17 PM > To: Pat Calhoun (pacalhou); skelly@arubanetworks.com; Abhijit > Choudhury > (achoudhu) > Cc: capwap@frascone.com > Subject: RE: [Capwap] crypto algorithms for DTLS > > Hi All, > > Are there any objections in the WG to adding the following cipher > suites: > TLS_RSA_WITH_AES_128_GCM_SHA256 > TLS_DH_RSA_WITH_AES_256_GCM_SHA384 to the base spec as a MAY? > > If not, based on the list discussion and approved draft status of > draft-ietf-tls-rsa-aes-gcm-03.txt, I support including these cipher > suites as a MAY in the next(last) WGLC. > > Best Regards, > Dorothy > > > > -----Original Message----- > > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Tuesday, July 08, 2008 4:06 PM > > To: Scott Kelly; Abhijit Choudhury (achoudhu) > > Cc: capwap > > Subject: Re: [Capwap] crypto algorithms for DTLS > > > > Oh, and just to make sure, if we were to go ahead with this, the > > following cipher suites would be added: > > > > TLS_RSA_WITH_AES_128_GCM_SHA256 > > TLS_DH_RSA_WITH_AES_256_GCM_SHA384 > > > > Right? > > > > PatC > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) > > Sent: Tuesday, July 08, 2008 3:57 PM > > To: Scott Kelly; Abhijit Choudhury (achoudhu) > > Cc: capwap > > Subject: Re: [Capwap] crypto algorithms for DTLS > > > > CAPWAP Chairs, > > > > I am done with the edits, and ready to submit the spec for > the WG Last > > > Call. This is a new feature, and we had agreed to defer to the next > > version of the protocol. However, the IETF has completed the long > > pole, and the change, as a MAY, is fairly minor. What would you > > recommend? > > > > PatC > > > > -----Original Message----- > > From: Scott Kelly [mailto:skelly@arubanetworks.com] > > Sent: Tuesday, July 08, 2008 3:42 PM > > To: Abhijit Choudhury (achoudhu) > > Cc: capwap > > Subject: Re: [Capwap] crypto algorithms for DTLS > > > > Hi Abhijit, > > > > > > > > Folks, > > > > > > The issue of using AES-GCM as a cipher-suite for CAPWAP/DTLS was > > > discussed in the list about a year ago. (Please refer to > > CAPWAP issue > > > > > 7 > > > (http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue7) > > > > > > Due to the use of DTLS, we were stuck with TLS ciphersuites. > > > To use GCM we would require a TLS GCM ciphersuite. We > > discussed this > > > at an ad-hoc meeting, and decided to defer this feature, > as GCM was > > > not a TLS ciphersuite, and there was no document to reference. > > > > > > However, since that time, use of AES-GCM has been approved > > in the TLS > > > working group, and we have an approved draft > > > https://datatracker.ietf.org/idtracker/draft-ietf-tls-rsa-aes-gcm/ > > > > > > As noted in the original email, there is a lot of momentum > > behind this > > > > > crypto algorithm, and it results in significant improvements in > > > throughput in either HW or SW implementations. > > > > > > Could we address this issue in the current spec and make > AES-GCM an > > > ciphersuite that can be used with CAPWAP/DTLS ? > > > > I have no objections to adding support for AES-GCM as a MAY. > > The original proposal suggested making it mandatory to > implement, but > > given the current lack of support in commodity crypto HW, I don't > > think this would be appropriate at this time. > > > > --Scott > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/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 Jul 9 11:34:05 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EFDD3A696C for ; Wed, 9 Jul 2008 11:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvHxdnEkXBqR for ; Wed, 9 Jul 2008 11:34:04 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2C2EB28C204 for ; Wed, 9 Jul 2008 11:34:04 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D9ABD43A230 for ; Wed, 9 Jul 2008 11:34:16 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 4A1F744014E for ; Wed, 9 Jul 2008 11:23:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 51BBA34AC061 for ; Wed, 9 Jul 2008 11:23:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 604FE3610002 for ; Wed, 9 Jul 2008 11:23:01 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 9 Jul 2008 11:23:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,332,1212364800"; d="scan'208";a="124546147" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 09 Jul 2008 18:23:01 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m69IN1tQ022802; Wed, 9 Jul 2008 11:23: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.13.8/8.13.8) with ESMTP id m69IN1br021389; Wed, 9 Jul 2008 18:23:01 GMT Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 11:23:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 11:23:00 -0700 Message-ID: <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED20E@xmb-sjc-223.amer.cisco.com> In-Reply-To: <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS thread-index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4AAJ/T4MA== References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com><4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> From: "Abhijit Choudhury (achoudhu)" To: , "Pat Calhoun (pacalhou)" , , "Joseph Salowey (jsalowey)" X-OriginalArrivalTime: 09 Jul 2008 18:23:00.0989 (UTC) FILETIME=[D1E4C2D0:01C8E1F0] Authentication-Results: sj-dkim-4; header.From=achoudhu@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] crypto algorithms for 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 Hi Dorothy, Please note that AES-GCM requires TLS1.2 which is currently in AUTH48 state in the RFC-editors queue and should be published shortly. DTLS1.2, which is based on TLS1.2, is working group item and will most likely make it to last call after next IETF. I would suggest we reference TLS1.2 and add the AES-GCM ciphersuites as MAY. Also, in order to ensure that CAPWAP track DTLS better, we should change the text in section 2.4.4.1 from "Note that only block ciphers are currently recommended for use with DTLS. To understand the reasoning behind this, see [DTLS-DESIGN]." To "CAPWAP implementations only use cipher suites that are recommended for use with DTLS. Note that certain stream ciphers, such as RC4, that cannot be randomly accessed may not be used with DTLS." Thoughts ? Abhijit -----Original Message----- From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] Sent: Tuesday, July 08, 2008 4:17 PM To: Pat Calhoun (pacalhou); skelly@arubanetworks.com; Abhijit Choudhury (achoudhu) Cc: capwap@frascone.com Subject: RE: [Capwap] crypto algorithms for DTLS Hi All, Are there any objections in the WG to adding the following cipher suites: TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_DH_RSA_WITH_AES_256_GCM_SHA384 to the base spec as a MAY? If not, based on the list discussion and approved draft status of draft-ietf-tls-rsa-aes-gcm-03.txt, I support including these cipher suites as a MAY in the next(last) WGLC. Best Regards, Dorothy > -----Original Message----- > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Tuesday, July 08, 2008 4:06 PM > To: Scott Kelly; Abhijit Choudhury (achoudhu) > Cc: capwap > Subject: Re: [Capwap] crypto algorithms for DTLS > > Oh, and just to make sure, if we were to go ahead with this, the > following cipher suites would be added: > > TLS_RSA_WITH_AES_128_GCM_SHA256 > TLS_DH_RSA_WITH_AES_256_GCM_SHA384 > > Right? > > PatC > > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Tuesday, July 08, 2008 3:57 PM > To: Scott Kelly; Abhijit Choudhury (achoudhu) > Cc: capwap > Subject: Re: [Capwap] crypto algorithms for DTLS > > CAPWAP Chairs, > > I am done with the edits, and ready to submit the spec for the WG Last > Call. This is a new feature, and we had agreed to defer to the next > version of the protocol. However, the IETF has completed the long > pole, and the change, as a MAY, is fairly minor. What would you > recommend? > > PatC > > -----Original Message----- > From: Scott Kelly [mailto:skelly@arubanetworks.com] > Sent: Tuesday, July 08, 2008 3:42 PM > To: Abhijit Choudhury (achoudhu) > Cc: capwap > Subject: Re: [Capwap] crypto algorithms for DTLS > > Hi Abhijit, > > > > > Folks, > > > > The issue of using AES-GCM as a cipher-suite for CAPWAP/DTLS was > > discussed in the list about a year ago. (Please refer to > CAPWAP issue > > > 7 > > (http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue7) > > > > Due to the use of DTLS, we were stuck with TLS ciphersuites. > > To use GCM we would require a TLS GCM ciphersuite. We > discussed this > > at an ad-hoc meeting, and decided to defer this feature, as GCM was > > not a TLS ciphersuite, and there was no document to reference. > > > > However, since that time, use of AES-GCM has been approved > in the TLS > > working group, and we have an approved draft > > https://datatracker.ietf.org/idtracker/draft-ietf-tls-rsa-aes-gcm/ > > > > As noted in the original email, there is a lot of momentum > behind this > > > crypto algorithm, and it results in significant improvements in > > throughput in either HW or SW implementations. > > > > Could we address this issue in the current spec and make AES-GCM an > > ciphersuite that can be used with CAPWAP/DTLS ? > > I have no objections to adding support for AES-GCM as a MAY. > The original proposal suggested making it mandatory to implement, but > given the current lack of support in commodity crypto HW, I don't > think this would be appropriate at this time. > > --Scott > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/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 Jul 9 11:38:42 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C34628C205 for ; Wed, 9 Jul 2008 11:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJ4mQkjxRGJX for ; Wed, 9 Jul 2008 11:38:41 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 54D013A6AB8 for ; Wed, 9 Jul 2008 11:38:41 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 47E531C4101D for ; Wed, 9 Jul 2008 11:38:54 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 571C7440130 for ; Wed, 9 Jul 2008 11:38:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id CC39534AC06F for ; Wed, 9 Jul 2008 11:38:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C709334AC023 for ; Wed, 9 Jul 2008 11:38:42 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.68.10.87 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 9 Jul 2008 11:38:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,332,1212364800"; d="scan'208";a="36132187" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 09 Jul 2008 18:38:42 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m69Icgao032645 for ; Wed, 9 Jul 2008 11:38:42 -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.13.8/8.13.8) with ESMTP id m69Icgvj017250 for ; Wed, 9 Jul 2008 18:38:42 GMT Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 11:38:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 11:38:41 -0700 Message-ID: <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED231@xmb-sjc-223.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Capwap] crypto algorithms for DTLS thread-index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4AAJxBJoAAAkLegAAFD6tA= From: "Abhijit Choudhury (achoudhu)" To: X-OriginalArrivalTime: 09 Jul 2008 18:38:42.0099 (UTC) FILETIME=[02D6C030:01C8E1F3] Authentication-Results: sj-dkim-2; header.From=achoudhu@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Capwap] crypto algorithms for 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 -----Original Message----- From: Joseph Salowey (jsalowey) Sent: Wednesday, July 09, 2008 11:09 AM To: Abhijit Choudhury (achoudhu); 'Dorothy.Gellert@nokia.com'; Pat Calhoun (pacalhou); 'skelly@arubanetworks.com' Cc: 'capwap@frascone.com' Subject: RE: [Capwap] crypto algorithms for DTLS > -----Original Message----- > From: Abhijit Choudhury (achoudhu) > Sent: Wednesday, July 09, 2008 11:00 AM > To: Dorothy.Gellert@nokia.com; Pat Calhoun (pacalhou); > skelly@arubanetworks.com; Joseph Salowey (jsalowey) > Cc: capwap@frascone.com > Subject: RE: [Capwap] crypto algorithms for DTLS > > I'm okay with adding AES-GCM support as a MAY. > However, I'd suggest we add the following ciphers: > > TLS_RSA_WITH_AES_128_GCM_SHA256 > TLS_RSA_WITH_AES_256_GCM_SHA384 > > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 > > > Also, in the current spec, shouldn't we be specifying DHE instead of > DH in the cipher suite recommendations. > > Scott, Charles, Joe: any thoughts on this ? > [Joe] The DH cipher suites are for certificates containing static Diffie-Hellman keys which are not commonly used. I think you probably mean to specify DHE which are the ephemeral Diffie-hellman variants that are more commonly used and provide forward secrecy. The GCM cipher suites are based on TLS 1.2 which is currently in AUTH48 state in the RFC-editors queue and should be published shortly. > Thanks, > Abhijit > > > > -----Original Message----- > From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] > Sent: Tuesday, July 08, 2008 4:17 PM > To: Pat Calhoun (pacalhou); skelly@arubanetworks.com; Abhijit > Choudhury (achoudhu) > Cc: capwap@frascone.com > Subject: RE: [Capwap] crypto algorithms for DTLS > > Hi All, > > Are there any objections in the WG to adding the following cipher > suites: > TLS_RSA_WITH_AES_128_GCM_SHA256 > TLS_DH_RSA_WITH_AES_256_GCM_SHA384 to the base spec as a MAY? > > If not, based on the list discussion and approved draft status of > draft-ietf-tls-rsa-aes-gcm-03.txt, I support including these cipher > suites as a MAY in the next(last) WGLC. > > Best Regards, > Dorothy > > > > -----Original Message----- > > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Tuesday, July 08, 2008 4:06 PM > > To: Scott Kelly; Abhijit Choudhury (achoudhu) > > Cc: capwap > > Subject: Re: [Capwap] crypto algorithms for DTLS > > > > Oh, and just to make sure, if we were to go ahead with this, the > > following cipher suites would be added: > > > > TLS_RSA_WITH_AES_128_GCM_SHA256 > > TLS_DH_RSA_WITH_AES_256_GCM_SHA384 > > > > Right? > > > > PatC > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) > > Sent: Tuesday, July 08, 2008 3:57 PM > > To: Scott Kelly; Abhijit Choudhury (achoudhu) > > Cc: capwap > > Subject: Re: [Capwap] crypto algorithms for DTLS > > > > CAPWAP Chairs, > > > > I am done with the edits, and ready to submit the spec for > the WG Last > > Call. This is a new feature, and we had agreed to defer to the next > > version of the protocol. However, the IETF has completed the long > > pole, and the change, as a MAY, is fairly minor. What would you > > recommend? > > > > PatC > > > > -----Original Message----- > > From: Scott Kelly [mailto:skelly@arubanetworks.com] > > Sent: Tuesday, July 08, 2008 3:42 PM > > To: Abhijit Choudhury (achoudhu) > > Cc: capwap > > Subject: Re: [Capwap] crypto algorithms for DTLS > > > > Hi Abhijit, > > > > > > > > Folks, > > > > > > The issue of using AES-GCM as a cipher-suite for CAPWAP/DTLS was > > > discussed in the list about a year ago. (Please refer to > > CAPWAP issue > > > > > 7 > > > (http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue7) > > > > > > Due to the use of DTLS, we were stuck with TLS ciphersuites. > > > To use GCM we would require a TLS GCM ciphersuite. We > > discussed this > > > at an ad-hoc meeting, and decided to defer this feature, > as GCM was > > > not a TLS ciphersuite, and there was no document to reference. > > > > > > However, since that time, use of AES-GCM has been approved > > in the TLS > > > working group, and we have an approved draft > > > https://datatracker.ietf.org/idtracker/draft-ietf-tls-rsa-aes-gcm/ > > > > > > As noted in the original email, there is a lot of momentum > > behind this > > > > > crypto algorithm, and it results in significant improvements in > > > throughput in either HW or SW implementations. > > > > > > Could we address this issue in the current spec and make > AES-GCM an > > > ciphersuite that can be used with CAPWAP/DTLS ? > > > > I have no objections to adding support for AES-GCM as a MAY. > > The original proposal suggested making it mandatory to > implement, but > > given the current lack of support in commodity crypto HW, I don't > > think this would be appropriate at this time. > > > > --Scott > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/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 Jul 9 11:47:38 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7DD3A67F5 for ; Wed, 9 Jul 2008 11:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=-1.850, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 557iIIKiWjK2 for ; Wed, 9 Jul 2008 11:47:37 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 9626E28C23C for ; Wed, 9 Jul 2008 11:47:37 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8582F1C40FA5 for ; Wed, 9 Jul 2008 11:47:50 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 7A017440139 for ; Wed, 9 Jul 2008 11:11:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 50E8434AC04F for ; Wed, 9 Jul 2008 11:11:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 7B78934AC0A1 for ; Wed, 9 Jul 2008 11:08:50 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.68.10.86 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 9 Jul 2008 11:08:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,332,1212364800"; d="scan'208";a="17557336" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 09 Jul 2008 18:08:48 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m69I8msc003902; Wed, 9 Jul 2008 11:08:48 -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.13.8/8.13.8) with ESMTP id m69I8mGm013010; Wed, 9 Jul 2008 18:08:48 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 11:08:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 11:09:20 -0700 Message-ID: In-Reply-To: <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED1ED@xmb-sjc-223.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS thread-index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4AAJxBJoAAAkLeg References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com><4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED1ED@xmb-sjc-223.amer.cisco.com> From: "Joseph Salowey (jsalowey)" To: "Abhijit Choudhury (achoudhu)" , , "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 09 Jul 2008 18:08:48.0162 (UTC) FILETIME=[D591B020:01C8E1EE] Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Mailman-Approved-At: Wed, 09 Jul 2008 11:47:40 -0700 Cc: capwap@frascone.com Subject: Re: [Capwap] crypto algorithms for 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 > -----Original Message----- > From: Abhijit Choudhury (achoudhu) > Sent: Wednesday, July 09, 2008 11:00 AM > To: Dorothy.Gellert@nokia.com; Pat Calhoun (pacalhou); > skelly@arubanetworks.com; Joseph Salowey (jsalowey) > Cc: capwap@frascone.com > Subject: RE: [Capwap] crypto algorithms for DTLS > > I'm okay with adding AES-GCM support as a MAY. > However, I'd suggest we add the following ciphers: > > TLS_RSA_WITH_AES_128_GCM_SHA256 > TLS_RSA_WITH_AES_256_GCM_SHA384 > > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 > > > Also, in the current spec, shouldn't we be specifying DHE > instead of DH in the cipher suite recommendations. > > Scott, Charles, Joe: any thoughts on this ? > [Joe] The DH cipher suites are for certificates containing static Diffie-Hellman keys which are not commonly used. I think you probably mean to specify DHE which are the ephemeral Diffie-hellman variants that are more commonly used and provide forward secrecy. The GCM cipher suites are based on TLS 1.2 which is currently in AUTH48 state in the RFC-editors queue and should be published shortly. > Thanks, > Abhijit > > > > -----Original Message----- > From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] > Sent: Tuesday, July 08, 2008 4:17 PM > To: Pat Calhoun (pacalhou); skelly@arubanetworks.com; Abhijit > Choudhury (achoudhu) > Cc: capwap@frascone.com > Subject: RE: [Capwap] crypto algorithms for DTLS > > Hi All, > > Are there any objections in the WG to adding the following cipher > suites: > TLS_RSA_WITH_AES_128_GCM_SHA256 > TLS_DH_RSA_WITH_AES_256_GCM_SHA384 to the base spec as a MAY? > > If not, based on the list discussion and approved draft > status of draft-ietf-tls-rsa-aes-gcm-03.txt, I support > including these cipher suites as a MAY in the next(last) WGLC. > > Best Regards, > Dorothy > > > > -----Original Message----- > > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Tuesday, July 08, 2008 4:06 PM > > To: Scott Kelly; Abhijit Choudhury (achoudhu) > > Cc: capwap > > Subject: Re: [Capwap] crypto algorithms for DTLS > > > > Oh, and just to make sure, if we were to go ahead with this, the > > following cipher suites would be added: > > > > TLS_RSA_WITH_AES_128_GCM_SHA256 > > TLS_DH_RSA_WITH_AES_256_GCM_SHA384 > > > > Right? > > > > PatC > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) > > Sent: Tuesday, July 08, 2008 3:57 PM > > To: Scott Kelly; Abhijit Choudhury (achoudhu) > > Cc: capwap > > Subject: Re: [Capwap] crypto algorithms for DTLS > > > > CAPWAP Chairs, > > > > I am done with the edits, and ready to submit the spec for > the WG Last > > Call. This is a new feature, and we had agreed to defer to the next > > version of the protocol. However, the IETF has completed the long > > pole, and the change, as a MAY, is fairly minor. What would you > > recommend? > > > > PatC > > > > -----Original Message----- > > From: Scott Kelly [mailto:skelly@arubanetworks.com] > > Sent: Tuesday, July 08, 2008 3:42 PM > > To: Abhijit Choudhury (achoudhu) > > Cc: capwap > > Subject: Re: [Capwap] crypto algorithms for DTLS > > > > Hi Abhijit, > > > > > > > > Folks, > > > > > > The issue of using AES-GCM as a cipher-suite for CAPWAP/DTLS was > > > discussed in the list about a year ago. (Please refer to > > CAPWAP issue > > > > > 7 > > > (http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue7) > > > > > > Due to the use of DTLS, we were stuck with TLS ciphersuites. > > > To use GCM we would require a TLS GCM ciphersuite. We > > discussed this > > > at an ad-hoc meeting, and decided to defer this feature, > as GCM was > > > not a TLS ciphersuite, and there was no document to reference. > > > > > > However, since that time, use of AES-GCM has been approved > > in the TLS > > > working group, and we have an approved draft > > > https://datatracker.ietf.org/idtracker/draft-ietf-tls-rsa-aes-gcm/ > > > > > > As noted in the original email, there is a lot of momentum > > behind this > > > > > crypto algorithm, and it results in significant improvements in > > > throughput in either HW or SW implementations. > > > > > > Could we address this issue in the current spec and make > AES-GCM an > > > ciphersuite that can be used with CAPWAP/DTLS ? > > > > I have no objections to adding support for AES-GCM as a MAY. > > The original proposal suggested making it mandatory to > implement, but > > given the current lack of support in commodity crypto HW, I don't > > think this would be appropriate at this time. > > > > --Scott > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/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 Jul 9 12:14:38 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D64F28C1F0 for ; Wed, 9 Jul 2008 12:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ojPxY6tQMig for ; Wed, 9 Jul 2008 12:14:36 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id B0A113A6B14 for ; Wed, 9 Jul 2008 12:14:36 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EDC7C1C40F76 for ; Wed, 9 Jul 2008 12:14:47 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 869F54400E7 for ; Wed, 9 Jul 2008 12:14:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2902D361002B for ; Wed, 9 Jul 2008 12:14:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5996A34AC089 for ; Wed, 9 Jul 2008 12:13:26 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 9 Jul 2008 12:13:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,332,1212364800"; d="scan'208";a="50902433" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 09 Jul 2008 19:13:22 +0000 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/8.12.11) with ESMTP id m69JDM3T011611 for ; Wed, 9 Jul 2008 12:13:22 -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.13.8/8.13.8) with ESMTP id m69JDGfl013377 for ; Wed, 9 Jul 2008 19:13:22 GMT 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.1830); Wed, 9 Jul 2008 12:13:18 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 12:12:56 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20614E010@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue : IANA Cleanup Thread-Index: Acjh98sQ5gmak2fPT8OSyVghWgFj3w== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 09 Jul 2008 19:13:18.0717 (UTC) FILETIME=[D89982D0:01C8E1F7] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Capwap] Issue : IANA Cleanup 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 All, In getting ready to send the latest version of the specs for publication, I realized that the IANA considerations section still needed to be finalized. I guess I was keeping the best for last, so I have taken care of this in both specs, and I am including the text here for both specs. Note that I am making the assumption that we need a standards action for all number assignment. 15. IANA Considerations A separate UDP port for data channel communications is (currently) the selected demultiplexing mechanism, and a port must be assigned for this purpose in Section 3.1. The UDP port numbers are listed by IANA at http://www.iana.org/assignments/port-numbers. IANA needs to assign an organization local multicast address called the "All ACs multicast address" from the IPv6 multicast address registry in Section 3.3 15.1. CAPWAP Message Types The Message Type field in the CAPWAP header (see Section 4.5.1.1) is used to identify the operation performed by the message. There are multiple namespaces, which is identified via the first three octets of the field containing the IANA Enterprise Number [RFC5226]. When the Enterprise Number is set to zero, the message types are reserved for use by the base CAPWAP specification which are controlled and maintained by IANA and requires a Standards Action. 15.2. CAPWAP Header Flags The Flags field in the CAPWAP header (see Section 4.3) is used to identify any special treatment related to the message. There are currently three unused, reserved bits. These bits are controlled and maintained by IANA and requires a Standards Action. 15.3. CAPWAP Control Message Flags The Flags field in the CAPWAP Control Message header (see Section 4.5.1.4) is used to identify any special treatment related to the control message. There are currently eight unused, reserved bits. These bits are controlled and maintained by IANA and requires a Standards Action. 15.4. CAPWAP Control Message Type The Type field in the CAPWAP Control Message header (see Section 4.6) is used to identify the data being transported. The 32 bit enumerated values are currently defined in Section 4.5.1.1. These values are controlled and maintained by IANA and requires a Standards Action. 15.5. Wireless Binding Identifiers The Wireless Binding Identifier (WBID) field in the CAPWAP header (see Section 4.3) is used to identify the wireless technology associated with the packet. Due to the limited address space available, a new WBID request requires Standards Action. 15.6. AC Security Types The Security field in the AC Descriptor message element (see Section 4.6.1) is used to identify the authentication type available on the AC. This document defines two bits, and the remaining bits are controlled and maintained by IANA and requires a Standards Action. 15.7. AC DTLS Policy The DTLS Policy field in the AC Descriptor message element (see Section 4.6.1) is used to identify the how, and if, the CAPWAP Data Channel is to be secured. This document defines two bits, and the remaining bits are controlled and maintained by IANA and requires a Standards Action. 15.8. AC Information Type The Information Type field in the AC Descriptor message element (see Section 4.6.1) is used to represent information about the AC. This document defines two values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.9. CAPWAP Transport Protocol Types The Transport field in the CAPWAP Transport Protocol message element (see Section 4.6.15) is used to identify the transport to use for the CAPWAP Data Channel. This document defines two values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.10. Data Transfer Type The Data Type field in the Data Transfer Data message element (see Section 4.6.16) and Image Data message element (see Section 4.6.27) is used to provide information about the data being carried. This document defines three values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.11. Data Transfer Mode The Data Mode field in the Data Transfer Data message element (see Section 4.6.16) and Data Transfer Mode message element (see Section 15.11) is used to provide information about the data being carried. This document defines three values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.12. Discovery Types The Discovery Type field in the Discovery Type message element (see Section 4.6.23) is used by the WTP to indicate to the AC how it was discovered. This document defines five values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.13. Radio Admin State The Radio Admin field in the Radio Administrative State message element (see Section 4.6.33) is used by the WTP to represent the state of its radios. This document defines two bits, and the remaining bits are controlled and maintained by IANA and requires a Standards Action. 15.14. Radio Operational State The State field in the Radio Operational State message element (see Section 4.6.34) is used by the WTP to represent the operational state of its radios. This document defines two bits, and the remaining bits are controlled and maintained by IANA and requires a Standards Action. 15.15. Radio Failure Causes The Cause field in the Radio Operational State message element (see Section 4.6.34) is used by the WTP to represent the reason why a radio may have failed. This document defines four values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.16. Result Code The Result Code field in the Result Code message element (see Section 4.6.35) is used to indicate the success, or failure, of a CAPWAP control message. This document defines 23 values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.17. Returned Message Element Reason The Reason field in the Returned Message Element message element (see Section 4.6.36) is used to indicate the reason why a message element was not processed successfully. This document defines five values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.18. WTP Board Data Type The Board Data Type field in the WTP Board Data message element (see Section 4.6.40) is used to represent information about the WTP hardware. This document defines five values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.19. WTP Descriptor Type The Descriptor Type field in the WTP Descriptor message element (see Section 4.6.41) is used to represent information about the WTP software. This document defines four values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.20. WTP Fallback Mode The Mode field in the WTP Fallback message element (see Section 4.6.42) is used to indicate to the WTP the type of AC fallback mechanism it should employ. This document defines three values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.21. WTP Frame Tunnel Mode The Tunnel Type field in the WTP Frame Tunnel Mode message element (see Section 4.6.43) is used to indicate the type of tunneling to use between the WTP and the AC. This document defines four values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.22. WTP MAC Type The MAC Type field in the WTP MAC Type message element (see Section 4.6.46) is used to indicate the type of MAC to use in tunneled frames between the WTP and the AC. This document defines three values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.23. WTP Radio Stats Failure Type The Last Failure Type field in the WTP Radio Statistics message element (see Section 4.6.48) is used to indicate the last WTP failure. This document defines five values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.24. WTP Reboot Stats Failure Type The Last Failure Type field in the WTP Reboot Statistics message element (see Section 4.6.49) is used to indicate the last reboot reason. This document defines seven values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 10. IANA Considerations 10.1. CAPWAP Message Types This specification defines two new Message Types used in the CAPWAP header. These values are defined in Section 3. 10.2. CAPWAP Control Message Type This specification defines 27 new Message Types used in the CAPWAP header. These values are defined in Figure 8. 10.3. IEEE 802.11 Key Status The Key Status field in the IEEE 802.11 Add WLAN message element (see Section 6.1) and IEEE 802.11 Update WLAN message element (see Section 6.21) is used to provide information about the status of the keying exchange. This document defines four values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 10.4. IEEE 802.11 QoS The QoS field in the IEEE 802.11 Add WLAN message element (see Section 6.1) is used to configure a QoS policy for the WLAN. This document defines four values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 10.5. IEEE 802.11 Auth Type The Auth Type field in the IEEE 802.11 Add WLAN message element (see Section 6.1) is used to configure the IEEE 802.11 authentication policy for the WLAN. This document defines two bits, and the remaining bits are controlled and maintained by IANA and requires a Standards Action. 10.6. IEEE 802.11 Antenna Combiner The Combiner field in the IEEE 802.11 Antenna message element (see Section 6.2) is used to provide information about the WTP's antennas. This document defines four bits, and the remaining bits are controlled and maintained by IANA and requires a Standards Action. 10.7. IEEE 802.11 Antenna Selection The Antenna Selection field in the IEEE 802.11 Antenna message element (see Section 6.2) is used to provide information about the WTP's antennas. This document defines two values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 10.8. IEEE 802.11 Session Key Flags The Flags field in the IEEE 802.11 Station Session Key message element (see Section 6.15) is used to configure the session key association with the mobile device. This document defines two bits, and the remaining 14 bits are controlled and maintained by IANA and requires a Standards Action. 10.9. IEEE 802.11 Tag Packets The Tag Packets field in the IEEE 802.11 WTP Quality of Service message element (see Section 6.22) is used to specify how the CAPWAP Data Channel packets are to be tagged. This document defines two bits, and the remaining 6 bits are controlled and maintained by IANA and requires a Standards Action. 10.10. IEEE 802.11 WTP Radio Fail The Type field in the IEEE 802.11 WTP Radio Fail Alarm Indication message element (see Section 6.24) is used to provide information on why a WTP's radio has failed. This document defines two values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 10.11. IEEE 802.11 WTP Radio Type The Radio Type field in the IEEE 802.11 WTP Radio Information message element (see Section 6.25) is used to provide information about the WTP's radio type. This document defines four bits, and the remaining 28 bits are controlled and maintained by IANA and requires a Standards Action. 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 Wed Jul 9 12:16:00 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D0163A6820 for ; Wed, 9 Jul 2008 12:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YqADgBMQI69 for ; Wed, 9 Jul 2008 12:15:58 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 7914328C200 for ; Wed, 9 Jul 2008 12:15:47 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 74810439FA4 for ; Wed, 9 Jul 2008 12:16:00 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 57EDC4400D7 for ; Wed, 9 Jul 2008 12:15:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id DF56E34AC0F8 for ; Wed, 9 Jul 2008 12:15:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4D80634AC0A4 for ; Wed, 9 Jul 2008 12:14:20 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.72 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 9 Jul 2008 12:14:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,332,1212364800"; d="scan'208";a="86166651" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 09 Jul 2008 19:14:19 +0000 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/8.12.11) with ESMTP id m69JEJ4G012984 for ; Wed, 9 Jul 2008 12:14:19 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m69JEJAx021553 for ; Wed, 9 Jul 2008 19:14:19 GMT 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, 9 Jul 2008 12:14:18 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 12:13:34 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20614E018@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 148: IANA Cleanup Thread-Index: Acjh98sQ5gmak2fPT8OSyVghWgFj3wAAApMQ From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 09 Jul 2008 19:14:18.0885 (UTC) FILETIME=[FC766B50:01C8E1F7] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Capwap] Issue 148: IANA Cleanup 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 I should have noted this was created as issue 148. PatC -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Wednesday, July 09, 2008 12:13 PM To: capwap@frascone.com Subject: Issue : IANA Cleanup All, In getting ready to send the latest version of the specs for publication, I realized that the IANA considerations section still needed to be finalized. I guess I was keeping the best for last, so I have taken care of this in both specs, and I am including the text here for both specs. Note that I am making the assumption that we need a standards action for all number assignment. 15. IANA Considerations A separate UDP port for data channel communications is (currently) the selected demultiplexing mechanism, and a port must be assigned for this purpose in Section 3.1. The UDP port numbers are listed by IANA at http://www.iana.org/assignments/port-numbers. IANA needs to assign an organization local multicast address called the "All ACs multicast address" from the IPv6 multicast address registry in Section 3.3 15.1. CAPWAP Message Types The Message Type field in the CAPWAP header (see Section 4.5.1.1) is used to identify the operation performed by the message. There are multiple namespaces, which is identified via the first three octets of the field containing the IANA Enterprise Number [RFC5226]. When the Enterprise Number is set to zero, the message types are reserved for use by the base CAPWAP specification which are controlled and maintained by IANA and requires a Standards Action. 15.2. CAPWAP Header Flags The Flags field in the CAPWAP header (see Section 4.3) is used to identify any special treatment related to the message. There are currently three unused, reserved bits. These bits are controlled and maintained by IANA and requires a Standards Action. 15.3. CAPWAP Control Message Flags The Flags field in the CAPWAP Control Message header (see Section 4.5.1.4) is used to identify any special treatment related to the control message. There are currently eight unused, reserved bits. These bits are controlled and maintained by IANA and requires a Standards Action. 15.4. CAPWAP Control Message Type The Type field in the CAPWAP Control Message header (see Section 4.6) is used to identify the data being transported. The 32 bit enumerated values are currently defined in Section 4.5.1.1. These values are controlled and maintained by IANA and requires a Standards Action. 15.5. Wireless Binding Identifiers The Wireless Binding Identifier (WBID) field in the CAPWAP header (see Section 4.3) is used to identify the wireless technology associated with the packet. Due to the limited address space available, a new WBID request requires Standards Action. 15.6. AC Security Types The Security field in the AC Descriptor message element (see Section 4.6.1) is used to identify the authentication type available on the AC. This document defines two bits, and the remaining bits are controlled and maintained by IANA and requires a Standards Action. 15.7. AC DTLS Policy The DTLS Policy field in the AC Descriptor message element (see Section 4.6.1) is used to identify the how, and if, the CAPWAP Data Channel is to be secured. This document defines two bits, and the remaining bits are controlled and maintained by IANA and requires a Standards Action. 15.8. AC Information Type The Information Type field in the AC Descriptor message element (see Section 4.6.1) is used to represent information about the AC. This document defines two values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.9. CAPWAP Transport Protocol Types The Transport field in the CAPWAP Transport Protocol message element (see Section 4.6.15) is used to identify the transport to use for the CAPWAP Data Channel. This document defines two values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.10. Data Transfer Type The Data Type field in the Data Transfer Data message element (see Section 4.6.16) and Image Data message element (see Section 4.6.27) is used to provide information about the data being carried. This document defines three values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.11. Data Transfer Mode The Data Mode field in the Data Transfer Data message element (see Section 4.6.16) and Data Transfer Mode message element (see Section 15.11) is used to provide information about the data being carried. This document defines three values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.12. Discovery Types The Discovery Type field in the Discovery Type message element (see Section 4.6.23) is used by the WTP to indicate to the AC how it was discovered. This document defines five values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.13. Radio Admin State The Radio Admin field in the Radio Administrative State message element (see Section 4.6.33) is used by the WTP to represent the state of its radios. This document defines two bits, and the remaining bits are controlled and maintained by IANA and requires a Standards Action. 15.14. Radio Operational State The State field in the Radio Operational State message element (see Section 4.6.34) is used by the WTP to represent the operational state of its radios. This document defines two bits, and the remaining bits are controlled and maintained by IANA and requires a Standards Action. 15.15. Radio Failure Causes The Cause field in the Radio Operational State message element (see Section 4.6.34) is used by the WTP to represent the reason why a radio may have failed. This document defines four values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.16. Result Code The Result Code field in the Result Code message element (see Section 4.6.35) is used to indicate the success, or failure, of a CAPWAP control message. This document defines 23 values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.17. Returned Message Element Reason The Reason field in the Returned Message Element message element (see Section 4.6.36) is used to indicate the reason why a message element was not processed successfully. This document defines five values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.18. WTP Board Data Type The Board Data Type field in the WTP Board Data message element (see Section 4.6.40) is used to represent information about the WTP hardware. This document defines five values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.19. WTP Descriptor Type The Descriptor Type field in the WTP Descriptor message element (see Section 4.6.41) is used to represent information about the WTP software. This document defines four values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.20. WTP Fallback Mode The Mode field in the WTP Fallback message element (see Section 4.6.42) is used to indicate to the WTP the type of AC fallback mechanism it should employ. This document defines three values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.21. WTP Frame Tunnel Mode The Tunnel Type field in the WTP Frame Tunnel Mode message element (see Section 4.6.43) is used to indicate the type of tunneling to use between the WTP and the AC. This document defines four values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.22. WTP MAC Type The MAC Type field in the WTP MAC Type message element (see Section 4.6.46) is used to indicate the type of MAC to use in tunneled frames between the WTP and the AC. This document defines three values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.23. WTP Radio Stats Failure Type The Last Failure Type field in the WTP Radio Statistics message element (see Section 4.6.48) is used to indicate the last WTP failure. This document defines five values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.24. WTP Reboot Stats Failure Type The Last Failure Type field in the WTP Reboot Statistics message element (see Section 4.6.49) is used to indicate the last reboot reason. This document defines seven values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 10. IANA Considerations 10.1. CAPWAP Message Types This specification defines two new Message Types used in the CAPWAP header. These values are defined in Section 3. 10.2. CAPWAP Control Message Type This specification defines 27 new Message Types used in the CAPWAP header. These values are defined in Figure 8. 10.3. IEEE 802.11 Key Status The Key Status field in the IEEE 802.11 Add WLAN message element (see Section 6.1) and IEEE 802.11 Update WLAN message element (see Section 6.21) is used to provide information about the status of the keying exchange. This document defines four values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 10.4. IEEE 802.11 QoS The QoS field in the IEEE 802.11 Add WLAN message element (see Section 6.1) is used to configure a QoS policy for the WLAN. This document defines four values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 10.5. IEEE 802.11 Auth Type The Auth Type field in the IEEE 802.11 Add WLAN message element (see Section 6.1) is used to configure the IEEE 802.11 authentication policy for the WLAN. This document defines two bits, and the remaining bits are controlled and maintained by IANA and requires a Standards Action. 10.6. IEEE 802.11 Antenna Combiner The Combiner field in the IEEE 802.11 Antenna message element (see Section 6.2) is used to provide information about the WTP's antennas. This document defines four bits, and the remaining bits are controlled and maintained by IANA and requires a Standards Action. 10.7. IEEE 802.11 Antenna Selection The Antenna Selection field in the IEEE 802.11 Antenna message element (see Section 6.2) is used to provide information about the WTP's antennas. This document defines two values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 10.8. IEEE 802.11 Session Key Flags The Flags field in the IEEE 802.11 Station Session Key message element (see Section 6.15) is used to configure the session key association with the mobile device. This document defines two bits, and the remaining 14 bits are controlled and maintained by IANA and requires a Standards Action. 10.9. IEEE 802.11 Tag Packets The Tag Packets field in the IEEE 802.11 WTP Quality of Service message element (see Section 6.22) is used to specify how the CAPWAP Data Channel packets are to be tagged. This document defines two bits, and the remaining 6 bits are controlled and maintained by IANA and requires a Standards Action. 10.10. IEEE 802.11 WTP Radio Fail The Type field in the IEEE 802.11 WTP Radio Fail Alarm Indication message element (see Section 6.24) is used to provide information on why a WTP's radio has failed. This document defines two values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 10.11. IEEE 802.11 WTP Radio Type The Radio Type field in the IEEE 802.11 WTP Radio Information message element (see Section 6.25) is used to provide information about the WTP's radio type. This document defines four bits, and the remaining 28 bits are controlled and maintained by IANA and requires a Standards Action. 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 Wed Jul 9 12:29:46 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 472183A6B44 for ; Wed, 9 Jul 2008 12:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-S7t52ndflj for ; Wed, 9 Jul 2008 12:29:45 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 56CC83A68E0 for ; Wed, 9 Jul 2008 12:29:42 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4D60D1C40F68 for ; Wed, 9 Jul 2008 12:29:55 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id C3C004400D7 for ; Wed, 9 Jul 2008 12:29:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8896F34AC016 for ; Wed, 9 Jul 2008 12:29:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D7B8234AC00F for ; Wed, 9 Jul 2008 12:29:38 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.68.10.86 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 9 Jul 2008 12:29:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,332,1212364800"; d="scan'208";a="17566050" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 09 Jul 2008 19:29:30 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m69JTUrs006494; Wed, 9 Jul 2008 12:29:30 -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.13.8/8.13.8) with ESMTP id m69JTUb3020739; Wed, 9 Jul 2008 19:29:30 GMT 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, 9 Jul 2008 12:29:29 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 12:28:52 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20614E02E@xmb-sjc-235.amer.cisco.com> In-Reply-To: <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED20E@xmb-sjc-223.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS Thread-Index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4AAJ/T4MAACq6Gw X-Priority: 1 Priority: Urgent Importance: high References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com><4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED20E@xmb-sjc-223.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Abhijit Choudhury (achoudhu)" , , , "Joseph Salowey (jsalowey)" X-OriginalArrivalTime: 09 Jul 2008 19:29:29.0984 (UTC) FILETIME=[1B851800:01C8E1FA] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] crypto algorithms for 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 Ah, so this is a much larger change than simply adding two ciphers as MAY. I don't have visibility into TLS1.2 and DTLS1.2, and therefore have no idea whether this would break anything. Scott and CAPWAP chairs, do we go ahead with this change? Given it has been through IETF and IESG review, I suspect it would make sense to use the latest version. PatC -----Original Message----- From: Abhijit Choudhury (achoudhu) Sent: Wednesday, July 09, 2008 11:23 AM To: Dorothy.Gellert@nokia.com; Pat Calhoun (pacalhou); skelly@arubanetworks.com; Joseph Salowey (jsalowey) Cc: capwap@frascone.com Subject: RE: [Capwap] crypto algorithms for DTLS Hi Dorothy, Please note that AES-GCM requires TLS1.2 which is currently in AUTH48 state in the RFC-editors queue and should be published shortly. DTLS1.2, which is based on TLS1.2, is working group item and will most likely make it to last call after next IETF. I would suggest we reference TLS1.2 and add the AES-GCM ciphersuites as MAY. Also, in order to ensure that CAPWAP track DTLS better, we should change the text in section 2.4.4.1 from "Note that only block ciphers are currently recommended for use with DTLS. To understand the reasoning behind this, see [DTLS-DESIGN]." To "CAPWAP implementations only use cipher suites that are recommended for use with DTLS. Note that certain stream ciphers, such as RC4, that cannot be randomly accessed may not be used with DTLS." Thoughts ? Abhijit -----Original Message----- From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] Sent: Tuesday, July 08, 2008 4:17 PM To: Pat Calhoun (pacalhou); skelly@arubanetworks.com; Abhijit Choudhury (achoudhu) Cc: capwap@frascone.com Subject: RE: [Capwap] crypto algorithms for DTLS Hi All, Are there any objections in the WG to adding the following cipher suites: TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_DH_RSA_WITH_AES_256_GCM_SHA384 to the base spec as a MAY? If not, based on the list discussion and approved draft status of draft-ietf-tls-rsa-aes-gcm-03.txt, I support including these cipher suites as a MAY in the next(last) WGLC. Best Regards, Dorothy > -----Original Message----- > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Tuesday, July 08, 2008 4:06 PM > To: Scott Kelly; Abhijit Choudhury (achoudhu) > Cc: capwap > Subject: Re: [Capwap] crypto algorithms for DTLS > > Oh, and just to make sure, if we were to go ahead with this, the > following cipher suites would be added: > > TLS_RSA_WITH_AES_128_GCM_SHA256 > TLS_DH_RSA_WITH_AES_256_GCM_SHA384 > > Right? > > PatC > > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Tuesday, July 08, 2008 3:57 PM > To: Scott Kelly; Abhijit Choudhury (achoudhu) > Cc: capwap > Subject: Re: [Capwap] crypto algorithms for DTLS > > CAPWAP Chairs, > > I am done with the edits, and ready to submit the spec for the WG Last > Call. This is a new feature, and we had agreed to defer to the next > version of the protocol. However, the IETF has completed the long > pole, and the change, as a MAY, is fairly minor. What would you > recommend? > > PatC > > -----Original Message----- > From: Scott Kelly [mailto:skelly@arubanetworks.com] > Sent: Tuesday, July 08, 2008 3:42 PM > To: Abhijit Choudhury (achoudhu) > Cc: capwap > Subject: Re: [Capwap] crypto algorithms for DTLS > > Hi Abhijit, > > > > > Folks, > > > > The issue of using AES-GCM as a cipher-suite for CAPWAP/DTLS was > > discussed in the list about a year ago. (Please refer to > CAPWAP issue > > > 7 > > (http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue7) > > > > Due to the use of DTLS, we were stuck with TLS ciphersuites. > > To use GCM we would require a TLS GCM ciphersuite. We > discussed this > > at an ad-hoc meeting, and decided to defer this feature, as GCM was > > not a TLS ciphersuite, and there was no document to reference. > > > > However, since that time, use of AES-GCM has been approved > in the TLS > > working group, and we have an approved draft > > https://datatracker.ietf.org/idtracker/draft-ietf-tls-rsa-aes-gcm/ > > > > As noted in the original email, there is a lot of momentum > behind this > > > crypto algorithm, and it results in significant improvements in > > throughput in either HW or SW implementations. > > > > Could we address this issue in the current spec and make AES-GCM an > > ciphersuite that can be used with CAPWAP/DTLS ? > > I have no objections to adding support for AES-GCM as a MAY. > The original proposal suggested making it mandatory to implement, but > given the current lack of support in commodity crypto HW, I don't > think this would be appropriate at this time. > > --Scott > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/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 Jul 9 12:30:33 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A23B28C278 for ; Wed, 9 Jul 2008 12:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClO95z+2tDWP for ; Wed, 9 Jul 2008 12:30:31 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 49F6B28C279 for ; Wed, 9 Jul 2008 12:30:31 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 501401C40FC1 for ; Wed, 9 Jul 2008 12:30:44 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 0924C4400D4 for ; Wed, 9 Jul 2008 12:30:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8A15334AC02A for ; Wed, 9 Jul 2008 12:30:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2209634AC016 for ; Wed, 9 Jul 2008 12:30:32 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 9 Jul 2008 12:30:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,332,1212364800"; d="scan'208";a="50909994" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 09 Jul 2008 19:30:31 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m69JUVci021091 for ; Wed, 9 Jul 2008 12:30:31 -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.13.8/8.13.8) with ESMTP id m69JUVxf022193 for ; Wed, 9 Jul 2008 19:30:31 GMT 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.1830); Wed, 9 Jul 2008 12:30:31 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 12:30:15 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20614E02F@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20614E018@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 148: IANA Cleanup Thread-Index: Acjh98sQ5gmak2fPT8OSyVghWgFj3wAAApMQAACSdeA= References: <4FF84B0BC277FF45AA27FE969DD956A20614E018@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 09 Jul 2008 19:30:31.0021 (UTC) FILETIME=[3FE699D0:01C8E1FA] Authentication-Results: sj-dkim-4; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Capwap] Issue 148: IANA Cleanup 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 Sigh. The first paragraph about UDP ports shouldn't have been there. It was removed when I addressed Issue 142. PatC -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Wednesday, July 09, 2008 12:14 PM To: capwap@frascone.com Subject: Re: [Capwap] Issue 148: IANA Cleanup I should have noted this was created as issue 148. PatC -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Wednesday, July 09, 2008 12:13 PM To: capwap@frascone.com Subject: Issue : IANA Cleanup All, In getting ready to send the latest version of the specs for publication, I realized that the IANA considerations section still needed to be finalized. I guess I was keeping the best for last, so I have taken care of this in both specs, and I am including the text here for both specs. Note that I am making the assumption that we need a standards action for all number assignment. 15. IANA Considerations A separate UDP port for data channel communications is (currently) the selected demultiplexing mechanism, and a port must be assigned for this purpose in Section 3.1. The UDP port numbers are listed by IANA at http://www.iana.org/assignments/port-numbers. IANA needs to assign an organization local multicast address called the "All ACs multicast address" from the IPv6 multicast address registry in Section 3.3 15.1. CAPWAP Message Types The Message Type field in the CAPWAP header (see Section 4.5.1.1) is used to identify the operation performed by the message. There are multiple namespaces, which is identified via the first three octets of the field containing the IANA Enterprise Number [RFC5226]. When the Enterprise Number is set to zero, the message types are reserved for use by the base CAPWAP specification which are controlled and maintained by IANA and requires a Standards Action. 15.2. CAPWAP Header Flags The Flags field in the CAPWAP header (see Section 4.3) is used to identify any special treatment related to the message. There are currently three unused, reserved bits. These bits are controlled and maintained by IANA and requires a Standards Action. 15.3. CAPWAP Control Message Flags The Flags field in the CAPWAP Control Message header (see Section 4.5.1.4) is used to identify any special treatment related to the control message. There are currently eight unused, reserved bits. These bits are controlled and maintained by IANA and requires a Standards Action. 15.4. CAPWAP Control Message Type The Type field in the CAPWAP Control Message header (see Section 4.6) is used to identify the data being transported. The 32 bit enumerated values are currently defined in Section 4.5.1.1. These values are controlled and maintained by IANA and requires a Standards Action. 15.5. Wireless Binding Identifiers The Wireless Binding Identifier (WBID) field in the CAPWAP header (see Section 4.3) is used to identify the wireless technology associated with the packet. Due to the limited address space available, a new WBID request requires Standards Action. 15.6. AC Security Types The Security field in the AC Descriptor message element (see Section 4.6.1) is used to identify the authentication type available on the AC. This document defines two bits, and the remaining bits are controlled and maintained by IANA and requires a Standards Action. 15.7. AC DTLS Policy The DTLS Policy field in the AC Descriptor message element (see Section 4.6.1) is used to identify the how, and if, the CAPWAP Data Channel is to be secured. This document defines two bits, and the remaining bits are controlled and maintained by IANA and requires a Standards Action. 15.8. AC Information Type The Information Type field in the AC Descriptor message element (see Section 4.6.1) is used to represent information about the AC. This document defines two values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.9. CAPWAP Transport Protocol Types The Transport field in the CAPWAP Transport Protocol message element (see Section 4.6.15) is used to identify the transport to use for the CAPWAP Data Channel. This document defines two values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.10. Data Transfer Type The Data Type field in the Data Transfer Data message element (see Section 4.6.16) and Image Data message element (see Section 4.6.27) is used to provide information about the data being carried. This document defines three values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.11. Data Transfer Mode The Data Mode field in the Data Transfer Data message element (see Section 4.6.16) and Data Transfer Mode message element (see Section 15.11) is used to provide information about the data being carried. This document defines three values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.12. Discovery Types The Discovery Type field in the Discovery Type message element (see Section 4.6.23) is used by the WTP to indicate to the AC how it was discovered. This document defines five values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.13. Radio Admin State The Radio Admin field in the Radio Administrative State message element (see Section 4.6.33) is used by the WTP to represent the state of its radios. This document defines two bits, and the remaining bits are controlled and maintained by IANA and requires a Standards Action. 15.14. Radio Operational State The State field in the Radio Operational State message element (see Section 4.6.34) is used by the WTP to represent the operational state of its radios. This document defines two bits, and the remaining bits are controlled and maintained by IANA and requires a Standards Action. 15.15. Radio Failure Causes The Cause field in the Radio Operational State message element (see Section 4.6.34) is used by the WTP to represent the reason why a radio may have failed. This document defines four values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.16. Result Code The Result Code field in the Result Code message element (see Section 4.6.35) is used to indicate the success, or failure, of a CAPWAP control message. This document defines 23 values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.17. Returned Message Element Reason The Reason field in the Returned Message Element message element (see Section 4.6.36) is used to indicate the reason why a message element was not processed successfully. This document defines five values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.18. WTP Board Data Type The Board Data Type field in the WTP Board Data message element (see Section 4.6.40) is used to represent information about the WTP hardware. This document defines five values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.19. WTP Descriptor Type The Descriptor Type field in the WTP Descriptor message element (see Section 4.6.41) is used to represent information about the WTP software. This document defines four values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.20. WTP Fallback Mode The Mode field in the WTP Fallback message element (see Section 4.6.42) is used to indicate to the WTP the type of AC fallback mechanism it should employ. This document defines three values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.21. WTP Frame Tunnel Mode The Tunnel Type field in the WTP Frame Tunnel Mode message element (see Section 4.6.43) is used to indicate the type of tunneling to use between the WTP and the AC. This document defines four values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.22. WTP MAC Type The MAC Type field in the WTP MAC Type message element (see Section 4.6.46) is used to indicate the type of MAC to use in tunneled frames between the WTP and the AC. This document defines three values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.23. WTP Radio Stats Failure Type The Last Failure Type field in the WTP Radio Statistics message element (see Section 4.6.48) is used to indicate the last WTP failure. This document defines five values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 15.24. WTP Reboot Stats Failure Type The Last Failure Type field in the WTP Reboot Statistics message element (see Section 4.6.49) is used to indicate the last reboot reason. This document defines seven values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 10. IANA Considerations 10.1. CAPWAP Message Types This specification defines two new Message Types used in the CAPWAP header. These values are defined in Section 3. 10.2. CAPWAP Control Message Type This specification defines 27 new Message Types used in the CAPWAP header. These values are defined in Figure 8. 10.3. IEEE 802.11 Key Status The Key Status field in the IEEE 802.11 Add WLAN message element (see Section 6.1) and IEEE 802.11 Update WLAN message element (see Section 6.21) is used to provide information about the status of the keying exchange. This document defines four values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 10.4. IEEE 802.11 QoS The QoS field in the IEEE 802.11 Add WLAN message element (see Section 6.1) is used to configure a QoS policy for the WLAN. This document defines four values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 10.5. IEEE 802.11 Auth Type The Auth Type field in the IEEE 802.11 Add WLAN message element (see Section 6.1) is used to configure the IEEE 802.11 authentication policy for the WLAN. This document defines two bits, and the remaining bits are controlled and maintained by IANA and requires a Standards Action. 10.6. IEEE 802.11 Antenna Combiner The Combiner field in the IEEE 802.11 Antenna message element (see Section 6.2) is used to provide information about the WTP's antennas. This document defines four bits, and the remaining bits are controlled and maintained by IANA and requires a Standards Action. 10.7. IEEE 802.11 Antenna Selection The Antenna Selection field in the IEEE 802.11 Antenna message element (see Section 6.2) is used to provide information about the WTP's antennas. This document defines two values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 10.8. IEEE 802.11 Session Key Flags The Flags field in the IEEE 802.11 Station Session Key message element (see Section 6.15) is used to configure the session key association with the mobile device. This document defines two bits, and the remaining 14 bits are controlled and maintained by IANA and requires a Standards Action. 10.9. IEEE 802.11 Tag Packets The Tag Packets field in the IEEE 802.11 WTP Quality of Service message element (see Section 6.22) is used to specify how the CAPWAP Data Channel packets are to be tagged. This document defines two bits, and the remaining 6 bits are controlled and maintained by IANA and requires a Standards Action. 10.10. IEEE 802.11 WTP Radio Fail The Type field in the IEEE 802.11 WTP Radio Fail Alarm Indication message element (see Section 6.24) is used to provide information on why a WTP's radio has failed. This document defines two values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 10.11. IEEE 802.11 WTP Radio Type The Radio Type field in the IEEE 802.11 WTP Radio Information message element (see Section 6.25) is used to provide information about the WTP's radio type. This document defines four bits, and the remaining 28 bits are controlled and maintained by IANA and requires a Standards Action. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 9 14:08:10 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9803A6B57 for ; Wed, 9 Jul 2008 14:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1MN-lG8nzSk for ; Wed, 9 Jul 2008 14:08:09 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 92E023A6B6C for ; Wed, 9 Jul 2008 14:08:09 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BE7831C40FB3 for ; Wed, 9 Jul 2008 14:08:22 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 4FB31440158 for ; Wed, 9 Jul 2008 14:08:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2594234AC02E for ; Wed, 9 Jul 2008 14:08:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E240B34AC054 for ; Wed, 9 Jul 2008 14:08:11 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 9 Jul 2008 14:08:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,333,1212364800"; d="scan'208";a="64191381" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 09 Jul 2008 21:07:59 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m69L7xK6001906; Wed, 9 Jul 2008 14:07:59 -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.13.8/8.13.8) with ESMTP id m69L7x4r023296; Wed, 9 Jul 2008 21:07:59 GMT 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, 9 Jul 2008 14:07:59 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 14:07:28 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20614E0E5@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS Thread-Index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4AAJ/T4MAACq6GwAAN5BbA= References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com><4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED20E@xmb-sjc-223.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , "Abhijit Choudhury (achoudhu)" , , , "Joseph Salowey (jsalowey)" X-OriginalArrivalTime: 09 Jul 2008 21:07:59.0514 (UTC) FILETIME=[DDDFCFA0:01C8E207] Authentication-Results: sj-dkim-4; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] crypto algorithms for 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 Trying again - the e-mail somehow never made it to the capwap list. PatC -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Wednesday, July 09, 2008 12:29 PM To: Abhijit Choudhury (achoudhu); 'Dorothy.Gellert@nokia.com'; 'skelly@arubanetworks.com'; Joseph Salowey (jsalowey) Cc: 'capwap@frascone.com' Subject: RE: [Capwap] crypto algorithms for DTLS Importance: High Ah, so this is a much larger change than simply adding two ciphers as MAY. I don't have visibility into TLS1.2 and DTLS1.2, and therefore have no idea whether this would break anything. Scott and CAPWAP chairs, do we go ahead with this change? Given it has been through IETF and IESG review, I suspect it would make sense to use the latest version. PatC -----Original Message----- From: Abhijit Choudhury (achoudhu) Sent: Wednesday, July 09, 2008 11:23 AM To: Dorothy.Gellert@nokia.com; Pat Calhoun (pacalhou); skelly@arubanetworks.com; Joseph Salowey (jsalowey) Cc: capwap@frascone.com Subject: RE: [Capwap] crypto algorithms for DTLS Hi Dorothy, Please note that AES-GCM requires TLS1.2 which is currently in AUTH48 state in the RFC-editors queue and should be published shortly. DTLS1.2, which is based on TLS1.2, is working group item and will most likely make it to last call after next IETF. I would suggest we reference TLS1.2 and add the AES-GCM ciphersuites as MAY. Also, in order to ensure that CAPWAP track DTLS better, we should change the text in section 2.4.4.1 from "Note that only block ciphers are currently recommended for use with DTLS. To understand the reasoning behind this, see [DTLS-DESIGN]." To "CAPWAP implementations only use cipher suites that are recommended for use with DTLS. Note that certain stream ciphers, such as RC4, that cannot be randomly accessed may not be used with DTLS." Thoughts ? Abhijit -----Original Message----- From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] Sent: Tuesday, July 08, 2008 4:17 PM To: Pat Calhoun (pacalhou); skelly@arubanetworks.com; Abhijit Choudhury (achoudhu) Cc: capwap@frascone.com Subject: RE: [Capwap] crypto algorithms for DTLS Hi All, Are there any objections in the WG to adding the following cipher suites: TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_DH_RSA_WITH_AES_256_GCM_SHA384 to the base spec as a MAY? If not, based on the list discussion and approved draft status of draft-ietf-tls-rsa-aes-gcm-03.txt, I support including these cipher suites as a MAY in the next(last) WGLC. Best Regards, Dorothy > -----Original Message----- > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Tuesday, July 08, 2008 4:06 PM > To: Scott Kelly; Abhijit Choudhury (achoudhu) > Cc: capwap > Subject: Re: [Capwap] crypto algorithms for DTLS > > Oh, and just to make sure, if we were to go ahead with this, the > following cipher suites would be added: > > TLS_RSA_WITH_AES_128_GCM_SHA256 > TLS_DH_RSA_WITH_AES_256_GCM_SHA384 > > Right? > > PatC > > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Tuesday, July 08, 2008 3:57 PM > To: Scott Kelly; Abhijit Choudhury (achoudhu) > Cc: capwap > Subject: Re: [Capwap] crypto algorithms for DTLS > > CAPWAP Chairs, > > I am done with the edits, and ready to submit the spec for the WG Last > Call. This is a new feature, and we had agreed to defer to the next > version of the protocol. However, the IETF has completed the long > pole, and the change, as a MAY, is fairly minor. What would you > recommend? > > PatC > > -----Original Message----- > From: Scott Kelly [mailto:skelly@arubanetworks.com] > Sent: Tuesday, July 08, 2008 3:42 PM > To: Abhijit Choudhury (achoudhu) > Cc: capwap > Subject: Re: [Capwap] crypto algorithms for DTLS > > Hi Abhijit, > > > > > Folks, > > > > The issue of using AES-GCM as a cipher-suite for CAPWAP/DTLS was > > discussed in the list about a year ago. (Please refer to > CAPWAP issue > > > 7 > > (http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue7) > > > > Due to the use of DTLS, we were stuck with TLS ciphersuites. > > To use GCM we would require a TLS GCM ciphersuite. We > discussed this > > at an ad-hoc meeting, and decided to defer this feature, as GCM was > > not a TLS ciphersuite, and there was no document to reference. > > > > However, since that time, use of AES-GCM has been approved > in the TLS > > working group, and we have an approved draft > > https://datatracker.ietf.org/idtracker/draft-ietf-tls-rsa-aes-gcm/ > > > > As noted in the original email, there is a lot of momentum > behind this > > > crypto algorithm, and it results in significant improvements in > > throughput in either HW or SW implementations. > > > > Could we address this issue in the current spec and make AES-GCM an > > ciphersuite that can be used with CAPWAP/DTLS ? > > I have no objections to adding support for AES-GCM as a MAY. > The original proposal suggested making it mandatory to implement, but > given the current lack of support in commodity crypto HW, I don't > think this would be appropriate at this time. > > --Scott > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/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 Jul 9 14:20:01 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F12B83A6BA1 for ; Wed, 9 Jul 2008 14:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJtbtmMD16ca for ; Wed, 9 Jul 2008 14:20:01 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2CC553A6B9C for ; Wed, 9 Jul 2008 14:20:01 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5A0141C40FB5 for ; Wed, 9 Jul 2008 14:20:14 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id AE7F0440158 for ; Wed, 9 Jul 2008 14:20:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 08ECA34AC04F for ; Wed, 9 Jul 2008 14:20:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5EAAA34AC063 for ; Wed, 9 Jul 2008 14:20:00 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from mail.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by mx1.tigertech.net (Postfix) with SMTP for ; Wed, 9 Jul 2008 14:20:00 -0700 (PDT) Received: from aruba-mx2.arubanetworks.com ([10.1.1.83]) by mail.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jul 2008 14:19:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 14:19:49 -0700 Message-ID: <6F22142CC0DEBE478C659612F9CFCA5001905327@aruba-mx2.arubanetworks.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20614E0E5@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS Thread-Index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4AAJ/T4MAACq6GwAAN5BbAAAC6JcA== References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com><4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED20E@xmb-sjc-223.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20614E0E5@xmb-sjc-235.amer.cisco.com> From: "Scott Kelly" To: "Pat Calhoun (pacalhou)" , "Abhijit Choudhury (achoudhu)" , , "Joseph Salowey (jsalowey)" X-OriginalArrivalTime: 09 Jul 2008 21:19:59.0705 (UTC) FILETIME=[8B243C90:01C8E209] Cc: capwap@frascone.com Subject: Re: [Capwap] crypto algorithms for 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 Pat Calhoun wrote: > Ah, so this is a much larger change than simply adding two ciphers as > MAY. I don't have visibility into TLS1.2 and DTLS1.2, and > therefore have > no idea whether this would break anything. > > Scott and CAPWAP chairs, do we go ahead with this change? Given it has > been through IETF and IESG review, I suspect it would make > sense to use > the latest version. Referencing DTLS algs which are not yet standardized seems a little bit risky, and also would require a bit of wink wink nudge nudge in the process. Kind of calls the credibility of this whole exercise into question. How bad would it be to wait? It would simply require spinning out a new brief 3-5 page doc updating to DTLS1.2. This wouldn't prevent anyone who wants to from implementing the algorithms. Is there any compelling reason to ram this through rather than waiting for DTLS1.2 to be published? --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 Wed Jul 9 14:49:58 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 577C43A67B0 for ; Wed, 9 Jul 2008 14:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ox17tVJY8Rwg for ; Wed, 9 Jul 2008 14:49:57 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 272B928C0E8 for ; Wed, 9 Jul 2008 14:49:57 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 689B01C40F79 for ; Wed, 9 Jul 2008 14:50:10 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 7038B4400CA for ; Wed, 9 Jul 2008 14:49:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D1A36361001A for ; Wed, 9 Jul 2008 14:49:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 466E534AC016 for ; Wed, 9 Jul 2008 14:49:34 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.68.10.86 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 9 Jul 2008 14:49:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,333,1212364800"; d="scan'208";a="17590145" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 09 Jul 2008 21:49:33 +0000 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/8.12.11) with ESMTP id m69LnX2f014436; Wed, 9 Jul 2008 14:49:33 -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.13.8/8.13.8) with ESMTP id m69LnW2t001888; Wed, 9 Jul 2008 21:49:33 GMT Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 14:49:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 14:49:31 -0700 Message-ID: <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED3E0@xmb-sjc-223.amer.cisco.com> In-Reply-To: <6F22142CC0DEBE478C659612F9CFCA5001905327@aruba-mx2.arubanetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS thread-index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4AAJ/T4MAACq6GwAAN5BbAAAC6JcAAA6tGw References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com><4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED20E@xmb-sjc-223.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20614E0E5@xmb-sjc-235.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905327@aruba-mx2.arubanetworks.com> From: "Abhijit Choudhury (achoudhu)" To: "Scott Kelly" , "Pat Calhoun (pacalhou)" , , "Joseph Salowey (jsalowey)" X-OriginalArrivalTime: 09 Jul 2008 21:49:32.0682 (UTC) FILETIME=[ABEB0EA0:01C8E20D] Authentication-Results: sj-dkim-2; header.From=achoudhu@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] crypto algorithms for 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 Hi Scott, My understanding is that DTLS1.2 will use the ciphers specified in TLS1.2, which has already been approved. The DTLS1.2 spec will not have new ciphers, but will possibly have details on how to use these ciphers in DTLS. Please correct me if I'm wrong here. So, we should be okay adding these approved TLS ciphers to the OPTIONAL list, although it's true that they will not be used until DTLS1.2 is finalized. But the list is only OPTIONAL and there are other optional ciphers as well. If we take this path, we don't have to touch this spec later to add these ciphers. If we go the other route, how do we see it being done ? Will we need a draft to specify just the deltas in using DTLS1.2 for CAPWAP ? The concern I have is that it's not clear if the CAPWAP WG will be active at that point to take up this new work item. Thoughts ? Abhijit -----Original Message----- From: Scott Kelly [mailto:skelly@arubanetworks.com] Sent: Wednesday, July 09, 2008 2:20 PM To: Pat Calhoun (pacalhou); Abhijit Choudhury (achoudhu); Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) Cc: capwap@frascone.com Subject: RE: [Capwap] crypto algorithms for DTLS Pat Calhoun wrote: > Ah, so this is a much larger change than simply adding two ciphers as > MAY. I don't have visibility into TLS1.2 and DTLS1.2, and therefore > have no idea whether this would break anything. > > Scott and CAPWAP chairs, do we go ahead with this change? Given it has > been through IETF and IESG review, I suspect it would make sense to > use the latest version. Referencing DTLS algs which are not yet standardized seems a little bit risky, and also would require a bit of wink wink nudge nudge in the process. Kind of calls the credibility of this whole exercise into question. How bad would it be to wait? It would simply require spinning out a new brief 3-5 page doc updating to DTLS1.2. This wouldn't prevent anyone who wants to from implementing the algorithms. Is there any compelling reason to ram this through rather than waiting for DTLS1.2 to be published? --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 Jul 10 09:15:01 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D2C3A6918 for ; Thu, 10 Jul 2008 09:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id de24Acq67eQ6 for ; Thu, 10 Jul 2008 09:15:01 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 0BB873A6891 for ; Thu, 10 Jul 2008 09:15:00 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 173CF433BE0 for ; Thu, 10 Jul 2008 09:15:16 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 802CD440161 for ; Thu, 10 Jul 2008 09:14:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8037134AC071 for ; Thu, 10 Jul 2008 09:14:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C9C0A34AC09C for ; Thu, 10 Jul 2008 09:14:16 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from mail.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by mx1.tigertech.net (Postfix) with SMTP for ; Thu, 10 Jul 2008 09:14:16 -0700 (PDT) Received: from aruba-mx2.arubanetworks.com ([10.1.1.83]) by mail.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jul 2008 09:14:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 09:13:55 -0700 Message-ID: <6F22142CC0DEBE478C659612F9CFCA5001905402@aruba-mx2.arubanetworks.com> In-Reply-To: <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED3E0@xmb-sjc-223.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS Thread-Index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4AAJ/T4MAACq6GwAAN5BbAAAC6JcAAA6tGwACaxvkA= References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com><4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED20E@xmb-sjc-223.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20614E0E5@xmb-sjc-235.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905327@aruba-mx2.arubanetworks.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED3E0@xmb-sjc-223.amer.cisco.com> From: "Scott Kelly" To: "Abhijit Choudhury (achoudhu)" , "Pat Calhoun (pacalhou)" , , "Joseph Salowey (jsalowey)" X-OriginalArrivalTime: 10 Jul 2008 16:14:04.0387 (UTC) FILETIME=[F8EEBB30:01C8E2A7] Cc: capwap@frascone.com Subject: Re: [Capwap] crypto algorithms for 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 Hi Abhijit, > My understanding is that DTLS1.2 will use the ciphers > specified in TLS1.2, which has already been approved. > The DTLS1.2 spec will not have new ciphers, but will > possibly have details on how to use these ciphers in DTLS. > Please correct me if I'm wrong here. > > So, we should be okay adding these approved TLS ciphers > to the OPTIONAL list, although it's true that they will not > be used until DTLS1.2 is finalized. But the list is only > OPTIONAL and there are other optional ciphers as well. > If we take this path, we don't have to touch this spec later > to add these ciphers. I think there's a flaw in this logic. The currently optional ciphers are supported in DTLS1.0 -- you are asking to add ciphers which are not supported in DTLS1.0, meaning a compliant CAPWAP implementation (i.e. one implementing DTLS1.0) will not be able to interoperate with one using these ciphers. > If we go the other route, how do we see it being done ? > Will we need a draft to specify just the deltas in using DTLS1.2 > for CAPWAP ? The concern I have is that it's not clear if > the CAPWAP WG will be active at that point to take up this > new work item. > > Thoughts ? Yes, I think a new, brief document specifying the deltas is exactly what will be required. I also think speculation on the potential (non)existence of the capwap working group should not be the driver here. It isn't very relevant one way or the other. For example, we've published a number of ammendments to IPsec since the wg dissolved, and the ADs willingly sponsored/shepherded these documents through. If for some odd reason (despite the fact that we've just started mib work) the capwap wg dissolves, this should present no impediment to publishing an updated DTLS binding document. It's rarely a good idea to rush such initiatives. --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 Jul 10 09:27:55 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89D6B3A6932 for ; Thu, 10 Jul 2008 09:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+B1vGKWReXQ for ; Thu, 10 Jul 2008 09:27:44 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id BE6CC3A690C for ; Thu, 10 Jul 2008 09:27:44 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 463BF433CC9 for ; Thu, 10 Jul 2008 09:28:00 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id DD43C4400AD for ; Thu, 10 Jul 2008 09:27:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id B335434AC034 for ; Thu, 10 Jul 2008 09:27:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id DD34734AC049 for ; Thu, 10 Jul 2008 09:27:43 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 10 Jul 2008 09:27:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,339,1212364800"; d="scan'208";a="51367077" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 10 Jul 2008 16:27:39 +0000 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/8.12.11) with ESMTP id m6AGRdwA010549; Thu, 10 Jul 2008 09:27:39 -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.13.8/8.13.8) with ESMTP id m6AGRdub017182; Thu, 10 Jul 2008 16:27:39 GMT 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, 10 Jul 2008 09:27:39 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 09:27:38 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20614E3E6@xmb-sjc-235.amer.cisco.com> In-Reply-To: <6F22142CC0DEBE478C659612F9CFCA5001905402@aruba-mx2.arubanetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS Thread-Index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4AAJ/T4MAACq6GwAAN5BbAAAC6JcAAA6tGwACaxvkAAAIFB8A== References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com><4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED20E@xmb-sjc-223.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20614E0E5@xmb-sjc-235.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905327@aruba-mx2.arubanetworks.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED3E0@xmb-sjc-223.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905402@aruba-mx2.arubanetworks.com> From: "Pat Calhoun (pacalhou)" To: "Scott Kelly" , "Abhijit Choudhury (achoudhu)" , , "Joseph Salowey (jsalowey)" X-OriginalArrivalTime: 10 Jul 2008 16:27:39.0058 (UTC) FILETIME=[DE83A920:01C8E2A9] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] crypto algorithms for 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 Ok, given this debate, and being short on time, I will submit the documents without the GCM ciphers, and therefore will not be making changes from TLS/DTLS1.1 to TLS/DTLS1.2. We can deal with this in a separate document. I would recommend adding the following sentence after the list of supported ciphers in both the certificate and pre-shared key: Additional ciphers MAY be defined in follow on CAPWAP specifications. Ok? PatC -----Original Message----- From: Scott Kelly [mailto:skelly@arubanetworks.com] Sent: Thursday, July 10, 2008 9:14 AM To: Abhijit Choudhury (achoudhu); Pat Calhoun (pacalhou); Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) Cc: capwap@frascone.com Subject: RE: [Capwap] crypto algorithms for DTLS Hi Abhijit, > My understanding is that DTLS1.2 will use the ciphers specified in > TLS1.2, which has already been approved. > The DTLS1.2 spec will not have new ciphers, but will possibly have > details on how to use these ciphers in DTLS. > Please correct me if I'm wrong here. > > So, we should be okay adding these approved TLS ciphers to the > OPTIONAL list, although it's true that they will not be used until > DTLS1.2 is finalized. But the list is only OPTIONAL and there are > other optional ciphers as well. > If we take this path, we don't have to touch this spec later to add > these ciphers. I think there's a flaw in this logic. The currently optional ciphers are supported in DTLS1.0 -- you are asking to add ciphers which are not supported in DTLS1.0, meaning a compliant CAPWAP implementation (i.e. one implementing DTLS1.0) will not be able to interoperate with one using these ciphers. > If we go the other route, how do we see it being done ? > Will we need a draft to specify just the deltas in using DTLS1.2 for > CAPWAP ? The concern I have is that it's not clear if the CAPWAP WG > will be active at that point to take up this new work item. > > Thoughts ? Yes, I think a new, brief document specifying the deltas is exactly what will be required. I also think speculation on the potential (non)existence of the capwap working group should not be the driver here. It isn't very relevant one way or the other. For example, we've published a number of ammendments to IPsec since the wg dissolved, and the ADs willingly sponsored/shepherded these documents through. If for some odd reason (despite the fact that we've just started mib work) the capwap wg dissolves, this should present no impediment to publishing an updated DTLS binding document. It's rarely a good idea to rush such initiatives. --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 Jul 10 09:43:19 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906C33A68E7 for ; Thu, 10 Jul 2008 09:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3LAELuOi9jB for ; Thu, 10 Jul 2008 09:43:18 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 49DFC3A68DB for ; Thu, 10 Jul 2008 09:43:18 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9402C4328AC for ; Thu, 10 Jul 2008 09:43:33 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 8FDB5440164 for ; Thu, 10 Jul 2008 09:43:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 285EB34AC079 for ; Thu, 10 Jul 2008 09:43:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6019534AC02E for ; Thu, 10 Jul 2008 09:42:59 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 10 Jul 2008 09:42:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,339,1212364800"; d="scan'208";a="64465421" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 10 Jul 2008 16:42:58 +0000 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/8.12.11) with ESMTP id m6AGgwam019427; Thu, 10 Jul 2008 09:42:58 -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.13.8/8.13.8) with ESMTP id m6AGgt8M006495; Thu, 10 Jul 2008 16:42:58 GMT Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 09:42:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 09:42:58 -0700 Message-ID: <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED66A@xmb-sjc-223.amer.cisco.com> In-Reply-To: <6F22142CC0DEBE478C659612F9CFCA5001905402@aruba-mx2.arubanetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS thread-index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4AAJ/T4MAACq6GwAAN5BbAAAC6JcAAA6tGwACaxvkAAASF4kA== References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com><4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED20E@xmb-sjc-223.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20614E0E5@xmb-sjc-235.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905327@aruba-mx2.arubanetworks.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED3E0@xmb-sjc-223.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905402@aruba-mx2.arubanetworks.com> From: "Abhijit Choudhury (achoudhu)" To: "Scott Kelly" , "Pat Calhoun (pacalhou)" , , "Joseph Salowey (jsalowey)" X-OriginalArrivalTime: 10 Jul 2008 16:42:57.0607 (UTC) FILETIME=[02031D70:01C8E2AC] Authentication-Results: sj-dkim-1; header.From=achoudhu@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] crypto algorithms for 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 Hi Scott, Please see in-line. Thanks, Abhijit -----Original Message----- From: Scott Kelly [mailto:skelly@arubanetworks.com] Sent: Thursday, July 10, 2008 9:14 AM To: Abhijit Choudhury (achoudhu); Pat Calhoun (pacalhou); Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) Cc: capwap@frascone.com Subject: RE: [Capwap] crypto algorithms for DTLS Hi Abhijit, > My understanding is that DTLS1.2 will use the ciphers specified in > TLS1.2, which has already been approved. > The DTLS1.2 spec will not have new ciphers, but will possibly have > details on how to use these ciphers in DTLS. > Please correct me if I'm wrong here. > > So, we should be okay adding these approved TLS ciphers to the > OPTIONAL list, although it's true that they will not be used until > DTLS1.2 is finalized. But the list is only OPTIONAL and there are > other optional ciphers as well. > If we take this path, we don't have to touch this spec later to add > these ciphers. I think there's a flaw in this logic. The currently optional ciphers are supported in DTLS1.0 -- you are asking to add ciphers which are not supported in DTLS1.0, meaning a compliant CAPWAP implementation (i.e. one implementing DTLS1.0) will not be able to interoperate with one using these ciphers. [Abhijit] I don't buy this argument. Let's say we go down the route of creating a separate document in the future to add the DTLS1.2 ciphers. What changes ? A compliant DTLS1.0 implementation will be able to interoperate with a compliant DTLS1.2 implementation using the DTLS1.0 ciphers, but not with the new AEAD ciphers. So, the negotiation of the ciphersuite pretty much decides the interoperability. > If we go the other route, how do we see it being done ? > Will we need a draft to specify just the deltas in using DTLS1.2 for > CAPWAP ? The concern I have is that it's not clear if the CAPWAP WG > will be active at that point to take up this new work item. > > Thoughts ? Yes, I think a new, brief document specifying the deltas is exactly what will be required. I also think speculation on the potential (non)existence of the capwap working group should not be the driver here. It isn't very relevant one way or the other. For example, we've published a number of ammendments to IPsec since the wg dissolved, and the ADs willingly sponsored/shepherded these documents through. If for some odd reason (despite the fact that we've just started mib work) the capwap wg dissolves, this should present no impediment to publishing an updated DTLS binding document. It's rarely a good idea to rush such initiatives. --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 Jul 10 09:50:25 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C323D3A697A for ; Thu, 10 Jul 2008 09:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sUb+Jbi5-eU for ; Thu, 10 Jul 2008 09:50:24 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 9BC253A690C for ; Thu, 10 Jul 2008 09:50:24 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2088B433CC9 for ; Thu, 10 Jul 2008 09:50:40 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 94A0544015F for ; Thu, 10 Jul 2008 09:50:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 43F9D34AC02D for ; Thu, 10 Jul 2008 09:50:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 77A0234AC078 for ; Thu, 10 Jul 2008 09:50:25 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.68.10.86 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 10 Jul 2008 09:50:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,339,1212364800"; d="scan'208";a="17684590" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 10 Jul 2008 16:50:25 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6AGoNFc020838; Thu, 10 Jul 2008 09:50:23 -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.13.8/8.13.8) with ESMTP id m6AGoNTJ024855; Thu, 10 Jul 2008 16:50:23 GMT 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); Thu, 10 Jul 2008 09:50:23 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 09:50:22 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20614E416@xmb-sjc-235.amer.cisco.com> In-Reply-To: <6F22142CC0DEBE478C659612F9CFCA50019052D2@aruba-mx2.arubanetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS Thread-Index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4AAJxBJoAAAu+tgAC+dTsA= References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com><4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED1ED@xmb-sjc-223.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA50019052D2@aruba-mx2.arubanetworks.com> From: "Pat Calhoun (pacalhou)" To: "Scott Kelly" , "Abhijit Choudhury (achoudhu)" , , "Joseph Salowey (jsalowey)" X-OriginalArrivalTime: 10 Jul 2008 16:50:23.0474 (UTC) FILETIME=[0BC50520:01C8E2AD] Authentication-Results: sj-dkim-4; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] crypto algorithms for 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 I changed ciphers from DH to DHE. PatC -----Original Message----- From: Scott Kelly [mailto:skelly@arubanetworks.com] Sent: Wednesday, July 09, 2008 11:08 AM To: Abhijit Choudhury (achoudhu); Dorothy.Gellert@nokia.com; Pat Calhoun (pacalhou); Joseph Salowey (jsalowey) Cc: capwap@frascone.com Subject: RE: [Capwap] crypto algorithms for DTLS Hi Abhijit, Yes, it should be DHE - this has come up several times now, but keeps falling through the cracks somehow. --Scott > -----Original Message----- > From: Abhijit Choudhury (achoudhu) [mailto:achoudhu@cisco.com] > Sent: Wednesday, July 09, 2008 11:00 AM > To: Dorothy.Gellert@nokia.com; Pat Calhoun (pacalhou); Scott Kelly; > Joseph Salowey (jsalowey) > Cc: capwap@frascone.com > Subject: RE: [Capwap] crypto algorithms for DTLS > > I'm okay with adding AES-GCM support as a MAY. > However, I'd suggest we add the following ciphers: > > TLS_RSA_WITH_AES_128_GCM_SHA256 > TLS_RSA_WITH_AES_256_GCM_SHA384 > > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 > > > Also, in the current spec, shouldn't we be specifying DHE instead of > DH in the cipher suite recommendations. > > Scott, Charles, Joe: any thoughts on this ? > > Thanks, > Abhijit > > > > -----Original Message----- > From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] > Sent: Tuesday, July 08, 2008 4:17 PM > To: Pat Calhoun (pacalhou); skelly@arubanetworks.com; Abhijit > Choudhury > (achoudhu) > Cc: capwap@frascone.com > Subject: RE: [Capwap] crypto algorithms for DTLS > > Hi All, > > Are there any objections in the WG to adding the following cipher > suites: > TLS_RSA_WITH_AES_128_GCM_SHA256 > TLS_DH_RSA_WITH_AES_256_GCM_SHA384 to the base spec as a MAY? > > If not, based on the list discussion and approved draft status of > draft-ietf-tls-rsa-aes-gcm-03.txt, I support including these cipher > suites as a MAY in the next(last) WGLC. > > Best Regards, > Dorothy > > > > -----Original Message----- > > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Tuesday, July 08, 2008 4:06 PM > > To: Scott Kelly; Abhijit Choudhury (achoudhu) > > Cc: capwap > > Subject: Re: [Capwap] crypto algorithms for DTLS > > > > Oh, and just to make sure, if we were to go ahead with this, the > > following cipher suites would be added: > > > > TLS_RSA_WITH_AES_128_GCM_SHA256 > > TLS_DH_RSA_WITH_AES_256_GCM_SHA384 > > > > Right? > > > > PatC > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) > > Sent: Tuesday, July 08, 2008 3:57 PM > > To: Scott Kelly; Abhijit Choudhury (achoudhu) > > Cc: capwap > > Subject: Re: [Capwap] crypto algorithms for DTLS > > > > CAPWAP Chairs, > > > > I am done with the edits, and ready to submit the spec for > the WG Last > > > Call. This is a new feature, and we had agreed to defer to the next > > version of the protocol. However, the IETF has completed the long > > pole, and the change, as a MAY, is fairly minor. What would you > > recommend? > > > > PatC > > > > -----Original Message----- > > From: Scott Kelly [mailto:skelly@arubanetworks.com] > > Sent: Tuesday, July 08, 2008 3:42 PM > > To: Abhijit Choudhury (achoudhu) > > Cc: capwap > > Subject: Re: [Capwap] crypto algorithms for DTLS > > > > Hi Abhijit, > > > > > > > > Folks, > > > > > > The issue of using AES-GCM as a cipher-suite for CAPWAP/DTLS was > > > discussed in the list about a year ago. (Please refer to > > CAPWAP issue > > > > > 7 > > > (http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue7) > > > > > > Due to the use of DTLS, we were stuck with TLS ciphersuites. > > > To use GCM we would require a TLS GCM ciphersuite. We > > discussed this > > > at an ad-hoc meeting, and decided to defer this feature, > as GCM was > > > not a TLS ciphersuite, and there was no document to reference. > > > > > > However, since that time, use of AES-GCM has been approved > > in the TLS > > > working group, and we have an approved draft > > > https://datatracker.ietf.org/idtracker/draft-ietf-tls-rsa-aes-gcm/ > > > > > > As noted in the original email, there is a lot of momentum > > behind this > > > > > crypto algorithm, and it results in significant improvements in > > > throughput in either HW or SW implementations. > > > > > > Could we address this issue in the current spec and make > AES-GCM an > > > ciphersuite that can be used with CAPWAP/DTLS ? > > > > I have no objections to adding support for AES-GCM as a MAY. > > The original proposal suggested making it mandatory to > implement, but > > given the current lack of support in commodity crypto HW, I don't > > think this would be appropriate at this time. > > > > --Scott > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/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 Jul 10 09:52:48 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B06D3A690C for ; Thu, 10 Jul 2008 09:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiYO0I8UDpkx for ; Thu, 10 Jul 2008 09:52:47 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 20F253A67A3 for ; Thu, 10 Jul 2008 09:52:47 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CB6A9433CF8 for ; Thu, 10 Jul 2008 09:52:58 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 1CF9544015F for ; Thu, 10 Jul 2008 09:52:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D39E334AC0EB for ; Thu, 10 Jul 2008 09:52:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id F1EF634AC08A for ; Thu, 10 Jul 2008 09:52:23 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 10 Jul 2008 09:52:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,339,1212364800"; d="scan'208";a="125019552" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 10 Jul 2008 16:52:23 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6AGqNpn009293; Thu, 10 Jul 2008 09:52:23 -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.13.8/8.13.8) with ESMTP id m6AGqNnV027317; Thu, 10 Jul 2008 16:52:23 GMT Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 09:52:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 09:52:22 -0700 Message-ID: <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED67B@xmb-sjc-223.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20614E3E6@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS thread-index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4AAJ/T4MAACq6GwAAN5BbAAAC6JcAAA6tGwACaxvkAAAIFB8AAAx3QA References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com><4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED20E@xmb-sjc-223.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20614E0E5@xmb-sjc-235.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905327@aruba-mx2.arubanetworks.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED3E0@xmb-sjc-223.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905402@aruba-mx2.arubanetworks.com> <4FF84B0BC277FF45AA27FE969DD956A20614E3E6@xmb-sjc-235.amer.cisco.com> From: "Abhijit Choudhury (achoudhu)" To: "Pat Calhoun (pacalhou)" , "Scott Kelly" , , "Joseph Salowey (jsalowey)" X-OriginalArrivalTime: 10 Jul 2008 16:52:22.0892 (UTC) FILETIME=[52F2C2C0:01C8E2AD] Authentication-Results: sj-dkim-1; header.From=achoudhu@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] crypto algorithms for 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 Okay. I'm fine with defering this. Let's not delay the current spec. I'd suggest the following changes: 1. In order to ensure that CAPWAP track DTLS better, we should change the text in section 2.4.4.1 from "Note that only block ciphers are currently recommended for use with DTLS. To understand the reasoning behind this, see [DTLS-DESIGN]." To "CAPWAP implementations only use cipher suites that are recommended for use with DTLS." 2. Change the existing ciphers using DH to DHE. Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Thursday, July 10, 2008 9:28 AM To: Scott Kelly; Abhijit Choudhury (achoudhu); Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) Cc: capwap@frascone.com Subject: RE: [Capwap] crypto algorithms for DTLS Ok, given this debate, and being short on time, I will submit the documents without the GCM ciphers, and therefore will not be making changes from TLS/DTLS1.1 to TLS/DTLS1.2. We can deal with this in a separate document. I would recommend adding the following sentence after the list of supported ciphers in both the certificate and pre-shared key: Additional ciphers MAY be defined in follow on CAPWAP specifications. Ok? PatC -----Original Message----- From: Scott Kelly [mailto:skelly@arubanetworks.com] Sent: Thursday, July 10, 2008 9:14 AM To: Abhijit Choudhury (achoudhu); Pat Calhoun (pacalhou); Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) Cc: capwap@frascone.com Subject: RE: [Capwap] crypto algorithms for DTLS Hi Abhijit, > My understanding is that DTLS1.2 will use the ciphers specified in > TLS1.2, which has already been approved. > The DTLS1.2 spec will not have new ciphers, but will possibly have > details on how to use these ciphers in DTLS. > Please correct me if I'm wrong here. > > So, we should be okay adding these approved TLS ciphers to the > OPTIONAL list, although it's true that they will not be used until > DTLS1.2 is finalized. But the list is only OPTIONAL and there are > other optional ciphers as well. > If we take this path, we don't have to touch this spec later to add > these ciphers. I think there's a flaw in this logic. The currently optional ciphers are supported in DTLS1.0 -- you are asking to add ciphers which are not supported in DTLS1.0, meaning a compliant CAPWAP implementation (i.e. one implementing DTLS1.0) will not be able to interoperate with one using these ciphers. > If we go the other route, how do we see it being done ? > Will we need a draft to specify just the deltas in using DTLS1.2 for > CAPWAP ? The concern I have is that it's not clear if the CAPWAP WG > will be active at that point to take up this new work item. > > Thoughts ? Yes, I think a new, brief document specifying the deltas is exactly what will be required. I also think speculation on the potential (non)existence of the capwap working group should not be the driver here. It isn't very relevant one way or the other. For example, we've published a number of ammendments to IPsec since the wg dissolved, and the ADs willingly sponsored/shepherded these documents through. If for some odd reason (despite the fact that we've just started mib work) the capwap wg dissolves, this should present no impediment to publishing an updated DTLS binding document. It's rarely a good idea to rush such initiatives. --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 Jul 10 10:18:33 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EE173A692A for ; Thu, 10 Jul 2008 10:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6MpxnNvXR0x for ; Thu, 10 Jul 2008 10:18:32 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 49DB63A68B8 for ; Thu, 10 Jul 2008 10:18:32 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8D2D0433DCC for ; Thu, 10 Jul 2008 10:18:47 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id B016C440166 for ; Thu, 10 Jul 2008 10:17:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 435CC34AC0AA for ; Thu, 10 Jul 2008 10:17:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id AA94834AC08D for ; Thu, 10 Jul 2008 10:17:36 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.68.10.86 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 10 Jul 2008 10:17:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,339,1212364800"; d="scan'208";a="17692266" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 10 Jul 2008 17:17:36 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6AHHacv024519; Thu, 10 Jul 2008 10:17:36 -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.13.8/8.13.8) with ESMTP id m6AHHaLI028039; Thu, 10 Jul 2008 17:17:36 GMT 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.1830); Thu, 10 Jul 2008 10:17:36 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 10:17:34 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20614E45C@xmb-sjc-235.amer.cisco.com> In-Reply-To: <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED67B@xmb-sjc-223.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS Thread-Index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4AAJ/T4MAACq6GwAAN5BbAAAC6JcAAA6tGwACaxvkAAAIFB8AAAx3QAAAEpXEA= References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com><4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED20E@xmb-sjc-223.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20614E0E5@xmb-sjc-235.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905327@aruba-mx2.arubanetworks.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED3E0@xmb-sjc-223.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905402@aruba-mx2.arubanetworks.com> <4FF84B0BC277FF45AA27FE969DD956A20614E3E6@xmb-sjc-235.amer.cisco.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED67B@xmb-sjc-223.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Abhijit Choudhury (achoudhu)" , "Scott Kelly" , , "Joseph Salowey (jsalowey)" X-OriginalArrivalTime: 10 Jul 2008 17:17:36.0257 (UTC) FILETIME=[D8FBEF10:01C8E2B0] Authentication-Results: sj-dkim-4; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] crypto algorithms for 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 Out of curiosity, what is different in your text, other than removing the reference to a document that, I guess, provides more clarity on why this statement is made? Is it the explicit removal of block ciphers that is what's desired here? PatC -----Original Message----- From: Abhijit Choudhury (achoudhu) Sent: Thursday, July 10, 2008 9:52 AM To: Pat Calhoun (pacalhou); 'Scott Kelly'; 'Dorothy.Gellert@nokia.com'; Joseph Salowey (jsalowey) Cc: 'capwap@frascone.com' Subject: RE: [Capwap] crypto algorithms for DTLS Okay. I'm fine with defering this. Let's not delay the current spec. I'd suggest the following changes: 1. In order to ensure that CAPWAP track DTLS better, we should change the text in section 2.4.4.1 from "Note that only block ciphers are currently recommended for use with DTLS. To understand the reasoning behind this, see [DTLS-DESIGN]." To "CAPWAP implementations only use cipher suites that are recommended for use with DTLS." 2. Change the existing ciphers using DH to DHE. Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Thursday, July 10, 2008 9:28 AM To: Scott Kelly; Abhijit Choudhury (achoudhu); Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) Cc: capwap@frascone.com Subject: RE: [Capwap] crypto algorithms for DTLS Ok, given this debate, and being short on time, I will submit the documents without the GCM ciphers, and therefore will not be making changes from TLS/DTLS1.1 to TLS/DTLS1.2. We can deal with this in a separate document. I would recommend adding the following sentence after the list of supported ciphers in both the certificate and pre-shared key: Additional ciphers MAY be defined in follow on CAPWAP specifications. Ok? PatC -----Original Message----- From: Scott Kelly [mailto:skelly@arubanetworks.com] Sent: Thursday, July 10, 2008 9:14 AM To: Abhijit Choudhury (achoudhu); Pat Calhoun (pacalhou); Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) Cc: capwap@frascone.com Subject: RE: [Capwap] crypto algorithms for DTLS Hi Abhijit, > My understanding is that DTLS1.2 will use the ciphers specified in > TLS1.2, which has already been approved. > The DTLS1.2 spec will not have new ciphers, but will possibly have > details on how to use these ciphers in DTLS. > Please correct me if I'm wrong here. > > So, we should be okay adding these approved TLS ciphers to the > OPTIONAL list, although it's true that they will not be used until > DTLS1.2 is finalized. But the list is only OPTIONAL and there are > other optional ciphers as well. > If we take this path, we don't have to touch this spec later to add > these ciphers. I think there's a flaw in this logic. The currently optional ciphers are supported in DTLS1.0 -- you are asking to add ciphers which are not supported in DTLS1.0, meaning a compliant CAPWAP implementation (i.e. one implementing DTLS1.0) will not be able to interoperate with one using these ciphers. > If we go the other route, how do we see it being done ? > Will we need a draft to specify just the deltas in using DTLS1.2 for > CAPWAP ? The concern I have is that it's not clear if the CAPWAP WG > will be active at that point to take up this new work item. > > Thoughts ? Yes, I think a new, brief document specifying the deltas is exactly what will be required. I also think speculation on the potential (non)existence of the capwap working group should not be the driver here. It isn't very relevant one way or the other. For example, we've published a number of ammendments to IPsec since the wg dissolved, and the ADs willingly sponsored/shepherded these documents through. If for some odd reason (despite the fact that we've just started mib work) the capwap wg dissolves, this should present no impediment to publishing an updated DTLS binding document. It's rarely a good idea to rush such initiatives. --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 Jul 10 11:26:11 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2352E3A6A1A for ; Thu, 10 Jul 2008 11:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ys8hYZ8KXXPW for ; Thu, 10 Jul 2008 11:26:09 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id E07273A69E5 for ; Thu, 10 Jul 2008 11:26:09 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 502F81C40F8B for ; Thu, 10 Jul 2008 11:26:25 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 7CA784400A3 for ; Thu, 10 Jul 2008 11:26:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4280534AC081 for ; Thu, 10 Jul 2008 11:26:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id DF04434AC079 for ; Thu, 10 Jul 2008 11:26:10 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 10 Jul 2008 11:26:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,339,1212364800"; d="scan'208";a="51441388" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 10 Jul 2008 18:25:52 +0000 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/8.12.11) with ESMTP id m6AIPqek013107; Thu, 10 Jul 2008 11:25:52 -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.13.8/8.13.8) with ESMTP id m6AIPnIj019754; Thu, 10 Jul 2008 18:25:52 GMT Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 11:25:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 11:25:39 -0700 Message-ID: <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED74C@xmb-sjc-223.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20614E45C@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS thread-index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4AAJ/T4MAACq6GwAAN5BbAAAC6JcAAA6tGwACaxvkAAAIFB8AAAx3QAAAEpXEAAAjnkIA== References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com><4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED20E@xmb-sjc-223.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20614E0E5@xmb-sjc-235.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905327@aruba-mx2.arubanetworks.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED3E0@xmb-sjc-223.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905402@aruba-mx2.arubanetworks.com> <4FF84B0BC277FF45AA27FE969DD956A20614E3E6@xmb-sjc-235.amer.cisco.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED67B@xmb-sjc-223.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20614E45C@xmb-sjc-235.amer.cisc o.com> From: "Abhijit Choudhury (achoudhu)" To: "Pat Calhoun (pacalhou)" , "Scott Kelly" , , "Joseph Salowey (jsalowey)" X-OriginalArrivalTime: 10 Jul 2008 18:25:39.0892 (UTC) FILETIME=[5B052F40:01C8E2BA] Authentication-Results: sj-dkim-2; header.From=achoudhu@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] crypto algorithms for 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 Yes, CAPWAP doesn't need to constrain the ciphers to block ciphers. The real reason is that CAPWAP tracks DTLS1.0 which tracks TLS1.1, which uses block ciphers. So, it'd be better to say explicitly that we only use ciphers recommended for DTLS. This way, it'll be easier to upgrade later to DTLS1.2, without having to change text in this spec. We could include the reference... That's fine. So, how about this: Replace the text in section 2.4.4.1 from "Note that only block ciphers are currently recommended for use with DTLS. To understand the reasoning behind this, see [DTLS-DESIGN]." To "CAPWAP implementations only use cipher suites that are recommended for use with DTLS [DTLS-DESIGN]." Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Thursday, July 10, 2008 10:18 AM To: Abhijit Choudhury (achoudhu); 'Scott Kelly'; 'Dorothy.Gellert@nokia.com'; Joseph Salowey (jsalowey) Cc: 'capwap@frascone.com' Subject: RE: [Capwap] crypto algorithms for DTLS Out of curiosity, what is different in your text, other than removing the reference to a document that, I guess, provides more clarity on why this statement is made? Is it the explicit removal of block ciphers that is what's desired here? PatC -----Original Message----- From: Abhijit Choudhury (achoudhu) Sent: Thursday, July 10, 2008 9:52 AM To: Pat Calhoun (pacalhou); 'Scott Kelly'; 'Dorothy.Gellert@nokia.com'; Joseph Salowey (jsalowey) Cc: 'capwap@frascone.com' Subject: RE: [Capwap] crypto algorithms for DTLS Okay. I'm fine with defering this. Let's not delay the current spec. I'd suggest the following changes: 1. In order to ensure that CAPWAP track DTLS better, we should change the text in section 2.4.4.1 from "Note that only block ciphers are currently recommended for use with DTLS. To understand the reasoning behind this, see [DTLS-DESIGN]." To "CAPWAP implementations only use cipher suites that are recommended for use with DTLS." 2. Change the existing ciphers using DH to DHE. Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Thursday, July 10, 2008 9:28 AM To: Scott Kelly; Abhijit Choudhury (achoudhu); Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) Cc: capwap@frascone.com Subject: RE: [Capwap] crypto algorithms for DTLS Ok, given this debate, and being short on time, I will submit the documents without the GCM ciphers, and therefore will not be making changes from TLS/DTLS1.1 to TLS/DTLS1.2. We can deal with this in a separate document. I would recommend adding the following sentence after the list of supported ciphers in both the certificate and pre-shared key: Additional ciphers MAY be defined in follow on CAPWAP specifications. Ok? PatC -----Original Message----- From: Scott Kelly [mailto:skelly@arubanetworks.com] Sent: Thursday, July 10, 2008 9:14 AM To: Abhijit Choudhury (achoudhu); Pat Calhoun (pacalhou); Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) Cc: capwap@frascone.com Subject: RE: [Capwap] crypto algorithms for DTLS Hi Abhijit, > My understanding is that DTLS1.2 will use the ciphers specified in > TLS1.2, which has already been approved. > The DTLS1.2 spec will not have new ciphers, but will possibly have > details on how to use these ciphers in DTLS. > Please correct me if I'm wrong here. > > So, we should be okay adding these approved TLS ciphers to the > OPTIONAL list, although it's true that they will not be used until > DTLS1.2 is finalized. But the list is only OPTIONAL and there are > other optional ciphers as well. > If we take this path, we don't have to touch this spec later to add > these ciphers. I think there's a flaw in this logic. The currently optional ciphers are supported in DTLS1.0 -- you are asking to add ciphers which are not supported in DTLS1.0, meaning a compliant CAPWAP implementation (i.e. one implementing DTLS1.0) will not be able to interoperate with one using these ciphers. > If we go the other route, how do we see it being done ? > Will we need a draft to specify just the deltas in using DTLS1.2 for > CAPWAP ? The concern I have is that it's not clear if the CAPWAP WG > will be active at that point to take up this new work item. > > Thoughts ? Yes, I think a new, brief document specifying the deltas is exactly what will be required. I also think speculation on the potential (non)existence of the capwap working group should not be the driver here. It isn't very relevant one way or the other. For example, we've published a number of ammendments to IPsec since the wg dissolved, and the ADs willingly sponsored/shepherded these documents through. If for some odd reason (despite the fact that we've just started mib work) the capwap wg dissolves, this should present no impediment to publishing an updated DTLS binding document. It's rarely a good idea to rush such initiatives. --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 Jul 10 11:29:57 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 846453A6A58 for ; Thu, 10 Jul 2008 11:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twnpwlhDKYwB for ; Thu, 10 Jul 2008 11:29:56 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 7E2103A690E for ; Thu, 10 Jul 2008 11:29:56 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3807D1C40FA9 for ; Thu, 10 Jul 2008 11:30:12 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 49E564400A3 for ; Thu, 10 Jul 2008 11:29:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 1DCD634AC02E for ; Thu, 10 Jul 2008 11:29:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 9A02534AC02B for ; Thu, 10 Jul 2008 11:29:56 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.72 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 10 Jul 2008 11:29:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,339,1212364800"; d="scan'208";a="86437807" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 10 Jul 2008 18:29:52 +0000 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/8.12.11) with ESMTP id m6AITqbb023030; Thu, 10 Jul 2008 11:29:52 -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.13.8/8.13.8) with ESMTP id m6AITqdk023583; Thu, 10 Jul 2008 18:29:52 GMT 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.1830); Thu, 10 Jul 2008 11:29:51 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 11:29:51 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20614E525@xmb-sjc-235.amer.cisco.com> In-Reply-To: <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED74C@xmb-sjc-223.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS Thread-Index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4AAJ/T4MAACq6GwAAN5BbAAAC6JcAAA6tGwACaxvkAAAIFB8AAAx3QAAAEpXEAAAjnkIAAAU0Ng References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com><4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED20E@xmb-sjc-223.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20614E0E5@xmb-sjc-235.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905327@aruba-mx2.arubanetworks.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED3E0@xmb-sjc-223.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905402@aruba-mx2.arubanetworks.com> <4FF84B0BC277FF45AA27FE969DD956A20614E3E6@xmb-sjc-235.amer.cisco.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED67B@xmb-sjc-223.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20614E45C@xmb-sjc-235.amer.cisc o.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED74C@xmb-sjc-223.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Abhijit Choudhury (achoudhu)" , "Scott Kelly" , , "Joseph Salowey (jsalowey)" X-OriginalArrivalTime: 10 Jul 2008 18:29:51.0899 (UTC) FILETIME=[F13A66B0:01C8E2BA] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] crypto algorithms for 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 Scott - Are you OK with this proposal? PatC -----Original Message----- From: Abhijit Choudhury (achoudhu) Sent: Thursday, July 10, 2008 11:26 AM To: Pat Calhoun (pacalhou); 'Scott Kelly'; 'Dorothy.Gellert@nokia.com'; Joseph Salowey (jsalowey) Cc: 'capwap@frascone.com' Subject: RE: [Capwap] crypto algorithms for DTLS Yes, CAPWAP doesn't need to constrain the ciphers to block ciphers. The real reason is that CAPWAP tracks DTLS1.0 which tracks TLS1.1, which uses block ciphers. So, it'd be better to say explicitly that we only use ciphers recommended for DTLS. This way, it'll be easier to upgrade later to DTLS1.2, without having to change text in this spec. We could include the reference... That's fine. So, how about this: Replace the text in section 2.4.4.1 from "Note that only block ciphers are currently recommended for use with DTLS. To understand the reasoning behind this, see [DTLS-DESIGN]." To "CAPWAP implementations only use cipher suites that are recommended for use with DTLS [DTLS-DESIGN]." Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Thursday, July 10, 2008 10:18 AM To: Abhijit Choudhury (achoudhu); 'Scott Kelly'; 'Dorothy.Gellert@nokia.com'; Joseph Salowey (jsalowey) Cc: 'capwap@frascone.com' Subject: RE: [Capwap] crypto algorithms for DTLS Out of curiosity, what is different in your text, other than removing the reference to a document that, I guess, provides more clarity on why this statement is made? Is it the explicit removal of block ciphers that is what's desired here? PatC -----Original Message----- From: Abhijit Choudhury (achoudhu) Sent: Thursday, July 10, 2008 9:52 AM To: Pat Calhoun (pacalhou); 'Scott Kelly'; 'Dorothy.Gellert@nokia.com'; Joseph Salowey (jsalowey) Cc: 'capwap@frascone.com' Subject: RE: [Capwap] crypto algorithms for DTLS Okay. I'm fine with defering this. Let's not delay the current spec. I'd suggest the following changes: 1. In order to ensure that CAPWAP track DTLS better, we should change the text in section 2.4.4.1 from "Note that only block ciphers are currently recommended for use with DTLS. To understand the reasoning behind this, see [DTLS-DESIGN]." To "CAPWAP implementations only use cipher suites that are recommended for use with DTLS." 2. Change the existing ciphers using DH to DHE. Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Thursday, July 10, 2008 9:28 AM To: Scott Kelly; Abhijit Choudhury (achoudhu); Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) Cc: capwap@frascone.com Subject: RE: [Capwap] crypto algorithms for DTLS Ok, given this debate, and being short on time, I will submit the documents without the GCM ciphers, and therefore will not be making changes from TLS/DTLS1.1 to TLS/DTLS1.2. We can deal with this in a separate document. I would recommend adding the following sentence after the list of supported ciphers in both the certificate and pre-shared key: Additional ciphers MAY be defined in follow on CAPWAP specifications. Ok? PatC -----Original Message----- From: Scott Kelly [mailto:skelly@arubanetworks.com] Sent: Thursday, July 10, 2008 9:14 AM To: Abhijit Choudhury (achoudhu); Pat Calhoun (pacalhou); Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) Cc: capwap@frascone.com Subject: RE: [Capwap] crypto algorithms for DTLS Hi Abhijit, > My understanding is that DTLS1.2 will use the ciphers specified in > TLS1.2, which has already been approved. > The DTLS1.2 spec will not have new ciphers, but will possibly have > details on how to use these ciphers in DTLS. > Please correct me if I'm wrong here. > > So, we should be okay adding these approved TLS ciphers to the > OPTIONAL list, although it's true that they will not be used until > DTLS1.2 is finalized. But the list is only OPTIONAL and there are > other optional ciphers as well. > If we take this path, we don't have to touch this spec later to add > these ciphers. I think there's a flaw in this logic. The currently optional ciphers are supported in DTLS1.0 -- you are asking to add ciphers which are not supported in DTLS1.0, meaning a compliant CAPWAP implementation (i.e. one implementing DTLS1.0) will not be able to interoperate with one using these ciphers. > If we go the other route, how do we see it being done ? > Will we need a draft to specify just the deltas in using DTLS1.2 for > CAPWAP ? The concern I have is that it's not clear if the CAPWAP WG > will be active at that point to take up this new work item. > > Thoughts ? Yes, I think a new, brief document specifying the deltas is exactly what will be required. I also think speculation on the potential (non)existence of the capwap working group should not be the driver here. It isn't very relevant one way or the other. For example, we've published a number of ammendments to IPsec since the wg dissolved, and the ADs willingly sponsored/shepherded these documents through. If for some odd reason (despite the fact that we've just started mib work) the capwap wg dissolves, this should present no impediment to publishing an updated DTLS binding document. It's rarely a good idea to rush such initiatives. --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 Jul 10 11:46:39 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B1F128C14B for ; Thu, 10 Jul 2008 11:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmGj1lpvllyG for ; Thu, 10 Jul 2008 11:46:37 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 9485D28C147 for ; Thu, 10 Jul 2008 11:45:50 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5396A1C40FA6 for ; Thu, 10 Jul 2008 11:46:06 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 48D724400A3 for ; Thu, 10 Jul 2008 11:45:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id A3EEC34AC0EB for ; Thu, 10 Jul 2008 11:45:46 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 20F2534AC0B8 for ; Thu, 10 Jul 2008 11:45:34 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from mail.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by mx1.tigertech.net (Postfix) with SMTP for ; Thu, 10 Jul 2008 11:45:33 -0700 (PDT) Received: from aruba-mx2.arubanetworks.com ([10.1.1.83]) by mail.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jul 2008 11:45:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 11:45:19 -0700 Message-ID: <6F22142CC0DEBE478C659612F9CFCA5001A3159D@aruba-mx2.arubanetworks.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20614E525@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS Thread-Index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4AAJ/T4MAACq6GwAAN5BbAAAC6JcAAA6tGwACaxvkAAAIFB8AAAx3QAAAEpXEAAAjnkIAAAU0NgAAB5fyA= References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com><4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED20E@xmb-sjc-223.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20614E0E5@xmb-sjc-235.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905327@aruba-mx2.arubanetworks.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED3E0@xmb-sjc-223.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905402@aruba-mx2.arubanetworks.com> <4FF84B0BC277FF45AA27FE969DD956A20614E3E6@xmb-sjc-235.amer.cisco.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED67B@xmb-sjc-223.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20614E45C@xmb-sjc-235.amer.cisc o.com> <0A7D 7D6BC1EEF6489C3D0AE1B6B1619506BED74C@xmb-sjc-223.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20614E525@xmb-sjc-235.amer.cisco.com> From: "Scott Kelly" To: "Pat Calhoun (pacalhou)" , "Abhijit Choudhury (achoudhu)" , , "Joseph Salowey (jsalowey)" X-OriginalArrivalTime: 10 Jul 2008 18:45:28.0371 (UTC) FILETIME=[1F68B030:01C8E2BD] Cc: capwap@frascone.com Subject: Re: [Capwap] crypto algorithms for 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 I think this is probably a safe statement. > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Thursday, July 10, 2008 11:30 AM > To: Abhijit Choudhury (achoudhu); Scott Kelly; > Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) > Cc: capwap@frascone.com > Subject: RE: [Capwap] crypto algorithms for DTLS > > Scott - Are you OK with this proposal? > > PatC > > -----Original Message----- > From: Abhijit Choudhury (achoudhu) > Sent: Thursday, July 10, 2008 11:26 AM > To: Pat Calhoun (pacalhou); 'Scott Kelly'; > 'Dorothy.Gellert@nokia.com'; > Joseph Salowey (jsalowey) > Cc: 'capwap@frascone.com' > Subject: RE: [Capwap] crypto algorithms for DTLS > > Yes, CAPWAP doesn't need to constrain the ciphers to block ciphers. > The real reason is that CAPWAP tracks DTLS1.0 which tracks > TLS1.1, which > uses block ciphers. > So, it'd be better to say explicitly that we only use ciphers > recommended for DTLS. This way, it'll be easier to upgrade later to > DTLS1.2, without having to change text in this spec. > > We could include the reference... That's fine. > > So, how about this: > > > Replace the text in section 2.4.4.1 from > > "Note that only block ciphers are currently recommended for use > with DTLS. > To understand the reasoning behind this, see [DTLS-DESIGN]." > > To > > "CAPWAP implementations only use cipher suites that are > recommended for > use with DTLS [DTLS-DESIGN]." > > Thanks, > Abhijit > > > > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, July 10, 2008 10:18 AM > To: Abhijit Choudhury (achoudhu); 'Scott Kelly'; > 'Dorothy.Gellert@nokia.com'; Joseph Salowey (jsalowey) > Cc: 'capwap@frascone.com' > Subject: RE: [Capwap] crypto algorithms for DTLS > > Out of curiosity, what is different in your text, other than removing > the reference to a document that, I guess, provides more > clarity on why > this statement is made? Is it the explicit removal of block > ciphers that > is what's desired here? > > PatC > > -----Original Message----- > From: Abhijit Choudhury (achoudhu) > Sent: Thursday, July 10, 2008 9:52 AM > To: Pat Calhoun (pacalhou); 'Scott Kelly'; > 'Dorothy.Gellert@nokia.com'; > Joseph Salowey (jsalowey) > Cc: 'capwap@frascone.com' > Subject: RE: [Capwap] crypto algorithms for DTLS > > Okay. I'm fine with defering this. Let's not delay the current spec. > > > I'd suggest the following changes: > > 1. In order to ensure that CAPWAP track DTLS better, we should > change the text in section 2.4.4.1 from > > "Note that only block ciphers are currently recommended for use with > DTLS. > To understand the reasoning behind this, see [DTLS-DESIGN]." > > To > > "CAPWAP implementations only use cipher suites that are > recommended for > use with DTLS." > > 2. Change the existing ciphers using DH to DHE. > > > Thanks, > Abhijit > > > > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, July 10, 2008 9:28 AM > To: Scott Kelly; Abhijit Choudhury (achoudhu); > Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) > Cc: capwap@frascone.com > Subject: RE: [Capwap] crypto algorithms for DTLS > > Ok, given this debate, and being short on time, I will submit the > documents without the GCM ciphers, and therefore will not be making > changes from TLS/DTLS1.1 to TLS/DTLS1.2. We can deal with this in a > separate document. I would recommend adding the following > sentence after > the list of supported ciphers in both the certificate and pre-shared > key: > > Additional ciphers MAY be defined in follow on CAPWAP > specifications. > > Ok? > > PatC > > -----Original Message----- > From: Scott Kelly [mailto:skelly@arubanetworks.com] > Sent: Thursday, July 10, 2008 9:14 AM > To: Abhijit Choudhury (achoudhu); Pat Calhoun (pacalhou); > Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) > Cc: capwap@frascone.com > Subject: RE: [Capwap] crypto algorithms for DTLS > > Hi Abhijit, > > > My understanding is that DTLS1.2 will use the ciphers specified in > > TLS1.2, which has already been approved. > > The DTLS1.2 spec will not have new ciphers, but will possibly have > > details on how to use these ciphers in DTLS. > > Please correct me if I'm wrong here. > > > > So, we should be okay adding these approved TLS ciphers to the > > OPTIONAL list, although it's true that they will not be used until > > DTLS1.2 is finalized. But the list is only OPTIONAL and there are > > other optional ciphers as well. > > If we take this path, we don't have to touch this spec later to add > > these ciphers. > > I think there's a flaw in this logic. The currently optional > ciphers are > supported in DTLS1.0 -- you are asking to add ciphers which are not > supported in DTLS1.0, meaning a compliant CAPWAP implementation (i.e. > one implementing DTLS1.0) will not be able to interoperate with one > using these ciphers. > > > If we go the other route, how do we see it being done ? > > Will we need a draft to specify just the deltas in using > DTLS1.2 for > > CAPWAP ? The concern I have is that it's not clear if the > CAPWAP WG > > will be active at that point to take up this new work item. > > > > Thoughts ? > > Yes, I think a new, brief document specifying the deltas is > exactly what > will be required. I also think speculation on the potential > (non)existence of the capwap working group should not be the driver > here. It isn't very relevant one way or the other. For example, we've > published a number of ammendments to IPsec since the wg dissolved, and > the ADs willingly sponsored/shepherded these documents through. If for > some odd reason (despite the fact that we've just started mib > work) the > capwap wg dissolves, this should present no impediment to > publishing an > updated DTLS binding document. > > It's rarely a good idea to rush such initiatives. > > --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 Fri Jul 11 07:49:41 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F3C63A6ADE for ; Fri, 11 Jul 2008 07:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.832 X-Spam-Level: X-Spam-Status: No, score=-3.832 tagged_above=-999 required=5 tests=[AWL=-1.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06n7l6VVrT1y for ; Fri, 11 Jul 2008 07:49:40 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 108D03A6A37 for ; Fri, 11 Jul 2008 07:49:40 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1A998433D50 for ; Fri, 11 Jul 2008 07:49:58 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 593544400DB for ; Thu, 10 Jul 2008 17:36:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 257DE3618001 for ; Thu, 10 Jul 2008 17:36:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 1278C361800C for ; Thu, 10 Jul 2008 17:36:19 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 10 Jul 2008 17:36:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,341,1212364800"; d="scan'208";a="51593468" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 11 Jul 2008 00:36:10 +0000 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/8.12.11) with ESMTP id m6B0aADB011503; Thu, 10 Jul 2008 17:36:10 -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.13.8/8.13.8) with ESMTP id m6B0aAId006635; Fri, 11 Jul 2008 00:36:10 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 17:36:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 17:36:43 -0700 Message-ID: In-Reply-To: <6F22142CC0DEBE478C659612F9CFCA5001A3159D@aruba-mx2.arubanetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS thread-index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4AAJ/T4MAACq6GwAAN5BbAAAC6JcAAA6tGwACaxvkAAAIFB8AAAx3QAAAEpXEAAAjnkIAAAU0NgAAB5fyAADChi0A== References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com><4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED20E@xmb-sjc-223.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20614E0E5@xmb-sjc-235.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905327@aruba-mx2.arubanetworks.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED3E0@xmb-sjc-223.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905402@aruba-mx2.arubanetworks.com> <4FF84B0BC277FF45AA27FE969DD956A20614E3E6@xmb-sjc-235.amer.cisco.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED67B@xmb-sjc-223.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20614E45C@xmb-sjc-235.amer.cisc o.com> <0A7D 7D6BC1EEF6489C3D0AE1B6B1619506BED74C@xmb-sjc-223.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20614E525@xmb-sjc-235.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001A3159D@aruba-mx2.arubanetworks.com> From: "Joseph Salowey (jsalowey)" To: "Scott Kelly" , "Pat Calhoun (pacalhou)" , "Abhijit Choudhury (achoudhu)" , X-OriginalArrivalTime: 11 Jul 2008 00:36:10.0540 (UTC) FILETIME=[1D84DEC0:01C8E2EE] Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Mailman-Approved-At: Fri, 11 Jul 2008 07:49:48 -0700 Cc: capwap@frascone.com Subject: Re: [Capwap] crypto algorithms for 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 I think it would be best to reference the DTLS specification (RFC4347) for recommendations on cipher suites for use with DTLS. Cheers, Joe > -----Original Message----- > From: Scott Kelly [mailto:skelly@arubanetworks.com] > Sent: Thursday, July 10, 2008 11:45 AM > To: Pat Calhoun (pacalhou); Abhijit Choudhury (achoudhu); > Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) > Cc: capwap@frascone.com > Subject: RE: [Capwap] crypto algorithms for DTLS > > I think this is probably a safe statement. > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Thursday, July 10, 2008 11:30 AM > > To: Abhijit Choudhury (achoudhu); Scott Kelly; > > Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] crypto algorithms for DTLS > > > > Scott - Are you OK with this proposal? > > > > PatC > > > > -----Original Message----- > > From: Abhijit Choudhury (achoudhu) > > Sent: Thursday, July 10, 2008 11:26 AM > > To: Pat Calhoun (pacalhou); 'Scott Kelly'; > > 'Dorothy.Gellert@nokia.com'; Joseph Salowey (jsalowey) > > Cc: 'capwap@frascone.com' > > Subject: RE: [Capwap] crypto algorithms for DTLS > > > > Yes, CAPWAP doesn't need to constrain the ciphers to block ciphers. > > The real reason is that CAPWAP tracks DTLS1.0 which tracks TLS1.1, > > which uses block ciphers. > > So, it'd be better to say explicitly that we only use ciphers > > recommended for DTLS. This way, it'll be easier to upgrade later to > > DTLS1.2, without having to change text in this spec. > > > > We could include the reference... That's fine. > > > > So, how about this: > > > > > > Replace the text in section 2.4.4.1 from > > > > "Note that only block ciphers are currently recommended > for use with > > DTLS. > > To understand the reasoning behind this, see [DTLS-DESIGN]." > > > > To > > > > "CAPWAP implementations only use cipher suites that are > recommended > > for > > use with DTLS [DTLS-DESIGN]." > > > > Thanks, > > Abhijit > > > > > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) > > Sent: Thursday, July 10, 2008 10:18 AM > > To: Abhijit Choudhury (achoudhu); 'Scott Kelly'; > > 'Dorothy.Gellert@nokia.com'; Joseph Salowey (jsalowey) > > Cc: 'capwap@frascone.com' > > Subject: RE: [Capwap] crypto algorithms for DTLS > > > > Out of curiosity, what is different in your text, other > than removing > > the reference to a document that, I guess, provides more clarity on > > why this statement is made? Is it the explicit removal of block > > ciphers that is what's desired here? > > > > PatC > > > > -----Original Message----- > > From: Abhijit Choudhury (achoudhu) > > Sent: Thursday, July 10, 2008 9:52 AM > > To: Pat Calhoun (pacalhou); 'Scott Kelly'; > > 'Dorothy.Gellert@nokia.com'; Joseph Salowey (jsalowey) > > Cc: 'capwap@frascone.com' > > Subject: RE: [Capwap] crypto algorithms for DTLS > > > > Okay. I'm fine with defering this. Let's not delay the current spec. > > > > > > I'd suggest the following changes: > > > > 1. In order to ensure that CAPWAP track DTLS better, we should > > change the text in section 2.4.4.1 from > > > > "Note that only block ciphers are currently recommended for > use with > > DTLS. > > To understand the reasoning behind this, see [DTLS-DESIGN]." > > > > To > > > > "CAPWAP implementations only use cipher suites that are recommended > > for use with DTLS." > > > > 2. Change the existing ciphers using DH to DHE. > > > > > > Thanks, > > Abhijit > > > > > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) > > Sent: Thursday, July 10, 2008 9:28 AM > > To: Scott Kelly; Abhijit Choudhury (achoudhu); > > Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] crypto algorithms for DTLS > > > > Ok, given this debate, and being short on time, I will submit the > > documents without the GCM ciphers, and therefore will not be making > > changes from TLS/DTLS1.1 to TLS/DTLS1.2. We can deal with this in a > > separate document. I would recommend adding the following sentence > > after the list of supported ciphers in both the certificate and > > pre-shared > > key: > > > > Additional ciphers MAY be defined in follow on CAPWAP > > specifications. > > > > Ok? > > > > PatC > > > > -----Original Message----- > > From: Scott Kelly [mailto:skelly@arubanetworks.com] > > Sent: Thursday, July 10, 2008 9:14 AM > > To: Abhijit Choudhury (achoudhu); Pat Calhoun (pacalhou); > > Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] crypto algorithms for DTLS > > > > Hi Abhijit, > > > > > My understanding is that DTLS1.2 will use the ciphers > specified in > > > TLS1.2, which has already been approved. > > > The DTLS1.2 spec will not have new ciphers, but will > possibly have > > > details on how to use these ciphers in DTLS. > > > Please correct me if I'm wrong here. > > > > > > So, we should be okay adding these approved TLS ciphers to the > > > OPTIONAL list, although it's true that they will not be used until > > > DTLS1.2 is finalized. But the list is only OPTIONAL and there are > > > other optional ciphers as well. > > > If we take this path, we don't have to touch this spec > later to add > > > these ciphers. > > > > I think there's a flaw in this logic. The currently > optional ciphers > > are supported in DTLS1.0 -- you are asking to add ciphers which are > > not supported in DTLS1.0, meaning a compliant CAPWAP implementation > > (i.e. > > one implementing DTLS1.0) will not be able to interoperate with one > > using these ciphers. > > > > > If we go the other route, how do we see it being done ? > > > Will we need a draft to specify just the deltas in using > > DTLS1.2 for > > > CAPWAP ? The concern I have is that it's not clear if the > > CAPWAP WG > > > will be active at that point to take up this new work item. > > > > > > Thoughts ? > > > > Yes, I think a new, brief document specifying the deltas is exactly > > what will be required. I also think speculation on the potential > > (non)existence of the capwap working group should not be the driver > > here. It isn't very relevant one way or the other. For > example, we've > > published a number of ammendments to IPsec since the wg > dissolved, and > > the ADs willingly sponsored/shepherded these documents > through. If for > > some odd reason (despite the fact that we've just started mib > > work) the > > capwap wg dissolves, this should present no impediment to > publishing > > an updated DTLS binding document. > > > > It's rarely a good idea to rush such initiatives. > > > > --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 Fri Jul 11 09:27:40 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879B53A6B2F for ; Fri, 11 Jul 2008 09:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-7k1UGsgMxt for ; Fri, 11 Jul 2008 09:27:39 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 439403A6B20 for ; Fri, 11 Jul 2008 09:27:39 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B46C61C40F35 for ; Fri, 11 Jul 2008 09:27:55 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 1D7AE4400C0 for ; Fri, 11 Jul 2008 09:27:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E83EC34AC025 for ; Fri, 11 Jul 2008 09:27:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4FF0E34AC049 for ; Fri, 11 Jul 2008 09:27:40 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from mail.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by mx1.tigertech.net (Postfix) with SMTP for ; Fri, 11 Jul 2008 09:27:40 -0700 (PDT) Received: from aruba-mx2.arubanetworks.com ([10.1.1.83]) by mail.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jul 2008 09:27:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 09:27:34 -0700 Message-ID: <6F22142CC0DEBE478C659612F9CFCA5001A316DA@aruba-mx2.arubanetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS Thread-Index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4AAJ/T4MAACq6GwAAN5BbAAAC6JcAAA6tGwACaxvkAAAIFB8AAAx3QAAAEpXEAAAjnkIAAAU0NgAAB5fyAADChi0AAwDfMw References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com><4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED20E@xmb-sjc-223.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20614E0E5@xmb-sjc-235.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905327@aruba-mx2.arubanetworks.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED3E0@xmb-sjc-223.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905402@aruba-mx2.arubanetworks.com> <4FF84B0BC277FF45AA27FE969DD956A20614E3E6@xmb-sjc-235.amer.cisco.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED67B@xmb-sjc-223.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20614E45C@xmb-sjc-235.amer.cisc o.com> <0A7D 7D6BC1EEF6489C3D0AE1B6B1619506BED74C@xmb-sjc-223.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20614E525@xmb-sjc-235.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001A3159D@aruba-mx2.arubanetworks.com> From: "Scott Kelly" To: "Joseph Salowey (jsalowey)" , "Pat Calhoun (pacalhou)" , "Abhijit Choudhury (achoudhu)" , X-OriginalArrivalTime: 11 Jul 2008 16:27:34.0387 (UTC) FILETIME=[0624AC30:01C8E373] Cc: capwap@frascone.com Subject: Re: [Capwap] crypto algorithms for 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 I agree with Joe. > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Thursday, July 10, 2008 5:37 PM > To: Scott Kelly; Pat Calhoun (pacalhou); Abhijit Choudhury > (achoudhu); Dorothy.Gellert@nokia.com > Cc: capwap@frascone.com > Subject: RE: [Capwap] crypto algorithms for DTLS > > I think it would be best to reference the DTLS specification (RFC4347) > for recommendations on cipher suites for use with DTLS. > > Cheers, > > Joe > > > -----Original Message----- > > From: Scott Kelly [mailto:skelly@arubanetworks.com] > > Sent: Thursday, July 10, 2008 11:45 AM > > To: Pat Calhoun (pacalhou); Abhijit Choudhury (achoudhu); > > Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] crypto algorithms for DTLS > > > > I think this is probably a safe statement. > > > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > > Sent: Thursday, July 10, 2008 11:30 AM > > > To: Abhijit Choudhury (achoudhu); Scott Kelly; > > > Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) > > > Cc: capwap@frascone.com > > > Subject: RE: [Capwap] crypto algorithms for DTLS > > > > > > Scott - Are you OK with this proposal? > > > > > > PatC > > > > > > -----Original Message----- > > > From: Abhijit Choudhury (achoudhu) > > > Sent: Thursday, July 10, 2008 11:26 AM > > > To: Pat Calhoun (pacalhou); 'Scott Kelly'; > > > 'Dorothy.Gellert@nokia.com'; Joseph Salowey (jsalowey) > > > Cc: 'capwap@frascone.com' > > > Subject: RE: [Capwap] crypto algorithms for DTLS > > > > > > Yes, CAPWAP doesn't need to constrain the ciphers to > block ciphers. > > > The real reason is that CAPWAP tracks DTLS1.0 which > tracks TLS1.1, > > > which uses block ciphers. > > > So, it'd be better to say explicitly that we only use ciphers > > > recommended for DTLS. This way, it'll be easier to > upgrade later to > > > DTLS1.2, without having to change text in this spec. > > > > > > We could include the reference... That's fine. > > > > > > So, how about this: > > > > > > > > > Replace the text in section 2.4.4.1 from > > > > > > "Note that only block ciphers are currently recommended > > for use with > > > DTLS. > > > To understand the reasoning behind this, see [DTLS-DESIGN]." > > > > > > To > > > > > > "CAPWAP implementations only use cipher suites that are > > recommended > > > for > > > use with DTLS [DTLS-DESIGN]." > > > > > > Thanks, > > > Abhijit > > > > > > > > > > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) > > > Sent: Thursday, July 10, 2008 10:18 AM > > > To: Abhijit Choudhury (achoudhu); 'Scott Kelly'; > > > 'Dorothy.Gellert@nokia.com'; Joseph Salowey (jsalowey) > > > Cc: 'capwap@frascone.com' > > > Subject: RE: [Capwap] crypto algorithms for DTLS > > > > > > Out of curiosity, what is different in your text, other > > than removing > > > the reference to a document that, I guess, provides more > clarity on > > > why this statement is made? Is it the explicit removal of block > > > ciphers that is what's desired here? > > > > > > PatC > > > > > > -----Original Message----- > > > From: Abhijit Choudhury (achoudhu) > > > Sent: Thursday, July 10, 2008 9:52 AM > > > To: Pat Calhoun (pacalhou); 'Scott Kelly'; > > > 'Dorothy.Gellert@nokia.com'; Joseph Salowey (jsalowey) > > > Cc: 'capwap@frascone.com' > > > Subject: RE: [Capwap] crypto algorithms for DTLS > > > > > > Okay. I'm fine with defering this. Let's not delay the > current spec. > > > > > > > > > I'd suggest the following changes: > > > > > > 1. In order to ensure that CAPWAP track DTLS better, we should > > > change the text in section 2.4.4.1 from > > > > > > "Note that only block ciphers are currently recommended for > > use with > > > DTLS. > > > To understand the reasoning behind this, see [DTLS-DESIGN]." > > > > > > To > > > > > > "CAPWAP implementations only use cipher suites that are > recommended > > > for use with DTLS." > > > > > > 2. Change the existing ciphers using DH to DHE. > > > > > > > > > Thanks, > > > Abhijit > > > > > > > > > > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) > > > Sent: Thursday, July 10, 2008 9:28 AM > > > To: Scott Kelly; Abhijit Choudhury (achoudhu); > > > Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) > > > Cc: capwap@frascone.com > > > Subject: RE: [Capwap] crypto algorithms for DTLS > > > > > > Ok, given this debate, and being short on time, I will submit the > > > documents without the GCM ciphers, and therefore will not > be making > > > changes from TLS/DTLS1.1 to TLS/DTLS1.2. We can deal with > this in a > > > separate document. I would recommend adding the following > sentence > > > after the list of supported ciphers in both the certificate and > > > pre-shared > > > key: > > > > > > Additional ciphers MAY be defined in follow on CAPWAP > > > specifications. > > > > > > Ok? > > > > > > PatC > > > > > > -----Original Message----- > > > From: Scott Kelly [mailto:skelly@arubanetworks.com] > > > Sent: Thursday, July 10, 2008 9:14 AM > > > To: Abhijit Choudhury (achoudhu); Pat Calhoun (pacalhou); > > > Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) > > > Cc: capwap@frascone.com > > > Subject: RE: [Capwap] crypto algorithms for DTLS > > > > > > Hi Abhijit, > > > > > > > My understanding is that DTLS1.2 will use the ciphers > > specified in > > > > TLS1.2, which has already been approved. > > > > The DTLS1.2 spec will not have new ciphers, but will > > possibly have > > > > details on how to use these ciphers in DTLS. > > > > Please correct me if I'm wrong here. > > > > > > > > So, we should be okay adding these approved TLS ciphers to the > > > > OPTIONAL list, although it's true that they will not be > used until > > > > DTLS1.2 is finalized. But the list is only OPTIONAL and > there are > > > > other optional ciphers as well. > > > > If we take this path, we don't have to touch this spec > > later to add > > > > these ciphers. > > > > > > I think there's a flaw in this logic. The currently > > optional ciphers > > > are supported in DTLS1.0 -- you are asking to add ciphers > which are > > > not supported in DTLS1.0, meaning a compliant CAPWAP > implementation > > > (i.e. > > > one implementing DTLS1.0) will not be able to > interoperate with one > > > using these ciphers. > > > > > > > If we go the other route, how do we see it being done ? > > > > Will we need a draft to specify just the deltas in using > > > DTLS1.2 for > > > > CAPWAP ? The concern I have is that it's not clear if the > > > CAPWAP WG > > > > will be active at that point to take up this new work item. > > > > > > > > Thoughts ? > > > > > > Yes, I think a new, brief document specifying the deltas > is exactly > > > what will be required. I also think speculation on the potential > > > (non)existence of the capwap working group should not be > the driver > > > here. It isn't very relevant one way or the other. For > > example, we've > > > published a number of ammendments to IPsec since the wg > > dissolved, and > > > the ADs willingly sponsored/shepherded these documents > > through. If for > > > some odd reason (despite the fact that we've just started mib > > > work) the > > > capwap wg dissolves, this should present no impediment to > > publishing > > > an updated DTLS binding document. > > > > > > It's rarely a good idea to rush such initiatives. > > > > > > --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 Fri Jul 11 09:31:35 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8AD228C226 for ; Fri, 11 Jul 2008 09:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oc1p0YVMnVKE for ; Fri, 11 Jul 2008 09:31:34 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 1E05128C22D for ; Fri, 11 Jul 2008 09:31:10 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6DB4B1C40FA3 for ; Fri, 11 Jul 2008 09:31:28 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id E45CF4400C0 for ; Fri, 11 Jul 2008 09:31:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id B379E3610002 for ; Fri, 11 Jul 2008 09:31:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E1A0A34AC02D for ; Fri, 11 Jul 2008 09:31:10 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.72 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by mx1.tigertech.net (Postfix) with ESMTP for ; Fri, 11 Jul 2008 09:31:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,346,1212364800"; d="scan'208,217";a="86692285" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 11 Jul 2008 16:30:50 +0000 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/8.12.11) with ESMTP id m6BGUnpR029957; Fri, 11 Jul 2008 09:30:49 -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.13.8/8.13.8) with ESMTP id m6BGUmR5016145; Fri, 11 Jul 2008 16:30:49 GMT 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.1830); Fri, 11 Jul 2008 09:29:58 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 09:29:58 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A204821200@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] crypto algorithms for DTLS Thread-Index: AccmBQLzwzG/cJ5kRZauU475xjV55m7P1HiwAAGD4JAAANg9gAAAPmbAAAAmv4AAJ/T4MAACq6GwAAN5BbAAAC6JcAAA6tGwACaxvkAAAIFB8AAAx3QAAAEpXEAAAjnkIAAAU0NgAAB5fyAADChi0AAwDfMwAA6TPGo= From: "Pat Calhoun (pacalhou)" To: "Scott Kelly" , "Joseph Salowey (jsalowey)" , "Abhijit Choudhury (achoudhu)" , X-OriginalArrivalTime: 11 Jul 2008 16:29:58.0622 (UTC) FILETIME=[5C1D2FE0:01C8E373] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] crypto algorithms for 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: multipart/mixed; boundary="===============0715803733==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============0715803733== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E373.5BE9605F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E373.5BE9605F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Unfortunately, the spec has been released for publication already. I = will deal with this as part of the IETF Last Call process. PatC -----Original Message----- From: Scott Kelly [mailto:skelly@arubanetworks.com] Sent: Friday, July 11, 2008 09:27 AM Pacific Standard Time To: Joseph Salowey (jsalowey); Pat Calhoun (pacalhou); Abhijit Choudhury = (achoudhu); Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] crypto algorithms for DTLS I agree with Joe.=20 > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 > Sent: Thursday, July 10, 2008 5:37 PM > To: Scott Kelly; Pat Calhoun (pacalhou); Abhijit Choudhury=20 > (achoudhu); Dorothy.Gellert@nokia.com > Cc: capwap@frascone.com > Subject: RE: [Capwap] crypto algorithms for DTLS >=20 > I think it would be best to reference the DTLS specification (RFC4347) > for recommendations on cipher suites for use with DTLS. =20 >=20 > Cheers, >=20 > Joe=20 >=20 > > -----Original Message----- > > From: Scott Kelly [mailto:skelly@arubanetworks.com]=20 > > Sent: Thursday, July 10, 2008 11:45 AM > > To: Pat Calhoun (pacalhou); Abhijit Choudhury (achoudhu);=20 > > Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] crypto algorithms for DTLS > >=20 > > I think this is probably a safe statement. > >=20 > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > > Sent: Thursday, July 10, 2008 11:30 AM > > > To: Abhijit Choudhury (achoudhu); Scott Kelly;=20 > > > Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) > > > Cc: capwap@frascone.com > > > Subject: RE: [Capwap] crypto algorithms for DTLS > > >=20 > > > Scott - Are you OK with this proposal? > > >=20 > > > PatC > > >=20 > > > -----Original Message----- > > > From: Abhijit Choudhury (achoudhu) > > > Sent: Thursday, July 10, 2008 11:26 AM > > > To: Pat Calhoun (pacalhou); 'Scott Kelly';=20 > > > 'Dorothy.Gellert@nokia.com'; Joseph Salowey (jsalowey) > > > Cc: 'capwap@frascone.com' > > > Subject: RE: [Capwap] crypto algorithms for DTLS > > >=20 > > > Yes, CAPWAP doesn't need to constrain the ciphers to=20 > block ciphers. > > > The real reason is that CAPWAP tracks DTLS1.0 which=20 > tracks TLS1.1,=20 > > > which uses block ciphers. > > > So, it'd be better to say explicitly that we only use ciphers=20 > > > recommended for DTLS. This way, it'll be easier to=20 > upgrade later to=20 > > > DTLS1.2, without having to change text in this spec. > > >=20 > > > We could include the reference... That's fine. > > >=20 > > > So, how about this: > > >=20 > > > =20 > > > Replace the text in section 2.4.4.1 from > > >=20 > > > "Note that only block ciphers are currently recommended=20 > > for use with=20 > > > DTLS. > > > To understand the reasoning behind this, see [DTLS-DESIGN]." > > >=20 > > > To > > >=20 > > > "CAPWAP implementations only use cipher suites that are=20 > > recommended=20 > > > for > > > use with DTLS [DTLS-DESIGN]."=20 > > >=20 > > > Thanks, > > > Abhijit > > > =20 > > > =20 > > >=20 > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) > > > Sent: Thursday, July 10, 2008 10:18 AM > > > To: Abhijit Choudhury (achoudhu); 'Scott Kelly';=20 > > > 'Dorothy.Gellert@nokia.com'; Joseph Salowey (jsalowey) > > > Cc: 'capwap@frascone.com' > > > Subject: RE: [Capwap] crypto algorithms for DTLS > > >=20 > > > Out of curiosity, what is different in your text, other=20 > > than removing=20 > > > the reference to a document that, I guess, provides more=20 > clarity on=20 > > > why this statement is made? Is it the explicit removal of block=20 > > > ciphers that is what's desired here? > > >=20 > > > PatC > > >=20 > > > -----Original Message----- > > > From: Abhijit Choudhury (achoudhu) > > > Sent: Thursday, July 10, 2008 9:52 AM > > > To: Pat Calhoun (pacalhou); 'Scott Kelly';=20 > > > 'Dorothy.Gellert@nokia.com'; Joseph Salowey (jsalowey) > > > Cc: 'capwap@frascone.com' > > > Subject: RE: [Capwap] crypto algorithms for DTLS > > >=20 > > > Okay. I'm fine with defering this. Let's not delay the=20 > current spec. > > >=20 > > >=20 > > > I'd suggest the following changes: > > >=20 > > > 1. In order to ensure that CAPWAP track DTLS better, we should=20 > > > change the text in section 2.4.4.1 from > > >=20 > > > "Note that only block ciphers are currently recommended for=20 > > use with=20 > > > DTLS. > > > To understand the reasoning behind this, see [DTLS-DESIGN]." > > >=20 > > > To > > >=20 > > > "CAPWAP implementations only use cipher suites that are=20 > recommended=20 > > > for use with DTLS." > > >=20 > > > 2. Change the existing ciphers using DH to DHE. > > >=20 > > >=20 > > > Thanks, > > > Abhijit > > > =20 > > > =20 > > >=20 > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) > > > Sent: Thursday, July 10, 2008 9:28 AM > > > To: Scott Kelly; Abhijit Choudhury (achoudhu);=20 > > > Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) > > > Cc: capwap@frascone.com > > > Subject: RE: [Capwap] crypto algorithms for DTLS > > >=20 > > > Ok, given this debate, and being short on time, I will submit the=20 > > > documents without the GCM ciphers, and therefore will not=20 > be making=20 > > > changes from TLS/DTLS1.1 to TLS/DTLS1.2. We can deal with=20 > this in a=20 > > > separate document. I would recommend adding the following=20 > sentence=20 > > > after the list of supported ciphers in both the certificate and=20 > > > pre-shared > > > key: > > >=20 > > > Additional ciphers MAY be defined in follow on CAPWAP=20 > > > specifications. > > >=20 > > > Ok? > > >=20 > > > PatC > > >=20 > > > -----Original Message----- > > > From: Scott Kelly [mailto:skelly@arubanetworks.com] > > > Sent: Thursday, July 10, 2008 9:14 AM > > > To: Abhijit Choudhury (achoudhu); Pat Calhoun (pacalhou);=20 > > > Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey) > > > Cc: capwap@frascone.com > > > Subject: RE: [Capwap] crypto algorithms for DTLS > > >=20 > > > Hi Abhijit, > > >=20 > > > > My understanding is that DTLS1.2 will use the ciphers=20 > > specified in=20 > > > > TLS1.2, which has already been approved. > > > > The DTLS1.2 spec will not have new ciphers, but will=20 > > possibly have=20 > > > > details on how to use these ciphers in DTLS. > > > > Please correct me if I'm wrong here. > > > >=20 > > > > So, we should be okay adding these approved TLS ciphers to the=20 > > > > OPTIONAL list, although it's true that they will not be=20 > used until > > > > DTLS1.2 is finalized. But the list is only OPTIONAL and=20 > there are=20 > > > > other optional ciphers as well. > > > > If we take this path, we don't have to touch this spec=20 > > later to add=20 > > > > these ciphers. > > >=20 > > > I think there's a flaw in this logic. The currently=20 > > optional ciphers=20 > > > are supported in DTLS1.0 -- you are asking to add ciphers=20 > which are=20 > > > not supported in DTLS1.0, meaning a compliant CAPWAP=20 > implementation=20 > > > (i.e. > > > one implementing DTLS1.0) will not be able to=20 > interoperate with one=20 > > > using these ciphers. > > >=20 > > > > If we go the other route, how do we see it being done ? > > > > Will we need a draft to specify just the deltas in using > > > DTLS1.2 for > > > > CAPWAP ? The concern I have is that it's not clear if the > > > CAPWAP WG > > > > will be active at that point to take up this new work item. > > > >=20 > > > > Thoughts ? > > >=20 > > > Yes, I think a new, brief document specifying the deltas=20 > is exactly=20 > > > what will be required. I also think speculation on the potential=20 > > > (non)existence of the capwap working group should not be=20 > the driver=20 > > > here. It isn't very relevant one way or the other. For=20 > > example, we've=20 > > > published a number of ammendments to IPsec since the wg=20 > > dissolved, and=20 > > > the ADs willingly sponsored/shepherded these documents=20 > > through. If for=20 > > > some odd reason (despite the fact that we've just started mib > > > work) the > > > capwap wg dissolves, this should present no impediment to=20 > > publishing=20 > > > an updated DTLS binding document. > > >=20 > > > It's rarely a good idea to rush such initiatives.=20 > > >=20 > > > --Scott > > >=20 > >=20 >=20 ------_=_NextPart_001_01C8E373.5BE9605F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Capwap] crypto algorithms for DTLS

Unfortunately, the spec has been released for = publication already. I will deal with this as part of the IETF Last Call = process.


PatC

 -----Original Message-----
From:   Scott Kelly [mailto:skelly@arubanetworks.com<= /A>]
Sent:   Friday, July 11, 2008 09:27 AM Pacific Standard = Time
To:     Joseph Salowey (jsalowey); Pat Calhoun = (pacalhou); Abhijit Choudhury (achoudhu); Dorothy.Gellert@nokia.com
Cc:     capwap@frascone.com
Subject:        RE: [Capwap] crypto = algorithms for DTLS

I agree with Joe.

> -----Original Message-----
> From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]
> Sent: Thursday, July 10, 2008 5:37 PM
> To: Scott Kelly; Pat Calhoun (pacalhou); Abhijit Choudhury
> (achoudhu); Dorothy.Gellert@nokia.com
> Cc: capwap@frascone.com
> Subject: RE: [Capwap] crypto algorithms for DTLS
>
> I think it would be best to reference the DTLS specification = (RFC4347)
> for recommendations on cipher suites for use with DTLS. 
>
> Cheers,
>
> Joe
>
> > -----Original Message-----
> > From: Scott Kelly [mailto:skelly@arubanetworks.com<= /A>]
> > Sent: Thursday, July 10, 2008 11:45 AM
> > To: Pat Calhoun (pacalhou); Abhijit Choudhury (achoudhu);
> > Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey)
> > Cc: capwap@frascone.com
> > Subject: RE: [Capwap] crypto algorithms for DTLS
> >
> > I think this is probably a safe statement.
> >
> > > -----Original Message-----
> > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
> > > Sent: Thursday, July 10, 2008 11:30 AM
> > > To: Abhijit Choudhury (achoudhu); Scott Kelly;
> > > Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey)
> > > Cc: capwap@frascone.com
> > > Subject: RE: [Capwap] crypto algorithms for DTLS
> > >
> > > Scott - Are you OK with this proposal?
> > >
> > > PatC
> > >
> > > -----Original Message-----
> > > From: Abhijit Choudhury (achoudhu)
> > > Sent: Thursday, July 10, 2008 11:26 AM
> > > To: Pat Calhoun (pacalhou); 'Scott Kelly';
> > > 'Dorothy.Gellert@nokia.com'; Joseph Salowey = (jsalowey)
> > > Cc: 'capwap@frascone.com'
> > > Subject: RE: [Capwap] crypto algorithms for DTLS
> > >
> > > Yes, CAPWAP doesn't need to constrain the ciphers to
> block ciphers.
> > > The real reason is that CAPWAP tracks DTLS1.0 which
> tracks TLS1.1,
> > > which uses block ciphers.
> > > So, it'd be better to say explicitly that we only use = ciphers
> > > recommended for DTLS. This way, it'll be easier to
> upgrade later to
> > > DTLS1.2, without having to change text in this spec.
> > >
> > > We could include the reference... That's fine.
> > >
> > > So, how about this:
> > >
> > > 
> > > Replace the text in section 2.4.4.1 from
> > >
> > >   "Note that only block ciphers are currently = recommended
> > for use with
> > > DTLS.
> > >   To understand the reasoning behind this, see = [DTLS-DESIGN]."
> > >
> > > To
> > >
> > >   "CAPWAP implementations only use cipher = suites that are
> > recommended
> > > for
> > >        use with DTLS = [DTLS-DESIGN]."
> > >
> > > Thanks,
> > > Abhijit
> > > 
> > > 
> > >
> > > -----Original Message-----
> > > From: Pat Calhoun (pacalhou)
> > > Sent: Thursday, July 10, 2008 10:18 AM
> > > To: Abhijit Choudhury (achoudhu); 'Scott Kelly';
> > > 'Dorothy.Gellert@nokia.com'; Joseph Salowey = (jsalowey)
> > > Cc: 'capwap@frascone.com'
> > > Subject: RE: [Capwap] crypto algorithms for DTLS
> > >
> > > Out of curiosity, what is different in your text, = other
> > than removing
> > > the reference to a document that, I guess, provides = more
> clarity on
> > > why this statement is made? Is it the explicit removal of = block
> > > ciphers that is what's desired here?
> > >
> > > PatC
> > >
> > > -----Original Message-----
> > > From: Abhijit Choudhury (achoudhu)
> > > Sent: Thursday, July 10, 2008 9:52 AM
> > > To: Pat Calhoun (pacalhou); 'Scott Kelly';
> > > 'Dorothy.Gellert@nokia.com'; Joseph Salowey = (jsalowey)
> > > Cc: 'capwap@frascone.com'
> > > Subject: RE: [Capwap] crypto algorithms for DTLS
> > >
> > > Okay. I'm fine with defering this. Let's not delay = the
> current spec.
> > >
> > >
> > > I'd suggest the following changes:
> > >
> > > 1. In order to ensure that CAPWAP track DTLS better, we = should
> > >     change the text in section = 2.4.4.1 from
> > >
> > > "Note that only block ciphers are currently = recommended for
> > use with
> > > DTLS.
> > > To understand the reasoning behind this, see = [DTLS-DESIGN]."
> > >
> > > To
> > >
> > > "CAPWAP implementations only use cipher suites that = are
> recommended
> > > for use with DTLS."
> > >
> > > 2. Change the existing ciphers using DH to DHE.
> > >
> > >
> > > Thanks,
> > > Abhijit
> > > 
> > > 
> > >
> > > -----Original Message-----
> > > From: Pat Calhoun (pacalhou)
> > > Sent: Thursday, July 10, 2008 9:28 AM
> > > To: Scott Kelly; Abhijit Choudhury (achoudhu);
> > > Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey)
> > > Cc: capwap@frascone.com
> > > Subject: RE: [Capwap] crypto algorithms for DTLS
> > >
> > > Ok, given this debate, and being short on time, I will = submit the
> > > documents without the GCM ciphers, and therefore will = not
> be making
> > > changes from TLS/DTLS1.1 to TLS/DTLS1.2. We can deal = with
> this in a
> > > separate document. I would recommend adding the = following
> sentence
> > > after the list of supported ciphers in both the = certificate and
> > > pre-shared
> > > key:
> > >
> > >    Additional ciphers MAY be defined in = follow on CAPWAP
> > > specifications.
> > >
> > > Ok?
> > >
> > > PatC
> > >
> > > -----Original Message-----
> > > From: Scott Kelly [mailto:skelly@arubanetworks.com<= /A>]
> > > Sent: Thursday, July 10, 2008 9:14 AM
> > > To: Abhijit Choudhury (achoudhu); Pat Calhoun = (pacalhou);
> > > Dorothy.Gellert@nokia.com; Joseph Salowey (jsalowey)
> > > Cc: capwap@frascone.com
> > > Subject: RE: [Capwap] crypto algorithms for DTLS
> > >
> > > Hi Abhijit,
> > >
> > > > My understanding is that DTLS1.2 will use the = ciphers
> > specified in
> > > > TLS1.2, which has already been approved.
> > > > The DTLS1.2 spec will not have new ciphers, but = will
> > possibly have
> > > > details on how to use these ciphers in DTLS.
> > > > Please correct me if I'm wrong here.
> > > >
> > > > So, we should be okay adding these approved TLS = ciphers to the
> > > > OPTIONAL list, although it's true that they will not = be
> used until
> > > > DTLS1.2 is finalized. But the list is only OPTIONAL = and
> there are
> > > > other optional ciphers as well.
> > > > If we take this path, we don't have to touch this = spec
> > later to add
> > > > these ciphers.
> > >
> > > I think there's a flaw in this logic. The currently
> > optional ciphers
> > > are supported in DTLS1.0 -- you are asking to add = ciphers
> which are
> > > not supported in DTLS1.0, meaning a compliant CAPWAP
> implementation
> > > (i.e.
> > > one implementing DTLS1.0) will not be able to
> interoperate with one
> > > using these ciphers.
> > >
> > > > If we go the other route, how do we see it being = done ?
> > > > Will we need a draft to specify just the deltas in = using
> > > DTLS1.2 for
> > > > CAPWAP ?  The concern I have is that it's not = clear if the
> > > CAPWAP WG
> > > > will be active at that point to take up this new = work item.
> > > >
> > > > Thoughts ?
> > >
> > > Yes, I think a new, brief document specifying the = deltas
> is exactly
> > > what will be required. I also think speculation on the = potential
> > > (non)existence of the capwap working group should not = be
> the driver
> > > here. It isn't very relevant one way or the other. = For
> > example, we've
> > > published a number of ammendments to IPsec since the = wg
> > dissolved, and
> > > the ADs willingly sponsored/shepherded these = documents
> > through. If for
> > > some odd reason (despite the fact that we've just started = mib
> > > work) the
> > > capwap wg dissolves, this should present no impediment = to
> > publishing
> > > an updated DTLS binding document.
> > >
> > > It's rarely a good idea to rush such initiatives.
> > >
> > > --Scott
> > >
> >
>

------_=_NextPart_001_01C8E373.5BE9605F-- --===============0715803733== 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 --===============0715803733==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jul 11 09:54:20 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5A828C251 for ; Fri, 11 Jul 2008 09:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGCPOACh6qlk for ; Fri, 11 Jul 2008 09:54:18 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id EE6F028C249 for ; Fri, 11 Jul 2008 09:54:18 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4A9C21C40FB1 for ; Fri, 11 Jul 2008 09:54:37 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id A39B74400F6 for ; Fri, 11 Jul 2008 09:54:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2B2AA34AC074 for ; Fri, 11 Jul 2008 09:54:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 064A234AC0A1 for ; Fri, 11 Jul 2008 09:54:05 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Sender first seen 3 mons 28 days 01:10:38 ago / dynamic or unknown reverse DNS) Received: from exchange.tm.thingmagic.com (unknown [204.9.221.19]) by mx1.tigertech.net (Postfix) with ESMTP for ; Fri, 11 Jul 2008 09:54:04 -0700 (PDT) Received: from [10.36.0.26] (76.24.195.210) by exchange.tm.thingmagic.com (10.0.0.9) with Microsoft SMTP Server (TLS) id 8.1.278.0; Fri, 11 Jul 2008 12:53:51 -0400 In-Reply-To: <6F22142CC0DEBE478C659612F9CFCA5001905402@aruba-mx2.arubanetworks.com> References: <20061222193625.20423.qmail@web62409.mail.re1.yahoo.com><458C3B75.6090006@cs.umd.edu><0A7D7D6BC1EEF6489C3D0AE1B6B1619506BECE92@xmb-sjc-223.amer.cisco.com><6F22142CC0DEBE478C659612F9CFCA50019051DA@aruba-mx2.arubanetworks.com><4FF84B0BC277FF45AA27FE969DD956A2060D1EC7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2060D1ECE@xmb-sjc-235.amer.cisco.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA037B375D@daebe103.NOE.Nokia.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED20E@xmb-sjc-223.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20614E0E5@xmb-sjc-235.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905327@aruba-mx2.arubanetworks.com> <0A7D7D6BC1EEF6489C3D0AE1B6B1619506BED3E0@xmb-sjc-223.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001905402@aruba-mx2.arubanetworks.com> MIME-Version: 1.0 (Apple Message framework v753.1) Message-ID: From: Margaret Wasserman Date: Fri, 11 Jul 2008 12:53:48 -0400 To: Scott Kelly X-Mailer: Apple Mail (2.753.1) Cc: "Joseph Salowey (jsalowey)" , capwap@frascone.com, Dorothy.Gellert@nokia.com Subject: Re: [Capwap] crypto algorithms for 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 Just my personal opinion... I'd prefer to leave the security stuff as-is in this spec, unless it has a blocking technical flaw, because it has already been through Security Directorate review and has been reviewed by one (ex-) Security AD. There will always be a next update that we could consider in CAPWAP. For instance, there have been several updates to the IEEE specs that we have agreed not to consider, because it was necessary to draw a line and get this spec out. I'd prefer to draw the same line for these new security specs, get this document out as-is, and consider any updates for a later version. Margaret On Jul 10, 2008, at 12:13 PM, Scott Kelly wrote: > Hi Abhijit, > >> My understanding is that DTLS1.2 will use the ciphers >> specified in TLS1.2, which has already been approved. >> The DTLS1.2 spec will not have new ciphers, but will >> possibly have details on how to use these ciphers in DTLS. >> Please correct me if I'm wrong here. >> >> So, we should be okay adding these approved TLS ciphers >> to the OPTIONAL list, although it's true that they will not >> be used until DTLS1.2 is finalized. But the list is only >> OPTIONAL and there are other optional ciphers as well. >> If we take this path, we don't have to touch this spec later >> to add these ciphers. > > I think there's a flaw in this logic. The currently optional > ciphers are > supported in DTLS1.0 -- you are asking to add ciphers which are not > supported in DTLS1.0, meaning a compliant CAPWAP implementation (i.e. > one implementing DTLS1.0) will not be able to interoperate with one > using these ciphers. > >> If we go the other route, how do we see it being done ? >> Will we need a draft to specify just the deltas in using DTLS1.2 >> for CAPWAP ? The concern I have is that it's not clear if >> the CAPWAP WG will be active at that point to take up this >> new work item. >> >> Thoughts ? > > Yes, I think a new, brief document specifying the deltas is exactly > what > will be required. I also think speculation on the potential > (non)existence of the capwap working group should not be the driver > here. It isn't very relevant one way or the other. For example, we've > published a number of ammendments to IPsec since the wg dissolved, and > the ADs willingly sponsored/shepherded these documents through. If for > some odd reason (despite the fact that we've just started mib work) > the > capwap wg dissolves, this should present no impediment to > publishing an > updated DTLS binding document. > > It's rarely a good idea to rush such initiatives. > > --Scott > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 14 10:45:34 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F39903A6BCF for ; Mon, 14 Jul 2008 10:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMsgE8+CXopd for ; Mon, 14 Jul 2008 10:45:21 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id DA6C93A6BE7 for ; Mon, 14 Jul 2008 10:45:18 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A83CE433FD1 for ; Mon, 14 Jul 2008 10:45:44 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 0530B440101 for ; Mon, 14 Jul 2008 10:45:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8ABB334AC058 for ; Mon, 14 Jul 2008 10:45:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 01C0C34AC041 for ; Mon, 14 Jul 2008 10:45:30 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (64.170.98.32 whitelisted by list.dnswl.org 9.2) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 14 Jul 2008 10:45:29 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 0) id 674CE3A68FA; Mon, 14 Jul 2008 10:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714174503.674CE3A68FA@core3.amsl.com> Date: Mon, 14 Jul 2008 10:45:02 -0700 (PDT) Cc: capwap@frascone.com Subject: [Capwap] I-D ACTION:draft-ietf-capwap-protocol-specification-11.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Control And Provisioning of Wireless Access Points Working Group of the IETF. Title : CAPWAP Protocol Specification Author(s) : P. Calhoun Filename : draft-ietf-capwap-protocol-specification-11.txt Pages : 155 Date : 2008-7-14 This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the Objectives for Control and Provisioning of Wireless Access Points (CAPWAP). The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol, while separate binding extensions will enable its use with additional wireless technologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-protocol-specification-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-capwap-protocol-specification-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-7-14104350.I-D@ietf.org> --NextPart 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 --NextPart-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 14 11:00:15 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4E703A6C01 for ; Mon, 14 Jul 2008 11:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.251 X-Spam-Level: X-Spam-Status: No, score=-102.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udcspSlz43zA for ; Mon, 14 Jul 2008 11:00:15 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 16A1F3A6C45 for ; Mon, 14 Jul 2008 11:00:15 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7B98C433FB0 for ; Mon, 14 Jul 2008 11:00:41 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id C8ABD44011B for ; Mon, 14 Jul 2008 11:00:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 9F8DA34AC041 for ; Mon, 14 Jul 2008 11:00:30 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 996A734AC056 for ; Mon, 14 Jul 2008 11:00:28 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (64.170.98.32 whitelisted by list.dnswl.org 9.2) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 14 Jul 2008 11:00:28 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 0) id 04D9B3A6C16; Mon, 14 Jul 2008 11:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714180002.04D9B3A6C16@core3.amsl.com> Date: Mon, 14 Jul 2008 11:00:02 -0700 (PDT) Cc: capwap@frascone.com Subject: [Capwap] I-D ACTION:draft-ietf-capwap-protocol-binding-ieee80211-07.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Control And Provisioning of Wireless Access Points Working Group of the IETF. Title : CAPWAP Protocol Binding for IEEE 802.11 Author(s) : P. Calhoun Filename : draft-ietf-capwap-protocol-binding-ieee80211-07.txt Pages : 69 Date : 2008-7-14 Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management and radio management from the single access point to a centralized controller. This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-protocol-binding-ieee80211-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-capwap-protocol-binding-ieee80211-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-7-14104511.I-D@ietf.org> --NextPart 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 --NextPart-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 14 12:43:26 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64D823A6B54 for ; Mon, 14 Jul 2008 12:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTDbkvs5QNw4 for ; Mon, 14 Jul 2008 12:43:25 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 5F97F3A6B16 for ; Mon, 14 Jul 2008 12:43:25 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 958CD1C40F70 for ; Mon, 14 Jul 2008 12:43:51 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 547B2440132 for ; Mon, 14 Jul 2008 12:43:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4347434AC013 for ; Mon, 14 Jul 2008 12:43:10 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 84E3334AC033 for ; Mon, 14 Jul 2008 12:43:08 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from exchange.tm.thingmagic.com (vpn.thingmagic.com [204.9.221.19]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 14 Jul 2008 12:43:08 -0700 (PDT) Received: from [10.0.0.70] (10.0.0.70) by exchange.tm.thingmagic.com (10.0.0.9) with Microsoft SMTP Server (TLS) id 8.1.278.0; Mon, 14 Jul 2008 15:43:07 -0400 MIME-Version: 1.0 (Apple Message framework v753.1) Message-ID: <8726265A-D0BD-46F5-8F9D-27E0E1327EBD@thingmagic.com> To: From: Margaret Wasserman Date: Mon, 14 Jul 2008 15:43:02 -0400 X-Mailer: Apple Mail (2.753.1) Subject: [Capwap] WGLC on Base Spec -11 Changes 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 Hi All, This message begins a one week Working Group Last Call on the changes that were made in version 11 of the CAPWAP Protocol Specification. These changes were in response to AD review comments and several important issues raised by Yong Zhang. The -11 document is now available in the I-D archives here: http://www.ietf.org/internet-drafts/draft-ietf-capwap-protocol- specification-11.txt Please respond by the end of the day on Sunday, July 20th if you find any problems with the new version. Assuming there are no objections to the latest round of changes, we will ask our Area Director, Dan Romascanu, to send this document to IETF Last Call at the beginning of next week. 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 Mon Jul 14 21:36:46 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C4B3A67D2 for ; Mon, 14 Jul 2008 21:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOQhsN6WTKEU for ; Mon, 14 Jul 2008 21:36:45 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 5EA473A67A4 for ; Mon, 14 Jul 2008 21:36:45 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 917401C40F4F for ; Mon, 14 Jul 2008 21:37:12 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 996F24400F8 for ; Mon, 14 Jul 2008 21:37:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 78EDF3610011 for ; Mon, 14 Jul 2008 21:37:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6F208361000B for ; Mon, 14 Jul 2008 21:36:59 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.233 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 14 Jul 2008 21:36:59 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6F4atni027963 for ; Tue, 15 Jul 2008 07:36:56 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 07:36:54 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 23:36:53 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 23:35:16 -0500 Message-ID: <0AC25B27A4FD2E4B839C9FAF2C704DBA0381553C@daebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC announcement for draft-ietf-capwap-protocol-binding-ieee80211-07.txt Thread-Index: AcjmNC3WW7TUSF/1RI2eBO2ZILOzVQ== From: To: X-OriginalArrivalTime: 15 Jul 2008 04:36:53.0367 (UTC) FILETIME=[67C46070:01C8E634] X-Nokia-AV: Clean Subject: [Capwap] WGLC announcement for draft-ietf-capwap-protocol-binding-ieee80211-07.txt 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="===============1584217340==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============1584217340== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E634.67B13E4A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E634.67B13E4A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, This message begins a one week Working Group Last Call on the changes =20 that were made in version 07 of the CAPWAP 802.11 binding draft, draft-ietf-capwap-protocol-binding-ieee80211-07.txt. =20 These changes were in response to AD review comments and other issues raised on the WG list. draft-ietf-capwap-protocol-binding-ieee80211-07.txt is now available in the I-D archives here: http://www.ietf.org/internet-drafts/draft-ietf-capwap-protocol-binding-i eee80211-07.txt Please respond by the end of the day on Monday, July 21st if you find any problems with the new version. Assuming there are no objections to the latest round of changes, we will ask our Area Director, Dan Romascanu, to send this document to IETF Last Call immediately after the end of this WGLC. Thanks, Dorothy ------_=_NextPart_001_01C8E634.67B13E4A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WGLC announcement for = draft-ietf-capwap-protocol-binding-ieee80211-07.txt

Hi All,

This message begins a one week = Working Group Last Call on the changes 
that were made in version 07 of = the CAPWAP 802.11 binding draft, = draft-ietf-capwap-protocol-binding-ieee80211-07.txt.   =

These changes were in response to = AD review comments and other issues raised on the WG list.

draft-ietf-capwap-protocol-binding-ieee80211-07.txt is now = available in the I-D archives here:
http://www.ietf.org/internet-drafts/draft-ietf-capwap-protocol-bindi= ng-ieee80211-07.txt

Please respond by the end of the = day on Monday, July 21st if you find any problems with the new = version.

Assuming there are no objections = to the latest round of changes, we will ask our Area Director, Dan = Romascanu, to send this document to IETF Last Call immediately after the = end of this WGLC.

Thanks,
Dorothy


------_=_NextPart_001_01C8E634.67B13E4A-- --===============1584217340== 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 --===============1584217340==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 15 13:52:58 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D89DB3A6823 for ; Tue, 15 Jul 2008 13:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.732 X-Spam-Level: X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGpOrekAhJqc for ; Tue, 15 Jul 2008 13:52:57 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 836CC3A6A5F for ; Tue, 15 Jul 2008 13:52:57 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0E66B1C40FA8 for ; Tue, 15 Jul 2008 13:53:26 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 846CB440125 for ; Tue, 15 Jul 2008 13:53:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5BDAA3688003 for ; Tue, 15 Jul 2008 13:53:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3886E3688016 for ; Tue, 15 Jul 2008 13:53:09 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 15 Jul 2008 13:53:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,368,1212364800"; d="scan'208,217";a="65767862" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2008 20:53:08 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6FKr8Ee026989 for ; Tue, 15 Jul 2008 13:53:08 -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.13.8/8.13.8) with ESMTP id m6FKr8hN007081 for ; Tue, 15 Jul 2008 20:53:08 GMT 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, 15 Jul 2008 13:53:08 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Jul 2008 13:53:00 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2061B2325@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Changes in draft-ietf-capwap-protocol-binding-ieee80211-07.txt Thread-Index: AcjmvMRVdIHkEkhBQPC72gMJFD6w4g== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 15 Jul 2008 20:53:08.0587 (UTC) FILETIME=[C951A3B0:01C8E6BC] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Capwap] Changes in draft-ietf-capwap-protocol-binding-ieee80211-07.txt 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="===============1688708977==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============1688708977== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E6BC.C531B32C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E6BC.C531B32C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I thought it would be useful to include a list of all of the changes that have been incorporated into the 802.11 binding draft. I will not repeat all of the information that is available in the issue tracker, but instead just list the issues that were resolved. The issues are: =09 =09 Issue #108: AD review for draft-ietf-capwap-dhc-ac-option-01 T1 =20 Issue #118: AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 T8 =20 Issue #112: AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 T2 =20 Issue #117: AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 T7 =20 Issue #114: AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 T4 =20 Issue #115: AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 T5 =20 Issue #116: AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 T6 =20 Issue #120: AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 T10 =20 Issue #111: AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 T1 =20 Issue #113: AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 T3 =20 Issue #119: AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 T9 =20 Issue #124: AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E4 =20 Issue #121: AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E1 =20 Issue #130: AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E10 =20 Issue #132: AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E12 =20 Issue #129: AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E9 =20 Issue #128: AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E8 =20 Issue #126: AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E6 =20 Issue #125: AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E5 =20 Issue #122: AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E2 =20 Issue #127:AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E7 =20 Issue #123: AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E3 =20 Issue #131: AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E11 =20 Issue #148: IANA Cleanup =20 Issue #145: 802.11 binding doc. issues =20 ------_=_NextPart_001_01C8E6BC.C531B32C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,

I thought it = would be useful to=20 include a list of all of the changes that have been incorporated into=20 the 802.11 binding draft. I = will not=20 repeat all of the information that is available in the issue tracker, = but=20 instead just list the issues that were resolved. The issues = are:


Issue #108: AD = review for=20 draft-ietf-capwap-dhc-ac-option-01 T1
Issue #118: AD = review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06 T8
Issue #112: AD = review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06 T2
Issue #117: AD = review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06 T7
Issue #114: AD = review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06 T4
Issue #115: AD = review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06 T5
Issue #116: AD = review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06 T6
Issue #120: AD = review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06 T10 =
Issue #111: AD = review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06 T1
Issue #113: AD = review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06 T3
Issue #119: AD = review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06 T9
Issue #124: AD = review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E4
Issue #121: AD = review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E1
Issue #130: AD = review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E10 =
Issue #132: AD = review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E12
Issue #129: AD = review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E9
Issue #128: AD = review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E8
Issue #126: AD = review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E6
Issue #125: AD = review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E5
Issue #122: AD = review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E2
Issue #127:AD review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06=20 E7
Issue #123: AD = review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06=20 E3
Issue #131: AD = review=20 ofdraft-ietf-capwap-protocol-binding-ieee80211-06 E11=20
Issue #148: IANA=20 Cleanup
Issue #145: 802.11= =20 binding doc. issues=20
------_=_NextPart_001_01C8E6BC.C531B32C-- --===============1688708977== 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 --===============1688708977==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 15 13:55:04 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 872F13A69F3 for ; Tue, 15 Jul 2008 13:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.728 X-Spam-Level: X-Spam-Status: No, score=-2.728 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdgXT4s9HQog for ; Tue, 15 Jul 2008 13:55:02 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D04743A6863 for ; Tue, 15 Jul 2008 13:55:02 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 57B9F439FBF for ; Tue, 15 Jul 2008 13:55:31 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id B1EDF440125 for ; Tue, 15 Jul 2008 13:55:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 7963E3688014 for ; Tue, 15 Jul 2008 13:55:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 64D6E3688019 for ; Tue, 15 Jul 2008 13:55:10 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 15 Jul 2008 13:55:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,368,1212364800"; d="scan'208,217";a="127106924" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 15 Jul 2008 20:53:08 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6FKr8AB022528 for ; Tue, 15 Jul 2008 13:53:08 -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.13.8/8.13.8) with ESMTP id m6FKr8hP007081 for ; Tue, 15 Jul 2008 20:53:08 GMT 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, 15 Jul 2008 13:53:08 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Jul 2008 13:53:03 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2061B2326@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Changes in draft-ietf-capwap-protocol-specification-11.txt Thread-Index: AcjmvMaKvvrX8i6FS7++WCvSIQ4j0w== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 15 Jul 2008 20:53:08.0634 (UTC) FILETIME=[C958CFA0:01C8E6BC] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Capwap] Changes in draft-ietf-capwap-protocol-specification-11.txt 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="===============1264588816==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============1264588816== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E6BC.C74EE817" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E6BC.C74EE817 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I thought it would be useful to include a list of all of the changes that have been incorporated into the base draft. I will not repeat all of the information that is available in the issue tracker, but instead just list the issues that were resolved. The issues are: =09 =09 Issue #50: CAPWAP IESG Issue T9 =20 Issue #69: CAPWAP IESG Review Comment T28 =20 Issue #56: CAPWAP IESG Review Comment T15 =20 Issue #55: CAPWAP IESG Review Comment T14 =20 Issue #60: CAPWAP IESG Review Comment T19 =20 Issue #48: CAPWAP IESG Issue T7 =20 Issue #59: CAPWAP IESG Review Comment T18 =20 Issue #58: CAPWAP IESG Review Comment T17 =20 Issue #49: CAPWAP IESG Review T8 =20 Issue #54: CAPWAP IESG Review Comment T13 =20 Issue #47: CAPWAP IESG Issue T6 =20 Issue #68: CAPWAP IESG Review T27 =20 Issue #64: CAPWAP IESG Review Comment T23 =20 Issue #62: CAPWAP IESG Review Comment T21 =20 Issue #66: CAPWAP IESG Review Comment T25 =20 Issue #52: CAPWAP IESG Issue T11 =20 Issue #51: CAPWAP IESG Review Comment T10 =20 Issue #43: CAPWAP IESG Issue T2 =20 Issue #45: CAPWAP IESG Issue T4 =20 Issue #67: CAPWAP IESG Review T26 =20 Issue #75: CAPWAP IESG Review T34 =20 Issue #72: CAPWAP IESG Review T31 =20 Issue #76: CAPWAP IESG Review T35 =20 Issue #71: CAPWAP IESG Review T30 =20 Issue #70: CAPWAP IESG Review T29 =20 Issue #79: CAPWAP IESG Review T38 =20 Issue #81: CAPWAP IESG Review T40 =20 Issue #57: CAPWAP IESG Issue T16 =20 Issue #80: CAPWAP IESG Review T39 =20 Issue #44: CAPWAP IESG Issue T3 =20 Issue #78: CAPWAP IESG Review T37 =20 Issue #77: CAPWAP IESG Review T36 =20 Issue #46: CAPWAP IESG Issue T5 =20 Issue #61: CAPWAP IESG Review Comment T20 =20 Issue #42: CAPWAP IESG Issue T1 =20 Issue #99: CAPWAP Timers not referencing timers properly =20 Issue #63: IESG Review Comment T22 =20 Issue #41: CAPWAP DTLS Timer Clarification =20 Issue #65: IESG Review Comment T24 =20 Issue #53: CAPWAP IESG Review Comment T12 =20 Issue #73: CAPWAP IESG Review T32 =20 Issue #103: Invalid length information message element =20 Issue #74: CAPWAP IESG Review T33 =20 Issue #134: Image Data to Reset state machine issue =20 Issue #135: Incorrect Reset to DTLS Teardown state transition =20 Issue #136: The AC State Machine never gets from Join to Image Data =20 Issue #102: Join to Image Data state transition issue on the AC =20 Issue #107: ImageDataStartTimer is not specified correctly =20 Issue #137: ResponseTimeout is unnecessary =20 Issue #142: UDP IANA port =20 Issue #140: ME issues =20 Issue #141: More ME Issues =20 Issue #106: WaitJoin may be unnecessary =20 Issue #139: FSM Issues =20 Issue #143: Data Transfer Request is too ambiguous =20 Issue #144: Invalid reference to message element field =20 Issue #148: IANA Cleanup =20 Issue #147: Timer Issues =20 Issue #88: CAPWAP IESG Review E7 =20 Issue #83: CAPWAP IESG Review E2 =20 Issue #84: CAPWAP IESG Review E3 =20 Issue #90: CAPWAP IESG Review E9 =20 Issue #87: CAPWAP IESG Review E6 =20 Issue #91: CAPWAP IESG Review E10 =20 Issue #95: CAPWAP IESG Review E14 =20 Issue #96: CAPWAP IESG Review E15 =20 Issue #94: CAPWAP IESG Review E13 =20 Issue #93: CAPWAP IESG Review E12 =20 Issue #92: CAPWAP IESG Review E11 =20 Issue #98: CAPWAP IESG Review E17 =20 Issue #100: Editorial issue in 4.6.15 =20 Issue #101: Error in message element figure in 4.6.32 =20 Issue #82: CAPWAP IESG Review E1 =20 Issue #86: CAPWAP IESG Review E5 =20 Issue #85: CAPWAP IESG Review E4 =20 Issue #97: CAPWAP IESG Review E16 =20 Issue #89: CAPWAP IESG Review E8 =20 Issue #104: ReportInterval needs to move from section 4.8 to 4.7 =20 Issue #105: Intro to section 4.8 incorrect =20 Issue #133: Remove references from base spec abstract =20 Issue #138: Inconsistent values for enable/disable in section 4.6.34 =20 Issue #146: Invalid reference to boolean term =20 PatC =20 ------_=_NextPart_001_01C8E6BC.C74EE817 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,

I thought it = would be useful to=20 include a list of all of the changes that have been incorporated into = the base=20 draft. I will not repeat all of the information that is available in the = issue=20 tracker, but instead just list the issues that were resolved. The issues = are:


Issue #50: = CAPWAP IESG Issue T9
Issue #69: CAPWAP IESG Review Comment T28
Issue #56: CAPWAP IESG Review Comment T15
Issue #55: CAPWAP IESG Review Comment T14
Issue #60: CAPWAP IESG Review Comment T19
Issue #48: CAPWAP IESG Issue T7
Issue #59: CAPWAP IESG Review Comment T18
Issue #58: CAPWAP IESG Review Comment T17
Issue #49: CAPWAP IESG Review T8
Issue #54: CAPWAP IESG Review Comment T13
Issue #47: CAPWAP IESG Issue T6
Issue #68: CAPWAP IESG Review T27
Issue #64: CAPWAP IESG Review Comment T23
Issue #62: CAPWAP IESG Review Comment T21
Issue #66: CAPWAP IESG Review Comment T25
Issue #52: CAPWAP IESG Issue T11
Issue #51: CAPWAP IESG Review Comment T10
Issue #43: CAPWAP IESG Issue T2
Issue #45: CAPWAP IESG Issue T4
Issue #67: CAPWAP IESG Review T26
Issue #75: CAPWAP IESG Review T34
Issue #72: CAPWAP IESG Review T31
Issue #76: CAPWAP IESG Review T35
Issue #71: CAPWAP IESG Review T30
Issue #70: CAPWAP IESG Review T29
Issue #79: CAPWAP IESG Review T38
Issue #81: CAPWAP IESG Review T40
Issue #57: CAPWAP IESG Issue T16
Issue #80: CAPWAP IESG Review T39
Issue #44: CAPWAP IESG Issue T3
Issue #78: CAPWAP IESG Review T37
Issue #77: CAPWAP IESG Review T36
Issue #46: CAPWAP IESG Issue T5
Issue #61: CAPWAP IESG Review Comment T20
Issue #42: CAPWAP IESG Issue T1
Issue #99: CAPWAP Timers not referencing timers = properly=20
Issue #63: IESG Review Comment T22
Issue #41: CAPWAP DTLS Timer Clarification =
Issue #65: IESG Review Comment T24
Issue #53: CAPWAP IESG Review Comment T12
Issue #73: CAPWAP IESG Review T32
Issue #103: Invalid length information message = element
Issue #74: CAPWAP IESG Review T33
Issue #134: Image Data to Reset state machine = issue
Issue #135: Incorrect Reset to DTLS Teardown state = transition=20
Issue #136: The AC State Machine never gets from Join to = Image=20 Data
Issue #102: Join to Image Data state transition issue on the = AC
Issue #107: ImageDataStartTimer is not specified = correctly=20
Issue #137: ResponseTimeout is unnecessary
Issue #142: UDP IANA port
Issue #140: ME issues
Issue #141: More ME Issues
Issue #106: WaitJoin may be unnecessary
Issue #139: FSM Issues
Issue #143: Data Transfer Request is too = ambiguous
Issue #144: Invalid reference to message element = field
Issue #148: IANA Cleanup
Issue #147: Timer Issues
Issue #88: CAPWAP IESG Review E7
Issue #83: CAPWAP IESG Review E2
Issue #84: CAPWAP IESG Review E3
Issue #90: CAPWAP IESG Review E9
Issue #87: CAPWAP IESG Review E6
Issue #91: CAPWAP IESG Review E10
Issue #95: CAPWAP IESG Review E14
Issue #96: CAPWAP IESG Review E15
Issue #94: CAPWAP IESG Review E13
Issue #93: CAPWAP IESG Review E12
Issue #92: CAPWAP IESG Review E11
Issue #98: CAPWAP IESG Review E17
Issue #100: Editorial issue in 4.6.15
Issue #101: Error in message element figure in = 4.6.32
Issue #82: CAPWAP IESG Review E1
Issue #86: CAPWAP IESG Review E5
Issue #85: CAPWAP IESG Review E4
Issue #97: CAPWAP IESG Review E16
Issue #89: CAPWAP IESG Review E8
Issue #104: ReportInterval needs to move from section 4.8 to = 4.7
Issue #105: Intro to section 4.8 incorrect
Issue #133: Remove references from base spec = abstract
Issue #138: Inconsistent values for enable/disable in = section=20 4.6.34
Issue #146: Invalid reference to boolean term=20

PatC

 

------_=_NextPart_001_01C8E6BC.C74EE817-- --===============1264588816== 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 --===============1264588816==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 15 15:12:03 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA2B3A67E4 for ; Tue, 15 Jul 2008 15:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tl1mOhyF254O for ; Tue, 15 Jul 2008 15:12:02 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 74A313A67CC for ; Tue, 15 Jul 2008 15:12:02 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F15CF1C40FEB for ; Tue, 15 Jul 2008 15:12:30 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 5C13E44008D for ; Tue, 15 Jul 2008 15:12:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 30B453688009 for ; Tue, 15 Jul 2008 15:12:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 669B1368800F for ; Tue, 15 Jul 2008 15:12:06 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from exchange.tm.thingmagic.com (vpn.thingmagic.com [204.9.221.19]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 15 Jul 2008 15:12:05 -0700 (PDT) Received: from [10.36.0.26] (76.24.195.210) by exchange.tm.thingmagic.com (10.0.0.9) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 15 Jul 2008 18:11:58 -0400 MIME-Version: 1.0 (Apple Message framework v753.1) Message-ID: From: Margaret Wasserman Date: Tue, 15 Jul 2008 18:11:53 -0400 To: "Pat Calhoun (pacalhou)" X-Mailer: Apple Mail (2.753.1) Cc: capwap@frascone.com Subject: [Capwap] Renumbering of Message Elements 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 Hi Pat, In reviewing the diffs for the -11 base specification, it seems that you unnecessarily renumbered many of the message elements between versions -10 and -11. I know that you had to number the Message Elements that were TBD in the spec to resolve Issue 52, but I understood that you would retain the existing numbers and renumber the TBD elements with unused numbers. As is, this creates a big, unnecessary incompatibility between -10 and -11, and I'd prefer that this is corrected before publication, if possible. 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 Tue Jul 15 15:23:52 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45DAE3A683B for ; Tue, 15 Jul 2008 15:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.725 X-Spam-Level: X-Spam-Status: No, score=-2.725 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6DF1BfIvUXV for ; Tue, 15 Jul 2008 15:23:51 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 82ECA3A6A5F for ; Tue, 15 Jul 2008 15:23:51 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 341901C40FDB for ; Tue, 15 Jul 2008 15:24:20 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id C315D440093 for ; Tue, 15 Jul 2008 15:24:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8F5E33688008 for ; Tue, 15 Jul 2008 15:24:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E668C3688001 for ; Tue, 15 Jul 2008 15:24:08 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 15 Jul 2008 15:24:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,368,1212364800"; d="scan'208";a="53417580" Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-1.cisco.com with ESMTP; 15 Jul 2008 22:23:58 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id m6FMNwxX015529; Tue, 15 Jul 2008 15:23:58 -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.13.8/8.13.8) with ESMTP id m6FMNw3T000669; Tue, 15 Jul 2008 22:23:58 GMT 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, 15 Jul 2008 15:23:58 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Jul 2008 15:23:06 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2061B23ED@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Renumbering of Message Elements Thread-Index: Acjmx9NcvwpjfUs2RqeHd85UkgdYLwAABXag References: From: "Pat Calhoun (pacalhou)" To: "Margaret Wasserman" X-OriginalArrivalTime: 15 Jul 2008 22:23:58.0284 (UTC) FILETIME=[799768C0:01C8E6C9] Authentication-Results: sj-dkim-8; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Renumbering of Message Elements 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 Ah, yes, I believe when we removed a message element, everything got renumbered. We will deal with this as an IETF Last Call comment. I have created issue 149 to track this. PatC -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com] Sent: Tuesday, July 15, 2008 3:12 PM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Renumbering of Message Elements Hi Pat, In reviewing the diffs for the -11 base specification, it seems that you unnecessarily renumbered many of the message elements between versions -10 and -11. I know that you had to number the Message Elements that were TBD in the spec to resolve Issue 52, but I understood that you would retain the existing numbers and renumber the TBD elements with unused numbers. As is, this creates a big, unnecessary incompatibility between -10 and -11, and I'd prefer that this is corrected before publication, if possible. 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 Tue Jul 15 15:24:16 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E39F3A6AA4 for ; Tue, 15 Jul 2008 15:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKZY8aKlGf6x for ; Tue, 15 Jul 2008 15:24:15 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 5916D3A683B for ; Tue, 15 Jul 2008 15:24:15 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 098921C40FBE for ; Tue, 15 Jul 2008 15:24:44 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id B01F1440093 for ; Tue, 15 Jul 2008 15:24:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 7245B368800E for ; Tue, 15 Jul 2008 15:24:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E9AF83688011 for ; Tue, 15 Jul 2008 15:24:15 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.184]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 15 Jul 2008 15:24:14 -0700 (PDT) Received: by rn-out-0910.google.com with SMTP id j71so1941162rne.12 for ; Tue, 15 Jul 2008 15:24:14 -0700 (PDT) Received: by 10.142.223.4 with SMTP id v4mr4855216wfg.166.1216160653644; Tue, 15 Jul 2008 15:24:13 -0700 (PDT) Received: by 10.142.84.4 with HTTP; Tue, 15 Jul 2008 15:24:13 -0700 (PDT) Message-ID: Date: Tue, 15 Jul 2008 15:24:13 -0700 From: "Yong Zhang" To: capwap@frascone.com MIME-Version: 1.0 Content-Disposition: inline Subject: [Capwap] binding doc. 802.11 wlan config req/resp msg type value issue 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 In the capwap spec, it is said: All Request messages have odd numbered Message Type Values, and all Response messages have even numbered Message Type Values. When a WTP or AC receives a message with a Message Type Value field that is not recognized and is an odd number, the number in the Message Type Value Field is incremented by one, and a Response message with a Message Type Value field containing the incremented value and containing the Result Code message element with the value (Unrecognized Request) is returned to the sender of the received message. If the unknown message type is even, the message is ignored. However, the two new messages defined in the binding doc. do not follow this: The valid message types for IEEE 802.11 specific control messages are listed below. The IANA Enterprise number used with these messages is 13277. CAPWAP Control Message Message Type Value IEEE 802.11 WLAN Configuration Request 3398912 IEEE 802.11 WLAN Configuration Response 3398913 Yong _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 15 16:59:35 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57C6A3A67AF for ; Tue, 15 Jul 2008 16:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+bJM-g-ayEC for ; Tue, 15 Jul 2008 16:59:34 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 4ABF03A683B for ; Tue, 15 Jul 2008 16:59:34 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 807B71C40FF0 for ; Tue, 15 Jul 2008 17:00:01 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 3C4B044014E for ; Tue, 15 Jul 2008 16:59:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 178183708005 for ; Tue, 15 Jul 2008 16:59:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 88B503708004 for ; Tue, 15 Jul 2008 16:59:50 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from exchange.tm.thingmagic.com (vpn.thingmagic.com [204.9.221.19]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 15 Jul 2008 16:59:50 -0700 (PDT) Received: from [10.36.0.26] (76.24.195.210) by exchange.tm.thingmagic.com (10.0.0.9) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 15 Jul 2008 19:59:47 -0400 In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2061B23ED@xmb-sjc-235.amer.cisco.com> References: <4FF84B0BC277FF45AA27FE969DD956A2061B23ED@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 (Apple Message framework v753.1) Message-ID: <9B3D18FF-EB30-41B3-B71F-D55078160C37@thingmagic.com> From: Margaret Wasserman Date: Tue, 15 Jul 2008 19:59:42 -0400 To: Pat Calhoun X-Mailer: Apple Mail (2.753.1) Cc: "capwap@frascone.com" Subject: Re: [Capwap] Renumbering of Message Elements 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 Thanks, Pat! Fixing this during IETF Last Call is fine with me. Margaret On Jul 15, 2008, at 6:23 PM, Pat Calhoun (pacalhou) wrote: > Ah, yes, I believe when we removed a message element, everything got > renumbered. We will deal with this as an IETF Last Call comment. I > have > created issue 149 to track this. > > PatC > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Tuesday, July 15, 2008 3:12 PM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: Renumbering of Message Elements > > > Hi Pat, > > In reviewing the diffs for the -11 base specification, it seems > that you > unnecessarily renumbered many of the message elements between versions > -10 and -11. I know that you had to number the Message Elements that > were TBD in the spec to resolve Issue 52, but I understood that you > would retain the existing numbers and renumber the TBD elements with > unused numbers. > > As is, this creates a big, unnecessary incompatibility between -10 and > -11, and I'd prefer that this is corrected before publication, if > possible. > > Margaret > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 17 06:53:31 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0AE03A68A8 for ; Thu, 17 Jul 2008 06:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfJBPQ8Uii1e for ; Thu, 17 Jul 2008 06:53:31 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2309D3A683D for ; Thu, 17 Jul 2008 06:53:31 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CBD53432871 for ; Thu, 17 Jul 2008 06:54:02 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id D1CF3440164 for ; Thu, 17 Jul 2008 06:53:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 9C6E434AC037 for ; Thu, 17 Jul 2008 06:53:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 215D334AC08C for ; Thu, 17 Jul 2008 06:53:43 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Sender first seen 00:33:18 ago / dynamic or unknown reverse DNS) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 17 Jul 2008 06:53:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,203,1215403200"; d="scan'208";a="115073215" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 17 Jul 2008 09:20:14 -0400 X-IronPort-AV: E=Sophos;i="4.31,203,1215403200"; d="scan'208";a="230611566" Received: from unknown (HELO 306181ANEX2.global.avaya.com) ([135.9.6.101]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 17 Jul 2008 09:20:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Jul 2008 07:20:11 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-art review of draft-ietf-capwap-threat-analysis-01.txt Thread-Index: Acjn3f8YZPIvOUSeSeOUjArSGFQYBQAMcf0A From: "Mani, Mahalingam (Mani)" To: "capwap" Subject: [Capwap] FW: Gen-art review of draft-ietf-capwap-threat-analysis-01.txt 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 -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] Sent: Thursday, July 17, 2008 12:23 AM To: draft-ietf-capwap-threat-analysis@tools.ietf.org Cc: Romascanu, Dan (Dan); gen-art@ietf.org; capwap-chairs@tools.ietf.org Subject: Gen-art review of draft-ietf-capwap-threat-analysis-01.txt Hi, I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Draft: draft-ietf-capwap-threat-analysis-01.txt Reviewer: Gonzalo Camarillo Review Date: 17 July 2008 Summary: This draft is ready for publication as an Informational RFC. Comments: Expand CAPWAP in the title and in the abstract. Expand acronyms (e.g., RFID) on their first use. Thanks, Gonzalo _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 17 13:58:12 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12513A67B0 for ; Thu, 17 Jul 2008 13:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4oXtgfeq6YX for ; Thu, 17 Jul 2008 13:58:11 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id CF4203A677C for ; Thu, 17 Jul 2008 13:58:11 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 274571C40FB3 for ; Thu, 17 Jul 2008 13:58:44 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 385AB440188 for ; Thu, 17 Jul 2008 13:58:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id CAA663688005 for ; Thu, 17 Jul 2008 13:58:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3D0F33688006 for ; Thu, 17 Jul 2008 13:57:58 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.72 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 17 Jul 2008 13:57:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,205,1215388800"; d="scan'208";a="88143317" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 17 Jul 2008 20:57:53 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6HKvrfm022830; Thu, 17 Jul 2008 13:57:53 -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.13.8/8.13.8) with ESMTP id m6HKvrlb020509; Thu, 17 Jul 2008 20:57:53 GMT 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); Thu, 17 Jul 2008 13:57:53 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Jul 2008 13:57:51 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20621144D@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] binding doc. 802.11 wlan config req/resp msg type valueissue Thread-Index: AcjmyZWKch0ezzoxRES/Nh530b2PcgBhiXrw References: From: "Pat Calhoun (pacalhou)" To: "Yong Zhang" , X-OriginalArrivalTime: 17 Jul 2008 20:57:53.0328 (UTC) FILETIME=[C7DD2B00:01C8E84F] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Capwap] binding doc. 802.11 wlan config req/resp msg type valueissue 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 We will deal with this issue as part of the IETF Last Call process. I have created Issue 150 to track it. PatC -----Original Message----- From: Yong Zhang [mailto:yozhang@gmail.com] Sent: Tuesday, July 15, 2008 3:24 PM To: capwap@frascone.com Subject: [Capwap] binding doc. 802.11 wlan config req/resp msg type valueissue In the capwap spec, it is said: All Request messages have odd numbered Message Type Values, and all Response messages have even numbered Message Type Values. When a WTP or AC receives a message with a Message Type Value field that is not recognized and is an odd number, the number in the Message Type Value Field is incremented by one, and a Response message with a Message Type Value field containing the incremented value and containing the Result Code message element with the value (Unrecognized Request) is returned to the sender of the received message. If the unknown message type is even, the message is ignored. However, the two new messages defined in the binding doc. do not follow this: The valid message types for IEEE 802.11 specific control messages are listed below. The IANA Enterprise number used with these messages is 13277. CAPWAP Control Message Message Type Value IEEE 802.11 WLAN Configuration Request 3398912 IEEE 802.11 WLAN Configuration Response 3398913 Yong _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 21 16:29:58 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C06413A6A7F for ; Mon, 21 Jul 2008 16:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.822, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYAG5G-j65uv for ; Mon, 21 Jul 2008 16:29:58 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 043473A68E4 for ; Mon, 21 Jul 2008 16:29:57 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B9A441C40FCF for ; Mon, 21 Jul 2008 16:30:37 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 4AD7B4400E3 for ; Mon, 21 Jul 2008 16:30:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id DC9193610004 for ; Mon, 21 Jul 2008 16:30:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 857B73610014 for ; Mon, 21 Jul 2008 16:30:26 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from exchange.tm.thingmagic.com (exchange.tm.thingmagic.com [204.9.221.21]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 21 Jul 2008 16:30:26 -0700 (PDT) Received: from [10.36.0.26] (76.24.195.210) by exchange.tm.thingmagic.com (10.0.0.9) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 21 Jul 2008 19:30:25 -0400 MIME-Version: 1.0 (Apple Message framework v753.1) Message-ID: <3B97555A-A234-4DC6-A470-92A62A257091@thingmagic.com> To: From: Margaret Wasserman Date: Mon, 21 Jul 2008 19:30:20 -0400 X-Mailer: Apple Mail (2.753.1) Subject: [Capwap] Call for Agenda Items 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 Hi All, I've put together a draft agenda for our meeting at the Dublin IETF (see below). Is there anything else that we should plan to cover? Thanks, Margaret --- CAPWAP WG Agenda, IETF 72 Dublin Tuesday, 1740-1840, Ballroom I ================================ - Intro/Administrivia (3 min, Chairs) - CAPWAP Document Status (10 min, Chairs) - MIB Status and Open Issues (15 min, Yang Shi?) http://www.ietf.org/internet-drafts/draft-ietf-capwap-base-mib-00.txt http://www.ietf.org/internet-drafts/draft-ietf-capwap-802dot11- mib-00.txt - Looking Forward (10 min, Chairs) _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 22 04:39:11 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D6D3A6949 for ; Tue, 22 Jul 2008 04:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oV5zcIt17-as for ; Tue, 22 Jul 2008 04:39:05 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 74EBA3A68FE for ; Tue, 22 Jul 2008 04:39:05 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8BCE543266B for ; Tue, 22 Jul 2008 04:39:46 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 864AF4400EF for ; Tue, 22 Jul 2008 04:39:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 549B434AC02A for ; Tue, 22 Jul 2008 04:39:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 62EB434AC00F for ; Tue, 22 Jul 2008 04:39:36 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 22 Jul 2008 04:39:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,230,1215403200"; d="scan'208";a="136378622" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 22 Jul 2008 07:39:35 -0400 X-IronPort-AV: E=Sophos;i="4.31,230,1215403200"; d="scan'208";a="233480137" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 22 Jul 2008 07:39:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 13:39:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-capwap-base-mib-00 Thread-Index: Acjr75uH9pN27PhQQPCsOoAiWGFXmw== From: "Romascanu, Dan (Dan)" To: Subject: [Capwap] Comments on draft-ietf-capwap-base-mib-00 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 This is only a partial reviews and not yet a full MIB Doctor review. I am seeing a lot of problems in modeling and lack of synchronization between the MIB and the CAPWAP protocol document, so I would recommend that the authors of the protocol document and other WG members do a detailed check and comparison between the two documents. 1. smilint complains about: mibs/CAPWAP-MIB:314: [5] {identifier-case-match} warning: identifier `capwapWTPId' differs from `CapwapWTPId' only in case mibs/CAPWAP-MIB:632: [5] {identifier-case-match} warning: identifier `capwapRadioId' differs from `CapwapRadioId' only in case mibs/CAPWAP-MIB:712: [5] {identifier-case-match} warning: identifier `capwapStationId' differs from `CapwapStationId' only in case mibs/CAPWAP-MIB:1334: [5] {identifier-case-match} warning: identifier `capwapChannelType' differs from `CapwapChannelType' only in case mibs/CAPWAP-MIB:1342: [5] {identifier-case-match} warning: identifier `capwapWTPAuthenMethod' differs from `CapwapWTPAuthenMethod' only in case The problem is that object names are similar to TC names, excepting capitalization 2. smilint complains about: mibs/CAPWAP-MIB:294: [5] {index-element-accessible} warning: index element `capwapWTPId' of row `capwapWTPStateEntry' should be not-accessible in SMIv2 MIB mibs/CAPWAP-MIB:613: [5] {index-element-accessible} warning: index element `capwapRadioId' of row `capwapRadioBindEntry' should be not-accessible in SMIv2 MIB Objects that are indices in tables should be not-accessible, and if there is a need to use the objects for notifications they should be duplicated in the table. 3. smilint complains about: mibs/CAPWAP-MIB:1672: [5] {group-unref} warning: current group `capwapStationsGroup' is not referenced in this module 4. It would be better that all objects in the MIB module have a common naming prefix beyond capwap which is common to all capwap MIB modules. Maybe capwapBase or capwapProto. 5. The Introduction should refer to the CAPWAP work as to stable work not 'under way' 6. Overview - it looks to me that the first objective ('To work well under centralized architectures') and the fifth one ('to meet operator requirements for centralized architectures') are redundant 7. 'The SNMP agent run on the AC side, and it MAY not be required on the WTP side' - it is not clear what is meant here, and the usage of the RFC2119 language is not appropriate. Does it mean to say 'The CAPWAP-MIB MUST be run on the AC devices and is NOT REQUIRED on the WTP devices'? 8. Instead of 'ifIndex [RFC2863] will play a role in bridging between MIB standards defined by different SDOs' better say 'ifIndex [RFC2863] will be used as common handler for corresponding interfaces in the CAPWAP-MIB and specific wireless technologies MIB modules'. 9. 'To reuse MIB objects (defined by SDOs such as IEEE) for radio is very import' - s/import/important/ 10. There is no need for section 6.1 to duplicate the textual conventions defined in the MIB module itself 11. Section 7.2 - does not ifName map into WTP name? same ifDescr into WTP descriptor? 12. Section 7.3 - what is the entPhysicalClass that is recommended for the usage of RFC4133? 13. Naming consistency - it would be good to keep object names under a node with the same prefix as the node name - e.g. capwapAC -> capwapACWTPSessions or better capwapBaseAC -> capwapBaseACWTPSessions, etc. 14. CapWapWTPAuthenMethod - it would be better to put other(1) as the first enumerated value. 15. Objects like capwapWTPSessionsLimit have a limited range in the CAPWAP protocol dictated by the numbers of bits used for their representation (16 for example) - it would be appropriate to limit the range of the Unsigned32 accordingly 16. capwapDataChannelSecOptions, capwapWTPAuthenOptions - the BIT construct should be used as SYNTAX 17. capwapWTPACNameList is SIZE(256) in the MIB and 512 in section 4.6.5 of the protocol document. 18. capwapWTPState has one state dtls(1) while the state diagram in section 2.3.1 of the protocol document mentions three different states 'DTLS Setup', DTLS Connect', 'DTLS TD' - is dtls(1) supposed to cover all three? If so please be explicit in the DESCRIPTION clause 19. capwapWTPMACTypeOptions has a SYNTAX of CapwapWTPMACType which is an enumerated, but the DESCRIPTION clause indicates that BITS SYNTAX should be used here. 20. The SYNTAX of capwapStationVlanName should be SnmpAdminString 21. It would be good to find a more adequate name for the capwapVariables group 22. why is there a need to define a special group for objects for notifications, instead of defining these objects in the other configuration tables in the MIB module 23. What is the functionality of the capwapIdEntryNum? The reference to section 4.6.15 in the protocol document seems to be wrong, this is the CAPWAP transport protocol Regards, Dan _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 22 05:30:31 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91B093A693C for ; Tue, 22 Jul 2008 05:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bbBe7m5cVyg for ; Tue, 22 Jul 2008 05:30:24 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 685DB3A6972 for ; Tue, 22 Jul 2008 05:30:24 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9676C432933 for ; Tue, 22 Jul 2008 05:31:05 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 4111E44013D for ; Tue, 22 Jul 2008 05:30:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 97A34361000A for ; Tue, 22 Jul 2008 05:30:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id B184E34AC029 for ; Tue, 22 Jul 2008 05:30:55 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 22 Jul 2008 05:30:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,231,1215403200"; d="scan'208";a="136384766" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 22 Jul 2008 08:30:55 -0400 X-IronPort-AV: E=Sophos;i="4.31,231,1215403200"; d="scan'208";a="233505550" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 22 Jul 2008 08:30:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 14:30:53 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-ietf-capwap-802dot11-mib-00 Thread-Index: Acjr9sghATnZuGh4T/KgWpselprVuQ== From: "Romascanu, Dan (Dan)" To: Subject: [Capwap] comments on draft-ietf-capwap-802dot11-mib-00 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 This is not yet a full MIB Doctor review. 1. smilint complains mibs/CAPWAP-DOT11-MIB:117: [5] {identifier-case-match} warning: identifier `capwapDot11WLANId' differs from `CapwapDot11WLANId' only in case You need to define name objects different from TC names 2. The Introduction should refer to the CAPWAP work as to stable work not 'under way' 3. There is no need for section 6.1 to duplicate the textual conventions defined in the MIB module itself 4. There is no definition of the persistency of read-write or read-create objects for the capwapDot11WLANConfigTable, or a StorageType object in the rows. 5. The names of the capwapWTPMacType and capwapWTPTunnelMode objects do not respect the naming convention for the MIB module. Regards, Dan _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 22 05:46:16 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39DAA3A69C8 for ; Tue, 22 Jul 2008 05:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DONElCHoXzlC for ; Tue, 22 Jul 2008 05:45:57 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 39E383A69C0 for ; Tue, 22 Jul 2008 05:45:57 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 668CE4329DD for ; Tue, 22 Jul 2008 05:46:38 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 3EECC4400C4 for ; Tue, 22 Jul 2008 05:46:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 1540E34AC029 for ; Tue, 22 Jul 2008 05:46:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 986413610008 for ; Tue, 22 Jul 2008 05:46:26 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (64.170.98.32 whitelisted by list.dnswl.org 9.2) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 22 Jul 2008 05:46:26 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id F25FC3A698A; Tue, 22 Jul 2008 05:45:44 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20080722124544.F25FC3A698A@core3.amsl.com> Date: Tue, 22 Jul 2008 05:45:44 -0700 (PDT) Cc: capwap@frascone.com Subject: [Capwap] Last Call: draft-ietf-capwap-protocol-binding-ieee80211 (CAPWAP Protocol Binding for IEEE 802.11) to Proposed Standard X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com The IESG has received a request from the Control And Provisioning of Wireless Access Points WG (capwap) to consider the following document: - 'CAPWAP Protocol Binding for IEEE 802.11 ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-08-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-capwap-protocol-binding-ieee80211-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15275&rfc_flag=0 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 22 05:46:49 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87A0A3A6945 for ; Tue, 22 Jul 2008 05:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Cp-MOnFoqLb for ; Tue, 22 Jul 2008 05:46:48 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 68A633A698A for ; Tue, 22 Jul 2008 05:46:48 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A837D432A1E for ; Tue, 22 Jul 2008 05:47:29 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id C66514400C4 for ; Tue, 22 Jul 2008 05:47:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 9D6A634AC029 for ; Tue, 22 Jul 2008 05:47:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id F31F834AC015 for ; Tue, 22 Jul 2008 05:47:16 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (64.170.98.32 whitelisted by list.dnswl.org 9.2) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 22 Jul 2008 05:47:16 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 6EE2A3A69D6; Tue, 22 Jul 2008 05:46:24 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20080722124624.6EE2A3A69D6@core3.amsl.com> Date: Tue, 22 Jul 2008 05:46:24 -0700 (PDT) Cc: capwap@frascone.com Subject: [Capwap] Last Call: draft-ietf-capwap-protocol-specification (CAPWAP Protocol Specification) to Proposed Standard X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com The IESG has received a request from the Control And Provisioning of Wireless Access Points WG (capwap) to consider the following document: - 'CAPWAP Protocol Specification ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-08-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-capwap-protocol-specification-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14467&rfc_flag=0 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 22 14:34:17 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 055493A69A4 for ; Tue, 22 Jul 2008 14:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOpKeUVFOiwB for ; Tue, 22 Jul 2008 14:34:16 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 11B7F3A63EC for ; Tue, 22 Jul 2008 14:34:16 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C6BBB1C40FE0 for ; Tue, 22 Jul 2008 14:34:57 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 65EEC4400EF for ; Tue, 22 Jul 2008 14:34:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 384B73808001 for ; Tue, 22 Jul 2008 14:34:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8E23F3808007 for ; Tue, 22 Jul 2008 14:34:45 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 22 Jul 2008 14:34:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,233,1215388800"; d="scan'208";a="130178975" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 22 Jul 2008 21:34:45 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m6MLYjK1016839 for ; Tue, 22 Jul 2008 14:34:45 -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.13.8/8.13.8) with ESMTP id m6MLYjVV023428 for ; Tue, 22 Jul 2008 21:34:45 GMT 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, 22 Jul 2008 14:34:44 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 14:34:44 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062748C8@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 150: binding doc. 802.11 wlan config req/resp msg typevalueissue Thread-Index: AcjsN1xk6jRFtmt0Sy+G9sM1kcMdGA== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 22 Jul 2008 21:34:44.0205 (UTC) FILETIME=[C1B6F9D0:01C8EC42] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Capwap] Issue 150: binding doc. 802.11 wlan config req/resp msg typevalueissue 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 All, I have made the fixes for the issue raised. The crux of the issue is that the message element numbering requires that the first three octets be used for the IANA Enterprise Number, for which 802.11 uses 13277. The issue is that the base draft also requires that requests be odd numbered, and responses be even numbered. However, the -7 draft uses the inverse, where the request is even numbered and the response is odd numbered. The downside here is that this creates a backward compatibility issue with -07, which has been through WG Last Call, but it is a necessary change in order to comply with the numbering rules laid out in the base draft. So the new text looks like: 3. IEEE 802.11 Specific CAPWAP Control Messages [...] CAPWAP Control Message Message Type Value IEEE 802.11 WLAN Configuration Request 3398913 IEEE 802.11 WLAN Configuration Response 3398914 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 Jul 22 14:34:57 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755813A6818 for ; Tue, 22 Jul 2008 14:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.716 X-Spam-Level: X-Spam-Status: No, score=-2.716 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOZloI69xXOq for ; Tue, 22 Jul 2008 14:34:56 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 9F1993A63EC for ; Tue, 22 Jul 2008 14:34:56 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 68FBE1C40FC0 for ; Tue, 22 Jul 2008 14:35:38 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id ADC064400EF for ; Tue, 22 Jul 2008 14:34:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 7BEEB3808007 for ; Tue, 22 Jul 2008 14:34:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E5890380800F for ; Tue, 22 Jul 2008 14:34:52 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 22 Jul 2008 14:34:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,233,1215388800"; d="scan'208";a="56264572" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 22 Jul 2008 21:34:45 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m6MLYhJC016805 for ; Tue, 22 Jul 2008 14:34:43 -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.13.8/8.13.8) with ESMTP id m6MLYhsg027274 for ; Tue, 22 Jul 2008 21:34:44 GMT 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.1830); Tue, 22 Jul 2008 14:34:43 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 14:34:43 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062748C7@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 149: Incompatibility with message element numbering between drafts 10 and 11 Thread-Index: AcjsNhaFB75JCTv+Sniu0tSMeQ1Vvw== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 22 Jul 2008 21:34:43.0791 (UTC) FILETIME=[C177CDF0:01C8EC42] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Capwap] Issue 149: Incompatibility with message element numbering between drafts 10 and 11 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 All, I have made the necessary changes to the document that will eventually become -12 to ensure that the numbering of the message elements in the base draft are consistent with -10. I do, however, want to note that -10 had an error. While the table in section 4.6 showed the value 22 for the "Duplication IPv6 Address" message element, the value shown in the message element definition in section 4.6.25 was 23 and incorrect. The value in section 4.6.25, was both inconsistent with the table, but more importantly, conflicted with the Idle Timeout message element (section 4.6.26). This bug did not exist in -11, since I had renumbered all message elements. However, issue 149 requires me to change all of the message element type values to those found in -10. I wanted to note that I have corrected this bug in -12, which of course, means that the two drafts will differ in this regard. However, the message element table values are consistent across both -10 and -12. 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 Fri Jul 25 10:26:16 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E8273A699D for ; Fri, 25 Jul 2008 10:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_53=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-69E8qywHHB for ; Fri, 25 Jul 2008 10:26:14 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2742E3A686A for ; Fri, 25 Jul 2008 10:26:14 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C784B1C40F9B for ; Fri, 25 Jul 2008 10:26:15 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 4A76244014D for ; Fri, 25 Jul 2008 05:40:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 1B19434AC082 for ; Fri, 25 Jul 2008 05:40:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id EEF9834AC07E for ; Fri, 25 Jul 2008 05:40:11 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Sender first seen 00:40:01 ago / dynamic or unknown reverse DNS) Received: from huawei-3com.com (unknown [221.12.31.56]) by mx1.tigertech.net (Postfix) with ESMTP for ; Fri, 25 Jul 2008 05:40:09 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K4K00JFP9CH2Q@h3cml01-in.huawei-3com.com> for capwap@frascone.com; Fri, 25 Jul 2008 20:00:17 +0800 (CST) Received: from mailsecurity.h3c.com ([172.25.12.124]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K4K00GFP9CH5H@h3cml01-in.huawei-3com.com> for capwap@frascone.com; Fri, 25 Jul 2008 20:00:17 +0800 (CST) Received: from unknown (HELO s00338) ([10.154.68.126]) by mailsecurity.h3c.com with ESMTP; Fri, 25 Jul 2008 20:06:33 +0800 Date: Fri, 25 Jul 2008 20:00:02 +0800 From: young In-reply-to: To: capwap@frascone.com Message-id: <000001c8ee4d$f8a5b140$7e449a0a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook, Build 10.0.6838 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Thread-index: AcjsrVpj4K7cgYX7TDW/1jlG9Ui1CgBn5cuw X-Mailman-Approved-At: Fri, 25 Jul 2008 10:26:01 -0700 Subject: [Capwap] Comments inline for Dan's comment on MIB drafts 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="===============1801864836==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com --===============1801864836== Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable According to Dan's comments for on draft-ietf-capwap-base-mib-00 and draft-ietf-capwap-802dot11-mib-00, I gave my comments inline (each one is identified by -->). Most comments are accepted, thanks a lot.=20 As Dan's said, the MIB drafts should take more time in the work of synchronization between the MIB and the CAPWAP protocol document. New version of MIB drafts will do it. Message: 1 Date: Tue, 22 Jul 2008 13:39:32 +0200 From: "Romascanu, Dan (Dan)" Subject: [Capwap] Comments on draft-ietf-capwap-base-mib-00 To: Message-ID: =09 Content-Type: text/plain; charset=3D"us-ascii" This is only a partial reviews and not yet a full MIB Doctor review. I = am seeing a lot of problems in modeling and lack of synchronization between = the MIB and the CAPWAP protocol document, so I would recommend that the = authors of the protocol document and other WG members do a detailed check and comparison between the two documents.=20 --> Yes. New version of MIB drafts will do it. 1. smilint complains about:=20 mibs/CAPWAP-MIB:314: [5] {identifier-case-match} warning: identifier `capwapWTPId' differs from `CapwapWTPId' only in case -->Yes, a new name should be found for TC `CapwapWTPId". I will take sometime to get a good name. mibs/CAPWAP-MIB:632: [5] {identifier-case-match} warning: identifier `capwapRadioId' differs from `CapwapRadioId' only in case\ -->Yes, a new name should be found for TC `CapwapRadioId". I will take sometime to get a good name. mibs/CAPWAP-MIB:712: [5] {identifier-case-match} warning: identifier `capwapStationId' differs from `CapwapStationId' only in case -->Yes, a new name should be found for TC CapwapStationId". I will take sometime to get a good name. mibs/CAPWAP-MIB:1334: [5] {identifier-case-match} warning: identifier `capwapChannelType' differs from `CapwapChannelType' only in case --> Rename the `capwapChannelType' as "capwapBaseProtocolChannel" mibs/CAPWAP-MIB:1342: [5] {identifier-case-match} warning: identifier `capwapWTPAuthenMethod' differs from `CapwapWTPAuthenMethod' only in = case --> Rename capwapWTPAuthenMethod as capwapBaseAuthenMethod --> Rename CapwapWTPAuthenMethod as capwapBaseWTPAuthenMethod The problem is that object names are similar to TC names, excepting capitalization 2. smilint complains about:=20 mibs/CAPWAP-MIB:294: [5] {index-element-accessible} warning: index = element `capwapWTPId' of row `capwapWTPStateEntry' should be not-accessible in = SMIv2 MIB mibs/CAPWAP-MIB:613: [5] {index-element-accessible} warning: index = element `capwapRadioId' of row `capwapRadioBindEntry' should be not-accessible = in SMIv2 MIB Objects that are indices in tables should be not-accessible, and if = there is a need to use the objects for notifications they should be duplicated in = the table.=20 -->OK 3. smilint complains about: mibs/CAPWAP-MIB:1672: [5] {group-unref} warning: current group `capwapStationsGroup' is not referenced in this module --> The capwapStationsGroup should be added into MANDATORY-GROUPS . 4. It would be better that all objects in the MIB module have a common naming prefix beyond capwap which is common to all capwap MIB modules. = Maybe capwapBase or capwapProto.=20 --> OK. All objects in the MIB file should use a common naming prefix "capwapBase". 5. The Introduction should refer to the CAPWAP work as to stable work = not 'under way' --> OK.=20 6. Overview - it looks to me that the first objective ('To work well = under centralized architectures') and the fifth one ('to meet operator requirements for centralized architectures') are redundant ---> The first objective is to explain the objective from technique perspective. The SNMP design should follow the CAPWAP protocol design = idea. ---> The fifth one is to explain the objective from operator = perspective. --> Could have a better way to explain the objective? 7. 'The SNMP agent run on the AC side, and it MAY not be required on the = WTP side' - it is not clear what is meant here, and the usage of the RFC2119 language is not appropriate. Does it mean to say 'The CAPWAP-MIB MUST be = run on the AC devices and is NOT REQUIRED on the WTP devices'? =20 ---> Yes. 'The CAPWAP-MIB MUST be run on the AC devices and is NOT = REQUIRED on the WTP devices' will be used. 8. Instead of 'ifIndex [RFC2863] will play a role in bridging between = MIB standards defined by different SDOs' better say 'ifIndex [RFC2863] will = be used as common handler for corresponding interfaces in the CAPWAP-MIB = and specific wireless technologies MIB modules'.=20 --> Ok 9. 'To reuse MIB objects (defined by SDOs such as IEEE) for radio is = very import' - s/import/important/ --> Yes. should be important. 10. There is no need for section 6.1 to duplicate the textual = conventions defined in the MIB module itself --> OK, the section 6.1 will be removed. 11. Section 7.2 - does not ifName map into WTP name? same ifDescr into = WTP descriptor?=20 -->ifIndex will corresponding to a radio(Not a WTP), so ifName will not = map into a WTP name. --> It is same for ifDescr. 12. Section 7.3 - what is the entPhysicalClass that is recommended for = the usage of RFC4133?=20 --> I think the RFC4133 does not have a valid Physical class for CAPWAP architecture. --> I suggest to use other(1) for entPhysicalClass. 13. Naming consistency - it would be good to keep object names under a = node with the same prefix as the node name - e.g. capwapAC -> = capwapACWTPSessions or better capwapBaseAC -> capwapBaseACWTPSessions, etc. --> Ok, capwapBaseAC will be used. 14. CapWapWTPAuthenMethod - it would be better to put other(1) as the = first enumerated value.=20 -->OK 15. Objects like capwapWTPSessionsLimit have a limited range in the = CAPWAP protocol dictated by the numbers of bits used for their representation = (16 for example) - it would be appropriate to limit the range of the = Unsigned32 accordingly --> Yes 16. capwapDataChannelSecOptions, capwapWTPAuthenOptions - the BIT = construct should be used as SYNTAX --> Yes 17. capwapWTPACNameList is SIZE(256) in the MIB and 512 in section 4.6.5 = of the protocol document.=20 -->Should use 512 18. capwapWTPState has one state dtls(1) while the state diagram in = section 2.3.1 of the protocol document mentions three different states 'DTLS = Setup', DTLS Connect', 'DTLS TD' - is dtls(1) supposed to cover all three? If so please be explicit in the DESCRIPTION clause -->The dtls(1) supposes to cover all three. DESCRIPTION will give the information. 19. capwapWTPMACTypeOptions has a SYNTAX of CapwapWTPMACType which is an enumerated, but the DESCRIPTION clause indicates that BITS SYNTAX should = be used here.=20 --->CapwapWTPMACType should add one option "all(3) Support both = Local-MAC and Split-MAC mode" 20. The SYNTAX of capwapStationVlanName should be SnmpAdminString -->OK 21. It would be good to find a more adequate name for the = capwapVariables group --> How about "capwapBaseParameters"? 22. why is there a need to define a special group for objects for notifications, instead of defining these objects in the other = configuration tables in the MIB module --> The objects such as capwapImageFailureReason are only required for notifications. 23. What is the functionality of the capwapIdEntryNum? The reference to section 4.6.15 in the protocol document seems to be wrong, this is the CAPWAP transport protocol --> Yes, capwapIdEntryNum is not required. Regards, Dan Message: 2 Date: Tue, 22 Jul 2008 14:30:53 +0200 From: "Romascanu, Dan (Dan)" Subject: [Capwap] comments on draft-ietf-capwap-802dot11-mib-00 To: Message-ID: =09 Content-Type: text/plain; charset=3D"us-ascii" This is not yet a full MIB Doctor review. 1. smilint complains=20 mibs/CAPWAP-DOT11-MIB:117: [5] {identifier-case-match} warning: = identifier `capwapDot11WLANId' differs from `CapwapDot11WLANId' only in case You need to define name objects different from TC names ---> Yes, a new name should be found for TC `CapwapDot11WLANId". I will = take sometime to get a good name. 2. The Introduction should refer to the CAPWAP work as to stable work = not 'under way' --> OK 3. There is no need for section 6.1 to duplicate the textual conventions defined in the MIB module itself --> The section 6.1 will be removed. 4. There is no definition of the persistency of read-write or = read-create objects for the capwapDot11WLANConfigTable, or a StorageType object in = the rows.=20 --> The section will be updated. 5. The names of the capwapWTPMacType and capwapWTPTunnelMode objects do = not respect the naming convention for the MIB module.=20 --> OK. All objects in the MIB file should use a common naming prefix "capwapDot11". Regards, Dan -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: capwap-request@frascone.com = [mailto:capwap-request@frascone.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2008=C4=EA7=D4=C223=C8=D5 18:16 =CA=D5=BC=FE=C8=CB: capwap@frascone.com =D6=F7=CC=E2: Capwap Digest, Vol 32, Issue 34 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. Comments on draft-ietf-capwap-base-mib-00 (Romascanu, Dan (Dan)) 2. comments on draft-ietf-capwap-802dot11-mib-00 (Romascanu, Dan (Dan)) 3. Last Call: draft-ietf-capwap-protocol-binding-ieee80211 (CAPWAP Protocol Binding for IEEE 802.11) to Proposed Standard (The IESG) 4. Last Call: draft-ietf-capwap-protocol-specification (CAPWAP Protocol Specification) to Proposed Standard (The IESG) 5. Issue 150: binding doc. 802.11 wlan config req/resp msg typevalueissue (Pat Calhoun (pacalhou)) 6. Issue 149: Incompatibility with message element numbering between drafts 10 and 11 (Pat Calhoun (pacalhou)) ---------------------------------------------------------------------- Message: 1 Date: Tue, 22 Jul 2008 13:39:32 +0200 From: "Romascanu, Dan (Dan)" Subject: [Capwap] Comments on draft-ietf-capwap-base-mib-00 To: Message-ID: =09 Content-Type: text/plain; charset=3D"us-ascii" This is only a partial reviews and not yet a full MIB Doctor review. I am seeing a lot of problems in modeling and lack of synchronization between the MIB and the CAPWAP protocol document, so I would recommend that the authors of the protocol document and other WG members do a detailed check and comparison between the two documents.=20 1. smilint complains about:=20 mibs/CAPWAP-MIB:314: [5] {identifier-case-match} warning: identifier `capwapWTPId' differs from `CapwapWTPId' only in case mibs/CAPWAP-MIB:632: [5] {identifier-case-match} warning: identifier `capwapRadioId' differs from `CapwapRadioId' only in case mibs/CAPWAP-MIB:712: [5] {identifier-case-match} warning: identifier `capwapStationId' differs from `CapwapStationId' only in case mibs/CAPWAP-MIB:1334: [5] {identifier-case-match} warning: identifier `capwapChannelType' differs from `CapwapChannelType' only in case mibs/CAPWAP-MIB:1342: [5] {identifier-case-match} warning: identifier `capwapWTPAuthenMethod' differs from `CapwapWTPAuthenMethod' only in case The problem is that object names are similar to TC names, excepting capitalization 2. smilint complains about:=20 mibs/CAPWAP-MIB:294: [5] {index-element-accessible} warning: index element `capwapWTPId' of row `capwapWTPStateEntry' should be not-accessible in SMIv2 MIB mibs/CAPWAP-MIB:613: [5] {index-element-accessible} warning: index element `capwapRadioId' of row `capwapRadioBindEntry' should be not-accessible in SMIv2 MIB Objects that are indices in tables should be not-accessible, and if there is a need to use the objects for notifications they should be duplicated in the table.=20 3. smilint complains about: mibs/CAPWAP-MIB:1672: [5] {group-unref} warning: current group `capwapStationsGroup' is not referenced in this module 4. It would be better that all objects in the MIB module have a common naming prefix beyond capwap which is common to all capwap MIB modules. Maybe capwapBase or capwapProto.=20 5. The Introduction should refer to the CAPWAP work as to stable work not 'under way' 6. Overview - it looks to me that the first objective ('To work well under centralized architectures') and the fifth one ('to meet operator requirements for centralized architectures') are redundant 7. 'The SNMP agent run on the AC side, and it MAY not be required on the WTP side' - it is not clear what is meant here, and the usage of the RFC2119 language is not appropriate. Does it mean to say 'The CAPWAP-MIB MUST be run on the AC devices and is NOT REQUIRED on the WTP devices'? =20 8. Instead of 'ifIndex [RFC2863] will play a role in bridging between MIB standards defined by different SDOs' better say 'ifIndex [RFC2863] will be used as common handler for corresponding interfaces in the CAPWAP-MIB and specific wireless technologies MIB modules'.=20 9. 'To reuse MIB objects (defined by SDOs such as IEEE) for radio is very import' - s/import/important/ 10. There is no need for section 6.1 to duplicate the textual conventions defined in the MIB module itself 11. Section 7.2 - does not ifName map into WTP name? same ifDescr into WTP descriptor?=20 12. Section 7.3 - what is the entPhysicalClass that is recommended for the usage of RFC4133?=20 13. Naming consistency - it would be good to keep object names under a node with the same prefix as the node name - e.g. capwapAC -> capwapACWTPSessions or better capwapBaseAC -> capwapBaseACWTPSessions, etc. 14. CapWapWTPAuthenMethod - it would be better to put other(1) as the first enumerated value.=20 15. Objects like capwapWTPSessionsLimit have a limited range in the CAPWAP protocol dictated by the numbers of bits used for their representation (16 for example) - it would be appropriate to limit the range of the Unsigned32 accordingly 16. capwapDataChannelSecOptions, capwapWTPAuthenOptions - the BIT construct should be used as SYNTAX 17. capwapWTPACNameList is SIZE(256) in the MIB and 512 in section 4.6.5 of the protocol document.=20 18. capwapWTPState has one state dtls(1) while the state diagram in section 2.3.1 of the protocol document mentions three different states 'DTLS Setup', DTLS Connect', 'DTLS TD' - is dtls(1) supposed to cover all three? If so please be explicit in the DESCRIPTION clause 19. capwapWTPMACTypeOptions has a SYNTAX of CapwapWTPMACType which is an enumerated, but the DESCRIPTION clause indicates that BITS SYNTAX should be used here.=20 20. The SYNTAX of capwapStationVlanName should be SnmpAdminString 21. It would be good to find a more adequate name for the capwapVariables group 22. why is there a need to define a special group for objects for notifications, instead of defining these objects in the other configuration tables in the MIB module 23. What is the functionality of the capwapIdEntryNum? The reference to section 4.6.15 in the protocol document seems to be wrong, this is the CAPWAP transport protocol Regards, Dan ------------------------------ Message: 2 Date: Tue, 22 Jul 2008 14:30:53 +0200 From: "Romascanu, Dan (Dan)" Subject: [Capwap] comments on draft-ietf-capwap-802dot11-mib-00 To: Message-ID: =09 Content-Type: text/plain; charset=3D"us-ascii" This is not yet a full MIB Doctor review. 1. smilint complains=20 mibs/CAPWAP-DOT11-MIB:117: [5] {identifier-case-match} warning: identifier `capwapDot11WLANId' differs from `CapwapDot11WLANId' only in case You need to define name objects different from TC names 2. The Introduction should refer to the CAPWAP work as to stable work not 'under way' 3. There is no need for section 6.1 to duplicate the textual conventions defined in the MIB module itself 4. There is no definition of the persistency of read-write or read-create objects for the capwapDot11WLANConfigTable, or a StorageType object in the rows.=20 5. The names of the capwapWTPMacType and capwapWTPTunnelMode objects do not respect the naming convention for the MIB module.=20 Regards, Dan ------------------------------ Message: 3 Date: Tue, 22 Jul 2008 05:45:44 -0700 (PDT) From: The IESG Subject: [Capwap] Last Call: draft-ietf-capwap-protocol-binding-ieee80211 (CAPWAP Protocol Binding for IEEE 802.11) to Proposed Standard To: IETF-Announce Cc: capwap@frascone.com Message-ID: <20080722124544.F25FC3A698A@core3.amsl.com> The IESG has received a request from the Control And Provisioning of=20 Wireless Access Points WG (capwap) to consider the following document: - 'CAPWAP Protocol Binding for IEEE 802.11 ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-08-05. Exceptionally,=20 comments may be sent to iesg@ietf.org instead. In either case, please=20 retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-capwap-protocol-binding-ie= ee8 0211-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D1527 5&rfc_flag=3D0 ------------------------------ Message: 4 Date: Tue, 22 Jul 2008 05:46:24 -0700 (PDT) From: The IESG Subject: [Capwap] Last Call: draft-ietf-capwap-protocol-specification (CAPWAP Protocol Specification) to Proposed Standard To: IETF-Announce Cc: capwap@frascone.com Message-ID: <20080722124624.6EE2A3A69D6@core3.amsl.com> The IESG has received a request from the Control And Provisioning of=20 Wireless Access Points WG (capwap) to consider the following document: - 'CAPWAP Protocol Specification ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-08-05. Exceptionally,=20 comments may be sent to iesg@ietf.org instead. In either case, please=20 retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-capwap-protocol-specificat= ion -11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D1446 7&rfc_flag=3D0 ------------------------------ Message: 5 Date: Tue, 22 Jul 2008 14:34:44 -0700 From: "Pat Calhoun (pacalhou)" Subject: [Capwap] Issue 150: binding doc. 802.11 wlan config req/resp msg typevalueissue To: Message-ID: =09 <4FF84B0BC277FF45AA27FE969DD956A2062748C8@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=3D"us-ascii" All, I have made the fixes for the issue raised. The crux of the issue is that the message element numbering requires that the first three octets be used for the IANA Enterprise Number, for which 802.11 uses 13277. The issue is that the base draft also requires that requests be odd numbered, and responses be even numbered. However, the -7 draft uses the inverse, where the request is even numbered and the response is odd numbered.=20 The downside here is that this creates a backward compatibility issue with -07, which has been through WG Last Call, but it is a necessary change in order to comply with the numbering rules laid out in the base draft. So the new text looks like: 3. IEEE 802.11 Specific CAPWAP Control Messages [...] CAPWAP Control Message Message Type Value IEEE 802.11 WLAN Configuration Request 3398913 IEEE 802.11 WLAN Configuration Response 3398914 PatC ------------------------------ Message: 6 Date: Tue, 22 Jul 2008 14:34:43 -0700 From: "Pat Calhoun (pacalhou)" Subject: [Capwap] Issue 149: Incompatibility with message element numbering between drafts 10 and 11 To: Message-ID: =09 <4FF84B0BC277FF45AA27FE969DD956A2062748C7@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=3D"us-ascii" All, I have made the necessary changes to the document that will eventually become -12 to ensure that the numbering of the message elements in the base draft are consistent with -10. I do, however, want to note that -10 had an error. While the table in section 4.6 showed the value 22 for the "Duplication IPv6 Address" message element, the value shown in the message element definition in section 4.6.25 was 23 and incorrect. The value in section 4.6.25, was both inconsistent with the table, but more importantly, conflicted with the Idle Timeout message element (section 4.6.26).=20 This bug did not exist in -11, since I had renumbered all message elements. However, issue 149 requires me to change all of the message element type values to those found in -10. I wanted to note that I have corrected this bug in -12, which of course, means that the two drafts will differ in this regard. However, the message element table values are consistent across both -10 and -12. PatC ------------------------------ _________________________________________________________________ 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 32, Issue 34 ************************************** --===============1801864836== 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 --===============1801864836==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 28 05:41:28 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6906A3A67AA for ; Mon, 28 Jul 2008 05:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbXvTOZEDLjW for ; Mon, 28 Jul 2008 05:41:27 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id EAD183A6944 for ; Mon, 28 Jul 2008 05:41:26 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2D0001C40F4C for ; Mon, 28 Jul 2008 05:41:35 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 1634744012C for ; Sat, 26 Jul 2008 08:14:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D8CBA34AC089 for ; Sat, 26 Jul 2008 08:14:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0F6B534AC078 for ; Sat, 26 Jul 2008 08:14:46 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.105.134 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by mx1.tigertech.net (Postfix) with ESMTP for ; Sat, 26 Jul 2008 08:14:45 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6QFEYoB013719; Sat, 26 Jul 2008 10:14:37 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 26 Jul 2008 18:14:33 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 26 Jul 2008 18:14:19 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 26 Jul 2008 18:14:17 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7201350A06@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last call comments for capwap-protocol-specification-11 Thread-Index: AcjvMkW5w2XuuDfaQ6elKwP6Kje8UA== From: To: X-OriginalArrivalTime: 26 Jul 2008 15:14:19.0644 (UTC) FILETIME=[46DE5BC0:01C8EF32] X-Nokia-AV: Clean X-Mailman-Approved-At: Mon, 28 Jul 2008 05:41:23 -0700 Cc: capwap@frascone.com Subject: [Capwap] Last call comments for capwap-protocol-specification-11 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 I read capwap-protocol-specification-11 on my way to Dublin; here are some comments/observations. Substantial topics first: Section 3.5: The text about MTU discovery doesn't look right; Section 3.5 seems to assume that after the WTP has discovered the AC it wishes to communicate with, RFC 1191/1981/4821 would provide it with the MTU, and then the WTP would establish the CAPWAP session. But those RFCs don't specify e.g. what packets would be used for probing for the MTU. Section 4.6.29: Using MD5 in a new protocol, and not providing algorithm agility for moving to new algorithms, is probably not such a great idea. The linking of control and data channels, and how DTLS session resumption is used here, seems unnecessarily complicated. Normally session resumption is totally TLS internal optimization, and applications running over TLS don't know (and have no need to know) whether full or abbreviated TLS handshake was used. It seems this document wouldn't really need to say anything about session resumption; if the WTP provides the Session ID in data channel, and AC checks that both DTLS connections were established by the same authenticated client, that seems sufficient. This would seem to remove much implementation complexity; e.g. the requirement in 4.4.3 that "The AC DTLS implementation MUST NOT accept a session resumption request for a DTLS session in which the control channel for the session has been torn down" doesn't follow the usual TLS/DTLS module boundaries. Section 3.3: Should IPv4 use a well-known multicast address (instead of broadcast), too? Why not? The protocol allows the AC to add and delete static MAC ACL entries, but it seems the AC can't check what the current ACL entries are. This means the WTP and AC could get out-of-sync, right? (The AC can't delete the unneeded static MAC ACL entries if it doesn't know what they are.) Section 3.3: there's a single sentence about DNS-based discovery; probably slightly more details would be useful. Section 2.4.3: handling of cookies that fail to validate is really a DTLS detail, and shouldn't be in this specification. RFC 4347 doesn't say what the DTLS server should do, but I think the right approach is to treat an invalid cookie the same as no cookie (and not discard the whole message, as is suggested here -- I think that could lead to weird failure modes even in the absence of malicious attackers). I'll raise this on the TLS mailing list, so it can be clarified in DTLS 1.2 update. Section 4.3: it seems that allocation of WBIDs (and message element numbers in 4.6) would be better done in the document specifying the binding. Considering that WBID allocations require Standards Action, especially allocating WBIDs for technologies for which not even an Internet-Draft exists yet seems premature. Section 4.5.3: Is CAPWAP control protocol strictly "lock-step" (once you send a Request, you must wait for Response until you send another Request), or are multiple outstanding requests allowed? Can you "give up" a Request (stop retransmitting it even though you haven't received a Response), and move to the next Request? What should you do if you receive a Request with a Sequence Number that's too old (less than previous Request you've seend) or too new (greater than previous Request+1)? Replay protection is an optional feature in RFC 4347. Should this document say something about it? (e.g. MUST use?) There's some inconsistency about NAT detection: Sections 4.6.12, 4.6.13, and 4.6.15 say it's done using "CAPWAP Local IPv4/6 address" message elements; Sections 4.6.44, 4.6.45, and 6.1 say it's using "WTP IPv4/6 address" message elements. Minor clarifications/editorial nits: Section 2, 1st para: should reference RFC4347 instead of RFC4346 Section 2.3: should have a sentence saying what transitions represented by punctuation characters mean. Section 2.4.1: "DTLS will never terminate the handshake due to non-responsiveness; instead, DTLS will continue to increase its back-off timer period" While RFC 4347 doesn't specify how long you should continue retransmitting, the intent certainly was not to continue indefinitely. Section 2.4.3 text about DTLS retransmissions is slightly inaccurate; DTLS handshake isn't strictly request/response, and both parties (not just the DTLS client) retransmit based on timers (in some situations). Section 2.4.4.1: should reference RFC4346 instead of RFC4279. Section 2.4.4.2: TLS_DHE_PSK_WITH_AES_256_CBC_SHA is listed twice. Section 4.4.1, "The 8 bit Length field" looks like 16 bits. Section 4.4.2: is it unambiguous which 802.3 frame fields are included or omitted? (e.g. preamble, SOF delimeter, etc.) Section 4.6, message element 29 is spelled "Image Information" in the rest of the document, but "Image Info" here Section 4.6.1, description of R-MAC Field needs some more text (current text would probably be fine if the field was only 1 bit, but it's 8 bits). Section 4.6.6 (AC Timestamp): the timestamp format in RFC 1305 is 64 bits, but the field here is only 32 bits. The description of bit fields needs clarification in several places: at least Section 4.6.1 (Security field), 4.6.1 (DTLS Policy field), 4.6.43 (Frame Tunnel Mode field). For example, the "Security" field currently seems to say that bit 1 is X.509, bit 2 is PSK, and bits 0 and 3..7 are unused -- but the intention was probably to say that bit 0 is X.509 and so on. This gets especially confusing in Section 4.6.43 (and associated IANA text in 15.21), where it's not even clear whether this is an enumeration or bit field. Drawing bit diagrams would be a good idea, IMHO. Section 4.6.50 (WTP Static IP Address Information): probably should have a sentence saying why this is for IPv4 only. Section 4.6.50 (WTP Static IP Address Information): "Netmask" field is listed twice. Section 4.6.28 (Image Identifier): length should be >= 5 (instead of 1)? Section 4.6.30 (Initiate Download): there's no message element named "Image Download" Section 6.1 (Join Request): WTP IPv4/6 IP Address are listed twice. Section 4.6.28 (Image Identifier) says this message element is sent by the AC to the WTP; but according to Section 9.1, it can also be sent by the WTP? Section 9.1.2: should say that "Image Information" and "Initiate Download" elements are included only when this message is sent by the AC. Section 12.2 says Session ID is 64 bits, but in Section 4.6.37, it's 32 bits. Section 12.5: This text probably needs to mention PSK Identity Hint as well. Section 15: Even if the well-known port numbers have already been allocated, it would be good to say they've been allocated by IANA. Section 15: needs to cite RFC 5226 for the "Standards Action" policy. Section 15: RFC 5226 says that documents requesting creation of new registries MUST include certain instructions for IANA (RFC 5226 Section 4.2) -- many of the details are currently missing. Various places: Needs a reference to RFC 3629 for UTF-8. Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 28 11:41:28 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF4263A6AA0 for ; Mon, 28 Jul 2008 11:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7sxnlwK-I3p for ; Mon, 28 Jul 2008 11:41:27 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id A3BD73A6993 for ; Mon, 28 Jul 2008 11:41:27 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 118FE439FE0 for ; Mon, 28 Jul 2008 11:41:38 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id EF933440129 for ; Mon, 28 Jul 2008 11:41:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id BFA5A34AC0AA for ; Mon, 28 Jul 2008 11:41:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id CD43934AC0A3 for ; Mon, 28 Jul 2008 11:41:18 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.72 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 28 Jul 2008 11:41:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,267,1215388800"; d="scan'208";a="90567824" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 28 Jul 2008 18:41:18 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6SIfIiW004053; Mon, 28 Jul 2008 11:41:18 -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.13.8/8.13.8) with ESMTP id m6SIfIFv010211; Mon, 28 Jul 2008 18:41:18 GMT 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, 28 Jul 2008 11:41:18 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 11:41:16 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CAF35@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB7201350A06@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Last call comments for capwap-protocol-specification-11 Thread-Index: AcjvMkW5w2XuuDfaQ6elKwP6Kje8UABrWvOw References: <1696498986EFEC4D9153717DA325CB7201350A06@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 28 Jul 2008 18:41:18.0178 (UTC) FILETIME=[85B7C420:01C8F0E1] Authentication-Results: sj-dkim-4; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Last call comments for capwap-protocol-specification-11 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 Thanks for the review, Pasi. We use tracker to keep track of all of our issues. My plan is to create a unique tracker entry for all of the substantial issues you raised here, and a single one for the minor claritifications/nits you include below. Please see below for information on the issues I created. I plan to create a new thread as we attack each issue, one by one (except the minor points that will be dealt with as a whole). I will CC you on each one of these since I do not know that you are on the CAPWAP list. PatC > I read capwap-protocol-specification-11 on my way to Dublin; here are some comments/observations. > > Substantial topics first: > > Section 3.5: The text about MTU discovery doesn't look right; Section > 3.5 seems to assume that after the WTP has discovered the AC it wishes to communicate with, RFC 1191/1981/4821 would > provide it with the MTU, and then the WTP would establish the CAPWAP session. But those RFCs don't specify e.g. what > packets would be used for probing for the MTU. Created as Issue 151: http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue151 > > Section 4.6.29: Using MD5 in a new protocol, and not providing algorithm agility for moving to new algorithms, is > probably not such a great idea. Created as Issue 152: http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue152 > > The linking of control and data channels, and how DTLS session resumption is used here, seems unnecessarily > complicated. Normally session resumption is totally TLS internal optimization, and applications running over TLS don't > know (and have no need to know) whether full or abbreviated TLS handshake was used. It seems this document wouldn't > really need to say anything about session resumption; if the WTP provides the Session ID in data channel, and AC checks > that both DTLS connections were established by the same authenticated client, that seems sufficient. This would seem > to remove much implementation complexity; e.g. the requirement in 4.4.3 that "The AC DTLS implementation MUST NOT > accept a session resumption request for a DTLS session in which the control channel for the session has been torn > down" doesn't follow the usual TLS/DTLS module boundaries. Created as Issue 153: http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue153 > > Section 3.3: Should IPv4 use a well-known multicast address (instead of broadcast), too? Why not? Created as Issue 154: http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue154 > > The protocol allows the AC to add and delete static MAC ACL entries, but it seems the AC can't check what the current > ACL entries are. > This means the WTP and AC could get out-of-sync, right? (The AC can't delete the unneeded static MAC ACL entries if it > doesn't know what they are.) Created as Issue 155: http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue155 > > Section 3.3: there's a single sentence about DNS-based discovery; probably slightly more details would be useful. Created as Issue 156: http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue156 > > Section 2.4.3: handling of cookies that fail to validate is really a DTLS detail, and shouldn't be in this > specification. RFC 4347 doesn't say what the DTLS server should do, but I think the right approach is to treat an > invalid cookie the same as no cookie (and not discard the whole message, as is suggested here -- I think that could > lead to weird failure modes even in the absence of malicious attackers). I'll raise this on the TLS mailing list, so > it can be clarified in DTLS 1.2 update. Created as Issue 157: http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue157 > > Section 4.3: it seems that allocation of WBIDs (and message element numbers in 4.6) would be better done in the > document specifying the binding. Considering that WBID allocations require Standards Action, especially allocating > WBIDs for technologies for which not even an Internet-Draft exists yet seems premature. Created as Issue 158: http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue158 > > Section 4.5.3: Is CAPWAP control protocol strictly "lock-step" (once you send a Request, you must wait for Response > until you send another Request), or are multiple outstanding requests allowed? Can you "give up" a Request (stop > retransmitting it even though you haven't received a Response), and move to the next Request? What should you do if > you receive a Request with a Sequence Number that's too old (less than previous Request you've seend) or too new > (greater than previous Request+1)? Created as Issue 159: http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue159 > > Replay protection is an optional feature in RFC 4347. Should this document say something about it? (e.g. MUST use?) Created as Issue 160: http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue160 > > There's some inconsistency about NAT detection: Sections 4.6.12, 4.6.13, and 4.6.15 say it's done using "CAPWAP Local > IPv4/6 address" > message elements; Sections 4.6.44, 4.6.45, and 6.1 say it's using "WTP > IPv4/6 address" message elements. Created as Issue 161: http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue161 > > > > Minor clarifications/editorial nits: > > Section 2, 1st para: should reference RFC4347 instead of RFC4346 > > Section 2.3: should have a sentence saying what transitions represented by punctuation characters mean. > > Section 2.4.1: "DTLS will never terminate the handshake due to non-responsiveness; instead, DTLS will continue to > increase its back-off timer period" While RFC 4347 doesn't specify how long you should continue retransmitting, the > intent certainly was not to continue indefinitely. > > Section 2.4.3 text about DTLS retransmissions is slightly inaccurate; DTLS handshake isn't strictly request/response, > and both parties (not just the DTLS client) retransmit based on timers (in some situations). > > Section 2.4.4.1: should reference RFC4346 instead of RFC4279. > Section 2.4.4.2: TLS_DHE_PSK_WITH_AES_256_CBC_SHA is listed twice. > > Section 4.4.1, "The 8 bit Length field" looks like 16 bits. > > Section 4.4.2: is it unambiguous which 802.3 frame fields are included or omitted? (e.g. preamble, SOF delimeter, etc.) > > Section 4.6, message element 29 is spelled "Image Information" > in the rest of the document, but "Image Info" here > > Section 4.6.1, description of R-MAC Field needs some more text (current text would probably be fine if the field was > only 1 bit, but it's 8 bits). > > Section 4.6.6 (AC Timestamp): the timestamp format in RFC 1305 is > 64 bits, but the field here is only 32 bits. > > The description of bit fields needs clarification in several places: > at least Section 4.6.1 (Security field), 4.6.1 (DTLS Policy field), > 4.6.43 (Frame Tunnel Mode field). For example, the "Security" field currently seems to say that bit 1 is X.509, bit 2 > is PSK, and bits 0 and 3..7 are unused -- but the intention was probably to say that bit 0 is X.509 and so on. This > gets especially confusing in Section 4.6.43 (and associated IANA text in 15.21), where it's not even clear whether this > is an enumeration or bit field. Drawing bit diagrams would be a good idea, IMHO. > > Section 4.6.50 (WTP Static IP Address Information): probably should have a sentence saying why this is for IPv4 only. > > Section 4.6.50 (WTP Static IP Address Information): "Netmask" field is listed twice. > > Section 4.6.28 (Image Identifier): length should be >= 5 (instead of 1)? > > Section 4.6.30 (Initiate Download): there's no message element named "Image Download" > > Section 6.1 (Join Request): WTP IPv4/6 IP Address are listed twice. > > Section 4.6.28 (Image Identifier) says this message element is sent by the AC to the WTP; but according to Section 9.1, > it can also be sent by the WTP? > > Section 9.1.2: should say that "Image Information" and "Initiate Download" elements are included only when this message > is sent by the AC. > > Section 12.2 says Session ID is 64 bits, but in Section 4.6.37, it's 32 bits. > > Section 12.5: This text probably needs to mention PSK Identity Hint as well. > > Section 15: Even if the well-known port numbers have already been allocated, it would be good to say they've been > allocated by IANA. > > Section 15: needs to cite RFC 5226 for the "Standards Action" policy. > > Section 15: RFC 5226 says that documents requesting creation of new registries MUST include certain instructions for > IANA (RFC 5226 Section 4.2) -- many of the details are currently missing. > > Various places: Needs a reference to RFC 3629 for UTF-8. Created as Issue 162: http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue162 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 28 11:49:01 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4C73A6ADE for ; Mon, 28 Jul 2008 11:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gUDgtP6jdni for ; Mon, 28 Jul 2008 11:49:00 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 720333A6AF3 for ; Mon, 28 Jul 2008 11:49:00 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B9ED343070A for ; Mon, 28 Jul 2008 11:49:08 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 8A3CF440145 for ; Mon, 28 Jul 2008 11:48:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 40BD434AC04E for ; Mon, 28 Jul 2008 11:48:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 48DB134AC0BE for ; Mon, 28 Jul 2008 11:48:22 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 28 Jul 2008 11:48:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,267,1215388800"; d="scan'208";a="69760235" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 28 Jul 2008 18:48:21 +0000 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/8.12.11) with ESMTP id m6SImLJg023010; Mon, 28 Jul 2008 11:48:21 -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.13.8/8.13.8) with ESMTP id m6SImLMZ028028; Mon, 28 Jul 2008 18:48:21 GMT 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, 28 Jul 2008 11:48:21 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 11:48:21 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CAF53@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 152: Need crypto protocol agility Thread-Index: Acjw4oHLYyukKDPST9eZ/dsEadCGVg== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 28 Jul 2008 18:48:21.0464 (UTC) FILETIME=[82041580:01C8F0E2] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 152: Need crypto protocol agility 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 All, Pasi's comment is: Section 4.6.29: Using MD5 in a new protocol, and not providing algorithm agility for moving to new algorithms, is probably not such a great idea Specifically, the text currently looks like: 4.6.29. Image Information The Image Information message element is present in the Image Data Response message sent by the AC to the WTP and 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | File Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hash | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hash | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hash | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hash | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 29 for Image Information Length: 20 File Size: A 32-bit value containing the size of the file, in bytes, that will be transferred by the AC to the WTP. Hash: A 16 octet hash of the image. The hash is computed using MD5, using the following pseudo-code: #include CapwapCreateHash(char *hash, char *image, int image_len) { MD_CTX context; MDInit (&context); MDUpdate (&context, buffer, len); MDFinal (hash, &context); } Certainly, it is possible to create a new field immediately following the File Size field, called Algorithm Identifier. This field would dictate the alg used in the generation of the Hash. This change is fairly simple and straightforward. ... But. There are two things that I'd like to raise here. 1. The hash is not created for security purposes, but rather for validation purposes. So I question whether we really need to worry about MD5 not being OK when creating a hash that is used to validate the contents. Even if MD5 was/is compromised, the purpose of this hash does not compromise anything. In fact, notice there is no "secret" used here either. So nothing is at risk. 2. This change would break backward CAPWAP interoperability. Because of issue number two (2), I'd like to get the WG's opinion on whether this change would be addressed, or rejected. Pasi, any comments on this? 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 Mon Jul 28 11:51:44 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37A813A6AF3 for ; Mon, 28 Jul 2008 11:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Vl+fRh3UVSf for ; Mon, 28 Jul 2008 11:51:39 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 8E9463A69A9 for ; Mon, 28 Jul 2008 11:51:39 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DA24C1C40F51 for ; Mon, 28 Jul 2008 11:51:49 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 0615944013B for ; Mon, 28 Jul 2008 11:51:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E7CCE34AC0C1 for ; Mon, 28 Jul 2008 11:51:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 627E134AC0AF for ; Mon, 28 Jul 2008 11:51:28 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.72 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 28 Jul 2008 11:51:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,267,1215388800"; d="scan'208";a="90571516" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 28 Jul 2008 18:51:26 +0000 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/8.12.11) with ESMTP id m6SIpQBa007613; Mon, 28 Jul 2008 11:51:26 -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.13.8/8.13.8) with ESMTP id m6SIpQQk000744; Mon, 28 Jul 2008 18:51:26 GMT 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.1830); Mon, 28 Jul 2008 11:51:26 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 11:51:26 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CAF60@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 153: Linking of control and data channels Thread-Index: Acjw4vA1vyAJJ+CuQ4208WWS+V7wsQ== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 28 Jul 2008 18:51:26.0599 (UTC) FILETIME=[F05D7170:01C8F0E2] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Pasi.Eronen@nokia.com, clancy@ltsnet.net Subject: [Capwap] Issue 153: Linking of control and data channels 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 Pasi's comment is: The linking of control and data channels, and how DTLS session resumption is used here, seems unnecessarily complicated. Normally session resumption is totally TLS internal optimization, and applications running over TLS don't know (and have no need to know) whether full or abbreviated TLS handshake was used. It seems this document wouldn't really need to say anything about session resumption; if the WTP provides the Session ID in data channel, and AC checks that both DTLS connections were established by the same authenticated client, that seems sufficient. This would seem to remove much implementation complexity; e.g. the requirement in 4.4.3 that "The AC DTLS implementation MUST NOT accept a session resumption request for a DTLS session in which the control channel for the session has been torn down" doesn't follow the usual TLS/DTLS module boundaries. Given the nature of the question, I would like to defer to Scott or Charles. I recall us going back and forth on this, and would like their guidance before we propose a change. 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 Mon Jul 28 12:43:28 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0D93A6B01 for ; Mon, 28 Jul 2008 12:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFxiWsuZr2X6 for ; Mon, 28 Jul 2008 12:43:27 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id B72C73A6AFD for ; Mon, 28 Jul 2008 12:43:27 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 61276439FCA for ; Mon, 28 Jul 2008 12:43:38 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id C0E3A4400F2 for ; Mon, 28 Jul 2008 12:42:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6728834AC007 for ; Mon, 28 Jul 2008 12:42:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5FC5334AC093 for ; Mon, 28 Jul 2008 12:42:57 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 28 Jul 2008 12:42:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,267,1215388800"; d="scan'208";a="69784859" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 28 Jul 2008 19:42:52 +0000 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/8.12.11) with ESMTP id m6SJgqt9011828; Mon, 28 Jul 2008 12:42:52 -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.13.8/8.13.8) with ESMTP id m6SJgqmd022290; Mon, 28 Jul 2008 19:42:52 GMT 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, 28 Jul 2008 12:42:51 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 12:42:56 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CAFCD@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 151: MTU discovery doesn't look right Thread-Index: Acjw6iHIcnbSlA5zSyuGML+2FIg5kw== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 28 Jul 2008 19:42:51.0997 (UTC) FILETIME=[1F67D0D0:01C8F0EA] Authentication-Results: sj-dkim-4; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 151: MTU discovery doesn't look right 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 Pasi's comment was: 3.5 seems to assume that after the WTP has discovered the AC it wishes to communicate with, RFC 1191/1981/4821 would provide it with the MTU, and then the WTP would establish the CAPWAP session. But those RFCs don't specify e.g. what packets would be used for probing for the MTU. I have taken a look at the RFCs, and he is correct. It looks like we had removed from functionality from the CAPWAP protocol prematurely some time ago. So I re-instated the MTU Discovery Padding message element (glad we had only commented out the text :). Here is the new text: 3.5. MTU Discovery Once a WTP has discovered the AC it wishes to establish a CAPWAP session with, it SHOULD perform a Path MTU (PMTU) discovery. One recommendation for performing PMTU discovery is to have the WTP transmit Discovery Request (see Section 5.1) messages, and include the MTU Discovery Padding message element (see Section 4.6.33). The actual procedures used for PMTU discovery are described in [RFC1191], for IPv4, or for IPv6 [RFC1981] SHOULD be used. Alternatively, implementers MAY use the procedures defined in [RFC4821]. The WTP SHOULD also periodically re-evaluate the PMTU using the guidelines provided in these two RFCs, using the Primary Discovery Request (see Section 5.3) along with the MTU Discovery Padding message element (see Section 4.6.33). When the MTU is initially known, or updated in the case where an existing session already exists, the discovered PMTU is used to configure the DTLS component (see Section 2.3.2.1), while non-DTLS frames need to be fragmented to fit the MTU, defined in Section 3.4. 4.6. CAPWAP Protocol Message Elements [...] MTU Discovery Padding 52 4.6.33. MTU Discovery Padding The MTU Discovery Padding message element is used as padding to perform MTU discovery, and MUST contain octets of value 0xFF, of any length. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Padding... +-+-+-+-+-+-+-+- Type: 52 for MTU Discovery Padding Length: variable Pad: A variable length pad, filled with the value 0xFF. 5.1. Discovery Request Message [...] The following message elements MAY be included in the Discovery Request message: o MTU Discovery Padding, see Section 4.6.33 5.3. Primary Discovery Request Message The Primary Discovery Request message is sent by the WTP to determine whether its preferred (or primary) AC is available or to performa a Path MTU Discovery (see section Section 3.5. [...] The following message elements MAY be included in the Primary Discovery Request message: o MTU Discovery Padding, see Section 4.6.33 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 Mon Jul 28 12:48:06 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C77233A6B01 for ; Mon, 28 Jul 2008 12:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbwdMWJrHi42 for ; Mon, 28 Jul 2008 12:48:06 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id EC2B23A69FA for ; Mon, 28 Jul 2008 12:48:05 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 918211C40F57 for ; Mon, 28 Jul 2008 12:48:16 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id F1C0E440100 for ; Mon, 28 Jul 2008 12:47:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 7F64134AC007 for ; Mon, 28 Jul 2008 12:47:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0B97334AC016 for ; Mon, 28 Jul 2008 12:47:51 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 28 Jul 2008 12:47:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,267,1215388800"; d="scan'208";a="58587879" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 28 Jul 2008 19:47:50 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6SJloh8026469; Mon, 28 Jul 2008 12:47:50 -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.13.8/8.13.8) with ESMTP id m6SJlk5C025601; Mon, 28 Jul 2008 19:47:50 GMT 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, 28 Jul 2008 12:47:46 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 12:47:51 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CAFD9@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 157: Issue with handling of cookies Thread-Index: Acjw6tG1G8u7uh1mSwuiFoQtIQlumA== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 28 Jul 2008 19:47:46.0948 (UTC) FILETIME=[CF35C440:01C8F0EA] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Pasi.Eronen@nokia.com, clancy@ltsnet.net Subject: [Capwap] Issue 157: Issue with handling of cookies 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 Here is Pasi's comment: Section 2.4.3: handling of cookies that fail to validate is really a DTLS detail, and shouldn't be in this specification. RFC 4347 doesn't say what the DTLS server should do, but I think the right approach is to treat an invalid cookie the same as no cookie (and not discard the whole message, as is suggested here -- I think that could lead to weird failure modes even in the absence of malicious attackers). I'll raise this on the TLS mailing list, so it can be clarified in DTLS 1.2 update. Given the nature of the question, I would like to defer to Scott or Charles. I recall us going back and forth on this, and would like their guidance before we propose a change. 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 Mon Jul 28 12:48:48 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E30F83A6B01 for ; Mon, 28 Jul 2008 12:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3JquGO7rjcs for ; Mon, 28 Jul 2008 12:48:47 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 164C83A69FA for ; Mon, 28 Jul 2008 12:48:47 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B03091C40F62 for ; Mon, 28 Jul 2008 12:48:57 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 3FE58440100 for ; Mon, 28 Jul 2008 12:48:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C09A134AC0E2 for ; Mon, 28 Jul 2008 12:48:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4B58A34AC0DF for ; Mon, 28 Jul 2008 12:48:39 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.72 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 28 Jul 2008 12:48:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,267,1215388800"; d="scan'208";a="90592274" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 28 Jul 2008 19:48:38 +0000 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/8.12.11) with ESMTP id m6SJmbvS007352; Mon, 28 Jul 2008 12:48:37 -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.13.8/8.13.8) with ESMTP id m6SJmbgV026225; Mon, 28 Jul 2008 19:48:37 GMT 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, 28 Jul 2008 12:48:37 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 12:48:41 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CAFDA@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 160: Use of Replay Protection Thread-Index: Acjw6u+d2TGpYkIvQWWEGcfXXleL/A== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 28 Jul 2008 19:48:37.0597 (UTC) FILETIME=[ED6630D0:01C8F0EA] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Pasi.Eronen@nokia.com, clancy@ltsnet.net Subject: [Capwap] Issue 160: Use of Replay Protection 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 Here is Pasi's comment: Replay protection is an optional feature in RFC 4347. Should this document say something about it? (e.g. MUST use?) Given the nature of the question, I would like to defer to Scott or Charles. I recall us going back and forth on this, and would like their guidance before we propose a change. 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 Mon Jul 28 12:55:21 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E351A3A6A03 for ; Mon, 28 Jul 2008 12:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzYGy-U91LAu for ; Mon, 28 Jul 2008 12:55:20 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id B96B03A68E5 for ; Mon, 28 Jul 2008 12:55:20 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 60B1B43A225 for ; Mon, 28 Jul 2008 12:55:31 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id DB399440119 for ; Mon, 28 Jul 2008 12:55:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5A07534AC057 for ; Mon, 28 Jul 2008 12:55:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8CF1434AC0A6 for ; Mon, 28 Jul 2008 12:55:09 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 28 Jul 2008 12:55:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,267,1215388800"; d="scan'208";a="58591662" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 28 Jul 2008 19:55:09 +0000 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/8.12.11) with ESMTP id m6SJt9nD006327; Mon, 28 Jul 2008 12:55:09 -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.13.8/8.13.8) with ESMTP id m6SJt9pR026991; Mon, 28 Jul 2008 19:55:09 GMT 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.1830); Mon, 28 Jul 2008 12:55:08 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 12:55:14 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CAFE4@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 154: Should we use IPv4 Multicast Address? Thread-Index: Acjw69m1Vw1OQWnKSgO8nGWyzCUNHw== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 28 Jul 2008 19:55:09.0083 (UTC) FILETIME=[D6BE36B0:01C8F0EB] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 154: Should we use IPv4 Multicast 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pasi's comment was: Section 3.3: Should IPv4 use a well-known multicast address (instead of broadcast), too? Why not? I'm not very familiar with the registration of a well-known multicast address. From what I can find at http://www.iana.org/assignments/multicast-addresses, the procedure must be very much the same as any other address space. That said, this has never come up by any AC/WTP vendor before, so I question whether the change is necessary. My response to Pasi on his "Why not?" is that our product has never, nor never will, do this. I can't speak for others, and will let them chime in. Thoughts? 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 Mon Jul 28 13:13:26 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96413A6B03 for ; Mon, 28 Jul 2008 13:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCtfh+PgiE13 for ; Mon, 28 Jul 2008 13:13:26 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 336C53A67A5 for ; Mon, 28 Jul 2008 13:13:26 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DB8A6439FAB for ; Mon, 28 Jul 2008 13:13:36 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id B7A90440109 for ; Mon, 28 Jul 2008 13:13:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2BC0034AC07B for ; Mon, 28 Jul 2008 13:13:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8F4C634AC028 for ; Mon, 28 Jul 2008 13:13:08 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 28 Jul 2008 13:13:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,267,1215388800"; d="scan'208";a="132717500" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 28 Jul 2008 20:12:45 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6SKCj1A004576; Mon, 28 Jul 2008 13:12:45 -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.13.8/8.13.8) with ESMTP id m6SKCitR024234; Mon, 28 Jul 2008 20:12:45 GMT 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, 28 Jul 2008 13:12:44 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 13:12:50 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CB002@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 156: Need more details on use of DNS for discovery Thread-Index: Acjw7k+CFmHJVrthTkC9sgWe7odDLw== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 28 Jul 2008 20:12:44.0800 (UTC) FILETIME=[4BFFD800:01C8F0EE] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 156: Need more details on use of DNS for 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 Pasi's comment was: Section 3.3: there's a single sentence about DNS-based discovery; probably slightly more details would be useful. Well... There's not much else we can say, but I am proposing the following text In hopes that it will provide more clarity to the implementor. 3.3. AC Discovery [...] DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or more AC addresses. A WTP that wishes to make use of DNS SHOULD use the format described in [RFC2782]. The recommended format for a lookup would be _capwap._udp.example.com. 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 Mon Jul 28 13:31:52 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FDD828C172 for ; Mon, 28 Jul 2008 13:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0Wm90AulCkq for ; Mon, 28 Jul 2008 13:31:51 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 129EA3A6B0A for ; Mon, 28 Jul 2008 13:31:51 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BA3C7439FEB for ; Mon, 28 Jul 2008 13:31:59 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id CF7B9440105 for ; Mon, 28 Jul 2008 13:31:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6CEFF34AC00A for ; Mon, 28 Jul 2008 13:31:46 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id EDA2D34AC07B for ; Mon, 28 Jul 2008 13:31:43 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 28 Jul 2008 13:31:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,267,1215388800"; d="scan'208";a="58609542" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 28 Jul 2008 20:31:43 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6SKVhuM015001; Mon, 28 Jul 2008 13:31:43 -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.13.8/8.13.8) with ESMTP id m6SKVhx8023634; Mon, 28 Jul 2008 20:31:43 GMT 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.1830); Mon, 28 Jul 2008 13:31:43 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 13:31:51 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CB02E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 158: Allocation of WBIDs Thread-Index: Acjw8PdCAVQM+IyqQnudEwaAE0luBg== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 28 Jul 2008 20:31:43.0398 (UTC) FILETIME=[F2A81C60:01C8F0F0] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 158: Allocation of WBIDs 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 Pasi's comment was: Section 4.3: it seems that allocation of WBIDs (and message element numbers in 4.6) would be better done in the document specifying the binding. Considering that WBID allocations require Standards Action, especially allocating WBIDs for technologies for which not even an Internet-Draft exists yet seems premature. The current text reads: 4.3. CAPWAP Header [...] WBID: A 5 bit field which is the wireless binding identifier. The identifier will indicate the type of wireless packet associated with the radio. The following values are defined: 0 - Reserved 1 - IEEE 802.11 2 - IEEE 802.16 3 - EPCGlobal [EPCGlobal] Frankly, I don't care much whether we adopt this proposed change. The IEEE 802.11 binding specification does not include the WBID value, so a change would be required for that specification. The bigger change, I suspect, is on the EPCGlobal spec. Of particular note, the CAPWAP spec currently requires a Standards Action to allocate one of these numbers, and since the RFID CAPWAP specification is being published by EPCGlobal, and not the IETF, I'm not sure how they could get a number assigned. Margaret, you are closer to this than I am, so do you have any recommendations? Finally, removing the IEEE 802.16 from the list is not a problem, and I agree that if there is ever a specification that defines the use of CAPWAP for 802.16, then the number would be assigned at that time. So if the change were to be made, the new text would read: 4.3. CAPWAP Header [...] WBID: A 5 bit field which is the wireless binding identifier. The identifier will indicate the type of wireless packet associated with the radio. 2.1. CAPWAP Wireless Binding Identifier The CAPWAP Header, defined in section 4.3 of [I-D.ietf-capwap-protocol-specification] requires that all CAPWAP binding specifications have a Wireless Binding Identifier (WBID) assigned. This document, which defines the IEEE 802.11 binding, uses the the value one (1). 10. IANA Considerations 10.1. CAPWAP Wireless Binding Identifier This specification defines a new Wireless Binding Identifier, which is used in the CAPWAP header. This value is defined in Section 2.1. 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 Mon Jul 28 18:06:25 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E027F3A68AD for ; Mon, 28 Jul 2008 18:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCkZraTNfM7k for ; Mon, 28 Jul 2008 18:06:24 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id C1C6D3A680C for ; Mon, 28 Jul 2008 18:06:24 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D2FAC43A20D for ; Mon, 28 Jul 2008 18:06:33 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 91D57440105 for ; Mon, 28 Jul 2008 17:55:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 23B2A34AC02A for ; Mon, 28 Jul 2008 17:55:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 1EDF234AC018 for ; Mon, 28 Jul 2008 17:55:06 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from bacon.cs.umd.edu (server-nat-4.cs.umd.edu [128.8.127.147]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 28 Jul 2008 17:55:05 -0700 (PDT) Received: from [127.0.0.1] ([130.129.19.129]) (authenticated bits=0) by bacon.cs.umd.edu (8.13.1/8.14.1) with ESMTP id m6T0sroF015062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 20:54:56 -0400 Message-ID: <488E6A5C.2060408@umd.edu> Date: Mon, 28 Jul 2008 20:54:52 -0400 From: Charles Clancy User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <4FF84B0BC277FF45AA27FE969DD956A2062CAF60@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2062CAF60@xmb-sjc-235.amer.cisco.com> X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-49, required 5, ALL_TRUSTED -50.00, UNSUB_DRH 1.00) X-CSD-MailScanner-From: tcc@umd.edu X-Mailman-Approved-At: Mon, 28 Jul 2008 18:06:21 -0700 Cc: capwap@frascone.com, Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 153: Linking of control and data channels 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 The goal of the text was to provide efficient interoperability, and handle all the edge cases. Typically when you use session resumption, you're resuming a session that's ended. Here we have two simultaneous DTLS sessions running, with the second one being a resumption of the first. We're using DTLS session resumption to quickly open a second tunnel while the first is still running. Given this use, I believe all the text in section 4.4.3 is necessary. The alternative would be to not say anything about it and leave it up to the DTLS implementations. I think this would result in having to do full authentications on the data channel more frequently than not. It could also possibly allow you to establish a data channel without a control channel. -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland Pat Calhoun (pacalhou) wrote: > Pasi's comment is: > > The linking of control and data channels, and how DTLS session > resumption is > used here, seems unnecessarily complicated. Normally session > resumption is > totally TLS internal optimization, and applications running over TLS > don't > know (and have no need to know) whether full or abbreviated TLS > handshake was > used. It seems this document wouldn't really need to say anything > about > session resumption; if the WTP provides the Session ID in data > channel, and AC > checks that both DTLS connections were established by the same > authenticated > client, that seems sufficient. This would seem to remove much > implementation > complexity; e.g. the requirement in 4.4.3 that "The AC DTLS > implementation > MUST NOT accept a session resumption request for a DTLS session in > which the > control channel for the session has been torn down" doesn't follow > the usual > TLS/DTLS module boundaries. > > Given the nature of the question, I would like to defer to Scott or > Charles. I recall us going back and forth on this, and would like their > guidance before we propose a change. > > PatC > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 28 18:06:42 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77B8E3A68AD for ; Mon, 28 Jul 2008 18:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vxzh-57Gg09n for ; Mon, 28 Jul 2008 18:06:41 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id A9DEA3A680C for ; Mon, 28 Jul 2008 18:06:41 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DD99C1C40F4E for ; Mon, 28 Jul 2008 18:06:52 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id F31E9440105 for ; Mon, 28 Jul 2008 18:04:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D83C834AC01B for ; Mon, 28 Jul 2008 18:04:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 39FB634AC018 for ; Mon, 28 Jul 2008 18:04:03 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from bacon.cs.umd.edu (server-nat-4.cs.umd.edu [128.8.127.147]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 28 Jul 2008 18:04:02 -0700 (PDT) Received: from [127.0.0.1] ([130.129.65.243]) (authenticated bits=0) by bacon.cs.umd.edu (8.13.1/8.14.1) with ESMTP id m6T13upk015197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 21:03:57 -0400 Message-ID: <488E6C7B.6010407@umd.edu> Date: Mon, 28 Jul 2008 21:03:55 -0400 From: Charles Clancy User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <4FF84B0BC277FF45AA27FE969DD956A2062CAFD9@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2062CAFD9@xmb-sjc-235.amer.cisco.com> X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-49, required 5, ALL_TRUSTED -50.00, UNSUB_DRH 1.00) X-CSD-MailScanner-From: tcc@umd.edu X-Mailman-Approved-At: Mon, 28 Jul 2008 18:06:21 -0700 Cc: capwap@frascone.com, Pasi.Eronen@nokia.com, clancy@ltsnet.net Subject: Re: [Capwap] Issue 157: Issue with handling of cookies 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 I'd be okay with treating a cookie failure as not receiving the cookie. Replace: If a cookie fails to validate, this could represent a WTP error, or it could represent a DoS attack. Hence, AC resource utilization SHOULD be minimized. The AC MAY log a message indicating the failure, but SHOULD NOT attempt to reply to the WTP. With: If a cookie fails to validate, this could represent a WTP error, or it could represent a DoS attack. Hence, AC resource utilization SHOULD be minimized. The AC MAY log a message indicating the failure, and SHOULD treat the message as though no cookie were present. -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland Pat Calhoun (pacalhou) wrote: > Here is Pasi's comment: > > Section 2.4.3: handling of cookies that fail to validate is really a > DTLS > detail, and shouldn't be in this specification. RFC 4347 doesn't say > what the > DTLS server should do, but I think the right approach is to treat an > invalid > cookie the same as no cookie (and not discard the whole message, as > is > suggested here -- I think that could lead to weird failure modes even > in the > absence of malicious attackers). I'll raise this on the TLS mailing > list, so > it can be clarified in DTLS 1.2 update. > > Given the nature of the question, I would like to defer to Scott or > Charles. I recall us going back and forth on this, and would like their > guidance before we propose a change. > > PatC > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jul 28 18:19:34 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11BB28C0D7 for ; Mon, 28 Jul 2008 18:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qToDg3Qn+MsJ for ; Mon, 28 Jul 2008 18:19:34 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 05B3B3A695F for ; Mon, 28 Jul 2008 18:19:34 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3B13D1C40FAA for ; Mon, 28 Jul 2008 18:19:45 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 6BEEE440105 for ; Mon, 28 Jul 2008 18:19:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4CF6234AC01B for ; Mon, 28 Jul 2008 18:19:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 34F0834AC018 for ; Mon, 28 Jul 2008 18:19:36 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 28 Jul 2008 18:19:35 -0700 (PDT) Received: from [209.86.224.48] (helo=elwamui-rustique.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KNdqc-0003jG-AR; Mon, 28 Jul 2008 21:17:54 -0400 Received: from 216.48.30.225 by webmail.earthlink.net with HTTP; Mon, 28 Jul 2008 21:17:29 -0400 Message-ID: <28807265.1217294249257.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> Date: Mon, 28 Jul 2008 18:17:29 -0700 (GMT-07:00) From: "Scott G. Kelly" To: Charles Clancy , "Pat Calhoun (pacalhou)" Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7b7f19f0d9c038d9aa478a2c1818ea2d8bead10c3a55da99be350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.48 Cc: capwap@frascone.com, Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 153: Linking of control and data channels 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 I agree with Charles. -----Original Message----- >From: Charles Clancy >Sent: Jul 28, 2008 5:54 PM >To: "Pat Calhoun (pacalhou)" >Cc: capwap@frascone.com, Pasi.Eronen@nokia.com >Subject: Re: [Capwap] Issue 153: Linking of control and data channels > >The goal of the text was to provide efficient interoperability, and >handle all the edge cases. Typically when you use session resumption, >you're resuming a session that's ended. Here we have two simultaneous >DTLS sessions running, with the second one being a resumption of the >first. We're using DTLS session resumption to quickly open a second >tunnel while the first is still running. Given this use, I believe all >the text in section 4.4.3 is necessary. > >The alternative would be to not say anything about it and leave it up to >the DTLS implementations. I think this would result in having to do >full authentications on the data channel more frequently than not. It >could also possibly allow you to establish a data channel without a >control channel. > >-- >t. charles clancy, ph.d. eng.umd.edu/~tcc >electrical & computer engineering, university of maryland > > >Pat Calhoun (pacalhou) wrote: >> Pasi's comment is: >> >> The linking of control and data channels, and how DTLS session >> resumption is >> used here, seems unnecessarily complicated. Normally session >> resumption is >> totally TLS internal optimization, and applications running over TLS >> don't >> know (and have no need to know) whether full or abbreviated TLS >> handshake was >> used. It seems this document wouldn't really need to say anything >> about >> session resumption; if the WTP provides the Session ID in data >> channel, and AC >> checks that both DTLS connections were established by the same >> authenticated >> client, that seems sufficient. This would seem to remove much >> implementation >> complexity; e.g. the requirement in 4.4.3 that "The AC DTLS >> implementation >> MUST NOT accept a session resumption request for a DTLS session in >> which the >> control channel for the session has been torn down" doesn't follow >> the usual >> TLS/DTLS module boundaries. >> >> Given the nature of the question, I would like to defer to Scott or >> Charles. I recall us going back and forth on this, and would like their >> guidance before we propose a change. >> >> PatC >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/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 Jul 28 18:32:21 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0874F3A694C for ; Mon, 28 Jul 2008 18:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xP5Bp1pmyce1 for ; Mon, 28 Jul 2008 18:32:20 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2E1823A6874 for ; Mon, 28 Jul 2008 18:32:20 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 671521C40F5D for ; Mon, 28 Jul 2008 18:32:31 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 9C14D440108 for ; Mon, 28 Jul 2008 18:09:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6E27834AC01B for ; Mon, 28 Jul 2008 18:09:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 037B834AC084 for ; Mon, 28 Jul 2008 18:09:18 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from bacon.cs.umd.edu (server-nat-4.cs.umd.edu [128.8.127.147]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 28 Jul 2008 18:09:17 -0700 (PDT) Received: from [127.0.0.1] ([130.129.65.169]) (authenticated bits=0) by bacon.cs.umd.edu (8.13.1/8.14.1) with ESMTP id m6T197np016385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 21:09:08 -0400 Message-ID: <488E6DB2.1080101@umd.edu> Date: Mon, 28 Jul 2008 21:09:06 -0400 From: Charles Clancy User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <4FF84B0BC277FF45AA27FE969DD956A2062CAFDA@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2062CAFDA@xmb-sjc-235.amer.cisco.com> X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-49, required 5, ALL_TRUSTED -50.00, UNSUB_DRH 1.00) X-CSD-MailScanner-From: tcc@umd.edu X-Mailman-Approved-At: Mon, 28 Jul 2008 18:32:20 -0700 Cc: capwap@frascone.com, Pasi.Eronen@nokia.com, clancy@ltsnet.net Subject: Re: [Capwap] Issue 160: Use of Replay Protection 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 Saying that DTLS replay detection MUST be used is okay with me. Section 4.5.3 has text that assumes DTLS replay detection is being used. -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland Pat Calhoun (pacalhou) wrote: > Here is Pasi's comment: > > Replay protection is an optional feature in RFC 4347. Should this > document say > something about it? (e.g. MUST use?) > > Given the nature of the question, I would like to defer to Scott or > Charles. I recall us going back and forth on this, and would like their > guidance before we propose a change. > > PatC > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 29 01:44:23 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E379F28C1DF for ; Tue, 29 Jul 2008 01:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcR1l2GLdPhk for ; Tue, 29 Jul 2008 01:44:22 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 6BC8728C0CE for ; Tue, 29 Jul 2008 01:44:22 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7AEB2430A41 for ; Tue, 29 Jul 2008 01:44:34 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id BA37D4400FE for ; Tue, 29 Jul 2008 01:44:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 7D95734AC02B for ; Tue, 29 Jul 2008 01:44:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C3B9F34AC045 for ; Tue, 29 Jul 2008 01:44:24 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from exchange.tm.thingmagic.com (exchange.tm.thingmagic.com [204.9.221.21]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 01:44:24 -0700 (PDT) Received: from [130.129.22.121] (130.129.22.121) by exchange.tm.thingmagic.com (10.0.0.9) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 29 Jul 2008 04:44:23 -0400 In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2062CAF53@xmb-sjc-235.amer.cisco.com> References: <4FF84B0BC277FF45AA27FE969DD956A2062CAF53@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 (Apple Message framework v753.1) Message-ID: From: Margaret Wasserman Date: Tue, 29 Jul 2008 09:44:20 +0100 To: Pat Calhoun X-Mailer: Apple Mail (2.753.1) Cc: capwap@frascone.com, Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 152: Need crypto protocol agility 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 I agree with Pat's reasoning about this being a non-security- sensitive checksum and would prefer not to change this section to add hash agility. Margaret On Jul 28, 2008, at 7:48 PM, Pat Calhoun (pacalhou) wrote: > All, > > Pasi's comment is: > > Section 4.6.29: Using MD5 in a new protocol, and not providing > algorithm > agility for moving to new algorithms, is probably not such a great > idea > > Specifically, the text currently looks like: > > > 4.6.29. Image Information > > The Image Information message element is present in the Image Data > Response message sent by the AC to the WTP and 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | File Size | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hash | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hash | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hash | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hash | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: 29 for Image Information > > Length: 20 > > File Size: A 32-bit value containing the size of the file, in > bytes, that will be transferred by the AC to the WTP. > > Hash: A 16 octet hash of the image. The hash is computed using > MD5, using the following pseudo-code: > > #include > CapwapCreateHash(char *hash, char *image, int image_len) > { > MD_CTX context; > > MDInit (&context); > MDUpdate (&context, buffer, len); > MDFinal (hash, &context); > } > > > Certainly, it is possible to create a new field immediately following > the File Size field, called Algorithm Identifier. This field would > dictate the alg used in the generation of the Hash. This change is > fairly simple and straightforward. > > ... But. There are two things that I'd like to raise here. > > 1. The hash is not created for security purposes, but rather for > validation purposes. So I question whether we really need to worry > about > MD5 not being OK when creating a hash that is used to validate the > contents. Even if MD5 was/is compromised, the purpose of this hash > does > not compromise anything. In fact, notice there is no "secret" used > here > either. So nothing is at risk. > > 2. This change would break backward CAPWAP interoperability. > > Because of issue number two (2), I'd like to get the WG's opinion on > whether this change would be addressed, or rejected. > > Pasi, any comments on this? > > PatC > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 29 01:48:04 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4394B3A6B1E for ; Tue, 29 Jul 2008 01:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlVlkPxn8JRQ for ; Tue, 29 Jul 2008 01:48:01 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D13093A6B15 for ; Tue, 29 Jul 2008 01:48:00 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E5F24430B60 for ; Tue, 29 Jul 2008 01:48:12 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id D29284400FE for ; Tue, 29 Jul 2008 01:48:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id A5AB934AC045 for ; Tue, 29 Jul 2008 01:48:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id EEE2B34AC078 for ; Tue, 29 Jul 2008 01:48:03 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from exchange.tm.thingmagic.com (exchange.tm.thingmagic.com [204.9.221.21]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 01:48:02 -0700 (PDT) Received: from [130.129.22.121] (130.129.22.121) by exchange.tm.thingmagic.com (10.0.0.9) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 29 Jul 2008 04:48:02 -0400 In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2062CAF60@xmb-sjc-235.amer.cisco.com> References: <4FF84B0BC277FF45AA27FE969DD956A2062CAF60@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 (Apple Message framework v753.1) Message-ID: From: Margaret Wasserman Date: Tue, 29 Jul 2008 09:47:59 +0100 To: Pat Calhoun X-Mailer: Apple Mail (2.753.1) Cc: capwap@frascone.com, Pasi.Eronen@nokia.com, clancy@ltsnet.net Subject: Re: [Capwap] Issue 153: Linking of control and data channels 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 On Jul 28, 2008, at 7:51 PM, Pat Calhoun (pacalhou) wrote: > Pasi's comment is: > > The linking of control and data channels, and how DTLS session > resumption is > used here, seems unnecessarily complicated. Normally session > resumption is > totally TLS internal optimization, and applications running over > TLS > don't > know (and have no need to know) whether full or abbreviated TLS > handshake was > used. It seems this document wouldn't really need to say anything > about > session resumption; if the WTP provides the Session ID in data > channel, and AC > checks that both DTLS connections were established by the same > authenticated > client, that seems sufficient. This would seem to remove much > implementation > complexity; e.g. the requirement in 4.4.3 that "The AC DTLS > implementation > MUST NOT accept a session resumption request for a DTLS session in > which the > control channel for the session has been torn down" doesn't follow > the usual > TLS/DTLS module boundaries. > > Given the nature of the question, I would like to defer to Scott or > Charles. I recall us going back and forth on this, and would like > their > guidance before we propose a change. I'd like to add one fact to the discussion of complexity in this protocol... We already have (at least) three implementations of the CAPWAP base protocol, including two completely independent implementations, that were tested together at an EPCglobal interoperability event last week. We didn't run into any significant problems getting the different implementations to work together. So, the level of complexity in the base spec doesn't seem to be causing interoperability problems in practice. I'd personally prefer that we err on the side of keeping things stable at this point, rather than trying to simplify them. 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 Tue Jul 29 01:55:16 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF78028C18D for ; Tue, 29 Jul 2008 01:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MP356OeaLlrQ for ; Tue, 29 Jul 2008 01:55:16 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id F145C3A6B36 for ; Tue, 29 Jul 2008 01:55:15 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 13EF8430BF1 for ; Tue, 29 Jul 2008 01:55:28 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 6945244014F for ; Tue, 29 Jul 2008 01:55:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4A4BC34AC02B for ; Tue, 29 Jul 2008 01:55:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id BAD7934AC045 for ; Tue, 29 Jul 2008 01:55:18 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from exchange.tm.thingmagic.com (exchange.tm.thingmagic.com [204.9.221.21]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 01:55:18 -0700 (PDT) Received: from [130.129.22.121] (130.129.22.121) by exchange.tm.thingmagic.com (10.0.0.9) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 29 Jul 2008 04:55:18 -0400 In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2062CB02E@xmb-sjc-235.amer.cisco.com> References: <4FF84B0BC277FF45AA27FE969DD956A2062CB02E@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 (Apple Message framework v753.1) Message-ID: From: Margaret Wasserman Date: Tue, 29 Jul 2008 09:55:14 +0100 To: Pat Calhoun X-Mailer: Apple Mail (2.753.1) Cc: capwap@frascone.com, Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 158: Allocation of WBIDs 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 > > Frankly, I don't care much whether we adopt this proposed change. The > IEEE 802.11 binding specification does not include the WBID value, > so a > change would be required for that specification. The bigger change, I > suspect, is on the EPCGlobal spec. Of particular note, the CAPWAP spec > currently requires a Standards Action to allocate one of these > numbers, > and since the RFID CAPWAP specification is being published by > EPCGlobal, > and not the IETF, I'm not sure how they could get a number assigned. > Margaret, you are closer to this than I am, so do you have any > recommendations? (Wearing my EPCglobal hat) The EPCglobal Discovery Configuration and Initialization (DCI) specification defines a CAPWAP binding for RFID readers. It is very nearly complete after ~1-1/2 years of work. EPCglobal requires interoperability testing before they will ratify a standard, and that testing was completed last week. Final ratification of the EPCglobal standard is now blocked on getting an RFC number for CAPWAP. EPCglobal doesn't have any plans to publish DCI as an IETF standards track document. The work in EPCglobal was done based on the CAPWAP WG's agreement to assign an binding ID for that purpose in the CAPWAP spec. While I agree that further binding IDs need to be defined in their bindings, I think it would be pretty late to change the agreement with EPCglobal now. > Finally, removing the IEEE 802.16 from the list is not a problem, > and I > agree that if there is ever a specification that defines the use of > CAPWAP for 802.16, then the number would be assigned at that time. That would be fine with me, as the 802.16 binding doesn't exist, AFAIK. 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 Tue Jul 29 06:24:58 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54DB43A6A34 for ; Tue, 29 Jul 2008 06:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9B6bZFMTPya for ; Tue, 29 Jul 2008 06:24:57 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 6C59E3A69F9 for ; Tue, 29 Jul 2008 06:24:57 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0591C433DD4 for ; Tue, 29 Jul 2008 06:25:10 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 293E244014B for ; Tue, 29 Jul 2008 02:59:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id CDDDC34AC078 for ; Tue, 29 Jul 2008 02:59:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 1475734AC062 for ; Tue, 29 Jul 2008 02:59:07 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.105.134 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 02:59:07 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6T9wI4V027803; Tue, 29 Jul 2008 04:59:00 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 12:58:39 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 12:58:36 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 12:58:39 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72013BA8AA@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 158: Allocation of WBIDs Thread-Index: AcjxWPPBckiC/dIYR2+hBkqFhpAT4wACFMvQ References: <4FF84B0BC277FF45AA27FE969DD956A2062CB02E@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 29 Jul 2008 09:58:36.0773 (UTC) FILETIME=[AB46E150:01C8F161] X-Nokia-AV: Clean X-Mailman-Approved-At: Tue, 29 Jul 2008 06:24:54 -0700 Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 158: Allocation of WBIDs 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 Ok -- but if the intent is to allow CAPWAP bindings (and possibly other types of CAPWAP specifications) to be developed outside IETF Standards Track, then the IANA instructions need to be something else than "Standards Action". Best regards, Pasi > -----Original Message----- > From: ext Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: 29 July, 2008 11:55 > To: Pat Calhoun > Cc: capwap@frascone.com; Eronen Pasi (Nokia-NRC/Helsinki) > Subject: Re: [Capwap] Issue 158: Allocation of WBIDs > > > > > Frankly, I don't care much whether we adopt this proposed > change. The > > IEEE 802.11 binding specification does not include the WBID value, > > so a > > change would be required for that specification. The bigger > change, I > > suspect, is on the EPCGlobal spec. Of particular note, the > CAPWAP spec > > currently requires a Standards Action to allocate one of these > > numbers, > > and since the RFID CAPWAP specification is being published by > > EPCGlobal, > > and not the IETF, I'm not sure how they could get a number assigned. > > Margaret, you are closer to this than I am, so do you have any > > recommendations? > > (Wearing my EPCglobal hat) > > The EPCglobal Discovery Configuration and Initialization (DCI) > specification defines a CAPWAP binding for RFID readers. It is very > nearly complete after ~1-1/2 years of work. EPCglobal requires > interoperability testing before they will ratify a standard, > and that > testing was completed last week. Final ratification of the > EPCglobal > standard is now blocked on getting an RFC number for CAPWAP. > EPCglobal doesn't have any plans to publish DCI as an IETF standards > track document. > > The work in EPCglobal was done based on the CAPWAP WG's agreement to > assign an binding ID for that purpose in the CAPWAP spec. While I > agree that further binding IDs need to be defined in their bindings, > I think it would be pretty late to change the agreement with > EPCglobal now. > > > Finally, removing the IEEE 802.16 from the list is not a problem, > > and I > > agree that if there is ever a specification that defines the use of > > CAPWAP for 802.16, then the number would be assigned at that time. > > That would be fine with me, as the 802.16 binding doesn't > exist, AFAIK. > > 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 Tue Jul 29 06:24:59 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004163A69F9 for ; Tue, 29 Jul 2008 06:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgoMn+qUlRxq for ; Tue, 29 Jul 2008 06:24:57 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 5353E3A67B7 for ; Tue, 29 Jul 2008 06:24:57 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DB11C433D50 for ; Tue, 29 Jul 2008 06:25:09 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 9D4C64400B4 for ; Tue, 29 Jul 2008 02:48:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6F58334AC041 for ; Tue, 29 Jul 2008 02:48:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4075934AC03C for ; Tue, 29 Jul 2008 02:48:26 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.233 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 02:48:26 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6T9m1Ru023326; Tue, 29 Jul 2008 12:48:23 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 12:48:17 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 12:48:06 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 12:48:06 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72013BA889@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last call comments for capwap-protocol-binding-ieee80211-07 Thread-Index: AcjxWvvYp8NTYNntQ6KnjwjYAMoZsw== From: To: X-OriginalArrivalTime: 29 Jul 2008 09:48:06.0868 (UTC) FILETIME=[33D30140:01C8F160] X-Nokia-AV: Clean X-Mailman-Approved-At: Tue, 29 Jul 2008 06:24:54 -0700 Cc: capwap@frascone.com Subject: [Capwap] Last call comments for capwap-protocol-binding-ieee80211-07 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 I read capwap-protocol-binding-ieee80211-07 on my way to Dublin; here are some comments/observations. Substantial topics first: I was under the impression that 802 (or at least 802.11) required (or assumed) strict in-order delivery -- but perhaps I remember this wrong? (Obvious, tunneling over arbitrary IP hops doesn't guarantee in-order delivery, and it seems the data channel doesn't have mechanisms to reorder or drop out-of-order packets.) 802.11 header has 4 different addresses, all of which can be different. When doing split MAC with 802.3 frames, the 802.3 frame contains only two of the addresses; the "Radio MAC Address" field in CAPWAP header contains the third -- but what about the fourth one? The document should have some more text about how the WTP processes IEEE 802.11 IEs it receives from the AC. Section 6.6 talks about copying them to Beacon/Probe Response messages, but it seems that in some cases, the WTP also does some local processing. (I was sort of expecting a list of all IEs, and description of expected WTP processing (possibly none) for them.) Section 6.15: Is this really the PTK (which also includes KCK and KEK, which aren't needed by the WTP since the AC is handling the EAPOL-Key messages -- so probably shouldn't be sent to PTK), or only the TK used for encrypting traffic? Is the binding specified here sufficient for 802.11r as well, or would something more be needed? (I don't know the answer -- but probably the document should tell what it is) Section 6.14 says that packets exceeding this priority are either dropped or "down-tagged" -- but it seems which of these is done depends on WTP (and the AC can't even know what the WTP does). Isn't this problematic for interoperability? Question: Section 4 says the "Destination WLANs" field is used only for multicast/broadcast; how is the destination WLAN determined for unicast? (Is this by mapping destination MAC address to earlier IEEE 802.11 Station messages -- which means a single MAC address can't be in more than one WLAN?) (Perhaps the document should have couple of sentences about this) Question: The WLAN ID is always shown as 8 bits, but it seems some other parts limit the spec to 16 WLANs per WTP Radio. Could a WTP supporting more than 16 WLANs use multiple Radio IDs, or is 16 a hard limit? (Perhaps the document should have couple of sentences about this -- at least saying that WLAN ID is between 0 and 15) Minor clarifications/editorial nits: Section 3: CAPWAP base protocol requires that all Request messages are odd numbers, and Responses even; these aren't. Section 3.1, "sent after the CAPWAP Configuration Update Request message (..) has been received by the WTP" probably means "sent after the CAPWAP Configuration Update Response message has been received by the AC"? Section 5.10: "Station QoS Profile" should be "IEEE 802.11 Station QoS Profile" Section 6.1 and 6.21: are some of these 802.11 information elements optional, or are all of them always included? Section 6.1 and 6.21: what do you put in "Key Status" if you're not using encryption at all? Section 6.21: to avoid repetition of text, I'd suggest simply pointing to existing text in Section 6.1 for field descriptions. Section 6.1 and 6.21: "32 byte Session Key" -- length depends on "Key Length" field, right? Section 6.2/10.6: is the "Combiner" a bit field or enumerated field? (And in the former case, an explicit bit diagram would be very useful to avoid confusion about bit numbering) Section 6.14, 6.20, and 6.22: the 802.1p Tag field should probably be shown as 3 bits in the diagram, to make it unambiguous about which bits are not used. Section 6.15: The sentence "Note that AKM-Only is MAY be set..." would benefit for some clarification -- does 802.11 really drop all unencrypted EAPOL-Key frames if you have an encryption key? (it seems that would cause difficulties when e.g. client reboots -- but I'm not sure what 802.11 does here) Section 6.15: "MUST NOT be sent if the WTP had not specifically advertised support for the requested encryption scheme": would be easier to understand if it said how the WTP advertises this (presumably, the Encryption Capabilities field in the WTP Descriptor Message Element?) Sections 6.20 and 6.22: the DSCP Tag field should probably be shown as 6 bits in the diagram, to make it unambiguous how it's sent in IPv4/IPv6 header (and which bits are unused). Section 6.16, "maximum value of 65535" -- the fields are 32 bits, so probably should be 4294967295? Section 6.20 and 6.22: "if packets are to be DSCP tagged" would benefit of clarifying what packets are meant (I guess it means CAPWAP Data packets sent from the WTP to the AC?). Section 6.22/10.9: is the "Tag Packets" a bit field or enumerated field? (In the former case, an explicit bit diagram would be very useful to avoid confusion about bit numbering.) Section 6.23: "Country Code" field probably should be called "Country String" (since it contains other things than the country code, and it's called "country string" in 802.11), and it should be 3 octets instead of 4. Section 6.23: The description of third octet of Country field doesn't quite match IEEE 802.11 (e.g. 'X' character is missing, and the '255' entry is confusing). Section 6.23: reference [ISO.3166.1984] should be to the latest edition, not 1984 version: [ISO.3166-1] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions - Part 1: Country codes", ISO Standard 3166-1:1997 Section 6.25: an explicit bit diagram would be useful for the "Radio Type" field, since it's not clear whether e.g. "2" really means bit number 2, or perhaps bit number 6 (rest of the text suggests it's the latter). Section 8.1: an explicit bit diagram would be useful (since bit numbering has been somewhat inconsistent in various parts of the spec). Section 8.1: WEP is missing from the list? Section 8.1: there probably should be IANA considerations text about how the remaining bits are allocated. Section 10.2, "defines 27 new Message Types" -> "defines 25 new Message Element Types"? Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 29 08:47:40 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 696B13A6A5A for ; Tue, 29 Jul 2008 08:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVPvh0u58g+7 for ; Tue, 29 Jul 2008 08:47:37 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id ACCC03A6BC2 for ; Tue, 29 Jul 2008 08:47:36 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 53C2A1C40FBA for ; Tue, 29 Jul 2008 08:47:34 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 547374400FC for ; Tue, 29 Jul 2008 08:47:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0BAE634AC025 for ; Tue, 29 Jul 2008 08:47:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 42AE834AC01F for ; Tue, 29 Jul 2008 08:47:22 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 08:47:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,273,1215388800"; d="scan'208";a="58980803" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 29 Jul 2008 15:45:29 +0000 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/8.12.11) with ESMTP id m6TFjSvH013136; Tue, 29 Jul 2008 08:45:28 -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.13.8/8.13.8) with ESMTP id m6TFjMBH024247; Tue, 29 Jul 2008 15:45:28 GMT 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.1830); Tue, 29 Jul 2008 08:45:23 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 08:45:22 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CB33A@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 161: NAT Inconsistencies Thread-Index: AcjxkhxK+PJwXexpQpS7KRytn/xWJA== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 29 Jul 2008 15:45:23.0439 (UTC) FILETIME=[1D0427F0:01C8F192] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 161: NAT Inconsistencies 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 Pasi's Comment was: There's some inconsistency about NAT detection: Sections 4.6.12, 4.6.13, and 4.6.15 say it's done using "CAPWAP Local IPv4/6 address" message elements; Sections 4.6.44, 4.6.45, and 6.1 say it's using "WTP IPv4/6 address" message elements. Pasi's comment is spot on. The document was unfortunately very inconsistent. There were two pairs of message elements that was doing basically the same thing, and to make things worse, there was no clear text that explained which pair to use. So I have removed the "WTP IPv4/v6 Address" message elements, since we need a way for both the WTP and the AC to communicate their address. Most of the text below contains changes only, except a new paragraph in the NAT Considerations section. 4.6.12. CAPWAP Local IPv4 Address The CAPWAP Local IPv4 Address message element is sent by either the WTP, in the Join Request, or by the AC, in the Join Response. The CAPWAP Local IPv4 Address message element is used to communicate the IP Address of the transmitter. The receiver uses this to determine whether a middlebox exists between the two peers, by comparing the source IP address of the packet against the value of the message element. [...] 4.6.13. CAPWAP Local IPv6 Address The CAPWAP Local IPv6 Address message element is sent by either the WTP, in the Join Request, or by the AC, in the Join Response. The CAPWAP Local IPv6 Address message element is used to communicate the IP Address of the transmitter. The receiver uses this to determine whether a middlebox exists between the two peers, by comparing the source IP address of the packet against the value of the message element. [...] 4.6.15. CAPWAP Transport Protocol When CAPWAP is run over IPv6, the UDP-Lite or UDP transports MAY be used (see Section 3). The CAPWAP IPv6 Transport Protocol message element is used by either the WTP or the AC to signal which transport protocol is to be used for the CAPWAP data channel. Upon receiving the Join Request, the AC MAY set the CAPWAP Transport Protocol to UDP-Lite in the Join Response message if the CAPWAP message was received over IPv6, and the CAPWAP Local IPv6 Address message element (see Section 4.6.13) is present and no middlebox was detected (see Section 11). Upon receiving the Join Response, the WTP MAY set the CAPWAP Transport Protocol to UDP-Lite in the Configuration Status Request or Image Data Request message if the AC advertised support for UDP-Lite, the message was received over IPv6, the CAPWAP Local IPv6 Address message element (see Section 4.6.13) and no middlebox was detected (see Section 11). Upon receiving either the Configuration Status Request or the Image Data Request, the AC MUST observe the preference indicated by the WTP in the CAPWAP Transport Protocol, as long as it is consistent with what the AC advertised in the Join Response. [...] 6.1. Join Request [...] At least one of the following message element MUST be included in the Join Request message. o CAPWAP Local IPv4 Address, see Section 4.6.12 o CAPWAP Local IPv6 Address, see Section 4.6.13 6.2. Join Response [...] One of the following message elements MUST be included in the Join Response Message: o CAPWAP Local IPv4 Address, see Section 4.6.12 o CAPWAP Local IPv6 Address, see Section 4.6.13 11. NAT Considerations [...] In order for a CAPWAP WTP or AC to detect whether a middlebox is present, both the Join Request (see Section 6.1) and the Join Response (see Section 6.2) include either the CAPWAP Local IPv4 Address (see Section 4.6.12), or the CAPWAP Local IPv6 Address (see Section 4.6.13) message element. Upon receiving one of these messages, if the packet's source IP address differs from the address found in either one of these message elements, it indicates that a middlebox is present. 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 Jul 29 08:49:10 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72F3F28C343 for ; Tue, 29 Jul 2008 08:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hX94OpUlXRO3 for ; Tue, 29 Jul 2008 08:49:09 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2B9E328C34C for ; Tue, 29 Jul 2008 08:49:09 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 91DD143A02A for ; Tue, 29 Jul 2008 08:49:19 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id BCCF04400FC for ; Tue, 29 Jul 2008 08:49:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6EFFE34AC0C2 for ; Tue, 29 Jul 2008 08:49:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0543F34AC099 for ; Tue, 29 Jul 2008 08:48:51 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 08:48:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,273,1215388800"; d="scan'208";a="133092530" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 29 Jul 2008 15:48:50 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m6TFmoOM019529; Tue, 29 Jul 2008 08:48:50 -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.13.8/8.13.8) with ESMTP id m6TFmolR023763; Tue, 29 Jul 2008 15:48:50 GMT 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.1830); Tue, 29 Jul 2008 08:48:50 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 08:48:49 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CB345@xmb-sjc-235.amer.cisco.com> In-Reply-To: <28807265.1217294249257.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 153: Linking of control and data channels Thread-Index: AcjxGSta2hlE4ugyTNWIjbb23F39VQAeV3fA References: <28807265.1217294249257.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> From: "Pat Calhoun (pacalhou)" To: "Scott G. Kelly" , "Charles Clancy" X-OriginalArrivalTime: 29 Jul 2008 15:48:50.0262 (UTC) FILETIME=[984AD760:01C8F192] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: capwap@frascone.com, Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 153: Linking of control and data channels 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 In which case I propose we close this issue and mark as rejected. Pasi? PatC -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Monday, July 28, 2008 6:17 PM To: Charles Clancy; Pat Calhoun (pacalhou) Cc: capwap@frascone.com; Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 153: Linking of control and data channels I agree with Charles. -----Original Message----- >From: Charles Clancy >Sent: Jul 28, 2008 5:54 PM >To: "Pat Calhoun (pacalhou)" >Cc: capwap@frascone.com, Pasi.Eronen@nokia.com >Subject: Re: [Capwap] Issue 153: Linking of control and data channels > >The goal of the text was to provide efficient interoperability, and >handle all the edge cases. Typically when you use session resumption, >you're resuming a session that's ended. Here we have two simultaneous >DTLS sessions running, with the second one being a resumption of the >first. We're using DTLS session resumption to quickly open a second >tunnel while the first is still running. Given this use, I believe all >the text in section 4.4.3 is necessary. > >The alternative would be to not say anything about it and leave it up >to the DTLS implementations. I think this would result in having to do >full authentications on the data channel more frequently than not. It >could also possibly allow you to establish a data channel without a >control channel. > >-- >t. charles clancy, ph.d. eng.umd.edu/~tcc >electrical & computer engineering, university of maryland > > >Pat Calhoun (pacalhou) wrote: >> Pasi's comment is: >> >> The linking of control and data channels, and how DTLS session >> resumption is >> used here, seems unnecessarily complicated. Normally session >> resumption is >> totally TLS internal optimization, and applications running over >> TLS don't >> know (and have no need to know) whether full or abbreviated TLS >> handshake was >> used. It seems this document wouldn't really need to say anything >> about >> session resumption; if the WTP provides the Session ID in data >> channel, and AC >> checks that both DTLS connections were established by the same >> authenticated >> client, that seems sufficient. This would seem to remove much >> implementation >> complexity; e.g. the requirement in 4.4.3 that "The AC DTLS >> implementation >> MUST NOT accept a session resumption request for a DTLS session in >> which the >> control channel for the session has been torn down" doesn't follow >> the usual >> TLS/DTLS module boundaries. >> >> Given the nature of the question, I would like to defer to Scott or >> Charles. I recall us going back and forth on this, and would like >> their guidance before we propose a change. >> >> PatC >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/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 Jul 29 08:52:45 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3933A6824 for ; Tue, 29 Jul 2008 08:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, FUZZY_CPILL=0.001, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWyEu3E5AmrG for ; Tue, 29 Jul 2008 08:52:44 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 7AB5828C351 for ; Tue, 29 Jul 2008 08:52:44 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 55150439FE3 for ; Tue, 29 Jul 2008 08:52:57 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id D603D4400FC for ; Tue, 29 Jul 2008 08:52:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2A66434AC001 for ; Tue, 29 Jul 2008 08:52:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 1E55434AC00F for ; Tue, 29 Jul 2008 08:52:34 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 08:52:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,273,1215388800"; d="scan'208";a="70119587" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2008 15:52:31 +0000 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/8.12.11) with ESMTP id m6TFqTks020083; Tue, 29 Jul 2008 08:52:29 -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.13.8/8.13.8) with ESMTP id m6TFqJPk017826; Tue, 29 Jul 2008 15:52:29 GMT 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.1830); Tue, 29 Jul 2008 08:52:28 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 08:52:27 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CB34E@xmb-sjc-235.amer.cisco.com> In-Reply-To: <488E6DB2.1080101@umd.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 160: Use of Replay Protection Thread-Index: AcjxF7sLbMHsyO8gQaKn/ymgeejN8QAe1WQw References: <4FF84B0BC277FF45AA27FE969DD956A2062CAFDA@xmb-sjc-235.amer.cisco.com> <488E6DB2.1080101@umd.edu> From: "Pat Calhoun (pacalhou)" To: "Charles Clancy" X-OriginalArrivalTime: 29 Jul 2008 15:52:28.0569 (UTC) FILETIME=[1A69D890:01C8F193] Authentication-Results: sj-dkim-4; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: capwap@frascone.com, Pasi.Eronen@nokia.com, clancy@ltsnet.net Subject: Re: [Capwap] Issue 160: Use of Replay Protection 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 Charles, could you propose the best way to include this in the draft? PatC -----Original Message----- From: Charles Clancy [mailto:tcc@umd.edu] Sent: Monday, July 28, 2008 6:09 PM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com; Pasi.Eronen@nokia.com; clancy@ltsnet.net Subject: Re: [Capwap] Issue 160: Use of Replay Protection Saying that DTLS replay detection MUST be used is okay with me. Section 4.5.3 has text that assumes DTLS replay detection is being used. -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland Pat Calhoun (pacalhou) wrote: > Here is Pasi's comment: > > Replay protection is an optional feature in RFC 4347. Should this > document say > something about it? (e.g. MUST use?) > > Given the nature of the question, I would like to defer to Scott or > Charles. I recall us going back and forth on this, and would like > their guidance before we propose a change. > > PatC > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 29 08:53:33 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB0CE28C351 for ; Tue, 29 Jul 2008 08:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfLiybUS4Q2S for ; Tue, 29 Jul 2008 08:53:32 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id DE9F43A6B7F for ; Tue, 29 Jul 2008 08:53:32 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C36F243A263 for ; Tue, 29 Jul 2008 08:53:45 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id C7EDD4400FC for ; Tue, 29 Jul 2008 08:53:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 9010234AC00F for ; Tue, 29 Jul 2008 08:53:34 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 426E634AC087 for ; Tue, 29 Jul 2008 08:53:32 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 08:53:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,273,1215388800"; d="scan'208";a="133095151" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 29 Jul 2008 15:53:30 +0000 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/8.12.11) with ESMTP id m6TFrURg030750; Tue, 29 Jul 2008 08:53:30 -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.13.8/8.13.8) with ESMTP id m6TFrUxD015258; Tue, 29 Jul 2008 15:53:30 GMT 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.1830); Tue, 29 Jul 2008 08:53:30 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 08:53:29 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CB352@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 152: Need crypto protocol agility Thread-Index: AcjxV1TuKDcm1R7uTwmRveK0CNpjpQAO+SoA References: <4FF84B0BC277FF45AA27FE969DD956A2062CAF53@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Margaret Wasserman" X-OriginalArrivalTime: 29 Jul 2008 15:53:30.0692 (UTC) FILETIME=[3F711040:01C8F193] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: capwap@frascone.com, Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 152: Need crypto protocol agility 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 Pasi, are you OK with this? PatC -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com] Sent: Tuesday, July 29, 2008 1:44 AM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com; Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 152: Need crypto protocol agility I agree with Pat's reasoning about this being a non-security- sensitive checksum and would prefer not to change this section to add hash agility. Margaret On Jul 28, 2008, at 7:48 PM, Pat Calhoun (pacalhou) wrote: > All, > > Pasi's comment is: > > Section 4.6.29: Using MD5 in a new protocol, and not providing > algorithm > agility for moving to new algorithms, is probably not such a great > idea > > Specifically, the text currently looks like: > > > 4.6.29. Image Information > > The Image Information message element is present in the Image Data > Response message sent by the AC to the WTP and 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | File Size | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hash | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hash | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hash | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hash | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: 29 for Image Information > > Length: 20 > > File Size: A 32-bit value containing the size of the file, in > bytes, that will be transferred by the AC to the WTP. > > Hash: A 16 octet hash of the image. The hash is computed using > MD5, using the following pseudo-code: > > #include > CapwapCreateHash(char *hash, char *image, int image_len) > { > MD_CTX context; > > MDInit (&context); > MDUpdate (&context, buffer, len); > MDFinal (hash, &context); > } > > > Certainly, it is possible to create a new field immediately following > the File Size field, called Algorithm Identifier. This field would > dictate the alg used in the generation of the Hash. This change is > fairly simple and straightforward. > > ... But. There are two things that I'd like to raise here. > > 1. The hash is not created for security purposes, but rather for > validation purposes. So I question whether we really need to worry > about > MD5 not being OK when creating a hash that is used to validate the > contents. Even if MD5 was/is compromised, the purpose of this hash > does not compromise anything. In fact, notice there is no "secret" > used here either. So nothing is at risk. > > 2. This change would break backward CAPWAP interoperability. > > Because of issue number two (2), I'd like to get the WG's opinion on > whether this change would be addressed, or rejected. > > Pasi, any comments on this? > > PatC > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 29 08:56:29 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 193AE3A6BCD for ; Tue, 29 Jul 2008 08:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5njxqbfZ7fh for ; Tue, 29 Jul 2008 08:56:28 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 62CBB3A6BCB for ; Tue, 29 Jul 2008 08:56:27 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3D2861C40F61 for ; Tue, 29 Jul 2008 08:56:40 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id BD7E4440160 for ; Tue, 29 Jul 2008 08:56:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2CBCC34AC022 for ; Tue, 29 Jul 2008 08:56:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E04EC34AC096 for ; Tue, 29 Jul 2008 08:56:25 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 08:56:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,273,1215388800"; d="scan'208";a="70121362" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2008 15:56:24 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6TFuNK0018555; Tue, 29 Jul 2008 08:56:23 -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.13.8/8.13.8) with ESMTP id m6TFuNIg003803; Tue, 29 Jul 2008 15:56:24 GMT 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, 29 Jul 2008 08:56:23 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 08:56:22 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CB358@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 155: WTP/AC ACL Synchronization Issue Thread-Index: Acjxk6WgO871AfXUQeimFFKPXffqpg== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 29 Jul 2008 15:56:23.0845 (UTC) FILETIME=[A6A61D50:01C8F193] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 155: WTP/AC ACL Synchronization Issue 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 Pasi's comment was: The protocol allows the AC to add and delete static MAC ACL entries, but it seems the AC can't check what the current ACL entries are. This means the WTP and AC could get out-of-sync, right? (The AC can't delete the unneeded static MAC ACL entries if it doesn't know what they are.) Well.... When a WTP comes up, it provides its configuration to the AC, and at that point it would include its ACL table. Sure, I guess an AC could have a bug and "forget" what the WTP provided - but I'm not sure we should be addressing poor programming practices through standards. I would recommend we reject this comment. 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 Jul 29 08:58:03 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 020AC3A6BCE for ; Tue, 29 Jul 2008 08:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+zYi-MlfRnx for ; Tue, 29 Jul 2008 08:58:02 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 262E73A6BCC for ; Tue, 29 Jul 2008 08:58:02 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0D8391C40F61 for ; Tue, 29 Jul 2008 08:58:15 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 339A8440160 for ; Tue, 29 Jul 2008 08:56:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id DC2BF34AC025 for ; Tue, 29 Jul 2008 08:56:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4877834AC030 for ; Tue, 29 Jul 2008 08:55:57 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.230 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 08:55:57 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6TFtm2E001928; Tue, 29 Jul 2008 18:55:54 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 18:55:47 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 18:55:33 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 18:55:31 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72013BABA4@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last call comments for capwap-threat-analysis-01 Thread-Index: Acjxk4c83XdA/mSDSZCnMSU3mzDwrw== From: To: X-OriginalArrivalTime: 29 Jul 2008 15:55:33.0495 (UTC) FILETIME=[88A35070:01C8F193] X-Nokia-AV: Clean X-Mailman-Approved-At: Tue, 29 Jul 2008 08:58:04 -0700 Cc: capwap@frascone.com Subject: [Capwap] Last call comments for capwap-threat-analysis-01 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 Couple of comments/observations about capwap-threat-analysis-01: There seem to be couple of places where this document isn't completely in sync with the protocol/binding documents. In particular, the following two places: Section 4.2, "The current CAPWAP binding for IEEE 802.11 only supports the use of IEEE 802.11i [80211I] security on the wireless link." The current version of the binding spec seems to support WEP, too. Section 6.1: The text about "Local MAC", "Remote MAC", and "Split MAC" doesn't seem to match the other documents. E.g., there's no "Remote MAC" in the other documents, and description of "Local MAC" doesn't quite match the description in IEEE 802.11 binding. The document would benefit from some discussion about authorization. Especially if WTPs/ACs have manufacturer-issued certificates installed in factory, everyone can easily authenticate everyone else. And with DHCP AC option, this could "zero configuration" for WTPs -- except that this wouldn't be secure: WTP (and AC) needs some configuration to know who is the *right* AC (who are the *right* WTPs). Editorial nits: Section 9.2: the section title includes "Rootkit installation": is this in right place, or should it be in Section 9.3? Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 29 08:58:51 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E193E28C2DE for ; Tue, 29 Jul 2008 08:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yT-udE2IhuvZ for ; Tue, 29 Jul 2008 08:58:51 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2125628C351 for ; Tue, 29 Jul 2008 08:58:51 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 072AA1C40FB3 for ; Tue, 29 Jul 2008 08:59:04 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id C291344015D for ; Tue, 29 Jul 2008 08:58:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 7629634AC025 for ; Tue, 29 Jul 2008 08:58:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D002534AC005 for ; Tue, 29 Jul 2008 08:58:48 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 08:58:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,273,1215388800"; d="scan'208";a="58987993" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 29 Jul 2008 15:58:46 +0000 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/8.12.11) with ESMTP id m6TFwkJI008670; Tue, 29 Jul 2008 08:58:46 -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.13.8/8.13.8) with ESMTP id m6TFwkRc020518; Tue, 29 Jul 2008 15:58:46 GMT 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, 29 Jul 2008 08:58:45 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 08:58:43 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CB35B@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 159: Question on CAPWAP control protocol Thread-Index: Acjxk/nQUciR3NiTR4OGNCDw9vljdw== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 29 Jul 2008 15:58:45.0466 (UTC) FILETIME=[FB0FC3A0:01C8F193] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 159: Question on CAPWAP control protocol 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 Pasi's question was: Section 4.5.3: Is CAPWAP control protocol strictly "lock-step" (once you send a Request, you must wait for Response until you send another Request), or are multiple outstanding requests allowed? Can you "give up" a Request (stop retransmitting it even though you haven't received a Response), and move to the next Request? What should you do if you receive a Request with a Sequence Number that's too old (less than previous Request you've seend) or too new (greater than previous Request+1)? No, the protocol only allows a single request at any given time. This has fundamentally been how the original LWAPP protocol was also built. We've discussed this many times, both through the protocol evaluation phase, as well as the CAPWAP protocol development phase, and never saw a need to change it. Shipping products have also showed that for this particular application, it is sufficient. I propose rejecting this comment. 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 Jul 29 09:38:18 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7713A68E5 for ; Tue, 29 Jul 2008 09:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k61MOfzk-vK for ; Tue, 29 Jul 2008 09:38:17 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 406053A6891 for ; Tue, 29 Jul 2008 09:38:17 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2B47A1C40FC6 for ; Tue, 29 Jul 2008 09:38:30 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 08DC0440157 for ; Tue, 29 Jul 2008 09:38:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id A206134AC0AC for ; Tue, 29 Jul 2008 09:38:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6A19C34AC11A for ; Tue, 29 Jul 2008 09:37:07 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from exchange.tm.thingmagic.com (exchange.tm.thingmagic.com [204.9.221.21]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 09:37:07 -0700 (PDT) Received: from nwilliams-pc1 (10.0.0.175) by exchange.tm.thingmagic.com (10.0.0.9) with Microsoft SMTP Server id 8.1.291.1; Tue, 29 Jul 2008 12:37:06 -0400 From: "Nathan J. Williams" To: "Pat Calhoun (pacalhou)" References: <4FF84B0BC277FF45AA27FE969DD956A2062CB358@xmb-sjc-235.amer.cisco.com> Date: Tue, 29 Jul 2008 12:37:10 -0400 In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2062CB358@xmb-sjc-235.amer.cisco.com> (Pat Calhoun's message of "Tue, 29 Jul 2008 11:56:22 -0400") Message-ID: MIME-Version: 1.0 Cc: "capwap@frascone.com" , "Pasi.Eronen@nokia.com" Subject: Re: [Capwap] Issue 155: WTP/AC ACL Synchronization Issue 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 "Pat Calhoun (pacalhou)" writes: > The protocol allows the AC to add and delete static MAC ACL entries, > but it > seems the AC can't check what the current ACL entries are. > This means the WTP and AC could get out-of-sync, right? (The AC can't > delete > the unneeded static MAC ACL entries if it doesn't know what they > are.) > > Well.... When a WTP comes up, it provides its configuration to the AC, > and at that point it would include its ACL table. Does it? I don't think the protocol has a message for communicating that state, and there certainly isn't one required or permitted in the Configuration Status message. Rereading around this, I'm reminded that the MAC ACL definition, at least as far as it can be understood from the add/remove message elements, is a little weird. It's a blacklist, and describing that as an ACL seems odd. As a blacklist, I would expect it to be empty by default, but that doesn't help the fact that the AC doesn't know the existing set of static entries. - Nathan _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 29 09:39:44 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A26E3A68C8 for ; Tue, 29 Jul 2008 09:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.769 X-Spam-Level: X-Spam-Status: No, score=-3.769 tagged_above=-999 required=5 tests=[AWL=-1.170, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKm6Ctbe7jqd for ; Tue, 29 Jul 2008 09:39:43 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 8BBA83A68B4 for ; Tue, 29 Jul 2008 09:39:43 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4D0BD43A521 for ; Tue, 29 Jul 2008 09:39:56 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id E68E4440160 for ; Tue, 29 Jul 2008 09:04:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 9276734AC02A for ; Tue, 29 Jul 2008 09:04:45 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0210D34AC09F for ; Tue, 29 Jul 2008 09:04:21 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.105.134 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 09:04:20 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6TG47ie007335; Tue, 29 Jul 2008 11:04:15 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 19:04:06 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 19:03:53 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 19:03:51 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72013BABA9@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2062CB358@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 155: WTP/AC ACL Synchronization Issue Thread-Index: Acjxk6WgO871AfXUQeimFFKPXffqpgAAHk2Q References: <4FF84B0BC277FF45AA27FE969DD956A2062CB358@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 29 Jul 2008 16:03:53.0273 (UTC) FILETIME=[B2876290:01C8F194] X-Nokia-AV: Clean X-Mailman-Approved-At: Tue, 29 Jul 2008 09:39:37 -0700 Subject: Re: [Capwap] Issue 155: WTP/AC ACL Synchronization Issue 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 Pat Calhoun wrote: > Well.... When a WTP comes up, it provides its configuration to the AC, > and at that point it would include its ACL table. Sure, I guess an AC > could have a bug and "forget" what the WTP provided - but I'm not sure > we should be addressing poor programming practices through standards. > > I would recommend we reject this comment. If the Configuration Status Request message included the static ACL table, that would work -- but I can't find anything in the current spec about sending the ACL table in this message. Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 29 09:39:44 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60B233A68B4 for ; Tue, 29 Jul 2008 09:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.363 X-Spam-Level: X-Spam-Status: No, score=-3.363 tagged_above=-999 required=5 tests=[AWL=-1.364, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kq-eXstfby6i for ; Tue, 29 Jul 2008 09:39:43 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 6B6123A681E for ; Tue, 29 Jul 2008 09:39:43 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3D29343A21C for ; Tue, 29 Jul 2008 09:39:56 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 8CC34440157 for ; Tue, 29 Jul 2008 09:37:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 419C134AC0F3 for ; Tue, 29 Jul 2008 09:37:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C13CF34AC06A for ; Tue, 29 Jul 2008 09:35:47 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.105.134 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 09:35:47 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6TGY0HN000443; Tue, 29 Jul 2008 11:35:39 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 19:35:30 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 19:35:30 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 19:35:30 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72013BABB4@vaebe104.NOE.Nokia.com> In-Reply-To: <488E6A5C.2060408@umd.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 153: Linking of control and data channels Thread-Index: AcjxFcGY2corpzEaRTaGdQSci7C7xQAfxz7Q References: <4FF84B0BC277FF45AA27FE969DD956A2062CAF60@xmb-sjc-235.amer.cisco.com> <488E6A5C.2060408@umd.edu> From: To: , X-OriginalArrivalTime: 29 Jul 2008 16:35:30.0599 (UTC) FILETIME=[1D6C5B70:01C8F199] X-Nokia-AV: Clean X-Mailman-Approved-At: Tue, 29 Jul 2008 09:39:37 -0700 Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 153: Linking of control and data channels 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 The need for efficiency is understandable, and I wouldn't have any concerns if the spec simply said "MUST support TLS Session Resumption". However, the requirement that the CAPWAP Data Channel establishment MUST NOT use full handshake (and possibly, Control Channel establishment MUST NOT use session resumption -- although this part is less clear), and the requirement "MUST NOT accept a session resumption request for a DTLS session in which the control channel for the session has been torn down" are more complex from TLS/DTLS perspective than they seem. These requirements don't lead to any performance improvements -- a sane implementation would anyway perform DTLS session resumption whenever possible. If the requirements here are kept as-is, you probably need to specify some additional details (and this would be the first RFC ever that touched these parts of TLS -- so given that there's no performance gain, are you really sure you need to do this?) - clearly say that DTLS MUST NOT accept (or initiate) full handshake on port 5247, and (presumably) MUST NOT accept (or initiate) session resumption on port 5246. - specify how the DTLS/TLS implementation maintains its session cache (current TLS RFCs allow deleting session cache entries at any time, which wouldn't always work). Assuming that the data channel is established only once, immediately following control channel establishment, you need to keep the session cache entry around until the data channel is established. And you need to delete the session cache entry when the control channel is closed. - probably prohibit use of TLS renegotiation, or else explain how it would work Best regards, Pasi > -----Original Message----- > From: ext Charles Clancy [mailto:tcc@umd.edu] > Sent: 29 July, 2008 03:55 > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com; Eronen Pasi (Nokia-NRC/Helsinki) > Subject: Re: [Capwap] Issue 153: Linking of control and data channels > > The goal of the text was to provide efficient interoperability, and > handle all the edge cases. Typically when you use session > resumption, you're resuming a session that's ended. Here we have > two simultaneous DTLS sessions running, with the second one being a > resumption of the first. We're using DTLS session resumption to > quickly open a second tunnel while the first is still running. > Given this use, I believe all the text in section 4.4.3 is > necessary. > > The alternative would be to not say anything about it and leave it > up to the DTLS implementations. I think this would result in having > to do full authentications on the data channel more frequently than > not. It could also possibly allow you to establish a data channel > without a control channel. > > -- > t. charles clancy, ph.d. eng.umd.edu/~tcc > electrical & computer engineering, university of maryland > > > Pat Calhoun (pacalhou) wrote: > > Pasi's comment is: > > > > The linking of control and data channels, and how DTLS session > > resumption is > > used here, seems unnecessarily complicated. Normally session > > resumption is > > totally TLS internal optimization, and applications > running over TLS > > don't > > know (and have no need to know) whether full or abbreviated TLS > > handshake was > > used. It seems this document wouldn't really need to say anything > > about > > session resumption; if the WTP provides the Session ID in data > > channel, and AC > > checks that both DTLS connections were established by the same > > authenticated > > client, that seems sufficient. This would seem to remove much > > implementation > > complexity; e.g. the requirement in 4.4.3 that "The AC DTLS > > implementation > > MUST NOT accept a session resumption request for a DTLS > session in > > which the > > control channel for the session has been torn down" > doesn't follow > > the usual > > TLS/DTLS module boundaries. > > > > Given the nature of the question, I would like to defer to Scott or > > Charles. I recall us going back and forth on this, and > would like their > > guidance before we propose a change. > > > > PatC > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 29 09:53:24 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9B803A69B8 for ; Tue, 29 Jul 2008 09:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBxM+TdKP+s8 for ; Tue, 29 Jul 2008 09:53:23 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id CE17D3A6942 for ; Tue, 29 Jul 2008 09:53:23 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F31AB1C40F82 for ; Tue, 29 Jul 2008 09:53:33 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 96C6744015A for ; Tue, 29 Jul 2008 09:53:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id BB3D534AC078 for ; Tue, 29 Jul 2008 09:53:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3ACFB34AC013 for ; Tue, 29 Jul 2008 09:53:18 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.230 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 09:53:17 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6TGqfQF023875; Tue, 29 Jul 2008 19:52:48 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 19:52:38 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 19:52:37 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 19:52:35 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72013BABC0@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2062CB35B@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 159: Question on CAPWAP control protocol Thread-Index: Acjxk/nQUciR3NiTR4OGNCDw9vljdwABp7cg References: <4FF84B0BC277FF45AA27FE969DD956A2062CB35B@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 29 Jul 2008 16:52:37.0760 (UTC) FILETIME=[81A8B000:01C8F19B] X-Nokia-AV: Clean Subject: Re: [Capwap] Issue 159: Question on CAPWAP control protocol 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 This was really a question asking for clarification, not a request to allow multiple parallel requests. E.g., there doesn't seem to be text prohibiting multiple pending requests. Quite the opposite, in fact -- Section 4.5.1.2 says "counter is monotonically incremented, ensuring that no two pending Request messages have the same Sequence Number". The document also doesn't say anything about rejecting old requests (with sequence number smaller than expected), or how to process "too new" requests. Best regards, Pasi > -----Original Message----- > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: 29 July, 2008 18:59 > To: capwap@frascone.com > Cc: Eronen Pasi (Nokia-NRC/Helsinki) > Subject: Issue 159: Question on CAPWAP control protocol > > Pasi's question was: > > Section 4.5.3: Is CAPWAP control protocol strictly > "lock-step" (once > you send > a Request, you must wait for Response until you send another > Request), or are > multiple outstanding requests allowed? Can you "give up" a Request > (stop > retransmitting it even though you haven't received a Response), and > move to > the next Request? What should you do if you receive a > Request with a > Sequence > Number that's too old (less than previous Request you've seend) or > too new > (greater than previous Request+1)? > > No, the protocol only allows a single request at any given time. This > has fundamentally been how the original LWAPP protocol was also built. > We've discussed this many times, both through the protocol evaluation > phase, as well as the CAPWAP protocol development phase, and > never saw a > need to change it. Shipping products have also showed that for this > particular application, it is sufficient. > > I propose rejecting this comment. > > 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 Jul 29 10:12:35 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDBED3A635F for ; Tue, 29 Jul 2008 10:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FUZZY_CPILL=0.001, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N74r+ZCpDUXB for ; Tue, 29 Jul 2008 10:12:34 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id CB2DA3A68FF for ; Tue, 29 Jul 2008 10:12:34 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CC0E21C40FB7 for ; Tue, 29 Jul 2008 10:12:47 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 2E23C440152 for ; Tue, 29 Jul 2008 10:12:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E36F934AC125 for ; Tue, 29 Jul 2008 10:12:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 99D8634AC0FC for ; Tue, 29 Jul 2008 10:11:21 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from bacon.cs.umd.edu (server-nat-4.cs.umd.edu [128.8.127.147]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 10:11:21 -0700 (PDT) Received: from [130.129.18.59] ([130.129.18.59]) (authenticated bits=0) by bacon.cs.umd.edu (8.13.1/8.14.1) with ESMTP id m6THBC2x012919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 13:11:13 -0400 Message-ID: <488F4F2F.2050909@cs.umd.edu> Date: Tue, 29 Jul 2008 13:11:11 -0400 From: Charles Clancy User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <4FF84B0BC277FF45AA27FE969DD956A2062CAFDA@xmb-sjc-235.amer.cisco.com> <488E6DB2.1080101@umd.edu> <4FF84B0BC277FF45AA27FE969DD956A2062CB34E@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2062CB34E@xmb-sjc-235.amer.cisco.com> X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-48.999, required 5, ALL_TRUSTED -50.00, FUZZY_CPILL 0.00, UNSUB_DRH 1.00) X-CSD-MailScanner-From: clancy@cs.umd.edu Cc: capwap@frascone.com, Pasi.Eronen@nokia.com, Charles Clancy , clancy@ltsnet.net Subject: Re: [Capwap] Issue 160: Use of Replay Protection 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 Pat, A new paragraph to the end of section 2.4.1: The DTLS implementation used by CAPWAP MUST use replay detection, per Section 3.3 of . Since the CAPWAP protocol handles retransmissions by re-encrypting lost frames, any duplicate DTLS frames are either unintentional or malicious, and should be silently discarded. -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland Pat Calhoun (pacalhou) wrote: > Charles, could you propose the best way to include this in the draft? > > PatC > > -----Original Message----- > From: Charles Clancy [mailto:tcc@umd.edu] > Sent: Monday, July 28, 2008 6:09 PM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com; Pasi.Eronen@nokia.com; clancy@ltsnet.net > Subject: Re: [Capwap] Issue 160: Use of Replay Protection > > Saying that DTLS replay detection MUST be used is okay with me. Section > 4.5.3 has text that assumes DTLS replay detection is being used. > > -- > t. charles clancy, ph.d. eng.umd.edu/~tcc > electrical & computer engineering, university of maryland > > > Pat Calhoun (pacalhou) wrote: >> Here is Pasi's comment: >> >> Replay protection is an optional feature in RFC 4347. Should this >> document say >> something about it? (e.g. MUST use?) >> >> Given the nature of the question, I would like to defer to Scott or >> Charles. I recall us going back and forth on this, and would like >> their guidance before we propose a change. >> >> PatC >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 29 10:34:33 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2C4A3A69F5 for ; Tue, 29 Jul 2008 10:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RElpSIzc8rz for ; Tue, 29 Jul 2008 10:34:32 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id CFCE13A69EB for ; Tue, 29 Jul 2008 10:34:32 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DE6881C40F60 for ; Tue, 29 Jul 2008 10:34:45 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 91C19440164 for ; Tue, 29 Jul 2008 10:34:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3C9AB3610008 for ; Tue, 29 Jul 2008 10:34:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id ACF9D3610006 for ; Tue, 29 Jul 2008 10:34:25 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from bacon.cs.umd.edu (server-nat-4.cs.umd.edu [128.8.127.147]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 10:34:25 -0700 (PDT) Received: from [130.129.18.59] ([130.129.18.59]) (authenticated bits=0) by bacon.cs.umd.edu (8.13.1/8.14.1) with ESMTP id m6THYHFh015116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 13:34:18 -0400 Message-ID: <488F5498.4000700@cs.umd.edu> Date: Tue, 29 Jul 2008 13:34:16 -0400 From: Charles Clancy User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" , tim.polk@nist.gov References: <4FF84B0BC277FF45AA27FE969DD956A2062CAF53@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2062CB352@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2062CB352@xmb-sjc-235.amer.cisco.com> X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-49, required 5, ALL_TRUSTED -50.00, UNSUB_DRH 1.00) X-CSD-MailScanner-From: clancy@cs.umd.edu Cc: Margaret Wasserman , capwap@frascone.com, Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 152: Need crypto protocol agility 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 Pat, Per Pasi's comments in the meeting, the concern is FIPS 140-2 compliance. MD5 may be forbidden regardless of its use. Looking at FIPS 140-2 Annex A, it specifically talks about "Secure Hashes". I think there are two options -- (1) make it clear that we're not using MD5 as a "Secure Hash" in the document, or (2) switch to using CRC which is obviously NOT a secure hash. Tim -- See discussion below. Would using MD5 for a non-cryptographic firmware checksum make FIPS 140-2 compliance difficult? -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland Pat Calhoun (pacalhou) wrote: > Pasi, are you OK with this? > > PatC > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Tuesday, July 29, 2008 1:44 AM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com; Pasi.Eronen@nokia.com > Subject: Re: [Capwap] Issue 152: Need crypto protocol agility > > I agree with Pat's reasoning about this being a non-security- sensitive > checksum and would prefer not to change this section to add hash > agility. > > Margaret > > > On Jul 28, 2008, at 7:48 PM, Pat Calhoun (pacalhou) wrote: > >> All, >> >> Pasi's comment is: >> >> Section 4.6.29: Using MD5 in a new protocol, and not providing >> algorithm >> agility for moving to new algorithms, is probably not such a great >> idea >> >> Specifically, the text currently looks like: >> >> >> 4.6.29. Image Information >> >> The Image Information message element is present in the Image Data >> Response message sent by the AC to the WTP and 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | File Size | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Hash | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Hash | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Hash | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Hash | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Type: 29 for Image Information >> >> Length: 20 >> >> File Size: A 32-bit value containing the size of the file, in >> bytes, that will be transferred by the AC to the WTP. >> >> Hash: A 16 octet hash of the image. The hash is computed using >> MD5, using the following pseudo-code: >> >> #include >> CapwapCreateHash(char *hash, char *image, int image_len) >> { >> MD_CTX context; >> >> MDInit (&context); >> MDUpdate (&context, buffer, len); >> MDFinal (hash, &context); >> } >> >> >> Certainly, it is possible to create a new field immediately following >> the File Size field, called Algorithm Identifier. This field would >> dictate the alg used in the generation of the Hash. This change is >> fairly simple and straightforward. >> >> ... But. There are two things that I'd like to raise here. >> >> 1. The hash is not created for security purposes, but rather for >> validation purposes. So I question whether we really need to worry >> about >> MD5 not being OK when creating a hash that is used to validate the >> contents. Even if MD5 was/is compromised, the purpose of this hash >> does not compromise anything. In fact, notice there is no "secret" >> used here either. So nothing is at risk. >> >> 2. This change would break backward CAPWAP interoperability. >> >> Because of issue number two (2), I'd like to get the WG's opinion on >> whether this change would be addressed, or rejected. >> >> Pasi, any comments on this? >> >> PatC >> >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/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 Jul 29 10:58:12 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFE963A6910 for ; Tue, 29 Jul 2008 10:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5sLWDfks4M7 for ; Tue, 29 Jul 2008 10:58:11 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 4A4DC3A6AD4 for ; Tue, 29 Jul 2008 10:58:11 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5F6211C40FDF for ; Tue, 29 Jul 2008 10:58:24 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id CAE8B440165 for ; Tue, 29 Jul 2008 10:58:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id A5351361000E for ; Tue, 29 Jul 2008 10:58:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 12883361002B for ; Tue, 29 Jul 2008 10:58:04 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.68.10.86 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 10:58:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,273,1215388800"; d="scan'208";a="18954044" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 29 Jul 2008 17:57:55 +0000 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/8.12.11) with ESMTP id m6THvttW026849; Tue, 29 Jul 2008 10:57:55 -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.13.8/8.13.8) with ESMTP id m6THvtTf023442; Tue, 29 Jul 2008 17:57:55 GMT 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, 29 Jul 2008 10:57:54 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 10:57:53 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CB476@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 162: Nits from Pasi's Review Thread-Index: AcjxpJ8DYnfaA0X6TJ+e+FjtUH/6og== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 29 Jul 2008 17:57:54.0888 (UTC) FILETIME=[A072FC80:01C8F1A4] Authentication-Results: sj-dkim-4; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 162: Nits from Pasi's Review 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 > Section 2, 1st para: should reference RFC4347 instead of RFC4346 Correct - made the change. > > Section 2.3: should have a sentence saying what transitions represented by punctuation characters mean. Correct - the sentence SHOULD have read: The state machine transitions in Figure 4 are represented by alphabetic and punctuation characters. > > Section 2.4.1: "DTLS will never terminate the handshake due to non-responsiveness; instead, DTLS will continue to > increase its back-off timer period" While RFC 4347 doesn't specify how long you should continue retransmitting, the > intent certainly was not to continue indefinitely. > > Section 2.4.3 text about DTLS retransmissions is slightly inaccurate; DTLS handshake isn't strictly request/response, > and both parties (not just the DTLS client) retransmit based on timers (in some situations). Created issue 168 to track this. > > Section 2.4.4.1: should reference RFC4346 instead of RFC4279. Got it. > Section 2.4.4.2: TLS_DHE_PSK_WITH_AES_256_CBC_SHA is listed twice. Yup - cut/paste error. Got it. > > Section 4.4.1, "The 8 bit Length field" looks like 16 bits. Correct - the picture was right. Changed the text. > > Section 4.4.2: is it unambiguous which 802.3 frame fields are included or omitted? (e.g. preamble, SOF delimeter, etc.) > > Section 4.6, message element 29 is spelled "Image Information" > in the rest of the document, but "Image Info" here Yup - thanks. > > Section 4.6.1, description of R-MAC Field needs some more text (current text would probably be fine if the field was > only 1 bit, but it's 8 bits). I will create a separate issue for this, because it will require a little more work than just a nit. Issue 163 now exists to track this and I will take this up in a separate thread. > > Section 4.6.6 (AC Timestamp): the timestamp format in RFC 1305 is > 64 bits, but the field here is only 32 bits. Oh, right. The intent was to only include the most significant 32 bits of the timestamp. We are not too worried about the kind of granularity that the lower 32 bits would provide. So in order to address this, I would propose a small change to the text: Timestamp: The AC's current time, allowing all of the WTPs to be time synchronized in the format defined by Network Time Protocol (NTP) in RFC 1305 [RFC1305]. Only the most significant 32 bits of the NTP time is included in this field. > > The description of bit fields needs clarification in several places: > at least Section 4.6.1 (Security field), 4.6.1 (DTLS Policy field), > 4.6.43 (Frame Tunnel Mode field). For example, the "Security" field currently seems to say that bit 1 is X.509, bit 2 > is PSK, and bits 0 and 3..7 are unused -- but the intention was probably to say that bit 0 is X.509 and so on. This > gets especially confusing in Section 4.6.43 (and associated IANA text in 15.21), where it's not even clear whether this > is an enumeration or bit field. Drawing bit diagrams would be a good idea, IMHO. Again, because of the amount of text that will be changed due to this Clarification, I have created issue 164. > > Section 4.6.50 (WTP Static IP Address Information): probably should have a sentence saying why this is for IPv4 only. Well.. I have added the following sentence to the introduction of the Message element: IPv6 WTPs are expected to use dynamic addresses. > > Section 4.6.50 (WTP Static IP Address Information): "Netmask" field is listed twice. Got it - thanks. > > Section 4.6.28 (Image Identifier): length should be >= 5 (instead of 1)? Correct > > Section 4.6.30 (Initiate Download): there's no message element named "Image Download" You've unfortunately uncovered a much bigger issue. I have created issue 165 to track this. > > Section 6.1 (Join Request): WTP IPv4/6 IP Address are listed twice. Fixed by addressing the NAT Considerations issue. > > Section 4.6.28 (Image Identifier) says this message element is sent by the AC to the WTP; but according to Section 9.1, > it can also be sent by the WTP? Yes, this is now part of issue 165 > > Section 9.1.2: should say that "Image Information" and "Initiate Download" elements are included only when this message > is sent by the AC. Also part of issue 165 > > Section 12.2 says Session ID is 64 bits, but in Section 4.6.37, it's 32 bits. Right. Changed the Session ID message element length. > > Section 12.5: This text probably needs to mention PSK Identity Hint as well. Not sure what this means, so will open up a new tracker issue 167 to handle this. > > Section 15: Even if the well-known port numbers have already been allocated, it would be good to say they've been > allocated by IANA. > > Section 15: needs to cite RFC 5226 for the "Standards Action" policy. > > Section 15: RFC 5226 says that documents requesting creation of new registries MUST include certain instructions for > IANA (RFC 5226 Section 4.2) -- many of the details are currently missing. OK, I am creating a separate issue to track all of the IANA changes. This is tracker issue 166. > > Various places: Needs a reference to RFC 3629 for UTF-8. Yes, took care of that. Pasi, please confirm the issues that are addressed here are OK with you. I can then close this. I will create separate threads for the other issues opened as a result of this one. Thanks again for the review! 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 Jul 29 11:17:38 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49DC328C116 for ; Tue, 29 Jul 2008 11:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUT3pu+QS76f for ; Tue, 29 Jul 2008 11:17:37 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 315E83A6916 for ; Tue, 29 Jul 2008 11:17:37 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 31C111C40FC4 for ; Tue, 29 Jul 2008 11:17:50 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 4A91B440162 for ; Tue, 29 Jul 2008 11:17:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2EA773610002 for ; Tue, 29 Jul 2008 11:17:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5D4423610004 for ; Tue, 29 Jul 2008 11:17:30 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from bacon.cs.umd.edu (server-nat-4.cs.umd.edu [128.8.127.147]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 11:17:30 -0700 (PDT) Received: from [172.17.2.122] ([130.129.65.221]) (authenticated bits=0) by bacon.cs.umd.edu (8.13.1/8.14.1) with ESMTP id m6TIH2a0020087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 14:17:04 -0400 Message-ID: <488F5E9E.9010707@cs.umd.edu> Date: Tue, 29 Jul 2008 14:17:02 -0400 From: Charles Clancy User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <28807265.1217294249257.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> <4FF84B0BC277FF45AA27FE969DD956A2062CB345@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2062CB345@xmb-sjc-235.amer.cisco.com> X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-49, required 5, ALL_TRUSTED -50.00, UNSUB_DRH 1.00) X-CSD-MailScanner-From: clancy@cs.umd.edu Cc: capwap@frascone.com, Pasi.Eronen@nokia.com, Charles Clancy Subject: Re: [Capwap] Issue 153: Linking of control and data channels 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 Pat, We discussed this during the meeting. Pasi suggested simplifying the text, and indicated that it shouldn't cause any interoperability problems. I'm proposing the following text for section 4.4.3: If the AC and WTP are configured to tunnel the data channel over DTLS, the proper DTLS session must be initiated. To avoid having to reauthenticate and reauthorize an AC and WTP, the DTLS data channel SHOULD be initiated using the TLS session resumption feature . The AC DTLS implementation MUST NOT initiate a data channel session for a DTLS session for which there is no active control channel session. -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland Pat Calhoun (pacalhou) wrote: > In which case I propose we close this issue and mark as rejected. > > Pasi? > > PatC > > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > Sent: Monday, July 28, 2008 6:17 PM > To: Charles Clancy; Pat Calhoun (pacalhou) > Cc: capwap@frascone.com; Pasi.Eronen@nokia.com > Subject: Re: [Capwap] Issue 153: Linking of control and data channels > > I agree with Charles. > > -----Original Message----- >> From: Charles Clancy >> Sent: Jul 28, 2008 5:54 PM >> To: "Pat Calhoun (pacalhou)" >> Cc: capwap@frascone.com, Pasi.Eronen@nokia.com >> Subject: Re: [Capwap] Issue 153: Linking of control and data channels >> >> The goal of the text was to provide efficient interoperability, and >> handle all the edge cases. Typically when you use session resumption, >> you're resuming a session that's ended. Here we have two simultaneous >> DTLS sessions running, with the second one being a resumption of the >> first. We're using DTLS session resumption to quickly open a second >> tunnel while the first is still running. Given this use, I believe all > >> the text in section 4.4.3 is necessary. >> >> The alternative would be to not say anything about it and leave it up >> to the DTLS implementations. I think this would result in having to do > >> full authentications on the data channel more frequently than not. It >> could also possibly allow you to establish a data channel without a >> control channel. >> >> -- >> t. charles clancy, ph.d. eng.umd.edu/~tcc >> electrical & computer engineering, university of maryland >> >> >> Pat Calhoun (pacalhou) wrote: >>> Pasi's comment is: >>> >>> The linking of control and data channels, and how DTLS session >>> resumption is >>> used here, seems unnecessarily complicated. Normally session >>> resumption is >>> totally TLS internal optimization, and applications running over >>> TLS don't >>> know (and have no need to know) whether full or abbreviated TLS >>> handshake was >>> used. It seems this document wouldn't really need to say anything >>> about >>> session resumption; if the WTP provides the Session ID in data >>> channel, and AC >>> checks that both DTLS connections were established by the same >>> authenticated >>> client, that seems sufficient. This would seem to remove much >>> implementation >>> complexity; e.g. the requirement in 4.4.3 that "The AC DTLS >>> implementation >>> MUST NOT accept a session resumption request for a DTLS session in > >>> which the >>> control channel for the session has been torn down" doesn't follow > >>> the usual >>> TLS/DTLS module boundaries. >>> >>> Given the nature of the question, I would like to defer to Scott or >>> Charles. I recall us going back and forth on this, and would like >>> their guidance before we propose a change. >>> >>> PatC >>> _________________________________________________________________ >>> To unsubscribe or modify your subscription options, please visit: >>> http://lists.frascone.com/mailman/listinfo/capwap >>> >>> Archives: http://lists.frascone.com/pipermail/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 Jul 29 11:23:24 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33AF428B56A for ; Tue, 29 Jul 2008 11:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2K5FVRL1JFx for ; Tue, 29 Jul 2008 11:23:23 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 762A73A6AD1 for ; Tue, 29 Jul 2008 11:23:23 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9F6DE1C40FC3 for ; Tue, 29 Jul 2008 11:23:36 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id A9BB54400FB for ; Tue, 29 Jul 2008 11:23:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6222F361003D for ; Tue, 29 Jul 2008 11:23:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C33B13610039 for ; Tue, 29 Jul 2008 11:23:03 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from bacon.cs.umd.edu (server-nat-4.cs.umd.edu [128.8.127.147]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 11:23:00 -0700 (PDT) Received: from [172.17.2.122] ([130.129.65.221]) (authenticated bits=0) by bacon.cs.umd.edu (8.13.1/8.14.1) with ESMTP id m6TIMmPQ020227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 14:22:50 -0400 Message-ID: <488F5FF8.2050305@cs.umd.edu> Date: Tue, 29 Jul 2008 14:22:48 -0400 From: Charles Clancy User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <4FF84B0BC277FF45AA27FE969DD956A2062CB476@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2062CB476@xmb-sjc-235.amer.cisco.com> X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-50, required 5, autolearn=not spam, ALL_TRUSTED -50.00) X-CSD-MailScanner-From: clancy@cs.umd.edu Cc: capwap@frascone.com, Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 162: Nits from Pasi's Review 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 Pat, >> Section 12.5: This text probably needs to mention PSK Identity Hint >> as well. > > Not sure what this means, so will open up a new tracker issue 167 to > handle this. We should add to the first bulleted list of section 12.5: o PSK Identity: Identity hint associated with the provisioned key (see section 2.4.4.4 for more information). -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 29 11:25:30 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A79EF3A67AB for ; Tue, 29 Jul 2008 11:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruOExgLPJ4kv for ; Tue, 29 Jul 2008 11:25:30 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 009E43A635F for ; Tue, 29 Jul 2008 11:25:30 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2A37C1C40FB9 for ; Tue, 29 Jul 2008 11:25:40 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 4B3BF4400FB for ; Tue, 29 Jul 2008 11:25:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 266073610008 for ; Tue, 29 Jul 2008 11:25:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5DFB5361000F for ; Tue, 29 Jul 2008 11:25:27 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from bacon.cs.umd.edu (server-nat-4.cs.umd.edu [128.8.127.147]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 11:25:27 -0700 (PDT) Received: from [172.17.2.122] ([130.129.65.221]) (authenticated bits=0) by bacon.cs.umd.edu (8.13.1/8.14.1) with ESMTP id m6TIOw6n021495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 14:25:00 -0400 Message-ID: <488F607A.4090005@cs.umd.edu> Date: Tue, 29 Jul 2008 14:24:58 -0400 From: Charles Clancy User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <4FF84B0BC277FF45AA27FE969DD956A2062CB476@xmb-sjc-235.amer.cisco.com> <488F5FF8.2050305@cs.umd.edu> In-Reply-To: <488F5FF8.2050305@cs.umd.edu> X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-50, required 5, autolearn=not spam, ALL_TRUSTED -50.00) X-CSD-MailScanner-From: clancy@cs.umd.edu Cc: capwap@frascone.com, Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 162: Nits from Pasi's Review 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 Correction -- we already have "Key Identifier" in the bulleted list, which is the PSK Identity Hint. Perhaps it would be best to add the text I mentioned below in place of the third bullet in the first bulleted list of 12.5. -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland Charles Clancy wrote: > Pat, > > >> Section 12.5: This text probably needs to mention PSK Identity Hint > >> as well. > > > > Not sure what this means, so will open up a new tracker issue 167 to > > handle this. > > We should add to the first bulleted list of section 12.5: > > o PSK Identity: Identity hint associated with the provisioned key > (see section 2.4.4.4 for more information). > > -- > t. charles clancy, ph.d. eng.umd.edu/~tcc > electrical & computer engineering, university of maryland > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 29 12:17:15 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D5DF3A6B42 for ; Tue, 29 Jul 2008 12:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.681 X-Spam-Level: X-Spam-Status: No, score=-2.681 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jx7FHLN1W3vs for ; Tue, 29 Jul 2008 12:17:14 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 26E213A6B41 for ; Tue, 29 Jul 2008 12:17:13 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2C2EB1C40F4F for ; Tue, 29 Jul 2008 12:17:27 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 42D90440159 for ; Tue, 29 Jul 2008 12:17:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 12AC4361000E for ; Tue, 29 Jul 2008 12:17:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 73E733610005 for ; Tue, 29 Jul 2008 12:17:12 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.72 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 12:17:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,273,1215388800"; d="scan'208";a="90954066" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 29 Jul 2008 19:17:06 +0000 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/8.12.11) with ESMTP id m6TJH6HF017993; Tue, 29 Jul 2008 12:17:06 -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.13.8/8.13.8) with ESMTP id m6TJH5C9014721; Tue, 29 Jul 2008 19:17:05 GMT 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.1830); Tue, 29 Jul 2008 12:17:05 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 12:17:03 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CB585@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 164: Some bitfields need to be clarified Thread-Index: Acjxr68Adw4re4xRQ+WbjSG6r7+Ajw== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 29 Jul 2008 19:17:05.0461 (UTC) FILETIME=[B002E650:01C8F1AF] Authentication-Results: sj-dkim-4; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 164: Some bitfields need to be clarified 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 Pasi's comment was: The description of bit fields needs clarification in several places: at least Section 4.6.1 (Security field), 4.6.1 (DTLS Policy field), 4.6.43 (Frame Tunnel Mode field). For example, the "Security" field currently seems to say that bit 1 is X.509, bit 2 is PSK, and bits 0 and 3..7 are unused -- but the intention was probably to say that bit 0 is X.509 and so on. This gets especially confusing in Section 4.6.43 (and associated IANA text in 15.21), where it's not even clear whether this is an enumeration or bit field. Drawing bit diagrams would be a good idea, IMHO. Pasi is correct. One could mis-interpret the spec and think that the values provided are in fact the values, and not the bit positions in the frame. So I do agree that we should address this problem to ensure interoperability. Note that in my process, I assumed that existing implementation assumed that the value was in fact the bit position, hence why the zero (0) was always reserved. Here is the proposed text: 4.6.1. AC Descriptor [...] Security: A 8 bit mask specifying the authentication credential type supported by the AC (See Section 2.4.4). The field has the following format: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Reserved |S|X|U| +-+-+-+-+-+-+-+-+ Reserved: A set of reserved bits for future use. 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. S: The AC supports the pre-shared secret authentication, as described in Section 12.6. X: The AC supports X.509 Certificate authentication, as described in Section 12.7. U: This bit is set to zero and is unused. [...] DTLS Policy: The AC communicates its policy on the use of DTLS for the CAPWAP data channel. The AC MAY communicate more than one supported option, represented by the bit field below. The WTP MUST abide by one of the options communicated by AC. The field has the following format: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Reserved |D|C|U| +-+-+-+-+-+-+-+-+ Reserved: A set of reserved bits for future use. 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. D: DTLS Enabled Data Channel Supported C: Clear Text Data Channel Supported U: This bit is set to zero and is unused. 4.6.44. WTP Frame Tunnel Mode The WTP Frame Tunnel Mode message element allows the WTP to communicate the tunneling modes of operation which it supports to the AC. A WTP that advertises support for all types allows the AC to select which type will be used, based on its local policy. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Reservd|N|E|L|U| +-+-+-+-+-+-+-+-+ Type: 41 for WTP Frame Tunnel Mode Length: 1 Reservd: A set of reserved bits for future use. 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. N: Native Frame Tunnel mode requires the WTP and AC to encapsulate all user payloads as native wireless frames, as defined by the wireless binding (see for example Section 4.4) E: The 802.3 Frame Tunnel Mode requires the WTP and AC to encapsulate all user payload as native IEEE 802.3 frames (see Section 4.4). All user traffic is tunneled to the AC. This value MUST NOT be used when the WTP MAC Type is set to Split-MAC. L: When Local Bridging is used, the WTP does not tunnel user traffic to the AC; all user traffic is locally bridged. This value MUST NOT be used when the WTP MAC Type is set to Split-MAC. U: This bit is set to zero and is unused. 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 Jul 29 12:24:23 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B77A3A6B5E for ; Tue, 29 Jul 2008 12:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1n+Ew0p2P6Ay for ; Tue, 29 Jul 2008 12:24:22 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id B38F13A6B5D for ; Tue, 29 Jul 2008 12:24:22 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D264D1C40F7E for ; Tue, 29 Jul 2008 12:24:35 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 0FBFB440159 for ; Tue, 29 Jul 2008 12:24:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E286E361000F for ; Tue, 29 Jul 2008 12:24:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 07CDC3610004 for ; Tue, 29 Jul 2008 12:24:23 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 12:24:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,273,1215388800"; d="scan'208";a="133188007" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 29 Jul 2008 19:24:22 +0000 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/8.12.11) with ESMTP id m6TJOMPZ005266; Tue, 29 Jul 2008 12:24:22 -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.13.8/8.13.8) with ESMTP id m6TJOMTt027469; Tue, 29 Jul 2008 19:24:22 GMT 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.1830); Tue, 29 Jul 2008 12:24:22 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 12:24:20 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CB58C@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 163: R-MAC Info Field needs to be clarified and cleaned up Thread-Index: AcjxsLN7vuVOv1feQwOrPA/QKaCKsA== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 29 Jul 2008 19:24:22.0213 (UTC) FILETIME=[B455F750:01C8F1B0] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 163: R-MAC Info Field needs to be clarified and cleaned up 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 Pasi's Comment was: Section 4.6.1, description of R-MAC Field needs some more text (current text would probably be fine if the field was only 1 bit, but it's 8 bits). Yes, clearly this needs some additional language. However, turning the field into a series of flags would change the protocol, and therefore not be what the WG would prefer. So instead I am proposing the following language, which provides clarity without any compatibility issues: 4.6.1. AC Descriptor [...] R-MAC Field: The AC supports the optional Radio MAC Address field in the CAPWAP transport Header (see Section 4.3). The following enumerated values are supported: 0 - Reserved 1 - Supported 2 - Not Supported Note that I chose these values in order to be consistent with the enabled/disabled values used throughout the specification - as opposed to the logical binary values. 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 Jul 29 12:25:33 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F192F3A6AB2 for ; Tue, 29 Jul 2008 12:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.673 X-Spam-Level: X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yZ2y47Nx58y for ; Tue, 29 Jul 2008 12:25:33 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 405593A68B5 for ; Tue, 29 Jul 2008 12:25:33 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 826591C40FBB for ; Tue, 29 Jul 2008 12:25:46 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 08362440159 for ; Tue, 29 Jul 2008 12:25:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D3B1C3610003 for ; Tue, 29 Jul 2008 12:25:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6F224361000D for ; Tue, 29 Jul 2008 12:25:32 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 12:25:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,273,1215388800"; d="scan'208";a="133188645" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 29 Jul 2008 19:25:32 +0000 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/8.12.11) with ESMTP id m6TJPWj1007154; Tue, 29 Jul 2008 12:25: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.13.8/8.13.8) with ESMTP id m6TJPW6u026175; Tue, 29 Jul 2008 19:25:32 GMT 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, 29 Jul 2008 12:25:31 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 12:25:30 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CB58F@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 167: Need to mention PSK Identity Hint Thread-Index: AcjxsN0z2Oh9uYPdTY+hKQ89dmN6VA== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 29 Jul 2008 19:25:31.0867 (UTC) FILETIME=[DDDA52B0:01C8F1B0] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Pasi.Eronen@nokia.com, clancy@ltsnet.net Subject: [Capwap] Issue 167: Need to mention PSK Identity Hint 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 Pasi's comment was: Section 12.5: This text probably needs to mention PSK Identity Hint as well. I will need help from Scott and/or Charles on how to address this comment. 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 Jul 29 12:30:28 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE8E528C119 for ; Tue, 29 Jul 2008 12:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZ-iiVVIwwUZ for ; Tue, 29 Jul 2008 12:30:28 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 03AD73A6783 for ; Tue, 29 Jul 2008 12:30:28 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8E03C43A505 for ; Tue, 29 Jul 2008 12:30:33 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 71228440159 for ; Tue, 29 Jul 2008 12:30:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 1074A361000D for ; Tue, 29 Jul 2008 12:30:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3C4F1361000A for ; Tue, 29 Jul 2008 12:30:22 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from bacon.cs.umd.edu (server-nat-4.cs.umd.edu [128.8.127.147]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 12:30:21 -0700 (PDT) Received: from [127.0.0.1] ([130.129.65.9]) (authenticated bits=0) by bacon.cs.umd.edu (8.13.1/8.14.1) with ESMTP id m6TJToQm028741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 15:29:52 -0400 Message-ID: <488F6FAE.6080805@umd.edu> Date: Tue, 29 Jul 2008 15:29:50 -0400 From: Charles Clancy User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <4FF84B0BC277FF45AA27FE969DD956A2062CB58F@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2062CB58F@xmb-sjc-235.amer.cisco.com> X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-50, required 5, autolearn=not spam, ALL_TRUSTED -50.00) X-CSD-MailScanner-From: tcc@umd.edu Cc: capwap@frascone.com, Pasi.Eronen@nokia.com, clancy@ltsnet.net Subject: Re: [Capwap] Issue 167: Need to mention PSK Identity Hint 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 Pat, > Section 12.5: This text probably needs to mention PSK Identity Hint > as > well. > > I will need help from Scott and/or Charles on how to address this > comment. See my earlier post. Replace: o Key Identifier: The pre-shared key identifier, as described in RFC 4279 [RFC4279]. With: o PSK Identity: Identity hint associated with the provisioned key (see section 2.4.4.4 for more information). -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jul 29 13:24:51 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5610128C122 for ; Tue, 29 Jul 2008 13:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3C-ukVro2FB2 for ; Tue, 29 Jul 2008 13:24:49 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 645EE28C14D for ; Tue, 29 Jul 2008 13:24:47 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A83331C40F5D for ; Tue, 29 Jul 2008 13:25:00 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 93D43440102 for ; Tue, 29 Jul 2008 13:24:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5593E361000C for ; Tue, 29 Jul 2008 13:24:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E04403610015 for ; Tue, 29 Jul 2008 13:24:47 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 13:24:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,273,1215388800"; d="scan'208";a="70233049" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2008 20:24:43 +0000 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/8.12.11) with ESMTP id m6TKOhmZ002040; Tue, 29 Jul 2008 13:24:43 -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.13.8/8.13.8) with ESMTP id m6TKOgtc015409; Tue, 29 Jul 2008 20:24:42 GMT 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, 29 Jul 2008 13:24:42 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 13:24:41 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CB5FE@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 165: Image Download inconsistencies Thread-Index: AcjxuSHHbMnlOv04Qjmm+6GXGVnY3A== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 29 Jul 2008 20:24:42.0753 (UTC) FILETIME=[22588710:01C8F1B9] Authentication-Results: sj-dkim-4; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 165: Image Download inconsistencies 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 Pasi's comment was: Section 4.6.30 (Initiate Download): there's no message element named "Image Download" and Section 4.6.28 (Image Identifier) says this message element is sent by the AC to the WTP; but according to Section 9.1, it can also be sent by the WTP? and Section 9.1.2: should say that "Image Information" and "Initiate Download" elements are included only when this message is sent by the AC. This is another area that Pasi fortunately caught that is has some bugs. I just went through the text, and there were some inconsistencies, not to mention exchanges that made no sense. For instance, the AC would send the Initiate Download, but it is really the WTP's decision to initiate the download so that needed to be fixed. Further, as Pasi found out, there was a reference to a message element that did not exist (Image Download), inconsistencies on whom should send what, etc. In fact, even in the four scenarios that are described in section 9.1, use case four was inconsistent with use case three. So I have cleaned up the text, and we have, what I now believe is good text. Of course, I would appreciate a review. Unfortunately, a diff only of section 9.1 would be too hard to follow, so I will include the whole section with the use cases. 4.6.28. Image Identifier The Image Identifier message element is sent by the AC to the WTP to indicate the expected active software version that is to be run on the WTP. The WTP sends the Image Identifier message element in order to request a specific software version from the AC. The actual download process is defined in Section 9.1. The value is a variable length UTF-8 encoded string [RFC3629], which is NOT zero terminated. [...] 4.6.29. Image Information The Image Information message element is present in the Image Data Response message sent by the AC to the WTP and contains the following fields. [...] 4.6.30. Initiate Download The Initiate Download message element is used by the WTP to inform the AC that the AC SHOULD initiate a firmware upgrade. The AC subsequently transmits an Image Data Request message which includes the Image Data message element. This message element does not contain any data. [...] 6.2. Join Response [...] The AC includes the Image Identifier message element to indicate the software version it expects the WTP to run. This information is used to determine whether the WTP MUST either change its currently running firmware image, or download a new version (see Section 9.1.1). 8.4. Configuration Update Request [...] The AC includes the Image Identifier message element (see Section 4.6.28) to force the WTP to update its firmware while in the Run state. The WTP MAY proceed to download the requested firmware if it determines the version specified in the Image Identifier message element is not in its non-volatile storage by transmitting an Image Data Request (see Section 9.1.1) that includes the Initiate Download message element (see Section 4.6.30). 9.1. Firmware Management This section describes the firmware download procedures used by the CAPWAP protocol. Firmware download can occur during the Image Data or Run state. Figure 6 provides an example of a WTP that performs a firmware upgrade while in the Image Data state. In this example, the WTP does not already have the requested firmware (Image Identifier = x), and downloads the image from the AC. WTP AC Join Request --------------------------------------------------------> Join Response (Image Identifier = x) <------------------------------------------------------ Image Data Request (Image Identifier = x, Initiate Download) --------------------------------------------------------> Image Data Response (Result Code = Success, Image Information = {size,hash}) <------------------------------------------------------ Image Data Request (Image Data = Data) <------------------------------------------------------ Image Data Response (Result Code = Success) --------------------------------------------------------> ..... Image Data Request (Image Data = EOF) <------------------------------------------------------ Image Data Response (Result Code = Success) --------------------------------------------------------> (WTP enters the Reset State) Figure 6: WTP Firmware Download Case 1 Figure 7 provides an example in which the WTP has the image specified by the AC in its non-volative storage, but is not its current running image. In this case, the WTP opts to NOT download the firmware and immediately reset to the requested image. WTP AC Join Request --------------------------------------------------------> Join Response (Image Identifier = x) <------------------------------------------------------ (WTP enters the Reset State) Figure 7: WTP Firmware Download Case 2 Figure 8 provides an example of a WTP that performs a firmware upgrade while in the Run state. This mode of firmware upgrade allows the WTP to download its image while continuing to provide service. The WTP will not automatically reset until it is notified by the AC, with a Reset Request message. WTP AC Configuration Update Request (Image Identifier = x) <------------------------------------------------------ Configuration Update Response (Result Code = Success) --------------------------------------------------------> Image Data Request (Image Identifier = x, Initiate Download) --------------------------------------------------------> Image Data Response (Result Code = Success, Image Information = {size,hash}) <------------------------------------------------------ Image Data Request (Image Data = Data) <------------------------------------------------------ Image Data Response (Result Code = Success) --------------------------------------------------------> ..... Image Data Request (Image Data = EOF) <------------------------------------------------------ Image Data Response (Result Code = Success) --------------------------------------------------------> ..... (administratively requested reboot request) Reset Request (Image Identifier = x) <------------------------------------------------------ Reset Response (Result Code = Success) --------------------------------------------------------> Figure 8: WTP Firmware Download Case 3 Figure 9 provides another example of the firmware download while in the Run state. In this example, the WTP already has the image specified by the AC in its non-volative storage. The WTP opts to NOT download the firmware. The WTP resets upon receipt of a Reset Request message from the AC. WTP AC Configuration Update Request (Image Identifier = x) <------------------------------------------------------ Configuration Update Response (Result Code = Already Have Image) --------------------------------------------------------> ..... (administratively requested reboot request) Reset Request (Image Identifier = x) <------------------------------------------------------ Reset Response (Result Code = Success) --------------------------------------------------------> Figure 9: WTP Firmware Download Case 4 9.1.1. Image Data Request [...] The decision that new firmware is to be downloaded to the WTP can occur in one of two ways: When the WTP joins the AC, the Join Response message includes the Image Identifier message element, which informs the WTP of the firmware it is expected to run. if the WTP does not currently have the requested firmware version, it transmits an Image Data Request message, with the appropriate Image Identifier message element. If the WTP already has the requested firmware in its non-volatile flash, but is not its currently running image, it simply resets to run the proper firmware. Once the WTP is in the Run state, it is possible for the AC to cause the WTP to initiate a firmware download by sending an Configuration Update Request message with the Image Identifier message elements. This will cause the WTP to transmit an Image Data Request with the Image Identifier and the Initiate Download message elements. Note that when the firmware is downloaded in this way, the WTP does not automatically reset after the download is complete. The WTP will only reset when it receives a Reset Request message from the AC. If the WTP already had the requested firmware version in its non-volatile storage, the WTP does not transmit the Image Data Request message and responds with a Configuration Update Response message with the Result Code set to Image Already Present. Regardless of how the download was initiated, once the AC receives an Image Data Request message with the Image Identifier message element, it begins the transfer process by transmitting an Image Data Request message that includes the Image Data message element. This continues until the firmware image has been transferred. [...] The following message elements MAY be included in the Image Data Request message when sent by the WTP. o Image Identifier, see Section 4.6.28 o Initiate Download, see Section 4.6.30 9.1.2. Image Data Response [...] The following message elements MAY be included in the Image Data Response message when sent by the AC. o Image Information, see Section 4.6.29 9.2. Reset Request [...] A Reset Request message is sent by an AC to cause a WTP to reinitialize its operation. If the AC includes the Image Identifier message element (see Section 4.6.28), it indicates to the WTP that it SHOULD use that version of software upon reboot. 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 Jul 29 13:34:07 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB47428C150 for ; Tue, 29 Jul 2008 13:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXiD6G6tgRgb for ; Tue, 29 Jul 2008 13:34:06 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id A423028C149 for ; Tue, 29 Jul 2008 13:34:06 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 011581C40F8F for ; Tue, 29 Jul 2008 13:34:19 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 01E7944010E for ; Tue, 29 Jul 2008 13:34:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2B29A3618009 for ; Tue, 29 Jul 2008 13:34:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E9D953618006 for ; Tue, 29 Jul 2008 13:34:03 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 13:34:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,273,1215388800"; d="scan'208";a="70237426" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2008 20:34:03 +0000 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/8.12.11) with ESMTP id m6TKY3wj008123; Tue, 29 Jul 2008 13:34:03 -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.13.8/8.13.8) with ESMTP id m6TKY3Cg023064; Tue, 29 Jul 2008 20:34:03 GMT 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, 29 Jul 2008 13:34:02 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 13:34:02 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CB616@xmb-sjc-235.amer.cisco.com> In-Reply-To: <488F5E9E.9010707@cs.umd.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 153: Linking of control and data channels Thread-Index: Acjxp9zzjtOuNiosSzyOglhju164zgAEoReA References: <28807265.1217294249257.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> <4FF84B0BC277FF45AA27FE969DD956A2062CB345@xmb-sjc-235.amer.cisco.com> <488F5E9E.9010707@cs.umd.edu> From: "Pat Calhoun (pacalhou)" To: "Charles Clancy" X-OriginalArrivalTime: 29 Jul 2008 20:34:02.0983 (UTC) FILETIME=[7044D770:01C8F1BA] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap@frascone.com, Pasi.Eronen@nokia.com, Charles Clancy Subject: Re: [Capwap] Issue 153: Linking of control and data channels 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 Do you mean to replace all of the text, or are you proposing adding the second paragraph to replace the last one? PatC -----Original Message----- From: Charles Clancy [mailto:clancy@cs.umd.edu] Sent: Tuesday, July 29, 2008 11:17 AM To: Pat Calhoun (pacalhou) Cc: Scott G. Kelly; Charles Clancy; capwap@frascone.com; Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 153: Linking of control and data channels Pat, We discussed this during the meeting. Pasi suggested simplifying the text, and indicated that it shouldn't cause any interoperability problems. I'm proposing the following text for section 4.4.3: If the AC and WTP are configured to tunnel the data channel over DTLS, the proper DTLS session must be initiated. To avoid having to reauthenticate and reauthorize an AC and WTP, the DTLS data channel SHOULD be initiated using the TLS session resumption feature . The AC DTLS implementation MUST NOT initiate a data channel session for a DTLS session for which there is no active control channel session. -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland Pat Calhoun (pacalhou) wrote: > In which case I propose we close this issue and mark as rejected. > > Pasi? > > PatC > > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > Sent: Monday, July 28, 2008 6:17 PM > To: Charles Clancy; Pat Calhoun (pacalhou) > Cc: capwap@frascone.com; Pasi.Eronen@nokia.com > Subject: Re: [Capwap] Issue 153: Linking of control and data channels > > I agree with Charles. > > -----Original Message----- >> From: Charles Clancy >> Sent: Jul 28, 2008 5:54 PM >> To: "Pat Calhoun (pacalhou)" >> Cc: capwap@frascone.com, Pasi.Eronen@nokia.com >> Subject: Re: [Capwap] Issue 153: Linking of control and data channels >> >> The goal of the text was to provide efficient interoperability, and >> handle all the edge cases. Typically when you use session >> resumption, you're resuming a session that's ended. Here we have two >> simultaneous DTLS sessions running, with the second one being a >> resumption of the first. We're using DTLS session resumption to >> quickly open a second tunnel while the first is still running. Given >> this use, I believe all > >> the text in section 4.4.3 is necessary. >> >> The alternative would be to not say anything about it and leave it up >> to the DTLS implementations. I think this would result in having to >> do > >> full authentications on the data channel more frequently than not. >> It could also possibly allow you to establish a data channel without >> a control channel. >> >> -- >> t. charles clancy, ph.d. eng.umd.edu/~tcc >> electrical & computer engineering, university of maryland >> >> >> Pat Calhoun (pacalhou) wrote: >>> Pasi's comment is: >>> >>> The linking of control and data channels, and how DTLS session >>> resumption is >>> used here, seems unnecessarily complicated. Normally session >>> resumption is >>> totally TLS internal optimization, and applications running over >>> TLS don't >>> know (and have no need to know) whether full or abbreviated TLS >>> handshake was >>> used. It seems this document wouldn't really need to say anything >>> about >>> session resumption; if the WTP provides the Session ID in data >>> channel, and AC >>> checks that both DTLS connections were established by the same >>> authenticated >>> client, that seems sufficient. This would seem to remove much >>> implementation >>> complexity; e.g. the requirement in 4.4.3 that "The AC DTLS >>> implementation >>> MUST NOT accept a session resumption request for a DTLS session >>> in > >>> which the >>> control channel for the session has been torn down" doesn't >>> follow > >>> the usual >>> TLS/DTLS module boundaries. >>> >>> Given the nature of the question, I would like to defer to Scott or >>> Charles. I recall us going back and forth on this, and would like >>> their guidance before we propose a change. >>> >>> PatC >>> _________________________________________________________________ >>> To unsubscribe or modify your subscription options, please visit: >>> http://lists.frascone.com/mailman/listinfo/capwap >>> >>> Archives: http://lists.frascone.com/pipermail/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 Jul 29 14:05:43 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD77A3A69CF for ; Tue, 29 Jul 2008 14:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vlcD7H3BVcx for ; Tue, 29 Jul 2008 14:05:42 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id BF8163A67AB for ; Tue, 29 Jul 2008 14:05:42 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DBF2D1C40F81 for ; Tue, 29 Jul 2008 14:05:54 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 0936B4400E3 for ; Tue, 29 Jul 2008 14:05:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 77CB9362801C for ; Tue, 29 Jul 2008 14:05:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 928EF3628009 for ; Tue, 29 Jul 2008 14:05:36 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from bacon.cs.umd.edu (server-nat-4.cs.umd.edu [128.8.127.147]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 14:05:35 -0700 (PDT) Received: from [127.0.0.1] ([130.129.65.9]) (authenticated bits=0) by bacon.cs.umd.edu (8.13.1/8.14.1) with ESMTP id m6TL513X006876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 17:05:03 -0400 Message-ID: <488F85FC.2030108@umd.edu> Date: Tue, 29 Jul 2008 17:05:00 -0400 From: Charles Clancy User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <28807265.1217294249257.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> <4FF84B0BC277FF45AA27FE969DD956A2062CB345@xmb-sjc-235.amer.cisco.com> <488F5E9E.9010707@cs.umd.edu> <4FF84B0BC277FF45AA27FE969DD956A2062CB616@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2062CB616@xmb-sjc-235.amer.cisco.com> X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-49, required 5, ALL_TRUSTED -50.00, UNSUB_DRH 1.00) X-CSD-MailScanner-From: tcc@umd.edu Cc: capwap@frascone.com, Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 153: Linking of control and data channels 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 Pat, Replace the whole section with the text below. -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland Pat Calhoun (pacalhou) wrote: > Do you mean to replace all of the text, or are you proposing adding the > second paragraph to replace the last one? > > PatC > > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Tuesday, July 29, 2008 11:17 AM > To: Pat Calhoun (pacalhou) > Cc: Scott G. Kelly; Charles Clancy; capwap@frascone.com; > Pasi.Eronen@nokia.com > Subject: Re: [Capwap] Issue 153: Linking of control and data channels > > Pat, > > We discussed this during the meeting. Pasi suggested simplifying the > text, and indicated that it shouldn't cause any interoperability > problems. I'm proposing the following text for section 4.4.3: > > If the AC and WTP are configured to tunnel the data channel over > DTLS, the proper DTLS session must be initiated. To avoid having to > reauthenticate and reauthorize an AC and WTP, the DTLS data channel > SHOULD be initiated using the TLS session resumption feature > . > > The AC DTLS implementation MUST NOT initiate a data channel session > for a DTLS session for which there is no active control > channel session. > > > -- > t. charles clancy, ph.d. eng.umd.edu/~tcc > electrical & computer engineering, university of maryland > > > Pat Calhoun (pacalhou) wrote: >> In which case I propose we close this issue and mark as rejected. >> >> Pasi? >> >> PatC >> >> -----Original Message----- >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >> Sent: Monday, July 28, 2008 6:17 PM >> To: Charles Clancy; Pat Calhoun (pacalhou) >> Cc: capwap@frascone.com; Pasi.Eronen@nokia.com >> Subject: Re: [Capwap] Issue 153: Linking of control and data channels >> >> I agree with Charles. >> >> -----Original Message----- >>> From: Charles Clancy >>> Sent: Jul 28, 2008 5:54 PM >>> To: "Pat Calhoun (pacalhou)" >>> Cc: capwap@frascone.com, Pasi.Eronen@nokia.com >>> Subject: Re: [Capwap] Issue 153: Linking of control and data channels >>> >>> The goal of the text was to provide efficient interoperability, and >>> handle all the edge cases. Typically when you use session >>> resumption, you're resuming a session that's ended. Here we have two > >>> simultaneous DTLS sessions running, with the second one being a >>> resumption of the first. We're using DTLS session resumption to >>> quickly open a second tunnel while the first is still running. Given > >>> this use, I believe all >>> the text in section 4.4.3 is necessary. >>> >>> The alternative would be to not say anything about it and leave it up > >>> to the DTLS implementations. I think this would result in having to >>> do >>> full authentications on the data channel more frequently than not. >>> It could also possibly allow you to establish a data channel without >>> a control channel. >>> >>> -- >>> t. charles clancy, ph.d. eng.umd.edu/~tcc >>> electrical & computer engineering, university of maryland >>> >>> >>> Pat Calhoun (pacalhou) wrote: >>>> Pasi's comment is: >>>> >>>> The linking of control and data channels, and how DTLS session >>>> resumption is >>>> used here, seems unnecessarily complicated. Normally session >>>> resumption is >>>> totally TLS internal optimization, and applications running over >>>> TLS don't >>>> know (and have no need to know) whether full or abbreviated TLS >>>> handshake was >>>> used. It seems this document wouldn't really need to say anything > >>>> about >>>> session resumption; if the WTP provides the Session ID in data >>>> channel, and AC >>>> checks that both DTLS connections were established by the same >>>> authenticated >>>> client, that seems sufficient. This would seem to remove much >>>> implementation >>>> complexity; e.g. the requirement in 4.4.3 that "The AC DTLS >>>> implementation >>>> MUST NOT accept a session resumption request for a DTLS session >>>> in >>>> which the >>>> control channel for the session has been torn down" doesn't >>>> follow >>>> the usual >>>> TLS/DTLS module boundaries. >>>> >>>> Given the nature of the question, I would like to defer to Scott or >>>> Charles. I recall us going back and forth on this, and would like >>>> their guidance before we propose a change. >>>> >>>> PatC >>>> _________________________________________________________________ >>>> To unsubscribe or modify your subscription options, please visit: >>>> http://lists.frascone.com/mailman/listinfo/capwap >>>> >>>> Archives: http://lists.frascone.com/pipermail/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 Jul 29 14:33:39 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B68DB3A6B70 for ; Tue, 29 Jul 2008 14:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FUZZY_CPILL=0.001, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TI9k4h9Iched for ; Tue, 29 Jul 2008 14:33:38 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 51E4A3A6A3E for ; Tue, 29 Jul 2008 14:33:34 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AC5441C4030D for ; Tue, 29 Jul 2008 14:33:47 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id ECA2C440154 for ; Tue, 29 Jul 2008 14:33:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 92CC53648014 for ; Tue, 29 Jul 2008 14:33:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id B19E2364800A for ; Tue, 29 Jul 2008 14:33:26 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 14:33:26 -0700 (PDT) Received: from [209.86.224.31] (helo=elwamui-chisos.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KNwot-00028r-Mm; Tue, 29 Jul 2008 17:33:23 -0400 Received: from 208.54.95.22 by webmail.earthlink.net with HTTP; Tue, 29 Jul 2008 17:33:23 -0400 Message-ID: <17047380.1217367203616.JavaMail.root@elwamui-chisos.atl.sa.earthlink.net> Date: Tue, 29 Jul 2008 17:33:23 -0400 (EDT) From: "Scott G. Kelly" To: Charles Clancy , "Pat Calhoun (pacalhou)" Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7b7f19f0d9c038d9aaa20cf4f70188de8c5a5cb03e4ecd6342350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.31 Cc: capwap@frascone.com, Pasi.Eronen@nokia.com, clancy@ltsnet.net Subject: Re: [Capwap] Issue 160: Use of Replay Protection 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 Agree. -----Original Message----- >From: Charles Clancy >Sent: Jul 28, 2008 9:09 PM >To: "Pat Calhoun (pacalhou)" >Cc: capwap@frascone.com, Pasi.Eronen@nokia.com, clancy@ltsnet.net >Subject: Re: [Capwap] Issue 160: Use of Replay Protection > >Saying that DTLS replay detection MUST be used is okay with me. Section >4.5.3 has text that assumes DTLS replay detection is being used. > >-- >t. charles clancy, ph.d. eng.umd.edu/~tcc >electrical & computer engineering, university of maryland > > >Pat Calhoun (pacalhou) wrote: >> Here is Pasi's comment: >> >> Replay protection is an optional feature in RFC 4347. Should this >> document say >> something about it? (e.g. MUST use?) >> >> Given the nature of the question, I would like to defer to Scott or >> Charles. I recall us going back and forth on this, and would like their >> guidance before we propose a change. >> >> PatC >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/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 Jul 29 15:51:51 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15A5428C125 for ; Tue, 29 Jul 2008 15:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgYEO6wlaedl for ; Tue, 29 Jul 2008 15:51:50 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id F24A528C13B for ; Tue, 29 Jul 2008 15:51:49 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8580C1C40FA8 for ; Tue, 29 Jul 2008 15:52:03 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 91A2F440157 for ; Tue, 29 Jul 2008 15:51:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 604A8368800D for ; Tue, 29 Jul 2008 15:51:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4AFAE3688022 for ; Tue, 29 Jul 2008 15:51:48 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 29 Jul 2008 15:51:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,274,1215388800"; d="scan'208";a="133270152" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 29 Jul 2008 22:51:33 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6TMpXDD028751; Tue, 29 Jul 2008 15:51:33 -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.13.8/8.13.8) with ESMTP id m6TMpWCI026198; Tue, 29 Jul 2008 22:51:33 GMT 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, 29 Jul 2008 15:51:31 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 15:51:30 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2062CB728@xmb-sjc-235.amer.cisco.com> In-Reply-To: <488F85FC.2030108@umd.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 153: Linking of control and data channels Thread-Index: AcjxvuIXKQHj0EKBQFSgxPfO8CxVkgADr+gA References: <28807265.1217294249257.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> <4FF84B0BC277FF45AA27FE969DD956A2062CB345@xmb-sjc-235.amer.cisco.com> <488F5E9E.9010707@cs.umd.edu> <4FF84B0BC277FF45AA27FE969DD956A2062CB616@xmb-sjc-235.amer.cisco.com> <488F85FC.2030108@umd.edu> From: "Pat Calhoun (pacalhou)" To: "Charles Clancy" X-OriginalArrivalTime: 29 Jul 2008 22:51:31.0598 (UTC) FILETIME=[A4D39AE0:01C8F1CD] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap@frascone.com, Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 153: Linking of control and data channels 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 Done - thanks! PatC -----Original Message----- From: Charles Clancy [mailto:tcc@umd.edu] Sent: Tuesday, July 29, 2008 2:05 PM To: Pat Calhoun (pacalhou) Cc: Scott G. Kelly; capwap@frascone.com; Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 153: Linking of control and data channels Pat, Replace the whole section with the text below. -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland Pat Calhoun (pacalhou) wrote: > Do you mean to replace all of the text, or are you proposing adding > the second paragraph to replace the last one? > > PatC > > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Tuesday, July 29, 2008 11:17 AM > To: Pat Calhoun (pacalhou) > Cc: Scott G. Kelly; Charles Clancy; capwap@frascone.com; > Pasi.Eronen@nokia.com > Subject: Re: [Capwap] Issue 153: Linking of control and data channels > > Pat, > > We discussed this during the meeting. Pasi suggested simplifying the > text, and indicated that it shouldn't cause any interoperability > problems. I'm proposing the following text for section 4.4.3: > > If the AC and WTP are configured to tunnel the data channel over > DTLS, the proper DTLS session must be initiated. To avoid having to > reauthenticate and reauthorize an AC and WTP, the DTLS data channel > SHOULD be initiated using the TLS session resumption feature > . > > The AC DTLS implementation MUST NOT initiate a data channel session > for a DTLS session for which there is no active control > channel session. > > > -- > t. charles clancy, ph.d. eng.umd.edu/~tcc > electrical & computer engineering, university of maryland > > > Pat Calhoun (pacalhou) wrote: >> In which case I propose we close this issue and mark as rejected. >> >> Pasi? >> >> PatC >> >> -----Original Message----- >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >> Sent: Monday, July 28, 2008 6:17 PM >> To: Charles Clancy; Pat Calhoun (pacalhou) >> Cc: capwap@frascone.com; Pasi.Eronen@nokia.com >> Subject: Re: [Capwap] Issue 153: Linking of control and data channels >> >> I agree with Charles. >> >> -----Original Message----- >>> From: Charles Clancy >>> Sent: Jul 28, 2008 5:54 PM >>> To: "Pat Calhoun (pacalhou)" >>> Cc: capwap@frascone.com, Pasi.Eronen@nokia.com >>> Subject: Re: [Capwap] Issue 153: Linking of control and data >>> channels >>> >>> The goal of the text was to provide efficient interoperability, and >>> handle all the edge cases. Typically when you use session >>> resumption, you're resuming a session that's ended. Here we have >>> two > >>> simultaneous DTLS sessions running, with the second one being a >>> resumption of the first. We're using DTLS session resumption to >>> quickly open a second tunnel while the first is still running. >>> Given > >>> this use, I believe all >>> the text in section 4.4.3 is necessary. >>> >>> The alternative would be to not say anything about it and leave it >>> up > >>> to the DTLS implementations. I think this would result in having to >>> do full authentications on the data channel more frequently than >>> not. >>> It could also possibly allow you to establish a data channel without >>> a control channel. >>> >>> -- >>> t. charles clancy, ph.d. eng.umd.edu/~tcc >>> electrical & computer engineering, university of maryland >>> >>> >>> Pat Calhoun (pacalhou) wrote: >>>> Pasi's comment is: >>>> >>>> The linking of control and data channels, and how DTLS session >>>> resumption is >>>> used here, seems unnecessarily complicated. Normally session >>>> resumption is >>>> totally TLS internal optimization, and applications running over >>>> TLS don't >>>> know (and have no need to know) whether full or abbreviated TLS >>>> handshake was >>>> used. It seems this document wouldn't really need to say >>>> anything > >>>> about >>>> session resumption; if the WTP provides the Session ID in data >>>> channel, and AC >>>> checks that both DTLS connections were established by the same >>>> authenticated >>>> client, that seems sufficient. This would seem to remove much >>>> implementation >>>> complexity; e.g. the requirement in 4.4.3 that "The AC DTLS >>>> implementation >>>> MUST NOT accept a session resumption request for a DTLS session >>>> in which the >>>> control channel for the session has been torn down" doesn't >>>> follow the usual >>>> TLS/DTLS module boundaries. >>>> >>>> Given the nature of the question, I would like to defer to Scott or >>>> Charles. I recall us going back and forth on this, and would like >>>> their guidance before we propose a change. >>>> >>>> PatC >>>> _________________________________________________________________ >>>> To unsubscribe or modify your subscription options, please visit: >>>> http://lists.frascone.com/mailman/listinfo/capwap >>>> >>>> Archives: http://lists.frascone.com/pipermail/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 Jul 30 07:40:12 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAE983A6BE5 for ; Wed, 30 Jul 2008 07:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNrzUpTgaQpH for ; Wed, 30 Jul 2008 07:40:09 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D53AD3A6BD8 for ; Wed, 30 Jul 2008 07:39:58 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C63A3433DBA for ; Wed, 30 Jul 2008 07:40:11 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 7200E440100 for ; Wed, 30 Jul 2008 07:40:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 506AA34AC022 for ; Wed, 30 Jul 2008 07:40:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 82BD334AC01F for ; Wed, 30 Jul 2008 07:39:59 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 30 Jul 2008 07:39:59 -0700 (PDT) Received: from [209.86.224.34] (helo=elwamui-hound.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KOCqM-0001Bm-8u; Wed, 30 Jul 2008 10:39:58 -0400 Received: from 24.6.132.243 by webmail.earthlink.net with HTTP; Wed, 30 Jul 2008 10:39:55 -0400 Message-ID: <28330555.1217428798174.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> Date: Wed, 30 Jul 2008 07:39:58 -0700 (GMT-07:00) From: "Scott G. Kelly" To: Pasi.Eronen@nokia.com, ietf@ietf.org Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7b7f19f0d9c038d9aa779551b031ca7a3a09a5c572567efd7c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.34 Cc: capwap@frascone.com Subject: Re: [Capwap] Last call comments for capwap-threat-analysis-01 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 Some comments inline below... Pasi.Eronen wrote: >Couple of comments/observations about capwap-threat-analysis-01: > >There seem to be couple of places where this document isn't >completely in sync with the protocol/binding documents. >In particular, the following two places: > >Section 4.2, "The current CAPWAP binding for IEEE 802.11 only >supports the use of IEEE 802.11i [80211I] security on the >wireless link." The current version of the binding spec seems >to support WEP, too. > I think Charles already addressed this. >Section 6.1: The text about "Local MAC", "Remote MAC", and "Split MAC" >doesn't seem to match the other documents. E.g., there's no "Remote MAC" >in the other documents, and description of "Local MAC" doesn't quite >match the description in IEEE 802.11 binding. See RFC4118. >The document would benefit from some discussion about authorization. >Especially if WTPs/ACs have manufacturer-issued certificates installed >in factory, everyone can easily authenticate everyone else. And with >DHCP AC option, this could "zero configuration" for WTPs -- except >that this wouldn't be secure: WTP (and AC) needs some configuration >to know who is the *right* AC (who are the *right* WTPs). I believe you attended the lunch with Sam where this was discussed. We've explicitly deferred certificate-related authn/authz discussion for now so that we can get these specs published in a meaningful timeframe, although we do discuss validating the EKU bits and MAC address for this. This is the classic "camel's nose" problem: if you attempt to add text that addresses this more fully, where do you stop? I don't think we want to open this can of worms just now. At Sam's request, we added some cert-related clarifications, but I think we all agreed to stop there. > >Editorial nits: > >Section 9.2: the section title includes "Rootkit installation": is >this in right place, or should it be in Section 9.3? > It definitely belongs in 9.2, as this would be an attacker objective for decentralized (802.11) encryption scenarios. It could also be referenced separately in 9.3. It's straightforward to modify the section header to accommodate this. --Scott >Best regards, >Pasi >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/capwap > >Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 30 08:08:27 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5A1528C370 for ; Wed, 30 Jul 2008 08:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxR8QzguIKOl for ; Wed, 30 Jul 2008 08:08:26 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 943FD28C363 for ; Wed, 30 Jul 2008 08:08:26 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 11555433FE4 for ; Wed, 30 Jul 2008 08:08:42 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id E0A4644011D for ; Wed, 30 Jul 2008 08:08:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6D7EB34AC09A for ; Wed, 30 Jul 2008 08:08:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id F3F7C34AC071 for ; Wed, 30 Jul 2008 08:07:58 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.105.134 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 30 Jul 2008 08:07:58 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6UF7cqS024859; Wed, 30 Jul 2008 10:07:52 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 18:06:17 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 18:06:11 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 18:06:08 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72013BB191@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2062CB352@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 152: Need crypto protocol agility Thread-Index: AcjxV1TuKDcm1R7uTwmRveK0CNpjpQAO+SoAADB7ToA= References: <4FF84B0BC277FF45AA27FE969DD956A2062CAF53@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2062CB352@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 30 Jul 2008 15:06:11.0847 (UTC) FILETIME=[CDC57170:01C8F255] X-Nokia-AV: Clean Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 152: Need crypto protocol agility 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 After talking with Tim, I think using MD5 (and not having agility) is acceptable in this context -- but the document needs to explain why a cryptographically secure hash function isn't needed in this particular place (e.g. in security considerations section). (Also, the text should just say "A 16-octet MD5 hash of the image" and have reference to RFC 1321; the pseudo-code is confusing since e.g. the variable names in different parts of it don't match.) Best regards, Pasi > -----Original Message----- > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: 29 July, 2008 18:53 > To: Margaret Wasserman > Cc: capwap@frascone.com; Eronen Pasi (Nokia-NRC/Helsinki) > Subject: RE: [Capwap] Issue 152: Need crypto protocol agility > > Pasi, are you OK with this? > > PatC > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Tuesday, July 29, 2008 1:44 AM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com; Pasi.Eronen@nokia.com > Subject: Re: [Capwap] Issue 152: Need crypto protocol agility > > I agree with Pat's reasoning about this being a non-security- > sensitive > checksum and would prefer not to change this section to add hash > agility. > > Margaret > > > On Jul 28, 2008, at 7:48 PM, Pat Calhoun (pacalhou) wrote: > > > All, > > > > Pasi's comment is: > > > > Section 4.6.29: Using MD5 in a new protocol, and not providing > > algorithm > > agility for moving to new algorithms, is probably not > such a great > > idea > > > > Specifically, the text currently looks like: > > > > > > 4.6.29. Image Information > > > > The Image Information message element is present in the > Image Data > > Response message sent by the AC to the WTP and 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 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | File Size > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Hash > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Hash > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Hash > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Hash > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Type: 29 for Image Information > > > > Length: 20 > > > > File Size: A 32-bit value containing the size of the file, in > > bytes, that will be transferred by the AC to the WTP. > > > > Hash: A 16 octet hash of the image. The hash is computed using > > MD5, using the following pseudo-code: > > > > #include > > CapwapCreateHash(char *hash, char *image, int image_len) > > { > > MD_CTX context; > > > > MDInit (&context); > > MDUpdate (&context, buffer, len); > > MDFinal (hash, &context); > > } > > > > > > Certainly, it is possible to create a new field immediately > following > > the File Size field, called Algorithm Identifier. This field would > > dictate the alg used in the generation of the Hash. This change is > > fairly simple and straightforward. > > > > ... But. There are two things that I'd like to raise here. > > > > 1. The hash is not created for security purposes, but rather for > > validation purposes. So I question whether we really need to worry > > about > > MD5 not being OK when creating a hash that is used to validate the > > contents. Even if MD5 was/is compromised, the purpose of this hash > > does not compromise anything. In fact, notice there is no "secret" > > used here either. So nothing is at risk. > > > > 2. This change would break backward CAPWAP interoperability. > > > > Because of issue number two (2), I'd like to get the WG's > opinion on > > whether this change would be addressed, or rejected. > > > > Pasi, any comments on this? > > > > PatC > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 30 12:21:14 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 968843A6B76 for ; Wed, 30 Jul 2008 12:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.677 X-Spam-Level: X-Spam-Status: No, score=-3.677 tagged_above=-999 required=5 tests=[AWL=-1.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMHn5Gryl9GX for ; Wed, 30 Jul 2008 12:21:13 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 8E0533A6903 for ; Wed, 30 Jul 2008 12:21:13 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6F0DC43A6E2 for ; Wed, 30 Jul 2008 12:21:29 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 90B64440109 for ; Wed, 30 Jul 2008 12:21:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 522D934AC092 for ; Wed, 30 Jul 2008 12:21:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3F26834AC081 for ; Wed, 30 Jul 2008 12:21:16 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.105.134 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 30 Jul 2008 12:21:16 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6UJKdQ9017179; Wed, 30 Jul 2008 14:21:08 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 22:20:33 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 22:20:29 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 22:20:28 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72013BB23E@vaebe104.NOE.Nokia.com> In-Reply-To: <28330555.1217428798174.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Last call comments for capwap-threat-analysis-01 Thread-Index: AcjyUi02JiOkJc0sRdGHaT+c4BEQFQAJekTg References: <28330555.1217428798174.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> From: To: , X-OriginalArrivalTime: 30 Jul 2008 19:20:29.0488 (UTC) FILETIME=[5408B300:01C8F279] X-Nokia-AV: Clean Cc: capwap@frascone.com Subject: Re: [Capwap] Last call comments for capwap-threat-analysis-01 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 Scott G. Kelly wrote: > Some comments inline below... > > Pasi.Eronen wrote: > >Couple of comments/observations about capwap-threat-analysis-01: > > > >There seem to be couple of places where this document isn't > >completely in sync with the protocol/binding documents. > >In particular, the following two places: > > > >Section 4.2, "The current CAPWAP binding for IEEE 802.11 only > >supports the use of IEEE 802.11i [80211I] security on the > >wireless link." The current version of the binding spec seems > >to support WEP, too. > > I think Charles already addressed this. Right; I think we can say that "the binding supports using WEP, but doing so has so many other security problems we don't bother discussing WEP in this document" (or something more polite along those lines :-). > >Section 6.1: The text about "Local MAC", "Remote MAC", and "Split > >MAC" doesn't seem to match the other documents. E.g., there's no > >"Remote MAC" in the other documents, and description of "Local MAC" > >doesn't quite match the description in IEEE 802.11 binding. > > See RFC4118. Thanks for the pointer; however, since this document is a threat analysis for CAPWAP IEEE 802.11 binding, it should be aligned with the capwap-protocol-binding-ieee802 document, not RFC 4118. > >The document would benefit from some discussion about > >authorization. Especially if WTPs/ACs have manufacturer-issued > >certificates installed in factory, everyone can easily authenticate > >everyone else. And with DHCP AC option, this could "zero > >configuration" for WTPs -- except that this wouldn't be secure: WTP > >(and AC) needs some configuration to know who is the *right* AC > >(who are the *right* WTPs). > > I believe you attended the lunch with Sam where this was > discussed. We've explicitly deferred certificate-related authn/authz > discussion for now so that we can get these specs published in a > meaningful timeframe, although we do discuss validating the EKU bits > and MAC address for this. This is the classic "camel's nose" > problem: if you attempt to add text that addresses this more fully, > where do you stop? > > I don't think we want to open this can of worms just now. At > Sam's request, we added some cert-related clarifications, but > I think we all agreed to stop there. Trying to *solve* these problems would probably open a can of worms, but I wasn't proposing that -- just accurately describing what is solved and what isn't. (That shouldn't be more than couple of paragraphs.) Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 30 12:29:06 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB4523A6862 for ; Wed, 30 Jul 2008 12:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.62 X-Spam-Level: X-Spam-Status: No, score=-3.62 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7t2K0S9Ht9Z for ; Wed, 30 Jul 2008 12:29:05 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id EBCB13A695B for ; Wed, 30 Jul 2008 12:29:05 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7CE951C403AD for ; Wed, 30 Jul 2008 12:29:20 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 0741044015A for ; Wed, 30 Jul 2008 12:29:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C68D234AC023 for ; Wed, 30 Jul 2008 12:29:09 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id BADF834AC087 for ; Wed, 30 Jul 2008 12:29:07 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.230 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 30 Jul 2008 12:29:07 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6UJSuSk014675; Wed, 30 Jul 2008 22:29:02 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 22:28:56 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 22:28:56 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 22:28:55 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72013BB240@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2062CB002@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 156: Need more details on use of DNS for discovery Thread-Index: Acjw7k+CFmHJVrthTkC9sgWe7odDLwBixyKw References: <4FF84B0BC277FF45AA27FE969DD956A2062CB002@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 30 Jul 2008 19:28:56.0139 (UTC) FILETIME=[820581B0:01C8F27A] X-Nokia-AV: Clean Subject: Re: [Capwap] Issue 156: Need more details on use of DNS for 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 Pat Calhoun wrote: > > Pasi's comment was: > > Section 3.3: there's a single sentence about DNS-based discovery; > probably slightly more details would be useful. > > Well... There's not much else we can say, but I am proposing the > following text In hopes that it will provide more clarity to the > implementor. > > > 3.3. AC Discovery > [...] > DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one > or more AC addresses. A WTP that wishes to make use of DNS > SHOULD use the format described in [RFC2782]. The recommended > format for a lookup would be _capwap._udp.example.com. > I have some trouble parsing the 'The DNS name "CAPWAP-AC-Address" MAY be resolvable...' part. It seems to be suggesting doing a DNS query for DNS name "CAPWAP-AC-Address" -- or in other words, defining a new Top-Level Domain. That probably isn't a good idea. The two latter sentences are also leaving awfully lot of details to the implementor -- RFC2782 has specific requirements about the labels etc. (E.g. RFC 3861 has much more text about using SRV records for another purpose.) Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 30 13:02:40 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E80B33A685C for ; Wed, 30 Jul 2008 13:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zs-iRVmhLFW5 for ; Wed, 30 Jul 2008 13:02:39 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 021293A68AB for ; Wed, 30 Jul 2008 13:02:38 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C347043A691 for ; Wed, 30 Jul 2008 13:02:52 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id B0A4D4400FD for ; Wed, 30 Jul 2008 13:02:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 31CA834AC064 for ; Wed, 30 Jul 2008 13:02:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5C39C34AC04D for ; Wed, 30 Jul 2008 13:02:33 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 30 Jul 2008 13:02:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,281,1215388800"; d="scan'208";a="70633697" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 30 Jul 2008 20:01:27 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6UK1RDe014077; Wed, 30 Jul 2008 13:01:27 -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.13.8/8.13.8) with ESMTP id m6UK1Rga015192; Wed, 30 Jul 2008 20:01:27 GMT 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, 30 Jul 2008 13:01:27 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 13:01:19 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20632FC22@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 166: Various IANA Issues Thread-Index: AcjyfwiGWFFYbM34RwGLIXgw/+Uu9w== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 30 Jul 2008 20:01:27.0219 (UTC) FILETIME=[0CF4B030:01C8F27F] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 166: Various IANA Issues 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 Pasi's comment was: Section 15: Even if the well-known port numbers have already been allocated, it would be good to say they've been allocated by IANA. Section 15: needs to cite RFC 5226 for the "Standards Action" policy. Section 15: RFC 5226 says that documents requesting creation of new registries MUST include certain instructions for IANA (RFC 5226 Section 4.2) -- many of the details are currently missing. 15. IANA Considerations This section details the actions to be taken by IANA during the publication of the specification. There are numerous registries that need to be created, and the contents, document action (see [RFC5226], and registry format are all included below. Note that in cases where bit fields are referred to, the bit numbering is left to right, where the leftmost bit is labelled as bit zero (0). 15.1. Multicast Address This document requires a new organization local multicast address called the "All ACs multicast address" from the IPv6 multicast address registry [to be removed upon publication http://www.iana.org/assignments/ipv6-multicast-addresses]. The new multicast address is to be inserted in Section 3.3. 15.2. UDP Port This document requires a two UDP Ports organization local multicast address from the registered port numbers registry [to be removed upon publication http://www.iana.org/assignments/port-numbers]. The new UDP Ports numbers have already been assigned and can be found in Section 3.1. The following values are being registered: Keyword Decimal Description References ------- ------- ----------- ---------- capwap-control 5246/udp CAPWAP Control Protocol This Document capwap-data 5247/udp CAPWAP Data Protocol This Document 15.3. CAPWAP Message Types The Message Type field in the CAPWAP header (see Section 4.5.1.1) is used to identify the operation performed by the message. There are multiple namespaces, which is identified via the first three octets of the field containing the IANA Enterprise Number [RFC5226]. IANA will create and maintain the CAPWAP Message Types registry for all message types whose Enterprise Number is set to zero (0). The namespace is 32 bits (0-4294967295), where the value of zero (0) is reserved and must not be assigned. The values one (1) through 26 are allocated in this specification, and can be found in Section 4.5.1.1. Any new assignments of a CAPWAP Message Type, whose Enterprise Number is set to zero (0) requires a Standards Action. The format of the registry to be maintained by IANA has the following format: CAPWAP Control Message Message Type Reference Calhoun, Editor, et al. Expires January 31, 2009 [Page 146] Internet-Draft CAPWAP Protocol Specification July 2008 Value 15.4. CAPWAP Header Flags The Flags field in the CAPWAP header (see Section 4.3) is 9 bits in length and is used to identify any special treatment related to the message. This specification defines bits zero (0) through five (5), while bits six (6) through eight (8) are reserved. There are currently three unused, reserved bits which are managed by IANA and whose assignment requires a Standard Action. IANA will create the CAPWAP Header Flags registry, whose format is: Flag Field Name Bit Position Reference 15.5. CAPWAP Control Message Flags The Flags field in the CAPWAP Control Message header (see Section 4.5.1.4) is used to identify any special treatment related to the control message. There are currently eight (8) unused, reserved bits. These bits whose assignment is managed by IANA and requires a Standards Action. IANA will create the CAPWAP Control Message Flags registry, whose format is: Flag Field Name Bit Position Reference 15.6. CAPWAP Control Message Type The Type field in the CAPWAP Control Message header (see Section 4.6) is used to identify the data being transported. The namespace is 32 bits (0-4294967295), where the value of zero (0) is reserved and must not be assigned. The values one (1) through 52 are allocated in this specification, and can be found in Section 4.5.1.1. This namespace is managed by IANA and assignments require a Standards Action. IANA will create the CAPWAP Control Message Type registry, whose format is: CAPWAP Message Element Type Value Reference 15.7. Wireless Binding Identifiers The Wireless Binding Identifier (WBID) field in the CAPWAP header (see Section 4.3) is used to identify the wireless technology associated with the packet. Due to the limited address space available, a new WBID request requires Standards Action. Calhoun, Editor, et al. Expires January 31, 2009 [Page 147] Internet-Draft CAPWAP Protocol Specification July 2008 15.8. AC Security Types The Security field in the AC Descriptor message element (see Section 4.6.1) is 8 bits in length and used to identify the authentication methods available on the AC. This specification defines bits five (5) and six (6), while bits zero (0) through four (4) as well as bit seven (7) are reserved and unused. These reserved bits are managed by IANA and assignment requires a Standards Action. IANA will create the AC Security Types registry, whose format is: AC Security Type Bit Position Reference 15.9. AC DTLS Policy The DTLS Policy field in the AC Descriptor message element (see Section 4.6.1) is 8 bits in length and used to identify whether the CAPWAP Data Channel is to be secured. This specification defines bits five (5) and six (6), while bits zero (0) through four (4) as well as bit seven (7) are reserved and unused. These reserved bits are managed by IANA and assignment requires a Standards Action. IANA will create the AC DTLS Policy registry, whose format is: AC DTLS Policy Bit Position Reference 15.10. AC Information Type The Information Type field in the AC Descriptor message element (see Section 4.6.1) is used to represent information about the AC. The namespace is 16 bits (0-65535), where the value of zero (0) is reserved and must not be assigned. The values four (4) and five (5) are allocated in this specification, and can be found in Section 4.6.1. This namespace is managed by IANA and assignments require a Standards Action. IANA will create the AC Information Type registry, whose format is: AC Information Type Type Value Reference 15.11. CAPWAP Transport Protocol Types The Transport field in the CAPWAP Transport Protocol message element (see Section 4.6.15) is used to identify the transport to use for the CAPWAP Data Channel. The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1) and two (2) are allocated in this specification, and can be found in Section 4.6.15. This namespace is managed by IANA and assignments require a Standards Action. IANA will create the CAPWAP Transport Protocol Types registry, whose format is: Calhoun, Editor, et al. Expires January 31, 2009 [Page 148] Internet-Draft CAPWAP Protocol Specification July 2008 CAPWAP Transport Protocol Type Type Value Reference 15.12. Data Transfer Type The Data Type field in the Data Transfer Data message element (see Section 4.6.16) and Image Data message element (see Section 4.6.27) is used to provide information about the data being carried. The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1), two (2) and five (5) are allocated in this specification, and can be found in Section 4.6.16. This namespace is managed by IANA and assignments require a Standards Action. IANA will create the Data Transfer Type registry, whose format is: Data Transfer Type Type Value Reference 15.13. Data Transfer Mode The Data Mode field in the Data Transfer Data message element (see Section 4.6.16) and Data Transfer Mode message element (see Section 15.13) is used to provide information about the data being carried. The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1) and two (2) are allocated in this specification, and can be found in Section 15.13. This namespace is managed by IANA and assignments require a Standards Action. IANA will create the Data Transfer Mode registry, whose format is: Data Transfer Mode Type Value Reference 15.14. Discovery Types The Discovery Type field in the Discovery Type message element (see Section 4.6.23) is used by the WTP to indicate to the AC how it was discovered. The namespace is 8 bits (0-255). The values zero (0) through four (4) are allocated in this specification, and can be found in Section 4.6.23. This namespace is managed by IANA and assignments require a Standards Action. IANA will create the Discovery Types registry, whose format is: Discovery Types Type Value Reference 15.15. Radio Admin State The Radio Admin field in the Radio Administrative State message element (see Section 4.6.34) is used by the WTP to represent the state of its radios. The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values Calhoun, Editor, et al. Expires January 31, 2009 [Page 149] Internet-Draft CAPWAP Protocol Specification July 2008 one (1) and two (2) are allocated in this specification, and can be found in Section 4.6.34. This namespace is managed by IANA and assignments require a Standards Action. IANA will create the Radio Admin State registry, whose format is: Radio Admin State Type Value Reference 15.16. Radio Operational State The State field in the Radio Operational State message element (see Section 4.6.35) is used by the WTP to represent the operational state of its radios. The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1) and two (2) are allocated in this specification, and can be found in Section 4.6.35. This namespace is managed by IANA and assignments require a Standards Action. IANA will create the Radio Operational State registry, whose format is: Radio Operational State Type Value Reference 15.17. Radio Failure Causes The Cause field in the Radio Operational State message element (see Section 4.6.35) is used by the WTP to represent the reason why a radio may have failed. The namespace is 8 bits (0-255), where the value of zero (0) through three (3) are allocated in this specification, and can be found in Section 4.6.35. This namespace is managed by IANA and assignments require a Standards Action. IANA will create the Radio Failure Causes registry, whose format is: Radio Failure Causes Type Value Reference 15.18. Result Code The Result Code field in the Result Code message element (see Section 4.6.36) is used to indicate the success, or failure, of a CAPWAP control message. The namespace is 32 bits (0-4294967295), where the value of zero (0) through 22 are allocated in this specification, and can be found in Section 4.6.36. This namespace is managed by IANA and assignments require a Standards Action. IANA will create the Result Code registry, whose format is: Result Code Type Value Reference Calhoun, Editor, et al. Expires January 31, 2009 [Page 150] Internet-Draft CAPWAP Protocol Specification July 2008 15.19. Returned Message Element Reason The Reason field in the Returned Message Element message element (see Section 4.6.37) is used to indicate the reason why a message element was not processed successfully. The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1) through four (4) are allocated in this specification, and can be found in Section 4.6.37. This namespace is managed by IANA and assignments require a Standards Action. IANA will create the Returned Message Element Reason registry, whose format is: Returned Message Element Reason Type Value Reference 15.20. WTP Board Data Type The Board Data Type field in the WTP Board Data message element (see Section 4.6.41) is used to represent information about the WTP hardware. The namespace is 16 bits (0-65535), where the value of zero (0) through four (4) are allocated in this specification, and can be found in Section 4.6.41. This namespace is managed by IANA and assignments require a Standards Action. IANA will create the WTP Board Data Type registry, whose format is: WTP Board Data Type Type Value Reference 15.21. WTP Descriptor Type The Descriptor Type field in the WTP Descriptor message element (see Section 4.6.42) is used to represent information about the WTP software. The namespace is 16 bits (0-65535), where the value of zero (0) through three (3) are allocated in this specification, and can be found in Section 4.6.42. This namespace is managed by IANA and assignments require a Standards Action. IANA will create the WTP Board Data Type registry, whose format is: WTP Descriptor Type Type Value Reference 15.22. WTP Fallback Mode The Mode field in the WTP Fallback message element (see Section 4.6.43) is used to indicate to the WTP the type of AC fallback mechanism it should employ. The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1) and two (2) are allocated in this specification, and can be found in Section 4.6.43. This namespace is managed by IANA and assignments require a Standards Action. IANA will create the WTP Fallback Mode registry, whose format is: Calhoun, Editor, et al. Expires January 31, 2009 [Page 151] Internet-Draft CAPWAP Protocol Specification July 2008 WTP Fallback Mode Type Value Reference 15.23. WTP Frame Tunnel Mode The Tunnel Type field in the WTP Frame Tunnel Mode message element (see Section 4.6.44) is 8 bits and is used to indicate the type of tunneling to use between the WTP and the AC. This specification defines bits four (4) through six (6), while bits zero (0) through four (4) as well as bit seven (7) are reserved and unused. These reserved bits are managed by IANA and assignment requires a Standards Action. IANA will create the AC DTLS Policy registry, whose format is: WTP Frame Tunnel Mode Bit Position Reference 15.24. WTP MAC Type The MAC Type field in the WTP MAC Type message element (see Section 4.6.45) is used to indicate the type of MAC to use in tunneled frames between the WTP and the AC. The namespace is 8 bits (0-255), where the value of zero (0) through two (2) are allocated in this specification, and can be found in Section 4.6.45. This namespace is managed by IANA and assignments require a Standards Action. IANA will create the WTP MAC Type registry, whose format is: WTP MAC Type Type Value Reference 15.25. WTP Radio Stats Failure Type The Last Failure Type field in the WTP Radio Statistics message element (see Section 4.6.47) is used to indicate the last WTP failure. The namespace is 8 bits (0-255), where the value of zero (0) through three (3) as well as the value 255 are allocated in this specification, and can be found in Section 4.6.47. This namespace is managed by IANA and assignments require a Standards Action. IANA will create the WTP Radio Stats Failure Type registry, whose format is: WTP Radio Stats Failure Type Type Value Reference 15.26. WTP Reboot Stats Failure Type The Last Failure Type field in the WTP Reboot Statistics message element (see Section 4.6.48) is used to indicate the last reboot reason. The namespace is 8 bits (0-255), where the value of zero (0) through five (5) as well as the value 255 are allocated in this specification, and can be found in Section 4.6.48. This namespace is managed by IANA and assignments require a Standards Action. IANA Calhoun, Editor, et al. Expires January 31, 2009 [Page 152] Internet-Draft CAPWAP Protocol Specification July 2008 will create the WTP Reboot Stats Failure Type registry, whose format is: WTP Reboot Stats Failure Type Type Value Reference 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 Wed Jul 30 13:57:41 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FA4E3A69E4 for ; Wed, 30 Jul 2008 13:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZ68d5lqAD6z for ; Wed, 30 Jul 2008 13:57:40 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 5F8053A68C8 for ; Wed, 30 Jul 2008 13:57:40 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6B9BF1C40F64 for ; Wed, 30 Jul 2008 13:57:56 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id C80E5440171 for ; Wed, 30 Jul 2008 13:57:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id A4BE334AC083 for ; Wed, 30 Jul 2008 13:57:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id B613834AC081 for ; Wed, 30 Jul 2008 13:57:38 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 30 Jul 2008 13:57:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,281,1215388800"; d="scan'208";a="70657081" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 30 Jul 2008 20:57:38 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6UKvc71006878; Wed, 30 Jul 2008 13:57:38 -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.13.8/8.13.8) with ESMTP id m6UKvcrD013660; Wed, 30 Jul 2008 20:57:38 GMT 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, 30 Jul 2008 13:57:38 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 13:57:25 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20632FC96@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72013BB191@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 152: Need crypto protocol agility Thread-Index: AcjxV1TuKDcm1R7uTwmRveK0CNpjpQAO+SoAADB7ToAADGhsMA== References: <4FF84B0BC277FF45AA27FE969DD956A2062CAF53@xmb-sjc-235.amer.cisco.com><4FF84B0BC277FF45AA27FE969DD956A2062CB352@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72013BB191@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 30 Jul 2008 20:57:38.0108 (UTC) FILETIME=[E62987C0:01C8F286] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 152: Need crypto protocol agility 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 Ok, sounds good. How about the following? 4.6.29. Image Information The Image Information message element is present in the Image Data Response message sent by the AC to the WTP and 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | File Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hash | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hash | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hash | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hash | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 26 for Image Information Length: 20 File Size: A 32-bit value containing the size of the file, in bytes, that will be transferred by the AC to the WTP. Hash: A 16 octet MD5 hash of the image using the procedures defined in [RFC1321]. [...] 12.1.5. Use of MD5 The Image Information Section 4.6.29) message element makes use of MD5 to compute the hash field. It is important to note that in order to preserve interoperability with existing CAPWAP implementations, it was decided to not provide protocol agility. That said, it is also important to note that the use of MD5 in this context is to create a cryptographically secure hash, but instead to provide a basic checksum value. Therefore, the use of MD5 is not considered a security vulnerability. PatC -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Wednesday, July 30, 2008 8:06 AM To: Pat Calhoun (pacalhou); margaret@thingmagic.com Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 152: Need crypto protocol agility After talking with Tim, I think using MD5 (and not having agility) is acceptable in this context -- but the document needs to explain why a cryptographically secure hash function isn't needed in this particular place (e.g. in security considerations section). (Also, the text should just say "A 16-octet MD5 hash of the image" and have reference to RFC 1321; the pseudo-code is confusing since e.g. the variable names in different parts of it don't match.) Best regards, Pasi > -----Original Message----- > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: 29 July, 2008 18:53 > To: Margaret Wasserman > Cc: capwap@frascone.com; Eronen Pasi (Nokia-NRC/Helsinki) > Subject: RE: [Capwap] Issue 152: Need crypto protocol agility > > Pasi, are you OK with this? > > PatC > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Tuesday, July 29, 2008 1:44 AM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com; Pasi.Eronen@nokia.com > Subject: Re: [Capwap] Issue 152: Need crypto protocol agility > > I agree with Pat's reasoning about this being a non-security- > sensitive checksum and would prefer not to change this section to add > hash agility. > > Margaret > > > On Jul 28, 2008, at 7:48 PM, Pat Calhoun (pacalhou) wrote: > > > All, > > > > Pasi's comment is: > > > > Section 4.6.29: Using MD5 in a new protocol, and not providing > > algorithm > > agility for moving to new algorithms, is probably not > such a great > > idea > > > > Specifically, the text currently looks like: > > > > > > 4.6.29. Image Information > > > > The Image Information message element is present in the > Image Data > > Response message sent by the AC to the WTP and 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 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | File Size > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Hash > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Hash > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Hash > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Hash > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Type: 29 for Image Information > > > > Length: 20 > > > > File Size: A 32-bit value containing the size of the file, in > > bytes, that will be transferred by the AC to the WTP. > > > > Hash: A 16 octet hash of the image. The hash is computed using > > MD5, using the following pseudo-code: > > > > #include > > CapwapCreateHash(char *hash, char *image, int image_len) > > { > > MD_CTX context; > > > > MDInit (&context); > > MDUpdate (&context, buffer, len); > > MDFinal (hash, &context); > > } > > > > > > Certainly, it is possible to create a new field immediately > following > > the File Size field, called Algorithm Identifier. This field would > > dictate the alg used in the generation of the Hash. This change is > > fairly simple and straightforward. > > > > ... But. There are two things that I'd like to raise here. > > > > 1. The hash is not created for security purposes, but rather for > > validation purposes. So I question whether we really need to worry > > about > > MD5 not being OK when creating a hash that is used to validate the > > contents. Even if MD5 was/is compromised, the purpose of this hash > > does not compromise anything. In fact, notice there is no "secret" > > used here either. So nothing is at risk. > > > > 2. This change would break backward CAPWAP interoperability. > > > > Because of issue number two (2), I'd like to get the WG's > opinion on > > whether this change would be addressed, or rejected. > > > > Pasi, any comments on this? > > > > PatC > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/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 Jul 30 14:17:22 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 155AA3A69CF for ; Wed, 30 Jul 2008 14:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6doZHyGCnPDs for ; Wed, 30 Jul 2008 14:17:21 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 4D1D13A6971 for ; Wed, 30 Jul 2008 14:17:21 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 552B91C40FC6 for ; Wed, 30 Jul 2008 14:17:37 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 558FC440171 for ; Wed, 30 Jul 2008 14:17:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 741B33648013 for ; Wed, 30 Jul 2008 14:17:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4CBF7361801D for ; Wed, 30 Jul 2008 14:17:22 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from exchange.tm.thingmagic.com (exchange.tm.thingmagic.com [204.9.221.21]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 30 Jul 2008 14:17:21 -0700 (PDT) Received: from nwilliams-pc1 (10.0.0.175) by exchange.tm.thingmagic.com (10.0.0.9) with Microsoft SMTP Server id 8.1.291.1; Wed, 30 Jul 2008 17:17:21 -0400 From: "Nathan J. Williams" To: "Pat Calhoun (pacalhou)" References: <4FF84B0BC277FF45AA27FE969DD956A2062CAF53@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A2062CB352@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72013BB191@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20632FC96@xmb-sjc-235.amer.cisco.com> Date: Wed, 30 Jul 2008 17:17:30 -0400 In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20632FC96@xmb-sjc-235.amer.cisco.com> (Pat Calhoun's message of "Wed, 30 Jul 2008 16:57:25 -0400") Message-ID: MIME-Version: 1.0 Cc: Margaret Wasserman , "capwap@frascone.com" , "Pasi.Eronen@nokia.com" Subject: Re: [Capwap] Issue 152: Need crypto protocol agility 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 "Pat Calhoun (pacalhou)" writes: > 12.1.5. Use of MD5 > > The Image Information Section 4.6.29) message element makes use of > MD5 to compute the hash field. It is important to note that in order > to preserve interoperability with existing CAPWAP implementations, it > was decided to not provide protocol agility. That said, it is also > important to note that the use of MD5 in this context is to create a ^^^ not > cryptographically secure hash, but instead to provide a basic > checksum value. Therefore, the use of MD5 is not considered a > security vulnerability. > Right? - Nathan _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 30 14:18:03 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3371C3A69CF for ; Wed, 30 Jul 2008 14:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlsv4YqRipJe for ; Wed, 30 Jul 2008 14:18:02 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 656BE3A6840 for ; Wed, 30 Jul 2008 14:18:02 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 42DA91C40FB0 for ; Wed, 30 Jul 2008 14:18:15 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 9B923440171 for ; Wed, 30 Jul 2008 14:17:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 40A083648005 for ; Wed, 30 Jul 2008 14:17:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id EEDEA364800F for ; Wed, 30 Jul 2008 14:17:56 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by mx1.tigertech.net (Postfix) with SMTP for ; Wed, 30 Jul 2008 14:17:56 -0700 (PDT) Received: (qmail 23404 invoked from network); 30 Jul 2008 17:17:54 -0400 Received: from unknown (HELO ?127.0.0.1?) (172.22.23.1) by gumby.elbrysnetworks.com with SMTP; 30 Jul 2008 17:17:54 -0400 Message-ID: <4890DA83.3090604@elbrysnetworks.com> Date: Wed, 30 Jul 2008 17:17:55 -0400 From: "David B. Nelson" User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: capwap@frascone.com References: <4FF84B0BC277FF45AA27FE969DD956A2062CAF53@xmb-sjc-235.amer.cisco.com><4FF84B0BC277FF45AA27FE969DD956A2062CB352@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72013BB191@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20632FC96@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20632FC96@xmb-sjc-235.amer.cisco.com> Subject: Re: [Capwap] Issue 152: Need crypto protocol agility 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 Pat Calhoun wrote: > 12.1.5. Use of MD5 > > The Image Information Section 4.6.29) message element makes use of > MD5 to compute the hash field. It is important to note that in order > to preserve interoperability with existing CAPWAP implementations, it > was decided to not provide protocol agility. That said, it is also > important to note that the use of MD5 in this context is ^ not > to create a > cryptographically secure hash, but instead to provide a basic > checksum value. Therefore, the use of MD5 is not considered a > security vulnerability. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 30 15:00:12 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9955A3A67A6 for ; Wed, 30 Jul 2008 15:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjaaCLleFypf for ; Wed, 30 Jul 2008 15:00:11 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id AF8CD3A67EA for ; Wed, 30 Jul 2008 15:00:11 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 51AE21C40F6B for ; Wed, 30 Jul 2008 15:00:20 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id DD6BC440173 for ; Wed, 30 Jul 2008 15:00:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 9F253364800F for ; Wed, 30 Jul 2008 15:00:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D765D364800A for ; Wed, 30 Jul 2008 15:00:02 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 30 Jul 2008 15:00:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,281,1215388800"; d="scan'208";a="70682205" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 30 Jul 2008 21:59:54 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6ULxsaI021623; Wed, 30 Jul 2008 14:59:54 -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.13.8/8.13.8) with ESMTP id m6ULxsad022839; Wed, 30 Jul 2008 21:59:54 GMT 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, 30 Jul 2008 14:59:53 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 14:59:56 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20632FD02@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 152: Need crypto protocol agility Thread-Index: AcjyiavUZ+SAZ6BdTnKXQO5640D0NgABeWYA References: <4FF84B0BC277FF45AA27FE969DD956A2062CAF53@xmb-sjc-235.amer.cisco.com><4FF84B0BC277FF45AA27FE969DD956A2062CB352@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB72013BB191@vaebe104.NOE.Nokia.com><4FF84B0BC277FF45AA27FE969DD956A20632FC96@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Nathan J. Williams" X-OriginalArrivalTime: 30 Jul 2008 21:59:53.0975 (UTC) FILETIME=[98E99870:01C8F28F] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Margaret Wasserman , capwap@frascone.com, Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 152: Need crypto protocol agility 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 Oh right. Making sure that everyone is awake ;-) PatC -----Original Message----- From: Nathan J. Williams [mailto:nathan.williams@thingmagic.com] Sent: Wednesday, July 30, 2008 2:18 PM To: Pat Calhoun (pacalhou) Cc: Pasi.Eronen@nokia.com; Margaret Wasserman; capwap@frascone.com Subject: Re: [Capwap] Issue 152: Need crypto protocol agility "Pat Calhoun (pacalhou)" writes: > 12.1.5. Use of MD5 > > The Image Information Section 4.6.29) message element makes use of > MD5 to compute the hash field. It is important to note that in order > to preserve interoperability with existing CAPWAP implementations, it > was decided to not provide protocol agility. That said, it is also > important to note that the use of MD5 in this context is to create > a ^^^ not > cryptographically secure hash, but instead to provide a basic > checksum value. Therefore, the use of MD5 is not considered a > security vulnerability. > Right? - Nathan _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 30 15:37:45 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4FFE3A69D5 for ; Wed, 30 Jul 2008 15:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z304R0kA88E7 for ; Wed, 30 Jul 2008 15:37:44 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D8CD43A69EE for ; Wed, 30 Jul 2008 15:37:44 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1A9651C40F7A for ; Wed, 30 Jul 2008 15:38:01 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id F39EF44016F for ; Wed, 30 Jul 2008 15:37:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id BCEDE3648010 for ; Wed, 30 Jul 2008 15:37:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8B04C361800B for ; Wed, 30 Jul 2008 15:37:44 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.72 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 30 Jul 2008 15:37:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,281,1215388800"; d="scan'208";a="91373496" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 30 Jul 2008 22:37:39 +0000 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/8.12.11) with ESMTP id m6UMbdZE013953; Wed, 30 Jul 2008 15:37:39 -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.13.8/8.13.8) with ESMTP id m6UMbdkU007741; Wed, 30 Jul 2008 22:37:39 GMT 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, 30 Jul 2008 15:37:39 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 15:37:40 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20632FD50@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72013BB240@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 156: Need more details on use of DNS for discovery Thread-Index: Acjw7k+CFmHJVrthTkC9sgWe7odDLwBixyKwAAbVHpA= References: <4FF84B0BC277FF45AA27FE969DD956A2062CB002@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72013BB240@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 30 Jul 2008 22:37:39.0561 (UTC) FILETIME=[DF4E9590:01C8F294] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Capwap] Issue 156: Need more details on use of DNS for 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 My apologies, Pasi. I'm not sure what I was thinking when I wrote the text. What I should have sent was: DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or more AC addresses. A WTP that wishes to make use of DNS SHOULD use the format described in [RFC2782]. The recommended format for a lookup would be CAPWAP-AC-Address._udp.example.com. Does that make more sense? PatC -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Wednesday, July 30, 2008 12:29 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: Issue 156: Need more details on use of DNS for discovery Pat Calhoun wrote: > > Pasi's comment was: > > Section 3.3: there's a single sentence about DNS-based discovery; > probably slightly more details would be useful. > > Well... There's not much else we can say, but I am proposing the > following text In hopes that it will provide more clarity to the > implementor. > > > 3.3. AC Discovery > [...] > DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one > or more AC addresses. A WTP that wishes to make use of DNS > SHOULD use the format described in [RFC2782]. The recommended > format for a lookup would be _capwap._udp.example.com. > I have some trouble parsing the 'The DNS name "CAPWAP-AC-Address" MAY be resolvable...' part. It seems to be suggesting doing a DNS query for DNS name "CAPWAP-AC-Address" -- or in other words, defining a new Top-Level Domain. That probably isn't a good idea. The two latter sentences are also leaving awfully lot of details to the implementor -- RFC2782 has specific requirements about the labels etc. (E.g. RFC 3861 has much more text about using SRV records for another purpose.) Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 30 15:42:08 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AF8F3A6B31 for ; Wed, 30 Jul 2008 15:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3VbXgcBnkox for ; Wed, 30 Jul 2008 15:42:07 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 332743A6ADF for ; Wed, 30 Jul 2008 15:42:07 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 75D181C40F6E for ; Wed, 30 Jul 2008 15:42:23 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id EAA72440173 for ; Wed, 30 Jul 2008 15:42:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id B07413808008 for ; Wed, 30 Jul 2008 15:42:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8E6973648014 for ; Wed, 30 Jul 2008 15:42:10 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 30 Jul 2008 15:42:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,281,1215388800"; d="scan'208";a="133722765" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 30 Jul 2008 22:42:06 +0000 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/8.12.11) with ESMTP id m6UMg6gC021311; Wed, 30 Jul 2008 15:42:06 -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.13.8/8.13.8) with ESMTP id m6UMg6cF021951; Wed, 30 Jul 2008 22:42:06 GMT 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.1830); Wed, 30 Jul 2008 15:42:04 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 15:42:06 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20632FD58@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72013BA8AA@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 158: Allocation of WBIDs Thread-Index: AcjxWPPBckiC/dIYR2+hBkqFhpAT4wACFMvQAEz5BoA= References: <4FF84B0BC277FF45AA27FE969DD956A2062CB02E@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72013BA8AA@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 30 Jul 2008 22:42:04.0744 (UTC) FILETIME=[7D5E4C80:01C8F295] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 158: Allocation of WBIDs 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 Correct, Pasi. The current IANA classification requires a Standards track RFC for assignment of WBIDs (and every other namespace in the document). I suspect that if EPCGlobal is using their own Enterprise Number for control message types, then it is less of an issue. However, the message element types are still global, and therefore unless you are using the vendor specific message element, you would need an RFC. So what I'm hearing is remove 802.16, and keep 802.11 and EPCGlobal. We just need to work out the details of the IANA classification. PatC -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Tuesday, July 29, 2008 2:59 AM To: margaret@thingmagic.com; Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 158: Allocation of WBIDs Ok -- but if the intent is to allow CAPWAP bindings (and possibly other types of CAPWAP specifications) to be developed outside IETF Standards Track, then the IANA instructions need to be something else than "Standards Action". Best regards, Pasi > -----Original Message----- > From: ext Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: 29 July, 2008 11:55 > To: Pat Calhoun > Cc: capwap@frascone.com; Eronen Pasi (Nokia-NRC/Helsinki) > Subject: Re: [Capwap] Issue 158: Allocation of WBIDs > > > > > Frankly, I don't care much whether we adopt this proposed > change. The > > IEEE 802.11 binding specification does not include the WBID value, > > so a change would be required for that specification. The bigger > change, I > > suspect, is on the EPCGlobal spec. Of particular note, the > CAPWAP spec > > currently requires a Standards Action to allocate one of these > > numbers, and since the RFID CAPWAP specification is being published > > by EPCGlobal, and not the IETF, I'm not sure how they could get a > > number assigned. > > Margaret, you are closer to this than I am, so do you have any > > recommendations? > > (Wearing my EPCglobal hat) > > The EPCglobal Discovery Configuration and Initialization (DCI) > specification defines a CAPWAP binding for RFID readers. It is very > nearly complete after ~1-1/2 years of work. EPCglobal requires > interoperability testing before they will ratify a standard, and that > testing was completed last week. Final ratification of the EPCglobal > standard is now blocked on getting an RFC number for CAPWAP. > EPCglobal doesn't have any plans to publish DCI as an IETF standards > track document. > > The work in EPCglobal was done based on the CAPWAP WG's agreement to > assign an binding ID for that purpose in the CAPWAP spec. While I > agree that further binding IDs need to be defined in their bindings, I > think it would be pretty late to change the agreement with EPCglobal > now. > > > Finally, removing the IEEE 802.16 from the list is not a problem, > > and I agree that if there is ever a specification that defines the > > use of CAPWAP for 802.16, then the number would be assigned at that > > time. > > That would be fine with me, as the 802.16 binding doesn't exist, > AFAIK. > > 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 Wed Jul 30 15:52:49 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DA193A6893 for ; Wed, 30 Jul 2008 15:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id op4Pjad-rR7G for ; Wed, 30 Jul 2008 15:52:46 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 8CEBB3A69EE for ; Wed, 30 Jul 2008 15:52:45 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CFF351C40F77 for ; Wed, 30 Jul 2008 15:53:01 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 682014400FD for ; Wed, 30 Jul 2008 15:52:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0FC833648013 for ; Wed, 30 Jul 2008 15:52:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id A2CA03648014 for ; Wed, 30 Jul 2008 15:52:48 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 30 Jul 2008 15:52:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,281,1215388800"; d="scan'208";a="70695302" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 30 Jul 2008 22:52:48 +0000 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/8.12.11) with ESMTP id m6UMqmVh005362; Wed, 30 Jul 2008 15:52:48 -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.13.8/8.13.8) with ESMTP id m6UMqmbS016413; Wed, 30 Jul 2008 22:52:48 GMT 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, 30 Jul 2008 15:52:47 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 15:52:47 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20632FD71@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 168: DTLS and Retransmissions Thread-Index: AcjylvyfmZeSOKGfSvGDVi6rh78I9Q== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 30 Jul 2008 22:52:47.0925 (UTC) FILETIME=[FCBBEE50:01C8F296] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Pasi.Eronen@nokia.com, clancy@ltsnet.net Subject: [Capwap] Issue 168: DTLS and Retransmissions 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 Pasi's comment was: Section 2.4.1: "DTLS will never terminate the handshake due to non-responsiveness; instead, DTLS will continue to increase its back-off timer period" While RFC 4347 doesn't specify how long you should continue retransmitting, the intent certainly was not to continue indefinitely. Section 2.4.3 text about DTLS retransmissions is slightly inaccurate; DTLS handshake isn't strictly request/response, and both parties (not just the DTLS client) retransmit based on timers (in some situations). It is unclear to me as to whether these are simply observations, or request for change. That said, I would like either Charles or Scott to reply. 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 Wed Jul 30 16:06:24 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A1C3A6978 for ; Wed, 30 Jul 2008 16:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ss2wZ+gtQLv9 for ; Wed, 30 Jul 2008 16:06:23 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 0ED0A3A67AC for ; Wed, 30 Jul 2008 16:06:23 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5DE7D1C40F60 for ; Wed, 30 Jul 2008 16:06:39 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 5CC6644014D for ; Wed, 30 Jul 2008 16:06:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 34CE0361800B for ; Wed, 30 Jul 2008 16:06:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6EF4B3648005 for ; Wed, 30 Jul 2008 16:06:26 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 30 Jul 2008 16:06:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,281,1215388800"; d="scan'208";a="59655211" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 30 Jul 2008 23:06:24 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6UN6OCZ008065; Wed, 30 Jul 2008 16:06:24 -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.13.8/8.13.8) with ESMTP id m6UN6O68025181; Wed, 30 Jul 2008 23:06:24 GMT 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, 30 Jul 2008 16:06:24 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 16:06:24 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20632FD97@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72013BA889@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Last call comments for capwap-protocol-binding-ieee80211-07 Thread-Index: AcjxWvvYp8NTYNntQ6KnjwjYAMoZswBPcLeg References: <1696498986EFEC4D9153717DA325CB72013BA889@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 30 Jul 2008 23:06:24.0003 (UTC) FILETIME=[E3278D30:01C8F298] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Last call comments for capwap-protocol-binding-ieee80211-07 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 Hi Pasi, Finally over your comments on the base protocol, and just getting around to the binding spec. I will only create issues where needed, and therefore indicated below. Otherwise I will simply address them in this e-mail. > I was under the impression that 802 (or at least 802.11) required (or > assumed) strict in-order delivery -- but perhaps I remember this wrong? > (Obvious, tunneling over arbitrary IP hops doesn't guarantee in-order delivery, and it seems the data channel doesn't > have mechanisms to reorder or drop out-of-order packets.) > > 802.11 header has 4 different addresses, all of which can be different. When doing split MAC with 802.3 frames, the > 802.3 frame contains only two of the addresses; the "Radio MAC Address" field in CAPWAP header contains the third -- > but what about the fourth one? > The document should have some more text about how the WTP processes IEEE 802.11 IEs it receives from the AC. Section > 6.6 talks about copying them to Beacon/Probe Response messages, but it seems that in some cases, the WTP also does some local processing. (I was sort of expecting a list of all IEs, and description of expected WTP processing (possibly none) for them.) Section 6.15: Is this really the PTK (which also includes KCK and KEK, which aren't needed by the WTP since the AC is handling the EAPOL-Key messages -- so probably shouldn't be sent to PTK), or only the TK used for encrypting traffic? Is the binding specified here sufficient for 802.11r as well, or would something more be needed? (I don't know the answer -- but probably the document should tell what it is) Section 6.14 says that packets exceeding this priority are either dropped or "down-tagged" -- but it seems which of these is done depends on WTP (and the AC can't even know what the WTP does). Isn't this problematic for interoperability? Question: Section 4 says the "Destination WLANs" field is used only for multicast/broadcast; how is the destination WLAN determined for unicast? (Is this by mapping destination MAC address to earlier IEEE 802.11 Station messages -- which means a single MAC address can't be in more than one WLAN?) (Perhaps the document should have couple of sentences about this) Question: The WLAN ID is always shown as 8 bits, but it seems some other parts limit the spec to 16 WLANs per WTP Radio. Could a WTP supporting more than 16 WLANs use multiple Radio IDs, or is 16 a hard limit? (Perhaps the document should have couple of sentences about this -- at least saying that WLAN ID is between 0 and 15) Minor clarifications/editorial nits: Section 3: CAPWAP base protocol requires that all Request messages are odd numbers, and Responses even; these aren't. Section 3.1, "sent after the CAPWAP Configuration Update Request message (..) has been received by the WTP" probably means "sent after the CAPWAP Configuration Update Response message has been received by the AC"? Section 5.10: "Station QoS Profile" should be "IEEE 802.11 Station QoS Profile" Section 6.1 and 6.21: are some of these 802.11 information elements optional, or are all of them always included? Section 6.1 and 6.21: what do you put in "Key Status" if you're not using encryption at all? Section 6.21: to avoid repetition of text, I'd suggest simply pointing to existing text in Section 6.1 for field descriptions. Section 6.1 and 6.21: "32 byte Session Key" -- length depends on "Key Length" field, right? Section 6.2/10.6: is the "Combiner" a bit field or enumerated field? (And in the former case, an explicit bit diagram would be very useful to avoid confusion about bit numbering) Section 6.14, 6.20, and 6.22: the 802.1p Tag field should probably be shown as 3 bits in the diagram, to make it unambiguous about which bits are not used. Section 6.15: The sentence "Note that AKM-Only is MAY be set..." would benefit for some clarification -- does 802.11 really drop all unencrypted EAPOL-Key frames if you have an encryption key? (it seems that would cause difficulties when e.g. client reboots -- but I'm not sure what 802.11 does here) Section 6.15: "MUST NOT be sent if the WTP had not specifically advertised support for the requested encryption scheme": would be easier to understand if it said how the WTP advertises this (presumably, the Encryption Capabilities field in the WTP Descriptor Message Element?) Sections 6.20 and 6.22: the DSCP Tag field should probably be shown as 6 bits in the diagram, to make it unambiguous how it's sent in IPv4/IPv6 header (and which bits are unused). Section 6.16, "maximum value of 65535" -- the fields are 32 bits, so probably should be 4294967295? Section 6.20 and 6.22: "if packets are to be DSCP tagged" would benefit of clarifying what packets are meant (I guess it means CAPWAP Data packets sent from the WTP to the AC?). Section 6.22/10.9: is the "Tag Packets" a bit field or enumerated field? (In the former case, an explicit bit diagram would be very useful to avoid confusion about bit numbering.) Section 6.23: "Country Code" field probably should be called "Country String" (since it contains other things than the country code, and it's called "country string" in 802.11), and it should be 3 octets instead of 4. Section 6.23: The description of third octet of Country field doesn't quite match IEEE 802.11 (e.g. 'X' character is missing, and the '255' entry is confusing). Section 6.23: reference [ISO.3166.1984] should be to the latest edition, not 1984 version: [ISO.3166-1] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions - Part 1: Country codes", ISO Standard 3166-1:1997 Section 6.25: an explicit bit diagram would be useful for the "Radio Type" field, since it's not clear whether e.g. "2" really means bit number 2, or perhaps bit number 6 (rest of the text suggests it's the latter). Section 8.1: an explicit bit diagram would be useful (since bit numbering has been somewhat inconsistent in various parts of the spec). Section 8.1: WEP is missing from the list? Section 8.1: there probably should be IANA considerations text about how the remaining bits are allocated. Section 10.2, "defines 27 new Message Types" -> "defines 25 new Message Element Types"? Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jul 30 16:31:24 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0778A3A6939 for ; Wed, 30 Jul 2008 16:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfhFD1UBTNQo for ; Wed, 30 Jul 2008 16:31:22 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id CD5EA3A67E5 for ; Wed, 30 Jul 2008 16:31:22 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 140471C40F49 for ; Wed, 30 Jul 2008 16:31:39 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 950A6440101 for ; Wed, 30 Jul 2008 16:31:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 1774B3618008 for ; Wed, 30 Jul 2008 16:31:30 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 30296364800F for ; Wed, 30 Jul 2008 16:31:28 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 30 Jul 2008 16:31:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,282,1215388800"; d="scan'208";a="133740821" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 30 Jul 2008 23:31:27 +0000 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/8.12.11) with ESMTP id m6UNVQ3a025230; Wed, 30 Jul 2008 16:31:26 -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.13.8/8.13.8) with ESMTP id m6UNVQDJ017346; Wed, 30 Jul 2008 23:31:27 GMT 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, 30 Jul 2008 16:31:26 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 16:31:26 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20632FDC3@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72013BA889@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Last call comments for capwap-protocol-binding-ieee80211-07 Thread-Index: AcjxWvvYp8NTYNntQ6KnjwjYAMoZswBPfGhw References: <1696498986EFEC4D9153717DA325CB72013BA889@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 30 Jul 2008 23:31:26.0799 (UTC) FILETIME=[62E405F0:01C8F29C] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Last call comments for capwap-protocol-binding-ieee80211-07 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 Hi Pasi, Finally over your comments on the base protocol, and just getting around to the binding spec. I will only create issues where needed, and therefore indicated below. Otherwise I will simply address them in this e-mail. > I was under the impression that 802 (or at least 802.11) required (or > assumed) strict in-order delivery -- but perhaps I remember this wrong? > (Obvious, tunneling over arbitrary IP hops doesn't guarantee in-order > delivery, and it seems the data channel doesn't have mechanisms to > reorder or drop out-of-order packets.) The MAC layer will provide guaranteed delivery at the AP, but remember that the air isn't exactly a reliable medium. The AP is then responsible for tunneling the packets. For open or when crypto is provided at the WTP, there are no issues with re-ordering. When crypto is provided at the AC, both TKIP and AES have no ordering requirements, so that is also not an issue. > > 802.11 header has 4 different addresses, all of which can be > different. When doing split MAC with 802.3 frames, the > 802.3 frame contains only two of the addresses; the "Radio MAC > Address" field in CAPWAP header contains the third -- but what about the fourth one? The CAPWAP WG only supports 802.11-2007, and does not support ad-hoc mode (client-client). The very fact that we are providing an alternative way to deploy 802.11 infrastructure means that do not need to support ad hoc mode ;-) > The document should have some more text about how the WTP processes > IEEE 802.11 IEs it receives from the AC. Section > 6.6 talks about copying them to Beacon/Probe Response messages, but it > seems that in some cases, the WTP also does some local processing. (I > was sort of expecting a list of all IEs, and description of expected > WTP processing (possibly none) for them.) There are two mode of operation: 1. Split MAC. In this case, the WTP needs to make sure that the beacons have the proper information. Other than that,the AC handles all of the IEs in the manner described in the 802.11-2007 standard. 2. Local MAC. In this case, the 802.11 management packets are processed in the WTP, as described 2.2.2. In this case, the WTP handles the IEs in the manner described in the 802.11-2007 standard. > > Section 6.15: Is this really the PTK (which also includes KCK and KEK, which aren't needed by the WTP since the AC is > handling the EAPOL-Key messages -- so probably shouldn't be sent to PTK), or only the TK used for encrypting traffic? We send the whole PTK. The WTP simply extracts what it needs and uses it. > > Is the binding specified here sufficient for 802.11r as well, or would something more be needed? (I don't know the > answer -- but probably the document should tell what it is) Given we only support 802.11-2007, we do not worry about 802.11r at this point (or 802.11n), so the answer is yes, more is needed. > > Section 6.14 says that packets exceeding this priority are either dropped or "down-tagged" -- but it seems which of > these is done depends on WTP (and the AC can't even know what the WTP does). > Isn't this problematic for interoperability? Created issue 169. http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue169 > > Question: Section 4 says the "Destination WLANs" field is used only for multicast/broadcast; how is the destination > WLAN determined for unicast? (Is this by mapping destination MAC address to earlier IEEE > 802.11 Station messages -- which means a single MAC address can't be in more than one WLAN?) (Perhaps the document > should have couple of sentences about this) Well... Right. If the packet is destined for a specific host, then the 802.11 packet will include that info. The Destination WLAN is only for multicast/broadcast traffic. Not sure what is missing. > > Question: The WLAN ID is always shown as 8 bits, but it seems some other parts limit the spec to 16 WLANs per WTP > Radio. Could a WTP supporting more than 16 WLANs use multiple Radio IDs, or is 16 a hard limit? (Perhaps the document > should have couple of sentences about this -- at least saying that WLAN ID is between 0 and 15) Created issue 170. http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue170 > > > > Minor clarifications/editorial nits: > > Section 3: CAPWAP base protocol requires that all Request messages are odd numbers, and Responses even; these aren't. Yes, this was raised already and will be addressed in the next rev. > Section 3.1, "sent after the CAPWAP Configuration Update Request message (..) has been received by the WTP" probably > means "sent after the CAPWAP Configuration Update Response message has been received by the AC"? > > Section 5.10: "Station QoS Profile" should be "IEEE 802.11 Station QoS Profile" > > Section 6.1 and 6.21: are some of these 802.11 information elements optional, or are all of them always included? > > Section 6.1 and 6.21: what do you put in "Key Status" if you're not using encryption at all? > > Section 6.21: to avoid repetition of text, I'd suggest simply pointing to existing text in Section 6.1 for field > descriptions. > > Section 6.1 and 6.21: "32 byte Session Key" -- length depends on "Key Length" field, right? > > Section 6.2/10.6: is the "Combiner" a bit field or enumerated field? > (And in the former case, an explicit bit diagram would be very useful to avoid confusion about bit numbering) > > Section 6.14, 6.20, and 6.22: the 802.1p Tag field should probably be shown as 3 bits in the diagram, to make it > unambiguous about which bits are not used. > > Section 6.15: The sentence "Note that AKM-Only is MAY be set..." would benefit for some clarification -- does 802.11 > really drop all unencrypted EAPOL-Key frames if you have an encryption key? (it seems that would cause difficulties > when e.g. client reboots -- but I'm not sure what 802.11 does here) > > Section 6.15: "MUST NOT be sent if the WTP had not specifically advertised support for the requested encryption > scheme": would be easier to understand if it said how the WTP advertises this (presumably, the Encryption Capabilities > field in the WTP Descriptor Message Element?) > > Sections 6.20 and 6.22: the DSCP Tag field should probably be shown as 6 bits in the diagram, to make it unambiguous > how it's sent in > IPv4/IPv6 header (and which bits are unused). > Section 6.16, "maximum value of 65535" -- the fields are 32 bits, so probably should be 4294967295? > > Section 6.20 and 6.22: "if packets are to be DSCP tagged" would benefit of clarifying what packets are meant (I guess > it means CAPWAP Data packets sent from the WTP to the AC?). > > Section 6.22/10.9: is the "Tag Packets" a bit field or enumerated field? > (In the former case, an explicit bit diagram would be very useful to avoid confusion about bit numbering.) > > Section 6.23: "Country Code" field probably should be called "Country String" (since it contains other things than the > country code, and it's called "country string" in 802.11), and it should be 3 octets instead of 4. > > Section 6.23: The description of third octet of Country field doesn't quite match IEEE 802.11 (e.g. 'X' character is > missing, and the '255' > entry is confusing). > > Section 6.23: reference [ISO.3166.1984] should be to the latest edition, not 1984 version: > > [ISO.3166-1] International Organization for Standardization, "Codes > for the representation of names of countries and their > subdivisions - Part 1: Country codes", ISO Standard > 3166-1:1997 > > Section 6.25: an explicit bit diagram would be useful for the "Radio Type" field, since it's not clear whether e.g. > "2" really means bit number 2, or perhaps bit number 6 (rest of the text suggests it's the latter). > > Section 8.1: an explicit bit diagram would be useful (since bit numbering has been somewhat inconsistent in various > parts of the spec). > > Section 8.1: WEP is missing from the list? > > Section 8.1: there probably should be IANA considerations text about how the remaining bits are allocated. > > Section 10.2, "defines 27 new Message Types" -> "defines 25 new Message Element Types"? Given there will be spec changes, created issue 171. http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue171 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 Wed Jul 30 16:31:57 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 231503A67E5 for ; Wed, 30 Jul 2008 16:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.726 X-Spam-Level: X-Spam-Status: No, score=-2.726 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eiwx6OYxjo8x for ; Wed, 30 Jul 2008 16:31:56 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 35BD63A6782 for ; Wed, 30 Jul 2008 16:31:56 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 937991C40F9A for ; Wed, 30 Jul 2008 16:32:12 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 86BD4440101 for ; Wed, 30 Jul 2008 16:31:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5A5D73618004 for ; Wed, 30 Jul 2008 16:31:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 9B30F3648013 for ; Wed, 30 Jul 2008 16:31:39 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 30 Jul 2008 16:31:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,282,1215388800"; d="scan'208";a="59664047" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 30 Jul 2008 23:31:39 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6UNVdQV017848; Wed, 30 Jul 2008 16:31:39 -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.13.8/8.13.8) with ESMTP id m6UNVdGd024301; Wed, 30 Jul 2008 23:31:39 GMT 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.1830); Wed, 30 Jul 2008 16:31:38 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 16:31:38 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20632FDC4@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 169: What to do with QoS tags exceeding maximum Thread-Index: AcjynGndl9dXBah+RG+rRLzs+z7g/A== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 30 Jul 2008 23:31:39.0044 (UTC) FILETIME=[6A307640:01C8F29C] Authentication-Results: sj-dkim-4; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 169: What to do with QoS tags exceeding maximum 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 Pasi's comment was > Section 6.14 says that packets exceeding this priority are either dropped or "down-tagged" -- but it seems which of > these is done depends on WTP (and the AC can't even know what the WTP does). > Isn't this problematic for interoperability? Well... That's a good question. I suppose we could either make a decision in this group, or change the format of the frame in order to allow the AC to communicate to the WTP what behavior it should take. Any preference? If we opt to not change the frame formats, then I would opt for down-tagging. 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 Thu Jul 31 03:25:44 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2BB43A6C61 for ; Thu, 31 Jul 2008 03:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=-0.970, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbsXe-I-SqdP for ; Thu, 31 Jul 2008 03:25:44 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id EC9E43A6C67 for ; Thu, 31 Jul 2008 03:25:43 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DFD9F432924 for ; Thu, 31 Jul 2008 03:25:48 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 9E5624400F9 for ; Thu, 31 Jul 2008 03:25:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 787DA34AC02A for ; Thu, 31 Jul 2008 03:25:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 7D82834AC035 for ; Thu, 31 Jul 2008 03:25:35 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.233 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 31 Jul 2008 03:25:35 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6VAPK5C019725; Thu, 31 Jul 2008 13:25:28 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jul 2008 13:25:23 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jul 2008 13:25:17 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 31 Jul 2008 13:25:20 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720141158F@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20632FD02@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 152: Need crypto protocol agility Thread-Index: AcjyiavUZ+SAZ6BdTnKXQO5640D0NgABeWYAABnrRHA= References: <4FF84B0BC277FF45AA27FE969DD956A2062CAF53@xmb-sjc-235.amer.cisco.com><4FF84B0BC277FF45AA27FE969DD956A2062CB352@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB72013BB191@vaebe104.NOE.Nokia.com><4FF84B0BC277FF45AA27FE969DD956A20632FC96@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20632FD02@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 31 Jul 2008 10:25:17.0527 (UTC) FILETIME=[BA3A0E70:01C8F2F7] X-Nokia-AV: Clean Cc: margaret@thingmagic.com, capwap@frascone.com Subject: Re: [Capwap] Issue 152: Need crypto protocol agility 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 The text could also mention how the image is protected (if it's not MD5), and reverse the order of explanation. Something like this maybe? "The authenticity and integrity of the image file is protected by DTLS, and in this context, MD5 is not used as a cryptographically secure hash, but just as a basic checksum. Therefore, the use of MD5 is not considered a security vulnerability, and no mechanisms for algorithm agility are provided." Best regards, Pasi > -----Original Message----- > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: 31 July, 2008 01:00 > To: Nathan J. Williams > Cc: Eronen Pasi (Nokia-NRC/Helsinki); Margaret Wasserman; > capwap@frascone.com > Subject: RE: [Capwap] Issue 152: Need crypto protocol agility > > Oh right. Making sure that everyone is awake ;-) > > PatC > > -----Original Message----- > From: Nathan J. Williams [mailto:nathan.williams@thingmagic.com] > Sent: Wednesday, July 30, 2008 2:18 PM > To: Pat Calhoun (pacalhou) > Cc: Pasi.Eronen@nokia.com; Margaret Wasserman; capwap@frascone.com > Subject: Re: [Capwap] Issue 152: Need crypto protocol agility > > "Pat Calhoun (pacalhou)" writes: > > > 12.1.5. Use of MD5 > > > > The Image Information Section 4.6.29) message element > makes use of > > MD5 to compute the hash field. It is important to note that in > order > > to preserve interoperability with existing CAPWAP > implementations, > it > > was decided to not provide protocol agility. That said, > it is also > > important to note that the use of MD5 in this context is > to create > > a > ^^^ > not > > > cryptographically secure hash, but instead to provide a basic > > checksum value. Therefore, the use of MD5 is not considered a > > security vulnerability. > > > > Right? > > - Nathan > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 31 10:06:02 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 734523A6D07 for ; Thu, 31 Jul 2008 10:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.723 X-Spam-Level: X-Spam-Status: No, score=-2.723 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOb4m8hxu4cu for ; Thu, 31 Jul 2008 10:06:00 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 6BB7B3A6D00 for ; Thu, 31 Jul 2008 10:06:00 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 10D321C40F98 for ; Thu, 31 Jul 2008 10:06:18 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 60809440121 for ; Thu, 31 Jul 2008 10:06:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2767634AC02B for ; Thu, 31 Jul 2008 10:06:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0117034AC02D for ; Thu, 31 Jul 2008 10:06:00 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 31 Jul 2008 10:05:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208";a="60012311" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 31 Jul 2008 17:05:24 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m6VH5LaZ010114; Thu, 31 Jul 2008 10:05:21 -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.13.8/8.13.8) with ESMTP id m6VH5LRm009859; Thu, 31 Jul 2008 17:05:21 GMT 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, 31 Jul 2008 10:05:19 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 31 Jul 2008 10:05:18 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20633000B@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 171: Pasi nits on binding spec Thread-Index: AcjzL5wHOa8wpdqYQUmSlvTmZmTg1Q== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 31 Jul 2008 17:05:19.0688 (UTC) FILETIME=[9CA12C80:01C8F32F] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 171: Pasi nits on binding 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 > Section 3: CAPWAP base protocol requires that all Request messages are odd > numbers, and Responses even; these aren't. Yes, this was raised already and will be addressed in the next rev. > Section 3.1, "sent after the CAPWAP Configuration Update Request message > (..) has been received by the WTP" probably > means "sent after the CAPWAP Configuration Update Response message has been > received by the AC"? Oh - right. > > Section 5.10: "Station QoS Profile" should be "IEEE 802.11 Station QoS > Profile" Right. > > Section 6.1 and 6.21: are some of these 802.11 information elements > optional, or are all of them always included? Always, since the text states: The inclusion of this message element MUST also include the IEEE 802.11 Information Element message element, containing the following 802.11 IEs: > > Section 6.1 and 6.21: what do you put in "Key Status" if you're not using > encryption at all? Well... Good question. The way it works is that the absence of a key means that the key status field is irrelevant, but perhaps it would be good to define a new "unused" value. However, this *could* create a backward compatibility problem. Alternatively, we could add text that simply states that this field is ignored if the key field has a zero length, and then it really doesn't matter what value was used. OK? > > Section 6.21: to avoid repetition of text, I'd suggest simply pointing to > existing text in Section 6.1 for field > descriptions. Tried that before - had a bug asking for specific text :( > > Section 6.1 and 6.21: "32 byte Session Key" -- length depends on "Key > Length" field, right? Ack! > > Section 6.2/10.6: is the "Combiner" a bit field or enumerated field? > (And in the former case, an explicit bit diagram would be very useful to > avoid confusion about bit numbering) Enumerated - fixed it. Thanks. > > Section 6.14, 6.20, and 6.22: the 802.1p Tag field should probably be shown > as 3 bits in the diagram, to make it > unambiguous about which bits are not used. Well... That would truncate a packet on a non-byte boundary. Do you really believe that would help clear things up? > > Section 6.15: The sentence "Note that AKM-Only is MAY be set..." would > benefit for some clarification -- does 802.11 > really drop all unencrypted EAPOL-Key frames if you have an encryption key? > (it seems that would cause difficulties > when e.g. client reboots -- but I'm not sure what 802.11 does here) When the client reboots, it will re-associate and that will cause the state to change anyhow. If 802.1X is enabled, then the station will need to re-authenticate in order to get to the point where it can transmit data frames. This is normal IEEE 802.11-2007/802.1X behavior - and is very well defined in the existing standards. > > Section 6.15: "MUST NOT be sent if the WTP had not specifically advertised > support for the requested encryption > scheme": would be easier to understand if it said how the WTP advertises > this (presumably, the Encryption Capabilities > field in the WTP Descriptor Message Element?) Got it. Added text at the end of the paragraph: 6.15. IEEE 802.11 Station Session Key The IEEE 802.11 Station Session Key message element is sent when the AC determines that encryption of a station must be performed in the WTP. This message element MUST NOT be present without the IEEE 802.11 Station (see Section 6.13) message element, and MUST NOT be sent if the WTP had not specifically advertised support for the requested encryption scheme, through the WTP Descriptor Message Element's Encryption Capabilities Field (see Section 8.1). > > Sections 6.20 and 6.22: the DSCP Tag field should probably be shown as 6 > bits in the diagram, to make it unambiguous > how it's sent in > IPv4/IPv6 header (and which bits are unused). See above. I think showing fragments of a byte is even harder to understand. I have never seen RFCs to that. > Section 6.16, "maximum value of 65535" -- the fields are 32 bits, so > probably should be 4294967295? Oh - you want to use *that* decimal system ;-) > > Section 6.20 and 6.22: "if packets are to be DSCP tagged" would benefit of > clarifying what packets are meant (I guess > it means CAPWAP Data packets sent from the WTP to the AC?). New text: 6.20. IEEE 802.11 Update Station QoS The IEEE 802.11 Update Station QoS message element is used to change the Quality of Service policy on the WTP for a given station. The QoS tags included in this message element are to be applied to packets received by the station. [...] 6.22. IEEE 802.11 WTP Quality of Service The IEEE 802.11 WTP Quality of Service message element value is sent by the AC to the WTP to communicate quality of service configuration information. The QoS tag included in this message element are to be applied to packets received by the WTP from station on a particular radio. > > Section 6.22/10.9: is the "Tag Packets" a bit field or enumerated field? > (In the former case, an explicit bit diagram would be very useful to avoid > confusion about bit numbering.) Agreed - and I've fixed this to be: 6.22. IEEE 802.11 WTP Quality of Service [...] 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Tag Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [...] Tag Packet: A bit field indicating whether CAPWAP packets should be tagged for QoS purposes. The field has the following format: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Reserved |D|P|U| +-+-+-+-+-+-+-+-+ Reserved: A set of reserved bits for future use. 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. D: When set, this indicates that the CAPWAP packets should be tagged for QoS purposes using DSCP. P: When set, this indicates that the CAPWAP packets should be tagged for QoS purposes using 802.1p. U: When set, this indicates that the CAPWAP packets should be untagged. When set, both the D and P bits MUST NOT be set. > > Section 6.23: "Country Code" field probably should be called "Country > String" (since it contains other things than the > country code, and it's called "country string" in 802.11), and it should be > 3 octets instead of 4. OK, again one key goal through this process is to minimize any interoperability issues with existing implementations, so instead of changing the length of the field, I propose adding the following sentence to the end of the Country String field description: Note that the last byte of the Country String MUST be set to NULL. > > Section 6.23: The description of third octet of Country field doesn't quite > match IEEE 802.11 (e.g. 'X' character is > missing, and the '255' > entry is confusing). Yup - you are absolutely correct. I have fixed it to be: 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. 4. an ASCII 'X' character, if the station is operating under a non-country entity. The first two octets of the non-country entity shall be two ASCII 'XX' characters. I do want to note that this breaks backward interoperability, however I'm not sure I've ever seen an AP that advertises the last option. > > Section 6.23: reference [ISO.3166.1984] should be to the latest edition, not > 1984 version: > > [ISO.3166-1] International Organization for Standardization, "Codes > for the representation of names of countries and their > subdivisions - Part 1: Country codes", ISO Standard > 3166-1:1997 Got it - thanks! > > Section 6.25: an explicit bit diagram would be useful for the "Radio Type" > field, since it's not clear whether e.g. > "2" really means bit number 2, or perhaps bit number 6 (rest of the text > suggests it's the latter). I agree, and I have fixed it to be: 6.25. IEEE 802.11 WTP Radio Information [...] 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 | Radio Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio Type | +-+-+-+-+-+-+-+-+ [...] Radio Type: The type of radio present. Note this is a bit field which is used to specify support for more than a single type of PHY/MAC. The field has the following format: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Reservd|N|G|A|B| +-+-+-+-+-+-+-+-+ Reservd: A set of reserved bits for future use. 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. N: An IEEE 802.11n radioP. G: An IEEE 802.11g radio. A: An IEEE 802.11a radio. B: An IEEE 802.11b radio. Note this makes certain assumptions about the position of the first bit, and I think most people in the past would have assumed what I've done here. However, this was a potential cause of interoperability issue, and therefore could require an implementation to change. > > Section 8.1: an explicit bit diagram would be useful (since bit numbering > has been somewhat inconsistent in various > parts of the spec). Yes, you have a great point. Here is the new text: 8.1. WTP Descriptor Message Element, Encryption Capabilities Field: This specification defines two new bits for the WTP Descriptor's Encryption Capabilities field, as defined in [I-D.ietf-capwap-protocol-specification]. Note that only the bits defined in this specification are described below. The format of the Encryption Capabilities Field is: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | |A|T| | +-+-+-+-+-+-+-+-+ A: WTP supports AES-CCMP, as defined in [IEEE.802-11.2007]. T: WTP supports TKIP and Michael, as defined in [IEEE.802-11.2007] and [WPA], respectively. Again, this MAY have create an interoperability issue since the old text was so vague. It is difficult to determine how people interpreted the old text. > > Section 8.1: WEP is missing from the list? Given that WEP was introduced so long ago, it was just assumed that WTPs support it. However, with TKIP and AES possibly requiring changes to the ASIC, we wanted to allow WTPs to advertise these capabilities. > > Section 8.1: there probably should be IANA considerations text about how the > remaining bits are allocated. I'm have opened issue 172 to track this issue. http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue172 > > Section 10.2, "defines 27 new Message Types" -> "defines 25 new Message > Element Types"? This was fixed when I cleaned up IANA considerations, given the issue you raised on the base spec. 10. IANA Considerations This section details the actions to be taken by IANA during the publication of the specification. There are numerous registries that need to be created, and the contents, document action (see [RFC5226], and registry format are all included below. Note that in cases where bit fields are referred to, the bit numbering is left to right, where the leftmost bit is labelled as bit zero (0). 10.1. CAPWAP Wireless Binding Identifier This specification requires a value assigned from the Wireless Binding Identifier namespace, defined in [I-D.ietf-capwap-protocol-specification]. The value assigned is to be added to Section 2.1. The value of one (1)is highly recommended, as it is used in implementations. 10.2. CAPWAP IEEE 802.11 Message Types This document creates a new sub-registry to the existing CAPWAP Message Type registry, which is defined in [I-D.ietf-capwap-protocol-specification]. IANA will create and maintain the CAPWAP IEEE 802.11 Message Types sub-registry for all message types whose Enterprise Number is set to 13277. The namespace is 32 bits (0-4294967295), where the values 3398911 and 3398912 are reserved and must not be assigned. The values 3398913 and 3398914 are allocated in this specification, and can be found in Section 3. Any new assignments of a CAPWAP IEEE 802.11 Message Type, whose Enterprise Number is set to 13277) requires a Standards Action. The format of the registry to be maintained by IANA has the following format: CAPWAP IEEE 802.11 Message Type Reference Control Message Value 10.3. CAPWAP Control Message Type This specification defines new values to be registered to the existing CAPWAP Control Message Type registry, defined in [I-D.ietf-capwap-protocol-specification]. The values used in this document, 1024 through 1048, as listed in Figure 8 are recommended as implementations already exist that make use of these values. 10.4. IEEE 802.11 Key Status The Key Status field in the IEEE 802.11 Add WLAN message element (see Section 6.1) and IEEE 802.11 Update WLAN message element (see Calhoun, Editor, et al. Expires February 1, 2009 [Page 64] Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 July 2008 Section 6.21) is used to provide information about the status of the keying exchange. This document defines four values, and the remaining values are controlled and maintained by IANA and requires a Standards Action. 10.5. IEEE 802.11 QoS The QoS field in the IEEE 802.11 Add WLAN message element (see Section 6.1) is used to configure a QoS policy for the WLAN. The namespace is 8 bits (0-255), where the values zero (0) through four (4) are allocated in this specification, and can be found in Section 6.1. This namespace is managed by IANA and assignments require a Standards Action. IANA will create the IEEE 802.11 QoS registry, whose format is: IEEE 802.11 QoS Type Value Reference 10.6. IEEE 802.11 Auth Type The Auth Type field in the IEEE 802.11 Add WLAN message element (see Section 6.1) is 8 bits and is used to configure the IEEE 802.11 authentication policy for the WLAN. The namespace is 8 bits (0-255), where the values zero (0) and one (1) are allocated in this specification, and can be found in Section 6.1. This namespace is managed by IANA and assignments require a Standards Action. IANA will create the IEEE 802.11 Auth Type registry, whose format is: IEEE 802.11 Auth Type Type Value Reference 10.7. IEEE 802.11 Antenna Combiner The Combiner field in the IEEE 802.11 Antenna message element (see Section 6.2) is used to provide information about the WTP's antennas. The namespace is 8 bits (0-255), where the values zero (0) and one (1) are allocated in this specification, and can be found in Section 6.2. This namespace is managed by IANA and assignments require a Standards Action. IANA will create the IEEE 802.11 Antenna Combiner registry, whose format is: IEEE 802.11 Antenna Combiner Type Value Reference 10.8. IEEE 802.11 Antenna Selection The Antenna Selection field in the IEEE 802.11 Antenna message element (see Section 6.2) is used to provide information about the WTP's antennas. The namespace is 8 bits (0-255), where the values zero (0) is reserved and used and the values one (1) through four (4) are allocated in this specification, and can be found in Section 6.2. Calhoun, Editor, et al. Expires February 1, 2009 [Page 65] Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 July 2008 This namespace is managed by IANA and assignments require a Standards Action. IANA will create the IEEE 802.11 Antenna Selection registry, whose format is: IEEE 802.11 Antenna Selection Type Value Reference 10.9. IEEE 802.11 Session Key Flags The Flags field in the IEEE 802.11 Station Session Key message element (see Section 6.15) is 16 bits and is used to configure the session key association with the mobile device. This specification defines bits zero (0) and one (1), while bits two (2) through sixteen are reserved. The reserved bits are managed by IANA and whose assignment requires a Standard Action. IANA will create the IEEE 802.11 Session Key Flags registry, whose format is: IEEE 802.11 Station Session Key Bit Position Reference 10.10. IEEE 802.11 Tag Packets The Tag Packets field in the IEEE 802.11 WTP Quality of Service message element (see Section 6.22) is 8 bits and is used to specify how the CAPWAP Data Channel packets are to be tagged. This specification defines bits five (5) through seven (7). The remaining bits are managed by IANA and whose assignment requires a Standard Action. IANA will create the IEEE 802.11 Tag Packets registry, whose format is: IEEE 802.11 Tag Packets Bit Position Reference 10.11. IEEE 802.11 WTP Radio Fail The Type field in the IEEE 802.11 WTP Radio Fail Alarm Indication message element (see Section 6.24) is used to provide information on why a WTP's radio has failed. The namespace is 8 bits (0-255), where the values zero (0) is reserved and unused, while the values one (1) and two (2) are allocated in this specification, and can be found in Section 6.24. This namespace is managed by IANA and assignments require a Standards Action. IANA will create the IEEE 802.11 WTP Radio Fail registry, whose format is: IEEE 802.11 WTP Radio Fail Type Value Reference 10.12. IEEE 802.11 WTP Radio Type The Radio Type field in the IEEE 802.11 WTP Radio Information message element (see Section 6.25) is 8 bits and is used to provide information about the WTP's radio type. This specification defines Calhoun, Editor, et al. Expires February 1, 2009 [Page 66] Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 July 2008 bits five (5) through seven (7). The remaining bits are managed by IANA and whose assignment requires a Standard Action. IANA will create the IEEE 802.11 WTP Radio Type registry, whose format is: IEEE 802.11 WTP Radio Type Bit Position Reference _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 31 10:09:16 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 149A33A6D08 for ; Thu, 31 Jul 2008 10:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGkeANA82g-R for ; Thu, 31 Jul 2008 10:09:15 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 375593A6D0E for ; Thu, 31 Jul 2008 10:09:15 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8524643A24E for ; Thu, 31 Jul 2008 10:09:33 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 3459C4400EE for ; Thu, 31 Jul 2008 10:09:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 26C3634AC02D for ; Thu, 31 Jul 2008 10:09:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D7C3834AC00A for ; Thu, 31 Jul 2008 10:09:16 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 31 Jul 2008 10:09:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208";a="71005865" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 31 Jul 2008 17:09:12 +0000 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/8.12.11) with ESMTP id m6VH9C0u016417; Thu, 31 Jul 2008 10:09:12 -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.13.8/8.13.8) with ESMTP id m6VH9Bxn022533; Thu, 31 Jul 2008 17:09:12 GMT 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, 31 Jul 2008 10:09:11 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 31 Jul 2008 10:09:11 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206330012@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 170: Inconsistent WLAN ID length Thread-Index: AcjzMCaT16zJgWxHTAeB4NpoRtzebg== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 31 Jul 2008 17:09:11.0995 (UTC) FILETIME=[271868B0:01C8F330] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 170: Inconsistent WLAN ID 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="===============0652255739==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============0652255739== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F330.26CB7AC2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F330.26CB7AC2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ------_=_NextPart_001_01C8F330.26CB7AC2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ------_=_NextPart_001_01C8F330.26CB7AC2-- --===============0652255739== 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 --===============0652255739==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 31 10:12:44 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3D53A6D0F for ; Thu, 31 Jul 2008 10:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.716 X-Spam-Level: X-Spam-Status: No, score=-2.716 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yP+ULfnHNKIU for ; Thu, 31 Jul 2008 10:12:43 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2EE673A6C31 for ; Thu, 31 Jul 2008 10:12:43 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C81BF1C41018 for ; Thu, 31 Jul 2008 10:12:55 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 172C644013E for ; Thu, 31 Jul 2008 10:12:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id CBC6434AC076 for ; Thu, 31 Jul 2008 10:12:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D43B934AC0AD for ; Thu, 31 Jul 2008 10:12:25 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 31 Jul 2008 10:12:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208";a="60015612" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 31 Jul 2008 17:12:25 +0000 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/8.12.11) with ESMTP id m6VHCOAq021293; Thu, 31 Jul 2008 10:12: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.13.8/8.13.8) with ESMTP id m6VHCHmZ014026; Thu, 31 Jul 2008 17:12:24 GMT 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); Thu, 31 Jul 2008 10:12:24 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 31 Jul 2008 10:12:23 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20633001F@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 172: How is the WTP Descriptor's Encryption Capabilities defined? Thread-Index: AcjzMJkgfuojjpP+SgySgRFa6gVRZA== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 31 Jul 2008 17:12:24.0085 (UTC) FILETIME=[99970450:01C8F330] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 172: How is the WTP Descriptor's Encryption Capabilities defined? 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 Pasi's comment was: > Section 8.1: there probably should be IANA considerations text about how the > remaining bits are allocated. The actual issue here is given the number of bits this field has (8), are we expecting that a given WTP will advertise the encryption capabilities based on the binding being advertised? This means that every binding spec would be able to define all 8 bits. Of course, this would then create a potentially significant problem if a WTP advertises two separate bindings. Currently, the new text in the binding specification is: 8.1. WTP Descriptor Message Element, Encryption Capabilities Field: This specification defines two new bits for the WTP Descriptor's Encryption Capabilities field, as defined in [I-D.ietf-capwap-protocol-specification]. Note that only the bits defined in this specification are described below. The format of the Encryption Capabilities Field is: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | |A|T| | +-+-+-+-+-+-+-+-+ A: WTP supports AES-CCMP, as defined in [IEEE.802-11.2007]. T: WTP supports TKIP and Michael, as defined in [IEEE.802-11.2007] and [WPA], respectively. Again, as currently specified, this means that bits 4 and 5 cannot be redefined by another binding document. So we have to make a decision of whether: 1. We allow the bits to be defined entirely by the binding specification. Prevents a WTP from supporting two different bindings. 2. We allow the bits to be globally allocated. This allows a WTP to advertise multiple bindings, but it restricts the encryption methods to 8 - for all bindings. 3. Create an interoperability issue by removing the encryption capabilities field in the base document (or leave the field but mark it reserved), and require all bindings to define their own encryption capabilities message element. Thoughts? 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 Thu Jul 31 10:15:26 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910423A6D08 for ; Thu, 31 Jul 2008 10:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.713 X-Spam-Level: X-Spam-Status: No, score=-2.713 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SL0pGGfCp3ao for ; Thu, 31 Jul 2008 10:15:25 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 9EB003A6D0E for ; Thu, 31 Jul 2008 10:15:25 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 866761C40F8A for ; Thu, 31 Jul 2008 10:15:42 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id BB51B4400EE for ; Thu, 31 Jul 2008 10:15:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8F6DF34AC018 for ; Thu, 31 Jul 2008 10:15:09 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0000634AC00A for ; Thu, 31 Jul 2008 10:15:06 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 31 Jul 2008 10:15:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208";a="134061886" Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 31 Jul 2008 17:14:29 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id m6VHETUl011363; Thu, 31 Jul 2008 10:14:29 -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.13.8/8.13.8) with ESMTP id m6VHET5S007602; Thu, 31 Jul 2008 17:14:29 GMT 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.1830); Thu, 31 Jul 2008 10:14:28 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 31 Jul 2008 10:14:27 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206330023@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB720141158F@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 152: Need crypto protocol agility Thread-Index: AcjyiavUZ+SAZ6BdTnKXQO5640D0NgABeWYAABnrRHAADmf+QA== References: <4FF84B0BC277FF45AA27FE969DD956A2062CAF53@xmb-sjc-235.amer.cisco.com><4FF84B0BC277FF45AA27FE969DD956A2062CB352@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB72013BB191@vaebe104.NOE.Nokia.com><4FF84B0BC277FF45AA27FE969DD956A20632FC96@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A20632FD02@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720141158F@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 31 Jul 2008 17:14:28.0549 (UTC) FILETIME=[E3C6B750:01C8F330] Authentication-Results: sj-dkim-8; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); Cc: margaret@thingmagic.com, capwap@frascone.com Subject: Re: [Capwap] Issue 152: Need crypto protocol agility 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 Works for me. Made the change. Thanks! PatC -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Thursday, July 31, 2008 3:25 AM To: Pat Calhoun (pacalhou); nathan.williams@thingmagic.com Cc: margaret@thingmagic.com; capwap@frascone.com Subject: RE: [Capwap] Issue 152: Need crypto protocol agility The text could also mention how the image is protected (if it's not MD5), and reverse the order of explanation. Something like this maybe? "The authenticity and integrity of the image file is protected by DTLS, and in this context, MD5 is not used as a cryptographically secure hash, but just as a basic checksum. Therefore, the use of MD5 is not considered a security vulnerability, and no mechanisms for algorithm agility are provided." Best regards, Pasi > -----Original Message----- > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: 31 July, 2008 01:00 > To: Nathan J. Williams > Cc: Eronen Pasi (Nokia-NRC/Helsinki); Margaret Wasserman; > capwap@frascone.com > Subject: RE: [Capwap] Issue 152: Need crypto protocol agility > > Oh right. Making sure that everyone is awake ;-) > > PatC > > -----Original Message----- > From: Nathan J. Williams [mailto:nathan.williams@thingmagic.com] > Sent: Wednesday, July 30, 2008 2:18 PM > To: Pat Calhoun (pacalhou) > Cc: Pasi.Eronen@nokia.com; Margaret Wasserman; capwap@frascone.com > Subject: Re: [Capwap] Issue 152: Need crypto protocol agility > > "Pat Calhoun (pacalhou)" writes: > > > 12.1.5. Use of MD5 > > > > The Image Information Section 4.6.29) message element > makes use of > > MD5 to compute the hash field. It is important to note that in > order > > to preserve interoperability with existing CAPWAP > implementations, > it > > was decided to not provide protocol agility. That said, > it is also > > important to note that the use of MD5 in this context is > to create > > a > ^^^ > not > > > cryptographically secure hash, but instead to provide a basic > > checksum value. Therefore, the use of MD5 is not considered a > > security vulnerability. > > > > Right? > > - Nathan > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jul 31 14:43:49 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3308A3A6D46 for ; Thu, 31 Jul 2008 14:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMt11tARdXmI for ; Thu, 31 Jul 2008 14:43:47 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id C90593A6CE1 for ; Thu, 31 Jul 2008 14:43:47 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 951411C40F8A for ; Thu, 31 Jul 2008 14:44:06 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id CCFAE4400FE for ; Thu, 31 Jul 2008 14:43:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 68C713688038 for ; Thu, 31 Jul 2008 14:43:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 7B0713688039 for ; Thu, 31 Jul 2008 14:43:47 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.72 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 31 Jul 2008 14:43:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,288,1215388800"; d="scan'208";a="91758477" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 31 Jul 2008 21:43:38 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6VLhanf021585; Thu, 31 Jul 2008 14:43:36 -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.13.8/8.13.8) with ESMTP id m6VLhaWL027023; Thu, 31 Jul 2008 21:43:36 GMT 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); Thu, 31 Jul 2008 14:43:35 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 31 Jul 2008 14:43:34 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206330259@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 155: WTP/AC ACL Synchronization Issue Thread-Index: AcjxmZZy6ib2BGvcS82szqLgDUR38gBvEfZw References: <4FF84B0BC277FF45AA27FE969DD956A2062CB358@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Nathan J. Williams" X-OriginalArrivalTime: 31 Jul 2008 21:43:35.0169 (UTC) FILETIME=[7BE96710:01C8F356] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap@frascone.com, Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 155: WTP/AC ACL Synchronization Issue 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 Sorry for the delay, had to talk to some of the developers to make sure that I understood what was going on. So, first, yes, this is a blacklist, and not an ACL. I think we opted to use the term ACL vs. blacklist because of it is less offensive to some. Second, the way it works is that the AC *always* sends an updated list to the WTP at reboot. However, some WTPs *could* conceptually operate without an AC (such as the case where the WAN link between the WTP and the AC is down). Obviously, such WTPs could only operate this way when configured for Local mode. Split mode requires an AC. So the WTP stores the ACL, and can use it even if it reboots and it is unable to connect to the AC. However, it always gets an updated list from the AC when it does connect. So... Given that we've never discussed the concept of a WTP operating without an AC, does it really make sense to leave this functionality in the spec? I think we should pull out the Add/Delete Static message elements, and deal with this in a future rev of the spec if the need arises (because it will likely require more than just some verbage here and there). Thoughts? PatC -----Original Message----- From: Nathan J. Williams [mailto:nathan.williams@thingmagic.com] Sent: Tuesday, July 29, 2008 9:37 AM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com; Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 155: WTP/AC ACL Synchronization Issue "Pat Calhoun (pacalhou)" writes: > The protocol allows the AC to add and delete static MAC ACL > entries, but it > seems the AC can't check what the current ACL entries are. > This means the WTP and AC could get out-of-sync, right? (The AC > can't delete > the unneeded static MAC ACL entries if it doesn't know what they > are.) > > Well.... When a WTP comes up, it provides its configuration to the AC, > and at that point it would include its ACL table. Does it? I don't think the protocol has a message for communicating that state, and there certainly isn't one required or permitted in the Configuration Status message. Rereading around this, I'm reminded that the MAC ACL definition, at least as far as it can be understood from the add/remove message elements, is a little weird. It's a blacklist, and describing that as an ACL seems odd. As a blacklist, I would expect it to be empty by default, but that doesn't help the fact that the AC doesn't know the existing set of static entries. - Nathan _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap