From cabo@tzi.org Thu Oct 4 15:09:32 2012 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 87EDD21F8589; Thu, 4 Oct 2012 15:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.223 X-Spam-Level: X-Spam-Status: No, score=-106.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WRXWDj-3qu1; Thu, 4 Oct 2012 15:09:31 -0700 (PDT) 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 4BD1621F8588; Thu, 4 Oct 2012 15:09:30 -0700 (PDT) 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 q94M9NtP022650; Fri, 5 Oct 2012 00:09:23 +0200 (CEST) Received: from [192.168.217.117] (p548920DE.dip.t-dialin.net [84.137.32.222]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 65763311; Fri, 5 Oct 2012 00:09:23 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Oct 2012 00:09:22 +0200 To: "lwip@ietf.org" , "core@ietf.org WG" , roll WG , "6lowpan@ietf.org" <6lowpan@ietf.org> Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) X-Mailer: Apple Mail (2.1498) Subject: [6lowpan] Constrained Node/Network Cluster @ IETF85 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: Thu, 04 Oct 2012 22:09:32 -0000 Here is my usual eclectic condensed agenda. I'm sure we'll have a lot of ad-hoc meetings, too, but these are the = current WG meeting that could be considered part of a Constrained = Node/Network Cluster (or might impact it). As you can see, lwig is currently on top of Friday's core meeting, and = that will have to change. Apart from that, the damage seems to be limited this time, at least = before the usual round of swaps. See you all in Atlanta! Gr=FC=DFe, Carsten MONDAY, November 5, 2012 0900-1130 Morning Session I Salon A APP apparea Applications Area Open Meeting = - Combined with APPSAWG Salon D INT 6man IPv6 Maintenance WG 1300-1500 Afternoon Session I GrBlrm C INT intarea Internet Area Working Group WG 1520-1720 Afternoon Session II Salon C RTG roll Routing Over Low power and Lossy = networks WG GrBlrm D TSV tsvarea Transport Area Open Meeting=20 TUESDAY, November 6, 2012 0900-1130 Morning Session I Salon E APP httpbis Hypertext Transfer Protocol Bis = WG GrBlrm D INT homenet Home Networking WG 1300-1500 Afternoon Session I GrBlrm C APP core Constrained RESTful Environments = WG WEDNESDAY, November 7, 2012 0900-1130 Morning Session I Salon A SEC jose Javascript Object Signing and = Encryption WG 1300-1430 Afternoon Session I GrBlrm D SEC httpauth HTTP Authentication Mechanisms = BOF THURSDAY, November 8, 2012 0900-1130 Morning Session I Salon A SEC oauth Web Authorization Protocol WG 1300-1500 Afternoon Session I GrBlrm D RTG rtgarea Routing Area Open Meeting=20 Salon E TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1510-1710 Afternoon Session II Salon A OPS eman Energy Management WG GrBlrm C TSV tsvwg Transport Area Working Group WG Salon C SEC saag Security Area Open Meeting=20 FRIDAY, November 9, 2012 0900-1100 Morning Session I Salon D TSV tsvwg Transport Area Working Group WG 1120-1220 Afternoon Session I Salon E APP core Constrained RESTful Environments = WG Salon C INT lwig Light-Weight Implementation = Guidance WG 1230-1330 Afternoon Session II Salon E APP core Constrained RESTful Environments = WG Salon C INT lwig Light-Weight Implementation = Guidance WG From cabo@tzi.org Sun Oct 7 02:32:35 2012 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 33DD921F8522; Sun, 7 Oct 2012 02:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.924 X-Spam-Level: X-Spam-Status: No, score=-105.924 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADCXvlu727Zk; Sun, 7 Oct 2012 02:32:34 -0700 (PDT) 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 4D4D921F8514; Sun, 7 Oct 2012 02:32:33 -0700 (PDT) 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 q979WP7i026511; Sun, 7 Oct 2012 11:32:25 +0200 (CEST) Received: from [192.168.217.105] (p54891E9D.dip.t-dialin.net [84.137.30.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 475A688A; Sun, 7 Oct 2012 11:32:25 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Carsten Bormann In-Reply-To: Date: Sun, 7 Oct 2012 11:32:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "lwip@ietf.org" , "core@ietf.org WG" , roll WG , "6lowpan@ietf.org" <6lowpan@ietf.org> X-Mailer: Apple Mail (2.1498) Subject: Re: [6lowpan] Constrained Node/Network Cluster @ IETF85 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, 07 Oct 2012 09:32:35 -0000 On Oct 5, 2012, at 00:09, Carsten Bormann wrote: > Here is my usual eclectic condensed agenda. ... and here is an update based on yesterday's changes. As you can see, the lwig/core overlap is fixed (thanks, Barry), and = there have been a few other relocations to avoid other conflicts. Gr=FC=DFe, Carsten MONDAY, November 5, 2012 0900-1130 Morning Session I Salon A APP apparea Applications Area Open Meeting - Combined with = APPSAWG Salon D INT 6man IPv6 Maintenance WG 1300-1500 Afternoon Session I Salon D APP httpbis Hypertext Transfer Protocol Bis WG Grand C INT intarea Internet Area Working Group WG 1520-1720 Afternoon Session II Salon C RTG *** roll Routing Over Low power and Lossy networks WG Grand D TSV tsvarea Transport Area Open Meeting 1740-1940 Afternoon Session III Salon E INT *** lwig Light-Weight Implementation Guidance WG TUESDAY, November 6, 2012 0900-1130 Morning Session I Salon E APP httpbis Hypertext Transfer Protocol Bis WG 1300-1500 Afternoon Session I Grand C APP *** core Constrained RESTful Environments WG WEDNESDAY, November 7, 2012 0900-1130 Morning Session I Salon D INT homenet Home Networking WG Salon A SEC jose Javascript Object Signing and Encryption WG 1300-1430 Afternoon Session I Grand D SEC httpauth HTTP Authentication Mechanisms BOF THURSDAY, November 8, 2012 0900-1130 Morning Session I Salon A SEC oauth Web Authorization Protocol WG 1300-1500 Afternoon Session I Salon D OPS v6ops IPv6 Operations WG Grand D RTG rtgarea Routing Area Open Meeting Salon E TSV rmcat RTP Media Congestion Avoidance Techniques WG 1510-1710 Afternoon Session II Salon A OPS eman Energy Management WG Salon D OPS v6ops IPv6 Operations WG Salon C SEC saag Security Area Open Meeting Grand C TSV tsvwg Transport Area Working Group WG FRIDAY, November 9, 2012 0900-1100 Morning Session I Salon D TSV tsvwg Transport Area Working Group WG 1120-1330 Afternoon Session I/II Salon E APP *** core Constrained RESTful Environments WG From teemu.savolainen@nokia.com Fri Oct 12 09:08:53 2012 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 2CA3B21F85C2 for <6lowpan@ietfa.amsl.com>; Fri, 12 Oct 2012 09:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3uh1Da9w8DZ for <6lowpan@ietfa.amsl.com>; Fri, 12 Oct 2012 09:08:51 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0CD21F859E for <6lowpan@ietf.org>; Fri, 12 Oct 2012 09:08:49 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q9CG8hVd019386 for <6lowpan@ietf.org>; Fri, 12 Oct 2012 19:08:46 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.50]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Oct 2012 19:08:43 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.19]) by 008-AM1MMR2-016.mgdnok.nokia.com ([65.54.30.50]) with mapi id 14.02.0309.003; Fri, 12 Oct 2012 18:08:42 +0200 From: To: <6lowpan@ietf.org> Thread-Topic: Noteworthy changes in draft-ietf-6lowpan-btle-11.txt Thread-Index: Ac2okr3m1pAfeRwxSWSrVCY+sN5xbw== Date: Fri, 12 Oct 2012 16:08:41 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962044B03AB@008-AM1MPN1-053.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: 0Ywc1/TmJmZP14okFmB8GKW5sxvyTd3V63AAqnUkVgkdhorCnUZ5ttynUMa7X9zG15CNMDiGjZtJkjGvt9kL7fqLFK9CJx9G+XL4zEHWeOLtXRZim+gA24+Am1YdafhV6QzOH8He+pY/7M92r4Yc5T1EK8dewPiToz+DZzHJ6SDrCuJWnU8tGS4WsvkuvIDf1dDrrbajDUWmEB0bZA4pBsp3gr7QY3T4rKenlf0s0sjBMqr/R+ogjVOxIguSmJ8hiSMrTVSLO3SRfpE3Pn2sqg== x-originating-ip: [172.16.99.12] Content-Type: multipart/alternative; boundary="_000_916CE6CF87173740BC8A2CE443096962044B03AB008AM1MPN1053mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 12 Oct 2012 16:08:43.0714 (UTC) FILETIME=[DA252A20:01CDA893] X-Nokia-AV: Clean Subject: [6lowpan] Noteworthy changes in draft-ietf-6lowpan-btle-11.txt 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, 12 Oct 2012 16:08:53 -0000 --_000_916CE6CF87173740BC8A2CE443096962044B03AB008AM1MPN1053mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We just posted draft-ietf-6lowpan-btle-11.txt that contains both changes ba= sed on the feedback from IESG, but also changes based on the feedback by Ma= rcel De Kogel. Marcel has implemented the draft and found some issues durin= g his work. Please check out the changes and comment if not OK. Revision: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-btle-11.tx= t Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6lowpan-btle-11 The summary of changes based on _Marcel's findings_ are listed below (I hop= e I didn't miss any). IESG's comments (DISCUSSes) are visible in the tracke= r. 1) BT-LE device addressing: it is now clarified that the BT-LE address may = not be globally unique like the MAC in typical interface cards is. The BT-L= E address may also be randomly generated (once in first boot, or more often= per BT-LE device lifetime). This requires that the IID generated from the = random BT-LE address to have Universal/Local bit set to zero. This caused c= hanges to section 2.3 (description of addressing), 3.2 (note that IID can b= e inferred from Neighbor Cache with device address), and 3.2.1 (Universal/L= ocal bit). 2) The L2CAP channel characteristics were too unclear, and are now clarifie= d in the section 3.2. 3) 3.2 had a bug: it said in rev -10 "IID derived directly from the 48-bit = Bluetooth Device addresses", which was wrong because in case of privacy add= resses there was no way to derive IID from 48-bit Bluetooth Device address.= Instead we need to say:"the IID value inferred, with help of Neighbor Cach= e, from the link-layer address". 4) We were missing text related to communications between nodes in the BT-L= E piconet. We had to clarify in section 3.2 and 3.2.4 that the BT-LE slaves= cannot directly talk to each other with link-local addresses. i.e. that in= the star topology each branch is individual link, even if they share the /= 64 prefix. That also causes that the PIO option in RA must have on-link fla= g bit 'L' set to zero. This is updated into section 3.2.1. Due the lack of = means for BT-LE slaves to talk to each other with link-local addresses, the= piconet needs to be numbered with ULA if BT-LE slave-to-slave communicatio= ns are needed and global addresses are not present (text added to 3.2.4). Best regards, Teemu --_000_916CE6CF87173740BC8A2CE443096962044B03AB008AM1MPN1053mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We just posted draft-ietf-6lowpan-btle-11.txt that c= ontains both changes based on the feedback from IESG, but also changes base= d on the feedback by Marcel De Kogel. Marcel has implemented the draft and = found some issues during his work.

 

Please check out the changes and comment if not OK.<= o:p>

 

Revision: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-btle-11.txt=

Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6lowpan-btle-11

 

The summary of changes based on _Marcel’s f= indings_ are listed below (I hope I didn’t miss any). IESG’= s comments (DISCUSSes) are visible in the tracker.

 

1) BT-LE device addressing: it is now clarified t= hat the BT-LE address may not be globally unique like the MAC in typical in= terface cards is. The BT-LE address may also be randomly generated (once in= first boot, or more often per BT-LE device lifetime). This requires that the IID generated from the random BT-= LE address to have Universal/Local bit set to zero. This caused changes to = section 2.3 (description of addressing), 3.2 (note that IID can be inferred= from Neighbor Cache with device address), and 3.2.1 (Universal/Local bit).

 

2) The L2CAP channel characteristics were too unc= lear, and are now clarified in the section 3.2.

 

3) 3.2 had a bug: it said in rev -10 "IID de= rived directly from the 48-bit Bluetooth Device addresses", which was = wrong because in case of privacy addresses there was no way to derive IID f= rom 48-bit Bluetooth Device address. Instead we need to say:"the IID value inferred, with help of Neighbor Cache, = from the link-layer address".

 

4) We were missing text related to communications= between nodes in the BT-LE piconet. We had to clarify in section 3.2 and 3= .2.4 that the BT-LE slaves cannot directly talk to each other with link-loc= al addresses. i.e. that in the star topology each branch is individual link, even if they share the /64 prefix= . That also causes that the PIO option in RA must have on-link flag bit 'L'= set to zero. This is updated into section 3.2.1. Due the lack of means for= BT-LE slaves to talk to each other with link-local addresses, the piconet needs to be numbered with ULA if BT= -LE slave-to-slave communications are needed and global addresses are not p= resent (text added to 3.2.4).

 

Best regards,

 

Teemu

--_000_916CE6CF87173740BC8A2CE443096962044B03AB008AM1MPN1053mg_-- From Gerald.Paprocki@us.elster.com Fri Oct 12 12:10:03 2012 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 3CD0121F8701 for <6lowpan@ietfa.amsl.com>; Fri, 12 Oct 2012 12:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.992 X-Spam-Level: X-Spam-Status: No, score=-5.992 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAoqf6fz1Hgu for <6lowpan@ietfa.amsl.com>; Fri, 12 Oct 2012 12:10:02 -0700 (PDT) Received: from mail53.messagelabs.com (mail53.messagelabs.com [216.82.249.211]) by ietfa.amsl.com (Postfix) with SMTP id 9756F21F86FC for <6lowpan@ietf.org>; Fri, 12 Oct 2012 12:10:02 -0700 (PDT) X-Env-Sender: Gerald.Paprocki@us.elster.com X-Msg-Ref: server-4.tower-53.messagelabs.com!1350069001!6062091!2 X-Originating-IP: [129.179.1.27] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21160 invoked from network); 12 Oct 2012 19:10:01 -0000 Received: from ip27.net129179-1.block1.us.syntegra.com (HELO us-smtp01.smtp.elster.com) (129.179.1.27) by server-4.tower-53.messagelabs.com with SMTP; 12 Oct 2012 19:10:01 -0000 Auto-Submitted: auto-generated From: Gerald.Paprocki@us.elster.com To: 6lowpan@ietf.org Message-ID: Date: Fri, 12 Oct 2012 15:09:00 -0400 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.2FP3|July 10, 2011) at 10/12/2012 03:01:44 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [6lowpan] AUTO: Gerald Paprocki is out of the office (returning 10/15/2012) 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, 12 Oct 2012 19:10:03 -0000 I am out of the office until 10/15/2012. I am out of the office and will be returning Monday 15th. If assistance is required during my absence please contact one of my primes below. - IP AxisLink Secure Tunnel server - Inyong Park @ 919-250-5698 - EA_MS Interfaces - Bill Phillips @ 919-212-4888 - EA Inspector - Ying Xu @ 919-250-5446 Note: This is an automated response to your message "6lowpan Digest, Vol 92, Issue 3" sent on 10/12/2012 3:00:17 PM. This is the only notification you will receive while this person is away. From rdroms.ietf@gmail.com Mon Oct 22 10:59:12 2012 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 2275C21F8B64 for <6lowpan@ietfa.amsl.com>; Mon, 22 Oct 2012 10:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfdNY0-AvByy for <6lowpan@ietfa.amsl.com>; Mon, 22 Oct 2012 10:59:05 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC0C21F8B46 for <6lowpan@ietf.org>; Mon, 22 Oct 2012 10:59:05 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3592317vcb.31 for <6lowpan@ietf.org>; Mon, 22 Oct 2012 10:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:x-mailer:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=o5rkCnaxow4XvfcyHzlquOf1UFQWHLIBjXCp6CyKSIk=; b=CPqshoDU8Ze+/6+KoA9RKM3g77JOS3tFDnRnArxnImy157Tvybyxs5IWOxKw3DdAxX h1VDi0Y8vLDkvY+ilymxizq8BBFLfgIMElhaXxl7FHIRDr45qU17wFQtH/bzsTsF5n2J LBskdCf171oTbr4e6AG1Qfj5AY9yeHVsAreAfJyURyYVQoX87WXEazw3skgVuO2+NIZK 8qOKcfIVi1zHVQEkPV+KeAHQLHjbFpLDfg7tL+ZTPZtkN9qguqS8JE69/ydev45aNB6n IGkS7wPbECNzkUA21rpxX8UF7TL0wFhB/+I25zBAV1A+6nHSK4vMWuLpiCwZvzmA0Iw2 8fUA== Received: by 10.52.36.40 with SMTP id n8mr12832363vdj.52.1350928744603; Mon, 22 Oct 2012 10:59:04 -0700 (PDT) Received: from [10.138.94.46] (mobile-198-228-194-105.mycingular.net. [198.228.194.105]) by mx.google.com with ESMTPS id cz16sm10725919vdb.15.2012.10.22.10.59.03 (version=SSLv3 cipher=OTHER); Mon, 22 Oct 2012 10:59:03 -0700 (PDT) From: Ralph Droms X-Mailer: Apple Mail (2.1283) Content-Type: text/plain; charset=us-ascii Message-Id: <89A369B2-374C-4513-8D65-1D2D53DD820A@gmail.com> Date: Mon, 22 Oct 2012 13:59:00 -0400 To: 6lowpan 6lowpan <6lowpan@ietf.org> Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Subject: [6lowpan] AD review of draft-kelsey-intarea-mesh-link-establishment 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, 22 Oct 2012 17:59:12 -0000 I've been asked to sponsor draft-kelsey-intarea-mesh-link-establishment as a= n AD-sponsored individual submission. As part of my AD review of the docume= nt, I'm soliciting input from a variety of relevant communities, including t= he 6lowpan mailing list. I expect to complete my review next week and then send the document out for I= ETF last call. Please respond with comments by next Monday, Oct 29, either t= o the mailing list or directly to me. I'm aware that the last call will ov= erlap the IETF but it will be a four week last call, which should be enough f= or reviewing this document. - Ralph From qiuying@i2r.a-star.edu.sg Mon Oct 22 20:50:23 2012 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 BF3911F0C54; Mon, 22 Oct 2012 20:50: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSFOis-8d37E; Mon, 22 Oct 2012 20:50:23 -0700 (PDT) Received: from gw2.scei.a-star.edu.sg (gw2.scei.a-star.edu.sg [192.122.140.11]) by ietfa.amsl.com (Postfix) with ESMTP id 389201F0429; Mon, 22 Oct 2012 20:50:21 -0700 (PDT) Received: from pps.filterd (gw2 [127.0.0.1]) by gw2.scei.a-star.edu.sg (8.14.4/8.14.4) with SMTP id q9N3mEf9021247; Tue, 23 Oct 2012 11:50:19 +0800 Received: from s3-cas05.shared-svc.local ([10.217.253.201]) by gw2.scei.a-star.edu.sg with ESMTP id 185k4h01gw-1; Tue, 23 Oct 2012 11:50:19 +0800 Received: from Win7PC (10.217.253.130) by S3-CAS05.shared-svc.local (10.217.253.201) with Microsoft SMTP Server id 14.1.339.1; Tue, 23 Oct 2012 11:50:18 +0800 From: QIU Ying To: , <6lowpan@ietf.org> Date: Tue, 23 Oct 2012 11:56:34 +0800 Message-ID: <015801cdb0d2$649305b0$2db91110$@a-star.edu.sg> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2wkf59C4jlyJFSRzOqX2NnRKc2WQAPaWDQ Content-Language: en-sg X-Originating-IP: [10.217.253.130] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-10-23_02:2012-10-22, 2012-10-23, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=9 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1210220422 Content-Type: text/plain; charset="UTF-8" Subject: [6lowpan] FW: New Version Notification for draft-qiu-roll-kemp-02.txt 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, 23 Oct 2012 03:50:23 -0000 Hi, The KEMP draft is updated. The messages in the draft will be carried in KMP= format proposed by IEEE802.15.9 working group so that the KEMP protocol is= compatible with IEEE802.15.9 and could be deployed in layer 2. Regards Qiu Ying =20=20=20=20 -----Original Message----- A new version of I-D, draft-qiu-roll-kemp-02.txt has been successfully subm= itted by Ying Qiu and posted to the IETF repository. Filename: draft-qiu-roll-kemp Revision: 02 Title: Lightweight Key Establishment and Management Protocol in Dynamic S= ensor Networks (KEMP) Creation date: 2012-10-22 WG ID: Individual Submission Number of pages: 20 URL: http://www.ietf.org/internet-drafts/draft-qiu-roll-kemp-02= .txt Status: http://datatracker.ietf.org/doc/draft-qiu-roll-kemp Htmlized: http://tools.ietf.org/html/draft-qiu-roll-kemp-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-qiu-roll-kemp-02 Abstract: When a sensor node roams within a very large and distributed wireless sensor network, which consists of numerous sensor nodes, its routing path and neighborhood keep changing. In order to provide a high level of security in this environment, the moving sensor node needs to be authenticated to new neighboring nodes as well as to establish a key for secure communication. The document proposes an efficient and scalable protocol to establish and update the secure key in a dynamic wireless sensor network environment. The protocol guarantees that two sensor nodes share at least one key with probability 1 (100%) with less memory and energy cost, while not causing considerable communication overhead. =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 The IETF Secretariat Institute for Infocomm Research disclaimer: "This email is confidential an= d may be privileged. If you are not the intended recipient, please delete i= t and notify us immediately. Please do not copy or use it for any purpose, = or disclose its contents to any other person. Thank you." From qiuying@i2r.a-star.edu.sg Mon Oct 22 21:00:37 2012 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 393E61F0C54; Mon, 22 Oct 2012 21:00:37 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6mWQTnJDmRk; Mon, 22 Oct 2012 21:00:36 -0700 (PDT) Received: from gw1.scei.a-star.edu.sg (gw1.scei.a-star.edu.sg [192.122.140.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4B15C1F0C69; Mon, 22 Oct 2012 21:00:36 -0700 (PDT) Received: from S3-CAS05.shared-svc.local ([10.217.253.201]) by gw1.scei.a-star.edu.sg (8.14.4/8.14.4) with ESMTP id q9N40YqE009699; Tue, 23 Oct 2012 12:00:34 +0800 Received: from Win7PC (10.217.253.130) by S3-CAS05.shared-svc.local (10.217.253.201) with Microsoft SMTP Server id 14.1.339.1; Tue, 23 Oct 2012 12:00:34 +0800 From: QIU Ying To: "'QIU Ying'" , , <6lowpan@ietf.org> References: In-Reply-To: Date: Tue, 23 Oct 2012 12:06:49 +0800 Message-ID: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2wkf59C4jlyJFSRzOqX2NnRKc2WQAPaWDQAADK/bA= Content-Language: en-sg X-Originating-IP: [10.217.253.130] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-10-23_02:2012-10-22, 2012-10-23, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1210220426 Subject: Re: [6lowpan] slot for New Version of draft-qiu-roll-kemp-02.txt 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, 23 Oct 2012 04:00:37 -0000 Dear JV, Might I ask a 5-10min slot to update the draft? Sorry for late applying as I were not sure if I am able to attend IETF85. Regards and Thanks Qiu Ying > -----Original Message----- > From: QIU Ying [mailto:qiuying@i2r.a-star.edu.sg] > Sent: Tuesday, October 23, 2012 11:57 AM > To: 'roll@ietf.org'; '6lowpan@ietf.org' > Subject: FW: New Version Notification for draft-qiu-roll-kemp-02.txt > > Hi, > > The KEMP draft is updated. The messages in the draft will be carried in > KMP format proposed by IEEE802.15.9 working group so that the KEMP > protocol is compatible with IEEE802.15.9 and could be deployed in layer > 2. > > Regards > Qiu Ying > > > -----Original Message----- > > A new version of I-D, draft-qiu-roll-kemp-02.txt has been successfully > submitted by Ying Qiu and posted to the IETF repository. > > Filename: draft-qiu-roll-kemp > Revision: 02 > Title: Lightweight Key Establishment and Management > Protocol in Dynamic Sensor Networks (KEMP) > Creation date: 2012-10-22 > WG ID: Individual Submission > Number of pages: 20 > URL: http://www.ietf.org/internet-drafts/draft-qiu-roll- > kemp-02.txt > Status: http://datatracker.ietf.org/doc/draft-qiu-roll-kemp > Htmlized: http://tools.ietf.org/html/draft-qiu-roll-kemp-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-qiu-roll-kemp- > 02 > > Abstract: > When a sensor node roams within a very large and distributed > wireless > sensor network, which consists of numerous sensor nodes, its routing > path and neighborhood keep changing. In order to provide a high > level of security in this environment, the moving sensor node needs > to be authenticated to new neighboring nodes as well as to establish > a key for secure communication. The document proposes an efficient > and scalable protocol to establish and update the secure key in a > dynamic wireless sensor network environment. The protocol > guarantees > that two sensor nodes share at least one key with probability 1 > (100%) with less memory and energy cost, while not causing > considerable communication overhead. > > > > > The IETF Secretariat Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." From sarikaya2012@gmail.com Tue Oct 23 13:23:24 2012 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 79E881F0424; Tue, 23 Oct 2012 13:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wc25LD7xkDr; Tue, 23 Oct 2012 13:23:23 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id A26D71F0CA1; Tue, 23 Oct 2012 13:23:23 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so6939554iec.31 for ; Tue, 23 Oct 2012 13:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=6Dtn5gQLIXLKoVJ8/BQKeyqYyv7eSgCnnHmFU3Vymmo=; b=Ou0f72iTfqNhs/SGXLT9M5jXRagmfwjts+Llwq+fzicyVeuQ4abS51D/xMz/f/k2VQ UFmQu38LXum1aTR5YuKW87USrs85/5qz3ZM3l1ruJRLvZqkM2j0OZpt+BcFCsrxOWg/K UnB/kzp2r7Yb8SfXQdv1DCbgV0CA3UyYnAII8dVJOyEaLWZrTc3234AzIKw9924J0PIn 1Og6GorCvLgfmQ85XKU96lnr20xDIHKjNo4JQLp/7kRfGgFnB24FNWisInB5vcouFdTq seLxP6/O/A1D14npJcmfd2BjL0+Av0f/ZtKi1OkSd7n6UWnRuv+MqjygMQagUgakmbSK TRng== MIME-Version: 1.0 Received: by 10.50.5.205 with SMTP id u13mr306986igu.37.1351023803199; Tue, 23 Oct 2012 13:23:23 -0700 (PDT) Received: by 10.231.85.26 with HTTP; Tue, 23 Oct 2012 13:23:23 -0700 (PDT) In-Reply-To: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg> References: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg> Date: Tue, 23 Oct 2012 15:23:23 -0500 Message-ID: From: Behcet Sarikaya To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Keoh, Sye Loong" , 6lowpan@ietf.org Subject: Re: [6lowpan] slot for New Version of draft-qiu-roll-kemp-02.txt 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: Tue, 23 Oct 2012 20:23:24 -0000 Hi Jean-Pierre, all, There is some overlap with this draft and our work on Secure Bootstrapping that was being pursued until recently in Core WG. It is still not clear to me which WG should be home for this activity, can you please clarify? Regards, Behcet On Mon, Oct 22, 2012 at 11:06 PM, QIU Ying wrot= e: > Dear JV, > > Might I ask a 5-10min slot to update the draft? > > Sorry for late applying as I were not sure if I am able to attend IETF85. > > Regards and Thanks > Qiu Ying > > >> -----Original Message----- >> From: QIU Ying [mailto:qiuying@i2r.a-star.edu.sg] >> Sent: Tuesday, October 23, 2012 11:57 AM >> To: 'roll@ietf.org'; '6lowpan@ietf.org' >> Subject: FW: New Version Notification for draft-qiu-roll-kemp-02.txt >> >> Hi, >> >> The KEMP draft is updated. The messages in the draft will be carried in >> KMP format proposed by IEEE802.15.9 working group so that the KEMP >> protocol is compatible with IEEE802.15.9 and could be deployed in layer >> 2. >> >> Regards >> Qiu Ying >> >> >> -----Original Message----- >> >> A new version of I-D, draft-qiu-roll-kemp-02.txt has been successfully >> submitted by Ying Qiu and posted to the IETF repository. >> >> Filename: draft-qiu-roll-kemp >> Revision: 02 >> Title: Lightweight Key Establishment and Management >> Protocol in Dynamic Sensor Networks (KEMP) >> Creation date: 2012-10-22 >> WG ID: Individual Submission >> Number of pages: 20 >> URL: http://www.ietf.org/internet-drafts/draft-qiu-roll- >> kemp-02.txt >> Status: http://datatracker.ietf.org/doc/draft-qiu-roll-kemp >> Htmlized: http://tools.ietf.org/html/draft-qiu-roll-kemp-02 >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-qiu-roll-kemp- >> 02 >> >> Abstract: >> When a sensor node roams within a very large and distributed >> wireless >> sensor network, which consists of numerous sensor nodes, its routing >> path and neighborhood keep changing. In order to provide a high >> level of security in this environment, the moving sensor node needs >> to be authenticated to new neighboring nodes as well as to establish >> a key for secure communication. The document proposes an efficient >> and scalable protocol to establish and update the secure key in a >> dynamic wireless sensor network environment. The protocol >> guarantees >> that two sensor nodes share at least one key with probability 1 >> (100%) with less memory and energy cost, while not causing >> considerable communication overhead. >> >> >> >> >> The IETF Secretariat > > Institute for Infocomm Research disclaimer: "This email is confidential = and may be privileged. If you are not the intended recipient, please delete= it and notify us immediately. Please do not copy or use it for any purpose= , or disclose its contents to any other person. Thank you." > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Thu Oct 25 01:12:11 2012 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 AE5E321F89B6; Thu, 25 Oct 2012 01:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.114 X-Spam-Level: X-Spam-Status: No, score=-106.114 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTLLZ16mDoCj; Thu, 25 Oct 2012 01:12:11 -0700 (PDT) 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 C609421F89CB; Thu, 25 Oct 2012 01:12:10 -0700 (PDT) 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 q9P8Bw0a014709; Thu, 25 Oct 2012 10:12:00 +0200 (CEST) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1D491D73; Thu, 25 Oct 2012 10:11:46 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Carsten Bormann Date: Thu, 25 Oct 2012 10:11:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4FB2FFE4-ABD7-44DD-84F0-C5BA38493891@tzi.org> To: "6lowpan@ietf.org" <6lowpan@ietf.org>, "core@ietf.org WG" X-Mailer: Apple Mail (2.1499) Subject: [6lowpan] IETF85: Adaptation Layer Fragmentation Indication (ALFI) on intarea agenda X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "6lowpan@ietf.org" <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, 25 Oct 2012 08:12:11 -0000 One problem we have in 6LoWPAN networks is that the 6LoWPAN = fragmentation is "transparent", i.e. there is no equivalent of Path MTU = discovery that would enable applications to make informed decisions = about the packet sizes they choose. Since that problem is not specific to 6LoWPAN, and not even to IPv6, it = is being discussed in the intarea working group. (The specific proposal is currently focused on IPv6, however.) If you care about this subject, below is a snippet from the current = intarea agenda (which, of course, can change). Gr=FC=DFe, Carsten http://www.ietf.org/proceedings/85/agenda/agenda-85-intarea says: > intarea WG Agenda=20 > IETF 85 > Monday, November 5, 2012 > 1300-1500 Afternoon Session I >=20 > 1. Agenda Bashing, WG & Document Status (Chairs) 10 minutes > =20 > 2. Adaptation Layer Fragmentation Indication > Carsten Bormann 20 minutes > draft-bormann-intarea-alfi-01 >=20 > Objective: >=20 > Present the draft that describes a mechanism by which an > IPv6 adaptation layer can indicate the presence of > fragmentation capability and can specify preferred packet > sizes for the link type. The goal is to publicize the work > and identify a suitable venue to continue this work. From Gerald.Paprocki@us.elster.com Thu Oct 25 12:02:24 2012 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 5018621F89A7 for <6lowpan@ietfa.amsl.com>; Thu, 25 Oct 2012 12:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.146 X-Spam-Level: X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nA+0dolG3WUW for <6lowpan@ietfa.amsl.com>; Thu, 25 Oct 2012 12:02:23 -0700 (PDT) Received: from mail197.messagelabs.com (mail197.messagelabs.com [216.82.254.83]) by ietfa.amsl.com (Postfix) with SMTP id ADAE921F892D for <6lowpan@ietf.org>; Thu, 25 Oct 2012 12:02:23 -0700 (PDT) X-Env-Sender: Gerald.Paprocki@us.elster.com X-Msg-Ref: server-10.tower-197.messagelabs.com!1351191739!10699401!1 X-Originating-IP: [129.179.1.27] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30342 invoked from network); 25 Oct 2012 19:02:22 -0000 Received: from ip27.net129179-1.block1.us.syntegra.com (HELO us-smtp01.smtp.elster.com) (129.179.1.27) by server-10.tower-197.messagelabs.com with SMTP; 25 Oct 2012 19:02:22 -0000 Auto-Submitted: auto-generated From: Gerald.Paprocki@us.elster.com To: 6lowpan@ietf.org Message-ID: Date: Thu, 25 Oct 2012 15:02:32 -0400 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.2FP3|July 10, 2011) at 10/25/2012 02:53:46 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [6lowpan] AUTO: Gerald Paprocki is out of the office (returning 10/29/2012) 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: Thu, 25 Oct 2012 19:02:24 -0000 I am out of the office until 10/29/2012. I am out of the office and will be returning Monday Oct 29th. If assistance is required during my absence please contact one of my primes below. - IP AxisLink Secure Tunnel server - Inyong Park @ 919-250-5698 - EA_MS Interfaces - Bill Phillips @ 919-212-4888 - EA Inspector - Ying Xu @ 919-250-5446 Note: This is an automated response to your message "6lowpan Digest, Vol 92, Issue 8" sent on 10/25/2012 3:00:36 PM. This is the only notification you will receive while this person is away. From mcr@sandelman.ca Thu Oct 25 14:44:06 2012 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 659F021F88CF; Thu, 25 Oct 2012 14:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YP69kDHPtESV; Thu, 25 Oct 2012 14:44:06 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 02A7621F88CE; Thu, 25 Oct 2012 14:44:06 -0700 (PDT) Received: from sandelman.ca (74-115-197-230.eng.wind.ca [74.115.197.230]) by relay.sandelman.ca (Postfix) with ESMTPS id 5247681A9; Thu, 25 Oct 2012 17:36:27 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 08549CA0CD; Thu, 25 Oct 2012 11:01:11 -0400 (EDT) From: Michael Richardson To: sarikaya@ieee.org In-reply-to: References: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg> Comments: In-reply-to Behcet Sarikaya message dated "Tue, 23 Oct 2012 15:23:23 -0500." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 25 Oct 2012 11:01:10 -0400 Message-ID: <1116.1351177270@sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org, "Keoh, Sye Loong" , 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] slot for New Version of draft-qiu-roll-kemp-02.txt 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: Thu, 25 Oct 2012 21:44:06 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Behcet Sarikaya wrote: BS> There is some overlap with this draft and our work on Secure BS> Bootstrapping that was being pursued until recently in Core WG. BS> It is still not clear to me which WG should be home for this activi= ty, BS> can you please clarify? I thought that this was the point of SOLACE. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQiVQ2AAoJEKD0KQ7Gj3P2pn8H/0NqHQYbX+0hA80YL1AOdtLE YOmWSjqhtAhy0j7aAIuLfsxSkpuspQZA6DgW4Wk0IKiXrc8wBVShd1xbf+yWmUTz xSQw7aVEgKBj951aXQ7fNjm+2XJKjq6SevEVqGGOHPjOFVvsYUHqNrK/HZziBRMy zv2ifx8opO7ItOoMZIMc7mHjHGLGLKyWDLPRJ1ZKjw9vlY5cflnpBRrcsuDy0uJo aVdTMwZDAPHCU+0rxxn+Or7XeFNcw6IrQug0tzSEZ6aQXLy0LU6Ct6zmt0IcJJzp p8wgwDYGP2BHqNjte6EdAVCOXTPbMYKBH6uSnREJuEyKLJ9S0w9FlsNGFwTwUR8= =n7GN -----END PGP SIGNATURE----- --=-=-=-- From qiuying@i2r.a-star.edu.sg Mon Oct 29 08:56:50 2012 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 04CDB21F871D; Mon, 29 Oct 2012 08:56:50 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1m7MtgTZzRoI; Mon, 29 Oct 2012 08:56:49 -0700 (PDT) Received: from gw3.scei.a-star.edu.sg (gw3.scei.a-star.edu.sg [192.122.140.12]) by ietfa.amsl.com (Postfix) with ESMTP id 03F4021F86CA; Mon, 29 Oct 2012 08:56:48 -0700 (PDT) Received: from pps.filterd (gw3 [127.0.0.1]) by gw3.scei.a-star.edu.sg (8.14.4/8.14.4) with SMTP id q9TFtsnH013787; Mon, 29 Oct 2012 23:56:44 +0800 Received: from s3-cas05.shared-svc.local ([10.217.253.201]) by gw3.scei.a-star.edu.sg with ESMTP id 189se9g36r-1; Mon, 29 Oct 2012 23:56:44 +0800 Received: from Win7PC (10.217.253.130) by S3-CAS05.shared-svc.local (10.217.253.201) with Microsoft SMTP Server id 14.1.339.1; Mon, 29 Oct 2012 23:56:43 +0800 From: QIU Ying To: , <6lowpan@ietf.org> References: In-Reply-To: Date: Tue, 30 Oct 2012 00:03:08 +0800 Message-ID: <02a001cdb5ee$e34164d0$a9c42e70$@a-star.edu.sg> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2wkf59C4jlyJFSRzOqX2NnRKc2WQAPaWDQAUeD8xA= Content-Language: en-sg X-Originating-IP: [10.217.253.130] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-10-29_02:2012-10-29, 2012-10-29, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=9 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1210290156 Content-Type: text/plain; charset="UTF-8" Subject: Re: [6lowpan] New Version Notification for draft-qiu-roll-kemp: Do need an alternative security design ? 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, 29 Oct 2012 15:56:50 -0000 Dear all, Do need an alternative security design instead of the current public key pr= otocols in key establishment? It's one of arguments in previous WG meeting. My answer is yes. Actually, the similar discussion had been raised in mobil= e IPv6 WG (RFC4225). Besides the authentication, another major check is the reachability checkin= g to verify if the claimed mobile node is reachable (section 4.1). RFC4225 = also explains why the current Public Key Infrastructure (i.e. IKE) is not a= ccepted in mobile IPv6 (section 5.2). =20=20 Frankly, the scheme used in KEMP is not fresh new. It is in style of the po= pular Kerberos. Instead of sending the ticket to visiting server from clien= t directly in Kerberos, the ticket is sent to the visiting server (new near= by router in KEMP) from the KDC (base station in KEMP). The benefit of this= modification includes: 1) reduce the communication; 2) the client (mobile = node in KEMP) is check if reachable from the 3rd party (new nearby router);= 3) revocation in time. Thank to many WG participants commenting on the draft (inclusive Rene Strui= k, Steve Childress, Shoichi Sakane, Greg Zaverucha, Matthew Campagna), the = draft should be more mature and stronger. Regards Qiu Ying > -----Original Message----- > From: QIU Ying [mailto:qiuying@i2r.a-star.edu.sg] > Sent: Tuesday, October 23, 2012 11:57 AM > To: 'roll@ietf.org'; '6lowpan@ietf.org' > Subject: FW: New Version Notification for draft-qiu-roll-kemp-02.txt >=20 > Hi, >=20 > The KEMP draft is updated. The messages in the draft will be carried in > KMP format proposed by IEEE802.15.9 working group so that the KEMP > protocol is compatible with IEEE802.15.9 and could be deployed in layer > 2. >=20 > Regards > Qiu Ying >=20 >=20 > -----Original Message----- >=20 > A new version of I-D, draft-qiu-roll-kemp-02.txt has been successfully > submitted by Ying Qiu and posted to the IETF repository. >=20 > Filename: draft-qiu-roll-kemp > Revision: 02 > Title: Lightweight Key Establishment and Management > Protocol in Dynamic Sensor Networks (KEMP) > Creation date: 2012-10-22 > WG ID: Individual Submission > Number of pages: 20 > URL: http://www.ietf.org/internet-drafts/draft-qiu-roll- > kemp-02.txt > Status: http://datatracker.ietf.org/doc/draft-qiu-roll-kemp > Htmlized: http://tools.ietf.org/html/draft-qiu-roll-kemp-02 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-qiu-roll-kemp- > 02 >=20 > Abstract: > When a sensor node roams within a very large and distributed > wireless > sensor network, which consists of numerous sensor nodes, its routing > path and neighborhood keep changing. In order to provide a high > level of security in this environment, the moving sensor node needs > to be authenticated to new neighboring nodes as well as to establish > a key for secure communication. The document proposes an efficient > and scalable protocol to establish and update the secure key in a > dynamic wireless sensor network environment. The protocol > guarantees > that two sensor nodes share at least one key with probability 1 > (100%) with less memory and energy cost, while not causing > considerable communication overhead. >=20 >=20 >=20 >=20 > The IETF Secretariat Institute for Infocomm Research disclaimer: "This email is confidential an= d may be privileged. If you are not the intended recipient, please delete i= t and notify us immediately. Please do not copy or use it for any purpose, = or disclose its contents to any other person. Thank you." From qiuying@i2r.a-star.edu.sg Mon Oct 29 09:42:55 2012 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 C9CBB21F86F0; Mon, 29 Oct 2012 09:42:55 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Gv5GSQZqe97; Mon, 29 Oct 2012 09:42:55 -0700 (PDT) Received: from gw2.scei.a-star.edu.sg (gw2.scei.a-star.edu.sg [192.122.140.11]) by ietfa.amsl.com (Postfix) with ESMTP id 91CF521F86E5; Mon, 29 Oct 2012 09:42:54 -0700 (PDT) Received: from pps.filterd (gw2 [127.0.0.1]) by gw2.scei.a-star.edu.sg (8.14.4/8.14.4) with SMTP id q9TGcVH5001928; Tue, 30 Oct 2012 00:42:45 +0800 Received: from s3-cas05.shared-svc.local ([10.217.253.201]) by gw2.scei.a-star.edu.sg with ESMTP id 189vx1018p-1; Tue, 30 Oct 2012 00:42:45 +0800 Received: from Win7PC (10.217.253.130) by S3-CAS05.shared-svc.local (10.217.253.201) with Microsoft SMTP Server id 14.1.339.1; Tue, 30 Oct 2012 00:42:45 +0800 From: QIU Ying To: "'Michael Richardson'" , References: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg> <1116.1351177270@sandelman.ca> In-Reply-To: <1116.1351177270@sandelman.ca> Date: Tue, 30 Oct 2012 00:49:09 +0800 Message-ID: <02a101cdb5f5$51109a70$f331cf50$@a-star.edu.sg> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2y+eJ8zB/KFlDFQnGBF/2JcO4RVwC9yeiA Content-Language: en-sg X-Originating-IP: [10.217.253.130] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-10-29_02:2012-10-29, 2012-10-29, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1210290171 Cc: roll@ietf.org, "'Keoh, Sye Loong'" , 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] slot for New Version of draft-qiu-roll-kemp-02.txt 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, 29 Oct 2012 16:42:55 -0000 Hi, Behcet Initially, I was also confusing which WG is best for this kind solution. The draft finally settled down in the ROLL WG because, at that time, there were many RFCs in ROLL WG about the requirements for LL networks and the KEMP draft is designed to provide a security solution to meet the requirements mentioned in these RFCs. Regards Qiu Ying > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Michael Richardson > Sent: Thursday, October 25, 2012 11:01 PM > To: sarikaya@ieee.org > Cc: roll@ietf.org; Keoh, Sye Loong; 6lowpan@ietf.org > Subject: Re: [Roll] [6lowpan] slot for New Version of draft-qiu-roll- > kemp-02.txt > > > Behcet Sarikaya wrote: > BS> There is some overlap with this draft and our work on Secure > BS> Bootstrapping that was being pursued until recently in Core WG. > > BS> It is still not clear to me which WG should be home for this > activity, > BS> can you please clarify? > > I thought that this was the point of SOLACE. > > -- > Michael Richardson > -on the road- > From cabo@tzi.org Mon Oct 29 09:56:46 2012 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 7485A21F8703; Mon, 29 Oct 2012 09:56:46 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-NEfLvJ9glD; Mon, 29 Oct 2012 09:56:46 -0700 (PDT) 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 A1D4021F86E7; Mon, 29 Oct 2012 09:56:45 -0700 (PDT) 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 q9TGuRQw003860; Mon, 29 Oct 2012 17:56:27 +0100 (CET) Received: from eduroam-0380.wlan.uni-bremen.de (eduroam-0380.wlan.uni-bremen.de [134.102.17.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40B57B5; Mon, 29 Oct 2012 17:56:27 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <02a101cdb5f5$51109a70$f331cf50$@a-star.edu.sg> Date: Mon, 29 Oct 2012 17:56:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg> <1116.1351177270@sandelman.ca> <02a101cdb5f5$51109a70$f331cf50$@a-star.edu.sg> To: QIU Ying X-Mailer: Apple Mail (2.1499) Cc: 'Michael Richardson' , "'Keoh, Sye Loong'" , roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] slot for New Version of draft-qiu-roll-kemp-02.txt 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, 29 Oct 2012 16:56:46 -0000 On Oct 29, 2012, at 17:49, QIU Ying wrote: > which WG is best I think right now we don't know that. All WGs in the CN/N cluster have the problem and have some unfulfilled = charter item in this space. So we can continue to play tourists and use the WG that happens to have = the largest amount of space on the agenda... In SOLACE, we are discussing right now when to meet during the Atlanta = IETF. It looks like we will meet on Sunday before the reception for some = brainstorming and maybe on Monday during lunchtime for getting = organized. If you are interested, please join the SOLACE mailing list: https://www.ietf.org/mailman/admin/solace Gr=FC=DFe, Carsten From stephen.farrell@cs.tcd.ie Mon Oct 29 10:31:48 2012 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 5756721F86F3; Mon, 29 Oct 2012 10:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4wftrsxB20w; Mon, 29 Oct 2012 10:31:47 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BD34921F86E8; Mon, 29 Oct 2012 10:31:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2D760C781; Mon, 29 Oct 2012 17:31:26 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFTlVnDAqwCX; Mon, 29 Oct 2012 17:31:24 +0000 (GMT) Received: from [10.87.48.4] (unknown [86.42.183.189]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0694FC77B; Mon, 29 Oct 2012 17:31:24 +0000 (GMT) Message-ID: <508EBD6B.1070606@cs.tcd.ie> Date: Mon, 29 Oct 2012 17:31:23 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121017 Thunderbird/16.0.1 MIME-Version: 1.0 To: Carsten Bormann References: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg> <1116.1351177270@sandelman.ca> <02a101cdb5f5$51109a70$f331cf50$@a-star.edu.sg> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "Turner, Sean P." , "'Keoh, Sye Loong'" , roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] slot for New Version of draft-qiu-roll-kemp-02.txt 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, 29 Oct 2012 17:31:48 -0000 Carsten, all, On 10/29/2012 04:56 PM, Carsten Bormann wrote: > On Oct 29, 2012, at 17:49, QIU Ying wrote: > >> which WG is best > > I think right now we don't know that. > All WGs in the CN/N cluster have the problem and have some unfulfilled charter item in this space. > So we can continue to play tourists and use the WG that happens to have the largest amount of space on the agenda... > > In SOLACE, we are discussing right now when to meet during the Atlanta IETF. Would it be timely to spend 10 minutes on this during the saag session? I'd really like that the security area not end up being surprised by whatever is eventually decided so getting a presentation at saag would be useful at the point where you more or less know the direction, but are still flexible enough to deal with someone who e.g. points out significant security issues. It might be that waiting another meeting cycle or two would be better if the basic ideas aren't yet firmed up. So, is this work far enough advanced already for that to be productive now or is it still so early it'd be counter-productive? (And presenting at saag before you're ready could very well be counter-productive - it can be a tough audience;-) Ta, S. > It looks like we will meet on Sunday before the reception for some brainstorming and maybe on Monday during lunchtime for getting organized. > If you are interested, please join the SOLACE mailing list: > > https://www.ietf.org/mailman/admin/solace > > Grüße, Carsten > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > From cabo@tzi.org Mon Oct 29 10:48:58 2012 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 75B1F21F86EA; Mon, 29 Oct 2012 10:48:58 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENR-w95KubpX; Mon, 29 Oct 2012 10:48:58 -0700 (PDT) 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 96D7421F86CD; Mon, 29 Oct 2012 10:48:57 -0700 (PDT) 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 q9THlOWB026270; Mon, 29 Oct 2012 18:47:24 +0100 (CET) Received: from eduroam-0380.wlan.uni-bremen.de (eduroam-0380.wlan.uni-bremen.de [134.102.17.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 93CC4F6; Mon, 29 Oct 2012 18:47:24 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <508EBD6B.1070606@cs.tcd.ie> Date: Mon, 29 Oct 2012 18:47:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg> <1116.1351177270@sandelman.ca> <02a101cdb5f5$51109a70$f331cf50$@a-star.edu.sg> <508EBD6B.1070606@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1499) Cc: "Turner, Sean P." , 6lowpan@ietf.org, "roll@ietf.org WG" , "solace@ietf.org" Subject: Re: [6lowpan] [Roll] slot for New Version of draft-qiu-roll-kemp-02.txt 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, 29 Oct 2012 17:48:58 -0000 On Oct 29, 2012, at 18:31, Stephen Farrell = wrote: >=20 > Carsten, all, >=20 > On 10/29/2012 04:56 PM, Carsten Bormann wrote: >> On Oct 29, 2012, at 17:49, QIU Ying = wrote: >>=20 >>> which WG is best >>=20 >> I think right now we don't know that. >> All WGs in the CN/N cluster have the problem and have some = unfulfilled charter item in this space. >> So we can continue to play tourists and use the WG that happens to = have the largest amount of space on the agenda... >>=20 >> In SOLACE, we are discussing right now when to meet during the = Atlanta IETF. >=20 > Would it be timely to spend 10 minutes on this during the saag > session? Splendid idea! By Thursday, we should have a somewhat clearer idea of what we want to = do. > I'd really like that the security area not end up being surprised > by whatever is eventually decided so getting a presentation at > saag would be useful at the point where you more or less know > the direction, but are still flexible enough to deal with someone > who e.g. points out significant security issues. >=20 > It might be that waiting another meeting cycle or two would be > better if the basic ideas aren't yet firmed up. >=20 > So, is this work far enough advanced already for that to be > productive now or is it still so early it'd be counter-productive? > (And presenting at saag before you're ready could very well > be counter-productive - it can be a tough audience;-) Oh, there will be no technical presentation at this point. These 10 minutes would be about alerting the security community about = this activity. (See my ROLL slides from Vancouver -- = http://www.ietf.org/proceedings/84/slides/slides-84-roll-11.pdf) What we want to do first is=20 a) collecting more fleshed out approaches, documenting how precisely = they work, and b) identifying gaps in the existing standards, if any. If we are successful in getting structure into this, then there might be 1) "system standards" that explain how to tie things together, as well = as=20 2) potentially point activities addressing these gaps (but these will = not be "SOLACE"). Gr=FC=DFe, Carsten From rstruik.ext@gmail.com Mon Oct 29 11:27:21 2012 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 8BBCD21F8702; Mon, 29 Oct 2012 11:27:21 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+0dQastVC0S; Mon, 29 Oct 2012 11:27:20 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0AA21F8741; Mon, 29 Oct 2012 11:27:20 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id x24so2498278iak.31 for ; Mon, 29 Oct 2012 11:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=ZP0ZjHkgf2qXokPgKLLVaDLCbP40pLS5VeHiSiZ6jJ8=; b=SvsMxLfHIMPYNTsFbPjzpmP3tHSiCFW214n8WSQyK0Ukvgru7Y88hl82lIHPaelAuf yK5sdzbA2gCdE3qU2R/yrTlcYREhX8Wr9XAtGodypTvUdrwtGBLDbtaIdMUpw6FM8V0f d12zph5zkoc+Fb+Oeolwi2hlc5iYkkZdqzQHxkSLlYSF+IvYRT20oUXSHpADdDtfOSPg DcdvjM4uZgN4wzNJgBeSFSTFjlwKVvRq2a0iWdny3BSHYq1JtY1X9rbx/dw5iVhPXIUI EdGrPCbZKR6X3YEQUgFEzsNab5n5Oor4LoS9TFYxVPQFbtcj2C8LyO1DngYfoR5w/Taw jyTg== Received: by 10.50.154.227 with SMTP id vr3mr10433261igb.43.1351535239877; Mon, 29 Oct 2012 11:27:19 -0700 (PDT) Received: from [192.168.1.100] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.4.27]) by mx.google.com with ESMTPS id uz1sm6583031igb.16.2012.10.29.11.27.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Oct 2012 11:27:19 -0700 (PDT) Message-ID: <508ECA68.4030402@gmail.com> Date: Mon, 29 Oct 2012 14:26:48 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: QIU Ying References: <02a001cdb5ee$e34164d0$a9c42e70$@a-star.edu.sg> In-Reply-To: <02a001cdb5ee$e34164d0$a9c42e70$@a-star.edu.sg> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] New Version Notification for draft-qiu-roll-kemp: Do need an alternative security design ? 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, 29 Oct 2012 18:27:22 -0000 Hi Qiu: Just curious: could you elaborate a little bit on the RFC 4225, Section 5.2 remark below? I just would like to understand scalability, resource utilization, and other issues somewhat better and may have missed something here. In particular, if one uses a symmetric-key scheme with online involvement of a trusted party who distributes pairwise keying material, doesn't one then get lots of message traffic to/from this third party and its local neighbors for each protocol instantiation? On a more general note, agreed there is a need to tackle trust life cycle management in a dedicated forum. Originally, I thought the Smart Object Security Workshop (which we had end of March 2012, just prior to the IETF meeting) would be a good forum to tackle issues, but felt we missed some opportunities there to bring forward an agenda of things to accomplish (in my mind, there was too much inside the box thinking in terms of "tweaks to IETF drafts"), with less emphasis on what makes ubiquitous networking different from a deployment use case perspective (e.g., the lighting use case example comes to mind). Unfortunately, I will not be at the Atlanta meeting, though I might be in Vancouver. Glad to contribute to call to action there. Best regards, Rene On 10/29/2012 12:03 PM, QIU Ying wrote: > Dear all, > > Do need an alternative security design instead of the current public key protocols in key establishment? It's one of arguments in previous WG meeting. > > My answer is yes. Actually, the similar discussion had been raised in mobile IPv6 WG (RFC4225). > > Besides the authentication, another major check is the reachability checking to verify if the claimed mobile node is reachable (section 4.1). RFC4225 also explains why the current Public Key Infrastructure (i.e. IKE) is not accepted in mobile IPv6 (section 5.2). > > Frankly, the scheme used in KEMP is not fresh new. It is in style of the popular Kerberos. Instead of sending the ticket to visiting server from client directly in Kerberos, the ticket is sent to the visiting server (new nearby router in KEMP) from the KDC (base station in KEMP). The benefit of this modification includes: 1) reduce the communication; 2) the client (mobile node in KEMP) is check if reachable from the 3rd party (new nearby router); 3) revocation in time. > > Thank to many WG participants commenting on the draft (inclusive Rene Struik, Steve Childress, Shoichi Sakane, Greg Zaverucha, Matthew Campagna), the draft should be more mature and stronger. > > Regards > Qiu Ying > > >> -----Original Message----- >> From: QIU Ying [mailto:qiuying@i2r.a-star.edu.sg] >> Sent: Tuesday, October 23, 2012 11:57 AM >> To: 'roll@ietf.org'; '6lowpan@ietf.org' >> Subject: FW: New Version Notification for draft-qiu-roll-kemp-02.txt >> >> Hi, >> >> The KEMP draft is updated. The messages in the draft will be carried in >> KMP format proposed by IEEE802.15.9 working group so that the KEMP >> protocol is compatible with IEEE802.15.9 and could be deployed in layer >> 2. >> >> Regards >> Qiu Ying >> >> >> -----Original Message----- >> >> A new version of I-D, draft-qiu-roll-kemp-02.txt has been successfully >> submitted by Ying Qiu and posted to the IETF repository. >> >> Filename: draft-qiu-roll-kemp >> Revision: 02 >> Title: Lightweight Key Establishment and Management >> Protocol in Dynamic Sensor Networks (KEMP) >> Creation date: 2012-10-22 >> WG ID: Individual Submission >> Number of pages: 20 >> URL: http://www.ietf.org/internet-drafts/draft-qiu-roll- >> kemp-02.txt >> Status: http://datatracker.ietf.org/doc/draft-qiu-roll-kemp >> Htmlized: http://tools.ietf.org/html/draft-qiu-roll-kemp-02 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-qiu-roll-kemp- >> 02 >> >> Abstract: >> When a sensor node roams within a very large and distributed >> wireless >> sensor network, which consists of numerous sensor nodes, its routing >> path and neighborhood keep changing. In order to provide a high >> level of security in this environment, the moving sensor node needs >> to be authenticated to new neighboring nodes as well as to establish >> a key for secure communication. The document proposes an efficient >> and scalable protocol to establish and update the secure key in a >> dynamic wireless sensor network environment. The protocol >> guarantees >> that two sensor nodes share at least one key with probability 1 >> (100%) with less memory and energy cost, while not causing >> considerable communication overhead. >> >> >> >> >> The IETF Secretariat > Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." > _______________________________________________ > 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 | US: +1 (415) 690-7363 From stephen.farrell@cs.tcd.ie Mon Oct 29 13:46:25 2012 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 6C5A921F871D; Mon, 29 Oct 2012 13:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPjbcul9PEef; Mon, 29 Oct 2012 13:46:24 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4E321F870C; Mon, 29 Oct 2012 13:46:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7434FC77B; Mon, 29 Oct 2012 20:46:01 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Pp2h1LZO0hf; Mon, 29 Oct 2012 20:45:59 +0000 (GMT) Received: from [10.87.48.4] (unknown [86.42.183.189]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4325CBE25; Mon, 29 Oct 2012 20:45:59 +0000 (GMT) Message-ID: <508EEB07.8080807@cs.tcd.ie> Date: Mon, 29 Oct 2012 20:45:59 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121017 Thunderbird/16.0.1 MIME-Version: 1.0 To: Michael Richardson References: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg> <1116.1351177270@sandelman.ca> <02a101cdb5f5$51109a70$f331cf50$@a-star.edu.sg> <508EBD6B.1070606@cs.tcd.ie> <10703.1351542774@obiwan.sandelman.ca> In-Reply-To: <10703.1351542774@obiwan.sandelman.ca> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , roll@ietf.org, "'Keoh, Sye Loong'" , saag@ietf.org, "Turner, Sean P." , 6lowpan@ietf.org, Carsten Bormann Subject: Re: [6lowpan] SOLACE things at SAAG 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, 29 Oct 2012 20:46:25 -0000 Hiya, So Carsten volunteered to give saag a heads-up on the problem this time. If he and Cullen want to arm-wrestle that's fine:-) I'm sure either would do a fine job. I didn't mean to say anything about the solace draft being good, bad or indifferent. But I figured someone is working on this problem somewhere and would like to make sure that whatever solution looks like it'll be adopted is something that wouldn't cause saag folk to have fits. Cheers, S. On 10/29/2012 08:32 PM, Michael Richardson wrote: > >>>>>> "Stephen" == Stephen Farrell writes: > Stephen> Would it be timely to spend 10 minutes on this during the saag > Stephen> session? > > I think, if you want to talk something SOLACE related which is more > concrete than a possible SOLACE IRTF "charter", then maybe have Cullen > talk about: > > http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/CullenJennings.pdf > http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/slides/Cullen1.pdf > > Stephen> I'd really like that the security area not end up being surprised > Stephen> by whatever is eventually decided so getting a presentation at > Stephen> saag would be useful at the point where you more or less know > Stephen> the direction, but are still flexible enough to deal with someone > Stephen> who e.g. points out significant security issues. > > Except that: > 1) the constrained devices are more constrained than the IP phones > described. > > 2) the constrained devices probably can not be attacked/p0wned until > after they get on the network, and so actually authenticating to the > network is the "application" > > Cullen's slides provide a really good starting explanation. > While the details of the ultimate answer are going to be a bit different > in small ways, the basic architecture he presents has been articulated > repeatedly by many. > > So, if your aim is to get more security geeks thinking about attacks, > and about defenses, in advance of an actual proposed protocol (and > SOLACE is an I*R*TF group, recall. A protocol might not be the result > anyway), then I suggest giving Cullen a few minutes to talk about his > slide 7,8,9. > > Stephen> It might be that waiting another meeting cycle or two would be > Stephen> better if the basic ideas aren't yet firmed up. > > One meeting cycle won't help. Four might. > From cabo@tzi.org Mon Oct 29 14:16:32 2012 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 D83AD21F86E7; Mon, 29 Oct 2012 14:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.337 X-Spam-Level: X-Spam-Status: No, score=-107.337 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-OZ9WrV6y4B; Mon, 29 Oct 2012 14:16:32 -0700 (PDT) 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 ED9D721F86E1; Mon, 29 Oct 2012 14:16:31 -0700 (PDT) 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 q9TLFdsf029404; Mon, 29 Oct 2012 22:15:39 +0100 (CET) Received: from [192.168.217.105] (p54891A96.dip.t-dialin.net [84.137.26.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5B04D194; Mon, 29 Oct 2012 22:15:38 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <508EEB07.8080807@cs.tcd.ie> Date: Mon, 29 Oct 2012 22:15:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8AF21C42-1B84-4CD1-9904-AF4CA1AB16B5@tzi.org> References: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg> <1116.1351177270@sandelman.ca> <02a101cdb5f5$51109a70$f331cf50$@a-star.edu.sg> <508EBD6B.1070606@cs.tcd.ie> <10703.1351542774@obiwan.sandelman.ca> <508EEB07.8080807@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1499) Cc: Cullen Jennings , Michael Richardson , roll@ietf.org, "'Keoh, Sye Loong'" , saag@ietf.org, "Turner, Sean P." , 6lowpan@ietf.org Subject: Re: [6lowpan] SOLACE things at SAAG 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, 29 Oct 2012 21:16:33 -0000 On Oct 29, 2012, at 21:45, Stephen Farrell = wrote: > If he and Cullen want to arm-wrestle > that's fine:-) Well, Cullen's I-D (please have a look at = draft-jennings-core-transitive-trust-enrollment-01.txt,.pdf) is a very good example for the kind of input document that we are = looking for. But it is just one way of doing things. There are so many others. To a = large extent, the differences are not just based on technological = choices, but on what people are actually trying to do with the smart = objects, i.e., what purpose in life they have. After half a decade of kicking around half-baked solutions in this space = in various IETF working groups, I think it is a good idea to spend more = time understanding the design space. How, and where, to spend this time = in the most productive way is what I would like to discuss with = interested people before we do the SAAG slot: -> solace@ietf.org Gr=FC=DFe, Carsten PS. Here is section 3.3 of the CoRE roadmap I-D, which lists a couple = more related drafts: Several individual drafts analyze the issues around the security of constrained devices in constrained networks. | draft-garcia-core-security | | 2012-03-26 | | draft-sarikaya-core-sbootstrapping | -05 | 2012-07-10 | | draft-jennings-core-transitive-trust-enrollment | -01 | 2012-10-13 | [I-D.garcia-core-security] in particular describes the "Thing Lifecycle" and discusses resulting architectural considerations. [I-D.jennings-core-transitive-trust-enrollment] demonstrates a specific approach to securing the Thing Lifecycle based on defined roles of security players, including a Manufacturer, an Introducer, and a Transfer Agent. Further work around Thing Lifecycles is also expected to occur in the SOLACE initiative (Smart Object Lifecycle Architecture for Constrained Environments), with its early mailing list at solace@ietf.org -- developed after the model of the COMAN initiative (Management for Constrained Management Networks and Devices, coman@ietf.org, [I-D.ersue-constrained-mgmt]). From qiuying@i2r.a-star.edu.sg Wed Oct 31 09:49:56 2012 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 2C3AF21F878E; Wed, 31 Oct 2012 09:49: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQwmNjzO6nVZ; Wed, 31 Oct 2012 09:49:55 -0700 (PDT) Received: from gw1.scei.a-star.edu.sg (gw1.scei.a-star.edu.sg [192.122.140.10]) by ietfa.amsl.com (Postfix) with ESMTP id AD76E21F878D; Wed, 31 Oct 2012 09:49:54 -0700 (PDT) Received: from S3-CAS05.shared-svc.local ([10.217.253.201]) by gw1.scei.a-star.edu.sg (8.14.4/8.14.4) with ESMTP id q9VGnngP026253; Thu, 1 Nov 2012 00:49:50 +0800 Received: from Win7PC (10.217.253.130) by S3-CAS05.shared-svc.local (10.217.253.201) with Microsoft SMTP Server id 14.1.339.1; Thu, 1 Nov 2012 00:49:48 +0800 From: QIU Ying To: "'Rene Struik'" References: <02a001cdb5ee$e34164d0$a9c42e70$@a-star.edu.sg> <508ECA68.4030402@gmail.com> In-Reply-To: <508ECA68.4030402@gmail.com> Date: Thu, 1 Nov 2012 00:56:16 +0800 Message-ID: <036901cdb788$a481d5e0$ed8581a0$@a-star.edu.sg> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac22Awuizrt3ftb5Rx6RXh5Wrj8ExwBg8lOw Content-Language: en-sg X-Originating-IP: [10.217.253.130] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-10-31_03:2012-10-31, 2012-10-31, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1210310162 Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] New Version Notification for draft-qiu-roll-kemp: Do need an alternative security design ? 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: Wed, 31 Oct 2012 16:49:56 -0000 Hi, Rene Thanks for your comments. The discussion of using public keys in MIP6 WG was much more than the description in RFC 4225, e.g. the lack of global PKI, the key revocation, etc. These issues also restricted to accept the public key schemes in MIPv6 since a mobile device are always roaming and lost easily. Regarding the scalability, according to my understanding, for example IKE, a pre-configured security policy (SP), which based on the home address of mobile devices, is needed before IKE exchange procedure. The pre-configuration is lack of scalability as the visiting mobile devices could be from any locations or any domains. The IKE scheme is only solve the issue of authentication between the mobile device and the correspondent node. It cannot ensure that a mobile device is reachable from other nodes. "resource utilization": did you mean the limited capability of mobile devices? I cannot remember if there are a lot of words on the capability in the MIPv6 specification. I thought it is not practice to involve the revocation checking in a mobile device. Anyway, the capability issue is much more sensitive in LLNs than in mobile networks. Your observation is correct that "get lots of message traffic to/from this third party and its local neighbours" because need more hops. In KEMP protocol, using the base station as the trust third party is only in the bootstraps phase (or at a specified interval). In the following update phases, the distribution mode should be employed. In the distribution mode, the previous neighbour router is role as the trust 3rd party to introduce the moving sensor to the next neighbour router. In this case, the total hops could reduce to 3. By the way, in the public key scheme, the extra messages / communications are required when the certifications need to update. I hope that the above explanation could be express the actual concept of the MIPv6 authors, not just on my own understanding ;) Regards Qiu Ying > -----Original Message----- > From: Rene Struik [mailto:rstruik.ext@gmail.com] > Sent: Tuesday, October 30, 2012 2:27 AM > To: QIU Ying > Cc: roll@ietf.org; 6lowpan@ietf.org > Subject: Re: [6lowpan] New Version Notification for draft-qiu-roll-kemp: > Do need an alternative security design ? > > Hi Qiu: > > Just curious: could you elaborate a little bit on the RFC 4225, Section > 5.2 remark below? I just would like to understand scalability, resource > utilization, and other issues somewhat better and may have missed > something here. In particular, if one uses a symmetric-key scheme with > online involvement of a trusted party who distributes pairwise keying > material, doesn't one then get lots of message traffic to/from this > third party and its local neighbors for each protocol instantiation? > > On a more general note, agreed there is a need to tackle trust life > cycle management in a dedicated forum. Originally, I thought the Smart > Object Security Workshop (which we had end of March 2012, just prior to > the IETF meeting) would be a good forum to tackle issues, but felt we > missed some opportunities there to bring forward an agenda of things to > accomplish (in my mind, there was too much inside the box thinking in > terms of "tweaks to IETF drafts"), with less emphasis on what makes > ubiquitous networking different from a deployment use case perspective > (e.g., the lighting use case example comes to mind). > > Unfortunately, I will not be at the Atlanta meeting, though I might be > in Vancouver. Glad to contribute to call to action there. > > Best regards, Rene > > On 10/29/2012 12:03 PM, QIU Ying wrote: > > Dear all, > > > > Do need an alternative security design instead of the current public > key protocols in key establishment? It's one of arguments in previous > WG meeting. > > > > My answer is yes. Actually, the similar discussion had been raised in > mobile IPv6 WG (RFC4225). > > > > Besides the authentication, another major check is the reachability > checking to verify if the claimed mobile node is reachable (section > 4.1). RFC4225 also explains why the current Public Key Infrastructure > (i.e. IKE) is not accepted in mobile IPv6 (section 5.2). > > > > Frankly, the scheme used in KEMP is not fresh new. It is in style of > the popular Kerberos. Instead of sending the ticket to visiting server > from client directly in Kerberos, the ticket is sent to the visiting > server (new nearby router in KEMP) from the KDC (base station in KEMP). > The benefit of this modification includes: 1) reduce the communication; > 2) the client (mobile node in KEMP) is check if reachable from the 3rd > party (new nearby router); 3) revocation in time. > > > > Thank to many WG participants commenting on the draft (inclusive Rene > Struik, Steve Childress, Shoichi Sakane, Greg Zaverucha, Matthew > Campagna), the draft should be more mature and stronger. > > > > Regards > > Qiu Ying > > > > > >> -----Original Message----- > >> From: QIU Ying [mailto:qiuying@i2r.a-star.edu.sg] > >> Sent: Tuesday, October 23, 2012 11:57 AM > >> To: 'roll@ietf.org'; '6lowpan@ietf.org' > >> Subject: FW: New Version Notification for draft-qiu-roll-kemp-02.txt > >> > >> Hi, > >> > >> The KEMP draft is updated. The messages in the draft will be carried > >> in KMP format proposed by IEEE802.15.9 working group so that the > KEMP > >> protocol is compatible with IEEE802.15.9 and could be deployed in > >> layer 2. > >> > >> Regards > >> Qiu Ying > >> > >> > >> -----Original Message----- > >> > >> A new version of I-D, draft-qiu-roll-kemp-02.txt has been > >> successfully submitted by Ying Qiu and posted to the IETF repository. > >> > >> Filename: draft-qiu-roll-kemp > >> Revision: 02 > >> Title: Lightweight Key Establishment and Management > >> Protocol in Dynamic Sensor Networks (KEMP) > >> Creation date: 2012-10-22 > >> WG ID: Individual Submission > >> Number of pages: 20 > >> URL: http://www.ietf.org/internet-drafts/draft-qiu-roll- > >> kemp-02.txt > >> Status: http://datatracker.ietf.org/doc/draft-qiu-roll-kemp > >> Htmlized: http://tools.ietf.org/html/draft-qiu-roll-kemp-02 > >> Diff: http://www.ietf.org/rfcdiff?url2=draft-qiu-roll- > kemp- > >> 02 > >> > >> Abstract: > >> When a sensor node roams within a very large and distributed > >> wireless > >> sensor network, which consists of numerous sensor nodes, its > routing > >> path and neighborhood keep changing. In order to provide a high > >> level of security in this environment, the moving sensor node > needs > >> to be authenticated to new neighboring nodes as well as to > establish > >> a key for secure communication. The document proposes an > efficient > >> and scalable protocol to establish and update the secure key in a > >> dynamic wireless sensor network environment. The protocol > >> guarantees > >> that two sensor nodes share at least one key with probability 1 > >> (100%) with less memory and energy cost, while not causing > >> considerable communication overhead. > >> > >> > >> > >> > >> The IETF Secretariat > > Institute for Infocomm Research disclaimer: "This email is > confidential and may be privileged. If you are not the intended > recipient, please delete it and notify us immediately. Please do not > copy or use it for any purpose, or disclose its contents to any other > person. Thank you." > > _______________________________________________ > > 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 | US: +1 (415) 690-7363 Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you."