From jari.arkko@piuha.net Tue Nov 8 04:10:13 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E8221F8C6E; Tue, 8 Nov 2011 04:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5nukf8c7ULc; Tue, 8 Nov 2011 04:10:12 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id D2D7821F8B66; Tue, 8 Nov 2011 04:10:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2F7E52CCE0; Tue, 8 Nov 2011 14:10:06 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBBDjaYvJSEC; Tue, 8 Nov 2011 14:10:05 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 9AB792CC61; Tue, 8 Nov 2011 14:10:05 +0200 (EET) Message-ID: <4EB91C1D.5000606@piuha.net> Date: Tue, 08 Nov 2011 14:10:05 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: core , 6lowpan@ietf.org, roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] informal hacking & interop session on Sunday X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 12:10:13 -0000 In the last IETF we organized an informal session to demonstrate & test various smart object related implementations. We are now doing this again for the Taipei IETF. We will meet at 19:00-22:00 on Sunday, November 13th, (room TBD). If you are attending the IETF and have your Internet of Things toys with you (be it 6lowpan, coap, rpl, or anything else) feel free to join. Maybe you'll find someone to test with, or at least get to see other people with interesting implementations. Jari From rgm@labs.htt-consult.com Fri Nov 11 12:01:07 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD5221F8ABB for <6lowpan@ietfa.amsl.com>; Fri, 11 Nov 2011 12:01:07 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEsEMCNG2J89 for <6lowpan@ietfa.amsl.com>; Fri, 11 Nov 2011 12:01:06 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 04D1121F8AE6 for <6lowpan@ietf.org>; Fri, 11 Nov 2011 12:01:01 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 47A6462A78 for <6lowpan@ietf.org>; Fri, 11 Nov 2011 20:00:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PH4AKAPHzH3 for <6lowpan@ietf.org>; Fri, 11 Nov 2011 15:00:10 -0500 (EST) Received: from nc2400.htt-consult.com (adsl-74-176-213-231.asm.bellsouth.net [74.176.213.231]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id 1806C62B9D for <6lowpan@ietf.org>; Fri, 11 Nov 2011 15:00:10 -0500 (EST) Message-ID: <4EBD7EC9.4090705@labs.htt-consult.com> Date: Fri, 11 Nov 2011 15:00:09 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110928 Fedora/3.1.15-1.fc14 Thunderbird/3.1.15 MIME-Version: 1.0 To: 6lowpan@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] IEEE 802.15.9 KMP over 802.15.4 and 802.15.7 approved X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 20:01:07 -0000 The IEEE 802ec approved the PAR this afternoon. The PAR documents are at: https://mentor.ieee.org/802.15/dcn/11/15-11-0613-05-0kmp-key-management-protocol-par.doc https://mentor.ieee.org/802.15/dcn/11/15-11-0665-05-0kmp-kmp-5c-draft.doc We did agree to two procedural changes in the PAR, so there will be a rev 6 posted sometime soon. From jari.arkko@piuha.net Sat Nov 12 04:13:41 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21E521F85FF; Sat, 12 Nov 2011 04:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSacoeXQee3Y; Sat, 12 Nov 2011 04:13:41 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 10AB121F8551; Sat, 12 Nov 2011 04:13:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 500112CCE1; Sat, 12 Nov 2011 14:13:26 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IL0adqpXQ9-0; Sat, 12 Nov 2011 14:13:25 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id F20672CC61; Sat, 12 Nov 2011 14:13:23 +0200 (EET) Message-ID: <4EBE62E2.8010103@piuha.net> Date: Sat, 12 Nov 2011 20:13:22 +0800 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: core , 6lowpan@ietf.org, roll@ietf.org References: <4EB91C1D.5000606@piuha.net> In-Reply-To: <4EB91C1D.5000606@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [6lowpan] informal hacking & interop session on Sunday X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 12:13:41 -0000 The room is 202A. See you there! Jari On 08.11.2011 20:10, Jari Arkko wrote: > In the last IETF we organized an informal session to demonstrate & test various smart object related implementations. We are now doing this again for the Taipei IETF. We will meet at 19:00-22:00 on Sunday, November 13th, (room TBD). If you are attending the IETF and have your Internet of Things toys with you (be it 6lowpan, coap, rpl, or anything else) feel free to join. Maybe you'll find someone to test with, or at least get to see other people with interesting implementations. > > Jari > From czhou@cisco.com Sat Nov 12 23:06:04 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C6921F8A56 for <6lowpan@ietfa.amsl.com>; Sat, 12 Nov 2011 23:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.867 X-Spam-Level: X-Spam-Status: No, score=-4.867 tagged_above=-999 required=5 tests=[AWL=1.731, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZ5euotiWjZ9 for <6lowpan@ietfa.amsl.com>; Sat, 12 Nov 2011 23:06:04 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 050EE21F893C for <6lowpan@ietf.org>; Sat, 12 Nov 2011 23:06:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=czhou@cisco.com; l=5310; q=dns/txt; s=iport; t=1321167964; x=1322377564; h=mime-version:subject:date:message-id:from:to; bh=rcg+/7vopUSAUhuaV60jGPrC6WfWC9PEVHoLRXW/BtM=; b=isVZAEPDL2A713pbBfWxwD6LQsnYt/DYeQmLFU7T5hXJbSFUAAzb94Bk CxJLVmrU6m9nF93yy47nuVWeR2sXM6plTTsi7o55ohxdtmsE8IQywPNsV n0b5S0RFYVk4Oozr9sB4Qw3estOhkdY3aLtNKKhV0/+0yr/83SI6Dr6ca s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FABdsv06tJV2b/2dsb2JhbABBgk2gBYddgQWBdAEEEgEJEQNbASoGGAdXAQQbGp55gSYBnSqGaoIyYwSIEJFijFQ X-IronPort-AV: E=Sophos;i="4.69,502,1315180800"; d="scan'208,217";a="35440495" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 13 Nov 2011 07:06:02 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAD76EDv008261 for <6lowpan@ietf.org>; Sun, 13 Nov 2011 07:06:14 GMT Received: from xmb-rcd-208.cisco.com ([72.163.62.215]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Nov 2011 01:06:02 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: A9aO Cd+7 ChyD CkFV DbXM DxvQ FhJR FylD IFng IPKc IVu0 Ie4A IwDD JWB3 J1Bt KM7S; 1; NgBsAG8AdwBwAGEAbgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {4B280A0D-9703-45AF-99B3-7A7B48088129}; YwB6AGgAbwB1AEAAYwBpAHMAYwBvAC4AYwBvAG0A; Sun, 13 Nov 2011 07:05:59 GMT; QQBuAHkAbwBuAGUAIABhAHQAdABlAG4AZAAgAEkARQBUAEYAIAA4ADIAIABpAG4AIABUAGEAaQBwAGUAaQAgAG4AbwB3AD8A MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA1D2.B3F32B25" x-cr-puzzleid: {4B280A0D-9703-45AF-99B3-7A7B48088129} Content-class: urn:content-classes:message Date: Sun, 13 Nov 2011 01:05:59 -0600 Message-ID: <01A021EBB03D534AB5CE4B620B5F82D104857BBF@XMB-RCD-208.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Anyone attend IETF 82 in Taipei now? Thread-Index: Acyh0rIrDT6J5Dy8Re2tVGAaLAmt2A== From: "Chao Zhou (czhou)" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 13 Nov 2011 07:06:02.0222 (UTC) FILETIME=[B40348E0:01CCA1D2] Subject: [6lowpan] Anyone attend IETF 82 in Taipei now? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 07:06:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA1D2.B3F32B25 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If so, I'd like to have an informal discussion. =20 Thanks. -Chao ------_=_NextPart_001_01CCA1D2.B3F32B25 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If so, I’d like to have an informal = discussion.

 

Thanks.

-Chao

------_=_NextPart_001_01CCA1D2.B3F32B25-- From cabo@tzi.org Sat Nov 12 23:53:31 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6088311E80B2 for <6lowpan@ietfa.amsl.com>; Sat, 12 Nov 2011 23:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.688 X-Spam-Level: X-Spam-Status: No, score=-103.688 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_RECV_IP_061228=0.895, SARE_RECV_SPAM_DOMN0b=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsuuummExoM2 for <6lowpan@ietfa.amsl.com>; Sat, 12 Nov 2011 23:53:30 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9202711E80B0 for <6lowpan@ietf.org>; Sat, 12 Nov 2011 23:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pAD7rLo5029271; Sun, 13 Nov 2011 08:53:21 +0100 (CET) Received: from [192.168.0.237] (61-230-53-8.dynamic.hinet.net [61.230.53.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 397214B3; Sun, 13 Nov 2011 08:53:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <01A021EBB03D534AB5CE4B620B5F82D104857BBF@XMB-RCD-208.cisco.com> Date: Sun, 13 Nov 2011 15:53:14 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <38E0451F-31AE-4714-9D03-BA428C99C1C6@tzi.org> References: <01A021EBB03D534AB5CE4B620B5F82D104857BBF@XMB-RCD-208.cisco.com> To: "Chao Zhou (czhou)" X-Mailer: Apple Mail (2.1251.1) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Anyone attend IETF 82 in Taipei now? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 07:53:31 -0000 I'm here. I'm going to be at the reception today from 1700 to 1900. If you haven't met me, find my picture (and those of many other WG = chairs) at http://www.ietf.org/wg/chair-photos.html Gr=FC=DFe, Carsten On Nov 13, 2011, at 15:05, Chao Zhou (czhou) wrote: > If so, I=92d like to have an informal discussion. > =20 > Thanks. > -Chao > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From zehn.cao@gmail.com Sun Nov 13 07:48:57 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1799421F861E for <6lowpan@ietfa.amsl.com>; Sun, 13 Nov 2011 07:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zhe05nJ1TRKi for <6lowpan@ietfa.amsl.com>; Sun, 13 Nov 2011 07:48:56 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF2021F8560 for <6lowpan@ietf.org>; Sun, 13 Nov 2011 07:48:56 -0800 (PST) Received: by iaeo4 with SMTP id o4so8087482iae.31 for <6lowpan@ietf.org>; Sun, 13 Nov 2011 07:48:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UOT2yBEdrsG5UaZ08ieDelDoLTiYm2OWQmJqF46IQh8=; b=QaHrbBZyg0Ogmtf411FsYgr/ScjUsFPOmGaybQTRJiBBSPgfCnodUFoe7jFOa8i0U0 bYHX63MGlfnVU/sWZZ8cGw4Cc0DPYiAJsHlR4FRHorCArcJ/6IrwUgqoZ5Bl8YfyKdZH k+JGjFuv9cEbJ+Qkby+uZeL8mqnPrf//Xrbrs= MIME-Version: 1.0 Received: by 10.43.45.137 with SMTP id uk9mr8450658icb.52.1321199335427; Sun, 13 Nov 2011 07:48:55 -0800 (PST) Received: by 10.42.164.133 with HTTP; Sun, 13 Nov 2011 07:48:55 -0800 (PST) In-Reply-To: <38E0451F-31AE-4714-9D03-BA428C99C1C6@tzi.org> References: <01A021EBB03D534AB5CE4B620B5F82D104857BBF@XMB-RCD-208.cisco.com> <38E0451F-31AE-4714-9D03-BA428C99C1C6@tzi.org> Date: Sun, 13 Nov 2011 23:48:55 +0800 Message-ID: From: Zhen Cao To: Carsten Bormann Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "Chao Zhou \(czhou\)" , 6lowpan@ietf.org Subject: Re: [6lowpan] Anyone attend IETF 82 in Taipei now? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 15:48:57 -0000 Have you decided the informal meeting time and venue? On Sun, Nov 13, 2011 at 3:53 PM, Carsten Bormann wrote: > I'm here. > > I'm going to be at the reception today from 1700 to 1900. > If you haven't met me, find my picture (and those of many other WG chairs= ) at > > =A0 =A0 =A0 =A0http://www.ietf.org/wg/chair-photos.html > > Gr=FC=DFe, Carsten > > On Nov 13, 2011, at 15:05, Chao Zhou (czhou) wrote: > >> If so, I=92d like to have an informal discussion. >> >> Thanks. >> -Chao >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > --=20 Best regards, Zhen From alper.yegin@yegin.org Sun Nov 13 22:17:57 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A7B11E80BE for <6lowpan@ietfa.amsl.com>; Sun, 13 Nov 2011 22:17:57 -0800 (PST) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emEa9BE2NTik for <6lowpan@ietfa.amsl.com>; Sun, 13 Nov 2011 22:17:56 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC6D11E8094 for <6lowpan@ietf.org>; Sun, 13 Nov 2011 22:17:56 -0800 (PST) Received: from [10.1.1.2] (odakk1.odakk.com [78.111.98.194]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LZzGf-1R2qzB18px-00lL62; Mon, 14 Nov 2011 01:17:52 -0500 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <4EBD7EC9.4090705@labs.htt-consult.com> Date: Mon, 14 Nov 2011 08:17:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7122CCCC-BF56-4A67-B255-DF126BEA495D@yegin.org> References: <4EBD7EC9.4090705@labs.htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1244.3) X-Provags-ID: V02:K0:jR4ceeR1ox3ZUwkgK0yzKYoChjp5yijLvawk9HJWD64 LrYgJVlg6lbhik+E4lylSnHly/xXSOwHtU3Vb9RstnVtaH8CAI 1Yvb5dUb0NWEThn/j1431cdaFuTyjJp/9RsWhQotD+JjsMQm7M onP6gFt4Fn8KF2/iWZIgS/IW+erYyps3QHsePAfccQgW497D40 xWfFEsEgHVZfSsxxqdq32Q6ho9wxQUYRJhz6gNp1M5pcNxagJb 1BHgjPZ564eogLoWMjIbDDuNqGAnmSr7eM7lnNMMxC3OnZhalr OhuHmsQRMvBNG6CV0+9bcYKkiBkgAo7IIGvKfMZvS3tlkShsQo NnWrGhacf4LO2h+733Q1FhkMLJhrSNwzBHJY6tA23 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] IEEE 802.15.9 KMP over 802.15.4 and 802.15.7 approved X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 06:17:57 -0000 Hi Bob, This PAR document still does not refer to IETF's PANA (IETF RFC that is = already adopted by the Zigbee IP spec.) I'm hoping the PAR changes you = are referring are already addressing that. Please let us know. Thanks. Alper =20 On Nov 11, 2011, at 10:00 PM, Robert Moskowitz wrote: > The IEEE 802ec approved the PAR this afternoon. The PAR documents are = at: >=20 > = https://mentor.ieee.org/802.15/dcn/11/15-11-0613-05-0kmp-key-management-pr= otocol-par.doc > = https://mentor.ieee.org/802.15/dcn/11/15-11-0665-05-0kmp-kmp-5c-draft.doc >=20 > We did agree to two procedural changes in the PAR, so there will be a = rev 6 posted sometime soon. >=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From rgm@labs.htt-consult.com Mon Nov 14 08:47:52 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2431F0CAA for <6lowpan@ietfa.amsl.com>; Mon, 14 Nov 2011 08:47:52 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtxjekwBPG64 for <6lowpan@ietfa.amsl.com>; Mon, 14 Nov 2011 08:47:48 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3A11F0C73 for <6lowpan@ietf.org>; Mon, 14 Nov 2011 08:47:48 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 866C662ACE; Mon, 14 Nov 2011 16:47:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zmaM545ksur; Mon, 14 Nov 2011 11:46:59 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [203.69.99.17]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id BFDF562ABE; Mon, 14 Nov 2011 11:46:58 -0500 (EST) Message-ID: <4EC145FC.4030601@labs.htt-consult.com> Date: Tue, 15 Nov 2011 00:46:52 +0800 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110928 Fedora/3.1.15-1.fc14 Thunderbird/3.1.15 MIME-Version: 1.0 To: Alper Yegin References: <4EBD7EC9.4090705@labs.htt-consult.com> <7122CCCC-BF56-4A67-B255-DF126BEA495D@yegin.org> In-Reply-To: <7122CCCC-BF56-4A67-B255-DF126BEA495D@yegin.org> Content-Type: multipart/alternative; boundary="------------050507020807020108020803" Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] IEEE 802.15.9 KMP over 802.15.4 and 802.15.7 approved X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 16:47:52 -0000 This is a multi-part message in MIME format. --------------050507020807020108020803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/14/2011 03:17 PM, Alper Yegin wrote: > > Hi Bob, > > This PAR document still does not refer to IETF's PANA (IETF RFC that > is already adopted by the Zigbee IP spec.) I'm hoping the PAR changes > you are referring are already addressing that. Please let us know. It was a procedural question as to what is 'wanted' here. Strictly IEEE standards or broader interpretation? The 802EC clearified that a broader inclusion was desired so words have been added to point out that Zibgee IP has addressed this within their upper layer. A 'literal' interpretation was that 802.1X does not work over 802.15.4 or 15.7 so there was no comparable standard. Also 802.1 pointed out the need to include the potential need of an Registry Authority (6.1b) and that too was added. The final posted PAR will reflect these two changes. > > Thanks. > > Alper > > > On Nov 11, 2011, at 10:00 PM, Robert Moskowitz wrote: > > > The IEEE 802ec approved the PAR this afternoon. The PAR documents > > are at: > > > > https://mentor.ieee.org/802.15/dcn/11/15-11-0613-05-0kmp-key-management-protocol-par.doc > > > > https://mentor.ieee.org/802.15/dcn/11/15-11-0665-05-0kmp-kmp-5c-draft.doc > > > > We did agree to two procedural changes in the PAR, so there will be > > a rev 6 posted sometime soon. > > > > > > _______________________________________________ 6lowpan mailing > > list 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > > --------------050507020807020108020803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/14/2011 03:17 PM, Alper Yegin wrote:
>
> Hi Bob,
>
> This PAR document still does not refer to IETF's PANA (IETF RFC that
> is already adopted by the Zigbee IP spec.) I'm hoping the PAR changes
> you are referring are already addressing that. Please let us know.

It was a procedural question as to what is 'wanted' here.  Strictly IEEE standards or broader interpretation?  The 802EC clearified that a broader inclusion was desired so words have been added to point out that Zibgee IP has addressed this within their upper layer.  A 'literal' interpretation was that 802.1X does not work over 802.15.4 or 15.7 so there was no comparable standard.

Also 802.1 pointed out the need to include the potential need of an Registry Authority (6.1b) and that too was added.  The final posted PAR will reflect these two changes.

>
> Thanks.
>
> Alper
>
>
> On Nov 11, 2011, at 10:00 PM, Robert Moskowitz wrote:
>
>> The IEEE 802ec approved the PAR this afternoon. The PAR documents
>> are at:
>>
>> https://mentor.ieee.org/802.15/dcn/11/15-11-0613-05-0kmp-key-management-protocol-par.doc
>>
>>
https://mentor.ieee.org/802.15/dcn/11/15-11-0665-05-0kmp-kmp-5c-draft.doc
>>
>> We did agree to two procedural changes in the PAR, so there will be
>> a rev 6 posted sometime soon.
>>
>>
>> _______________________________________________ 6lowpan mailing
>> list 6lowpan@ietf.org
>> https://www.ietf.org/mailman/listinfo/6lowpan
>
>

--------------050507020807020108020803-- From robert.cragie@gmail.com Mon Nov 14 09:30:19 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8F111E8314 for <6lowpan@ietfa.amsl.com>; Mon, 14 Nov 2011 09:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXszm1t+X435 for <6lowpan@ietfa.amsl.com>; Mon, 14 Nov 2011 09:30:15 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2E611E8301 for <6lowpan@ietf.org>; Mon, 14 Nov 2011 09:30:15 -0800 (PST) Received: by vws5 with SMTP id 5so6318739vws.31 for <6lowpan@ietf.org>; Mon, 14 Nov 2011 09:30:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lL92kZVZlTeUU677xsyjdTg6/hid/WUcBJrEnQ/VULM=; b=MAnI42Pvi3UcdLbJKlpkOyVAeEDG87bG6h4DxpKzq4ibZz+iTSudBzJXCXcdQsmP2P 9BRkjAkQ2yd40s8NJcY+/Hwylr1beI6v2zlZppsmrmRDSQk+ulIEububAKrp+Dtqd0aa /m/afzzC7IryCWN2FCsEJZjrAF6OQS14XYX7I= MIME-Version: 1.0 Received: by 10.52.37.165 with SMTP id z5mr35654674vdj.117.1321291813975; Mon, 14 Nov 2011 09:30:13 -0800 (PST) Sender: robert.cragie@gmail.com Received: by 10.220.188.202 with HTTP; Mon, 14 Nov 2011 09:30:13 -0800 (PST) In-Reply-To: <4EC145FC.4030601@labs.htt-consult.com> References: <4EBD7EC9.4090705@labs.htt-consult.com> <7122CCCC-BF56-4A67-B255-DF126BEA495D@yegin.org> <4EC145FC.4030601@labs.htt-consult.com> Date: Mon, 14 Nov 2011 17:30:13 +0000 X-Google-Sender-Auth: NJGyq3cGX7OrvzFrQdppYwJp9Xs Message-ID: From: Robert Cragie To: Robert Moskowitz Content-Type: multipart/alternative; boundary=bcaec51d281a3775c904b1b5394b Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] IEEE 802.15.9 KMP over 802.15.4 and 802.15.7 approved X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 17:30:19 -0000 --bcaec51d281a3775c904b1b5394b Content-Type: text/plain; charset=ISO-8859-1 Bob, I have to say I object to the following statement in the PAR: "Lack of key management support in IEEE Std 802.15.4 and IEEE Std 802.15.7 results in weak keys which is a common avenue for attacking the security system." "results in weak keys" implies this is always the case, which is simply not true. This should be rephrased as "may result in weak keys". Users of 802.15.4 such as ZigBee have put in place a KMP which does not result in weak keys, And I agree with Alper - if you are mentioning IETF and 802.1X, you really have to mention PANA as it is entirely relevant. Robert On Mon, Nov 14, 2011 at 4:46 PM, Robert Moskowitz wrote: > ** > On 11/14/2011 03:17 PM, Alper Yegin wrote: > > > > Hi Bob, > > > > This PAR document still does not refer to IETF's PANA (IETF RFC that > > is already adopted by the Zigbee IP spec.) I'm hoping the PAR changes > > you are referring are already addressing that. Please let us know. > > It was a procedural question as to what is 'wanted' here. Strictly IEEE > standards or broader interpretation? The 802EC clearified that a broader > inclusion was desired so words have been added to point out that Zibgee IP > has addressed this within their upper layer. A 'literal' interpretation > was that 802.1X does not work over 802.15.4 or 15.7 so there was no > comparable standard. > > Also 802.1 pointed out the need to include the potential need of an > Registry Authority (6.1b) and that too was added. The final posted PAR > will reflect these two changes. > > > > > > Thanks. > > > > Alper > > > > > > On Nov 11, 2011, at 10:00 PM, Robert Moskowitz wrote: > > > >> The IEEE 802ec approved the PAR this afternoon. The PAR documents > >> are at: > >> > >> > https://mentor.ieee.org/802.15/dcn/11/15-11-0613-05-0kmp-key-management-protocol-par.doc > >> > >> > https://mentor.ieee.org/802.15/dcn/11/15-11-0665-05-0kmp-kmp-5c-draft.doc > >> > >> We did agree to two procedural changes in the PAR, so there will be > >> a rev 6 posted sometime soon. > >> > >> > >> _______________________________________________ 6lowpan mailing > >> list 6lowpan@ietf.org > >> https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > -- Robert Cragie Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com --bcaec51d281a3775c904b1b5394b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bob,

I have to say I object to the following statement i= n the PAR:

"Lack of key management support in IEEE = Std 802.15.4 and IEEE Std 802.15.7 results in weak keys which is a common a= venue for attacking the security system."

"results in weak keys" implies this is always= the case, which is simply not true. This should be rephrased as "may = result in weak keys". Users of 802.15.4 such as ZigBee have put in pla= ce a KMP which does not result in weak keys,

And I agree with Alper - if you are mentioning IETF and= 802.1X, you really have to mention PANA as it is entirely relevant.
<= div>
Robert

On Mon, Nov 14,= 2011 at 4:46 PM, Robert Moskowitz <rgm@labs.htt-consult.com> wrote:
=20 =20 =20
On 11/14/2011 03:17 PM, Alper Yegin wrote:
>
> Hi Bob,
>
> This PAR document still does not refer to IETF's PANA (IETF RFC that
> is already adopted by the Zigbee IP spec.) I'm hoping the PA= R changes
> you are referring are already addressing that. Please let us know.

It was a procedural question as to what is 'wanted' here.=A0 St= rictly IEEE standards or broader interpretation?=A0 The 802EC clearified that a broader inclusion was desired so words have been added to point out that Zibgee IP has addressed this within their upper layer.=A0 A 'literal' interpretation was that 802.1X does not work over 802= .15.4 or 15.7 so there was no comparable standard.

Also 802.1 pointed out the need to include the potential need of an Registry Authority (6.1b) and that too was added.=A0 The final posted PAR will reflect these two changes.


>
> Thanks.
>
> Alper
>
>
> On Nov 11, 2011, at 10:00 PM, Robert Moskowitz wrote:
>
>> The IEEE 802ec approved the PAR this afternoon. The PAR documents
>> are at:
>>
>> https://mentor.ieee.org/802.15/= dcn/11/15-11-0613-05-0kmp-key-management-protocol-par.doc
>>
>>
https://mentor.ieee.org/802.15/dcn/11/15-11-06= 65-05-0kmp-kmp-5c-draft.doc
>>
>> We did agree to two procedural changes in the PAR, so there will be
>> a rev 6 posted sometime soon.
>>
>>
>> _______________________________________________ 6lowpan mailing
>> list 6= lowpan@ietf.org
>> https://www.ietf.org/mailman/listinfo/6lowpan
>
>


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan




--

= Robert C= ragie

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
 http://www.gridmerge.com


--bcaec51d281a3775c904b1b5394b-- From ben@blindcreek.com Mon Nov 14 11:32:46 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E3321F8B1D for <6lowpan@ietfa.amsl.com>; Mon, 14 Nov 2011 11:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.996 X-Spam-Level: X-Spam-Status: No, score=0.996 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATICB=1.372, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCn1Af+K9hcb for <6lowpan@ietfa.amsl.com>; Mon, 14 Nov 2011 11:32:45 -0800 (PST) Received: from wilson.nswebhost.com (static-6-231-217-209.nocdirect.com [209.217.231.6]) by ietfa.amsl.com (Postfix) with ESMTP id A0F1221F8D3D for <6lowpan@ietf.org>; Mon, 14 Nov 2011 11:32:45 -0800 (PST) Received: from [64.74.213.174] (helo=[192.168.250.11]) by wilson.nswebhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1RQ2Gj-0008K5-08; Mon, 14 Nov 2011 13:32:37 -0600 Message-ID: <4EC16CDB.5010503@blindcreek.com> Date: Mon, 14 Nov 2011 11:32:43 -0800 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.23) Gecko/20110920 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: 6lowpan@ietf.org, Robert Moskowitz References: <4EBD7EC9.4090705@labs.htt-consult.com> <7122CCCC-BF56-4A67-B255-DF126BEA495D@yegin.org> <4EC145FC.4030601@labs.htt-consult.com> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [6lowpan] IEEE 802.15.9 KMP over 802.15.4 and 802.15.7 approved X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 19:32:46 -0000 Excellent points that will make the PAR stronger.

Many on this list have been through the IEEE 802 project process, but for those that may not have it might help to explain the purpose of the PAR, which is to ask IEEE-SA to authorize a new project, in this case a recommended practice. The scope clause defines the direction of the project and can be thought of as the 'normative' part of the PAR.  The other clauses provide the New Standards committee (NesCom) background, and not in any way limitations.   

I see positive potential for the project. As Robert points out there are many security methods applied over and with 802.15 standards and for some (like me) it can be a mystifying topic.  I am looking to TG9 to help.

As currently drafted the scope is not limited to the particular protocols mentioned as examples. The 802.15 operating procedures allow a very open process and input is welcome from all that choose to participate. If/when it is approved the first steps will be to define, within the scope of the project, what specific protocols are relevant to the RP.  I commend Bob for reaching out at this early stage to solicit input on the project, and encourage continued participation.   The experience of those that have used 802.15.4 and other standards in the 802.15 family will be of great value.

So as a potential user of the RP (who isn't qualified to contribute much beyond desire ;-), thanks all for the help on the PAR and I look forward to continued contributions!

-B


Bob,

I have to say I object to the following statement in the PAR:

"Lack of key management support in IEEE Std 802.15.4 and IEEE Std 802.15.7 results in weak keys which is a common avenue for attacking the security system."

"results in weak keys" implies this is always the case, which is simply not true. This should be rephrased as "may result in weak keys". Users of 802.15.4 such as ZigBee have put in place a KMP which does not result in weak keys,

And I agree with Alper - if you are mentioning IETF and 802.1X, you really have to mention PANA as it is entirely relevant.

Robert

On Mon, Nov 14, 2011 at 4:46 PM, Robert Moskowitz <rgm@labs.htt-consult.com> wrote:
On 11/14/2011 03:17 PM, Alper Yegin wrote:
>

> Hi Bob,

>

> This PAR document still does not refer to IETF's PANA (IETF
RFC that

> is already adopted by the Zigbee IP spec.) I'm hoping the PAR
changes

> you are referring are already addressing that. Please let us
know.

It was a procedural question as to what is 'wanted' here.  Strictly IEEE standards or broader interpretation?  The 802EC clearified that a broader inclusion was desired so words have been added to point out that Zibgee IP has addressed this within their upper layer.  A 'literal' interpretation was that 802.1X does not work over 802.15.4 or 15.7 so there was no comparable standard.

Also 802.1 pointed out the need to include the potential need of an Registry Authority (6.1b) and that too was added.  The final posted PAR will reflect these two changes.


>

> Thanks.

>

> Alper

>

>

> On Nov 11, 2011, at 10:00 PM, Robert Moskowitz wrote:

>

>> The IEEE 802ec approved the PAR this afternoon. The PAR
documents

>> are at:

>>

>>
https://mentor.ieee.org/802.15/dcn/11/15-11-0613-05-0kmp-key-management-protocol-par.doc

>>

>>
https://mentor.ieee.org/802.15/dcn/11/15-11-0665-05-0kmp-kmp-5c-draft.doc
>>

>> We did agree to two procedural changes in the PAR, so
there will be

>> a rev 6 posted sometime soon.

>>

>>

>> _______________________________________________ 6lowpan
mailing

>> list 6lowpan@ietf.org

>> https://www.ietf.org/mailman/listinfo/6lowpan

>

>


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan




--

Robert Cragie

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
 http://www.gridmerge.com



_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan

From cabo@tzi.org Mon Nov 14 21:43:00 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF0511E80C4; Mon, 14 Nov 2011 21:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiNNimxzSOLL; Mon, 14 Nov 2011 21:42:58 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 66C6A11E8098; Mon, 14 Nov 2011 21:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pAF5gmN5015023; Tue, 15 Nov 2011 06:42:48 +0100 (CET) Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 23ADDC8D; Tue, 15 Nov 2011 06:42:45 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1251.1) From: Carsten Bormann Date: Tue, 15 Nov 2011 13:42:39 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org> To: 6lowpan <6lowpan@ietf.org>, roll@ietf.org, core WG , lwip@ietf.org X-Mailer: Apple Mail (2.1251.1) Subject: [6lowpan] Cross-layer issues in Constrained Node/Networks: informal get-together X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: 6lowpan <6lowpan@ietf.org> List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 05:43:00 -0000 Our WGs (6LoWPAN/ROLL/CoRE/LWIG) are about making IP work well on constrained node/network environments. A number of issues in this space are cross-layer (or at least cross-WG) in nature. While these are a constant topic in the hallways, maybe we can make more progress by getting a group of people in one room. We are going to have an informal get-together to discuss some of these issues at Thu, 1740-1940, room 102 While the room maybe is not optimal for an informal discussion (and the overlap with TLS is unfortunate for some of us), it does enable use of the projector -- and it was available now that the LISP WG meeting is canceled. I'm going to try to get some structure into the discussion. The following items have been mentioned as possible subjects (drafts are mentioned as potential background material): 0 -- implications of 802.15.4g, 802.15.4e on 6LoWPAN is there anything we need to do/should be doing to make 6LoWPAN more useful with these new/extended link layers in the 802.15.4 space? Anything beyond the adaptation layer? What about security/key management? Also: other links, e.g. 6LoWPAN for Bluetooth-Low-Energy draft-ietf-6lowpan-btle-03.txt (We had a nice lunch discussion in a small group today, so we are already mostly done with the basic work on this topic) e.g., what are the interactions of the Bluetooth security protocols/attribute protocol and the things we are doing on the IP side? 1 -- 6LoWPAN-GHC and its application to ROLL, SenML and other protocols draft-bormann-6lowpan-ghc-03.txt draft-goyal-6lowpan-rpl-compression-00.txt draft-goyal-roll-rpl-compression-00.txt draft-jennings-senml-07.txt Any other protocols that would benefit significantly from 6LoWPAN-GHC? 2 -- Cross-Layer implications of the CoRE discovery discussion Discover of servers, services, and resources sometimes interacts with discovery of network elements like proxies, routers, networks. http://tools.ietf.org/html/draft-brandt-coap-subnet-discovery-00 Is there a useful overlap between application layer discovery and network layer autoconfiguration? Related: 6LoWPAN vs. HOMENET What are the implications of the HOMENET architecture document and technical proposals on the typical deployment of 6LoWPANs for home automation applications? (Implications on discovery?) 3 -- LWIG draft-bormann-lwig-guidance-00.txt what can we do to discuss APIs in a meaningful way here? what else should be in this document? 4 -- extensions for industrial applications of 6LoWPAN draft-wang-6lowpan-scheduling-requirements-00.txt Are there solutions that could be implemented in 6LoWPAN that solve some of these requirements? Is it even useful to discuss industrial applications outside of the system standards ISA100.11a/Wireless-HART/WIA-PA (i.e., is there a "pure IPv6" space waiting to be explored)? 5 -- network management for constrained node/networks What is the best place to bring the various efforts together? Should we be doing the bigger picture in the IETF NMRG? This is a lot of items, and we won't cover all of them in these two hours, but maybe we can at least make interested people known to each other and spin off further hallway discussions. Maybe we can go through the items in this sequence (i.e., =E2=89=A4 10 = minutes per number) in the first hour and then revisit points that merit more discussion. If you want to make a more structured contribution to, or lead, any one of these points, please tell me (and send a slide or two,=20= if useful). Gruesse, Carsten PS.: To be redundantly clear, let me add this Disclaimer: This is not a BOF, not even a Bar-BOF. It is not about drumming up support for some potential work. Just about technical discussion. No intent to forcibly draw in ADs... PPS.: I have attempted to set a reply-to to 6lowpan. Feel free to answer to *one* of the WGs. Please don't spam all four. From rgm@labs.htt-consult.com Mon Nov 14 22:19:51 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C7B1F0C38 for <6lowpan@ietfa.amsl.com>; Mon, 14 Nov 2011 22:19:51 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFsU2SHXAKuB for <6lowpan@ietfa.amsl.com>; Mon, 14 Nov 2011 22:19:50 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id C623411E80AB for <6lowpan@ietf.org>; Mon, 14 Nov 2011 22:19:49 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 2ADB862A91; Tue, 15 Nov 2011 06:19:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzRteMuEYN4Q; Tue, 15 Nov 2011 01:19:07 -0500 (EST) Received: from nc2400.htt-consult.com (dhcp-54ca.meeting.ietf.org [130.129.84.202]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id 2BBA562A86; Tue, 15 Nov 2011 01:19:05 -0500 (EST) Message-ID: <4EC20459.1090606@labs.htt-consult.com> Date: Tue, 15 Nov 2011 14:19:05 +0800 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110928 Fedora/3.1.15-1.fc14 Thunderbird/3.1.15 MIME-Version: 1.0 To: "Benjamin A. Rolfe" References: <4EBD7EC9.4090705@labs.htt-consult.com> <7122CCCC-BF56-4A67-B255-DF126BEA495D@yegin.org> <4EC145FC.4030601@labs.htt-consult.com> <4EC16CDB.5010503@blindcreek.com> In-Reply-To: <4EC16CDB.5010503@blindcreek.com> Content-Type: multipart/alternative; boundary="------------020300010301080202010903" Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] IEEE 802.15.9 KMP over 802.15.4 and 802.15.7 approved X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 06:19:51 -0000 This is a multi-part message in MIME format. --------------020300010301080202010903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/15/2011 03:32 AM, Benjamin A. Rolfe wrote: > Excellent points that will make the PAR stronger. > > Many on this list have been through the IEEE 802 project process, but > for those that may not have it might help to explain the purpose of > the PAR, which is to ask IEEE-SA to authorize a new project, in this > case a recommended practice. The scope clause defines the direction of > the project and can be thought of as the 'normative' part of the PAR. > The other clauses provide the New Standards committee (NesCom) > background, and not in any way limitations. > > I see positive potential for the project. As Robert points out there > are many security methods applied over and with 802.15 standards and > for some (like me) it can be a mystifying topic. I am looking to TG9 > to help. > > As currently drafted the scope is not limited to the particular > protocols mentioned as examples. The 802.15 operating procedures allow > a very open process and input is welcome from all that choose to > participate. If/when it is approved the first steps will be to define, > within the scope of the project, what specific protocols are relevant > to the RP. I commend Bob for reaching out at this early stage to > solicit input on the project, and encourage continued participation. > The experience of those that have used 802.15.4 and other standards in > the 802.15 family will be of great value. > > So as a potential user of the RP (who isn't qualified to contribute > much beyond desire ;-), thanks all for the help on the PAR and I look > forward to continued contributions! Oh, you are going to contribute, but as a MAC expert. I THINK I have the Frame Control bits figured out and the use of the Payload IE over the Header IE, but not only does this need to be worked out but consider a controller that is receiving a string of datagrams with Forced ACKs for sensor 1 when sensor 2 starts sending a chain. Does the controller NAK sensor 2 until it finishes with sensor 1? Should KMP processing be single-threaded? What about timeouts if the sensor moves out of range during the KMP exchange then moves back within range. Well within the KMP this SHOULD be handled but the chaining? Both sides SHOULD flush out partial transmit/receive sequences on the same timing. And this is only 15.4, I need some senior guidance in cracking 15.7. There are other points for discussion as well. All this is JUST to open up 802.15 to workable security solutions independent of the higher layer selection. > > -B > > >> Bob, >> >> I have to say I object to the following statement in the PAR: >> >> "Lack of key management support in IEEE Std 802.15.4 and IEEE Std >> 802.15.7 results in weak keys which is a common avenue for attacking >> the security system." >> >> "results in weak keys" implies this is always the case, which is >> simply not true. This should be rephrased as "may result in weak >> keys". Users of 802.15.4 such as ZigBee have put in place a KMP which >> does not result in weak keys, >> >> And I agree with Alper - if you are mentioning IETF and 802.1X, you >> really have to mention PANA as it is entirely relevant. >> >> Robert >> >> On Mon, Nov 14, 2011 at 4:46 PM, Robert Moskowitz >> > wrote: >> >> On 11/14/2011 03:17 PM, Alper Yegin wrote: >> > >> >> >> >> > Hi Bob, >> >> >> >> > >> >> >> >> > This PAR document still does not refer to >> IETF's PANA (IETF >> >> RFC that >> >> >> >> > is already adopted by the Zigbee IP spec.) I'm >> hoping the PAR >> >> changes >> >> >> >> > you are referring are already addressing that. >> Please let us >> >> know. >> >> It was a procedural question as to what is 'wanted' here. >> Strictly IEEE standards or broader interpretation? The 802EC >> clearified that a broader inclusion was desired so words have >> been added to point out that Zibgee IP has addressed this within >> their upper layer. A 'literal' interpretation was that 802.1X >> does not work over 802.15.4 or 15.7 so there was no comparable >> standard. >> >> Also 802.1 pointed out the need to include the potential need of >> an Registry Authority (6.1b) and that too was added. The final >> posted PAR will reflect these two changes. >> >> >> > >> >> >> >> > Thanks. >> >> >> >> > >> >> >> >> > Alper >> >> >> >> > >> >> >> >> > >> >> >> >> > On Nov 11, 2011, at 10:00 PM, Robert Moskowitz >> wrote: >> >> >> >> > >> >> >> >> >> The IEEE 802ec approved the PAR this >> afternoon. The PAR >> >> documents >> >> >> >> >> are at: >> >> >> >> >> >> >> >> >> >> >> >> https://mentor.ieee.org/802.15/dcn/11/15-11-0613-05-0kmp-key-management-protocol-par.doc >> >> >> >> >> >> >> >> >> >> >> https://mentor.ieee.org/802.15/dcn/11/15-11-0665-05-0kmp-kmp-5c-draft.doc >> >> >> >> >> >> >> We did agree to two procedural changes in >> the PAR, so >> >> there will be >> >> >> >> >> a rev 6 posted sometime soon. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> 6lowpan >> >> mailing >> >> >> >> >> list 6lowpan@ietf.org >> >> >> >> >> >> https://www.ietf.org/mailman/listinfo/6lowpan >> >> >> >> > >> >> >> >> > >> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> >> >> >> >> -- >> >> Robert Cragie >> >> Gridmerge Ltd. >> 89 Greenfield Crescent, >> Wakefield, WF4 4WA, UK >> +44 1924 910888 >> +1 415 513 0064 >> http://www.gridmerge.com >> >> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > -- Robert Moskowitz Senior Technical Advisor Security & Standards Verizon Business Systems C:248-219-2059 F:248-968-2824 E:robert.moskowitz@verizonbusiness.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------020300010301080202010903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/15/2011 03:32 AM, Benjamin A. Rolfe wrote:
Excellent points that will make the PAR stronger.

Many on this list have been through the IEEE 802 project process, but for those that may not have it might help to explain the purpose of the PAR, which is to ask IEEE-SA to authorize a new project, in this case a recommended practice. The scope clause defines the direction of the project and can be thought of as the 'normative' part of the PAR.  The other clauses provide the New Standards committee (NesCom) background, and not in any way limitations.   

I see positive potential for the project. As Robert points out there are many security methods applied over and with 802.15 standards and for some (like me) it can be a mystifying topic.  I am looking to TG9 to help.

As currently drafted the scope is not limited to the particular protocols mentioned as examples. The 802.15 operating procedures allow a very open process and input is welcome from all that choose to participate. If/when it is approved the first steps will be to define, within the scope of the project, what specific protocols are relevant to the RP.  I commend Bob for reaching out at this early stage to solicit input on the project, and encourage continued participation.   The experience of those that have used 802.15.4 and other standards in the 802.15 family will be of great value.

So as a potential user of the RP (who isn't qualified to contribute much beyond desire ;-), thanks all for the help on the PAR and I look forward to continued contributions!

Oh, you are going to contribute, but as a MAC expert.  I THINK I have the Frame Control bits figured out and the use of the Payload IE over the Header IE, but not only does this need to be worked out but consider a controller that is receiving a string of datagrams with Forced ACKs for sensor 1 when sensor 2 starts sending a chain.  Does the controller NAK sensor 2 until it finishes with sensor 1?  Should KMP processing be single-threaded?  What about timeouts if the sensor moves out of range during the KMP exchange then moves back within range.  Well within the KMP this SHOULD be handled but the chaining?  Both sides SHOULD flush out partial transmit/receive sequences on the same timing.  And this is only 15.4, I need some senior guidance in cracking 15.7.

There are other points for discussion as well.  All this is JUST to open up 802.15 to workable security solutions independent of the higher layer selection.


-B


Bob,

I have to say I object to the following statement in the PAR:

"Lack of key management support in IEEE Std 802.15.4 and IEEE Std 802.15.7 results in weak keys which is a common avenue for attacking the security system."

"results in weak keys" implies this is always the case, which is simply not true. This should be rephrased as "may result in weak keys". Users of 802.15.4 such as ZigBee have put in place a KMP which does not result in weak keys,

And I agree with Alper - if you are mentioning IETF and 802.1X, you really have to mention PANA as it is entirely relevant.

Robert

On Mon, Nov 14, 2011 at 4:46 PM, Robert Moskowitz <rgm@labs.htt-consult.com> wrote:
On 11/14/2011 03:17 PM, Alper Yegin wrote:
>



> Hi Bob,



>



> This PAR document still does not refer to
IETF's PANA (IETF

RFC that



> is already adopted by the Zigbee IP spec.) I'm
hoping the PAR

changes



> you are referring are already addressing that.
Please let us

know.

It was a procedural question as to what is 'wanted' here.  Strictly IEEE standards or broader interpretation?  The 802EC clearified that a broader inclusion was desired so words have been added to point out that Zibgee IP has addressed this within their upper layer.  A 'literal' interpretation was that 802.1X does not work over 802.15.4 or 15.7 so there was no comparable standard.

Also 802.1 pointed out the need to include the potential need of an Registry Authority (6.1b) and that too was added.  The final posted PAR will reflect these two changes.


>



> Thanks.



>



> Alper



>



>



> On Nov 11, 2011, at 10:00 PM, Robert Moskowitz
wrote:



>



>> The IEEE 802ec approved the PAR this
afternoon. The PAR

documents



>> are at:



>>



>>

https://mentor.ieee.org/802.15/dcn/11/15-11-0613-05-0kmp-key-management-protocol-par.doc



>>



>>
https://mentor.ieee.org/802.15/dcn/11/15-11-0665-05-0kmp-kmp-5c-draft.doc
>>



>> We did agree to two procedural changes in
the PAR, so

there will be



>> a rev 6 posted sometime soon.



>>



>>



>>
_______________________________________________
6lowpan

mailing



>> list 6lowpan@ietf.org




>> https://www.ietf.org/mailman/listinfo/6lowpan



>



>


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan




--

Robert Cragie

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
 http://www.gridmerge.com



_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan


--
Standard Robert Moskowitz
Senior Technical Advisor
Security & Standards
Verizon Business Systems
C:      248-219-2059
F:      248-968-2824
E:      robert.moskowitz@verizonbusiness.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------020300010301080202010903-- From angelo.castellani@gmail.com Tue Nov 15 00:44:20 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85A721F8FBF; Tue, 15 Nov 2011 00:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYFUPwxl913N; Tue, 15 Nov 2011 00:44:20 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 683E921F8FC1; Tue, 15 Nov 2011 00:44:19 -0800 (PST) Received: by wwe5 with SMTP id 5so4069940wwe.13 for ; Tue, 15 Nov 2011 00:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=l/VV90Z3ZVSOjeRfbwdWFjmFD4CIZM9s/KdvMib9URA=; b=XTEJgS8D6qkZNrG9deRG0j4SXt/ddxln6qxdxfk6+q2JIJeQ/8XO+mxTtoe8fpspo8 i5F/rKfbDIMsQyQWOdPKXETL07bfCHQr1rnAcT3+fwmJ+wAzKlALNNMqj2BgSqefayOj 7ZB4UKFa88g2hdzc6hTPUjbaOMdzDuaQ6hof0= Received: by 10.216.14.206 with SMTP id d56mr238784wed.33.1321346657131; Tue, 15 Nov 2011 00:44:17 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.62.8 with HTTP; Tue, 15 Nov 2011 00:43:36 -0800 (PST) In-Reply-To: References: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org> From: "Angelo P. Castellani" Date: Tue, 15 Nov 2011 09:43:36 +0100 X-Google-Sender-Auth: 0SyBWOqg3ArIZ9AXELR7aYn5iIg Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: lwip@ietf.org, roll WG , 6lowpan@ietf.org, Thomas Fossati , core WG Subject: Re: [6lowpan] [core] Cross-layer issues in Constrained Node/Networks: informal get-together X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 08:44:21 -0000 I will enjoy hearing to your talk and even send my comments to jabber, if will be possible for you to use the microphone on the vast majority of time (not always as during a formal WG meeting). If using the microphone frequently is a problem, it would be probably better to discuss offline the results of this informal meeting. BTW, do you plan to circulate some notes after this informal talk? Angelo On Tue, Nov 15, 2011 at 09:29, Carsten Bormann wrote: > On Nov 15, 2011, at 15:44, Thomas Fossati wrote: > >> is there any chance to get at least the audio streaming of the meeting ? > > Well, this is more of a brainstorming gathering, and I'm not sure I want = to enforce religious use of the microphone. > > I think the stream from room 102 should work in principle, so if you go t= o http://ietf82streaming.dnsalias.net/ietf/ietf825.m3u you should have a go= od chance of hearing faint voices arguing in the background noise. =C2=A0We= also can try to have a jabber monitor (probably not a "jabber scribe", tho= ugh). > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From cabo@tzi.org Tue Nov 15 00:54:10 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28EC21F9015 for <6lowpan@ietfa.amsl.com>; Tue, 15 Nov 2011 00:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 251NJVt5Zfwz for <6lowpan@ietfa.amsl.com>; Tue, 15 Nov 2011 00:54:09 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 3352021F9014 for <6lowpan@ietf.org>; Tue, 15 Nov 2011 00:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pAF8s0cx003591; Tue, 15 Nov 2011 09:54:01 +0100 (CET) Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E71ADD56; Tue, 15 Nov 2011 09:53:58 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 15 Nov 2011 16:53:52 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org> To: "Angelo P. Castellani" X-Mailer: Apple Mail (2.1251.1) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] [core] Cross-layer issues in Constrained Node/Networks: informal get-together X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 08:54:10 -0000 On Nov 15, 2011, at 16:43, Angelo P. Castellani wrote: > BTW, do you plan to circulate some notes after this informal talk? If somebody volunteers to take notes -- sure! (But, again, this is not a WG meeting, so there will be no "conclusions" = or "results".) Gr=FC=DFe, Carsten From rstruik.ext@gmail.com Tue Nov 15 05:48:12 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C7021F8C8C for <6lowpan@ietfa.amsl.com>; Tue, 15 Nov 2011 05:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Baq4Egwp8zaL for <6lowpan@ietfa.amsl.com>; Tue, 15 Nov 2011 05:48:08 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5F721F8C83 for <6lowpan@ietf.org>; Tue, 15 Nov 2011 05:48:07 -0800 (PST) Received: by ggnr5 with SMTP id r5so2528791ggn.31 for <6lowpan@ietf.org>; Tue, 15 Nov 2011 05:48:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; bh=IZKOQ4zEPlDsJNYGB25lC24nr21TXuyTtRmGAM/vzOw=; b=a7WY5Mg0gHadVDmP1+KrbCWz8yaUKzLA+qebcKjHYvFxXLeXnMu25i6/o6lqYeZHt8 uqcvVT4uay1Ffa4sHA6jdpyl8rGMrKZCCI3Yb2WHHph7cdhIAOnRqXTMDf0nv/+2PmPt hOaxdbunXYK3u0i64yOArSVo8bSLmkQ5rYv7w= Received: by 10.100.246.19 with SMTP id t19mr8090433anh.10.1321364887353; Tue, 15 Nov 2011 05:48:07 -0800 (PST) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.117.243]) by mx.google.com with ESMTPS id 32sm73959804anu.10.2011.11.15.05.48.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Nov 2011 05:48:05 -0800 (PST) Message-ID: <4EC26D8D.8040000@gmail.com> Date: Tue, 15 Nov 2011 08:47:57 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Robert Moskowitz References: <4EBD7EC9.4090705@labs.htt-consult.com> <7122CCCC-BF56-4A67-B255-DF126BEA495D@yegin.org> <4EC145FC.4030601@labs.htt-consult.com> <4EC16CDB.5010503@blindcreek.com> <4EC20459.1090606@labs.htt-consult.com> In-Reply-To: <4EC20459.1090606@labs.htt-consult.com> X-Enigmail-Version: 1.3.3 Content-Type: multipart/alternative; boundary="------------060907040608000007060306" Cc: 6lowpan@ietf.org Subject: [6lowpan] (what is the problem statement) Re: IEEE 802.15.9 KMP over 802.15.4 and 802.15.7 approved X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 13:48:12 -0000 This is a multi-part message in MIME format. --------------060907040608000007060306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Robert: Point of clarification: ZigBee SE1.x and ISA SP100.11a implement an end-to-end key agreement scheme (based on public keys and certificates) at a stack layer above the MAC. This key agreement scheme consists of four message flows between two parties A and B, where each party communicates a key contribution and a key confirmation message, and where each message flow fits within the maximum 802.15.4-2006 MAC frame size (of 127 octets), so that no fragmentation occurs. Question is what the problem is you are trying to solve that cannot be addressed by a higher layer protocol and what the benefits are compared to, e.g., the approach above. A table with features and benefits and comparison along different dimensions would surely help. Please note here that ZigBee SE1.x, ISA SP100.11a have been out there for quite a while. A similar remark holds for wHART (IEC 62951), an industrial control standard. It would have great merit to the group to clarify the problem statement, what is new, and what alleged benefits are, before diving into minutiae of time-outs and in/out communication reach topics (which apply to most management traffic, not just key management traffic, and - in fact - to most traffic [after all, shouldn't traffic elicit a state change?]). Best regards, Rene On 15/11/2011 1:19 AM, Robert Moskowitz wrote: > On 11/15/2011 03:32 AM, Benjamin A. Rolfe wrote: >> Excellent points that will make the PAR stronger. >> >> Many on this list have been through the IEEE 802 project process, but >> for those that may not have it might help to explain the purpose of >> the PAR, which is to ask IEEE-SA to authorize a new project, in this >> case a recommended practice. The scope clause defines the direction >> of the project and can be thought of as the 'normative' part of the >> PAR. The other clauses provide the New Standards committee (NesCom) >> background, and not in any way limitations. >> >> I see positive potential for the project. As Robert points out there >> are many security methods applied over and with 802.15 standards and >> for some (like me) it can be a mystifying topic. I am looking to TG9 >> to help. >> >> As currently drafted the scope is not limited to the particular >> protocols mentioned as examples. The 802.15 operating procedures >> allow a very open process and input is welcome from all that choose >> to participate. If/when it is approved the first steps will be to >> define, within the scope of the project, what specific protocols are >> relevant to the RP. I commend Bob for reaching out at this early >> stage to solicit input on the project, and encourage continued >> participation. The experience of those that have used 802.15.4 and >> other standards in the 802.15 family will be of great value. >> >> So as a potential user of the RP (who isn't qualified to contribute >> much beyond desire ;-), thanks all for the help on the PAR and I look >> forward to continued contributions! > > Oh, you are going to contribute, but as a MAC expert. I THINK I have > the Frame Control bits figured out and the use of the Payload IE over > the Header IE, but not only does this need to be worked out but > consider a controller that is receiving a string of datagrams with > Forced ACKs for sensor 1 when sensor 2 starts sending a chain. Does > the controller NAK sensor 2 until it finishes with sensor 1? Should > KMP processing be single-threaded? What about timeouts if the sensor > moves out of range during the KMP exchange then moves back within > range. Well within the KMP this SHOULD be handled but the chaining? > Both sides SHOULD flush out partial transmit/receive sequences on the > same timing. And this is only 15.4, I need some senior guidance in > cracking 15.7. > > There are other points for discussion as well. All this is JUST to > open up 802.15 to workable security solutions independent of the > higher layer selection. > >> >> -B >> >> >>> Bob, >>> >>> I have to say I object to the following statement in the PAR: >>> >>> "Lack of key management support in IEEE Std 802.15.4 and IEEE Std >>> 802.15.7 results in weak keys which is a common avenue for attacking >>> the security system." >>> >>> "results in weak keys" implies this is always the case, which is >>> simply not true. This should be rephrased as "may result in weak >>> keys". Users of 802.15.4 such as ZigBee have put in place a KMP >>> which does not result in weak keys, >>> >>> And I agree with Alper - if you are mentioning IETF and 802.1X, you >>> really have to mention PANA as it is entirely relevant. >>> >>> Robert >>> >>> On Mon, Nov 14, 2011 at 4:46 PM, Robert Moskowitz >>> > wrote: >>> >>> On 11/14/2011 03:17 PM, Alper Yegin wrote: >>> > >>> >>> >>> >>> > Hi Bob, >>> >>> >>> >>> > >>> >>> >>> >>> > This PAR document still does not refer to >>> IETF's PANA (IETF >>> >>> RFC that >>> >>> >>> >>> > is already adopted by the Zigbee IP spec.) I'm >>> hoping the PAR >>> >>> changes >>> >>> >>> >>> > you are referring are already addressing that. >>> Please let us >>> >>> know. >>> >>> It was a procedural question as to what is 'wanted' here. >>> Strictly IEEE standards or broader interpretation? The 802EC >>> clearified that a broader inclusion was desired so words have >>> been added to point out that Zibgee IP has addressed this within >>> their upper layer. A 'literal' interpretation was that 802.1X >>> does not work over 802.15.4 or 15.7 so there was no comparable >>> standard. >>> >>> Also 802.1 pointed out the need to include the potential need of >>> an Registry Authority (6.1b) and that too was added. The final >>> posted PAR will reflect these two changes. >>> >>> >>> > >>> >>> >>> >>> > Thanks. >>> >>> >>> >>> > >>> >>> >>> >>> > Alper >>> >>> >>> >>> > >>> >>> >>> >>> > >>> >>> >>> >>> > On Nov 11, 2011, at 10:00 PM, Robert Moskowitz >>> wrote: >>> >>> >>> >>> > >>> >>> >>> >>> >> The IEEE 802ec approved the PAR this >>> afternoon. The PAR >>> >>> documents >>> >>> >>> >>> >> are at: >>> >>> >>> >>> >> >>> >>> >>> >>> >> >>> >>> https://mentor.ieee.org/802.15/dcn/11/15-11-0613-05-0kmp-key-management-protocol-par.doc >>> >>> >>> >>> >> >>> >>> >>> >>> >> >>> https://mentor.ieee.org/802.15/dcn/11/15-11-0665-05-0kmp-kmp-5c-draft.doc >>> >> >>> >>> >>> >>> >> We did agree to two procedural changes in >>> the PAR, so >>> >>> there will be >>> >>> >>> >>> >> a rev 6 posted sometime soon. >>> >>> >>> >>> >> >>> >>> >>> >>> >> >>> >>> >>> >>> >> >>> _______________________________________________ >>> 6lowpan >>> >>> mailing >>> >>> >>> >>> >> list 6lowpan@ietf.org >>> >>> >>> >>> >>> >> https://www.ietf.org/mailman/listinfo/6lowpan >>> >>> >>> >>> > >>> >>> >>> >>> > >>> >>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >>> >>> >>> >>> -- >>> >>> Robert Cragie >>> >>> Gridmerge Ltd. >>> 89 Greenfield Crescent, >>> Wakefield, WF4 4WA, UK >>> +44 1924 910888 >>> +1 415 513 0064 >>> http://www.gridmerge.com >>> >>> >>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >> > > -- > Robert Moskowitz > Senior Technical Advisor > Security & Standards > Verizon Business Systems > C: 248-219-2059 > F: 248-968-2824 > E: robert.moskowitz@verizonbusiness.com > > There's no limit to what can be accomplished if it doesn't matter who > gets the credit > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 --------------060907040608000007060306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Robert:

Point of clarification:

ZigBee SE1.x and ISA SP100.11a implement an end-to-end key agreement scheme (based on public keys and certificates) at a stack layer above the MAC. This key agreement scheme consists of four message flows between two parties A and B, where each party communicates a key contribution and a key confirmation message, and where each message flow fits within the maximum 802.15.4-2006 MAC frame size (of 127 octets), so that no fragmentation occurs.

Question is what the problem is you are trying to solve that cannot be addressed by a higher layer protocol and what the benefits are compared to, e.g., the approach above. A table with features and benefits and comparison along different dimensions would surely help.

Please note here that ZigBee SE1.x, ISA SP100.11a have been out there for quite a while. A similar remark holds for wHART (IEC 62951), an industrial control standard.

It would have great merit to the group to clarify the problem statement, what is new, and what alleged benefits are, before diving into minutiae of time-outs and in/out communication reach topics (which apply to most management traffic, not just key management traffic, and - in fact - to most traffic [after all, shouldn't traffic elicit a state change?]).

Best regards, Rene

On 15/11/2011 1:19 AM, Robert Moskowitz wrote:
On 11/15/2011 03:32 AM, Benjamin A. Rolfe wrote:
Excellent points that will make the PAR stronger.

Many on this list have been through the IEEE 802 project process, but for those that may not have it might help to explain the purpose of the PAR, which is to ask IEEE-SA to authorize a new project, in this case a recommended practice. The scope clause defines the direction of the project and can be thought of as the 'normative' part of the PAR.  The other clauses provide the New Standards committee (NesCom) background, and not in any way limitations.   

I see positive potential for the project. As Robert points out there are many security methods applied over and with 802.15 standards and for some (like me) it can be a mystifying topic.  I am looking to TG9 to help.

As currently drafted the scope is not limited to the particular protocols mentioned as examples. The 802.15 operating procedures allow a very open process and input is welcome from all that choose to participate. If/when it is approved the first steps will be to define, within the scope of the project, what specific protocols are relevant to the RP.  I commend Bob for reaching out at this early stage to solicit input on the project, and encourage continued participation.   The experience of those that have used 802.15.4 and other standards in the 802.15 family will be of great value.

So as a potential user of the RP (who isn't qualified to contribute much beyond desire ;-), thanks all for the help on the PAR and I look forward to continued contributions!

Oh, you are going to contribute, but as a MAC expert.  I THINK I have the Frame Control bits figured out and the use of the Payload IE over the Header IE, but not only does this need to be worked out but consider a controller that is receiving a string of datagrams with Forced ACKs for sensor 1 when sensor 2 starts sending a chain.  Does the controller NAK sensor 2 until it finishes with sensor 1?  Should KMP processing be single-threaded?  What about timeouts if the sensor moves out of range during the KMP exchange then moves back within range.  Well within the KMP this SHOULD be handled but the chaining?  Both sides SHOULD flush out partial transmit/receive sequences on the same timing.  And this is only 15.4, I need some senior guidance in cracking 15.7.

There are other points for discussion as well.  All this is JUST to open up 802.15 to workable security solutions independent of the higher layer selection.


-B


Bob,

I have to say I object to the following statement in the PAR:

"Lack of key management support in IEEE Std 802.15.4 and IEEE Std 802.15.7 results in weak keys which is a common avenue for attacking the security system."

"results in weak keys" implies this is always the case, which is simply not true. This should be rephrased as "may result in weak keys". Users of 802.15.4 such as ZigBee have put in place a KMP which does not result in weak keys,

And I agree with Alper - if you are mentioning IETF and 802.1X, you really have to mention PANA as it is entirely relevant.

Robert

On Mon, Nov 14, 2011 at 4:46 PM, Robert Moskowitz <rgm@labs.htt-consult.com> wrote:
On 11/14/2011 03:17 PM, Alper Yegin wrote:
>



> Hi Bob,



>



> This PAR document still does not refer to
IETF's PANA (IETF

RFC that



> is already adopted by the Zigbee IP spec.) I'm
hoping the PAR

changes



> you are referring are already addressing that.
Please let us

know.

It was a procedural question as to what is 'wanted' here.  Strictly IEEE standards or broader interpretation?  The 802EC clearified that a broader inclusion was desired so words have been added to point out that Zibgee IP has addressed this within their upper layer.  A 'literal' interpretation was that 802.1X does not work over 802.15.4 or 15.7 so there was no comparable standard.

Also 802.1 pointed out the need to include the potential need of an Registry Authority (6.1b) and that too was added.  The final posted PAR will reflect these two changes.


>



> Thanks.



>



> Alper



>



>



> On Nov 11, 2011, at 10:00 PM, Robert Moskowitz
wrote:



>



>> The IEEE 802ec approved the PAR this
afternoon. The PAR

documents



>> are at:



>>



>>

https://mentor.ieee.org/802.15/dcn/11/15-11-0613-05-0kmp-key-management-protocol-par.doc



>>



>>
https://mentor.ieee.org/802.15/dcn/11/15-11-0665-05-0kmp-kmp-5c-draft.doc
>>



>> We did agree to two procedural changes in
the PAR, so

there will be



>> a rev 6 posted sometime soon.



>>



>>



>>
_______________________________________________
6lowpan

mailing



>> list 6lowpan@ietf.org




>> https://www.ietf.org/mailman/listinfo/6lowpan



>



>


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan




--

Robert Cragie

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
 http://www.gridmerge.com



_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan


--
Standard Robert Moskowitz
Senior Technical Advisor
Security & Standards
Verizon Business Systems
C:      248-219-2059
F:      248-968-2824
E:      robert.moskowitz@verizonbusiness.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan



-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363
--------------060907040608000007060306-- From sarikaya2012@gmail.com Tue Nov 15 17:35:17 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6F811E8145 for <6lowpan@ietfa.amsl.com>; Tue, 15 Nov 2011 17:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FsYyzFVryJj for <6lowpan@ietfa.amsl.com>; Tue, 15 Nov 2011 17:35:13 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 337E511E8136 for <6lowpan@ietf.org>; Tue, 15 Nov 2011 17:35:10 -0800 (PST) Received: by ggnr5 with SMTP id r5so3376454ggn.31 for <6lowpan@ietf.org>; Tue, 15 Nov 2011 17:35:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Y3NYj4fRmLoZyHaj+WI/Col52w4pzhNOCXqRLFeuGmk=; b=E3SbKnNbGz4LnbRZSM6t3jHeUOgnIIwCra/J8JvN13QEX8M0PdW/5GIEOz940CSgal eOpiYSew1bN9HMdYsR9djG5QFQvothbGsfLCjtPd0VQNZecQw4ugwG7+oVP+6bnVeDyJ b9bdovwn4r8C+K5ocbgxk97EFXVc6vrMMt5ks= MIME-Version: 1.0 Received: by 10.100.216.9 with SMTP id o9mr1141244ang.83.1321407309761; Tue, 15 Nov 2011 17:35:09 -0800 (PST) Received: by 10.236.191.228 with HTTP; Tue, 15 Nov 2011 17:35:09 -0800 (PST) In-Reply-To: References: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org> Date: Tue, 15 Nov 2011 19:35:09 -0600 Message-ID: From: Behcet Sarikaya To: Carsten Bormann Content-Type: multipart/alternative; boundary=001636988a6c4d4cc504b1d01d02 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] [core] Cross-layer issues in Constrained Node/Networks: informal get-together X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 01:35:17 -0000 --001636988a6c4d4cc504b1d01d02 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If we are discussing garriuty and fluffy, I am attending :-). Regards, Behcet On Tue, Nov 15, 2011 at 2:53 AM, Carsten Bormann wrote: > > On Nov 15, 2011, at 16:43, Angelo P. Castellani wrote: > > > BTW, do you plan to circulate some notes after this informal talk? > > If somebody volunteers to take notes -- sure! > (But, again, this is not a WG meeting, so there will be no "conclusions" > or "results".) > > Gr=FC=DFe, Carsten > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > --001636988a6c4d4cc504b1d01d02 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If we are discussing garriuty and fluffy, I am attending :-).

Regard= s,

Behcet

On Tue, Nov 15, 2011 at = 2:53 AM, Carsten Bormann <cabo@tzi.org> wrote:

On Nov 15, 2011, at 16:43, Angelo P. Castellani wrote:

> BTW, do you plan to circulate some notes after this informal talk?

If somebody volunteers to take notes -- sure!
(But, again, this is not a WG meeting, so there will be no "conclusion= s" or "results".)

Gr=FC=DFe, Carsten

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan

--001636988a6c4d4cc504b1d01d02-- From cabo@tzi.org Wed Nov 16 18:56:20 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2660B1F0CA1; Wed, 16 Nov 2011 18:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAYmV0ND6fQI; Wed, 16 Nov 2011 18:56:19 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 14AC51F0C8D; Wed, 16 Nov 2011 18:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pAH2u990017121; Thu, 17 Nov 2011 03:56:09 +0100 (CET) Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 46DBC999; Thu, 17 Nov 2011 03:56:06 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org> Date: Thu, 17 Nov 2011 10:56:02 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <49940D6A-23D5-4EF9-A328-E4C5F81F3A36@tzi.org> References: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org> To: 6lowpan <6lowpan@ietf.org> X-Mailer: Apple Mail (2.1251.1) Cc: lwip@ietf.org, roll@ietf.org, core WG Subject: Re: [6lowpan] Cross-layer issues in Constrained Node/Networks: informal get-together X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: 6lowpan <6lowpan@ietf.org> List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 02:56:20 -0000 On Nov 15, 2011, at 13:42, Carsten Bormann wrote: > We are going to have an informal get-together to discuss some of these > issues at >=20 > Thu, 1740-1940, room 102 I have started collecting slides for this event. We don't need slides to discuss something, but where they help, I would = like to have them before the meeting. Observe*) the current set of slides at http://www.tzi.org/~cabo/cross-layer.pdf Gr=FC=DFe, Carsten *) Sorry, no CoAP server there yet=85 Manual repeated HTTP GET = required.