From pthubert@cisco.com Sat Oct 1 11:26:01 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0303721F9213 for ; Sat, 1 Oct 2011 11:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.341 X-Spam-Level: X-Spam-Status: No, score=-6.341 tagged_above=-999 required=5 tests=[AWL=-3.742, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQ4VtsmHU6RT for ; Sat, 1 Oct 2011 11:26:00 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEC321F9211 for ; Sat, 1 Oct 2011 11:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1574; q=dns/txt; s=iport; t=1317493738; x=1318703338; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=oFkWBUDUfkjM8y+jPpPuqD2Cb7vSdtPY7NdrzDZPits=; b=KnOkXP084dk1moxkmhIj8Y8J6OY5ByYsVT74SRr+PUZuwN2gtJLr6DBU kRRLwjdo4jo9oDdmmQuq9KmuEI9fZcRGZuqBHMd66CF4dZunWKyikmqFb GQ0n04E/KnfAzNLSejhRXMPgI9Ta3AOKjN28aMFFs7DGqbHJCGPDlaJO/ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANdah06Q/khR/2dsb2JhbABAhGWiXXOBBYFUAQEBAxIBEA0EQxICASICBgYYAgICAQFVAQEEGxqiMQGMRZBtgS2EZDJhBJkQjBI X-IronPort-AV: E=Sophos;i="4.68,474,1312156800"; d="scan'208";a="128604" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 01 Oct 2011 18:28:55 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p91IStMU014740 for ; Sat, 1 Oct 2011 18:28:55 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 1 Oct 2011 20:28:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sat, 1 Oct 2011 20:28:54 +0200 Message-ID: In-Reply-To: <20111001182513.6356.82400.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification fordraft-phinney-roll-rpl-industrial-applicability-00.txt Thread-Index: AcyAZ+FWnxqd7Wy3Sk271TBeYHC8BwAAAmHg References: <20111001182513.6356.82400.idtracker@ietfa.amsl.com> From: "Pascal Thubert (pthubert)" To: "roll WG" X-OriginalArrivalTime: 01 Oct 2011 18:28:56.0316 (UTC) FILETIME=[FAB69BC0:01CC8067] Subject: [Roll] New Version Notification fordraft-phinney-roll-rpl-industrial-applicability-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2011 18:26:01 -0000 DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcGhpbm5leS1yb2xsLXJwbC1pbmR1c3RyaWFs LWFwcGxpY2FiaWxpdHktMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg UGFzY2FsIFRodWJlcnQgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxl bmFtZToJIGRyYWZ0LXBoaW5uZXktcm9sbC1ycGwtaW5kdXN0cmlhbC1hcHBsaWNhYmlsaXR5DQpS ZXZpc2lvbjoJIDAwDQpUaXRsZToJCSBSUEwgYXBwbGljYWJpbGl0eSBpbiBpbmR1c3RyaWFsIG5l dHdvcmtzDQpDcmVhdGlvbiBkYXRlOgkgMjAxMS0xMC0wMQ0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDMxDQoNCkFic3RyYWN0Og0KICAgVGhlIHdpZGUg ZGVwbG95bWVudCBvZiB3aXJlbGVzcyBkZXZpY2VzLCB3aXRoIHRoZWlyIGxvdyBpbnN0YWxsZWQN CiAgIGNvc3QgKGNvbXBhcmVkIHRvIHdpcmVkIGRldmljZXMpLCB3aWxsIHNpZ25pZmljYW50bHkg aW1wcm92ZSB0aGUNCiAgIHByb2R1Y3Rpdml0eSBhbmQgc2FmZXR5IG9mIGluZHVzdHJpYWwgcGxh bnRzLCB3aGlsZSBzaW11bHRhbmVvdXNseQ0KICAgaW5jcmVhc2luZyB0aGUgZWZmaWNpZW5jeSBh bmQgc2FmZXR5IG9mIHRoZSBwbGFudCYjMzk7cyB3b3JrZXJzLCBieQ0KICAgZXh0ZW5kaW5nIGFu ZCBtYWtpbmcgbW9yZSB0aW1lbHkgdGhlIGluZm9ybWF0aW9uIHNldCBhdmFpbGFibGUgYWJvdXQN CiAgIHBsYW50IG9wZXJhdGlvbnMuICBUaGUgbmV3IFJvdXRpbmcgUHJvdG9jb2wgZm9yIExvdyBQ b3dlciBhbmQgTG9zc3kNCiAgIE5ldHdvcmtzIChSUEwpIGRlZmluZXMgYSBEaXN0YW5jZSBWZWN0 b3IgcHJvdG9jb2wgdGhhdCBpcyBkZXNpZ25lZA0KICAgZm9yIHN1Y2ggbmV0d29ya3MuICBUaGUg YWltIG9mIHRoaXMgZG9jdW1lbnQgaXMgdG8gYW5hbHl6ZSB0aGUNCiAgIGFwcGxpY2FiaWxpdHkg b2YgdGhhdCByb3V0aW5nIHByb3RvY29sIGluIGluZHVzdHJpYWwgTExOcyBvZiBmaWVsZA0KICAg ZGV2aWNlcy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3Jl dGFyaWF0DQo= From cabo@tzi.org Mon Oct 3 14:15:45 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6971E21F8E84; Mon, 3 Oct 2011 14:15:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1OiSQqJzpSZ; Mon, 3 Oct 2011 14:15:45 -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 3E3BA21F8E30; Mon, 3 Oct 2011 14:15:25 -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 p93LIKk7027606; Mon, 3 Oct 2011 23:18:21 +0200 (CEST) Received: from [192.168.217.110] (p54899A37.dip.t-dialin.net [84.137.154.55]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BA1519C; Mon, 3 Oct 2011 23:18:20 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <1301979438.1743.1130.camel@d430> Date: Mon, 3 Oct 2011 23:18:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1301979438.1743.1130.camel@d430> To: 6lowpan <6lowpan@ietf.org> X-Mailer: Apple Mail (2.1244.3) Cc: roll@ietf.org Subject: [Roll] GHC draft, version -03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: 6lowpan@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 21:15:45 -0000 LoWPANners, ROLLers, I have updated the 6LoWPAN generic header compression (GHC) draft along = what I perceive to be the results of discussions so far: http://tools.ietf.org/html/draft-bormann-6lowpan-ghc-03 I have moved nibblecode and context references to an appendix, with the = intention of removing them unless we do agree one or both of them should = stay in. I have also moved the extensive examples to an appendix to = reduce the bulk of the main body. Apart from removing nibblecode and = context references, I haven't actually changed anything on the wire, so = if you have code, that should still be interoperable. I would love to receive comments in time to allow me an update before = the Taipei cutoff (Nov 1), so we can discuss a -04 version there in the = hallways (and possibly in or around the ROLL meeting). Ceterum censeo: = please keep the packet dumps (pcaps) coming=85 (Please reply to the 6lowpan mailing list only, unless there is a = ROLL-specific issue.) Gruesse, Carsten From mcr@sandelman.ca Fri Oct 7 17:29:28 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D1B21F8C0C; Fri, 7 Oct 2011 17:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIn2i3yJzznE; Fri, 7 Oct 2011 17:29:27 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 49DC521F8C14; Fri, 7 Oct 2011 17:29:27 -0700 (PDT) Received: from marajade.sandelman.ca (173-101-76-84.pools.spcsdns.net [173.101.76.84]) by relay.sandelman.ca (Postfix) with ESMTPS id 7A7673427C; Fri, 7 Oct 2011 20:31:35 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 23FAE98CAE; Fri, 7 Oct 2011 18:38:19 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 1A8E998B2E; Fri, 7 Oct 2011 18:38:19 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org, roll@ietf.org In-Reply-To: <4E7A4CA0.4040302@piuha.net> References: <4E7A46EC.8080109@globis.net> <4E7A4CA0.4040302@piuha.net> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 07 Oct 2011 18:38:19 -0400 Message-ID: <11595.1318027099@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] [homenet] Homenet Architecture & Interim Meeting X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 00:29:28 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable This is a conversation that started on the Homenet list. > So there may also be a requirement for interconnection of > multiple ultra-short range networks via a house backbone: > e.g. lights on top floor pool to form a mesh network, and lights > in the basement form a mesh network, but the reinforced concrete > floor partitions the two wireless meshes, so you need a routed > connection between them. Jari> I think we do include that already. Its part of being able to Jari> provide a routed, multi-subnet network. Precisely for these Jari> reasons. (But if you are arguing that we should all use some If you plug two RPL root bridges into two ports of an ethernet switch, they will happily link your lighting network together. That's something that I think that might not have been clearly stated in the discussion at today's interim meeting: RPL might not be hidden behind the ethernet/802.15.4 router, it might use the ethernet to connect different zones. So, don't be surprised if you see RPL ICMPv6 messages crossing some of the inside lans. Continuing along the thought process that stuff should just work, regardless of how grandma plugs things in... it would therefore be nice if RPL could bridge across a routed homenet lan. This would work, I think, if the RPL ICMPv6 DIOs, which are currently multicast to a link-local group by default, could instead on a RPL node with an uplink, send to a site-local ULA multicast group.=20=20 This is also not strictly necessary: the upstairs and downstairs RPL meshes, if they allocate ULA prefixes as we have discussed, simply route across the homenet LAN, and probably things will work. Where this might fail is if the P2P mechanism in RPL was being used, because it basically forms a temporary DAG across the mesh find the most direct route. If the best route is via the homenet, it won't be found if the two meshes are partitioned. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATo9+IICLcPvd0N1lAQIj7wgAgqowGY0MAHkFV4541q8mWk86/Zjm5f9P GucOpy2yCp0L5VXpXDtt/DspghFpnOh5eniGpg44qlBrLj1CW1CtsRZu+bFuqoU2 KCWzuoen4iqpJPKudDOUKpfDiN8qiN+ClDhioWyJZbwgd6x51icxEPpx65mxA+Hq HaGhc6zWx8zxlpzHVAmiaLBmRn8q9aHYY5g340hsSBhFY261npekXsA6sjzc1WaD fy11B+s9+kDGCdPi6PGzC9t7rWbanWcu7Z/n6VkoNM56BgkW8f0AulblabjD9I0U i4OP1dOq/I7F/ZiTDj+ZWkZRzemm0a7obgk+dNAbc9yKMgjFDCVkNw== =xubg -----END PGP SIGNATURE----- --=-=-=-- From trakadasp@yahoo.gr Mon Oct 10 22:38:37 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C84221F8D29 for ; Mon, 10 Oct 2011 22:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.456 X-Spam-Level: ** X-Spam-Status: No, score=2.456 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iO3M4x4Ri5hf for ; Mon, 10 Oct 2011 22:38:36 -0700 (PDT) Received: from nm22-vm6.bullet.mail.ird.yahoo.com (nm22-vm6.bullet.mail.ird.yahoo.com [212.82.109.225]) by ietfa.amsl.com (Postfix) with SMTP id 18E4721F8D0C for ; Mon, 10 Oct 2011 22:38:35 -0700 (PDT) Received: from [77.238.189.53] by nm22.bullet.mail.ird.yahoo.com with NNFMP; 11 Oct 2011 05:38:29 -0000 Received: from [212.82.108.126] by tm6.bullet.mail.ird.yahoo.com with NNFMP; 11 Oct 2011 05:38:29 -0000 Received: from [127.0.0.1] by omp1035.mail.ird.yahoo.com with NNFMP; 11 Oct 2011 05:38:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 543032.72087.bm@omp1035.mail.ird.yahoo.com Received: (qmail 68914 invoked by uid 60001); 11 Oct 2011 05:38:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.gr; s=s1024; t=1318311509; bh=vCtVirXS/bJbELkwT4W/ahsYmaUdettTM25AFcOJo3E=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=n4OLVxe3ce4tVqh2tpbjZakoTJjavn3K+dQhvnoE+c82jeaxFKcmh0BxfcHfLktDWIcOJcTPAOlWYCYRerK4uEkdmCmapKU0Hfnd/lvlFKxMTK6lEaIdzi1z9iv7DepIiJeagqPluCourrthuw8b0sGAV0DN/gY6yxbKWaBl6fI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.gr; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=rgTJmvbL7BqJsnoLwXxplO4M9LqNBf8ZZuzBij6FzuUTwnlAPUJRD4EgYm+GMQ5fgvzxHvnK3Y21sLwJLXbrrNb9cWzWd+eQ+4VMf+SsGosq8tYfybXqdRh70ip/p19yrbt9UkmbYmofkBPYze5EtTtDrOAkkMplLeGed6ltpDQ=; X-YMail-OSG: qie3PyYVM1kNno1KWFpvXmm.r5K_yiZ9UYe6nF_aUclQNQv vQz7xhRw.HXUFawILcVTX.3_etzOXIGkp5ymhbROLzFRvFsvRHmLiwkjvT9O Rrq_s9BH5FRKKL0XtO5iTO_NzSgKtc4_XdqowClsn6qU9D6SWp74Vd4H5i.6 f._Gg7uOAOjKbwsahDtESRfw95q040FHunkd6BXm3eIpjwHP36s09C_imnpA mWlVow1b2U3x1QsFw6BSoSTJi6y4xH10NnmaqL54NwYZ0LklGbhRlBvkrz66 F2Jk.q5_RDQezUIS61MGzlBgRsSRKQq70zdzoYjJ6zv8Ncrg39AEb_FHB3mo S89FXGondruLLG0s.E2Xe8mgTFikFHpoPC2uwMeqOrv.gxoUP4QnCH798tog NU5yDVccJJfCWUyQ- Received: from [83.235.46.66] by web29619.mail.ird.yahoo.com via HTTP; Tue, 11 Oct 2011 06:38:29 BST X-Mailer: YahooMailWebService/0.8.114.317681 References: <3659AA00A52C42FE8849A34AA15B0B66@adae.gr> Message-ID: <1318311509.67993.YahooMailNeo@web29619.mail.ird.yahoo.com> Date: Tue, 11 Oct 2011 06:38:29 +0100 (BST) From: Panos Trakadas To: "nicolas.dejean.ietf@googlemail.com" , "zahariad@teihal.gr" , "roll@ietf.org" In-Reply-To: <3659AA00A52C42FE8849A34AA15B0B66@adae.gr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="958994435-136507369-1318311509=:67993" Subject: [Roll] =?iso-8859-7?q?=D3=F7=E5=F4=3A_Some_comments_about_draft-z?= =?iso-8859-7?q?ahariadis-roll-metrics-composition-01?= X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Panos Trakadas List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 05:38:37 -0000 --958994435-136507369-1318311509=:67993 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable > Dear Nicolas,=0A> =0A> Thanks for commenting this draft.=0A> We will soon= update the draft taking into consideration your comments.=0A> See our repl= y below.=0A> =0A> Best Regards,=0A> Panos Trakadas.=0A> =0A> ----- Original= Message ----- From: "Nicolas DEJEAN" = =0A> To: ; =0A> Sent: Tuesday, Octob= er 04, 2011 6:00 PM=0A> Subject: Some comments about draft-zahariadis-roll-= metrics-composition-01=0A> =0A> =0A> Hello,=0A> =0A> I have several comment= s about this draft.=0A> I found out some good clarifications on metrics com= position and so on.=0A> Example 5 in particular will make me think for a wh= ile, I believe.=0A> =0A> Please find those comments bellow.=0A> I have writ= ten them very quickly while I was reading the draft and it=0A> might be som= etimes a little bit rough.=0A> Please do not be offended for that.=0A> =0A>= I really appreciate your work.=0A> =0A> Cheers,=0A> =0A> Nicolas D=E9jean.= =0A> =0A> =0A> --------------------------------=0A> =0A> 1- Motivation=0A> = =0A> It might be usefull there to provide an example showing a situation=0A= > where e.g. constraints cannot solve the issue while a compound metric=0A>= does.=0A> =0A> ->Panos: Although the main target of the document is to pro= vide design princilpes for lexical and additive metrics composition,=0A> we= will include an example with constraints. However, introducing constraints= , it is easy to show that there might not be a path from source=0A> to dest= ination, while following either lexical or additive metric composition a pa= th always exists, but the problem is focused on selecting the optimal one.= =0A> =0A> 2.2 Metric operator=0A> =0A> I have several issues with this sect= ion:=0A> =0A> - I do not agree that recorded metric are of type minimum or = maximum=0A> and aggregated metrics are additive and multiplicative. For ins= tance,=0A> LQL could be seen as an aggregated metric computed as the maximu= m over=0A> the path (as 7 is the worst value) but also as a recorded one wh= ere=0A> each node inserts a new record or updates an existing one. The firs= t=0A> method provides the worst LQL over the whole path (without knowing th= e=0A> number of links presenting this LQL) while the second allows=0A> diff= erentiating between a path with single weak link and a path with=0A> severa= l weak links.=0A> =0A> ->Panos: I agree with you. That's why (on page 7 of = the draft) we mention that "The properties and rules for the majority of ro= uting metrics shown in this figure follow the description presented in [I-D= .ietf-roll-routing-metrics]. However, it is important to mention that a rou= ting metric MAY follow different properties and rules" . We will try to fur= ther highlight this sentence so the statement is crystal clear.=0A> =0A> - = I cannot see how RSSI (if it is Received Signal Strength Indication)=0A> is= a multiplicative metric. RSSI would easily map onto LQL which,=0A> isn't i= t?=0A> =0A> ->Panos: It depends on how the node "reads" the signal strength= . In case that the reading is in dB values, then the metric is additive. We= will modify the RSSI metric rule (from multiplicative to additive), mentio= ning that it is presented in dB values. This will simplify and improve read= ability of the draft.=0A> =0A> - RSSI metric is used several times through = the document without beeing defined.=0A> =0A> ->Panos: After modifying RSSI= from multiplicative to additive, we believe that there is no need to defin= e it. As you wrote, RSSI easily maps onto LQL.=0A> =0A> Figure 2=0A> =0A> F= or (A), it should be <0 , 0.0>, isn't it?=0A> As a consequence, w(A,B,D) = =3D <2 , 2.6> and w(A,C,D) =3D <2 , 2.8>=0A> w(A,C,E) =3D <2 , 2.5> and w(A= ,B,E) =3D <2 , 2.8>=0A> =0A> ->Panos: According to page 17, section 3.3 of = [I-D.ietf-roll-routing-metrics], "... the first node along a path inserting= a Hop-Count Metric object MUST set the Hop-Count field value to 1". I assu= me that the same holds for all other metrics. Thus, the first node must adv= ertise Hop-Count and ETX (or any other metric taken into account in the OF)= value of 1. This is also in line with the definition of ETX. No node can a= dvertise an ETX of 0 when this metric is defined in [1, +infinity). Anyway,= the conclusions derived from these examples are not affected by the values= of node A, but we will modify this part.=0A> =0A> Figure 3=0A> =0A> The is= sue is the same=0A> For (A), it should be <0 , 0.0>, isn't it?=0A> B, C and= E are OK=0A> =0A> However,=0A> w(A,B,D) =3D <2 , 4.0>=0A> w(A,C,E,D) =3D <= 3 , 3.4>=0A> =0A> I did not verify the other figures.=0A> =0A> ->Panos: Sam= e comment as above.=0A> =0A> Example 5: this example is very interesting an= d might be used in the=0A> introduction part maybe ine a simpler form. It c= learly shows where=0A> compound metrics might be useful.=0A> =0A> It should= be underlined there why constraints could not be used there.=0A> =0A> ->Pa= nos: OK, although, as stated above, constraints do not follow the same conc= ept.=0A> =0A> Example 6 and Figure 7: I do not really understand the figure= there.=0A> What are the local values (certainly L and T link properties)?= =0A> Whar are the values advertised (i.e. the ones the potential successor= =0A> have to take into account for computong their own)?=0A> =0A> ->Panos: = Correct. This is the only example that does not show link values, but node = values, confusing the reader. We will modify it according to your comment.= =0A> =0A> I agree that with the 'bad' compound metric used, it seems that= =0A> sub-optimal paths are used. However, in this example, practically the= =0A> parent choice is the good one as the only available candidate for (E)= =0A> is (D).=0A> Maybe a more complex example would show the selection of t= he wrong parent ...=0A> =0A> ->Panos: Of course node E selects node D, as i= ts only parent. What we are highlighting is that since the metric is not is= otonic, when node D is the source, it selects path (A,B,D), while when node= D acts as a relay node, forwarding traffic of E, then it will select path = (A,C,D) which is not the optimal one.=0A> =0A> =0A> -----------------------= - --958994435-136507369-1318311509=:67993 Content-Type: text/html; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable
> Dear Nicolas,
>
> Thanks for commenting this draft.
&= gt; We will soon update the draft taking into consideration your comments.<= br>> See our reply below.
>
> Best Regards,
> Panos T= rakadas.
>
> ----- Original Message ----- From: "Nicolas DEJEA= N" <nicolas.dejean.ietf@googlemail.com<= /a>>
> To: <zahariad@teihal.gr>; <trakadasp@adae.gr>
> Sent: = Tuesday, October 04, 2011 6:00 PM
> Subject: Some comments about draf= t-zahariadis-roll-metrics-composition-01
>
>
> Hello,>
> I have several comments about this draft.
> I found o= ut some good clarifications on metrics composition and so on.
> Examp= le 5 in particular will make me think for a while, I believe.
>
&= gt; Please find those comments bellow.
> I have written them very qui= ckly while I was reading the draft and it
> might be sometimes a litt= le bit rough.
> Please do not be offended for that.
>
> = I really appreciate your work.
>
> Cheers,
>
> Ni= colas D=E9jean.
>
>
> --------------------------------<= br>>
> 1- Motivation
>
> It might be usefull there t= o provide an example showing a situation
> where e.g. constraints cannot solve the issue while a compound metric
> does.
>
&= gt; ->Panos: Although the main target of the document is to provide desi= gn princilpes for lexical and additive metrics composition,
> we will= include an example with constraints. However, introducing constraints, it = is easy to show that there might not be a path from source
> to desti= nation, while following either lexical or additive metric composition a pat= h always exists, but the problem is focused on selecting the optimal one.>
> 2.2 Metric operator
>
> I have several issues = with this section:
>
> - I do not agree that recorded metric a= re of type minimum or maximum
> and aggregated metrics are additive a= nd multiplicative. For instance,
> LQL could be seen as an aggregated= metric computed as the maximum over
> the path (as 7 is the worst va= lue) but also as a recorded one where
> each node inserts a new record or updates an existing one. The first
> method provides t= he worst LQL over the whole path (without knowing the
> number of lin= ks presenting this LQL) while the second allows
> differentiating bet= ween a path with single weak link and a path with
> several weak link= s.
>
> ->Panos: I agree with you. That's why (on page 7 of = the draft) we mention that "The properties and rules for the majority of ro= uting metrics shown in this figure follow the description presented in [I-D= .ietf-roll-routing-metrics]. However, it is important to mention that a rou= ting metric MAY follow different properties and rules" . We will try to fur= ther highlight this sentence so the statement is crystal clear.
> > - I cannot see how RSSI (if it is Received Signal Strength Indication= )
> is a multiplicative metric. RSSI would easily map onto LQL which,=
> isn't it?
>
> ->Panos: It depends on how the node "reads" the signal strength. In case that the reading is in dB va= lues, then the metric is additive. We will modify the RSSI metric rule (fro= m multiplicative to additive), mentioning that it is presented in dB values= . This will simplify and improve readability of the draft.
>
>= - RSSI metric is used several times through the document without beeing de= fined.
>
> ->Panos: After modifying RSSI from multiplicativ= e to additive, we believe that there is no need to define it. As you wrote,= RSSI easily maps onto LQL.
>
> Figure 2
>
> For = (A), it should be <0 , 0.0>, isn't it?
> As a consequence, w(A,= B,D) =3D <2 , 2.6> and w(A,C,D) =3D <2 , 2.8>
> w(A,C,E) = =3D <2 , 2.5> and w(A,B,E) =3D <2 , 2.8>
>
> ->= Panos: According to page 17, section 3.3 of [I-D.ietf-roll-routing-metrics]= , "... the first node along a path inserting a Hop-Count Metric object MUST set the Hop-Count field value to 1". I assume that the same holds for all = other metrics. Thus, the first node must advertise Hop-Count and ETX (or an= y other metric taken into account in the OF) value of 1. This is also in li= ne with the definition of ETX. No node can advertise an ETX of 0 when this = metric is defined in [1, +infinity). Anyway, the conclusions derived from t= hese examples are not affected by the values of node A, but we will modify = this part.
>
> Figure 3
>
> The issue is the same=
> For (A), it should be <0 , 0.0>, isn't it?
> B, C and = E are OK
>
> However,
> w(A,B,D) =3D <2 , 4.0>
= > w(A,C,E,D) =3D <3 , 3.4>
>
> I did not verify the o= ther figures.
>
> ->Panos: Same comment as above.
> <= br>> Example 5: this example is very interesting and might be used in th= e
> introduction part maybe ine a simpler form. It clearly shows where
> compound metrics might be useful.
>
> It should= be underlined there why constraints could not be used there.
>
&= gt; ->Panos: OK, although, as stated above, constraints do not follow th= e same concept.
>
> Example 6 and Figure 7: I do not really un= derstand the figure there.
> What are the local values (certainly L a= nd T link properties)?
> Whar are the values advertised (i.e. the one= s the potential successor
> have to take into account for computong t= heir own)?
>
> ->Panos: Correct. This is the only example t= hat does not show link values, but node values, confusing the reader. We wi= ll modify it according to your comment.
>
> I agree that with = the 'bad' compound metric used, it seems that
> sub-optimal paths are= used. However, in this example, practically the
> parent choice is t= he good one as the only available candidate for (E)
> is (D).
> Maybe a more complex example would show the selection of the = wrong parent ...
>
> ->Panos: Of course node E selects node= D, as its only parent. What we are highlighting is that since the metric i= s not isotonic, when node D is the source, it selects path (A,B,D), while w= hen node D acts as a relay node, forwarding traffic of E, then it will sele= ct path (A,C,D) which is not the optimal one.
>
>
> ---= ---------------------



--958994435-136507369-1318311509=:67993-- From rstruik.ext@gmail.com Thu Oct 13 14:48:40 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29EB21F8BB0 for ; Thu, 13 Oct 2011 14:48:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xICzho-g4PVo for ; Thu, 13 Oct 2011 14:48:39 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 27E3921F8A64 for ; Thu, 13 Oct 2011 14:48:39 -0700 (PDT) Received: by gyh20 with SMTP id 20so545826gyh.31 for ; Thu, 13 Oct 2011 14:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:x-forwarded-message-id :content-type:content-transfer-encoding; bh=cYBs2Hb6/KM/0g7GIeWYELVBkYgCpCSHTTbgHk1YNPU=; b=mq31aLSDuzO1OmdP86yuHGlehjYA2UJs86918UEnrjoIz+byQp2z1qeeOkLl6ClEpH AG3LEir+tiNUEF2JKL7T2T+eHEmMtGpDeJu8c2mMXexxuawXZZP3mFL1nyoDsjLWD6AW lTkGwGEXxw4PFAsLPrk368yPJw4NowbGkADgQ= Received: by 10.236.156.38 with SMTP id l26mr7805682yhk.47.1318542518810; Thu, 13 Oct 2011 14:48:38 -0700 (PDT) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.117.243]) by mx.google.com with ESMTPS id a18sm1450005yhh.2.2011.10.13.14.48.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Oct 2011 14:48:37 -0700 (PDT) Message-ID: <4E975CA0.4010104@gmail.com> Date: Thu, 13 Oct 2011 17:48:16 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Alexander, Roger" , "Tsao, Tzeta" References: <4E971239.7000400@gmail.com> In-Reply-To: <4E971239.7000400@gmail.com> X-Enigmail-Version: 1.3.2 X-Forwarded-Message-Id: <4E971239.7000400@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: [Roll] notes re AMiKey draft (draft-alexander-roll-amikey-lln-key-mgmt-02) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 21:48:40 -0000 Dear Roger, Tzeta: Please find below some notes on your AMIKey draft (draft-alexander-roll-amikey-lln-key-mgmt-02). I made the assumption that cryptographic protection is based on a nonce-based cryptographic mode of operation and that replay protection would be provided (thus, necessitating each receiving device to keep some nonce state on sending devices). While AMIKey could have applications that would not require a nonce-based mechanism and replay protection, this seems a fair assumption (and holds for RoLL-based cryptographic protection). As suggested previously, some of my notes have more to do with MIKey (RFC 3830), so it seems, than with AMIKey. However, some have to do with implicit assumptions on what basic functionality devices have on board. Please feel free to discuss. Best regards, Rene == 1) Notion of time Some of the MIKey constructs (e.g., CSB Id, Section 1.4) suggest that one assumes devices have a notion of time, e.g., to be used to detect replays/duplicates, and correlate messages with the corresponding acknowledgement. With RoLL, this notion of time is not a given. Moreover, this begs the question as to what to do if time notions between devices are out-of-synch. Does the MIKey specification cater to this? Additional note: -Section 5.2, first para: this seems to suggest a mandatory timestamp. Not sure what the granularity is with MIKey (important, since not to be reused) and how this time stamp would be managed. -Section 6.14, 2nd para: here, key validity periods are specified (KV), thus requiring a sufficiently accurate shared notion of time (for, if not, any time check may be unreliable or futile). 2) Key dependencies It seems that MIKey defines a deterministic mapping between key encryption keys (TGK) and session keys (TEK). As a result, inadvertent key exposure of the TGK key will expose all derived keys as well. This may be undesirable, e.g., if TGK is shared amongst many devices and one of those devices gets compromised. If session keys would be generated at random and transported over a secure per-device-pair channel instead, the impact of compromise of a single node seems more limited. Moreover, it seems to be preferable to have a logical separation between keys (e.g., in the event of ownership transfer of a single node or replacement of a malfunctioning single node). Additional note: -From Section 2 (AMIKey overview, para below Fig. 2) it is unclear whether the TEK is used directly as cryptographic key with, e.g., RoLL, or whether one derives additional keying material from this. -Section 6.16 (Key Index payload): this may benefit from some more explanation. 3) Key identification With RoLL, the pair (key source identifier, key index) indicates both the originator of the key ("key source id") and an index ("key index") of keys issued by this key originator. This does not necessarily imply, though, that keys are correlated, as is suggested in Section 1.4. (It seems that KeySourceId identifies a TGK, while KeyIndex identifies a parameter so as to allow computation of TEK=f(TGK,#)). If this interpretation is correct, this leads to key dependencies that may be undesirable, e.g., in the event of key compromise. 4) Challenge response protocol I am somewhat concerned about some of the message flows with MIKey (e.g., Section 3, 3rd para, Fig. 3), since a key request could arise, e.g., if a key or nonce are "out-of-synch" (which, for keys, mens that one does not have the proper key; for nonces, that one has lost this value). With MIKey PSK flows, this would result (in the context of RPL) that one cannot adequately secure the first message Q_MESSAGE, thereby aborting the protocol. Simply put, what does one do if keys are lost or if nonces are out of synch? Moreover, the message flows do not seem to provide for timeliness (in other words: how does entity I know that the request by entity R is "fresh")? In out-of-synch scenarios, it seems better to employ a proper challenge/response protocol (unilateral entity authentication), where the key requestor sends a random challenge to the key assignment initiator and where the response messsage includes a protected version of the requested key and incorporates this random value. This results in implicit key authentication (only the requestor can recover the key [assuming both entities have a shared key]) and provides logical binding between message flows without dependency on nonces. NOTE RS: with RoLL, this may cause some trouble, since this suggests mixing of unsecured and secured traffic in the network (which, vaguely, seems to be forbidden using the "security mode"). Since with RoLL, the security mode and the security level seems to be unduly tied together, this may result in the security mode toggling between unsecured and secured once such a C/R protocol would get implemented. 5) Timeliness/ logical binding in protocol flows It is not entirely clear how the MIKey protocol provides for logical binding between protocol flows. As already mentioned, this may be a problem with the protocol flows in Fig. 3 (key request), but also with subsequent detailed protocol flows (such as with Fig. 5, using the PSK method). Additional note: -Section 3.1, 2nd last para: doesn't this impact the resulting properties? 6) Public key usage: The MIKEY protocol seems to use the same public key both for signing and for encryption. It is unclear in abstracto whether this poses problems, but common practice is to separate public keys for different cryptographic purposes. If this practice is heeded to, this requires the use of two public keys per device (including management hereof). Additional note: -Section 3.2, forelast para: wouldn't this impact freshness and aliveness properties? -Section 3.2 vs. 3.3: What is the rationale for making public key encryption (3.2) mandatory and Diffie-Hellman key exchange (3.3) optional? To me, it seems that use of public key techniques may significantly simplify configuration management (since this now depends on juggling publicly available information, rather than handling of secret keying material). Of those techniques, DH-based protocols seem to be best suited for highly constrained networks, where energy cost and implementation footprint come at a premium. Moreover, these may also be more resistant to side channel attacks (not trivial, esp. for devices that can be expected to be low-cost, consumer-style devices that may not be able to rely on tamper-evidencing techniques). This suggests that public-key based techniques, rather than symmetric-key based techniques (with proper eye for detail, of course) should be mandatory to implement. 7) Hash function The suggested "hash function" (Section 4.1.2 - use of CMAC) may be somewhat unfortunate, since it is invertible if one has access to the key (in contrast to HMAC-SHAx, which is one-way, or block-cipher based hashes, such as AES-MMO, as ZigBee SE1.x used). This may have implications in the event of key compromise. 8) Key management fit [as already noted by others] Overarching question may be whether key management functionality best fits with RoLL, CoRE, etc. Of course, this a perennial question. Nevertheless, some of the functionality described seems to suggest layer violation (e.g., Section 6.1.2, Table 6.1.e), since RoLL may not know about application layers, etc. 9) Other notes -Section 4: RFC 4493 corresponds to NIST SP 800-38B. -Section 4.1.2: not sure what the AES-CMAC alignment remark is about. BTW - this seems to suggest one can mix usage of CMAC with that of CCM with the same key (cf. also Section 6.2 (Table 6.2.b) and the last para of Section 6.2). In my opinion, this may be highly dangerous. As case in point, with the development of 802.15.4-2003, the same mixing was suggested (CBC-MAC, CTR, CCM) and shown to lead to an unsecure scheme (I can send you my presentation at the time [Nov 2002]). -Section 4.2.4: CCM mode of operation uses a nonce, rather than IV. With RoLL, this is a 13-byte entry, rather than a 16-byte entry. Moreover, the structure of the nonce matters, since it is aimed at preventing nonce reuse by a single sender/amongst different senders sharing the same key. -Section 6.1, bullet #CS (8 bits): shouldn't this entry enumerate, rather than provide a number. -Section 6.7, 3rd para: the IEEE MAC address is a 64-bit entry (rather than a 48-bit address). Not sure how the reference to RFC 4291 comes into play here. -Section 6.10.2: Table 6.10.2c suggests the use of AES-CBC-MAC-x. Why not use CCM instead (it provides various combinations of encryption and authentication, including authentication-only). -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From jpv@cisco.com Fri Oct 14 05:18:58 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21D921F8B16 for ; Fri, 14 Oct 2011 05:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkAjA-05Kw4y for ; Fri, 14 Oct 2011 05:18:58 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5381221F8AFF for ; Fri, 14 Oct 2011 05:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=217; q=dns/txt; s=iport; t=1318594738; x=1319804338; h=mime-version:subject:from:date:cc: content-transfer-encoding:message-id:references:to; bh=wcUYfhw5nQkrJ5EA8h1FJf4HdqvVugcwVdsLgSjp95k=; b=aRtwb6lxRrJtVLeneBlR9mxCSLigiUV18a3ZBoR5dYhb5/VBaIr6h1u6 va1rKtGWW0eVYi5VtAWxYdFEnv04vuQ8RIG7dOpfuWoaklAfvLkMvzFWD uF6kvJrV9rynlfYuMzZuID17xaoMLDjPn5sqDXWW3xE/AG2wV0qfMgEP5 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAE4omE6rRDoJ/2dsb2JhbABDqF6BBYFTAQEBAQIBEgEnPwULUU0KBjWHXJkjAZAwjg6HDGEEiAGLdoUoCYxE X-IronPort-AV: E=Sophos;i="4.69,346,1315180800"; d="scan'208";a="7894925" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 14 Oct 2011 12:18:58 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9ECIvft003839; Fri, 14 Oct 2011 12:18:57 GMT Received: from xfe-sjc-231.amer.cisco.com ([128.107.191.114]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 05:18:57 -0700 Received: from [10.2.158.90] ([10.21.68.17]) by xfe-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 05:18:57 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: JP Vasseur Date: Fri, 14 Oct 2011 05:18:57 -0700 Content-Transfer-Encoding: 7bit Message-Id: <7EDD9A1C-BA19-4658-80A3-E4107C9A3EBE@cisco.com> References: <20111013180645.16786.78000.idtracker@ietfa.amsl.com> To: roll WG X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 14 Oct 2011 12:18:57.0289 (UTC) FILETIME=[726EA790:01CC8A6B] Cc: David Culler Subject: [Roll] Fwd: roll - Requested session has been scheduled for IETF 82 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 12:18:58 -0000 Here is the tentative schedule for the ROLL WG meeting in Tapei: > roll Session 1 (2 hours) > Monday, Afternoon Session I 1300-1500 > Room Name: 102 > --------------------------------------------- > From rstruik.ext@gmail.com Fri Oct 14 06:46:59 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F3521F8BB6 for ; Fri, 14 Oct 2011 06:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSuxqxtzGRtb for ; Fri, 14 Oct 2011 06:46:58 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E5F4E21F8514 for ; Fri, 14 Oct 2011 06:46:57 -0700 (PDT) Received: by ggnk3 with SMTP id k3so1317731ggn.31 for ; Fri, 14 Oct 2011 06:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:x-forwarded-message-id:content-type; bh=lGyyOswkTYnM9rZANCYGFoGA81II6NO2iynLilnITUw=; b=bQAzxFImwSiGMT/goiDLQg7jmVfV/b+5lvcaPp7Ed0u4vmlmRUg+Wh4FKrDdleREu2 wJTO4agCB7jjMWeRfdwgUIn2u5tjZ1x1WF++VXzgGpHKG1NGcHThk57dbhsbvoN9O78x c4U7/lWYXjfuGAq6BdgzWFK+iLpvI6aIysGCE= Received: by 10.236.173.165 with SMTP id v25mr12093325yhl.22.1318600017499; Fri, 14 Oct 2011 06:46:57 -0700 (PDT) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.117.243]) by mx.google.com with ESMTPS id v4sm4821581yhk.3.2011.10.14.06.46.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Oct 2011 06:46:55 -0700 (PDT) Message-ID: <4E983D47.1020601@gmail.com> Date: Fri, 14 Oct 2011 09:46:47 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: roll@ietf.org References: <4E975CA0.4010104@gmail.com> In-Reply-To: <4E975CA0.4010104@gmail.com> X-Enigmail-Version: 1.3.2 X-Forwarded-Message-Id: <4E975CA0.4010104@gmail.com> Content-Type: multipart/alternative; boundary="------------020006000406070306050304" Subject: [Roll] notes re AMiKey draft (draft-alexander-roll-amikey-lln-key-mgmt-02) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 13:46:59 -0000 This is a multi-part message in MIME format. --------------020006000406070306050304 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [resend] -------- Original Message -------- Subject: notes re AMiKey draft (draft-alexander-roll-amikey-lln-key-mgmt-02) Date: Thu, 13 Oct 2011 17:48:16 -0400 From: Rene Struik To: Alexander, Roger , Tsao, Tzeta CC: roll@ietf.org Dear Roger, Tzeta: Please find below some notes on your AMIKey draft (draft-alexander-roll-amikey-lln-key-mgmt-02). I made the assumption that cryptographic protection is based on a nonce-based cryptographic mode of operation and that replay protection would be provided (thus, necessitating each receiving device to keep some nonce state on sending devices). While AMIKey could have applications that would not require a nonce-based mechanism and replay protection, this seems a fair assumption (and holds for RoLL-based cryptographic protection). As suggested previously, some of my notes have more to do with MIKey (RFC 3830), so it seems, than with AMIKey. However, some have to do with implicit assumptions on what basic functionality devices have on board. Please feel free to discuss. Best regards, Rene == 1) Notion of time Some of the MIKey constructs (e.g., CSB Id, Section 1.4) suggest that one assumes devices have a notion of time, e.g., to be used to detect replays/duplicates, and correlate messages with the corresponding acknowledgement. With RoLL, this notion of time is not a given. Moreover, this begs the question as to what to do if time notions between devices are out-of-synch. Does the MIKey specification cater to this? Additional note: -Section 5.2, first para: this seems to suggest a mandatory timestamp. Not sure what the granularity is with MIKey (important, since not to be reused) and how this time stamp would be managed. -Section 6.14, 2nd para: here, key validity periods are specified (KV), thus requiring a sufficiently accurate shared notion of time (for, if not, any time check may be unreliable or futile). 2) Key dependencies It seems that MIKey defines a deterministic mapping between key encryption keys (TGK) and session keys (TEK). As a result, inadvertent key exposure of the TGK key will expose all derived keys as well. This may be undesirable, e.g., if TGK is shared amongst many devices and one of those devices gets compromised. If session keys would be generated at random and transported over a secure per-device-pair channel instead, the impact of compromise of a single node seems more limited. Moreover, it seems to be preferable to have a logical separation between keys (e.g., in the event of ownership transfer of a single node or replacement of a malfunctioning single node). Additional note: -From Section 2 (AMIKey overview, para below Fig. 2) it is unclear whether the TEK is used directly as cryptographic key with, e.g., RoLL, or whether one derives additional keying material from this. -Section 6.16 (Key Index payload): this may benefit from some more explanation. 3) Key identification With RoLL, the pair (key source identifier, key index) indicates both the originator of the key ("key source id") and an index ("key index") of keys issued by this key originator. This does not necessarily imply, though, that keys are correlated, as is suggested in Section 1.4. (It seems that KeySourceId identifies a TGK, while KeyIndex identifies a parameter so as to allow computation of TEK=f(TGK,#)). If this interpretation is correct, this leads to key dependencies that may be undesirable, e.g., in the event of key compromise. 4) Challenge response protocol I am somewhat concerned about some of the message flows with MIKey (e.g., Section 3, 3rd para, Fig. 3), since a key request could arise, e.g., if a key or nonce are "out-of-synch" (which, for keys, mens that one does not have the proper key; for nonces, that one has lost this value). With MIKey PSK flows, this would result (in the context of RPL) that one cannot adequately secure the first message Q_MESSAGE, thereby aborting the protocol. Simply put, what does one do if keys are lost or if nonces are out of synch? Moreover, the message flows do not seem to provide for timeliness (in other words: how does entity I know that the request by entity R is "fresh")? In out-of-synch scenarios, it seems better to employ a proper challenge/response protocol (unilateral entity authentication), where the key requestor sends a random challenge to the key assignment initiator and where the response messsage includes a protected version of the requested key and incorporates this random value. This results in implicit key authentication (only the requestor can recover the key [assuming both entities have a shared key]) and provides logical binding between message flows without dependency on nonces. NOTE RS: with RoLL, this may cause some trouble, since this suggests mixing of unsecured and secured traffic in the network (which, vaguely, seems to be forbidden using the "security mode"). Since with RoLL, the security mode and the security level seems to be unduly tied together, this may result in the security mode toggling between unsecured and secured once such a C/R protocol would get implemented. 5) Timeliness/ logical binding in protocol flows It is not entirely clear how the MIKey protocol provides for logical binding between protocol flows. As already mentioned, this may be a problem with the protocol flows in Fig. 3 (key request), but also with subsequent detailed protocol flows (such as with Fig. 5, using the PSK method). Additional note: -Section 3.1, 2nd last para: doesn't this impact the resulting properties? 6) Public key usage: The MIKEY protocol seems to use the same public key both for signing and for encryption. It is unclear in abstracto whether this poses problems, but common practice is to separate public keys for different cryptographic purposes. If this practice is heeded to, this requires the use of two public keys per device (including management hereof). Additional note: -Section 3.2, forelast para: wouldn't this impact freshness and aliveness properties? -Section 3.2 vs. 3.3: What is the rationale for making public key encryption (3.2) mandatory and Diffie-Hellman key exchange (3.3) optional? To me, it seems that use of public key techniques may significantly simplify configuration management (since this now depends on juggling publicly available information, rather than handling of secret keying material). Of those techniques, DH-based protocols seem to be best suited for highly constrained networks, where energy cost and implementation footprint come at a premium. Moreover, these may also be more resistant to side channel attacks (not trivial, esp. for devices that can be expected to be low-cost, consumer-style devices that may not be able to rely on tamper-evidencing techniques). This suggests that public-key based techniques, rather than symmetric-key based techniques (with proper eye for detail, of course) should be mandatory to implement. 7) Hash function The suggested "hash function" (Section 4.1.2 - use of CMAC) may be somewhat unfortunate, since it is invertible if one has access to the key (in contrast to HMAC-SHAx, which is one-way, or block-cipher based hashes, such as AES-MMO, as ZigBee SE1.x used). This may have implications in the event of key compromise. 8) Key management fit [as already noted by others] Overarching question may be whether key management functionality best fits with RoLL, CoRE, etc. Of course, this a perennial question. Nevertheless, some of the functionality described seems to suggest layer violation (e.g., Section 6.1.2, Table 6.1.e), since RoLL may not know about application layers, etc. 9) Other notes -Section 4: RFC 4493 corresponds to NIST SP 800-38B. -Section 4.1.2: not sure what the AES-CMAC alignment remark is about. BTW - this seems to suggest one can mix usage of CMAC with that of CCM with the same key (cf. also Section 6.2 (Table 6.2.b) and the last para of Section 6.2). In my opinion, this may be highly dangerous. As case in point, with the development of 802.15.4-2003, the same mixing was suggested (CBC-MAC, CTR, CCM) and shown to lead to an unsecure scheme (I can send you my presentation at the time [Nov 2002]). -Section 4.2.4: CCM mode of operation uses a nonce, rather than IV. With RoLL, this is a 13-byte entry, rather than a 16-byte entry. Moreover, the structure of the nonce matters, since it is aimed at preventing nonce reuse by a single sender/amongst different senders sharing the same key. -Section 6.1, bullet #CS (8 bits): shouldn't this entry enumerate, rather than provide a number. -Section 6.7, 3rd para: the IEEE MAC address is a 64-bit entry (rather than a 48-bit address). Not sure how the reference to RFC 4291 comes into play here. -Section 6.10.2: Table 6.10.2c suggests the use of AES-CBC-MAC-x. Why not use CCM instead (it provides various combinations of encryption and authentication, including authentication-only). -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 --------------020006000406070306050304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [resend]

-------- Original Message --------
Subject: notes re AMiKey draft (draft-alexander-roll-amikey-lln-key-mgmt-02)
Date: Thu, 13 Oct 2011 17:48:16 -0400
From: Rene Struik <rstruik.ext@gmail.com>
To: Alexander, Roger <Roger.Alexander@cooperindustries.com>, Tsao, Tzeta <Tzeta.Tsao@cooperindustries.com>
CC: roll@ietf.org 


Dear Roger, Tzeta:

Please find below some notes on your AMIKey draft
(draft-alexander-roll-amikey-lln-key-mgmt-02).

I made the assumption that cryptographic protection is based on a
nonce-based cryptographic mode of operation and that replay protection
would be provided (thus, necessitating each receiving device to keep
some nonce state on sending devices). While AMIKey could have
applications that would not require a nonce-based mechanism and replay
protection, this seems a fair assumption (and holds for RoLL-based
cryptographic protection).

As suggested previously, some of my notes have more to do with MIKey
(RFC 3830), so it seems, than with AMIKey. However, some have to do with
implicit assumptions on what basic functionality devices have on board.

Please feel free to discuss.

Best regards, Rene

==

1) Notion of time
Some of the MIKey constructs (e.g., CSB Id, Section 1.4) suggest that
one assumes devices have a notion of time, e.g., to be used to detect
replays/duplicates, and correlate messages with the corresponding
acknowledgement. With RoLL, this notion of time is not a given.
Moreover, this begs the question as to what to do if time notions
between devices are out-of-synch. Does the MIKey specification cater to
this?

Additional note:
-Section 5.2, first para: this seems to suggest a mandatory timestamp.
Not sure what the granularity is with MIKey (important, since not to be
reused) and how this time stamp would be managed.
-Section 6.14, 2nd para: here, key validity periods are specified (KV),
thus requiring a sufficiently accurate shared notion of time (for, if
not, any time check may be unreliable or futile).

2) Key dependencies
It seems that MIKey defines a deterministic mapping between key
encryption keys (TGK) and session keys (TEK). As a result, inadvertent
key exposure of the TGK key will expose all derived keys as well. This
may be undesirable, e.g., if TGK is shared amongst many devices and one
of those devices gets compromised. If session keys would be generated at
random and transported over a secure per-device-pair channel instead,
the impact of compromise of a single node seems more limited. Moreover,
it seems to be preferable to have a logical separation between keys
(e.g., in the event of ownership transfer of a single node or
replacement of a malfunctioning single node).

Additional note:
-From Section 2 (AMIKey overview, para below Fig. 2) it is unclear
whether the TEK is used directly as cryptographic key with, e.g., RoLL,
or whether one derives additional keying material from this.
-Section 6.16 (Key Index payload): this may benefit from some more
explanation.

3) Key identification
With RoLL, the pair (key source identifier, key index) indicates both
the originator of the key ("key source id") and an index ("key index")
of keys issued by this key originator. This does not necessarily imply,
though, that keys are correlated, as is suggested in Section 1.4. (It
seems that KeySourceId identifies a TGK, while KeyIndex identifies a
parameter so as to allow computation of TEK=f(TGK,#)). If this
interpretation is correct, this leads to key dependencies that may be
undesirable, e.g., in the event of key compromise.

4) Challenge response protocol
I am somewhat concerned about some of the message flows with MIKey
(e.g., Section 3, 3rd para, Fig. 3), since a key request could arise,
e.g., if a key or nonce are "out-of-synch" (which, for keys, mens that
one does not have the proper key; for nonces, that one has lost this
value). With MIKey PSK flows, this would result (in the context of RPL)
that one cannot adequately secure the first message Q_MESSAGE, thereby
aborting the protocol. Simply put, what does one do if keys are lost or
if nonces are out of synch? Moreover, the message flows do not seem to
provide for timeliness (in other words: how does entity I know that the
request by entity R is "fresh")?

In out-of-synch scenarios, it seems better to employ a proper
challenge/response protocol (unilateral entity authentication), where
the key requestor sends a random challenge to the key assignment
initiator and where the response messsage includes a protected version
of the requested key and incorporates this random value. This results in
implicit key authentication (only the requestor can recover the key
[assuming both entities have a shared key]) and provides logical binding
between message flows without dependency on nonces.

NOTE RS: with RoLL, this may cause some trouble, since this suggests
mixing of unsecured and secured traffic in the network (which, vaguely,
seems to be forbidden using the "security mode"). Since with RoLL, the
security mode and the security level seems to be unduly tied together,
this may result in the security mode toggling between unsecured and
secured once such a C/R protocol would get implemented.

5) Timeliness/ logical binding in protocol flows
It is not entirely clear how the MIKey protocol provides for logical
binding between protocol flows. As already mentioned, this may be a
problem with the protocol flows in Fig. 3 (key request), but also with
subsequent detailed protocol flows (such as with Fig. 5, using the PSK
method).

Additional note:
-Section 3.1, 2nd last para: doesn't this impact the resulting properties?

6) Public key usage:
The MIKEY protocol seems to use the same public key both for signing and
for encryption. It is unclear in abstracto whether this poses problems,
but common practice is to separate public keys for different
cryptographic purposes. If this practice is heeded to, this requires the
use of two public keys per device (including management hereof).

Additional note:
-Section 3.2, forelast para: wouldn't this impact freshness and
aliveness properties?
-Section 3.2 vs. 3.3: What is the rationale for making public key
encryption (3.2) mandatory and Diffie-Hellman key exchange (3.3)
optional? To me, it seems that use of public key techniques may
significantly simplify configuration management (since this now depends
on juggling publicly available information, rather than handling of
secret keying material). Of those techniques, DH-based protocols seem to
be best suited for highly constrained networks, where energy cost and
implementation footprint come at a premium. Moreover, these may also be
more resistant to side channel attacks (not trivial, esp. for devices
that can be expected to be low-cost, consumer-style devices that may not
be able to rely on tamper-evidencing techniques). This suggests that
public-key based techniques, rather than symmetric-key based techniques
(with proper eye for detail, of course) should be mandatory to implement.

7) Hash function
The suggested "hash function" (Section 4.1.2 - use of CMAC) may be
somewhat unfortunate, since it is invertible if one has access to the
key (in contrast to HMAC-SHAx, which is one-way, or block-cipher based
hashes, such as AES-MMO, as ZigBee SE1.x used). This may have
implications in the event of key compromise.

8) Key management fit
[as already noted by others] Overarching question may be whether key
management functionality best fits with RoLL, CoRE, etc. Of course, this
a perennial question. Nevertheless, some of the functionality described
seems to suggest layer violation (e.g., Section 6.1.2, Table 6.1.e),
since RoLL may not know about application layers, etc.

9) Other notes
-Section 4: RFC 4493 corresponds to NIST SP 800-38B.
-Section 4.1.2: not sure what the AES-CMAC alignment remark is about.
BTW - this seems to suggest one can mix usage of CMAC with that of CCM
with the same key (cf. also Section 6.2 (Table 6.2.b) and the last para
of Section 6.2). In my opinion, this may be highly dangerous. As case in
point, with the development of 802.15.4-2003, the same mixing was
suggested (CBC-MAC, CTR, CCM) and shown to lead to an unsecure scheme (I
can send you my presentation at the time [Nov 2002]).
-Section 4.2.4: CCM mode of operation uses a nonce, rather than IV. With
RoLL, this is a 13-byte entry, rather than a 16-byte entry. Moreover,
the structure of the nonce matters, since it is aimed at preventing
nonce reuse by a single sender/amongst different senders sharing the
same key.
-Section 6.1, bullet #CS (8 bits): shouldn't this entry enumerate,
rather than provide a number.
-Section 6.7, 3rd para: the IEEE MAC address is a 64-bit entry (rather
than a 48-bit address). Not sure how the reference to RFC 4291 comes
into play here.
-Section 6.10.2: Table 6.10.2c suggests the use of AES-CBC-MAC-x. Why
not use CCM instead (it provides various combinations of encryption and
authentication, including authentication-only).


-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363
--------------020006000406070306050304-- From prvs=2619253cd=Roger.Alexander@cooperindustries.com Fri Oct 14 13:14:39 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2EF121F8C74 for ; Fri, 14 Oct 2011 13:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+roRTNIOLQo for ; Fri, 14 Oct 2011 13:14:22 -0700 (PDT) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by ietfa.amsl.com (Postfix) with ESMTP id A8C5C21F8C71 for ; Fri, 14 Oct 2011 13:14:19 -0700 (PDT) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.69,348,1315195200"; d="scan'208,217";a="28547387" Received: from cipt0175.nam.ci.root ([10.132.108.175]) by cooperlighting-sw.cooperlighting.com with ESMTP; 14 Oct 2011 16:14:19 -0400 Received: from EVS2.NAM.CI.ROOT ([10.132.108.170]) by cipt0175.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 16:14:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8AAD.BC698A67" Date: Fri, 14 Oct 2011 16:13:23 -0400 Message-ID: In-Reply-To: <4E983D47.1020601@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Roll] notes re AMiKey draft(draft-alexander-roll-amikey-lln-key-mgmt-02) Thread-Index: AcyKd9h+MB2vZ4m3R+CNTelSpUOFhwAGO//g References: <4E975CA0.4010104@gmail.com> <4E983D47.1020601@gmail.com> From: "Alexander, Roger" To: "Rene Struik" , X-OriginalArrivalTime: 14 Oct 2011 20:14:18.0399 (UTC) FILETIME=[DA56AAF0:01CC8AAD] Subject: Re: [Roll] notes re AMiKey draft(draft-alexander-roll-amikey-lln-key-mgmt-02) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 20:14:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8AAD.BC698A67 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rene, =20 Thank you very much for the detailed review and comments. Please see responses below. =20 AMIKEY is of course a separate key management application intended to provide the out-of-band key management specification called for to support RPL 'Authenticated' mode security (see RPL, Section 3.2.3). It is thus intended to support the long-term updating/re-keying of the group key used to provide routing security among RPL peers.=20 =20 Thanks again. =20 Best regards, =20 Roger =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Rene Struik Sent: Friday, October 14, 2011 9:47 AM To: roll@ietf.org Subject: [Roll] notes re AMiKey draft(draft-alexander-roll-amikey-lln-key-mgmt-02) =20 [resend] -------- Original Message --------=20 Subject:=20 notes re AMiKey draft (draft-alexander-roll-amikey-lln-key-mgmt-02) Date:=20 Thu, 13 Oct 2011 17:48:16 -0400 From:=20 Rene Struik =20 To:=20 Alexander, Roger , Tsao, Tzeta =20 CC:=20 roll@ietf.org =20 Dear Roger, Tzeta: =20 Please find below some notes on your AMIKey draft (draft-alexander-roll-amikey-lln-key-mgmt-02). =20 I made the assumption that cryptographic protection is based on a nonce-based cryptographic mode of operation and that replay protection would be provided (thus, necessitating each receiving device to keep some nonce state on sending devices).=20 >>[RA] Correct. MIKEY does discuss the state information required (see Section 5.4). The required state maintenance is of course simplified where system-wide time is available though a Counter can also be used and is part of the specification. Note that in the specific case of RPL key management, state information is required only between the RPL node and the key server entity. =20 =20 While AMIKey could have applications that would not require a nonce-based mechanism and replay protection, this seems a fair assumption (and holds for RoLL-based cryptographic protection). >>[RA] Agreed. =20 As suggested previously, some of my notes have more to do with MIKey (RFC 3830), so it seems, than with AMIKey. However, some have to do with implicit assumptions on what basic functionality devices have on board. >>[RA] Understood but useful to clarify since it is the base for AMIKEY. =20 Please feel free to discuss. =20 Best regards, Rene =20 =3D=3D =20 1) Notion of time Some of the MIKey constructs (e.g., CSB Id, Section 1.4) suggest that one assumes devices have a notion of time, e.g., to be used to detect replays/duplicates, and correlate messages with the corresponding acknowledgement. With RoLL, this notion of time is not a given. Moreover, this begs the question as to what to do if time notions between devices are out-of-synch. Does the MIKey specification cater to this? >>[RA] Yes for MIKEY there is a notion of system time but an optional Counter is also defined. The NTP-based Timestamp is mandatory for MIKEY (See Section 4.2.8 and 6.6 of RFC 3830). For AMIKEY however, the Counter is to be made mandatory, while Timestamp is optional (consistent with RPL).=20 See Section 5.4 of RFC3830 for a good discussion of the issue regarding the tradeoff of state maintenance (replay cache) versus degree of time synchronization to be maintained.=20 =20 Additional note: -Section 5.2, first para: this seems to suggest a mandatory timestamp. >>[RA] This should read "Timestamp [payload]" where as specified in RFC3830 the Timestamp payload can be a Timestamp or Counter value. =20 Not sure what the granularity is with MIKey (important, since not to be reused) and how this time stamp would be managed. >>[RA] The granularity as given for NTP (32-bit fractional second). Devices would increment to their degree of supported system time synchronization. =20 -Section 6.14, 2nd para: here, key validity periods are specified (KV), thus requiring a sufficiently accurate shared notion of time (for, if not, any time check may be unreliable or futile). >>[RA] Only applicable where system time is supported. The validity period can be defined by an Interval (Valid From and Valid To) that can be referenced to the Timestamp of the key assignment message. The granularity in the triggering of key updates will depend on the system time accuracy supported. =20 =20 =20 2) Key dependencies It seems that MIKey defines a deterministic mapping between key encryption keys (TGK) and session keys (TEK). As a result, inadvertent key exposure of the TGK key will expose all derived keys as well. This may be undesirable, e.g., if TGK is shared amongst many devices and one of those devices gets compromised. If session keys would be generated at random and transported over a secure per-device-pair channel instead, the impact of compromise of a single node seems more limited. Moreover, it seems to be preferable to have a logical separation between keys (e.g., in the event of ownership transfer of a single node or replacement of a malfunctioning single node). >>[RA] Yes there is a deterministic mapping between the TEK generating key (TGK) and the TEK. However, the use of a TGK to derive multiple TEKs only applies where required for simultaneous assignment or update of related keys, as applicable for example in the multimedia domain for voice video, etc. For RPL the RPL routing group key (TEK) would be the only key derived from the assigned TGK.=20 =20 =20 Additional note: -From Section 2 (AMIKey overview, para below Fig. 2) it is unclear whether the TEK is used directly as cryptographic key with, e.g., RoLL, or whether one derives additional keying material from this. -Section 6.16 (Key Index payload): this may benefit from some more explanation. >>[RA] The TEK is the security key that will be assigned (derived from the TGK) by the RPL Key Server for use in securing the routing exchanges between the RPL peers. Some further clarifications can be made to ensure that this is better understood. As in other sections, the intent will be to use RPL-specific examples throughout while maintaining the protocol's more general application.=20 =20 =20 3) Key identification With RoLL, the pair (key source identifier, key index) indicates both the originator of the key ("key source id") and an index ("key index") of keys issued by this key originator. This does not necessarily imply, though, that keys are correlated, as is suggested in Section 1.4. (It seems that KeySourceId identifies a TGK, while KeyIndex identifies a parameter so as to allow computation of TEK=3Df(TGK,#)). If this interpretation is correct, this leads to key dependencies that may be undesirable, e.g., in the event of key compromise. >>[RA] As part of the 'Authenticated' mode operation, RPL-19, Section 10.1, RPL uses a shared group key assigned by a network Key Server (where pre-shared keys or public keys may be used to secure the key management communications with the key server). The Key Index associated with the assigned RPL group key allows RPL nodes to ensure synchronization to a common shared key. RPL's group key can be changed by the key server at any time and nodes can request the current key when out of sync with a routing peer (that is, when having a lower Key index key). The Key Source ID would refer to the RPL key server entity, again to ensure synchronization among RPL routing peers as to the entity from which the group key was obtained. Since the security of RPL routing exchanges is based on the shared group key it is vulnerable to compromise of a single group member and hence the need for key updates. With a single TGK/TEK assigned there is no difference in the level of vulnerability between the single assigned group TGK or the derived group TEK. =20 =20 =20 4) Challenge response protocol I am somewhat concerned about some of the message flows with MIKey (e.g., Section 3, 3rd para, Fig. 3), since a key request could arise, e.g., if a key or nonce are "out-of-synch" (which, for keys, mens that one does not have the proper key; for nonces, that one has lost this value). With MIKey PSK flows, this would result (in the context of RPL) that one cannot adequately secure the first message Q_MESSAGE, thereby aborting the protocol. Simply put, what does one do if keys are lost or if nonces are out of synch?=20 >>[RA] Keep in mind that the key being requested, the RPL group key that the node may have determined to be out of synch with its routing peers is different from the key being used to secure and authenticate the RPL node client (Q) to the key server (I). If the node is using a PSK for authenticating exchanges to the key server and that key is out of synch, the device needs to be re-provisioned/reconfigured (with Error indication of inability to access key server, for ex.). =20 =20 Moreover, the message flows do not seem to provide for timeliness (in other words: how does entity I know that the request by entity R is "fresh")? >>[RA] Timeliness is supported only where the time-based Timestamp is used. In the case of Q_MESSAGE the Timestamp payload is included in the message set according to the time of origination of the message. When the message is received at the server (I), it can be accepted provided it is within the allowable time window when (including allowance for degree to system time synchronization). In the returned I_MESSAGE the same Timestamp value is included which again must be received at Q within an allowable roundtrip time window (again subject to allowances for degree of system time synchronization).=20 =20 =20 In out-of-synch scenarios, it seems better to employ a proper challenge/response protocol (unilateral entity authentication), where the key requestor sends a random challenge to the key assignment initiator and where the response messsage includes a protected version of the requested key and incorporates this random value. This results in implicit key authentication (only the requestor can recover the key [assuming both entities have a shared key]) and provides logical binding between message flows without dependency on nonces. >>[RA] The Q_MESSAGE is indeed protected and so the Requestor's Timestamp value provides the equivalent of the random value. The logical binding is therefore supported in the defined mechanism. Let us discuss to ensure I fully understand the concern. =20 =20 NOTE RS: with RoLL, this may cause some trouble, since this suggests mixing of unsecured and secured traffic in the network (which, vaguely, seems to be forbidden using the "security mode"). Since with RoLL, the security mode and the security level seems to be unduly tied together, this may result in the security mode toggling between unsecured and secured once such a C/R protocol would get implemented. >>[RA] Keep in mind that the communications with the key server in RPL is distinct from the communications with routing peers. The key server using PSK or PKE methods with each node is able to assign the routing security group key. In the RPL 'Authenticated' mode a node has a key that only allows a leaf join (no routing). That leaf join then allows key management exchanges with the key server to obtain the current routing group key. Until that group key is obtained the node cannot operate as a routing peer. =20 =20 5) Timeliness/ logical binding in protocol flows It is not entirely clear how the MIKey protocol provides for logical binding between protocol flows. As already mentioned, this may be a problem with the protocol flows in Fig. 3 (key request), but also with subsequent detailed protocol flows (such as with Fig. 5, using the PSK method). >>[RA] See above discussion. =20 =20 Additional note: -Section 3.1, 2nd last para: doesn't this impact the resulting properties? >>[RA] This determines when a key assignment confirmation is required for a server-initiated key push. =20 =20 6) Public key usage: The MIKEY protocol seems to use the same public key both for signing and for encryption. It is unclear in abstracto whether this poses problems, but common practice is to separate public keys for different cryptographic purposes. If this practice is heeded to, this requires the use of two public keys per device (including management hereof). >>[RA] Noted. A recommendation that could be made for devices/networks that support additional processing resource capabilities. =20 =20 Additional note: -Section 3.2, forelast para: wouldn't this impact freshness and aliveness properties? >>[RA] Timeliness checks can be supported when the time-based Timestamp payload is used (see discussion above). =20 =20 -Section 3.2 vs. 3.3: What is the rationale for making public key encryption (3.2) mandatory and Diffie-Hellman key exchange (3.3) optional? To me, it seems that use of public key techniques may significantly simplify configuration management (since this now depends on juggling publicly available information, rather than handling of secret keying material). Of those techniques, DH-based protocols seem to be best suited for highly constrained networks, where energy cost and implementation footprint come at a premium. Moreover, these may also be more resistant to side channel attacks (not trivial, esp. for devices that can be expected to be low-cost, consumer-style devices that may not be able to rely on tamper-evidencing techniques). This suggests that public-key based techniques, rather than symmetric-key based techniques (with proper eye for detail, of course) should be mandatory to implement. >>[RA] I think it would be more consistent with RPL to make PSK mandatory and both PKE and DH methods optional. This comment was also made by another reviewer. The intent of AMIKEY is to provide a reasonable lowest-common denominator with the ability to ratchet up the security level based on application environment. =20 =20 7) Hash function The suggested "hash function" (Section 4.1.2 - use of CMAC) may be somewhat unfortunate, since it is invertible if one has access to the key (in contrast to HMAC-SHAx, which is one-way, or block-cipher based hashes, such as AES-MMO, as ZigBee SE1.x used). This may have implications in the event of key compromise. >>[RA] Agreed. A trade-off made to permit lowest common denominator (all AES implementation) devices. SHAx of course remains an option that is available for devices/networks that can support the additional capability. =20 =20 8) Key management fit [as already noted by others] Overarching question may be whether key management functionality best fits with RoLL, CoRE, etc. Of course, this a perennial question. Nevertheless, some of the functionality described seems to suggest layer violation (e.g., Section 6.1.2, Table 6.1.e), since RoLL may not know about application layers, etc. >>[RA] As described in the Section 2, the key management entity logically exists independent of the device protocol layers. The KM entity can thus select the particular protocol for which key management is being performed. As previously discussed, the objective is to be able to handle key management for one or more layers with a single protocol given the constraints of a LLN-type device.=20 =20 =20 9) Other notes -Section 4: RFC 4493 corresponds to NIST SP 800-38B. >>[RA] Noted. =20 =20 -Section 4.1.2: not sure what the AES-CMAC alignment remark is about. BTW - this seems to suggest one can mix usage of CMAC with that of CCM with the same key (cf. also Section 6.2 (Table 6.2.b) and the last para of Section 6.2). In my opinion, this may be highly dangerous. As case in point, with the development of 802.15.4-2003, the same mixing was suggested (CBC-MAC, CTR, CCM) and shown to lead to an unsecure scheme (I can send you my presentation at the time [Nov 2002]). >>[RA] I think this was just loose wording intended to convey replacement. CCM can be mandated. I would still be interested in your reference paper.=20 =20 =20 -Section 4.2.4: CCM mode of operation uses a nonce, rather than IV. With RoLL, this is a 13-byte entry, rather than a 16-byte entry. Moreover, the structure of the nonce matters, since it is aimed at preventing nonce reuse by a single sender/amongst different senders sharing the same key. >>[RA] Understood. The intent was to re-use the "IV" information element given in RFC 3830 as a Nonce. Since that "IV" included the Timestamp (time-based or Counter from the originator) it was guaranteed to be non-repeating. This should be cleaned up to avoid potential confusion. =20 =20 =20 -Section 6.1, bullet #CS (8 bits): shouldn't this entry enumerate, rather than provide a number. >>[RA] No this should be a number. This number will match the number of subsequent occurrences of "CS ID map info" elements in the message. =20 -Section 6.7, 3rd para: the IEEE MAC address is a 64-bit entry (rather than a 48-bit address). Not sure how the reference to RFC 4291 comes into play here. >>[RA] The idea is to allow use of the 48-bit MAC as an ID as well as the IEEE EUI 64-bit MAC where it can be derived from the IP address of packet carrying the key exchange message (the IPv6 address being auto-configured from the MAC address in conformance with RFC4291). =20 =20 -Section 6.10.2: Table 6.10.2c suggests the use of AES-CBC-MAC-x. Why not use CCM instead (it provides various combinations of encryption and authentication, including authentication-only). >>[RA] Yes CCM can be mandated. =20 =20 --=20 email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 =20 =20 ------_=_NextPart_001_01CC8AAD.BC698A67 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rene,

 

Thank = you very much for the detailed review and comments. Please see responses = below.

 

AMIKEY is of course a separate key management = application intended to provide the out-of-band key management = specification called for to support RPL ‘Authenticated’ mode = security (see RPL, Section 3.2.3). It is thus intended to support the = long-term updating/re-keying of the group key used to provide routing = security among RPL peers.

 

Thanks = again.

 

Best regards,

 

Roger

 

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of Rene Struik
Sent: Friday, October 14, 2011 9:47 = AM
To: roll@ietf.org
Subject: [Roll] notes re AMiKey = draft(draft-alexander-roll-amikey-lln-key-mgmt-02)

<= /div>

 

[resend]

-------- Original Message -------- =

<= /table>

 

Dear Roger, =
Tzeta:
 
Please find =
below some notes on your AMIKey =
draft
(draft-alexander-roll-amikey-lln-key-mgmt-02).=

 
I made the assumption =
that cryptographic protection is based on =
a
nonce-based cryptographic mode of operation and =
that replay protection
would be provided (thus, =
necessitating each receiving device to keep
some =
nonce state on sending devices).

>>[RA] Correct. MIKEY does discuss the state = information required (see Section 5.4). The required state maintenance = is of course simplified where system-wide time is available though a = Counter can also be used and is part of the specification. Note that in = the specific case of RPL key management, state information is required = only between the RPL node and the key server = entity.

 
 
While AMIKey could =
have
applications that would not require a =
nonce-based mechanism and replay
protection, this =
seems a fair assumption (and holds for =
RoLL-based
cryptographic =
protection).

>>[RA] = Agreed.

 
As suggested =
previously, some of my notes have more to do with =
MIKey
(RFC 3830), so it seems, than with AMIKey. =
However, some have to do with
implicit assumptions =
on what basic functionality devices have on board.

>>[RA] Understood but useful to clarify since = it is the base for = AMIKEY.

 
Please feel free =
to discuss.
 
Best =
regards, =
Rene
 
=3D=3D
 
1) Notion of =
time
Some of the MIKey constructs (e.g., CSB Id, =
Section 1.4) suggest that
one assumes devices have =
a notion of time, e.g., to be used to =
detect
replays/duplicates, and correlate messages =
with the corresponding
acknowledgement. With RoLL, =
this notion of time is not a given.
Moreover, this =
begs the question as to what to do if time =
notions
between devices are out-of-synch. Does the =
MIKey specification cater =
to
this?
>>[RA] Yes for MIKEY there is a notion of =
system time but an optional Counter is also defined. The NTP-based =
Timestamp is mandatory for MIKEY (See Section 4.2.8 and 6.6 of RFC =
3830). For AMIKEY however, the Counter is to be made mandatory, while =
Timestamp is optional (consistent with RPL). 
See Section 5.4 of RFC3830 for a good discussion of =
the issue regarding the tradeoff of state maintenance (replay cache) =
versus degree of time synchronization to be maintained. =

 
Additional =
note:
-Section 5.2, first para: this seems to =
suggest a mandatory timestamp.
>>[RA] This should read "Timestamp =
[payload]" where as specified in RFC3830 the Timestamp payload can =
be a Timestamp or Counter value.
 
Not sure what the granularity is =
with MIKey (important, since not to be
reused) and =
how this time stamp would be managed.
>>[RA] The granularity as given for NTP =
(32-bit fractional second). Devices would increment to their degree of =
supported system time synchronization.
 
-Section 6.14, 2nd para: here, key =
validity periods are specified (KV),
thus requiring =
a sufficiently accurate shared notion of time (for, =
if
not, any time check may be unreliable or =
futile).
>>[RA] Only =
applicable where system time is supported. The validity period can be =
defined by an Interval (Valid From and Valid To) that can be referenced =
to the Timestamp of the key assignment message. The granularity in the =
triggering of key updates will depend on the system time accuracy =
supported.    
 
 
2) Key =
dependencies
It seems that MIKey defines a =
deterministic mapping between key
encryption keys =
(TGK) and session keys (TEK). As a result, =
inadvertent
key exposure of the TGK key will expose =
all derived keys as well. This
may be undesirable, =
e.g., if TGK is shared amongst many devices and =
one
of those devices gets compromised. If session =
keys would be generated at
random and transported =
over a secure per-device-pair channel instead,
the =
impact of compromise of a single node seems more limited. =
Moreover,
it seems to be preferable to have a =
logical separation between keys
(e.g., in the event =
of ownership transfer of a single node =
or
replacement of a malfunctioning single =
node).
>>[RA] Yes there is =
a deterministic mapping between the TEK generating key (TGK) and the =
TEK. However, the use of a TGK to derive multiple TEKs only applies =
where required for simultaneous assignment or update of related keys, as =
applicable for example in the multimedia domain for voice video, etc. =
For RPL the RPL routing group key (TEK) would be the only key derived =
from the assigned TGK. 
 
 
Additio=
nal note:
-From Section 2 (AMIKey overview, para =
below Fig. 2) it is unclear
whether the TEK is used =
directly as cryptographic key with, e.g., RoLL,
or =
whether one derives additional keying material from =
this.
-Section 6.16 (Key Index payload): this may =
benefit from some =
more
explanation.
>>[RA] The TEK is the security key that will =
be assigned (derived from the TGK) by the RPL Key Server for use in =
securing the routing exchanges between the RPL peers. Some further =
clarifications can be made to ensure that this is better understood. As =
in other sections, the intent will be to use RPL-specific examples =
throughout while maintaining the protocol’s more general =
application. 
 
 
3) Key =
identification
With RoLL, the pair (key source =
identifier, key index) indicates both
the =
originator of the key ("key source id") and an index =
("key index")
of keys issued by this key =
originator. This does not necessarily =
imply,
though, that keys are correlated, as is =
suggested in Section 1.4. (It
seems that =
KeySourceId identifies a TGK, while KeyIndex identifies =
a
parameter so as to allow computation of =
TEK=3Df(TGK,#)). If this
interpretation is correct, =
this leads to key dependencies that may =
be
undesirable, e.g., in the event of key =
compromise.
>>[RA] As part =
of the 'Authenticated' mode operation, RPL-19, Section 10.1, RPL uses a =
shared group key assigned by a network Key Server (where pre-shared keys =
or public keys may be used to secure the key management communications =
with the key server). The Key Index associated with the assigned RPL =
group key allows RPL nodes to ensure synchronization to a common shared =
key. RPL's group key can be changed by the key server at any time and =
nodes can request the current key when out of sync with a routing peer =
(that is, when having a lower Key index key). The Key Source ID would =
refer to the RPL key server entity, again to ensure synchronization =
among RPL routing peers as to the entity from which the group key was =
obtained. Since the security of RPL routing exchanges is based on the =
shared group key it is vulnerable to compromise of a single group member =
and hence the need for key updates. With a single TGK/TEK assigned there =
is no difference in the level of vulnerability between the single =
assigned group TGK or the derived group TEK.  =

 
 
4) Challenge response =
protocol
I am somewhat concerned about some of the =
message flows with MIKey
(e.g., Section 3, 3rd =
para, Fig. 3), since a key request could =
arise,
e.g., if a key or nonce are =
"out-of-synch" (which, for keys, mens =
that
one does not have the proper key; for nonces, =
that one has lost this
value). With MIKey PSK =
flows, this would result (in the context of =
RPL)
that one cannot adequately secure the first =
message Q_MESSAGE, thereby
aborting the protocol. =
Simply put, what does one do if keys are lost or
if =
nonces are out of synch? 
>>[RA] Keep in mind that the key being =
requested, the RPL group key that the node may have determined to be out =
of synch with its routing peers is different from the key being used to =
secure and authenticate the RPL node client (Q) to the key server (I). =
If the node is using a PSK for authenticating exchanges to the key =
server and that key is out of synch, the device needs to be =
re-provisioned/reconfigured (with Error indication of inability to =
access key server, for ex.).
 
 
Moreover, the message =
flows do not seem to provide for timeliness (in other words: how does =
entity I know that the request by entity R is =
"fresh")?
>>[RA] =
Timeliness is supported only where the time-based Timestamp is used. In =
the case of Q_MESSAGE the Timestamp payload is included in the message =
set according to the time of origination of the message. When the =
message is received at the server (I), it can be accepted provided it is =
within the allowable time window when (including allowance for degree to =
system time synchronization). In the returned I_MESSAGE the same =
Timestamp value is included which again must be received at Q within an =
allowable roundtrip time window (again subject to allowances for degree =
of system time synchronization). 
 
 
In out-of-synch scenarios, it =
seems better to employ a proper
challenge/response =
protocol (unilateral entity authentication), =
where
the key requestor sends a random challenge to =
the key assignment
initiator and where the response =
messsage includes a protected version
of the =
requested key and incorporates this random value. This results =
in
implicit key authentication (only the requestor =
can recover the key
[assuming both entities have a =
shared key]) and provides logical binding
between =
message flows without dependency on nonces.
>>[RA] The Q_MESSAGE is indeed protected and =
so the Requestor's Timestamp value provides the equivalent of the random =
value. The logical binding is therefore supported in the defined =
mechanism. Let us discuss to ensure I fully understand the =
concern.
 
 
NOTE RS: with RoLL, this may cause =
some trouble, since this suggests
mixing of =
unsecured and secured traffic in the network (which, =
vaguely,
seems to be forbidden using the =
"security mode"). Since with RoLL, =
the
security mode and the security level seems to =
be unduly tied together,
this may result in the =
security mode toggling between unsecured =
and
secured once such a C/R protocol would get =
implemented.
>>[RA] Keep in =
mind that the communications with the key server in RPL is distinct from =
the communications with routing peers. The key server using PSK or PKE =
methods with each node is able to assign the routing security group key. =
In the RPL 'Authenticated' mode a node has a key that only allows a leaf =
join (no routing). That leaf join then allows key management exchanges =
with the key server to obtain the current routing group key. Until that =
group key is obtained the node cannot operate as a routing =
peer.=

 
 
5) Timeliness/ logical binding in =
protocol flows
It is not entirely clear how the =
MIKey protocol provides for logical
binding between =
protocol flows. As already mentioned, this may be =
a
problem with the protocol flows in Fig. 3 (key =
request), but also with
subsequent detailed =
protocol flows (such as with Fig. 5, using the =
PSK
method).
>>[RA] See above =
discussion.
 
 
Additio=
nal note:
-Section 3.1, 2nd last para: doesn't this =
impact the resulting properties?
>>[RA] This determines when a key assignment =
confirmation is required for a server-initiated key =
push.
 
 
6) Public key =
usage:
The MIKEY protocol seems to use the same =
public key both for signing and
for encryption. It =
is unclear in abstracto whether this poses =
problems,
but common practice is to separate public =
keys for different
cryptographic purposes. If this =
practice is heeded to, this requires the
use of two =
public keys per device (including management hereof).
>>[RA] Noted. A recommendation that could be =
made for devices/networks that support additional processing resource =
capabilities.
 
 
Additional =
note:
-Section 3.2, forelast para: wouldn't this =
impact freshness and
aliveness =
properties?
>>[RA] =
Timeliness checks can be supported when the time-based Timestamp payload =
is used (see discussion above).
 
 
-Section 3.2 vs. 3.3: What is the =
rationale for making public key
encryption (3.2) =
mandatory and Diffie-Hellman key exchange =
(3.3)
optional? To me, it seems that use of public =
key techniques may
significantly simplify =
configuration management (since this now depends
on =
juggling publicly available information, rather than handling =
of
secret keying material). Of those techniques, =
DH-based protocols seem to
be best suited for =
highly constrained networks, where energy cost =
and
implementation footprint come at a premium. =
Moreover, these may also be
more resistant to side =
channel attacks (not trivial, esp. for devices
that =
can be expected to be low-cost, consumer-style devices that may =
not
be able to rely on tamper-evidencing =
techniques). This suggests that
public-key based =
techniques, rather than symmetric-key based =
techniques
(with proper eye for detail, of course) =
should be mandatory to implement.
>>[RA] I think it would be more consistent =
with RPL to make PSK mandatory and both PKE and DH methods optional. =
This comment was also made by another reviewer. The intent of AMIKEY is =
to provide a reasonable lowest-common denominator with the ability to =
ratchet up the security level based on application =
environment.
 
 
7) Hash =
function
The suggested "hash function" =
(Section 4.1.2 - use of CMAC) may be
somewhat =
unfortunate, since it is invertible if one has access to =
the
key (in contrast to HMAC-SHAx, which is =
one-way, or block-cipher based
hashes, such as =
AES-MMO, as ZigBee SE1.x used). This may =
have
implications in the event of key =
compromise.
>>[RA] Agreed. =
A trade-off made to permit lowest common denominator (all AES =
implementation) devices. SHAx of course remains an option that is =
available for devices/networks that can support the additional =
capability.
 
 
8) Key =
management fit
[as already noted by others] =
Overarching question may be whether key
management =
functionality best fits with RoLL, CoRE, etc. Of course, =
this
a perennial question. Nevertheless, some of =
the functionality described
seems to suggest layer =
violation (e.g., Section 6.1.2, Table 6.1.e),
since =
RoLL may not know about application layers, etc.
>>[RA] As described in the Section 2, the key =
management entity logically exists independent of the device protocol =
layers. The KM entity can thus select the particular protocol for which =
key management is being performed. As previously discussed, the =
objective is to be able to handle key management for one or more layers =
with a single protocol given the constraints of a LLN-type device. =

 
 
9) Other =
notes
-Section 4: RFC 4493 corresponds to NIST SP =
800-38B.
>>[RA] =
Noted.
 
 
-Section =
4.1.2: not sure what the AES-CMAC alignment remark is =
about.
BTW - this seems to suggest one can mix =
usage of CMAC with that of CCM
with the same key =
(cf. also Section 6.2 (Table 6.2.b) and the last =
para
of Section 6.2). In my opinion, this may be =
highly dangerous. As case in
point, with the =
development of 802.15.4-2003, the same mixing =
was
suggested (CBC-MAC, CTR, CCM) and shown to lead =
to an unsecure scheme (I
can send you my =
presentation at the time [Nov 2002]).
>>[RA] I think this was just loose wording =
intended to convey replacement. CCM can be mandated. I would still be =
interested in your reference paper. 
 
 
-Section 4.2.4: CCM mode of =
operation uses a nonce, rather than IV. With
RoLL, =
this is a 13-byte entry, rather than a 16-byte entry. =
Moreover,
the structure of the nonce matters, since =
it is aimed at preventing
nonce reuse by a single =
sender/amongst different senders sharing the
same =
key.
>>[RA] Understood. =
The intent was to re-use the "IV" information element given in =
RFC 3830 as a Nonce. Since that "IV" included the Timestamp =
(time-based or Counter from the originator) it was guaranteed to be =
non-repeating. This should be cleaned up to avoid potential =
confusion.  
 
 
-Section 6.1, bullet #CS (8 bits): =
shouldn't this entry enumerate,
rather than provide =
a number.
>>[RA] No this =
should be a number. This number will match the number of subsequent =
occurrences of "CS ID map info" elements in the =
message.
 
-Section 6.7, 3rd para: the IEEE =
MAC address is a 64-bit entry (rather
than a 48-bit =
address). Not sure how the reference to RFC 4291 =
comes
into play here.
>>[RA] The idea is to allow use of the 48-bit =
MAC as an ID as well as the IEEE EUI 64-bit MAC where it can be derived =
from the IP address of packet carrying the key exchange message (the =
IPv6 address being auto-configured from the MAC address in conformance =
with RFC4291).
 
 
-Section 6.10.2: Table 6.10.2c =
suggests the use of AES-CBC-MAC-x. Why
not use CCM =
instead (it provides various combinations of encryption =
and
authentication, including =
authentication-only).
>>[RA] Yes CCM can be =
mandated.
 
 
-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) =
867-5658
USA Google voice: +1 (415) =
690-7363
 
 

------_=_NextPart_001_01CC8AAD.BC698A67--

From jpv@cisco.com  Sat Oct 15 09:07:50 2011
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814FF21F8AB0 for ; Sat, 15 Oct 2011 09:07:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.607
X-Spam-Level: 
X-Spam-Status: No, score=-105.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0o-Na7QEmvdG for ; Sat, 15 Oct 2011 09:07:50 -0700 (PDT)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id B643B21F8AAF for ; Sat, 15 Oct 2011 09:07:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=138; q=dns/txt; s=iport; t=1318694869; x=1319904469; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=F+pi9Z5Cop4PkBCrY7f7DLrzk/+gYuQWyqSHp8qovWM=; b=AvFl0keI2obcaFpQEQ/xEdRa1TABdygvYEleFzElYCxBq/BulS+pbPj4 ZgTurZtJ7JfwsSazLNKtV14s2AW5pYtHmzQrps2B8WmvR265sgdLLWbQu 2oPsMFlrWVorJ8/KzuyKkWB8ND8Ak4HqcGxgpni5yQ8GpRufQuTMK7sSV M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvwEAJmumU5Io8UQ/2dsb2JhbABDqGSBBYIHASeBfTWfA4EmAZ1ShydhBJN6hSkJjCY
X-IronPort-AV: E=Sophos;i="4.69,351,1315180800";  d="scan'208";a="1077582"
Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-3.cisco.com with ESMTP; 15 Oct 2011 16:07:44 +0000
Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9FG7h7M026923 for ; Sat, 15 Oct 2011 16:07:43 GMT
Received: from xfe-hkg-412.apac.cisco.com ([64.104.123.71]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Sun, 16 Oct 2011 00:07:43 +0800
Received: from [10.60.114.232] ([10.60.114.232]) by xfe-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Sun, 16 Oct 2011 00:07:42 +0800
From: JP Vasseur 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Sat, 15 Oct 2011 02:14:41 +0200
Message-Id: <90307235-2455-4201-B4E8-A80131B5C1A8@cisco.com>
To: roll WG 
Mime-Version: 1.0 (Apple Message framework v1244.3)
X-Mailer: Apple Mail (2.1244.3)
X-OriginalArrivalTime: 15 Oct 2011 16:07:43.0135 (UTC) FILETIME=[92164AF0:01CC8B54]
Subject: [Roll] IETF-82 slot
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 15 Oct 2011 16:07:50 -0000

Dear all,

Please let us know by Oct 30 if you plan to request a slot for the ROLL =
IETF-82 WG meeting.

Thanks.

JP and David.=

From pthubert@cisco.com  Mon Oct 17 03:33:43 2011
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361CA21F8B2A for ; Mon, 17 Oct 2011 03:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level: 
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[AWL=2.677,  BAYES_00=-2.599, GB_AFFORDABLE=1, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndm0yPVuj5yB for ; Mon, 17 Oct 2011 03:33:42 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4B64721F877F for ; Mon, 17 Oct 2011 03:33:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2920; q=dns/txt; s=iport; t=1318847622; x=1320057222; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=UDo70T2tHR0kcxPZyq8M+KX6n8wk5aRFeVHlzyVj0UI=; b=OY0VkLJMgHVIBFIWXd+gDreGRVuTtHJ8ls+C6zAXclDA5mSsU9+991vb Q+Ygh7QSti6swxoQDYK2zOUL/ydEpOEATmKEQvF7egVB8tuoLi+aDXDol R1MNHb031neLg1aQdPnZcaMcDfRSMUB7uzUKeZ3fGebniqk7QEg7HKdJR w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAOgDnE6Q/khR/2dsb2JhbABEhHWidXuBBYFuAQEBBBIBEA0EQw4EAgEIEQQBAQMCBgYXAQICAgEBRAcBAQUDAQEEEwganCgBjEeRRIEwhUQzYQSZLIwm
X-IronPort-AV: E=Sophos;i="4.69,358,1315180800"; d="scan'208";a="119271104"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 17 Oct 2011 10:33:39 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9HAXcux004830 for ; Mon, 17 Oct 2011 10:33:38 GMT
Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 17 Oct 2011 12:33:38 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Mon, 17 Oct 2011 12:33:37 +0200
Message-ID: 
In-Reply-To: <20111017100411.16096.53541.idtracker@ietfa.amsl.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: New Version Notification for draft-thubert-roll-asymlink-00.txt
Thread-Index: AcyMtCKH1qQZiHY4Sy2TQWOWlPUZQwAAJfkw
References: <20111017100411.16096.53541.idtracker@ietfa.amsl.com>
From: "Pascal Thubert (pthubert)" 
To: "roll WG" 
X-OriginalArrivalTime: 17 Oct 2011 10:33:38.0719 (UTC) FILETIME=[3B82A2F0:01CC8CB8]
Subject: [Roll] FW: New Version Notification for draft-thubert-roll-asymlink-00.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Oct 2011 10:33:43 -0000

RGVhciBXRzoNCg0KRHVyaW5nIHRoZSBlbGFib3JhdGlvbiBvZiBSUEwgZHJhZnQsIFJQTCB0aWNr
ZXQgIzMyIHdhcyBvcGVuZWQgdG8gY292ZXIgQXN5bW1ldHJpYyBMaW5rcy4gUmljaGFyZCBpbiBw
YXJ0aWN1bGFyIHN1Z2dlc3RlZCB0byAiQWRkIGEgZmxhZyB0byBSb3V0aW5nIE1ldHJpYy9Db25z
dHJhaW50IHRvIGluZGljYXRlIHdoZXRoZXIgdGhlIHBhdGggbWV0cmljIHJlcHJlc2VudHMgdGhl
IHVwd2FyZCAoZmxhZyA9IDApIG9yIGRvd253YXJkIChmbGFnID0gMSkgbWV0cmljLiAgVGhlIGZs
YWcgd291bGQgb25seSBiZSBtZWFuaW5nZnVsIGZvciBwYXRoIG1ldHJpY3MgdGhhdCBhcmUgYWdn
cmVnYXRpb25zIG9mIHBvdGVudGlhbGx5IGFzeW1tZXRyaWMgbGluayBtZXRyaWNzLCBzdWNoIGFz
IGxhdGVuY3kgb3IgbGluayBxdWFsaXR5Ii4gDQoNClRoZSBncm91cCBkaWQgbm90IGV4cHJlc3Mg
ZW5vdWdoIGludGVyZXN0IGF0IHRoZSB0aW1lIHRvIG1ha2UgdGhhdCBmZWF0dXJlIGEgY29yZSBm
ZWF0dXJlIG9mIHRoZSBwcm90b2NvbC4gDQoNClN0aWxsLCB0aGVyZSBhcmUgc3BlY2lmaWMgY2Fz
ZXMgb2Ygc3Ryb25nbHkgYXN5bW1ldHJpY2FsIGxpbmtzIHdoZXJlIGFuIG9wdGltaXphdGlvbiB3
b3VsZCBiZSB1c2VmdWwgd2hlbiBhZmZvcmRhYmxlLiBUaGlzIHBvcHBlZCB1cCBhZ2FpbiByZWNl
bnRseSBkdXJpbmcgdGhlIGJpLXdlZWtseSBkaXNjdXNzaW9uIGJldHdlZW4gdGhlIGF1dGhvcnMg
b2YgdGhlIGluZHVzdHJpYWwgYXBwbGljYWJpbGl0eSBkcmFmdC4gU28gd2UgZGVjaWRlZCB0aGF0
IEkgc2hvdWxkIHJhaXNlIHRoZSBxdWVzdGlvbiBhZ2FpbiB0byB0aGUgZ3JvdXAsIGFzIGEgbmV3
IG9wdGltaXphdGlvbi4gVGhpcyBkcmFmdCBzdWdnZXN0ZWQgYXMgd2UgZGlzY3Vzc2VkIGxvbmcg
YWdvIHRvIG1ha2UgMiBET0RBR3MsIG9uZSBvcHRpbWl6ZWQgZm9yIHVwd2FyZHMgdHJhZmZpYyBh
bmQgb25lIGZvciBkb3dud2FyZHMsIGFuZCB0aGVuIGNvdXBsZSB0aGVtLg0KDQpXaGF0IGRvIHlv
dSB0aGluaz8NCg0KUGFzY2FsDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50
ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSAN
ClNlbnQ6IGx1bmRpIDE3IG9jdG9icmUgMjAxMSAxMjowNA0KVG86IFBhc2NhbCBUaHViZXJ0IChw
dGh1YmVydCkNCkNjOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQpTdWJqZWN0OiBOZXcgVmVy
c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXRodWJlcnQtcm9sbC1hc3ltbGluay0wMC50eHQN
Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXRodWJlcnQtcm9sbC1hc3ltbGluay0wMC50
eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQYXNjYWwgVGh1YmVydCBhbmQg
cG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtdGh1YmVy
dC1yb2xsLWFzeW1saW5rDQpSZXZpc2lvbjoJIDAwDQpUaXRsZToJCSBSUEwgYWRhcHRhdGlvbiBm
b3IgYXN5bW1ldHJpY2FsIGxpbmtzDQpDcmVhdGlvbiBkYXRlOgkgMjAxMS0xMC0xNw0KV0cgSUQ6
CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDkNCg0KQWJzdHJhY3Q6
DQogICBUaGUgUm91dGluZyBQcm90b2NvbCBmb3IgTG93IFBvd2VyIGFuZCBMb3NzeSBOZXR3b3Jr
cyBkZWZpbmVzIGENCiAgIGdlbmVyaWMgRGlzdGFuY2UgVmVjdG9yIHByb3RvY29sIGZvciBMb3cg
UG93ZXIgYW5kIExvc3N5IE5ldHdvcmtzLA0KICAgbWFueSBvZiB3aGljaCBleGhpYml0IHN0cm9u
Z2x5IGFzeW1tZXRyaWNhbCBjaGFyYWN0ZXJpc3RpY3MuICBUaGlzDQogICBkcmFmdCBwcm9wb3Nl
cyBhbiBleHRlbnNpb24gZm9yIHRoYXQgb3B0aW1pemVzIFJQTCBvcGVyYXRpb25zIHdoZXJlYnkN
CiAgIHVwd2FyZHMgYW5kIGRvd253YXJkcyBkaXJlY3Rpb24tb3B0aW1pemVkIFJQTCBpbnN0YW5j
ZXMgYXJlDQogICBhc3NvY2lhdGVkLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0K
DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K

From c.chauvenet@watteco.com  Mon Oct 17 05:30:04 2011
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB16521F8696 for ; Mon, 17 Oct 2011 05:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.849
X-Spam-Level: 
X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, GB_AFFORDABLE=1, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8d-mBSITmj8 for ; Mon, 17 Oct 2011 05:30:04 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 323E121F8AB0 for ; Mon, 17 Oct 2011 05:30:04 -0700 (PDT)
Received: from mail90-ch1-R.bigfish.com (10.43.68.241) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.22; Mon, 17 Oct 2011 12:30:03 +0000
Received: from mail90-ch1 (localhost.localdomain [127.0.0.1])	by mail90-ch1-R.bigfish.com (Postfix) with ESMTP id 0621AF50105; Mon, 17 Oct 2011 12:30:03 +0000 (UTC)
X-SpamScore: -38
X-BigFish: VPS-38(zzc89bh936eK542M1dbaL1432Nzz1202hzz1033IL8275dhz2dh2a8h668h839h8aah)
X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:IE2RD2HUB009.red002.local; RD:none; EFVD:NLI
Received: from mail90-ch1 (localhost.localdomain [127.0.0.1]) by mail90-ch1 (MessageSwitch) id 1318854601971738_22371; Mon, 17 Oct 2011 12:30:01 +0000 (UTC)
Received: from CH1EHSMHS016.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247])	by mail90-ch1.bigfish.com (Postfix) with ESMTP id DD1BBD50053;	Mon, 17 Oct 2011 12:30:01 +0000 (UTC)
Received: from IE2RD2HUB009.red002.local (213.199.187.153) by CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 17 Oct 2011 12:29:59 +0000
Received: from IE2RD2XVS211.red002.local ([172.18.6.55]) by IE2RD2HUB009.red002.local ([10.33.16.248]) with mapi; Mon, 17 Oct 2011 05:29:39 -0700
From: C Chauvenet 
To: "Pascal Thubert (pthubert)" 
Date: Mon, 17 Oct 2011 05:29:37 -0700
Thread-Topic: [Roll] New Version Notification for draft-thubert-roll-asymlink-00.txt
Thread-Index: AcyMyG/1pK8BAFLgSViKBAwpb1hfzw==
Message-ID: <76231006-3774-43F7-B822-495DD6201F98@watteco.com>
References: <20111017100411.16096.53541.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: watteco.com
Cc: roll WG 
Subject: Re: [Roll] New Version Notification for	draft-thubert-roll-asymlink-00.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Oct 2011 12:30:05 -0000

Hi Pascal,

I agree that asymmetric links are challenging to establish a stable and opt=
imal routing topology.

I strongly push the design of a mechanism that could enable to route in suc=
h conditions.

I think it is worth to flesh out a standard mechanism to address issues wit=
h asymmetrical links, as it is not really an exception in LLNs.

I'm sure many RPL implementations faced asymmetrical links, and each one ha=
s its own mechanism.
It may be great to gather our experiments and do it in a standard way.

BTW, it would also enable a safer and quicker behavior of parent selection,=
 as DIO are not acknowledged (Link local multicast).

Your proposition seems good and simple because it just need a flag in the m=
etric container.

I'm wondering about the overhead it would imply.
Would you need to manage 2 DAGs before coupling them ?

C=E9dric.

=20
Le 17 oct. 2011 =E0 12:33, Pascal Thubert (pthubert) a =E9crit :

> Dear WG:
>=20
> During the elaboration of RPL draft, RPL ticket #32 was opened to cover A=
symmetric Links. Richard in particular suggested to "Add a flag to Routing =
Metric/Constraint to indicate whether the path metric represents the upward=
 (flag =3D 0) or downward (flag =3D 1) metric.  The flag would only be mean=
ingful for path metrics that are aggregations of potentially asymmetric lin=
k metrics, such as latency or link quality".=20
>=20
> The group did not express enough interest at the time to make that featur=
e a core feature of the protocol.=20
>=20
> Still, there are specific cases of strongly asymmetrical links where an o=
ptimization would be useful when affordable. This popped up again recently =
during the bi-weekly discussion between the authors of the industrial appli=
cability draft. So we decided that I should raise the question again to the=
 group, as a new optimization. This draft suggested as we discussed long ag=
o to make 2 DODAGs, one optimized for upwards traffic and one for downwards=
, and then couple them.
>=20
> What do you think?
>=20
> Pascal
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20
> Sent: lundi 17 octobre 2011 12:04
> To: Pascal Thubert (pthubert)
> Cc: Pascal Thubert (pthubert)
> Subject: New Version Notification for draft-thubert-roll-asymlink-00.txt
>=20
> A new version of I-D, draft-thubert-roll-asymlink-00.txt has been success=
fully submitted by Pascal Thubert and posted to the IETF repository.
>=20
> Filename:	 draft-thubert-roll-asymlink
> Revision:	 00
> Title:		 RPL adaptation for asymmetrical links
> Creation date:	 2011-10-17
> WG ID:		 Individual Submission
> Number of pages: 9
>=20
> Abstract:
>   The Routing Protocol for Low Power and Lossy Networks defines a
>   generic Distance Vector protocol for Low Power and Lossy Networks,
>   many of which exhibit strongly asymmetrical characteristics.  This
>   draft proposes an extension for that optimizes RPL operations whereby
>   upwards and downwards direction-optimized RPL instances are
>   associated.
>=20
>=20
>=20
>=20
>=20
> The IETF Secretariat
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>=20



From pthubert@cisco.com  Mon Oct 17 05:58:32 2011
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5636D21F8B78 for ; Mon, 17 Oct 2011 05:58:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.256
X-Spam-Level: 
X-Spam-Status: No, score=-5.256 tagged_above=-999 required=5 tests=[AWL=0.343,  BAYES_00=-2.599, GB_AFFORDABLE=1, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mL4C+95TTJs for ; Mon, 17 Oct 2011 05:58:31 -0700 (PDT)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0F621F8B68 for ; Mon, 17 Oct 2011 05:58:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3569; q=dns/txt; s=iport; t=1318856311; x=1320065911; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=KWwTcespNFvkNnd5grUul/Fw7j5x/zf9YpLAgb6Fi5Y=; b=UfNB/VyBizp8/5XjwyDpyfGzudL6sCqjBZOkOe3TInusTJRJ0PCeOLxm uTJxvuA1LmhOOmH00R6ULy27/Rc0JD6wq4qkLov38pTgjMMGFjH70IcAr O56qzhraNZVFne6tHj7YEfWIDReJQDMLRbxAqYQUw9kqkitUrDTDnw29y g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAEQmnE6Q/khL/2dsb2JhbABDqGeBBYFuAQEBAwEBAQEPAR0+CQIFBwQCAQgRBAEBCwYXAQYBJh8JCAEBBBMIGoddCJRaAZ4jBIcnYQSHUpFajCY
X-IronPort-AV: E=Sophos;i="4.69,359,1315180800";  d="scan'208";a="1161361"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 17 Oct 2011 12:58:29 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9HCwT25016783; Mon, 17 Oct 2011 12:58:29 GMT
Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 17 Oct 2011 14:58:29 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 17 Oct 2011 14:58:28 +0200
Message-ID: 
In-Reply-To: <76231006-3774-43F7-B822-495DD6201F98@watteco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] New Version Notification fordraft-thubert-roll-asymlink-00.txt
Thread-Index: AcyMyG/1pK8BAFLgSViKBAwpb1hfzwAAofug
References: <20111017100411.16096.53541.idtracker@ietfa.amsl.com>  <76231006-3774-43F7-B822-495DD6201F98@watteco.com>
From: "Pascal Thubert (pthubert)" 
To: "C Chauvenet" 
X-OriginalArrivalTime: 17 Oct 2011 12:58:29.0235 (UTC) FILETIME=[77762430:01CC8CCC]
Cc: roll WG 
Subject: Re: [Roll] New Version Notification fordraft-thubert-roll-asymlink-00.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Oct 2011 12:58:32 -0000

Hi Cedric:

Please see inline:


[Cedric >] Your proposition seems good and simple because it just need a =
flag in the metric container.

[Pascal >] Actually the proposed 'D' flag is in the DIO base object. The =
'D' flag does not influence only the metric containers, but the OF as a =
whole. For instance that proposal enables existing OFs such as OF0 and =
MrHof to operate with asymmetrical links. The flag tells the OF whether =
to use an metric that accounts for both directions, or for only one =
direction.



[Cedric >] I'm wondering about the overhead it would imply. Would you =
need to manage 2 DAGs before coupling them ?

 [Pascal >] Yes, you end up with 2 instances, and probable one or more =
additional parents. So there is a cost associated to the benefits.  In =
the case of an industrial network, the operational network is often =
computed and optimized by and external Path Computation Engine. In that =
case, it is useful to have a third DAG that is computed by a more =
dynamic OF and that serves as a last resort when the forwarding along =
the optimum graph fails.

Cheers;

Pascal=20




Le 17 oct. 2011 =E0 12:33, Pascal Thubert (pthubert) a =E9crit :

> Dear WG:
>=20
> During the elaboration of RPL draft, RPL ticket #32 was opened to =
cover Asymmetric Links. Richard in particular suggested to "Add a flag =
to Routing Metric/Constraint to indicate whether the path metric =
represents the upward (flag =3D 0) or downward (flag =3D 1) metric.  The =
flag would only be meaningful for path metrics that are aggregations of =
potentially asymmetric link metrics, such as latency or link quality".=20
>=20
> The group did not express enough interest at the time to make that =
feature a core feature of the protocol.=20
>=20
> Still, there are specific cases of strongly asymmetrical links where =
an optimization would be useful when affordable. This popped up again =
recently during the bi-weekly discussion between the authors of the =
industrial applicability draft. So we decided that I should raise the =
question again to the group, as a new optimization. This draft suggested =
as we discussed long ago to make 2 DODAGs, one optimized for upwards =
traffic and one for downwards, and then couple them.
>=20
> What do you think?
>=20
> Pascal
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20
> Sent: lundi 17 octobre 2011 12:04
> To: Pascal Thubert (pthubert)
> Cc: Pascal Thubert (pthubert)
> Subject: New Version Notification for =
draft-thubert-roll-asymlink-00.txt
>=20
> A new version of I-D, draft-thubert-roll-asymlink-00.txt has been =
successfully submitted by Pascal Thubert and posted to the IETF =
repository.
>=20
> Filename:	 draft-thubert-roll-asymlink
> Revision:	 00
> Title:		 RPL adaptation for asymmetrical links
> Creation date:	 2011-10-17
> WG ID:		 Individual Submission
> Number of pages: 9
>=20
> Abstract:
>   The Routing Protocol for Low Power and Lossy Networks defines a
>   generic Distance Vector protocol for Low Power and Lossy Networks,
>   many of which exhibit strongly asymmetrical characteristics.  This
>   draft proposes an extension for that optimizes RPL operations =
whereby
>   upwards and downwards direction-optimized RPL instances are
>   associated.
>=20
>=20
>=20
>=20
>=20
> The IETF Secretariat
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>=20



From prvs=265a68ec4=mukul@uwm.edu  Mon Oct 17 18:05:22 2011
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F92111E80AF for ; Mon, 17 Oct 2011 18:05:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YYrYNbpRLIK for ; Mon, 17 Oct 2011 18:05:21 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCB511E8095 for ; Mon, 17 Oct 2011 18:05:21 -0700 (PDT)
Received: from localhost (HELO mta02.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 17 Oct 2011 20:05:20 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id B9AB812E3C3; Mon, 17 Oct 2011 20:05:20 -0500 (CDT)
X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu
Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBXUaTTAvXkE; Mon, 17 Oct 2011 20:05:20 -0500 (CDT)
Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 462F512E3C0; Mon, 17 Oct 2011 20:05:20 -0500 (CDT)
Date: Mon, 17 Oct 2011 20:05:20 -0500 (CDT)
From: Mukul Goyal 
To: JP Vasseur 
Message-ID: <736630399.709598.1318899920135.JavaMail.root@mail05.pantherlink.uwm.edu>
In-Reply-To: <2AA5AC69E924D149A8D63EB676AF87DBEBC804@DFLE31.ent.ti.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.89.7.92]
X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918)
X-Authenticated-User: mukul@uwm.edu
Cc: roll 
Subject: [Roll] definition of "RPL Domain"
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Oct 2011 01:05:22 -0000

Hi JP

I was wondering if the term "RPL Domain" could be defined in the terminology draft. 

Thanks
Mukul 

----- Forwarded Message -----
From: "Joseph Reddy" 
To: ipv6@ietf.org
Sent: Friday, October 14, 2011 7:15:05 PM
Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt


Hi Jonathan,

The draft uses the term "RPL domain" in several places and this is not clearly defined. 

I would imagine that it includes all nodes that are downstream of the RPL border router. But can you clarify if Host nodes that are downstream of the border router but do not implement any part of RPL ( even as RPL Leaf nodes ) should be considered part of the "RPL domain" ?

In section 5, the draft now says "..Datagrams destined to nodes outside the RPL domain are dropped if the outer-most IPv6 header contains a RPL Option..."

This text would imply that any RPL node sending packets to nodes outside should always tunnel to the Root ? Is that the intention really or am I missing something here.. 

Also note that if non-RPL Host is not considered part of the RPL domain, then I am not sure that a forwarding router can know if the destination is inside the domain or not. 


-Regards, Joseph


------------------------------

Message: 5
Date: Tue, 11 Oct 2011 22:23:10 -0700
From: Jonathan Hui 
To: IETF IPv6 Mailing List 
Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt
Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com>
Content-Type: text/plain; charset=us-ascii


This update is intended to address Jari Arkko's AD review.

Summary of changes:
- Clarify when the RPL Option is used.
- Updated text on recommendations for avoiding fragmentation.
- Specify skip-over-and-continue policy for unrecognized sub-TLVs.
- Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST.
- Specify RPL Border Router operations in terms of forwarding decision outcomes.
- Expand security section.

--
Jonathan Hui

Begin forwarded message:

> From: internet-drafts@ietf.org
> Date: October 11, 2011 10:17:15 PM PDT
> To: i-d-announce@ietf.org
> Cc: ipv6@ietf.org
> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF.
> 
> 	Title           : RPL Option for Carrying RPL Information in Data-Plane Datagrams
> 	Author(s)       : Jonathan W. Hui
>                          JP Vasseur
> 	Filename        : draft-ietf-6man-rpl-option-04.txt
> 	Pages           : 14
> 	Date            : 2011-10-11
> 
>   The RPL protocol requires data-plane datagrams to carry RPL routing
>   information that is processed by RPL routers when forwarding those
>   datagrams.  This document describes the RPL Option for use within a
>   RPL domain.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

From esko.dijk@philips.com  Tue Oct 18 05:01:20 2011
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C3221F8593 for ; Tue, 18 Oct 2011 05:01:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D41REAhW1hm3 for ; Tue, 18 Oct 2011 05:01:19 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 26E6021F8560 for ; Tue, 18 Oct 2011 05:01:18 -0700 (PDT)
Received: from mail47-ch1-R.bigfish.com (10.43.68.243) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.22; Tue, 18 Oct 2011 12:01:18 +0000
Received: from mail47-ch1 (localhost.localdomain [127.0.0.1])	by mail47-ch1-R.bigfish.com (Postfix) with ESMTP id 4860218E838B; Tue, 18 Oct 2011 12:01:18 +0000 (UTC)
X-SpamScore: -70
X-BigFish: VPS-70(zz217bL15d6O9371K9251J8f9IL936eK542M1432Nzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h944h)
X-Forefront-Antispam-Report: CIP:168.87.56.20; KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI
X-FB-SS: 0,13,
Received: from mail47-ch1 (localhost.localdomain [127.0.0.1]) by mail47-ch1 (MessageSwitch) id 1318939276492041_22125; Tue, 18 Oct 2011 12:01:16 +0000 (UTC)
Received: from CH1EHSMHS030.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.254])	by mail47-ch1.bigfish.com (Postfix) with ESMTP id 65A27FC0050;	Tue, 18 Oct 2011 12:01:16 +0000 (UTC)
Received: from smtpx.philips.com (168.87.56.20) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 18 Oct 2011 12:01:13 +0000
Received: from NLAMSEXH04.connect1.local (172.16.153.25) by connect1.philips.com (172.16.156.160) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 18 Oct 2011 14:01:14 +0200
Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLAMSEXH04.connect1.local ([172.16.153.25]) with mapi; Tue, 18 Oct 2011 13:56:41 +0200
From: "Dijk, Esko" 
To: Mukul Goyal , JP Vasseur 
Date: Tue, 18 Oct 2011 14:01:07 +0200
Thread-Topic: [Roll] definition of "RPL Domain"
Thread-Index: AcyNMWZPunDRPQNoTCauijaxSS+1OwATKjsw
Message-ID: 
References: <2AA5AC69E924D149A8D63EB676AF87DBEBC804@DFLE31.ent.ti.com> <736630399.709598.1318899920135.JavaMail.root@mail05.pantherlink.uwm.edu>
In-Reply-To: <736630399.709598.1318899920135.JavaMail.root@mail05.pantherlink.uwm.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Cc: roll 
Subject: Re: [Roll] definition of "RPL Domain"
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Oct 2011 12:01:20 -0000

Sounds like a good idea. I propose then to also define "RPL traffic" in the=
 terminology draft because it can be interpreted in other ways than intende=
d.

best regards,
Esko

-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Muk=
ul Goyal
Sent: Tuesday 18 October 2011 3:05
To: JP Vasseur
Cc: roll
Subject: [Roll] definition of "RPL Domain"

Hi JP

I was wondering if the term "RPL Domain" could be defined in the terminolog=
y draft.

Thanks
Mukul

----- Forwarded Message -----
From: "Joseph Reddy" 
To: ipv6@ietf.org
Sent: Friday, October 14, 2011 7:15:05 PM
Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt


Hi Jonathan,

The draft uses the term "RPL domain" in several places and this is not clea=
rly defined.

I would imagine that it includes all nodes that are downstream of the RPL b=
order router. But can you clarify if Host nodes that are downstream of the =
border router but do not implement any part of RPL ( even as RPL Leaf nodes=
 ) should be considered part of the "RPL domain" ?

In section 5, the draft now says "..Datagrams destined to nodes outside the=
 RPL domain are dropped if the outer-most IPv6 header contains a RPL Option=
..."

This text would imply that any RPL node sending packets to nodes outside sh=
ould always tunnel to the Root ? Is that the intention really or am I missi=
ng something here..

Also note that if non-RPL Host is not considered part of the RPL domain, th=
en I am not sure that a forwarding router can know if the destination is in=
side the domain or not.


-Regards, Joseph


------------------------------

Message: 5
Date: Tue, 11 Oct 2011 22:23:10 -0700
From: Jonathan Hui 
To: IETF IPv6 Mailing List 
Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt
Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com>
Content-Type: text/plain; charset=3Dus-ascii


This update is intended to address Jari Arkko's AD review.

Summary of changes:
- Clarify when the RPL Option is used.
- Updated text on recommendations for avoiding fragmentation.
- Specify skip-over-and-continue policy for unrecognized sub-TLVs.
- Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST.
- Specify RPL Border Router operations in terms of forwarding decision outc=
omes.
- Expand security section.

--
Jonathan Hui

Begin forwarded message:

> From: internet-drafts@ietf.org
> Date: October 11, 2011 10:17:15 PM PDT
> To: i-d-announce@ietf.org
> Cc: ipv6@ietf.org
> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories. This draft is a work item of the IPv6 Maintenance Working Group of t=
he IETF.
>
>       Title           : RPL Option for Carrying RPL Information in Data-P=
lane Datagrams
>       Author(s)       : Jonathan W. Hui
>                          JP Vasseur
>       Filename        : draft-ietf-6man-rpl-option-04.txt
>       Pages           : 14
>       Date            : 2011-10-11
>
>   The RPL protocol requires data-plane datagrams to carry RPL routing
>   information that is processed by RPL routers when forwarding those
>   datagrams.  This document describes the RPL Option for use within a
>   RPL domain.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.


From rstruik.ext@gmail.com  Wed Oct 19 13:11:38 2011
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D11E21F86F6 for ; Wed, 19 Oct 2011 13:11:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.498
X-Spam-Level: 
X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAZIL+chaqCA for ; Wed, 19 Oct 2011 13:11:31 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE6721F86A0 for ; Wed, 19 Oct 2011 13:11:30 -0700 (PDT)
Received: by qyk31 with SMTP id 31so1936993qyk.10 for ; Wed, 19 Oct 2011 13:11:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; bh=BtzJn6tXtkaGmXM6mMi4eUGyFXImxv/KUV8qvVPnsLw=; b=KYHmnr0/rozZ/pJ7xxCWj1uQLldZyC610RUPRw8MPgsj1UNqryIRHIVxHyFQx++DJL CLu8sT31Xk7rnDhWQGbSZpAjnHo0RV1Sq/vdvm1wUSHMUKNXqmbOVdFt3pUl9rGP6sSw gQcQR6SjBBYASSc1TlwmYL99YWY0ebgrEMIa8=
Received: by 10.229.34.139 with SMTP id l11mr1742238qcd.122.1319055084828; Wed, 19 Oct 2011 13:11:24 -0700 (PDT)
Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.117.243]) by mx.google.com with ESMTPS id fz9sm7963617qab.13.2011.10.19.13.11.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Oct 2011 13:11:20 -0700 (PDT)
Message-ID: <4E9F2EE0.4050200@gmail.com>
Date: Wed, 19 Oct 2011 16:11:12 -0400
From: Rene Struik 
User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: "Alexander, Roger" 
References: <4E975CA0.4010104@gmail.com> <4E983D47.1020601@gmail.com> 
In-Reply-To: 
X-Enigmail-Version: 1.3.2
Content-Type: multipart/alternative; boundary="------------040703000907050809090304"
Cc: roll@ietf.org
Subject: Re: [Roll] notes re AMiKey draft(draft-alexander-roll-amikey-lln-key-mgmt-02)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Oct 2011 20:11:38 -0000

This is a multi-part message in MIME format.
--------------040703000907050809090304
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Roger:

Thanks for your feedback.

What would really help here is to showcase a specific instantiation of
AMIKey that exemplifies how it can address the key management aspects
that have been labelled out of scope with rpl-19. This could then also
serve as taking away [resp. identifying] thoughts that interoperability
may be sacrificed once one wishes to switch on security.

Another benefit of this exercise is that it maeks the AMIKey draft
somewhat more concrete for the ROLL WG membership. (It has been written
more abstractly than just to serve rpl, which is great, but may also
deter some of the audience.)

I can imagine this exercise to assume device counters, rather than a
notion of time (since, with rpl, this was argued to be "unrealistic" at
the time [around June 2010], but perhaps this needs revisiting]). This
would allow identifying whether this indeed addresses key management
aspects that were out of scope with rpl so far.

All - it would be invaluable to have some insight as to whether
implementations based on rpl-19 actually use its security provisions and
gain some insight into problems/bottlenecks/interop issues, and
the-like. So far, not too much information on this has been brought to
the foreground, but it would be invaluable to have some.
So, please do not be shy and share your experiences and perspectives here.

Best regards,

Rene



On 14/10/2011 4:13 PM, Alexander, Roger wrote:
>
> Hi Rene,
>
>  
>
> Thank you very much for the detailed review and comments. Please see
> responses below.
>
>  
>
> AMIKEY is of course a separate key management application intended to
> provide the out-of-band key management specification called for to
> support RPL 'Authenticated' mode security (see RPL, Section 3.2.3). It
> is thus intended to support the long-term updating/re-keying of the
> group key used to provide routing security among RPL peers.
>
>  
>
> Thanks again.
>
>  
>
> Best regards,
>
>  
>
> Roger
>
>  
>
>  
>
> *From:*roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf
> Of *Rene Struik
> *Sent:* Friday, October 14, 2011 9:47 AM
> *To:* roll@ietf.org
> *Subject:* [Roll] notes re AMiKey
> draft(draft-alexander-roll-amikey-lln-key-mgmt-02)
>
>  
>
> [resend]
>
> -------- Original Message --------
>
> *Subject: *
>
> 	
>
> notes re AMiKey draft (draft-alexander-roll-amikey-lln-key-mgmt-02)
>
> *Date: *
>
> 	
>
> Thu, 13 Oct 2011 17:48:16 -0400
>
> *From: *
>
> 	
>
> Rene Struik  
>
> *To: *
>
> 	
>
> Alexander, Roger 
> , Tsao, Tzeta
>  
>
> *CC: *
>
> 	
>
> roll@ietf.org 
>
>  
>
> Dear Roger, Tzeta:
>  
> Please find below some notes on your AMIKey draft
> (draft-alexander-roll-amikey-lln-key-mgmt-02).
>  
> I made the assumption that cryptographic protection is based on a
> nonce-based cryptographic mode of operation and that replay protection
> would be provided (thus, necessitating each receiving device to keep
> some nonce state on sending devices). 
>
> >>[RA] Correct. MIKEY does discuss the state information required (see
> Section 5.4). The required state maintenance is of course simplified
> where system-wide time is available though a Counter can also be used
> and is part of the specification. Note that in the specific case of
> RPL key management, state information is required only between the RPL
> node and the key server entity.
>
>  
>  
> While AMIKey could have
> applications that would not require a nonce-based mechanism and replay
> protection, this seems a fair assumption (and holds for RoLL-based
> cryptographic protection).
>
> >>[RA] Agreed.
>
>  
> As suggested previously, some of my notes have more to do with MIKey
> (RFC 3830), so it seems, than with AMIKey. However, some have to do with
> implicit assumptions on what basic functionality devices have on board.
>
> >>[RA] Understood but useful to clarify since it is the base for AMIKEY.
>
>  
> Please feel free to discuss.
>  
> Best regards, Rene
>  
> ==
>  
> 1) Notion of time
> Some of the MIKey constructs (e.g., CSB Id, Section 1.4) suggest that
> one assumes devices have a notion of time, e.g., to be used to detect
> replays/duplicates, and correlate messages with the corresponding
> acknowledgement. With RoLL, this notion of time is not a given.
> Moreover, this begs the question as to what to do if time notions
> between devices are out-of-synch. Does the MIKey specification cater to
> this?
>
> >>[RA] Yes for MIKEY there is a notion of system time but an optional
> Counter is also defined. The NTP-based Timestamp is mandatory for
> MIKEY (See Section 4.2.8 and 6.6 of RFC 3830). For AMIKEY however, the
> Counter is to be made mandatory, while Timestamp is optional
> (consistent with RPL).
>
> See Section 5.4 of RFC3830 for a good discussion of the issue
> regarding the tradeoff of state maintenance (replay cache) versus
> degree of time synchronization to be maintained.
>
>  
> Additional note:
> -Section 5.2, first para: this seems to suggest a mandatory timestamp.
>
> >>[RA] This should read "Timestamp [payload]" where as specified in
> RFC3830 the Timestamp payload can be a Timestamp or Counter value.
>
>  
> Not sure what the granularity is with MIKey (important, since not to be
> reused) and how this time stamp would be managed.
>
> >>[RA] The granularity as given for NTP (32-bit fractional second).
> Devices would increment to their degree of supported system time
> synchronization.
>
>  
> -Section 6.14, 2nd para: here, key validity periods are specified (KV),
> thus requiring a sufficiently accurate shared notion of time (for, if
> not, any time check may be unreliable or futile).
>
> >>[RA] Only applicable where system time is supported. The validity
> period can be defined by an Interval (Valid From and Valid To) that
> can be referenced to the Timestamp of the key assignment message. The
> granularity in the triggering of key updates will depend on the system
> time accuracy supported.   
>
>  
>  
> 2) Key dependencies
> It seems that MIKey defines a deterministic mapping between key
> encryption keys (TGK) and session keys (TEK). As a result, inadvertent
> key exposure of the TGK key will expose all derived keys as well. This
> may be undesirable, e.g., if TGK is shared amongst many devices and one
> of those devices gets compromised. If session keys would be generated at
> random and transported over a secure per-device-pair channel instead,
> the impact of compromise of a single node seems more limited. Moreover,
> it seems to be preferable to have a logical separation between keys
> (e.g., in the event of ownership transfer of a single node or
> replacement of a malfunctioning single node).
>
> >>[RA] Yes there is a deterministic mapping between the TEK generating
> key (TGK) and the TEK. However, the use of a TGK to derive multiple
> TEKs only applies where required for simultaneous assignment or update
> of related keys, as applicable for example in the multimedia domain
> for voice video, etc. For RPL the RPL routing group key (TEK) would be
> the only key derived from the assigned TGK.
>
>  
>  
> Additional note:
> -From Section 2 (AMIKey overview, para below Fig. 2) it is unclear
> whether the TEK is used directly as cryptographic key with, e.g., RoLL,
> or whether one derives additional keying material from this.
> -Section 6.16 (Key Index payload): this may benefit from some more
> explanation.
>
> >>[RA] The TEK is the security key that will be assigned (derived from
> the TGK) by the RPL Key Server for use in securing the routing
> exchanges between the RPL peers. Some further clarifications can be
> made to ensure that this is better understood. As in other sections,
> the intent will be to use RPL-specific examples throughout while
> maintaining the protocol's more general application.
>
>  
>  
> 3) Key identification
> With RoLL, the pair (key source identifier, key index) indicates both
> the originator of the key ("key source id") and an index ("key index")
> of keys issued by this key originator. This does not necessarily imply,
> though, that keys are correlated, as is suggested in Section 1.4. (It
> seems that KeySourceId identifies a TGK, while KeyIndex identifies a
> parameter so as to allow computation of TEK=f(TGK,#)). If this
> interpretation is correct, this leads to key dependencies that may be
> undesirable, e.g., in the event of key compromise.
>
> >>[RA] As part of the 'Authenticated' mode operation, RPL-19, Section
> 10.1, RPL uses a shared group key assigned by a network Key Server
> (where pre-shared keys or public keys may be used to secure the key
> management communications with the key server). The Key Index
> associated with the assigned RPL group key allows RPL nodes to ensure
> synchronization to a common shared key. RPL's group key can be changed
> by the key server at any time and nodes can request the current key
> when out of sync with a routing peer (that is, when having a lower Key
> index key). The Key Source ID would refer to the RPL key server
> entity, again to ensure synchronization among RPL routing peers as to
> the entity from which the group key was obtained. Since the security
> of RPL routing exchanges is based on the shared group key it is
> vulnerable to compromise of a single group member and hence the need
> for key updates. With a single TGK/TEK assigned there is no difference
> in the level of vulnerability between the single assigned group TGK or
> the derived group TEK. 
>
>  
>  
> 4) Challenge response protocol
> I am somewhat concerned about some of the message flows with MIKey
> (e.g., Section 3, 3rd para, Fig. 3), since a key request could arise,
> e.g., if a key or nonce are "out-of-synch" (which, for keys, mens that
> one does not have the proper key; for nonces, that one has lost this
> value). With MIKey PSK flows, this would result (in the context of RPL)
> that one cannot adequately secure the first message Q_MESSAGE, thereby
> aborting the protocol. Simply put, what does one do if keys are lost or
> if nonces are out of synch? 
>
> >>[RA] Keep in mind that the key being requested, the RPL group key
> that the node may have determined to be out of synch with its routing
> peers is different from the key being used to secure and authenticate
> the RPL node client (Q) to the key server (I). If the node is using a
> PSK for authenticating exchanges to the key server and that key is out
> of synch, the device needs to be re-provisioned/reconfigured (with
> Error indication of inability to access key server, for ex.).
>
>  
>
>  
>
> Moreover, the message flows do not seem to provide for timeliness (in other words: how does entity I know that the request by entity R is "fresh")?
>
> >>[RA] Timeliness is supported only where the time-based Timestamp is
> used. In the case of Q_MESSAGE the Timestamp payload is included in
> the message set according to the time of origination of the message.
> When the message is received at the server (I), it can be accepted
> provided it is within the allowable time window when (including
> allowance for degree to system time synchronization). In the returned
> I_MESSAGE the same Timestamp value is included which again must be
> received at Q within an allowable roundtrip time window (again subject
> to allowances for degree of system time synchronization).
>
>  
>  
> In out-of-synch scenarios, it seems better to employ a proper
> challenge/response protocol (unilateral entity authentication), where
> the key requestor sends a random challenge to the key assignment
> initiator and where the response messsage includes a protected version
> of the requested key and incorporates this random value. This results in
> implicit key authentication (only the requestor can recover the key
> [assuming both entities have a shared key]) and provides logical binding
> between message flows without dependency on nonces.
>
> >>[RA] The Q_MESSAGE is indeed protected and so the Requestor's
> Timestamp value provides the equivalent of the random value. The
> logical binding is therefore supported in the defined mechanism. Let
> us discuss to ensure I fully understand the concern.
>
>  
>  
> NOTE RS: with RoLL, this may cause some trouble, since this suggests
> mixing of unsecured and secured traffic in the network (which, vaguely,
> seems to be forbidden using the "security mode"). Since with RoLL, the
> security mode and the security level seems to be unduly tied together,
> this may result in the security mode toggling between unsecured and
> secured once such a C/R protocol would get implemented.
> >>[RA] Keep in mind that the communications with the key server in RPL is distinct from the communications with routing peers. The key server using PSK or PKE methods with each node is able to assign the routing security group key. In the RPL 'Authenticated' mode a node has a key that only allows a leaf join (no routing). That leaf join then allows key management exchanges with the key server to obtain the current routing group key. Until that group key is obtained the node cannot operate as a routing peer.
>  
>  
> 5) Timeliness/ logical binding in protocol flows
> It is not entirely clear how the MIKey protocol provides for logical
> binding between protocol flows. As already mentioned, this may be a
> problem with the protocol flows in Fig. 3 (key request), but also with
> subsequent detailed protocol flows (such as with Fig. 5, using the PSK
> method).
>
> >>[RA] See above discussion.
>
>  
>  
> Additional note:
> -Section 3.1, 2nd last para: doesn't this impact the resulting properties?
>
> >>[RA] This determines when a key assignment confirmation is required
> for a server-initiated key push.
>
>  
>  
> 6) Public key usage:
> The MIKEY protocol seems to use the same public key both for signing and
> for encryption. It is unclear in abstracto whether this poses problems,
> but common practice is to separate public keys for different
> cryptographic purposes. If this practice is heeded to, this requires the
> use of two public keys per device (including management hereof).
>
> >>[RA] Noted. A recommendation that could be made for devices/networks
> that support additional processing resource capabilities.
>
>  
>  
> Additional note:
> -Section 3.2, forelast para: wouldn't this impact freshness and
> aliveness properties?
>
> >>[RA] Timeliness checks can be supported when the time-based
> Timestamp payload is used (see discussion above).
>
>  
>  
> -Section 3.2 vs. 3.3: What is the rationale for making public key
> encryption (3.2) mandatory and Diffie-Hellman key exchange (3.3)
> optional? To me, it seems that use of public key techniques may
> significantly simplify configuration management (since this now depends
> on juggling publicly available information, rather than handling of
> secret keying material). Of those techniques, DH-based protocols seem to
> be best suited for highly constrained networks, where energy cost and
> implementation footprint come at a premium. Moreover, these may also be
> more resistant to side channel attacks (not trivial, esp. for devices
> that can be expected to be low-cost, consumer-style devices that may not
> be able to rely on tamper-evidencing techniques). This suggests that
> public-key based techniques, rather than symmetric-key based techniques
> (with proper eye for detail, of course) should be mandatory to implement.
>
> >>[RA] I think it would be more consistent with RPL to make PSK
> mandatory and both PKE and DH methods optional. This comment was also
> made by another reviewer. The intent of AMIKEY is to provide a
> reasonable lowest-common denominator with the ability to ratchet up
> the security level based on application environment.
>
>  
>  
> 7) Hash function
> The suggested "hash function" (Section 4.1.2 - use of CMAC) may be
> somewhat unfortunate, since it is invertible if one has access to the
> key (in contrast to HMAC-SHAx, which is one-way, or block-cipher based
> hashes, such as AES-MMO, as ZigBee SE1.x used). This may have
> implications in the event of key compromise.
>
> >>[RA] Agreed. A trade-off made to permit lowest common denominator
> (all AES implementation) devices. SHAx of course remains an option
> that is available for devices/networks that can support the additional
> capability.
>
>  
>  
> 8) Key management fit
> [as already noted by others] Overarching question may be whether key
> management functionality best fits with RoLL, CoRE, etc. Of course, this
> a perennial question. Nevertheless, some of the functionality described
> seems to suggest layer violation (e.g., Section 6.1.2, Table 6.1.e),
> since RoLL may not know about application layers, etc.
>
> >>[RA] As described in the Section 2, the key management entity
> logically exists independent of the device protocol layers. The KM
> entity can thus select the particular protocol for which key
> management is being performed. As previously discussed, the objective
> is to be able to handle key management for one or more layers with a
> single protocol given the constraints of a LLN-type device.
>
>  
>  
> 9) Other notes
> -Section 4: RFC 4493 corresponds to NIST SP 800-38B.
>
> >>[RA] Noted.
>
>  
>  
> -Section 4.1.2: not sure what the AES-CMAC alignment remark is about.
> BTW - this seems to suggest one can mix usage of CMAC with that of CCM
> with the same key (cf. also Section 6.2 (Table 6.2.b) and the last para
> of Section 6.2). In my opinion, this may be highly dangerous. As case in
> point, with the development of 802.15.4-2003, the same mixing was
> suggested (CBC-MAC, CTR, CCM) and shown to lead to an unsecure scheme (I
> can send you my presentation at the time [Nov 2002]).
>
> >>[RA] I think this was just loose wording intended to convey
> replacement. CCM can be mandated. I would still be interested in your
> reference paper.
>
>  
>  
> -Section 4.2.4: CCM mode of operation uses a nonce, rather than IV. With
> RoLL, this is a 13-byte entry, rather than a 16-byte entry. Moreover,
> the structure of the nonce matters, since it is aimed at preventing
> nonce reuse by a single sender/amongst different senders sharing the
> same key.
>
> >>[RA] Understood. The intent was to re-use the "IV" information
> element given in RFC 3830 as a Nonce. Since that "IV" included the
> Timestamp (time-based or Counter from the originator) it was
> guaranteed to be non-repeating. This should be cleaned up to avoid
> potential confusion. 
>
>  
>
>  
> -Section 6.1, bullet #CS (8 bits): shouldn't this entry enumerate,
> rather than provide a number.
>
> >>[RA] No this should be a number. This number will match the number
> of subsequent occurrences of "CS ID map info" elements in the message.
>
>  
> -Section 6.7, 3rd para: the IEEE MAC address is a 64-bit entry (rather
> than a 48-bit address). Not sure how the reference to RFC 4291 comes
> into play here.
>
> >>[RA] The idea is to allow use of the 48-bit MAC as an ID as well as
> the IEEE EUI 64-bit MAC where it can be derived from the IP address of
> packet carrying the key exchange message (the IPv6 address being
> auto-configured from the MAC address in conformance with RFC4291).
>
>  
>  
> -Section 6.10.2: Table 6.10.2c suggests the use of AES-CBC-MAC-x. Why
> not use CCM instead (it provides various combinations of encryption and
> authentication, including authentication-only).
>
> >>[RA] Yes CCM can be mandated.
>
>  
>  
> -- 
> email: rstruik.ext@gmail.com 
> Skype: rstruik
> cell: +1 (647) 867-5658
> USA Google voice: +1 (415) 690-7363
>  
>  


-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363


--------------040703000907050809090304
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Roger:

    

    Thanks for your feedback.

    

    What would really help here is to showcase a specific instantiation
    of AMIKey that exemplifies how it can address the key management
    aspects that have been labelled out of scope with rpl-19. This could
    then also serve as taking away [resp. identifying] thoughts that
    interoperability may be sacrificed once one wishes to switch on
    security.

    

    Another benefit of this exercise is that it maeks the AMIKey draft
    somewhat more concrete for the ROLL WG membership. (It has been
    written more abstractly than just to serve rpl, which is great, but
    may also deter some of the audience.)

    

    I can imagine this exercise to assume device counters, rather than a
    notion of time (since, with rpl, this was argued to be "unrealistic"
    at the time [around June 2010], but perhaps this needs revisiting]).
    This would allow identifying whether this indeed addresses key
    management aspects that were out of scope with rpl so far.

    

    All - it would be invaluable to have some insight as to whether
    implementations based on rpl-19 actually use its security provisions
    and gain some insight into problems/bottlenecks/interop issues, and
    the-like. So far, not too much information on this has been brought
    to the foreground, but it would be invaluable to have some.

    So, please do not be shy and share your experiences and perspectives
    here.

    

    Best regards,

    

    Rene

    

    

    

    On 14/10/2011 4:13 PM, Alexander, Roger wrote:
    

      
      
      
      

        
Hi Rene,

        
 

        
Thank you very much for the detailed
          review and comments. Please see responses below.

        
 

        
AMIKEY is of course a separate key
          management application intended to provide the out-of-band key
          management specification called for to support RPL
          ‘Authenticated’ mode security (see RPL, Section 3.2.3). It is
          thus intended to support the long-term updating/re-keying of
          the group key used to provide routing security among RPL
          peers. 

        
 

        
Thanks again.

        
 

        
Best regards,

        
 

        
Roger

        
 

        
 

        

          

            
From:
                roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
                  Behalf Of Rene Struik

                Sent: Friday, October 14, 2011 9:47 AM

                To: roll@ietf.org

                Subject: [Roll] notes re AMiKey
                draft(draft-alexander-roll-amikey-lln-key-mgmt-02)

          

        

        
 

        
[resend]

          

          -------- Original Message --------

Subject:

notes re AMiKey = draft = (draft-alexander-roll-amikey-lln-key-mgmt-02)

Date: =

Thu, 13 Oct 2011 17:48:16 = -0400

From:

Rene Struik <rstruik.ext@gmail.com>

To:

Alexander, Roger = <Roger.Alexander@= cooperindustries.com>, Tsao, Tzeta <Tzeta.Tsao@cooperindu= stries.com>

CC:

roll@ietf.org

Subject:

notes re AMiKey draft (draft-alexander-roll-amikey-lln-key-mgmt-02)

Date:

Thu, 13 Oct 2011 17:48:16 -0400

From:

Rene Struik <rstruik.ext@gmail.com>

To:

Alexander, Roger <Roger.Alexander@cooperindustries.com>, Tsao, Tzeta <Tzeta.Tsao@cooperindustries.com>

CC:

roll@ietf.org

 

Dear Roger, Tzeta:
 
Please find below some notes on your AMIKey draft
(draft-alexander-roll-amikey-lln-key-mgmt-02).
 
I made the assumption that cryptographic protection is based on a
nonce-based cryptographic mode of operation and that replay protection
would be provided (thus, necessitating each receiving device to keep
some nonce state on sending devices).

>>[RA] Correct. MIKEY does discuss the state information required (see Section 5.4). The required state maintenance is of course simplified where system-wide time is available though a Counter can also be used and is part of the specification. Note that in the specific case of RPL key management, state information is required only between the RPL node and the key server entity.

 
 
While AMIKey could have
applications that would not require a nonce-based mechanism and replay
protection, this seems a fair assumption (and holds for RoLL-based
cryptographic protection).

>>[RA] Agreed.

 
As suggested previously, some of my notes have more to do with MIKey
(RFC 3830), so it seems, than with AMIKey. However, some have to do with
implicit assumptions on what basic functionality devices have on board.

>>[RA] Understood but useful to clarify since it is the base for AMIKEY.

 
Please feel free to discuss.
 
Best regards, Rene
 
==
 
1) Notion of time
Some of the MIKey constructs (e.g., CSB Id, Section 1.4) suggest that
one assumes devices have a notion of time, e.g., to be used to detect
replays/duplicates, and correlate messages with the corresponding
acknowledgement. With RoLL, this notion of time is not a given.
Moreover, this begs the question as to what to do if time notions
between devices are out-of-synch. Does the MIKey specification cater to
this?

>>[RA] Yes for MIKEY there is a notion of system time but an optional Counter is also defined. The NTP-based Timestamp is mandatory for MIKEY (See Section 4.2.8 and 6.6 of RFC 3830). For AMIKEY however, the Counter is to be made mandatory, while Timestamp is optional (consistent with RPL).

See Section 5.4 of RFC3830 for a good discussion of the issue regarding the tradeoff of state maintenance (replay cache) versus degree of time synchronization to be maintained. 

 
Additional note:
-Section 5.2, first para: this seems to suggest a mandatory timestamp.

>>[RA] This should read "Timestamp [payload]" where as specified in RFC3830 the Timestamp payload can be a Timestamp or Counter value.

 
Not sure what the granularity is with MIKey (important, since not to be
reused) and how this time stamp would be managed.

>>[RA] The granularity as given for NTP (32-bit fractional second). Devices would increment to their degree of supported system time synchronization.

 
-Section 6.14, 2nd para: here, key validity periods are specified (KV),
thus requiring a sufficiently accurate shared notion of time (for, if
not, any time check may be unreliable or futile).

>>[RA] Only applicable where system time is supported. The validity period can be defined by an Interval (Valid From and Valid To) that can be referenced to the Timestamp of the key assignment message. The granularity in the triggering of key updates will depend on the system time accuracy supported.    

 
 
2) Key dependencies
It seems that MIKey defines a deterministic mapping between key
encryption keys (TGK) and session keys (TEK). As a result, inadvertent
key exposure of the TGK key will expose all derived keys as well. This
may be undesirable, e.g., if TGK is shared amongst many devices and one
of those devices gets compromised. If session keys would be generated at
random and transported over a secure per-device-pair channel instead,
the impact of compromise of a single node seems more limited. Moreover,
it seems to be preferable to have a logical separation between keys
(e.g., in the event of ownership transfer of a single node or
replacement of a malfunctioning single node).

>>[RA] Yes there is a deterministic mapping between the TEK generating key (TGK) and the TEK. However, the use of a TGK to derive multiple TEKs only applies where required for simultaneous assignment or update of related keys, as applicable for example in the multimedia domain for voice video, etc. For RPL the RPL routing group key (TEK) would be the only key derived from the assigned TGK. 

 
 
Additional note:
-From Section 2 (AMIKey overview, para below Fig. 2) it is unclear
whether the TEK is used directly as cryptographic key with, e.g., RoLL,
or whether one derives additional keying material from this.
-Section 6.16 (Key Index payload): this may benefit from some more
explanation.

>>[RA] The TEK is the security key that will be assigned (derived from the TGK) by the RPL Key Server for use in securing the routing exchanges between the RPL peers. Some further clarifications can be made to ensure that this is better understood. As in other sections, the intent will be to use RPL-specific examples throughout while maintaining the protocol’s more general application. 

 
 
3) Key identification
With RoLL, the pair (key source identifier, key index) indicates both
the originator of the key ("key source id") and an index ("key index")
of keys issued by this key originator. This does not necessarily imply,
though, that keys are correlated, as is suggested in Section 1.4. (It
seems that KeySourceId identifies a TGK, while KeyIndex identifies a
parameter so as to allow computation of TEK=f(TGK,#)). If this
interpretation is correct, this leads to key dependencies that may be
undesirable, e.g., in the event of key compromise.

>>[RA] As part of the 'Authenticated' mode operation, RPL-19, Section 10.1, RPL uses a shared group key assigned by a network Key Server (where pre-shared keys or public keys may be used to secure the key management communications with the key server). The Key Index associated with the assigned RPL group key allows RPL nodes to ensure synchronization to a common shared key. RPL's group key can be changed by the key server at any time and nodes can request the current key when out of sync with a routing peer (that is, when having a lower Key index key). The Key Source ID would refer to the RPL key server entity, again to ensure synchronization among RPL routing peers as to the entity from which the group key was obtained. Since the security of RPL routing exchanges is based on the shared group key it is vulnerable to compromise of a single group member and hence the need for key updates. With a single TGK/TEK assigned there is no difference in the level of vulnerability between the single assigned group TGK or the derived group TEK.  

 
 
4) Challenge response protocol
I am somewhat concerned about some of the message flows with MIKey
(e.g., Section 3, 3rd para, Fig. 3), since a key request could arise,
e.g., if a key or nonce are "out-of-synch" (which, for keys, mens that
one does not have the proper key; for nonces, that one has lost this
value). With MIKey PSK flows, this would result (in the context of RPL)
that one cannot adequately secure the first message Q_MESSAGE, thereby
aborting the protocol. Simply put, what does one do if keys are lost or
if nonces are out of synch?

>>[RA] Keep in mind that the key being requested, the RPL group key that the node may have determined to be out of synch with its routing peers is different from the key being used to secure and authenticate the RPL node client (Q) to the key server (I). If the node is using a PSK for authenticating exchanges to the key server and that key is out of synch, the device needs to be re-provisioned/reconfigured (with Error indication of inability to access key server, for ex.).

 

 

Moreover, the message flows do not seem to provide for timeliness (in other words: how does entity I know that the request by entity R is "fresh")?

>>[RA] Timeliness is supported only where the time-based Timestamp is used. In the case of Q_MESSAGE the Timestamp payload is included in the message set according to the time of origination of the message. When the message is received at the server (I), it can be accepted provided it is within the allowable time window when (including allowance for degree to system time synchronization). In the returned I_MESSAGE the same Timestamp value is included which again must be received at Q within an allowable roundtrip time window (again subject to allowances for degree of system time synchronization). 

 
 
In out-of-synch scenarios, it seems better to employ a proper
challenge/response protocol (unilateral entity authentication), where
the key requestor sends a random challenge to the key assignment
initiator and where the response messsage includes a protected version
of the requested key and incorporates this random value. This results in
implicit key authentication (only the requestor can recover the key
[assuming both entities have a shared key]) and provides logical binding
between message flows without dependency on nonces.

>>[RA] The Q_MESSAGE is indeed protected and so the Requestor's Timestamp value provides the equivalent of the random value. The logical binding is therefore supported in the defined mechanism. Let us discuss to ensure I fully understand the concern.

 
 
NOTE RS: with RoLL, this may cause some trouble, since this suggests
mixing of unsecured and secured traffic in the network (which, vaguely,
seems to be forbidden using the "security mode"). Since with RoLL, the
security mode and the security level seems to be unduly tied together,
this may result in the security mode toggling between unsecured and
secured once such a C/R protocol would get implemented.
>>[RA] Keep in mind that the communications with the key server in RPL is distinct from the communications with routing peers. The key server using PSK or PKE methods with each node is able to assign the routing security group key. In the RPL 'Authenticated' mode a node has a key that only allows a leaf join (no routing). That leaf join then allows key management exchanges with the key server to obtain the current routing group key. Until that group key is obtained the node cannot operate as a routing peer.
 
 
5) Timeliness/ logical binding in protocol flows
It is not entirely clear how the MIKey protocol provides for logical
binding between protocol flows. As already mentioned, this may be a
problem with the protocol flows in Fig. 3 (key request), but also with
subsequent detailed protocol flows (such as with Fig. 5, using the PSK
method).

>>[RA] See above discussion.

 
 
Additional note:
-Section 3.1, 2nd last para: doesn't this impact the resulting properties?

>>[RA] This determines when a key assignment confirmation is required for a server-initiated key push.

 
 
6) Public key usage:
The MIKEY protocol seems to use the same public key both for signing and
for encryption. It is unclear in abstracto whether this poses problems,
but common practice is to separate public keys for different
cryptographic purposes. If this practice is heeded to, this requires the
use of two public keys per device (including management hereof).

>>[RA] Noted. A recommendation that could be made for devices/networks that support additional processing resource capabilities.

 
 
Additional note:
-Section 3.2, forelast para: wouldn't this impact freshness and
aliveness properties?

>>[RA] Timeliness checks can be supported when the time-based Timestamp payload is used (see discussion above).

 
 
-Section 3.2 vs. 3.3: What is the rationale for making public key
encryption (3.2) mandatory and Diffie-Hellman key exchange (3.3)
optional? To me, it seems that use of public key techniques may
significantly simplify configuration management (since this now depends
on juggling publicly available information, rather than handling of
secret keying material). Of those techniques, DH-based protocols seem to
be best suited for highly constrained networks, where energy cost and
implementation footprint come at a premium. Moreover, these may also be
more resistant to side channel attacks (not trivial, esp. for devices
that can be expected to be low-cost, consumer-style devices that may not
be able to rely on tamper-evidencing techniques). This suggests that
public-key based techniques, rather than symmetric-key based techniques
(with proper eye for detail, of course) should be mandatory to implement.

>>[RA] I think it would be more consistent with RPL to make PSK mandatory and both PKE and DH methods optional. This comment was also made by another reviewer. The intent of AMIKEY is to provide a reasonable lowest-common denominator with the ability to ratchet up the security level based on application environment.

 
 
7) Hash function
The suggested "hash function" (Section 4.1.2 - use of CMAC) may be
somewhat unfortunate, since it is invertible if one has access to the
key (in contrast to HMAC-SHAx, which is one-way, or block-cipher based
hashes, such as AES-MMO, as ZigBee SE1.x used). This may have
implications in the event of key compromise.

>>[RA] Agreed. A trade-off made to permit lowest common denominator (all AES implementation) devices. SHAx of course remains an option that is available for devices/networks that can support the additional capability.

 
 
8) Key management fit
[as already noted by others] Overarching question may be whether key
management functionality best fits with RoLL, CoRE, etc. Of course, this
a perennial question. Nevertheless, some of the functionality described
seems to suggest layer violation (e.g., Section 6.1.2, Table 6.1.e),
since RoLL may not know about application layers, etc.

>>[RA] As described in the Section 2, the key management entity logically exists independent of the device protocol layers. The KM entity can thus select the particular protocol for which key management is being performed. As previously discussed, the objective is to be able to handle key management for one or more layers with a single protocol given the constraints of a LLN-type device. 

 
 
9) Other notes
-Section 4: RFC 4493 corresponds to NIST SP 800-38B.

>>[RA] Noted.

 
 
-Section 4.1.2: not sure what the AES-CMAC alignment remark is about.
BTW - this seems to suggest one can mix usage of CMAC with that of CCM
with the same key (cf. also Section 6.2 (Table 6.2.b) and the last para
of Section 6.2). In my opinion, this may be highly dangerous. As case in
point, with the development of 802.15.4-2003, the same mixing was
suggested (CBC-MAC, CTR, CCM) and shown to lead to an unsecure scheme (I
can send you my presentation at the time [Nov 2002]).

>>[RA] I think this was just loose wording intended to convey replacement. CCM can be mandated. I would still be interested in your reference paper. 

 
 
-Section 4.2.4: CCM mode of operation uses a nonce, rather than IV. With
RoLL, this is a 13-byte entry, rather than a 16-byte entry. Moreover,
the structure of the nonce matters, since it is aimed at preventing
nonce reuse by a single sender/amongst different senders sharing the
same key.

>>[RA] Understood. The intent was to re-use the "IV" information element given in RFC 3830 as a Nonce. Since that "IV" included the Timestamp (time-based or Counter from the originator) it was guaranteed to be non-repeating. This should be cleaned up to avoid potential confusion. 

 

 
-Section 6.1, bullet #CS (8 bits): shouldn't this entry enumerate,
rather than provide a number.

>>[RA] No this should be a number. This number will match the number of subsequent occurrences of "CS ID map info" elements in the message.

 
-Section 6.7, 3rd para: the IEEE MAC address is a 64-bit entry (rather
than a 48-bit address). Not sure how the reference to RFC 4291 comes
into play here.

>>[RA] The idea is to allow use of the 48-bit MAC as an ID as well as the IEEE EUI 64-bit MAC where it can be derived from the IP address of packet carrying the key exchange message (the IPv6 address being auto-configured from the MAC address in conformance with RFC4291).

 
 
-Section 6.10.2: Table 6.10.2c suggests the use of AES-CBC-MAC-x. Why
not use CCM instead (it provides various combinations of encryption and
authentication, including authentication-only).

>>[RA] Yes CCM can be mandated.

 
 
-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363
 
 


-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363
--------------040703000907050809090304-- From d.sturek@att.net Wed Oct 19 14:20:42 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8411021F8492 for ; Wed, 19 Oct 2011 14:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 947mwRPQEP+I for ; Wed, 19 Oct 2011 14:20:33 -0700 (PDT) Received: from nm13-vm0.access.bullet.mail.sp2.yahoo.com (nm13-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.160]) by ietfa.amsl.com (Postfix) with SMTP id AC9BD1F0C64 for ; Wed, 19 Oct 2011 14:20:33 -0700 (PDT) Received: from [98.139.44.105] by nm13.access.bullet.mail.sp2.yahoo.com with NNFMP; 19 Oct 2011 21:20:33 -0000 Received: from [98.139.44.89] by tm10.access.bullet.mail.sp2.yahoo.com with NNFMP; 19 Oct 2011 21:20:33 -0000 Received: from [127.0.0.1] by omp1026.access.mail.sp2.yahoo.com with NNFMP; 19 Oct 2011 21:20:33 -0000 X-Yahoo-Newman-Id: 597307.89396.bm@omp1026.access.mail.sp2.yahoo.com Received: (qmail 58194 invoked from network); 19 Oct 2011 21:20:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1319059232; bh=xOpxaj5/Mp1aB4fZf5+sEMixl8ve1zpVp2T/Hokg9vo=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=3gBdJxjuX+zv1/kCTGUMDFd0039PLhsiSkCpwFrVIO9HeNAT5v7Q31yuLRMTNZks6WqzT9U/VQYIyuYMutDGLLSpGK4jaPEnP339VUxO8VCMQ4rs+SOKduv7hoJDwVdAR+rgTrZwC7ydskFBrGRRZBwJxcPDh8IoJoR4BDCGnUM= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ZrMnjbsVM1l37kkjgeAvVkwOibujs3lxhjldS1Bq_XSkSWW 8WfiZS0Na1CLDLfO7ezrqgBEU60tNOCSKq6N_BQGIUKkS8nrTsVQjzYT.2iy Rt81JIXCMDPAEEyVoMc5WPcYedQOnzG2A7hGDpmJgm4Qwzy18E6nVnwr_j6T hdzYVxxebuYrtQexhfBCoDfvvDIYTq.3Fgb3x0qIU2TeOGhKpHYwNV2SzHSB 7ltROhGCuU.ur619MvnTh8YIW9r3dz7Qsjc3_UpXXdaCOEILplGLGQKiBdN2 Xg_3NWNV7K6LNU7CyWMTshHzqdObGsJrvzc.LG.6j60F7Ved2MZ17As3JPYC JMXsRIsUXvoIpPZoAB3b13w1hGFMSlmhVU2QCPIuv09Fcjo3M4_uSdrZNJmY DjQ9kE7b3_9QM8pc84dLL9rC9nHZgONelfWG8WCkeYEQL7fcN X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [172.22.13.113] (d.sturek@122.147.240.7 with login) by smtp101.sbc.mail.gq1.yahoo.com with SMTP; 19 Oct 2011 14:20:29 -0700 PDT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Wed, 19 Oct 2011 14:20:13 -0700 From: Don Sturek To: Rene Struik , "Alexander, Roger" Message-ID: Thread-Topic: [Roll] notes re AMiKey draft(draft-alexander-roll-amikey-lln-key-mgmt-02) In-Reply-To: <4E9F2EE0.4050200@gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3401878828_24401" Cc: roll@ietf.org Subject: Re: [Roll] notes re AMiKey draft(draft-alexander-roll-amikey-lln-key-mgmt-02) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 21:20:42 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3401878828_24401 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Rene, Currently, in ZigBee IP, we do not use the RPL security provisions and don'= t plan to in our initial deployments. We are using PANA to provision IEEE 802.15.4 link layer keys (with the ability to update the keys when required= ) then are using TLS security at the application layer. Don From: Rene Struik Date: Wed, 19 Oct 2011 16:11:12 -0400 To: "Alexander, Roger" Cc: Subject: Re: [Roll] notes re AMiKey draft(draft-alexander-roll-amikey-lln-key-mgmt-02) =20 Hi Roger: =20 Thanks for your feedback. =20 What would really help here is to showcase a specific instantiation of AMIKey that exemplifies how it can address the key management aspects that have been labelled out of scope with rpl-19. This could then also serve as taking away [resp. identifying] thoughts that interoperability may be sacrificed once one wishes to switch on security. =20 Another benefit of this exercise is that it maeks the AMIKey draft somewha= t more concrete for the ROLL WG membership. (It has been written more abstractly than just to serve rpl, which is great, but may also deter some of the audience.) =20 I can imagine this exercise to assume device counters, rather than a notio= n of time (since, with rpl, this was argued to be "unrealistic" at the time [around June 2010], but perhaps this needs revisiting]). This would allow identifying whether this indeed addresses key management aspects that were out of scope with rpl so far. =20 All - it would be invaluable to have some insight as to whether implementations based on rpl-19 actually use its security provisions and gain some insight into problems/bottlenecks/interop issues, and the-like. S= o far, not too much information on this has been brought to the foreground, but it would be invaluable to have some. So, please do not be shy and share your experiences and perspectives here. =20 Best regards, =20 Rene =20 =20 =20 On 14/10/2011 4:13 PM, Alexander, Roger wrote: > =20 > =20 >=20 > Hi Rene, > =20 > =20 > =20 > Thank you very much for the detailed review and comments. Please see resp= onses > below. > =20 > =20 > =20 > AMIKEY is of course a separate key management application intended to pro= vide > the out-of-band key management specification called for to support RPL > =8CAuthenticated=B9 mode security (see RPL, Section 3.2.3). It is thus intend= ed to > support the long-term updating/re-keying of the group key used to provide > routing security among RPL peers. > =20 > =20 > =20 > Thanks again. > =20 > =20 > =20 > Best regards, > =20 > =20 > =20 > Roger > =20 > =20 > =20 > =20 > =20 > =20 > =20 >=20 > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of R= ene > Struik > Sent: Friday, October 14, 2011 9:47 AM > To: roll@ietf.org > Subject: [Roll] notes re AMiKey > draft(draft-alexander-roll-amikey-lln-key-mgmt-02) > =20 > =20 > =20 > =20 > =20 > [resend] > =20 > -------- Original Message -------- > =20 > Subject: notes re AMiKey draft > (draft-alexander-roll-amikey-lln-key-mgmt-02) > Date: Thu, 13 Oct 2011 17:48:16 -0400 > From: Rene Struik > To: Alexander, Roger > , Tsao, Tzeta > > CC: roll@ietf.org > =20 > =20 > Dear Roger, Tzeta: > =20 > =20 > =20 > Please find below some notes on your AMIKey draft > =20 > (draft-alexander-roll-amikey-lln-key-mgmt-02). > =20 > =20 > =20 > I made the assumption that cryptographic protection is based on a > =20 > nonce-based cryptographic mode of operation and that replay protection > =20 > would be provided (thus, necessitating each receiving device to keep > =20 > some nonce state on sending devices). > =20 >>> >>[RA] Correct. MIKEY does discuss the state information required (see >>> Section 5.4). The required state maintenance is of course simplified wh= ere >>> system-wide time is available though a Counter can also be used and is = part >>> of the specification. Note that in the specific case of RPL key managem= ent, >>> state information is required only between the RPL node and the key ser= ver >>> entity. > =20 > =20 > =20 > =20 > =20 > While AMIKey could have > =20 > applications that would not require a nonce-based mechanism and replay > =20 > protection, this seems a fair assumption (and holds for RoLL-based > =20 > cryptographic protection). > =20 >>> >>[RA] Agreed. > =20 > =20 > =20 > As suggested previously, some of my notes have more to do with MIKey > =20 > (RFC 3830), so it seems, than with AMIKey. However, some have to do with > =20 > implicit assumptions on what basic functionality devices have on board. > =20 >>> >>[RA] Understood but useful to clarify since it is the base for AMIKEY= . > =20 > =20 > =20 > Please feel free to discuss. > =20 > =20 > =20 > Best regards, Rene > =20 > =20 > =20 > =3D=3D > =20 > =20 > =20 > 1) Notion of time > =20 > Some of the MIKey constructs (e.g., CSB Id, Section 1.4) suggest that > =20 > one assumes devices have a notion of time, e.g., to be used to detect > =20 > replays/duplicates, and correlate messages with the corresponding > =20 > acknowledgement. With RoLL, this notion of time is not a given. > =20 > Moreover, this begs the question as to what to do if time notions > =20 > between devices are out-of-synch. Does the MIKey specification cater to > =20 > this? > =20 >>> >>[RA] Yes for MIKEY there is a notion of system time but an optional >>> Counter is also defined. The NTP-based Timestamp is mandatory for MIKEY= (See >>> Section 4.2.8 and 6.6 of RFC 3830). For AMIKEY however, the Counter is = to be >>> made mandatory, while Timestamp is optional (consistent with RPL). > =20 > See Section 5.4 of RFC3830 for a good discussion of the issue regarding t= he > tradeoff of state maintenance (replay cache) versus degree of time > synchronization to be maintained. > =20 > =20 > =20 > Additional note: > =20 > -Section 5.2, first para: this seems to suggest a mandatory timestamp. > =20 >>> >>[RA] This should read "Timestamp [payload]" where as specified in RFC= 3830 >>> the Timestamp payload can be a Timestamp or Counter value. > =20 > =20 > =20 > Not sure what the granularity is with MIKey (important, since not to be > =20 > reused) and how this time stamp would be managed. > =20 >>> >>[RA] The granularity as given for NTP (32-bit fractional second). Dev= ices >>> would increment to their degree of supported system time synchronizatio= n. > =20 > =20 > =20 > -Section 6.14, 2nd para: here, key validity periods are specified (KV), > =20 > thus requiring a sufficiently accurate shared notion of time (for, if > =20 > not, any time check may be unreliable or futile). > =20 >>> >>[RA] Only applicable where system time is supported. The validity per= iod >>> can be defined by an Interval (Valid From and Valid To) that can be >>> referenced to the Timestamp of the key assignment message. The granular= ity >>> in the triggering of key updates will depend on the system time accurac= y >>> supported. =20 > =20 > =20 > =20 > =20 > =20 > 2) Key dependencies > =20 > It seems that MIKey defines a deterministic mapping between key > =20 > encryption keys (TGK) and session keys (TEK). As a result, inadvertent > =20 > key exposure of the TGK key will expose all derived keys as well. This > =20 > may be undesirable, e.g., if TGK is shared amongst many devices and one > =20 > of those devices gets compromised. If session keys would be generated at > =20 > random and transported over a secure per-device-pair channel instead, > =20 > the impact of compromise of a single node seems more limited. Moreover, > =20 > it seems to be preferable to have a logical separation between keys > =20 > (e.g., in the event of ownership transfer of a single node or > =20 > replacement of a malfunctioning single node). > =20 >>> >>[RA] Yes there is a deterministic mapping between the TEK generating = key >>> (TGK) and the TEK. However, the use of a TGK to derive multiple TEKs on= ly >>> applies where required for simultaneous assignment or update of related >>> keys, as applicable for example in the multimedia domain for voice vide= o, >>> etc. For RPL the RPL routing group key (TEK) would be the only key deri= ved >>> from the assigned TGK. > =20 > =20 > =20 > =20 > =20 > Additional note: > =20 > -From Section 2 (AMIKey overview, para below Fig. 2) it is unclear > =20 > whether the TEK is used directly as cryptographic key with, e.g., RoLL, > =20 > or whether one derives additional keying material from this. > =20 > -Section 6.16 (Key Index payload): this may benefit from some more > =20 > explanation. > =20 >>> >>[RA] The TEK is the security key that will be assigned (derived from = the >>> TGK) by the RPL Key Server for use in securing the routing exchanges be= tween >>> the RPL peers. Some further clarifications can be made to ensure that t= his >>> is better understood. As in other sections, the intent will be to use >>> RPL-specific examples throughout while maintaining the protocol=B9s more >>> general application. > =20 > =20 > =20 > =20 > =20 > 3) Key identification > =20 > With RoLL, the pair (key source identifier, key index) indicates both > =20 > the originator of the key ("key source id") and an index ("key index") > =20 > of keys issued by this key originator. This does not necessarily imply, > =20 > though, that keys are correlated, as is suggested in Section 1.4. (It > =20 > seems that KeySourceId identifies a TGK, while KeyIndex identifies a > =20 > parameter so as to allow computation of TEK=3Df(TGK,#)). If this > =20 > interpretation is correct, this leads to key dependencies that may be > =20 > undesirable, e.g., in the event of key compromise. > =20 >>> >>[RA] As part of the 'Authenticated' mode operation, RPL-19, Section 1= 0.1, >>> RPL uses a shared group key assigned by a network Key Server (where >>> pre-shared keys or public keys may be used to secure the key management >>> communications with the key server). The Key Index associated with the >>> assigned RPL group key allows RPL nodes to ensure synchronization to a >>> common shared key. RPL's group key can be changed by the key server at = any >>> time and nodes can request the current key when out of sync with a rout= ing >>> peer (that is, when having a lower Key index key). The Key Source ID wo= uld >>> refer to the RPL key server entity, again to ensure synchronization amo= ng >>> RPL routing peers as to the entity from which the group key was obtaine= d. >>> Since the security of RPL routing exchanges is based on the shared grou= p key >>> it is vulnerable to compromise of a single group member and hence the n= eed >>> for key updates. With a single TGK/TEK assigned there is no difference = in >>> the level of vulnerability between the single assigned group TGK or the >>> derived group TEK. > =20 > =20 > =20 > =20 > =20 > 4) Challenge response protocol > =20 > I am somewhat concerned about some of the message flows with MIKey > =20 > (e.g., Section 3, 3rd para, Fig. 3), since a key request could arise, > =20 > e.g., if a key or nonce are "out-of-synch" (which, for keys, mens that > =20 > one does not have the proper key; for nonces, that one has lost this > =20 > value). With MIKey PSK flows, this would result (in the context of RPL) > =20 > that one cannot adequately secure the first message Q_MESSAGE, thereby > =20 > aborting the protocol. Simply put, what does one do if keys are lost or > =20 > if nonces are out of synch? > =20 >>> >>[RA] Keep in mind that the key being requested, the RPL group key tha= t the >>> node may have determined to be out of synch with its routing peers is >>> different from the key being used to secure and authenticate the RPL no= de >>> client (Q) to the key server (I). If the node is using a PSK for >>> authenticating exchanges to the key server and that key is out of synch= , the >>> device needs to be re-provisioned/reconfigured (with Error indication o= f >>> inability to access key server, for ex.). > =20 > =20 > =20 > =20 > =20 > Moreover, the message flows do not seem to provide for timeliness (in oth= er > words: how does entity I know that the request by entity R is "fresh")? > =20 >>> >>[RA] Timeliness is supported only where the time-based Timestamp is u= sed. >>> In the case of Q_MESSAGE the Timestamp payload is included in the messa= ge >>> set according to the time of origination of the message. When the messa= ge is >>> received at the server (I), it can be accepted provided it is within th= e >>> allowable time window when (including allowance for degree to system ti= me >>> synchronization). In the returned I_MESSAGE the same Timestamp value is >>> included which again must be received at Q within an allowable roundtri= p >>> time window (again subject to allowances for degree of system time >>> synchronization). > =20 > =20 > =20 > =20 > =20 > In out-of-synch scenarios, it seems better to employ a proper > =20 > challenge/response protocol (unilateral entity authentication), where > =20 > the key requestor sends a random challenge to the key assignment > =20 > initiator and where the response messsage includes a protected version > =20 > of the requested key and incorporates this random value. This results in > =20 > implicit key authentication (only the requestor can recover the key > =20 > [assuming both entities have a shared key]) and provides logical binding > =20 > between message flows without dependency on nonces. > =20 >>> >>[RA] The Q_MESSAGE is indeed protected and so the Requestor's Timesta= mp >>> value provides the equivalent of the random value. The logical binding = is >>> therefore supported in the defined mechanism. Let us discuss to ensure = I >>> fully understand the concern. > =20 > =20 > =20 > =20 > =20 > NOTE RS: with RoLL, this may cause some trouble, since this suggests > =20 > mixing of unsecured and secured traffic in the network (which, vaguely, > =20 > seems to be forbidden using the "security mode"). Since with RoLL, the > =20 > security mode and the security level seems to be unduly tied together, > =20 > this may result in the security mode toggling between unsecured and > =20 > secured once such a C/R protocol would get implemented. > =20 >>> >>[RA] Keep in mind that the communications with the key server in RPL = is >>> distinct from the communications with routing peers. The key server usi= ng >>> PSK or PKE methods with each node is able to assign the routing securit= y >>> group key. In the RPL 'Authenticated' mode a node has a key that only a= llows >>> a leaf join (no routing). That leaf join then allows key management >>> exchanges with the key server to obtain the current routing group key. = Until >>> that group key is obtained the node cannot operate as a routing peer. > =20 > =20 > =20 > =20 > =20 > 5) Timeliness/ logical binding in protocol flows > =20 > It is not entirely clear how the MIKey protocol provides for logical > =20 > binding between protocol flows. As already mentioned, this may be a > =20 > problem with the protocol flows in Fig. 3 (key request), but also with > =20 > subsequent detailed protocol flows (such as with Fig. 5, using the PSK > =20 > method). > =20 >>> >>[RA] See above discussion. > =20 > =20 > =20 > =20 > =20 > Additional note: > =20 > -Section 3.1, 2nd last para: doesn't this impact the resulting properties= ? > =20 >>> >>[RA] This determines when a key assignment confirmation is required f= or a >>> server-initiated key push. > =20 > =20 > =20 > =20 > =20 > 6) Public key usage: > =20 > The MIKEY protocol seems to use the same public key both for signing and > =20 > for encryption. It is unclear in abstracto whether this poses problems, > =20 > but common practice is to separate public keys for different > =20 > cryptographic purposes. If this practice is heeded to, this requires the > =20 > use of two public keys per device (including management hereof). > =20 >>> >>[RA] Noted. A recommendation that could be made for devices/networks = that >>> support additional processing resource capabilities. > =20 > =20 > =20 > =20 > =20 > Additional note: > =20 > -Section 3.2, forelast para: wouldn't this impact freshness and > =20 > aliveness properties? > =20 >>> >>[RA] Timeliness checks can be supported when the time-based Timestamp >>> payload is used (see discussion above). > =20 > =20 > =20 > =20 > =20 > -Section 3.2 vs. 3.3: What is the rationale for making public key > =20 > encryption (3.2) mandatory and Diffie-Hellman key exchange (3.3) > =20 > optional? To me, it seems that use of public key techniques may > =20 > significantly simplify configuration management (since this now depends > =20 > on juggling publicly available information, rather than handling of > =20 > secret keying material). Of those techniques, DH-based protocols seem to > =20 > be best suited for highly constrained networks, where energy cost and > =20 > implementation footprint come at a premium. Moreover, these may also be > =20 > more resistant to side channel attacks (not trivial, esp. for devices > =20 > that can be expected to be low-cost, consumer-style devices that may not > =20 > be able to rely on tamper-evidencing techniques). This suggests that > =20 > public-key based techniques, rather than symmetric-key based techniques > =20 > (with proper eye for detail, of course) should be mandatory to implement. > =20 >>> >>[RA] I think it would be more consistent with RPL to make PSK mandato= ry >>> and both PKE and DH methods optional. This comment was also made by ano= ther >>> reviewer. The intent of AMIKEY is to provide a reasonable lowest-common >>> denominator with the ability to ratchet up the security level based on >>> application environment. > =20 > =20 > =20 > =20 > =20 > 7) Hash function > =20 > The suggested "hash function" (Section 4.1.2 - use of CMAC) may be > =20 > somewhat unfortunate, since it is invertible if one has access to the > =20 > key (in contrast to HMAC-SHAx, which is one-way, or block-cipher based > =20 > hashes, such as AES-MMO, as ZigBee SE1.x used). This may have > =20 > implications in the event of key compromise. > =20 >>> >>[RA] Agreed. A trade-off made to permit lowest common denominator (al= l AES >>> implementation) devices. SHAx of course remains an option that is avail= able >>> for devices/networks that can support the additional capability. > =20 > =20 > =20 > =20 > =20 > 8) Key management fit > =20 > [as already noted by others] Overarching question may be whether key > =20 > management functionality best fits with RoLL, CoRE, etc. Of course, this > =20 > a perennial question. Nevertheless, some of the functionality described > =20 > seems to suggest layer violation (e.g., Section 6.1.2, Table 6.1.e), > =20 > since RoLL may not know about application layers, etc. > =20 >>> >>[RA] As described in the Section 2, the key management entity logical= ly >>> exists independent of the device protocol layers. The KM entity can thu= s >>> select the particular protocol for which key management is being perfor= med. >>> As previously discussed, the objective is to be able to handle key >>> management for one or more layers with a single protocol given the >>> constraints of a LLN-type device. > =20 > =20 > =20 > =20 > =20 > 9) Other notes > =20 > -Section 4: RFC 4493 corresponds to NIST SP 800-38B. > =20 >>> >>[RA] Noted. > =20 > =20 > =20 > =20 > =20 > -Section 4.1.2: not sure what the AES-CMAC alignment remark is about. > =20 > BTW - this seems to suggest one can mix usage of CMAC with that of CCM > =20 > with the same key (cf. also Section 6.2 (Table 6.2.b) and the last para > =20 > of Section 6.2). In my opinion, this may be highly dangerous. As case in > =20 > point, with the development of 802.15.4-2003, the same mixing was > =20 > suggested (CBC-MAC, CTR, CCM) and shown to lead to an unsecure scheme (I > =20 > can send you my presentation at the time [Nov 2002]). > =20 >>> >>[RA] I think this was just loose wording intended to convey replaceme= nt. >>> CCM can be mandated. I would still be interested in your reference pape= r. > =20 > =20 > =20 > =20 > =20 > -Section 4.2.4: CCM mode of operation uses a nonce, rather than IV. With > =20 > RoLL, this is a 13-byte entry, rather than a 16-byte entry. Moreover, > =20 > the structure of the nonce matters, since it is aimed at preventing > =20 > nonce reuse by a single sender/amongst different senders sharing the > =20 > same key. > =20 >>> >>[RA] Understood. The intent was to re-use the "IV" information elemen= t >>> given in RFC 3830 as a Nonce. Since that "IV" included the Timestamp >>> (time-based or Counter from the originator) it was guaranteed to be >>> non-repeating. This should be cleaned up to avoid potential confusion. > =20 > =20 > =20 > =20 > =20 > -Section 6.1, bullet #CS (8 bits): shouldn't this entry enumerate, > =20 > rather than provide a number. > =20 >>> >>[RA] No this should be a number. This number will match the number of >>> subsequent occurrences of "CS ID map info" elements in the message. > =20 > =20 > =20 > -Section 6.7, 3rd para: the IEEE MAC address is a 64-bit entry (rather > =20 > than a 48-bit address). Not sure how the reference to RFC 4291 comes > =20 > into play here. > =20 >>> >>[RA] The idea is to allow use of the 48-bit MAC as an ID as well as t= he >>> IEEE EUI 64-bit MAC where it can be derived from the IP address of pack= et >>> carrying the key exchange message (the IPv6 address being auto-configur= ed >>> from the MAC address in conformance with RFC4291). > =20 > =20 > =20 > =20 > =20 > -Section 6.10.2: Table 6.10.2c suggests the use of AES-CBC-MAC-x. Why > =20 > not use CCM instead (it provides various combinations of encryption and > =20 > authentication, including authentication-only). > =20 >>> >>[RA] Yes CCM can be mandated. > =20 > =20 > =20 > =20 > =20 > --=20 > =20 > email: rstruik.ext@gmail.com > =20 > Skype: rstruik > =20 > cell: +1 (647) 867-5658 > =20 > USA Google voice: +1 (415) 690-7363 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > --=20 > email: rstruik.ext@gmail.com > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 > =20 > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --B_3401878828_24401 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Rene,

Currently, in ZigBee IP, we do not use the RPL security provisions and= don't plan to in our initial deployments.  We are using PANA to provis= ion IEEE 802.15.4 link layer keys (with the ability to update the keys when = required) then are using TLS security at the application layer.
Don


From: Rene Struik <rst= ruik.ext@gmail.com>
Date: W= ed, 19 Oct 2011 16:11:12 -0400
To: = "Alexander, Roger" <Roger.Alexander@cooperindustries.com>
Cc: <roll@ietf.org>Subject: Re: [Roll] notes re AMiKey = draft(draft-alexander-roll-amikey-lln-key-mgmt-02)

<= div>
Hi Roger:

Thanks for your feedback.

What would really help here is to showcase a specific instantiation of AMIKey that exemplifies how it can address the key management aspects that have been labelled out of scope with rpl-19. This could then also serve as taking away [resp. identifying] thoughts that interoperability may be sacrificed once one wishes to switch on security.

Another benefit of this exercise is that it maeks the AMIKey draft somewhat more concrete for the ROLL WG membership. (It has been written more abstractly than just to serve rpl, which is great, but may also deter some of the audience.)

I can imagine this exercise to assume device counters, rather than a notion of time (since, with rpl, this was argued to be "unrealistic" at the time [around June 2010], but perhaps this needs revisiting]). This would allow identifying whether this indeed addresses key management aspects that were out of scope with rpl so far.

All - it would be invaluable to have some insight as to whether implementations based on rpl-19 actually use its security provisions and gain some insight into problems/bottlenecks/interop issues, and the-like. So far, not too much information on this has been brought to the foreground, but it would be invaluable to have some.
So, please do not be shy and share your experiences and perspectives here.

Best regards,

Rene



On 14/10/2011 4:13 PM, Alexander, Roger wrote:

Hi Rene,

 

Thank you very much for the detailed review and comments. Please see responses below.

 

AMIKEY is of course a separate key management application intended to provide the out-of-band key management specification called for to support RPL ‘Authenticated’ mode security (see RPL, Section 3.2.3= ). It is thus intended to support the long-term updating/re-keying of the group key used to provide routing security among RPL peers.

 

Thanks again.

 

Best regards,

 

Roger

 

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Rene Struik
Sent: Friday, October 14, 2011 9:47 AM
To: roll@ietf.org
Subject: [Roll] notes re AMiKey draft(draft-alexander-roll-amikey-lln-key-mgmt-02)

 

[resend]

-------- Original Message --------

Subject:

notes re AMiKey draft (draft-alexander-roll-amikey-lln-key-mgmt-02)<= /p>

Date:

Thu, 13 Oct 2011 17:48:16 -0400

From:

Rene Struik <rstruik.ext@gmail.com>

To:

Alexander, Roger <Roger.Alexander@= cooperindustries.com>, Tsao, Tzeta <Tzeta.Tsao@cooperindustries.com><= /o:p>

CC:

roll@ietf.org

 = 

Dear Roger, Tzeta:
 
Please find below some notes on your AMIKey draft
        
(draft-alexander-roll-amikey-lln-key-mgmt-02).
        
 

        
I made the assumption that cryptographic protection is based o=
n a

        
nonce-based cryptographic mode of operation and that replay pr=
otection

        
would be provided (thus, necessitating each receiving device t=
o keep

        
some nonce state on sending devices). 

        
>>[RA] Correct. MIKEY does discuss
          the state information required (see Section 5.4). The required
          state maintenance is of course simplified where system-wide
          time is available though a Counter can also be used and is
          part of the specification. Note that in the specific case of
          RPL key management, state information is required only between
          the RPL node and the key server entity.

        
 

        
 

        
While AMIKey could have

        
applications that would not require a nonce-based mechanism an=
d replay

        
protection, this seems a fair assumption (and holds for RoLL-b=
ased

        
cryptographic protection).

        
>>[RA] Agreed.

        
 

        
As suggested previously, some of my notes have more to do with=
 MIKey

        
(RFC 3830), so it seems, than with AMIKey. However, some have =
to do with

        
implicit assumptions on what basic functionality devices have =
on board.

        
>>[RA] Understood but useful to
          clarify since it is the base for AMIKEY.

        
 

        
Please feel free to discuss.

        
 

        
Best regards, Rene

        
 

        
=3D=3D

        
 

        
1) Notion of time

        
Some of the MIKey constructs (e.g., CSB Id, Section 1.4) sugge=
st that

        
one assumes devices have a notion of time, e.g., to be used to=
 detect

        
replays/duplicates, and correlate messages with the correspond=
ing

        
acknowledgement. With RoLL, this notion of time is not a given=
.

        
Moreover, this begs the question as to what to do if time noti=
ons

        
between devices are out-of-synch. Does the MIKey specification=
 cater to

        
this?

        
>>[RA] Yes for MIKEY there is a
          notion of system time but an optional Counter is also defined.
          The NTP-based Timestamp is mandatory for MIKEY (See Section
          4.2.8 and 6.6 of RFC 3830). For AMIKEY however, the Counter is
          to be made mandatory, while Timestamp is optional (consistent
          with RPL). 

        
See Section 5.4 of RFC3830 for a good
          discussion of the issue regarding the tradeoff of state
          maintenance (replay cache) versus degree of time
          synchronization to be maintained. 

        
 

        
Additional note:

        
-Section 5.2, first para: this seems to suggest a mandatory ti=
mestamp.

        
>>[RA] This should read "Timestamp
          [payload]" where as specified in RFC3830 the Timestamp payload
          can be a Timestamp or Counter value.

        
 

        
Not sure what the granularity is with MIKey (important, since =
not to be

        
reused) and how this time stamp would be managed.
        
>>[RA] The granularity as given
          for NTP (32-bit fractional second). Devices would increment to
          their degree of supported system time synchronization.=


        
 

        
-Section 6.14, 2nd para: here, key validity periods are specif=
ied (KV),

        
thus requiring a sufficiently accurate shared notion of time (=
for, if

        
not, any time check may be unreliable or futile).
        
>>[RA] Only applicable where
          system time is supported. The validity period can be defined
          by an Interval (Valid From and Valid To) that can be
          referenced to the Timestamp of the key assignment message. The
          granularity in the triggering of key updates will depend on
          the system time accuracy supported.    =


        
 

        
 

        
2) Key dependencies

        
It seems that MIKey defines a deterministic mapping between ke=
y

        
encryption keys (TGK) and session keys (TEK). As a result, ina=
dvertent

        
key exposure of the TGK key will expose all derived keys as we=
ll. This

        
may be undesirable, e.g., if TGK is shared amongst many device=
s and one

        
of those devices gets compromised. If session keys would be ge=
nerated at

        
random and transported over a secure per-device-pair channel i=
nstead,

        
the impact of compromise of a single node seems more limited. =
Moreover,

        
it seems to be preferable to have a logical separation between=
 keys

        
(e.g., in the event of ownership transfer of a single node or<=
o:p>

        
replacement of a malfunctioning single node).
=
        
>>[RA] Yes there is a
          deterministic mapping between the TEK generating key (TGK) and
          the TEK. However, the use of a TGK to derive multiple TEKs
          only applies where required for simultaneous assignment or
          update of related keys, as applicable for example in the
          multimedia domain for voice video, etc. For RPL the RPL
          routing group key (TEK) would be the only key derived from the
          assigned TGK. 

        
 

        
 

        
Additional note:

        
-From Section 2 (AMIKey overview, para below Fig. 2) it is unc=
lear

        
whether the TEK is used directly as cryptographic key with, e.=
g., RoLL,

        
or whether one derives additional keying material from this.

        
-Section 6.16 (Key Index payload): this may benefit from some =
more

        
explanation.

        
>>[RA] The TEK is the security key
          that will be assigned (derived from the TGK) by the RPL Key
          Server for use in securing the routing exchanges between the
          RPL peers. Some further clarifications can be made to ensure
          that this is better understood. As in other sections, the
          intent will be to use RPL-specific examples throughout while
          maintaining the protocol’s more general application. <=
/o:p>

        
 

        
 

        
3) Key identification

        
With RoLL, the pair (key source identifier, key index) indicat=
es both

        
the originator of the key ("key source id") and an index ("key=
 index")

        
of keys issued by this key originator. This does not necessari=
ly imply,

        
though, that keys are correlated, as is suggested in Section 1=
.4. (It

        
seems that KeySourceId identifies a TGK, while KeyIndex identi=
fies a

        
parameter so as to allow computation of TEK=3Df(TGK,#)). If this=


        
interpretation is correct, this leads to key dependencies that=
 may be

        
undesirable, e.g., in the event of key compromise.<=
/pre>
        
>>[RA] As part of the
          'Authenticated' mode operation, RPL-19, Section 10.1, RPL uses
          a shared group key assigned by a network Key Server (where
          pre-shared keys or public keys may be used to secure the key
          management communications with the key server). The Key Index
          associated with the assigned RPL group key allows RPL nodes to
          ensure synchronization to a common shared key. RPL's group key
          can be changed by the key server at any time and nodes can
          request the current key when out of sync with a routing peer
          (that is, when having a lower Key index key). The Key Source
          ID would refer to the RPL key server entity, again to ensure
          synchronization among RPL routing peers as to the entity from
          which the group key was obtained. Since the security of RPL
          routing exchanges is based on the shared group key it is
          vulnerable to compromise of a single group member and hence
          the need for key updates. With a single TGK/TEK assigned there
          is no difference in the level of vulnerability between the
          single assigned group TGK or the derived group TEK.  

        
 

        
 

        
4) Challenge response protocol

        
I am somewhat concerned about some of the message flows with M=
IKey

        
(e.g., Section 3, 3rd para, Fig. 3), since a key request could=
 arise,

        
e.g., if a key or nonce are "out-of-synch" (which, for keys, m=
ens that

        
one does not have the proper key; for nonces, that one has los=
t this

        
value). With MIKey PSK flows, this would result (in the contex=
t of RPL)

        
that one cannot adequately secure the first message Q_MESSAGE,=
 thereby

        
aborting the protocol. Simply put, what does one do if keys ar=
e lost or

        
if nonces are out of synch? 

        
>>[RA] Keep in mind that the key
          being requested, the RPL group key that the node may have
          determined to be out of synch with its routing peers is
          different from the key being used to secure and authenticate
          the RPL node client (Q) to the key server (I). If the node is
          using a PSK for authenticating exchanges to the key server and
          that key is out of synch, the device needs to be
          re-provisioned/reconfigured (with Error indication of
          inability to access key server, for ex.).

        
 

        
 

        
Moreover, the message flows do not seem to provide for timelin=
ess (in other words: how does entity I know that the request by entity R is =
"fresh")?

        
>>[RA] Timeliness is supported
          only where the time-based Timestamp is used. In the case of
          Q_MESSAGE the Timestamp payload is included in the message set
          according to the time of origination of the message. When the
          message is received at the server (I), it can be accepted
          provided it is within the allowable time window when
          (including allowance for degree to system time
          synchronization). In the returned I_MESSAGE the same Timestamp
          value is included which again must be received at Q within an
          allowable roundtrip time window (again subject to allowances
          for degree of system time synchronization). 

        
 

        
 

        
In out-of-synch scenarios, it seems better to employ a proper<=
o:p>

        
challenge/response protocol (unilateral entity authentication)=
, where

        
the key requestor sends a random challenge to the key assignme=
nt

        
initiator and where the response messsage includes a protected=
 version

        
of the requested key and incorporates this random value. This =
results in

        
implicit key authentication (only the requestor can recover th=
e key

        
[assuming both entities have a shared key]) and provides logic=
al binding

        
between message flows without dependency on nonces.=


        
>>[RA] The Q_MESSAGE is indeed
          protected and so the Requestor's Timestamp value provides the
          equivalent of the random value. The logical binding is
          therefore supported in the defined mechanism. Let us discuss
          to ensure I fully understand the concern.

        
 

        
 

        
NOTE RS: with RoLL, this may cause some trouble, since this su=
ggests

        
mixing of unsecured and secured traffic in the network (which,=
 vaguely,

        
seems to be forbidden using the "security mode"). Since with R=
oLL, the

        
security mode and the security level seems to be unduly tied t=
ogether,

        
this may result in the security mode toggling between unsecure=
d and

        
secured once such a C/R protocol would get implemented.

        
>>[R=
A] Keep in mind that the communications with the key server in RPL is distin=
ct from the communications with routing peers. The key server using PSK or P=
KE methods with each node is able to assign the routing security group key. =
In the RPL 'Authenticated' mode a node has a key that only allows a leaf joi=
n (no routing). That leaf join then allows key management exchanges with the=
 key server to obtain the current routing group key. Until that group key is=
 obtained the node cannot operate as a routing peer.

        
 

        
 

        
5) Timeliness/ logical binding in protocol flows
        
It is not entirely clear how the MIKey protocol provides for l=
ogical

        
binding between protocol flows. As already mentioned, this may=
 be a

        
problem with the protocol flows in Fig. 3 (key request), but a=
lso with

        
subsequent detailed protocol flows (such as with Fig. 5, using=
 the PSK

        
method).

        
>>[RA] See above discussion.

        
 

        
 

        
Additional note:

        
-Section 3.1, 2nd last para: doesn't this impact the resulting=
 properties?

        
>>[RA] This determines when a key
          assignment confirmation is required for a server-initiated key
          push.

        
 

        
 

        
6) Public key usage:

        
The MIKEY protocol seems to use the same public key both for s=
igning and

        
for encryption. It is unclear in abstracto whether this poses =
problems,

        
but common practice is to separate public keys for different

        
cryptographic purposes. If this practice is heeded to, this re=
quires the

        
use of two public keys per device (including management hereof=
).

        
>>[RA] Noted. A recommendation
          that could be made for devices/networks that support
          additional processing resource capabilities.

        
 

        
 

        
Additional note:

        
-Section 3.2, forelast para: wouldn't this impact freshness an=
d

        
aliveness properties?

        
>>[RA] Timeliness checks can be
          supported when the time-based Timestamp payload is used (see
          discussion above).

        
 

        
 

        
-Section 3.2 vs. 3.3: What is the rationale for making public =
key

        
encryption (3.2) mandatory and Diffie-Hellman key exchange (3.=
3)

        
optional? To me, it seems that use of public key techniques ma=
y

        
significantly simplify configuration management (since this no=
w depends

        
on juggling publicly available information, rather than handli=
ng of

        
secret keying material). Of those techniques, DH-based protoco=
ls seem to

        
be best suited for highly constrained networks, where energy c=
ost and

        
implementation footprint come at a premium. Moreover, these ma=
y also be

        
more resistant to side channel attacks (not trivial, esp. for =
devices

        
that can be expected to be low-cost, consumer-style devices th=
at may not

        
be able to rely on tamper-evidencing techniques). This suggest=
s that

        
public-key based techniques, rather than symmetric-key based t=
echniques

        
(with proper eye for detail, of course) should be mandatory to=
 implement.

        
>>[RA] I think it would be more
          consistent with RPL to make PSK mandatory and both PKE and DH
          methods optional. This comment was also made by another
          reviewer. The intent of AMIKEY is to provide a reasonable
          lowest-common denominator with the ability to ratchet up the
          security level based on application environment.

        
 

        
 

        
7) Hash function

        
The suggested "hash function" (Section 4.1.2 - use of CMAC) ma=
y be

        
somewhat unfortunate, since it is invertible if one has access=
 to the

        
key (in contrast to HMAC-SHAx, which is one-way, or block-ciph=
er based

        
hashes, such as AES-MMO, as ZigBee SE1.x used). This may have<=
o:p>

        
implications in the event of key compromise.

        
>>[RA] Agreed. A trade-off made to
          permit lowest common denominator (all AES implementation)
          devices. SHAx of course remains an option that is available
          for devices/networks that can support the additional
          capability.

        
 

        
 

        
8) Key management fit

        
[as already noted by others] Overarching question may be wheth=
er key

        
management functionality best fits with RoLL, CoRE, etc. Of co=
urse, this

        
a perennial question. Nevertheless, some of the functionality =
described

        
seems to suggest layer violation (e.g., Section 6.1.2, Table 6=
.1.e),

        
since RoLL may not know about application layers, etc.

        
>>[RA] As described in the Section
          2, the key management entity logically exists independent of
          the device protocol layers. The KM entity can thus select the
          particular protocol for which key management is being
          performed. As previously discussed, the objective is to be
          able to handle key management for one or more layers with a
          single protocol given the constraints of a LLN-type device. =


        
 

        
 

        
9) Other notes

        
-Section 4: RFC 4493 corresponds to NIST SP 800-38B.

        
>>[RA] Noted.

        
 

        
 

        
-Section 4.1.2: not sure what the AES-CMAC alignment remark is=
 about.

        
BTW - this seems to suggest one can mix usage of CMAC with tha=
t of CCM

        
with the same key (cf. also Section 6.2 (Table 6.2.b) and the =
last para

        
of Section 6.2). In my opinion, this may be highly dangerous. =
As case in

        
point, with the development of 802.15.4-2003, the same mixing =
was

        
suggested (CBC-MAC, CTR, CCM) and shown to lead to an unsecure=
 scheme (I

        
can send you my presentation at the time [Nov 2002]).

        
>>[RA] I think this was just loose
          wording intended to convey replacement. CCM can be mandated. I
          would still be interested in your reference paper. 
        
 

        
 

        
-Section 4.2.4: CCM mode of operation uses a nonce, rather tha=
n IV. With

        
RoLL, this is a 13-byte entry, rather than a 16-byte entry. Mo=
reover,

        
the structure of the nonce matters, since it is aimed at preve=
nting

        
nonce reuse by a single sender/amongst different senders shari=
ng the

        
same key.

        
>>[RA] Understood. The intent was
          to re-use the "IV" information element given in RFC 3830 as a
          Nonce. Since that "IV" included the Timestamp (time-based or
          Counter from the originator) it was guaranteed to be
          non-repeating. This should be cleaned up to avoid potential
          confusion.  

        
 

        
 

        
-Section 6.1, bullet #CS (8 bits): shouldn't this entry enumer=
ate,

        
rather than provide a number.

        
>>[RA] No this should be a number.
          This number will match the number of subsequent occurrences of
          "CS ID map info" elements in the message.

        
 

        
-Section 6.7, 3rd para: the IEEE MAC address is a 64-bit entry=
 (rather

        
than a 48-bit address). Not sure how the reference to RFC 4291=
 comes

        
into play here.

        
>>[RA] The idea is to allow use of
          the 48-bit MAC as an ID as well as the IEEE EUI 64-bit MAC
          where it can be derived from the IP address of packet carrying
          the key exchange message (the IPv6 address being
          auto-configured from the MAC address in conformance with
          RFC4291).

        
 

        
 

        
-Section 6.10.2: Table 6.10.2c suggests the use of AES-CBC-MAC=
-x. Why

        
not use CCM instead (it provides various combinations of encry=
ption and

        
authentication, including authentication-only).
        
>>[RA] Yes CCM can be mandated.<=
/o:p>

        
 

        
 

        
-- 

        
email: rstruik.ext@gmail.com

        
Skype: rstruik

        
cell: +1 (647) 867-5658

        
USA Google voice: +1 (415) 690-7363

        
 

        
 

      


-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363
_______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/m= ailman/listinfo/roll --B_3401878828_24401-- From mcr@sandelman.ca Wed Oct 19 16:06:04 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A1D21F88B7 for ; Wed, 19 Oct 2011 16:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.506 X-Spam-Level: X-Spam-Status: No, score=-1.506 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TI1TyRh+Ejrf for ; Wed, 19 Oct 2011 16:06:04 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 44B0E21F87FC for ; Wed, 19 Oct 2011 16:06:03 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id 2F66B343BC for ; Wed, 19 Oct 2011 19:04:52 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 8D3D498CB3; Wed, 19 Oct 2011 18:09:52 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 8AFFE98CB2 for ; Wed, 19 Oct 2011 18:09:52 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <4E9F2EE0.4050200@gmail.com> References: <4E975CA0.4010104@gmail.com> <4E983D47.1020601@gmail.com> <4E9F2EE0.4050200@gmail.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Wed, 19 Oct 2011 18:09:52 -0400 Message-ID: <8975.1319062192@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] notes re AMiKey draft(draft-alexander-roll-amikey-lln-key-mgmt-02) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 23:06:04 -0000 >>>>> "Rene" == Rene Struik writes: Rene> All - it would be invaluable to have some insight as to Rene> whether implementations based on rpl-19 actually use its Rene> security provisions and gain some insight into Rene> problems/bottlenecks/interop issues, and the-like. So far, not It's too soon to hear much, I think. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From Jorjeta.Jetcheva@itron.com Wed Oct 19 17:11:00 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7013121F8876 for ; Wed, 19 Oct 2011 17:11:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4z0Mu9qvDxn for ; Wed, 19 Oct 2011 17:10:59 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.116]) by ietfa.amsl.com (Postfix) with ESMTP id C502821F8801 for ; Wed, 19 Oct 2011 17:10:58 -0700 (PDT) Received: from ITR-EXMBXVS-2.itron.com ([192.168.9.111]) by spo-exchcn-2.itron.com ([192.168.9.116]) with mapi; Wed, 19 Oct 2011 17:10:54 -0700 From: "Jetcheva, Jorjeta" To: Jari Arkko Date: Wed, 19 Oct 2011 17:10:51 -0700 Thread-Topic: [Roll] review of draft-ietf-roll-applicability-ami Thread-Index: AcxN9ghx5Rk6bGyoSeuEF0OnJqTgQxAxiWRg Message-ID: <0368F388C03BB34BBBFA73209849D47A4DE776F0@ITR-EXMBXVS-2.itron.com> References: <4E32B9D2.3000509@piuha.net> In-Reply-To: <4E32B9D2.3000509@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] review of draft-ietf-roll-applicability-ami X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 00:11:00 -0000 Hello Jari, Thank you for the comments on the first version of the RPL AMI Applicabilit= y draft. We have since published two more iterations and wanted to check i= n with you to make sure that we have addressed your concerns. We look forw= ard to your feedback. Thanks, Jorjeta=20 Jorjeta Jetcheva, Ph.D. Strategic Industry Standards and Architecture Office of the CTO Mobile: +1.408.688.1428 Knowledge to Shape Your Future =A0=A0=A0=A0=A0=A0=A0=A0=A0 -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jar= i Arkko Sent: Friday, July 29, 2011 6:47 AM To: roll@ietf.org Subject: [Roll] review of draft-ietf-roll-applicability-ami I have reviewed this document, and had some comments: First off, I was one of the IESG members who have been asking for the=20 ROLL working group to produce applicability statement(s) about RPL.=20 Thank you for working on this! However, I think we are still not quite=20 there. What at least I was asking for was more about experience,=20 measurements, and analysis about how well RPL works in various types of=20 networks. The current document is more descriptive (talks about the RPL=20 design goals, for instance) and contains some profiling. While those=20 parts are very useful as well, I feel that the core part of the=20 contribution that this applicability statement should be making is=20 missing. Perhaps the working should make an open call for the=20 experience/measurements/analysis that is needed. Some may already exist,=20 I'm sure. Some additional more detailed comments: The gas and water metering part discusses cases where the meters can or=20 can not rely on the networks that electricity measurement devices have=20 created. I think this description is not quite right. My experience is=20 that gas and water meters tend to exist in places with power easily=20 available. In Finland, for instance, water/heat pipe meters have been a=20 standard for new homes dating back at least 2004, and they all run from=20 mains power. So I think power will be available, and the ability to use=20 another measuring network is kind of a secondary issue (and reuse of=20 other networks may be more about administrative borders than about=20 technology anyway). Both the electricity and gas/water sections appear to take it almost for=20 granted that multi-hop routing is necessary in these applications.=20 That's certainly one way of building the networks, and the reason for=20 the existence of this working group. But I would have expected that an=20 applicability statement talked about the situations where this works=20 best versus situations where some other solutions might work better. I=20 see a lot of one-hop commercial deployment in this space, for instance,=20 the metering systems in Finland are cellular-based. Is there something=20 that you could say about when the different approaches are best=20 applicable? Or is that purely a business issue, i.e., both work well and=20 the only question is equipment/provider cost? > As a result, all smart metering traffic > typically goes through the LBRs, with the vast majority of traffic > flowing from smart meter devices to the head-end servers, i.e., in a > Multipoint-to-Point (MP2P) fashion. > =20 I'm not so sure about this. Pure metering implementations may have=20 initiation on either side of the connection, and a request is likely to=20 be a small packet but so are responses. As you note yourself later,=20 there are firmware updates and other extraneous traffic cases that may=20 balance the small response - slightly bigger response equation. In any=20 case, its pretty useless of for me or you to guess -- but I'm guessing=20 some actual operators have real data about the traffic mix and=20 directionality. Can that be cited? Jari _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Tue Oct 25 04:46:54 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E3021F8B17 for ; Tue, 25 Oct 2011 04:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a33N-0FzrdYi for ; Tue, 25 Oct 2011 04:46:54 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6981321F8B16 for ; Tue, 25 Oct 2011 04:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=235; q=dns/txt; s=iport; t=1319543214; x=1320752814; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=dRukVzxbKVJuWNFfzrnVBqF+gISEHwiImZuwOjf9a64=; b=TJKMonpVDVA7xKozp8fseY70X5ON3KMj1cOhFbMw/+D/Swo7lEzfFfcx jqKkTmeTqfa+nZgKRUXPjXzDw3TtxN2guxUca7g+33ujDFlAJzL+NuFsI 76H2C54KjWFyegR4tKhztWIViE/P49Ujr2XgDAYbe36a8ILK28YVNJAJ9 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4FAB2hpk6rRDoI/2dsb2JhbABDng8CAYsDgQWCBwEnP4E+HBmHZpVqAZ5vh2JhBJQJhSwJjCo X-IronPort-AV: E=Sophos;i="4.69,404,1315180800"; d="scan'208";a="9343826" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 25 Oct 2011 11:46:54 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9PBksjG000821; Tue, 25 Oct 2011 11:46:54 GMT Received: from xfe-sjc-221.amer.cisco.com ([128.107.191.32]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 04:46:53 -0700 Received: from [10.60.114.232] ([10.60.114.232]) by xfe-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 04:46:53 -0700 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Oct 2011 13:46:51 +0200 Message-Id: To: roll WG Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 25 Oct 2011 11:46:53.0531 (UTC) FILETIME=[CA53BAB0:01CC930B] Cc: David Culler Subject: [Roll] Provisional Agenda ROLL WG Meeting IETF-82 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 11:46:55 -0000 Dear all, Here is the provisional agenda for the ROLL WG meeting IETF-82: = http://www.ietf.org/proceedings/82/agenda/roll.txt If you have comments, request, please send an email to David, Dan and = myself. Thanks. JP.= From internet-drafts@ietf.org Tue Oct 25 08:53:10 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21A721F8BBA; Tue, 25 Oct 2011 08:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yppb0fa3hYca; Tue, 25 Oct 2011 08:53:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19AB621F8B17; Tue, 25 Oct 2011 08:53:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111025155305.26511.91815.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2011 08:53:05 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-applicability-ami-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 15:53:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : Applicability Statement for the Routing Protocol for Low= Power and Lossy Networks (RPL) in AMI Networks Author(s) : Daniel Popa Jorjeta Jetcheva Nicolas Dejean Ruben Salazar Jonathan W. Hui Filename : draft-ietf-roll-applicability-ami-04.txt Pages : 17 Date : 2011-10-25 This document discusses the applicability of RPL in Advanced Metering Infrastructure (AMI) networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-applicability-ami-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-applicability-ami-04.txt From Jorjeta.Jetcheva@itron.com Tue Oct 25 08:55:30 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A6E21F8C5E for ; Tue, 25 Oct 2011 08:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[AWL=-1.708, BAYES_40=-0.185, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zA1NV7mnoHCN for ; Tue, 25 Oct 2011 08:55:29 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.116]) by ietfa.amsl.com (Postfix) with ESMTP id 35D7D21F8C5A for ; Tue, 25 Oct 2011 08:55:29 -0700 (PDT) Received: from ITR-EXMBXVS-2.itron.com ([192.168.9.111]) by spo-exchcn-2.itron.com ([192.168.9.116]) with mapi; Tue, 25 Oct 2011 08:55:24 -0700 From: "Jetcheva, Jorjeta" To: "roll@ietf.org" Date: Tue, 25 Oct 2011 08:55:22 -0700 Thread-Topic: changes in draft-ietf-roll-applicability-ami-04.txt Thread-Index: Acx9Ss7hRJCwW4vkTj27zHG64Ecm7wVYLpFg Message-ID: <0368F388C03BB34BBBFA73209849D47A4E05292A@ITR-EXMBXVS-2.itron.com> References: <0368F388C03BB34BBBFA73209849D47A4D628684@ITR-EXMBXVS-2.itron.com> In-Reply-To: <0368F388C03BB34BBBFA73209849D47A4D628684@ITR-EXMBXVS-2.itron.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_008_0368F388C03BB34BBBFA73209849D47A4E05292AITREXMBXVS2itro_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [Roll] changes in draft-ietf-roll-applicability-ami-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 15:55:30 -0000 --_008_0368F388C03BB34BBBFA73209849D47A4E05292AITREXMBXVS2itro_ Content-Type: multipart/alternative; boundary="_000_0368F388C03BB34BBBFA73209849D47A4E05292AITREXMBXVS2itro_" --_000_0368F388C03BB34BBBFA73209849D47A4E05292AITREXMBXVS2itro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello everyone, Just wanted to draw your attention to the new iteration of the RPL AMI Appl= icability Internet-Draft (version 04). Below is a brief summary of the changes: * Expanded discussion of RPL storing vs. non-storing mode * Included additional reference to draft-ietf-roll-routing-metrics-= 19 in Section 4.1.4 Thank you for your comments, we look forward to additional feedback! Thanks, Jorjeta [cid:image001.jpg@01CC9271.56990390] Jorjeta Jetcheva, Ph.D. Strategic Industry Standards and Architecture Office of the CTO Mobile: +1.408.688.1428 Knowledge to Shape Your Future [cid:image002.jpg@01CC9271.56990390] [cid:im= age003.jpg@01CC9271.56990390] [cid:im= age004.jpg@01CC9271.56990390] [cid:image005.jpg@01CC9271.56990390] --_000_0368F388C03BB34BBBFA73209849D47A4E05292AITREXMBXVS2itro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello everyone,

 

Just wanted to draw your attention to the new= iteration of the RPL AMI Applicability Internet-Draft (version 04). 

 =

Below is a brief summary of the changes:=

 

·         Expanded discussion of RPL storing vs. non-storing mode

·         Inc= luded additional reference to draft-ietf-roll-routing-metrics-19 in Section= 4.1.4

 

Thank you for your comments, we look forward to additional feedback! = ;

&n= bsp;

Thanks, Jorjeta

 

 

<= tr>=

3D"http://marketing.=

Jorjeta Jetcheva, Ph.D.<= /p>

Strategic Industry Standards and Architecture

Office of the CTO
Mobile: +1.408.688= .1428
Knowledge to Shape Your Future

3D"http://marketing.itron.com/campaign/social_media_icon=   3D"htt=<= /a>&= nbsp;  3D"http://marke= &nbs= p; 3D"http://marketing.itron.com/c=

 

 

= --_000_0368F388C03BB34BBBFA73209849D47A4E05292AITREXMBXVS2itro_-- --_008_0368F388C03BB34BBBFA73209849D47A4E05292AITREXMBXVS2itro_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=20786; creation-date="Tue, 25 Oct 2011 08:55:19 GMT"; modification-date="Tue, 25 Oct 2011 08:55:19 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4RLERXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAA agEoAAMAAAABAAIAAAExAAIAAAAeAAAAcgEyAAIAAAAUAAAAkIdpAAQAAAABAAAApAAAANAACvyA AAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2gAMjAxMTowOTowOSAwOToz ODo1OQAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAASKADAAQAAAABAAAAUQAAAAAAAAAGAQMAAwAA AAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEAAgAAAgEABAAAAAEAAAEuAgIA BAAAAAEAABGOAAAAAAAAAEgAAAABAAAASAAAAAH/2P/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5v AhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAA AAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAA FHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALE AAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gA AAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJp Z2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElF QzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAA AAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZ WiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAA AAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVu Y2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNl IFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABX H+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAA AAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8 AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0B EwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZ AeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC 6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7 BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF 5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfS B+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEK Jwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzA DNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MP zw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMj E0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW +hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsU GzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qf vx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSr JNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIq NSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+ MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2 cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0i PWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdE ikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwq THJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJU j1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0n XXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1m kmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XAr cIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6 pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VH hauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q 1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJ nPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSp N6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYB tnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD 1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+ 0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4Dbg veFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M 8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23/ ///tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8V GBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4O DhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgA UQBIAwEiAAIRAQMRAf/dAAQABf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUB AQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJx gTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePz RieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYF NQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNU oxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//a AAwDAQACEQMRAD8AzkkklkPdKSSSSUpJJJJSkkkklKSSSSU//9DOSSSWQ90pJJJJSkkkklKSSSSU pJJJJT//0c5JJJZD3SkkkklKSSSSUpJJJJSkkkklP//Szkkl2H1A6dVa3LzLq2vbLambgDr/ADln 0v8ArSyscDOQiNLez5rmI8vhllkOLhr07cXEeF49Jd/0roWH1DMzep5dNdmNkWFmJXEQ2pzqS/aN rff6bVjZX1RzMzq+dVhGimqhzYaS4NAeN9bNK3e/0/dZ/XUh5eYAI14jQ/iwQ+J4JTlCX6v24iU5 S+WMjwxlD/AnPgeZVnpmKMvOqodqxxl/9UDc5aOb9Uuq4Yqa7ZbdfYa6qaiS47QXOt9zWNbWtbpX 1T6pgWm2wVvusrdsaHHa0jaf0tm36Tvofo/UUOTFm4JcECZVp5y2X5uewDGTHLG5A8Gv4uZ1fD6R gU7WVk5Dx7G7naD992qwluY31d611jLyy8squx3hlwuLgNxn2V+m232t2ol/1J6tj4d2U91R9AOc a2lxc5rPpOZ7P3Ruahh5fLGHq4pncyKMfM4MVY8mcSyGruXFrP5eH+q8+kkki3H/085eh9I/yR9T vtJ9thqffPi6z+Y/6PorzxJZeLJ7ZJqyRQ8Hsec5X7zGEDLhjGYnIVxcfD+g+h9Msf0r6mjJe4mz 0XWtJMwbP6O0f51SX1cc7A+rNnUcgl9tgsyXl5JJgbKwXH3e5lTF54kpBzFEen5Y8I16/vNWXwoS GQHJrly+9M8H6H+a+d7P6ndYszepXnqOQbMgs/Vg8wBuM3Mpb9Fu7bV7GraZjjpWbmdV6l1Amm6R VU4kNY2dzWtZLt9jPoM9P/0YvMk7nOcZcST4nVKHMERAMeIg2JX/ANJOb4WMmSUo5Pbx5IiE8cYR +WP+bl/k30vAzGV9Hy+sluz7QbckNPO1o9KgH+vXTWhdcyL8H6puGQ8vybKWUvc7kvsAbd/0fUXn CSJ5o8NcP6PDv1O8lg+ERGQT9ywMgycPB+hD+bxcXH+ipJJJV3Vf/9TOSXnaSyHun0RJedpJKfRE l52kkp9ESXnaSSn0RJedpJKf/9n/7RmsUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQQ6AAAAAACNAAAAEAAAAAEAAAAAAAtwcmludE91dHB1dAAAAAQAAAAAUHN0 U2Jvb2wBAAAAAEludGVlbnVtAAAAAEludGUAAAAAQ2xybQAAAA9wcmludFNpeHRlZW5CaXRib29s AAAAAAtwcmludGVyTmFtZVRFWFQAAAAMAEkATQBBAEcARQBSAFUATgBOAEUAUgAAADhCSU0EOwAA AAABsgAAABAAAAABAAAAAAAScHJpbnRPdXRwdXRPcHRpb25zAAAAEgAAAABDcHRuYm9vbAAAAAAA Q2xicmJvb2wAAAAAAFJnc01ib29sAAAAAABDcm5DYm9vbAAAAAAAQ250Q2Jvb2wAAAAAAExibHNi b29sAAAAAABOZ3R2Ym9vbAAAAAAARW1sRGJvb2wAAAAAAEludHJib29sAAAAAABCY2tnT2JqYwAA AAEAAAAAAABSR0JDAAAAAwAAAABSZCAgZG91YkBv4AAAAAAAAAAAAEdybiBkb3ViQG/gAAAAAAAA AAAAQmwgIGRvdWJAb+AAAAAAAAAAAABCcmRUVW50RiNSbHQAAAAAAAAAAAAAAABCbGQgVW50RiNS bHQAAAAAAAAAAAAAAABSc2x0VW50RiNQeGxAUgAAAAAAAAAAAAp2ZWN0b3JEYXRhYm9vbAEAAAAA UGdQc2VudW0AAAAAUGdQcwAAAABQZ1BDAAAAAExlZnRVbnRGI1JsdAAAAAAAAAAAAAAAAFRvcCBV bnRGI1JsdAAAAAAAAAAAAAAAAFNjbCBVbnRGI1ByY0BZAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAAB AAEASAAAAAEAAThCSU0EJgAAAAAADgAAAAAAAAAAAAA/gAAAOEJJTQQNAAAAAAAEAAAAeDhCSU0E GQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEAOEJJTScQAAAAAAAKAAEAAAAAAAAAAThC SU0D9QAAAAAASAAvZmYAAQBsZmYABgAAAAAAAQAvZmYAAQChmZoABgAAAAAAAQAyAAAAAQBaAAAA BgAAAAAAAQA1AAAAAQAtAAAABgAAAAAAAThCSU0D+AAAAAAAcAAA//////////////////////// /////wPoAAAAAP////////////////////////////8D6AAAAAD///////////////////////// ////A+gAAAAA/////////////////////////////wPoAAA4QklNBAgAAAAAABAAAAABAAACQAAA AkAAAAAAOEJJTQQeAAAAAAAEAAAAADhCSU0EGgAAAAADSQAAAAYAAAAAAAAAAAAAAFEAAABIAAAA CgBVAG4AdABpAHQAbABlAGQALQAxAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAABI AAAAUQAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAABAAAAABAAAAAAAAbnVsbAAA AAIAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAUQAAAABSZ2h0bG9uZwAAAEgAAAAGc2xpY2VzVmxMcwAA AAFPYmpjAAAAAQAAAAAABXNsaWNlAAAAEgAAAAdzbGljZUlEbG9uZwAAAAAAAAAHZ3JvdXBJRGxv bmcAAAAAAAAABm9yaWdpbmVudW0AAAAMRVNsaWNlT3JpZ2luAAAADWF1dG9HZW5lcmF0ZWQAAAAA VHlwZWVudW0AAAAKRVNsaWNlVHlwZQAAAABJbWcgAAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0 MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAAFEAAAAA UmdodGxvbmcAAABIAAAAA3VybFRFWFQAAAABAAAAAAAAbnVsbFRFWFQAAAABAAAAAAAATXNnZVRF WFQAAAABAAAAAAAGYWx0VGFnVEVYVAAAAAEAAAAAAA5jZWxsVGV4dElzSFRNTGJvb2wBAAAACGNl bGxUZXh0VEVYVAAAAAEAAAAAAAlob3J6QWxpZ25lbnVtAAAAD0VTbGljZUhvcnpBbGlnbgAAAAdk ZWZhdWx0AAAACXZlcnRBbGlnbmVudW0AAAAPRVNsaWNlVmVydEFsaWduAAAAB2RlZmF1bHQAAAAL YmdDb2xvclR5cGVlbnVtAAAAEUVTbGljZUJHQ29sb3JUeXBlAAAAAE5vbmUAAAAJdG9wT3V0c2V0 bG9uZwAAAAAAAAAKbGVmdE91dHNldGxvbmcAAAAAAAAADGJvdHRvbU91dHNldGxvbmcAAAAAAAAA C3JpZ2h0T3V0c2V0bG9uZwAAAAAAOEJJTQQoAAAAAAAMAAAAAj/wAAAAAAAAOEJJTQQUAAAAAAAE AAAABDhCSU0EDAAAAAARqgAAAAEAAABIAAAAUQAAANgAAERYAAARjgAYAAH/2P/iDFhJQ0NfUFJP RklMRQABAQAADEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElF QyBzUkdCAAAAAAAAAAAAAAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHw AAAAFGJrcHQAAAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQA AAJUAAAAcGRtZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1l YXMAAAQMAAAAJHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAI DHRleHQAAAAAQ29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNj AAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA 81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAA AAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93 d3cuaWVjLmNoAAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNj AAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAA AAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFla IAAAAAAATAlWAFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcg AAAAAENSVCBjdXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQA WQBeAGMAaABtAHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADl AOsA8AD2APsBAQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoB oQGpAbEBuQHBAckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKY AqICrAK2AsECywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD 4APsA/kEBgQTBCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVn BXcFhgWWBaYFtQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0H TwdhB3QHhgeZB6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5 CY8JpAm6Cc8J5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kM EgwqDEMMXAx1DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7u DwkPJQ9BD14Peg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYS RRJkEoQSoxLDEuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXg FgMWJhZJFmwWjxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0a BBoqGlEadxqeGsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5q HpQevh7pHxMfPh9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgj ZiOUI8Ij8CQfJE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSii KNQpBik4KWspnSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwu gi63Lu4vJC9aL5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSe NNg1EzVNNYc1wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07 azuqO+g8JzxlPKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJy QrVC90M6Q31DwEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBK N0p9SsRLDEtTS5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIx UnxSx1MTU19TqlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa 9VtFW5Vb5Vw1XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2Pr ZEBklGTpZT1lkmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBt uW4SbmtuxG8eb3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3Vnez eBF4bnjMeSp5iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCC koL0g1eDuoQdhICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Y jf+OZo7OjzaPnpAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZ kJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWp phqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuy wrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1 wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXO Ns62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK 3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr ++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3 /Af8mP0p/br+S/7c/23////tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkI DAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwM/8AAEQgAUQBIAwEiAAIRAQMRAf/dAAQABf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMA AQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMB AAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKj dDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cR AAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M0 8SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW 5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8AzkkklkPdKSSSSUpJJJJSkkkklKSSSSU//9DOSSSW Q90pJJJJSkkkklKSSSSUpJJJJT//0c5JJJZD3SkkkklKSSSSUpJJJJSkkkklP//Szkkl2H1A6dVa 3LzLq2vbLambgDr/ADln0v8ArSyscDOQiNLez5rmI8vhllkOLhr07cXEeF49Jd/0roWH1DMzep5d NdmNkWFmJXEQ2pzqS/aNrff6bVjZX1RzMzq+dVhGimqhzYaS4NAeN9bNK3e/0/dZ/XUh5eYAI14j Q/iwQ+J4JTlCX6v24iU5S+WMjwxlD/AnPgeZVnpmKMvOqodqxxl/9UDc5aOb9Uuq4Yqa7ZbdfYa6 qaiS47QXOt9zWNbWtbpX1T6pgWm2wVvusrdsaHHa0jaf0tm36Tvofo/UUOTFm4JcECZVp5y2X5ue wDGTHLG5A8Gv4uZ1fD6RgU7WVk5Dx7G7naD992qwluY31d611jLyy8squx3hlwuLgNxn2V+m232t 2ol/1J6tj4d2U91R9AOca2lxc5rPpOZ7P3Ruahh5fLGHq4pncyKMfM4MVY8mcSyGruXFrP5eH+q8 +kkki3H/085eh9I/yR9TvtJ9thqffPi6z+Y/6PorzxJZeLJ7ZJqyRQ8Hsec5X7zGEDLhjGYnIVxc fD+g+h9Msf0r6mjJe4mz0XWtJMwbP6O0f51SX1cc7A+rNnUcgl9tgsyXl5JJgbKwXH3e5lTF54kp BzFEen5Y8I16/vNWXwoSGQHJrly+9M8H6H+a+d7P6ndYszepXnqOQbMgs/Vg8wBuM3Mpb9Fu7bV7 GraZjjpWbmdV6l1Amm6RVU4kNY2dzWtZLt9jPoM9P/0YvMk7nOcZcST4nVKHMERAMeIg2JX/ANJO b4WMmSUo5Pbx5IiE8cYR+WP+bl/k30vAzGV9Hy+sluz7QbckNPO1o9KgH+vXTWhdcyL8H6puGQ8v ybKWUvc7kvsAbd/0fUXnCSJ5o8NcP6PDv1O8lg+ERGQT9ywMgycPB+hD+bxcXH+ipJJJV3Vf/9TO SXnaSyHun0RJedpJKfREl52kkp9ESXnaSSn0RJedpJKf/9k4QklNBCEAAAAAAFUAAAABAQAAAA8A QQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAgAFAAaABvAHQAbwBz AGgAbwBwACAAQwBTADUAAAABADhCSU0EBgAAAAAABwAIAQEAAQEA/+ENmmh0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6 TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0i QWRvYmUgWE1QIENvcmUgNS4wLWMwNjAgNjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAg ICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjIt cmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOnBob3Rvc2hvcD0iaHR0cDovL25z LmFkb2JlLmNvbS9waG90b3Nob3AvMS4wLyIgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9l bGVtZW50cy8xLjEvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21t LyIgeG1sbnM6c3RFdnQ9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJj ZUV2ZW50IyIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIg eG1wOkNyZWF0ZURhdGU9IjIwMTEtMDktMDlUMDk6Mzg6NTktMDc6MDAiIHhtcDpNZXRhZGF0YURh dGU9IjIwMTEtMDktMDlUMDk6Mzg6NTktMDc6MDAiIHhtcDpNb2RpZnlEYXRlPSIyMDExLTA5LTA5 VDA5OjM4OjU5LTA3OjAwIiBwaG90b3Nob3A6Q29sb3JNb2RlPSIzIiBwaG90b3Nob3A6SUNDUHJv ZmlsZT0ic1JHQiBJRUM2MTk2Ni0yLjEiIGRjOmZvcm1hdD0iaW1hZ2UvanBlZyIgeG1wTU06SW5z dGFuY2VJRD0ieG1wLmlpZDozOEVDOTBGRDFBMjI2ODExOEQ0REE0Qzk2QkZDRjc0MyIgeG1wTU06 RG9jdW1lbnRJRD0ieG1wLmRpZDozOEVDOTBGRDFBMjI2ODExOEQ0REE0Qzk2QkZDRjc0MyIgeG1w TU06T3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOjM4RUM5MEZEMUEyMjY4MTE4RDREQTRDOTZC RkNGNzQzIj4gPHBob3Rvc2hvcDpEb2N1bWVudEFuY2VzdG9ycz4gPHJkZjpCYWc+IDxyZGY6bGk+ eG1wLmRpZDo1QkM3ODJFQzExMjA2ODExODA4M0M2NDI4QkQ3NkVDNzwvcmRmOmxpPiA8L3JkZjpC YWc+IDwvcGhvdG9zaG9wOkRvY3VtZW50QW5jZXN0b3JzPiA8eG1wTU06SGlzdG9yeT4gPHJkZjpT ZXE+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJjcmVhdGVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAu aWlkOjM4RUM5MEZEMUEyMjY4MTE4RDREQTRDOTZCRkNGNzQzIiBzdEV2dDp3aGVuPSIyMDExLTA5 LTA5VDA5OjM4OjU5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3Ag Q1M1IE1hY2ludG9zaCIvPiA8L3JkZjpTZXE+IDwveG1wTU06SGlzdG9yeT4gPC9yZGY6RGVzY3Jp cHRpb24+IDwvcmRmOlJERj4gPC94OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJP RklMRQABAQAADEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElF QyBzUkdCAAAAAAAAAAAAAAABAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHw AAAAFGJrcHQAAAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQA AAJUAAAAcGRtZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1l YXMAAAQMAAAAJHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAI DHRleHQAAAAAQ29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNj AAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA 81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAA AAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93 d3cuaWVjLmNoAAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNj AAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAA AAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFla IAAAAAAATAlWAFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcg AAAAAENSVCBjdXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQA WQBeAGMAaABtAHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADl AOsA8AD2APsBAQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoB oQGpAbEBuQHBAckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKY AqICrAK2AsECywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD 4APsA/kEBgQTBCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVn BXcFhgWWBaYFtQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0H TwdhB3QHhgeZB6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5 CY8JpAm6Cc8J5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kM EgwqDEMMXAx1DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7u DwkPJQ9BD14Peg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYS RRJkEoQSoxLDEuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXg FgMWJhZJFmwWjxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0a BBoqGlEadxqeGsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5q HpQevh7pHxMfPh9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgj ZiOUI8Ij8CQfJE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSii KNQpBik4KWspnSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwu gi63Lu4vJC9aL5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSe NNg1EzVNNYc1wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07 azuqO+g8JzxlPKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJy QrVC90M6Q31DwEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBK N0p9SsRLDEtTS5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIx UnxSx1MTU19TqlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa 9VtFW5Vb5Vw1XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2Pr ZEBklGTpZT1lkmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBt uW4SbmtuxG8eb3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3Vnez eBF4bnjMeSp5iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCC koL0g1eDuoQdhICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Y jf+OZo7OjzaPnpAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZ kJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWp phqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuy wrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1 wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXO Ns62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK 3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr ++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3 /Af8mP0p/br+S/7c/23////uACFBZG9iZQBkQAAAAAEDABADAgMGAAAAAAAAAAAAAAAA/9sAhAAB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgICAgICAgICAgIDAwMD AwMDAwMDAQEBAQEBAQEBAQECAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwP/wgARCABRAEgDAREAAhEBAxEB/8QArgABAAICAwEAAAAAAAAAAAAAAAgJ BAoBAgcGAQEAAQMFAQAAAAAAAAAAAAAACAIGBwEEBQkKAxAAAgICAgIDAQEAAAAAAAAABgcFCAME EAkBAiAwUBESEQABBQEAAgIBAwUBAAAAAAADAQIEBQYHEggRFAAQIRUgMFATFiMSAAICAgEDAwIE AwkAAAAAAAECAwQRBRIhEwYAMQdBFBAgIjIwUFHwYXGBkUIzFQj/2gAMAwEBAhEDEQAAAIYdaHr8 AAAAAAAAAAAAAAAAAAAAAAAAAAAAA90sTHk7MDR5qflpMkDZJkj1Iy0uzCFaGNJeRqtvLthFgRjg rz8jfq7y4Gn3D88RuRzH6Csqv4dNKodWdnuzXJsPuNNfPOPurSphX6FQABmV7fDo3AAAAAA//9oA CAECAAEFAP22YUZg4GT5k3WJL8oMe1tvGLg0QSTEmpJibLplTFML4bdUmYwYleIuUw6O+lC2OiOB L+BSfGs+YQTq6yZR1Zp4v2J0jw6HgQmoKYxawgbSG7Aqj5e+TJl8/Z//2gAIAQMAAQUA/bapbmCA BJnDoZk1z2cNOYhNpzWQO1IBh95gNdIxf3fSzC93DeFMs2GMLXIKvQUNdhyPKjrh4/6sJfNuxug9 r8Wt09NrXAvoiYpbKWQJvd7r1kge7LveuouPMy7fy19XV1PT7P/aAAgBAQABBQD9utSx1HA77epy pNehHnoLr2NFkfVujKhsi4Gb1HOB3W3c3UzahK46q9UNoK8Fi467bm3cbB10n20Xaj4qV49KWdPV ap2YqF05ddcnJ126zOni3pC9bIQwHiqA6kS34obqDdxgGqF6oPluyMhJ5fs//9oACAECAgY/AP53 5Bv6rqL0UQWIkA4llZY0PE9G4s/MggghTkYz6Ni7uUj8XqsO/IK0AMje4gjPD9zDq7DPbQ5OGZAf x3+6vVI5YwyQJzUMAQO5J+4EZwYvXk/le41tabVWrDJUjwRxjgd4S5UBVHPtqVwTkZJxn15TU0bU K9OrLHhS0oRVlUvGgxCx5iMK0g9gXGGbOfWvilEE9+1ZaKKGFmZ2Cgs0uWRFWMAAksQVDAuF648c 8e1+z11eq9vv2i0kuUiiQgKCsLI8jNJ+hOQUsoYuFVmW54roKtejX1LLC6zswLSNyLNyjjkEjsV5 u/QNzVlJBGNntrE9QissjGNWcu6R5LMmYwOqgsqkhiMdAx4/idqcLaapJZz/AFkmz2P9QYV/tj0u 0nnY2hSeZSxJw02ft1GfYYaIYHTJJHv6ueTbGR5Lkyz23MjFmbivCMFieR5JEnHr/u6e/rat5NuD LtGixWEjAAB3zMkK9FUtxiPBRkqvQYU+vJPL/J/MGahYyIonJWOOPkGVVTk3ORBhE7agkFiQWkIH kPnDwdv7t7FwK3vwRe1AD/e8cMZwOnJzj39TrsbDSbaanHA7P+5pJgFmz/gpkIH0Ax+cNI5ZsYyS T0/z/i//2gAIAQMCBj8A/nfknkdR1XYQwhYSQDiaV1ijbichuDOHKkEEKcjGfRs395HF4lUcd+QV a4MjdCK8Z7f7mHV2Ge2hycMyBvx+MPj7x3d2qdox2NjZ7ErxMUJFarkxspIylvIPTIGOoPr4e+Ev AvLdvQ820urjs7uyXVjLZ2VevsErLK7yySfbm1KsvNU4twROQU4+GN78kReTbTf7mnZDyrDTkmll pTLDanbnehH2z2mlhqOP1utd+5FEVAPlFym2w13jGl1MV27fvRxQwQtM8ccdQCOaaWS0zOyhI0dZ HidIWlyhZdJrJ9tU8dp7Wr35ZIIxNaSTvJyp1lnLvHCgaeVrJrYIjQKZXjR/i8UK+y2PjO9oPYon XRQSMYY+1ymsizYpskkzykEFTJ3Y5kkSNk4+vEPCNZrd2r7iWrClmWGukMFi3wWOGfFp3HCR1imk RXjR+RDPGpk/FPC0LTaaPeVNQVHUpVoFf+yx/XhIt6X6D6E4Bb1L4brddCumPkNbXzLGiqWi14Ub SR+IAeTMNxuTDJUIrE8c+tF8QeKVIKmioza7RwR1Y0jhh70vftukSARoYp7k/cIUf8P6sgD14XD8 PeBJS8NivFts9WNmd2ggKa+e9IOUkixCW6O/MxVJJsMwaRc/EfwT8OfA0cXkuq4PcuwIktm3aMTR STSWBFH9vWnYtYnNmVkVliQOkdZS/wAWf+coNj92dHDq9E8kWe3355Tc2Tp9eEFq9ZQuwDduBeQA UAa6XxTVw1fBqG+t7KvHCMRxVNe8ktDj75DSpUVjn9Rct9fzmKpWjijJJIRQoJPucAAZP1Pv/F// 2gAIAQEBBj8A/wA3gcFZiMaktLUszQMAUoHPoaSDKurSOskLmFi/eiwFjtIxzXteZPFUd8fja+mx 02w6fpopm5ipLs9SYdTFXzAXU24f5NzfpQyorY4X+P25DVanyMZlZ+vfu0bbJ0GmrxTMzzDKt0FL AuYwJgAk1eyUQbKLJAI6AmUfi5iefi5yL+yp8+zntd2Lm3NdjynqfQbPLevuSFAlRBVOU5RptLzO w1MynhQaesrf+oFkIRYX1ynUoVKUvg4jfL2lyXDZPBOe43l+nyRYFPLvt5XUNTS7+jkX+PzkRa/n l4ddVByMWHPugqix45rQX+mRJa9XNwFZZjxW333Uui3GAwXOOdWtxeaO9jUNfZWVnt3ntKGhqKrH x4kIJXnlyAljAljJKHHRCIw+w0MDnmk3On5tsRZekrNHZvoMhYV3/Pz/AKu81cjPx4Vda304wq6G OqZbf7GvOVXtjiMUfsEa8n4fE7/kuxr8x0IHU7rSVkMN9Ypbuj5/IFyWX3USZVUNfUscxWFbG+lK ikAQ7C+adL6xf3vKDj5nA2F9NylRfaabf6DMYps2RZXufU+RhQTJY1tcWZAiyCR5UiP4I5gzvaD9 S9TKgq3UTeSbftwpD3IMc/XdIHIdyrzXy+R/crZediKqK5yqnkifKoz8jdRvLuyNqB8V1PTqGVZ2 MyWKJc9LLLfyGsrvsFeSurUDeUQkEJUY0ryEYiefx+a/2Z6LY2uj1+trOpew+jsddZz7W8vv4Ood m8VXzbixOaymCuc/ha5YrXFd8JOTwVFcv51OV7N9hkarp9hkxg4pC2NpFiQYEfR6AU3pee55Vv8A q1VXLtn01A9a+ANhTRoHy1jmAIrfZP2+9n/cKdPwfQ/5CFhcDpJ8yoymKyLLqNdVdLV5kttaLpdX nY7BVVayohjOURZJXDKee9ovYT3hl0i5tOs2nYPY2FU2yMbYuz+cpWYblNdPXycJZt/j+d1B0CJ7 g/asX+Cqr3OdeR+i6Cyv+t7Dj2K5RqLS/J52d1tenQa6m6Mh1Vo1YSNUT7kgho3/AM2R2s+ERPlP 6mnsp0ywOwTAMNNkmllaEfyowtId5HtExXL8NRfhPn9v7v8A/9k= --_008_0368F388C03BB34BBBFA73209849D47A4E05292AITREXMBXVS2itro_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=1675; creation-date="Tue, 25 Oct 2011 08:55:19 GMT"; modification-date="Tue, 25 Oct 2011 08:55:19 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAI0AAAIDAQAAAAAAAAAAAAAA AAMJBQYICgEAAQQDAQAAAAAAAAAAAAAABwECBQgABAYDEAABBAIABAUDBQAAAAAAAAAFAgMEBgEH ERITCAAiFBUWITIzQpVW1gkRAAIBAwIFAgMFCQAAAAAAAAECAxESBAUGACExIhNBB1FSFWEyIxQI cUKSU5PTJFTU/9oADAMBAAIRAxEAPwDu3a2HCltpkjghcgPe88Ek3PqEKMSi5/HOhMl7SNI5gyPr lpxxhvDyODiOZtSFqlfpMy9srokg6rbKSD8CUjZaj1AJoeRoQRxAjX4JBfBDLJAfuuGgUMPmUSTI 9p9CVAYdwqpBJPnWP4yY/etff3fxn0pv5qfwT/2eF+uD/Xl/qYv/AE8Dd2HCiNqkkQhceOY884k5 PqE2MNi4/JOmsCLSSI4gx/pl1xthzDKOLi+VtK1pT6TKe2N0aQ9FtlUk/AF41Wp9ASKnkKkgcIdf gjF88MscA+85eBgo+ZhHM72j1IU2juNFBIUF3p7f2DQOx2923VNuJ0W9wKhquKBtYPETJgI0ct1D BmHxDk2NLYiz3QJGSy0/yKXHU5haOC0pzg9+2Wg6TrnuNhaZrUK5OmSy5BeNq2vZDNIoahBIvVSR 0NKHkTxWX3B3Vqmge3ORqmiS+HU4oMUI/wAt8sEbEc+tjMAeo6ilOMY6B/2F13T9Ma6qu/Y3cNf9 yAAbwy+3YJr6kEx1nIsmCmRhRsk5sKuOEJS64uE3JfVBjrelNuLUnOVZUolbq/T5ruZuLLy9qjTc fbskoaCJ55FZFKLcpXwvaPJfaLjRSAPhxwe1/wBQmgw7exIt0y5cm4liInZIAUZg72kHyCv4dlxI FWr+0tAoPcTT97aNTtmi5NoqtsqlxdgxbOKwDPwnxGDgIqOMC0yZrMaZDKDHmldGRIYcSnC23XEK wrIP1za2obV3DJoOreMZ+PJHd42vQhgkisrUFQyMpFQCK0IB5cGDTN4adufbn1rSnZsDIgmtuUq3 bejBlJNCGVgaEg05EjjIO9K4Y3B2xGtc17KJB87QqDMEQVqSjJMgB+K2yMJZW6420iUWUK9OzlWc Y6rifHZ+32qYO3N8YWtaibcGOeRXb0RZUkhLnr2pfc32A8B73AwtR3HsDM0TSe/VJMWFok5d7RGK YRjoLpLCi86XMOFqac7itRaio8LW23+0qo3e0VSWTht2pdH0y5ZiMCSRkkGYtzY2OPH2JFgEuy3I vVW7IQ7Gaaxjp8nL4sluv243ruLWX1zau4Z8bS8lUYRefMEaMFCkwnHLRmNqBqALRix51rxWXZ3v ZsDbWiR7f3noOPJrWIXRpGxcJpXBdmHmGSgmEi1tNxbtC0pSnDU9f7XrV70S1Z6fVXaDWSVFuiQ1 OdEhgiQMYVBsMBcWKNralV9qA4+PW7HXD4x3mXEuJ+7Pir27NA1PQN0ZOl61OMvVIpUMkwd5PIXV HBLyfiFrWAYP3KQVPTi1e1t3aTujaMOs6DEcfSJ8ebxRWJEEVPIlFSMeMLVCVKdpUhh14r+JE6LD Fs1kS6crCQohVcJGbCiq2B2uODYzgBmyhY9YuQxg9EDKYalOxSDjMhxHVw2xleWURGP5jEDkFFmq agAsK150NVNCakVFR0qevDNQaBJgunpNLhWLYzOInstFgdLJQHC0DFXIYi6i1tFnWQ2h5fV1IP1+ RHH37YdR916fLjpep+Q6w935enw5Or+jhy+Xh424Bl+MflGyfy/p4lyvH9tviazr1t9evDZZcy// AC4cfz0FfPNh+Wnpd58fy9Ol3pSnLiEnyDUpJhm6iXgYBQMmqykgthi2o41V2xDzhhmpBUVimgXy cuvJdaguOEG4cfnS6lt7CEsr1Mn8wEYwkNlX9HDKb6/vliz8m5tUXHoSOo98RlfKt1RJIsTxm9o3 SU+KzuEKKkUdTHURkOEWoYBgAp//2Q== --_008_0368F388C03BB34BBBFA73209849D47A4E05292AITREXMBXVS2itro_ Content-Type: image/jpeg; name="image003.jpg" Content-Description: image003.jpg Content-Disposition: inline; filename="image003.jpg"; size=1586; creation-date="Tue, 25 Oct 2011 08:55:20 GMT"; modification-date="Tue, 25 Oct 2011 08:55:20 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIgAAAIDAAAAAAAAAAAAAAAA AAkKBQYIAQACAwEAAAAAAAAAAAAAAAAGBwMECAUQAAAHAAEDAwMFAQAAAAAAAAECAwQFBgcIERIJ ACETMVEUYXEiJBUWEQACAQMCBQIEAwkBAAAAAAABAgMREgQhBQAxEwYHQVFxIjJSYUIUgZGxctJz 09QVFv/aAAwDAQACEQMRAD8AYitXnMyeMsEmyrFDgpuuouThCTE3oV0hZWWi+v8ATlXcLW8LvkbD lk0gBwi3NJrOU26if5BEFxUQTcOF4d3rJxUnllskZQSoRDSvpVpkJpyJtArWhIoSGT96YMUpjVQV HrcwP7hGwFfjX3odOK2fzv0FIhlFcypaaZA6mOpq+oEIUPuYxuLgFKH7+rY8K7sTQTkn+3H/ALHE J74whqUWn8z/AOLidp3nUx6cno1pP0utxlbO7TJPTVd0e4WCUho0fd3KNoawYbRYyWCMREXCzYJR B0o2TUFuRdcE0FK2d4a3zExnnSQtIqkhSirWnpVZnIryBtIrSpAqRLj964E0oQgBSdSGY0/YY1B+ Fa+1Tpwn6lZe1FABUAOjdD2E/ToHwkEPr+nrVMEFYUNPyj+Hx4T0mQVdh7E8H88IvGOp6XdNl2fb svl5yOy2o0WQzGKutOkwrFgcXdO3yTu0wSE7GoxNrcM4mrJJtDoi5SIV+Cnt3pGFHeZO5MjDxcTZ tly0RsiWUTmKUXp0yiiNyjFoxc7FgbSSlPRhwfdkbbHlTTZufEzLEiFAyG03XEstRRqBRSlef4jj AvkP5WQvI+55rZIHivP8T2cBRbVFp1mwwSNcdXVvJTDR+1sSTBCnU8B/zEm5kFQ7HPxqLCT5A6D3 GnY/bZ7f2vMxzukW6F3BLo/UEZCMChPUk51qNRUDl7cHft2G45cLpiNiAKRay2l6kGtLV5Up6/Hg YcpUb8m7MmlAomRMyiVEzDa6QmIkcw0e4AexSyFUJ1Bb6GAB+/pq4GLM+FE/TY1Qfb/Vwv8AcN3w 4s2SO/UN9r+wP2cN3eHnm1vOxY5oeZapVM8rkHxVynFaTk7mpKuFpWwR0ZSr5C/PeXBdAtTJw/BD PI0xjtUYlIx11xKXt7QRyb5m7IwO293xdxx2yTPu+VkySiRoyoJkiYiIKgKiszD5yx0XXnV1ePe6 pd9wZ8VhF08CGFVKq6kiyQfNedTSMfSBrX3HC6nLTmByg5/W7NL3tef5jW5ahUC0V+NQzSUYxkc4 j5puezSC8m3suqXV65eIOo8pEhQVSKCQdBIY38vWhth8f4HYe1Z2HtP6uSGVrmMzRMQVBQUsWMUo STUHXhX5Xex7m3HGkzekrqCAI0lA1F2t13qB7fjxrPV6/wCPB5eZ1zVNc2evVZV6qNXhnfHVC5PG VZAwhXif9LBco6ISUiTQ4ImjTPYlnLFjRQK+KLoFTDX7Ym8rLsmOr422uemPmfIdGOmtV/SyUatb rXK3Vt0pxHv8fj5t0kLy5SyXcliLafl1WZARSltVDW0u14JX4tYHAmsTyYDGNXtc4grC0ILga48f Z6qnZNixmpBGGiSN+TNyCTUVQM9FQpjNPjEhAAT94imnfOcndT5Gyf8ApYcSNhJP0ehMZATdjXX1 gitANlKXVq3Kmp74yTt5Ytx/4Mk7rZF1epGyUFs9ttZXqfrry9OddBkYxXvHaztdUcWbXdqsdRS/ BGyRDbjmhS3z6rCmmWeKexznKW+kiYssKKxpMzKLeyoxoLlYADoUjg5u7JvK77TlBcbbI3tbWPJe Qg68l/Sx1NfpqwW6l3y14AO3I/Hq7hCYpctm0oHiK6U11aZwPlrdRS1tbdeP/9k= --_008_0368F388C03BB34BBBFA73209849D47A4E05292AITREXMBXVS2itro_ Content-Type: image/jpeg; name="image004.jpg" Content-Description: image004.jpg Content-Disposition: inline; filename="image004.jpg"; size=1696; creation-date="Tue, 25 Oct 2011 08:55:20 GMT"; modification-date="Tue, 25 Oct 2011 08:55:20 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIoAAAIDAQAAAAAAAAAAAAAA AAUGCAkKBwEAAwEBAAAAAAAAAAAAAAAABAYHBQgQAAEEAgEDAwEIAwAAAAAAAAMCBAUGAQcIERIW FBUJACFRoRMjJDRWltcZEQACAQMDAgQDBgcAAAAAAAABAgMRBAUSEwYhBwAxIhRBUUJSI5PUFRdh cdHSJKQW/9oADAMBAAIRAxEAPwDYRLfIbpFhIPGsfE2ywRwTESwsLCb07ERU6zRntRLw7W5bYq1i JDO1JVls5MwAN2HGDgyRuQRV1Sz7PcuvLZLikaFhUqUuWZT9ljFbyJqH1AOSp9LUYECRX/ezhVhd vas7voNNQktVVh5alEtzG+k/SxQBh6lqpBI//oxp3+pXX/LuO3++Pon9luXfOH8O8/KeA/344P8A OX8ax/OeCEV8hmkX8g0ayEVa69HFMNEhYJCb07LxcE0WrCFy0w0pu2LTYhw7Rak5dOQsDjZhzk58 jbjKUYt52f5dZ2z3FI5CoqFVLlWY/ZUyW8aaj9ILgsfStWIBMsO9nCb+7S0V3TWaajJasqj7TCK5 kfSPqYIQo9TUUFhnd4kS8ZZN5aVrktqF9vtjKokGmNUx0nU411YSxmtbBNAdoNebHVKi5HWWkIR7 6Z/INxHSDCUd5khGvsPny3Fpwa8u7XIriZI0iPuSspCBpo0K/cRyyjcLhdUaMRXrRSxHFHbqO1vO 4FlbXuLOYjkkmHtQ0IMhSGVw3+RJFC20qF9MkighelWCg9JY8eeR25LFs2zaU4z2ePo0ZunaVABV 03/TfWhzlMt8tCTtGMeT2Wx9SKrSbIrX1TbBov7MDauTgSMq8xeecN41jrHH8nzUUmVbG205l2Lv 79JoleOb025oZFYNpakvxkRWJA037cc15Tk8hkuK4GWLDrlLqAQ+4sxsPDKySQnVcrURspXUtYvI RuyaWMatntbvrGXtlD2RVpulXCGinw5WvTwgCdiA/jHXp3TZ0zcO4yVipAPfgLtm4cND4SvCCK7V Yw6Y6+xWexQyuGuI7nGyK2l0rSq+YIYBlZTSquqsOlR1HhFyeJy/HcwcTm7aS1ykTLqR6VAY9GVl LK6sK0dGZT1oeh8OvxXy+JDnrxtYd3XLRpe3vT7sK477AHjOcdc9P5/4/Sl3mQjs9kpPnHaj/dtv 6eKV2aWJO8+MiU+pZLo0/nYXP93iwrfuy9laM+Pzl3dtW3OwUCzZ+Rvki3VZK24SxlxRE5yTtQnz drI5Es7BDteUDWUChF6dUJXjuzjMt4phMNybuxx/G5y2iu7L/j8eduQakLJj4ipK1o1Opoaj406e KlyvNZjjPaXkOSwV1NZ3p5lkRuxnS4V8jKGAahK16AlaH4AiviPXzFzEgS1cUZ2YKo8zZuLU+SYf EEgJpCRbYiZZyQ2BoEjKhuZExMIxjCR5MrpjHdnqy9hYY4sHyS2txS3hy1EFahVKSKKefwUCvxoP Onhc79arrkHGbi6NbqfDksxFCzBkc1p/Ek0+FTTz8Uw2DIWu0zA43p3lOAS2GuiydfWqq7TLWiwg ys20nB1FFxdgnWFYWgEmePkCN3eBkPkTZBFtx3bBtkzxiI8qTEKmkbgmctDXV0JMiKmkv1QOtVqq 1YgMYVygYIcslHGmzjXPTSbZUWWm2OgVWZw4joJTGxVqM1FUlQDnnG6/GpfyuH5G+E+/u/IfJ7JP +F+X+5K9x9/94qvj3l3vPd6j1X7/ANX1/M/V6/WxbGx93H7JcF+o7Q29thvbOn06NC7mzppp0+jT Snp8LtxX2knvDyb9O3TubgTZ3dXq3NZ297XXVq+81V1da+G+GzLurpUg8mU8jYOlKi5NeJK0LkrV aB0kTBRbA21nB3NFOYncv4hCgNDpkBsGhyDOoTnI0NyYWba7GBvDxJMI139YhcKu5XoZjEjdQerB l1sAQCtSwaOMDFHkdoOTtyBYtDbZuVDejQdQhV2WtVqEIYRqxDENQKf/2Q== --_008_0368F388C03BB34BBBFA73209849D47A4E05292AITREXMBXVS2itro_ Content-Type: image/jpeg; name="image005.jpg" Content-Description: image005.jpg Content-Disposition: inline; filename="image005.jpg"; size=1656; creation-date="Tue, 25 Oct 2011 08:55:23 GMT"; modification-date="Tue, 25 Oct 2011 08:55:23 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIwAAQEAAwAAAAAAAAAAAAAA AAkIAwUKAQABBAMBAAAAAAAAAAAAAAAEAAMGBwEFCAkQAAEEAgEDBQADAQAAAAAAAAUDBAYHAQII ExQVABESFglCIyYXEQACAQIDBQQIBAcAAAAAAAABAgMRBAASBSETFAYHMUEiMlFhgZEzFRYIwUJi 0nGhsYLCIyT/2gAMAwEAAhEDEQA/AO5YldcXF6AnTto5bjJYeHRiFlSUirqOtZqcM4WyDGRVvKZw DKl3x7DVXZgho3wu+TTyqhoolnXfZ0xEeYgH2/gKYYE+byKxH9u317SDT2YzRu4BEyBsJPEAr2Vx or3Xi5DG5bUpwGS7F44HvewLC7IdMHnZv2ayCvTU26ayW+m3ttrtjC3X6h7m/bhGanare9f3Y2ri x0R6W7wxFZGIFNsdUkXcPYS9aCWeMf2kiCASYlSmo9t74ysqm3Vwgn7qKfFLTffXO5J7CCf4H8QB hcQo2sCF9NVNPcxNPZs7ezBE/pAFfSv81btJxlA1vPqlpYJe1RrRUa4LSkdaVNjRUyhu8VYsW7sg oXerMVR+MNk919mzxXTTGc7eip02Mw7QSf54BtpAGQHYCAPZTA+2BPOUXGuaXfTdNSTlQKh9H1bH BkJj0Shs5dQVlRwCu+CpeNzuNtw0QfAH04k9ryyzPILD11zj9TL9JwjlJFPOBjVWKiuweju2bf64 NVkkCsctSfT622e6mGv4R2nN7O4UfeLIIzMvIj8l5e7JvLDEmQMpXhrLkHeIuukSAaRjQ5scxb1y zFosUnLZFTUfojj2zj2zkmEZgrbfN/lgK5YKWQUpl9P6RXAg8d7+sGxDfJ+V3ZZXJA/rU/FKxeS8 QC1TyfsmgwQnanQMTd5gjIRBNVRzYYdaSZBJN5hLKrHDP5bJud1t9teTtH5o1vXL7VrzW7rUXMFp cXSJBeTW0Y3LfCCReEKwYANSoy1IYknHvlzr0a6cdPOR+neidN9A5Ktm1bmTStCubnVOW9O1u6l+ YiUG/kuL0b1pYWgd2jzhZTLlVoUjVTWA/i3ymZRC0gBP9CL31s5GexyMUqWb3PfbaINDzHE7MSyO yUU1k7nfdzMwIHVFkV31xgWq3U3U13yvjX1JF5b5sFrcxy69fnUTIiQNxFyEBGdnRwJDXOoAVuxC CSDXFT3HW77fn17Rb2y6TcpLyatjcT6pCdH0M3LK/CxW9xbSNaqF4WaVnmgU1uVdVVlEdcRxyJe8 zOHlvREGc5m2Lb5QrD5BIiTQjY04koRNYG4kEYkUTl0Tl8iPNng57kTndksvqmu5HOE1tU2iuPjp FdXv+eOSNaswdYubpyVejSyvH4ZMjxyRyOwKt3EipU5gFbFz8m6J9sP3JdJOY7q06caDoMMIa3WW LT7C3ugJrdJ7e6tby0t4JI5Y89JEVmSOaMxs08ZJaLlsytrKuRyHFvSyTtda8WLd3s0mbUq6JydX iGsGiCtkNZWClKUzYoHx8f3DIPF40RUNPFk8rsEW2yizdIC2SPjtS+nJJOF4W43u8jjzcNUb0bZD XbTatHPcB2Y2Ak1k8m8nHq1DpK331Np3ywJNqLL86DT8CQ1tAtY2bflFuFECqcszPRWKJmnP7Ud2 b8kGMdx9OT6/aSXgH5D4+ElPa4AYHRP7F/1vtvK9Lsv9L1up/D4+rCdeo9WzPH5O5LWvlNMv+yu8 81KeOte7HLFpJ9o+WLdRQZeL/NLzTk+LFm3tYd3wVdzmzf8APky/mxI905ud1f0FQ55anwam0MN7 lydcb0BKpKlFkTkpVspr4KotIbGF7kISPQwgUXkBFMozLKZXdIuemk3Uh+vJc/PLT6xkPd8GOGtN 54wcktBJvK7wtVwe4jF58hyWo6Sa6ft9hsjp3EpvRdTauPEYYhamNr+BnFitvujAtupiaAZUZGJc f//Z --_008_0368F388C03BB34BBBFA73209849D47A4E05292AITREXMBXVS2itro_-- From internet-drafts@ietf.org Sat Oct 29 05:36:12 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC5D21F888A; Sat, 29 Oct 2011 05:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDy4rVPLNZTj; Sat, 29 Oct 2011 05:36:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB6721F86D0; Sat, 29 Oct 2011 05:36:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111029123612.19032.71307.idtracker@ietfa.amsl.com> Date: Sat, 29 Oct 2011 05:36:12 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 12:36:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : A Mechanism to Measure the Quality of a Point-to-point R= oute in a Low Power and Lossy Network Author(s) : Mukul Goyal Emmanuel Baccelli Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-measurement-02.txt Pages : 18 Date : 2011-10-29 This document specifies a mechanism that enables an RPL router to measure the quality of an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-02.txt From prvs=27675f224=mukul@uwm.edu Sat Oct 29 08:55:01 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B34F21F84DA for ; Sat, 29 Oct 2011 08:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vARIPBGC9Ysa for ; Sat, 29 Oct 2011 08:55:01 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 39B3C21F84A5 for ; Sat, 29 Oct 2011 08:54:24 -0700 (PDT) Received: from localhost (HELO mta02.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 29 Oct 2011 10:54:23 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 97A2012E3BE for ; Sat, 29 Oct 2011 10:54:23 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kn9BClzjpGLQ for ; Sat, 29 Oct 2011 10:54:22 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 8787412E3B2 for ; Sat, 29 Oct 2011 10:54:22 -0500 (CDT) Date: Sat, 29 Oct 2011 10:54:22 -0500 (CDT) From: Mukul Goyal To: roll@ietf.org Message-ID: <478459054.91399.1319903662442.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <20111029123612.19032.71307.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 15:55:01 -0000 Hi all This update includes: 1) Reorganization of the contents (splitting sections into subsections) to help the implementor. 2) New sections on Security and IANA considerations. 3) Two new flags in the MO: one to allow the origin to request the target to generate a Measurement Request so that the origin can determine the round-trip cost of reaching the target; the other that allows an intermediate route to generate the Measurement Reply on target's behalf. Thanks Mukul ----- Original Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Sent: Saturday, October 29, 2011 7:36:12 AM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : A Mechanism to Measure the Quality of a Point-to-point Route in a Low Power and Lossy Network Author(s) : Mukul Goyal Emmanuel Baccelli Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-measurement-02.txt Pages : 18 Date : 2011-10-29 This document specifies a mechanism that enables an RPL router to measure the quality of an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-02.txt _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From moulchan@cisco.com Sat Oct 29 09:00:16 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C938621F853E for ; Sat, 29 Oct 2011 09:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QT09+X6NcJFY for ; Sat, 29 Oct 2011 09:00:14 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B380E21F8753 for ; Sat, 29 Oct 2011 09:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=2613; q=dns/txt; s=iport; t=1319904014; x=1321113614; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=v74suPnLyOeiQar7g/HhmpOR/wNEq90VK/Du0sPrL7k=; b=Y8jobKlW4ECm/Z6JlPkoumHv5SdMZtZAfaRSvSwjecm3UQ662BUtWKJ8 IZjhW4zssdEkEqyRUc7AW2sJPeZzSDvLWTtoUIXn11WYHiN9jPsWD3qlJ 2gZXb3DRmz5YbcwzwbZuYTDDSmzTGttOynqU99BnuTOzJzD0JdqXy04V/ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtwAANIhrE6tJXG8/2dsb2JhbABCDpoGj1SBBYFyAQEBAQMBAQEPAR0KNBcEAgEIEQQBAQsGFwEGASYfCQgBAQQBEggBGYdolUoBnUqIIWEEiAaRPotyVQ X-IronPort-AV: E=Sophos;i="4.69,424,1315180800"; d="scan'208";a="31917299" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 29 Oct 2011 16:00:14 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9TG0EHQ015654; Sat, 29 Oct 2011 16:00:14 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 29 Oct 2011 11:00:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 29 Oct 2011 11:00:10 -0500 Message-ID: In-Reply-To: <478459054.91399.1319903662442.JavaMail.root@mail17.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-02.txt Thread-Index: AcyWUyDFZRSDK8KoT96eGoJUIcg0ugAAHB/A References: <20111029123612.19032.71307.idtracker@ietfa.amsl.com> <478459054.91399.1319903662442.JavaMail.root@mail17.pantherlink.uwm.edu> From: "Mouli Chandramouli (moulchan)" To: "Mukul Goyal" , X-OriginalArrivalTime: 29 Oct 2011 16:00:14.0105 (UTC) FILETIME=[D83A4090:01CC9653] Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 16:00:16 -0000 Hello folks,=20 A newbie question.=20 It is assumed that network is lossy and low power and do we still need active probing mechanism analogous to standard IP networks ?=20 Thanks Mouli -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal Sent: Saturday, October 29, 2011 9:24 PM To: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-02.txt Hi all This update includes: 1) Reorganization of the contents (splitting sections into subsections) to help the implementor. 2) New sections on Security and IANA considerations. 3) Two new flags in the MO: one to allow the origin to request the target to generate a Measurement Request so that the origin can determine the round-trip cost of reaching the target; the other that allows an intermediate route to generate the Measurement Reply on target's behalf. Thanks Mukul=20 ----- Original Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Sent: Saturday, October 29, 2011 7:36:12 AM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : A Mechanism to Measure the Quality of a Point-to-point Route in a Low Power and Lossy Network Author(s) : Mukul Goyal Emmanuel Baccelli Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-measurement-02.txt Pages : 18 Date : 2011-10-29 This document specifies a mechanism that enables an RPL router to measure the quality of an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-02.t xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-02.tx t _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=277052783=mukul@uwm.edu Sun Oct 30 15:45:38 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A7921F8BD7 for ; Sun, 30 Oct 2011 15:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gigr8BWUCOvA for ; Sun, 30 Oct 2011 15:45:37 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7A221F8BD5 for ; Sun, 30 Oct 2011 15:45:37 -0700 (PDT) Received: from localhost (HELO mta02.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 30 Oct 2011 17:45:36 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 91E9E12E3C2 for ; Sun, 30 Oct 2011 17:45:36 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tocyV9gfKsLl for ; Sun, 30 Oct 2011 17:45:36 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 5492312E3BC for ; Sun, 30 Oct 2011 17:45:36 -0500 (CDT) Date: Sun, 30 Oct 2011 17:45:36 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <1166486576.96075.1320014736244.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <1381788859.96067.1320014687102.JavaMail.root@mail17.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] Fwd: I-D Action: draft-ietf-roll-p2p-measurement-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 22:45:38 -0000 ----- Forwarded Message ----- From: "Mukul Goyal" To: "Mouli Chandramouli (moulchan)" Sent: Sunday, October 30, 2011 5:44:47 PM Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-02.txt Mouli, I guess the best answer to your question is available in the introduction sections of draft-ietf-roll-p2p-rpl-04 and draft-ietf-roll-p2p-measurement-02. Thanks Mukul ----- Original Message ----- From: "Mouli Chandramouli (moulchan)" To: "Mukul Goyal" , roll@ietf.org Sent: Saturday, October 29, 2011 11:00:10 AM Subject: RE: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-02.txt Hello folks, A newbie question. It is assumed that network is lossy and low power and do we still need active probing mechanism analogous to standard IP networks ? Thanks Mouli -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal Sent: Saturday, October 29, 2011 9:24 PM To: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-02.txt Hi all This update includes: 1) Reorganization of the contents (splitting sections into subsections) to help the implementor. 2) New sections on Security and IANA considerations. 3) Two new flags in the MO: one to allow the origin to request the target to generate a Measurement Request so that the origin can determine the round-trip cost of reaching the target; the other that allows an intermediate route to generate the Measurement Reply on target's behalf. Thanks Mukul ----- Original Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Sent: Saturday, October 29, 2011 7:36:12 AM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : A Mechanism to Measure the Quality of a Point-to-point Route in a Low Power and Lossy Network Author(s) : Mukul Goyal Emmanuel Baccelli Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-measurement-02.txt Pages : 18 Date : 2011-10-29 This document specifies a mechanism that enables an RPL router to measure the quality of an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-02.t xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-02.tx t _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From Jorjeta.Jetcheva@itron.com Mon Oct 31 15:32:13 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A131F0CB8 for ; Mon, 31 Oct 2011 15:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLmUlBZoDp6V for ; Mon, 31 Oct 2011 15:32:12 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.116]) by ietfa.amsl.com (Postfix) with ESMTP id 12A161F0CAC for ; Mon, 31 Oct 2011 15:32:12 -0700 (PDT) Received: from ITR-EXMBXVS-2.itron.com ([192.168.9.111]) by spo-exchcn-2.itron.com ([192.168.9.116]) with mapi; Mon, 31 Oct 2011 15:32:11 -0700 From: "Jetcheva, Jorjeta" To: "roll@ietf.org" Date: Mon, 31 Oct 2011 15:32:09 -0700 Thread-Topic: changes in draft-ietf-roll-applicability-ami-05 Thread-Index: Acx9Ss7hRJCwW4vkTj27zHG64Ecm7wVYLpFgAVr1f0A= Message-ID: <0368F388C03BB34BBBFA73209849D47A4E290594@ITR-EXMBXVS-2.itron.com> References: <0368F388C03BB34BBBFA73209849D47A4D628684@ITR-EXMBXVS-2.itron.com> <0368F388C03BB34BBBFA73209849D47A4E05292A@ITR-EXMBXVS-2.itron.com> In-Reply-To: <0368F388C03BB34BBBFA73209849D47A4E05292A@ITR-EXMBXVS-2.itron.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_008_0368F388C03BB34BBBFA73209849D47A4E290594ITREXMBXVS2itro_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [Roll] changes in draft-ietf-roll-applicability-ami-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 22:32:13 -0000 --_008_0368F388C03BB34BBBFA73209849D47A4E290594ITREXMBXVS2itro_ Content-Type: multipart/alternative; boundary="_000_0368F388C03BB34BBBFA73209849D47A4E290594ITREXMBXVS2itro_" --_000_0368F388C03BB34BBBFA73209849D47A4E290594ITREXMBXVS2itro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello everyone, Just wanted to draw your attention to the new iteration of the RPL AMI Appl= icability Internet-Draft (version 05). Below is a brief summary of the changes: * Added new co-author * Expanded discussion of traffic characteristics in Section 2.2 We look forward to additional feedback! Thanks, Jorjeta [cid:image001.jpg@01CC97DD.2B28C300] Jorjeta Jetcheva, Ph.D. Strategic Industry Standards and Architecture Office of the CTO Mobile: +1.408.688.1428 Knowledge to Shape Your Future [cid:image002.jpg@01CC97DD.2B28C300] [cid:im= age003.jpg@01CC97DD.2B28C300] [cid:im= age004.jpg@01CC97DD.2B28C300] [cid:image005.jpg@01CC97DD.2B28C300] --_000_0368F388C03BB34BBBFA73209849D47A4E290594ITREXMBXVS2itro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello everyone,

 

Just wanted to draw your attention to the new= iteration of the RPL AMI Applicability Internet-Draft (version 05). 

 =

Below is a brief summary of the changes:<= o:p>

 

·         Added new co-author

·   &= nbsp;     Expanded discussion of traffic charact= eristics in Section 2.2

 

<= p class=3DMsoNormal>We look forward to additional feedback! 

 <= /span>

Thanks, Jorjeta

 

 

3D"http://marketing.itron.com/c=

Jorjeta Jetcheva, Ph.D.

Strategic Industry Standards and Architecture

=

Office of the CTO
Mobile: +1.408.688.1428
Kno= wledge to Shape Your Future

3D"http://marketing.itron.com/campaign/social_media_icon_twitter29=   3D"http://market=  = ; <= span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";text-d= ecoration:none'>3D"http://marketing.itron=   

 

 =

= --_000_0368F388C03BB34BBBFA73209849D47A4E290594ITREXMBXVS2itro_-- --_008_0368F388C03BB34BBBFA73209849D47A4E290594ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=20786; creation-date="Mon, 31 Oct 2011 15:32:09 GMT"; modification-date="Mon, 31 Oct 2011 15:32:09 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4RLERXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAA agEoAAMAAAABAAIAAAExAAIAAAAeAAAAcgEyAAIAAAAUAAAAkIdpAAQAAAABAAAApAAAANAACvyA AAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2gAMjAxMTowOTowOSAwOToz ODo1OQAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAASKADAAQAAAABAAAAUQAAAAAAAAAGAQMAAwAA AAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEAAgAAAgEABAAAAAEAAAEuAgIA BAAAAAEAABGOAAAAAAAAAEgAAAABAAAASAAAAAH/2P/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5v AhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAA AAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAA FHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALE AAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gA AAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJp Z2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElF QzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAA AAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZ WiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAA AAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVu Y2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNl IFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABX H+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAA AAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8 AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0B EwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZ AeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC 6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7 BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF 5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfS B+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEK Jwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzA DNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MP zw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMj E0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW +hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsU GzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qf vx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSr JNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIq NSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+ MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2 cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0i PWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdE ikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwq THJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJU j1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0n XXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1m kmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XAr cIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6 pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VH hauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q 1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJ nPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSp N6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYB tnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD 1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+ 0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4Dbg veFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M 8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23/ ///tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8V GBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4O DhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgA UQBIAwEiAAIRAQMRAf/dAAQABf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUB AQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJx gTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePz RieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYF NQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNU oxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//a AAwDAQACEQMRAD8AzkkklkPdKSSSSUpJJJJSkkkklKSSSSU//9DOSSSWQ90pJJJJSkkkklKSSSSU pJJJJT//0c5JJJZD3SkkkklKSSSSUpJJJJSkkkklP//Szkkl2H1A6dVa3LzLq2vbLambgDr/ADln 0v8ArSyscDOQiNLez5rmI8vhllkOLhr07cXEeF49Jd/0roWH1DMzep5dNdmNkWFmJXEQ2pzqS/aN rff6bVjZX1RzMzq+dVhGimqhzYaS4NAeN9bNK3e/0/dZ/XUh5eYAI14jQ/iwQ+J4JTlCX6v24iU5 S+WMjwxlD/AnPgeZVnpmKMvOqodqxxl/9UDc5aOb9Uuq4Yqa7ZbdfYa6qaiS47QXOt9zWNbWtbpX 1T6pgWm2wVvusrdsaHHa0jaf0tm36Tvofo/UUOTFm4JcECZVp5y2X5uewDGTHLG5A8Gv4uZ1fD6R gU7WVk5Dx7G7naD992qwluY31d611jLyy8squx3hlwuLgNxn2V+m232t2ol/1J6tj4d2U91R9AOc a2lxc5rPpOZ7P3Ruahh5fLGHq4pncyKMfM4MVY8mcSyGruXFrP5eH+q8+kkki3H/085eh9I/yR9T vtJ9thqffPi6z+Y/6PorzxJZeLJ7ZJqyRQ8Hsec5X7zGEDLhjGYnIVxcfD+g+h9Msf0r6mjJe4mz 0XWtJMwbP6O0f51SX1cc7A+rNnUcgl9tgsyXl5JJgbKwXH3e5lTF54kpBzFEen5Y8I16/vNWXwoS GQHJrly+9M8H6H+a+d7P6ndYszepXnqOQbMgs/Vg8wBuM3Mpb9Fu7bV7GraZjjpWbmdV6l1Amm6R VU4kNY2dzWtZLt9jPoM9P/0YvMk7nOcZcST4nVKHMERAMeIg2JX/ANJOb4WMmSUo5Pbx5IiE8cYR +WP+bl/k30vAzGV9Hy+sluz7QbckNPO1o9KgH+vXTWhdcyL8H6puGQ8vybKWUvc7kvsAbd/0fUXn CSJ5o8NcP6PDv1O8lg+ERGQT9ywMgycPB+hD+bxcXH+ipJJJV3Vf/9TOSXnaSyHun0RJedpJKfRE l52kkp9ESXnaSSn0RJedpJKf/9n/7RmsUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQQ6AAAAAACNAAAAEAAAAAEAAAAAAAtwcmludE91dHB1dAAAAAQAAAAAUHN0 U2Jvb2wBAAAAAEludGVlbnVtAAAAAEludGUAAAAAQ2xybQAAAA9wcmludFNpeHRlZW5CaXRib29s AAAAAAtwcmludGVyTmFtZVRFWFQAAAAMAEkATQBBAEcARQBSAFUATgBOAEUAUgAAADhCSU0EOwAA AAABsgAAABAAAAABAAAAAAAScHJpbnRPdXRwdXRPcHRpb25zAAAAEgAAAABDcHRuYm9vbAAAAAAA Q2xicmJvb2wAAAAAAFJnc01ib29sAAAAAABDcm5DYm9vbAAAAAAAQ250Q2Jvb2wAAAAAAExibHNi b29sAAAAAABOZ3R2Ym9vbAAAAAAARW1sRGJvb2wAAAAAAEludHJib29sAAAAAABCY2tnT2JqYwAA AAEAAAAAAABSR0JDAAAAAwAAAABSZCAgZG91YkBv4AAAAAAAAAAAAEdybiBkb3ViQG/gAAAAAAAA AAAAQmwgIGRvdWJAb+AAAAAAAAAAAABCcmRUVW50RiNSbHQAAAAAAAAAAAAAAABCbGQgVW50RiNS bHQAAAAAAAAAAAAAAABSc2x0VW50RiNQeGxAUgAAAAAAAAAAAAp2ZWN0b3JEYXRhYm9vbAEAAAAA UGdQc2VudW0AAAAAUGdQcwAAAABQZ1BDAAAAAExlZnRVbnRGI1JsdAAAAAAAAAAAAAAAAFRvcCBV bnRGI1JsdAAAAAAAAAAAAAAAAFNjbCBVbnRGI1ByY0BZAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAAB AAEASAAAAAEAAThCSU0EJgAAAAAADgAAAAAAAAAAAAA/gAAAOEJJTQQNAAAAAAAEAAAAeDhCSU0E GQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEAOEJJTScQAAAAAAAKAAEAAAAAAAAAAThC SU0D9QAAAAAASAAvZmYAAQBsZmYABgAAAAAAAQAvZmYAAQChmZoABgAAAAAAAQAyAAAAAQBaAAAA BgAAAAAAAQA1AAAAAQAtAAAABgAAAAAAAThCSU0D+AAAAAAAcAAA//////////////////////// /////wPoAAAAAP////////////////////////////8D6AAAAAD///////////////////////// ////A+gAAAAA/////////////////////////////wPoAAA4QklNBAgAAAAAABAAAAABAAACQAAA AkAAAAAAOEJJTQQeAAAAAAAEAAAAADhCSU0EGgAAAAADSQAAAAYAAAAAAAAAAAAAAFEAAABIAAAA CgBVAG4AdABpAHQAbABlAGQALQAxAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAABI AAAAUQAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAABAAAAABAAAAAAAAbnVsbAAA AAIAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAUQAAAABSZ2h0bG9uZwAAAEgAAAAGc2xpY2VzVmxMcwAA AAFPYmpjAAAAAQAAAAAABXNsaWNlAAAAEgAAAAdzbGljZUlEbG9uZwAAAAAAAAAHZ3JvdXBJRGxv bmcAAAAAAAAABm9yaWdpbmVudW0AAAAMRVNsaWNlT3JpZ2luAAAADWF1dG9HZW5lcmF0ZWQAAAAA VHlwZWVudW0AAAAKRVNsaWNlVHlwZQAAAABJbWcgAAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0 MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAAFEAAAAA UmdodGxvbmcAAABIAAAAA3VybFRFWFQAAAABAAAAAAAAbnVsbFRFWFQAAAABAAAAAAAATXNnZVRF WFQAAAABAAAAAAAGYWx0VGFnVEVYVAAAAAEAAAAAAA5jZWxsVGV4dElzSFRNTGJvb2wBAAAACGNl bGxUZXh0VEVYVAAAAAEAAAAAAAlob3J6QWxpZ25lbnVtAAAAD0VTbGljZUhvcnpBbGlnbgAAAAdk ZWZhdWx0AAAACXZlcnRBbGlnbmVudW0AAAAPRVNsaWNlVmVydEFsaWduAAAAB2RlZmF1bHQAAAAL YmdDb2xvclR5cGVlbnVtAAAAEUVTbGljZUJHQ29sb3JUeXBlAAAAAE5vbmUAAAAJdG9wT3V0c2V0 bG9uZwAAAAAAAAAKbGVmdE91dHNldGxvbmcAAAAAAAAADGJvdHRvbU91dHNldGxvbmcAAAAAAAAA C3JpZ2h0T3V0c2V0bG9uZwAAAAAAOEJJTQQoAAAAAAAMAAAAAj/wAAAAAAAAOEJJTQQUAAAAAAAE AAAABDhCSU0EDAAAAAARqgAAAAEAAABIAAAAUQAAANgAAERYAAARjgAYAAH/2P/iDFhJQ0NfUFJP RklMRQABAQAADEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElF QyBzUkdCAAAAAAAAAAAAAAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHw AAAAFGJrcHQAAAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQA AAJUAAAAcGRtZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1l YXMAAAQMAAAAJHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAI DHRleHQAAAAAQ29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNj AAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA 81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAA AAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93 d3cuaWVjLmNoAAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNj AAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAA AAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFla IAAAAAAATAlWAFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcg AAAAAENSVCBjdXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQA WQBeAGMAaABtAHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADl AOsA8AD2APsBAQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoB oQGpAbEBuQHBAckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKY AqICrAK2AsECywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD 4APsA/kEBgQTBCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVn BXcFhgWWBaYFtQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0H TwdhB3QHhgeZB6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5 CY8JpAm6Cc8J5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kM EgwqDEMMXAx1DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7u DwkPJQ9BD14Peg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYS RRJkEoQSoxLDEuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXg FgMWJhZJFmwWjxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0a BBoqGlEadxqeGsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5q HpQevh7pHxMfPh9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgj ZiOUI8Ij8CQfJE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSii KNQpBik4KWspnSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwu gi63Lu4vJC9aL5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSe NNg1EzVNNYc1wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07 azuqO+g8JzxlPKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJy QrVC90M6Q31DwEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBK N0p9SsRLDEtTS5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIx UnxSx1MTU19TqlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa 9VtFW5Vb5Vw1XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2Pr ZEBklGTpZT1lkmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBt uW4SbmtuxG8eb3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3Vnez eBF4bnjMeSp5iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCC koL0g1eDuoQdhICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Y jf+OZo7OjzaPnpAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZ kJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWp phqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuy wrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1 wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXO Ns62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK 3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr ++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3 /Af8mP0p/br+S/7c/23////tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkI DAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwM/8AAEQgAUQBIAwEiAAIRAQMRAf/dAAQABf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMA AQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMB AAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKj dDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cR AAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M0 8SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW 5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8AzkkklkPdKSSSSUpJJJJSkkkklKSSSSU//9DOSSSW Q90pJJJJSkkkklKSSSSUpJJJJT//0c5JJJZD3SkkkklKSSSSUpJJJJSkkkklP//Szkkl2H1A6dVa 3LzLq2vbLambgDr/ADln0v8ArSyscDOQiNLez5rmI8vhllkOLhr07cXEeF49Jd/0roWH1DMzep5d NdmNkWFmJXEQ2pzqS/aNrff6bVjZX1RzMzq+dVhGimqhzYaS4NAeN9bNK3e/0/dZ/XUh5eYAI14j Q/iwQ+J4JTlCX6v24iU5S+WMjwxlD/AnPgeZVnpmKMvOqodqxxl/9UDc5aOb9Uuq4Yqa7ZbdfYa6 qaiS47QXOt9zWNbWtbpX1T6pgWm2wVvusrdsaHHa0jaf0tm36Tvofo/UUOTFm4JcECZVp5y2X5ue wDGTHLG5A8Gv4uZ1fD6RgU7WVk5Dx7G7naD992qwluY31d611jLyy8squx3hlwuLgNxn2V+m232t 2ol/1J6tj4d2U91R9AOca2lxc5rPpOZ7P3Ruahh5fLGHq4pncyKMfM4MVY8mcSyGruXFrP5eH+q8 +kkki3H/085eh9I/yR9TvtJ9thqffPi6z+Y/6PorzxJZeLJ7ZJqyRQ8Hsec5X7zGEDLhjGYnIVxc fD+g+h9Msf0r6mjJe4mz0XWtJMwbP6O0f51SX1cc7A+rNnUcgl9tgsyXl5JJgbKwXH3e5lTF54kp BzFEen5Y8I16/vNWXwoSGQHJrly+9M8H6H+a+d7P6ndYszepXnqOQbMgs/Vg8wBuM3Mpb9Fu7bV7 GraZjjpWbmdV6l1Amm6RVU4kNY2dzWtZLt9jPoM9P/0YvMk7nOcZcST4nVKHMERAMeIg2JX/ANJO b4WMmSUo5Pbx5IiE8cYR+WP+bl/k30vAzGV9Hy+sluz7QbckNPO1o9KgH+vXTWhdcyL8H6puGQ8v ybKWUvc7kvsAbd/0fUXnCSJ5o8NcP6PDv1O8lg+ERGQT9ywMgycPB+hD+bxcXH+ipJJJV3Vf/9TO SXnaSyHun0RJedpJKfREl52kkp9ESXnaSSn0RJedpJKf/9k4QklNBCEAAAAAAFUAAAABAQAAAA8A QQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAgAFAAaABvAHQAbwBz AGgAbwBwACAAQwBTADUAAAABADhCSU0EBgAAAAAABwAIAQEAAQEA/+ENmmh0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6 TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0i QWRvYmUgWE1QIENvcmUgNS4wLWMwNjAgNjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAg ICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjIt cmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOnBob3Rvc2hvcD0iaHR0cDovL25z LmFkb2JlLmNvbS9waG90b3Nob3AvMS4wLyIgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9l bGVtZW50cy8xLjEvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21t LyIgeG1sbnM6c3RFdnQ9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJj ZUV2ZW50IyIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIg eG1wOkNyZWF0ZURhdGU9IjIwMTEtMDktMDlUMDk6Mzg6NTktMDc6MDAiIHhtcDpNZXRhZGF0YURh dGU9IjIwMTEtMDktMDlUMDk6Mzg6NTktMDc6MDAiIHhtcDpNb2RpZnlEYXRlPSIyMDExLTA5LTA5 VDA5OjM4OjU5LTA3OjAwIiBwaG90b3Nob3A6Q29sb3JNb2RlPSIzIiBwaG90b3Nob3A6SUNDUHJv ZmlsZT0ic1JHQiBJRUM2MTk2Ni0yLjEiIGRjOmZvcm1hdD0iaW1hZ2UvanBlZyIgeG1wTU06SW5z dGFuY2VJRD0ieG1wLmlpZDozOEVDOTBGRDFBMjI2ODExOEQ0REE0Qzk2QkZDRjc0MyIgeG1wTU06 RG9jdW1lbnRJRD0ieG1wLmRpZDozOEVDOTBGRDFBMjI2ODExOEQ0REE0Qzk2QkZDRjc0MyIgeG1w TU06T3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOjM4RUM5MEZEMUEyMjY4MTE4RDREQTRDOTZC RkNGNzQzIj4gPHBob3Rvc2hvcDpEb2N1bWVudEFuY2VzdG9ycz4gPHJkZjpCYWc+IDxyZGY6bGk+ eG1wLmRpZDo1QkM3ODJFQzExMjA2ODExODA4M0M2NDI4QkQ3NkVDNzwvcmRmOmxpPiA8L3JkZjpC YWc+IDwvcGhvdG9zaG9wOkRvY3VtZW50QW5jZXN0b3JzPiA8eG1wTU06SGlzdG9yeT4gPHJkZjpT ZXE+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJjcmVhdGVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAu aWlkOjM4RUM5MEZEMUEyMjY4MTE4RDREQTRDOTZCRkNGNzQzIiBzdEV2dDp3aGVuPSIyMDExLTA5 LTA5VDA5OjM4OjU5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3Ag Q1M1IE1hY2ludG9zaCIvPiA8L3JkZjpTZXE+IDwveG1wTU06SGlzdG9yeT4gPC9yZGY6RGVzY3Jp cHRpb24+IDwvcmRmOlJERj4gPC94OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJP RklMRQABAQAADEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElF QyBzUkdCAAAAAAAAAAAAAAABAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHw AAAAFGJrcHQAAAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQA AAJUAAAAcGRtZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1l YXMAAAQMAAAAJHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAI DHRleHQAAAAAQ29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNj AAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA 81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAA AAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93 d3cuaWVjLmNoAAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNj AAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAA AAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFla IAAAAAAATAlWAFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcg AAAAAENSVCBjdXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQA WQBeAGMAaABtAHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADl AOsA8AD2APsBAQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoB oQGpAbEBuQHBAckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKY AqICrAK2AsECywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD 4APsA/kEBgQTBCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVn BXcFhgWWBaYFtQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0H TwdhB3QHhgeZB6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5 CY8JpAm6Cc8J5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kM EgwqDEMMXAx1DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7u DwkPJQ9BD14Peg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYS RRJkEoQSoxLDEuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXg FgMWJhZJFmwWjxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0a BBoqGlEadxqeGsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5q HpQevh7pHxMfPh9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgj ZiOUI8Ij8CQfJE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSii KNQpBik4KWspnSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwu gi63Lu4vJC9aL5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSe NNg1EzVNNYc1wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07 azuqO+g8JzxlPKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJy QrVC90M6Q31DwEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBK N0p9SsRLDEtTS5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIx UnxSx1MTU19TqlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa 9VtFW5Vb5Vw1XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2Pr ZEBklGTpZT1lkmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBt uW4SbmtuxG8eb3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3Vnez eBF4bnjMeSp5iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCC koL0g1eDuoQdhICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Y jf+OZo7OjzaPnpAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZ kJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWp phqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuy wrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1 wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXO Ns62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK 3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr ++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3 /Af8mP0p/br+S/7c/23////uACFBZG9iZQBkQAAAAAEDABADAgMGAAAAAAAAAAAAAAAA/9sAhAAB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgICAgICAgICAgIDAwMD AwMDAwMDAQEBAQEBAQEBAQECAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwP/wgARCABRAEgDAREAAhEBAxEB/8QArgABAAICAwEAAAAAAAAAAAAAAAgJ BAoBAgcGAQEAAQMFAQAAAAAAAAAAAAAACAIGBwEEBQkKAxAAAgICAgIDAQEAAAAAAAAABgcFCAME EAkBAiAwUBESEQABBQEAAgIBAwUBAAAAAAADAQIEBQYHEggRFAAQIRUgMFATFiMSAAICAgEDAwIE AwkAAAAAAAECAwQRBRIhEwYAMQdBFBAgIjIwUFHwYXGBkUIzFQj/2gAMAwEBAhEDEQAAAIYdaHr8 AAAAAAAAAAAAAAAAAAAAAAAAAAAAA90sTHk7MDR5qflpMkDZJkj1Iy0uzCFaGNJeRqtvLthFgRjg rz8jfq7y4Gn3D88RuRzH6Csqv4dNKodWdnuzXJsPuNNfPOPurSphX6FQABmV7fDo3AAAAAA//9oA CAECAAEFAP22YUZg4GT5k3WJL8oMe1tvGLg0QSTEmpJibLplTFML4bdUmYwYleIuUw6O+lC2OiOB L+BSfGs+YQTq6yZR1Zp4v2J0jw6HgQmoKYxawgbSG7Aqj5e+TJl8/Z//2gAIAQMAAQUA/bapbmCA BJnDoZk1z2cNOYhNpzWQO1IBh95gNdIxf3fSzC93DeFMs2GMLXIKvQUNdhyPKjrh4/6sJfNuxug9 r8Wt09NrXAvoiYpbKWQJvd7r1kge7LveuouPMy7fy19XV1PT7P/aAAgBAQABBQD9utSx1HA77epy pNehHnoLr2NFkfVujKhsi4Gb1HOB3W3c3UzahK46q9UNoK8Fi467bm3cbB10n20Xaj4qV49KWdPV ap2YqF05ddcnJ126zOni3pC9bIQwHiqA6kS34obqDdxgGqF6oPluyMhJ5fs//9oACAECAgY/AP53 5Bv6rqL0UQWIkA4llZY0PE9G4s/MggghTkYz6Ni7uUj8XqsO/IK0AMje4gjPD9zDq7DPbQ5OGZAf x3+6vVI5YwyQJzUMAQO5J+4EZwYvXk/le41tabVWrDJUjwRxjgd4S5UBVHPtqVwTkZJxn15TU0bU K9OrLHhS0oRVlUvGgxCx5iMK0g9gXGGbOfWvilEE9+1ZaKKGFmZ2Cgs0uWRFWMAAksQVDAuF648c 8e1+z11eq9vv2i0kuUiiQgKCsLI8jNJ+hOQUsoYuFVmW54roKtejX1LLC6zswLSNyLNyjjkEjsV5 u/QNzVlJBGNntrE9QissjGNWcu6R5LMmYwOqgsqkhiMdAx4/idqcLaapJZz/AFkmz2P9QYV/tj0u 0nnY2hSeZSxJw02ft1GfYYaIYHTJJHv6ueTbGR5Lkyz23MjFmbivCMFieR5JEnHr/u6e/rat5NuD LtGixWEjAAB3zMkK9FUtxiPBRkqvQYU+vJPL/J/MGahYyIonJWOOPkGVVTk3ORBhE7agkFiQWkIH kPnDwdv7t7FwK3vwRe1AD/e8cMZwOnJzj39TrsbDSbaanHA7P+5pJgFmz/gpkIH0Ax+cNI5ZsYyS T0/z/i//2gAIAQMCBj8A/nfknkdR1XYQwhYSQDiaV1ijbichuDOHKkEEKcjGfRs395HF4lUcd+QV a4MjdCK8Z7f7mHV2Ge2hycMyBvx+MPj7x3d2qdox2NjZ7ErxMUJFarkxspIylvIPTIGOoPr4e+Ev AvLdvQ820urjs7uyXVjLZ2VevsErLK7yySfbm1KsvNU4twROQU4+GN78kReTbTf7mnZDyrDTkmll pTLDanbnehH2z2mlhqOP1utd+5FEVAPlFym2w13jGl1MV27fvRxQwQtM8ccdQCOaaWS0zOyhI0dZ HidIWlyhZdJrJ9tU8dp7Wr35ZIIxNaSTvJyp1lnLvHCgaeVrJrYIjQKZXjR/i8UK+y2PjO9oPYon XRQSMYY+1ymsizYpskkzykEFTJ3Y5kkSNk4+vEPCNZrd2r7iWrClmWGukMFi3wWOGfFp3HCR1imk RXjR+RDPGpk/FPC0LTaaPeVNQVHUpVoFf+yx/XhIt6X6D6E4Bb1L4brddCumPkNbXzLGiqWi14Ub SR+IAeTMNxuTDJUIrE8c+tF8QeKVIKmioza7RwR1Y0jhh70vftukSARoYp7k/cIUf8P6sgD14XD8 PeBJS8NivFts9WNmd2ggKa+e9IOUkixCW6O/MxVJJsMwaRc/EfwT8OfA0cXkuq4PcuwIktm3aMTR STSWBFH9vWnYtYnNmVkVliQOkdZS/wAWf+coNj92dHDq9E8kWe3355Tc2Tp9eEFq9ZQuwDduBeQA UAa6XxTVw1fBqG+t7KvHCMRxVNe8ktDj75DSpUVjn9Rct9fzmKpWjijJJIRQoJPucAAZP1Pv/F// 2gAIAQEBBj8A/wA3gcFZiMaktLUszQMAUoHPoaSDKurSOskLmFi/eiwFjtIxzXteZPFUd8fja+mx 02w6fpopm5ipLs9SYdTFXzAXU24f5NzfpQyorY4X+P25DVanyMZlZ+vfu0bbJ0GmrxTMzzDKt0FL AuYwJgAk1eyUQbKLJAI6AmUfi5iefi5yL+yp8+zntd2Lm3NdjynqfQbPLevuSFAlRBVOU5RptLzO w1MynhQaesrf+oFkIRYX1ynUoVKUvg4jfL2lyXDZPBOe43l+nyRYFPLvt5XUNTS7+jkX+PzkRa/n l4ddVByMWHPugqix45rQX+mRJa9XNwFZZjxW333Uui3GAwXOOdWtxeaO9jUNfZWVnt3ntKGhqKrH x4kIJXnlyAljAljJKHHRCIw+w0MDnmk3On5tsRZekrNHZvoMhYV3/Pz/AKu81cjPx4Vda304wq6G OqZbf7GvOVXtjiMUfsEa8n4fE7/kuxr8x0IHU7rSVkMN9Ypbuj5/IFyWX3USZVUNfUscxWFbG+lK ikAQ7C+adL6xf3vKDj5nA2F9NylRfaabf6DMYps2RZXufU+RhQTJY1tcWZAiyCR5UiP4I5gzvaD9 S9TKgq3UTeSbftwpD3IMc/XdIHIdyrzXy+R/crZediKqK5yqnkifKoz8jdRvLuyNqB8V1PTqGVZ2 MyWKJc9LLLfyGsrvsFeSurUDeUQkEJUY0ryEYiefx+a/2Z6LY2uj1+trOpew+jsddZz7W8vv4Ood m8VXzbixOaymCuc/ha5YrXFd8JOTwVFcv51OV7N9hkarp9hkxg4pC2NpFiQYEfR6AU3pee55Vv8A q1VXLtn01A9a+ANhTRoHy1jmAIrfZP2+9n/cKdPwfQ/5CFhcDpJ8yoymKyLLqNdVdLV5kttaLpdX nY7BVVayohjOURZJXDKee9ovYT3hl0i5tOs2nYPY2FU2yMbYuz+cpWYblNdPXycJZt/j+d1B0CJ7 g/asX+Cqr3OdeR+i6Cyv+t7Dj2K5RqLS/J52d1tenQa6m6Mh1Vo1YSNUT7kgho3/AM2R2s+ERPlP 6mnsp0ywOwTAMNNkmllaEfyowtId5HtExXL8NRfhPn9v7v8A/9k= --_008_0368F388C03BB34BBBFA73209849D47A4E290594ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=1675; creation-date="Mon, 31 Oct 2011 15:32:09 GMT"; modification-date="Mon, 31 Oct 2011 15:32:09 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAI0AAAIDAQAAAAAAAAAAAAAA AAMJBQYICgEAAQQDAQAAAAAAAAAAAAAABwECBQgABAYDEAABBAIABAUDBQAAAAAAAAAFAgMEBgEH ERITCAAiFBUWITIzQpVW1gkRAAIBAwIFAgMFCQAAAAAAAAECAxESBAUGACExIhNBB1FSFWEyIxQI cUKSU5PTJFTU/9oADAMBAAIRAxEAPwDu3a2HCltpkjghcgPe88Ek3PqEKMSi5/HOhMl7SNI5gyPr lpxxhvDyODiOZtSFqlfpMy9srokg6rbKSD8CUjZaj1AJoeRoQRxAjX4JBfBDLJAfuuGgUMPmUSTI 9p9CVAYdwqpBJPnWP4yY/etff3fxn0pv5qfwT/2eF+uD/Xl/qYv/AE8Dd2HCiNqkkQhceOY884k5 PqE2MNi4/JOmsCLSSI4gx/pl1xthzDKOLi+VtK1pT6TKe2N0aQ9FtlUk/AF41Wp9ASKnkKkgcIdf gjF88MscA+85eBgo+ZhHM72j1IU2juNFBIUF3p7f2DQOx2923VNuJ0W9wKhquKBtYPETJgI0ct1D BmHxDk2NLYiz3QJGSy0/yKXHU5haOC0pzg9+2Wg6TrnuNhaZrUK5OmSy5BeNq2vZDNIoahBIvVSR 0NKHkTxWX3B3Vqmge3ORqmiS+HU4oMUI/wAt8sEbEc+tjMAeo6ilOMY6B/2F13T9Ma6qu/Y3cNf9 yAAbwy+3YJr6kEx1nIsmCmRhRsk5sKuOEJS64uE3JfVBjrelNuLUnOVZUolbq/T5ruZuLLy9qjTc fbskoaCJ55FZFKLcpXwvaPJfaLjRSAPhxwe1/wBQmgw7exIt0y5cm4liInZIAUZg72kHyCv4dlxI FWr+0tAoPcTT97aNTtmi5NoqtsqlxdgxbOKwDPwnxGDgIqOMC0yZrMaZDKDHmldGRIYcSnC23XEK wrIP1za2obV3DJoOreMZ+PJHd42vQhgkisrUFQyMpFQCK0IB5cGDTN4adufbn1rSnZsDIgmtuUq3 bejBlJNCGVgaEg05EjjIO9K4Y3B2xGtc17KJB87QqDMEQVqSjJMgB+K2yMJZW6420iUWUK9OzlWc Y6rifHZ+32qYO3N8YWtaibcGOeRXb0RZUkhLnr2pfc32A8B73AwtR3HsDM0TSe/VJMWFok5d7RGK YRjoLpLCi86XMOFqac7itRaio8LW23+0qo3e0VSWTht2pdH0y5ZiMCSRkkGYtzY2OPH2JFgEuy3I vVW7IQ7Gaaxjp8nL4sluv243ruLWX1zau4Z8bS8lUYRefMEaMFCkwnHLRmNqBqALRix51rxWXZ3v ZsDbWiR7f3noOPJrWIXRpGxcJpXBdmHmGSgmEi1tNxbtC0pSnDU9f7XrV70S1Z6fVXaDWSVFuiQ1 OdEhgiQMYVBsMBcWKNralV9qA4+PW7HXD4x3mXEuJ+7Pir27NA1PQN0ZOl61OMvVIpUMkwd5PIXV HBLyfiFrWAYP3KQVPTi1e1t3aTujaMOs6DEcfSJ8ebxRWJEEVPIlFSMeMLVCVKdpUhh14r+JE6LD Fs1kS6crCQohVcJGbCiq2B2uODYzgBmyhY9YuQxg9EDKYalOxSDjMhxHVw2xleWURGP5jEDkFFmq agAsK150NVNCakVFR0qevDNQaBJgunpNLhWLYzOInstFgdLJQHC0DFXIYi6i1tFnWQ2h5fV1IP1+ RHH37YdR916fLjpep+Q6w935enw5Or+jhy+Xh424Bl+MflGyfy/p4lyvH9tviazr1t9evDZZcy// AC4cfz0FfPNh+Wnpd58fy9Ol3pSnLiEnyDUpJhm6iXgYBQMmqykgthi2o41V2xDzhhmpBUVimgXy cuvJdaguOEG4cfnS6lt7CEsr1Mn8wEYwkNlX9HDKb6/vliz8m5tUXHoSOo98RlfKt1RJIsTxm9o3 SU+KzuEKKkUdTHURkOEWoYBgAp//2Q== --_008_0368F388C03BB34BBBFA73209849D47A4E290594ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image003.jpg" Content-Description: image003.jpg Content-Disposition: inline; filename="image003.jpg"; size=1586; creation-date="Mon, 31 Oct 2011 15:32:10 GMT"; modification-date="Mon, 31 Oct 2011 15:32:10 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIgAAAIDAAAAAAAAAAAAAAAA AAkKBQYIAQACAwEAAAAAAAAAAAAAAAAGBwMECAUQAAAHAAEDAwMFAQAAAAAAAAECAwQFBgcIERIJ ACETMVEUYXEiJBUWEQACAQMCBQIEAwkBAAAAAAABAgMREgQhBQAxEwYHQVFxIjJSYUIUgZGxctJz 09QVFv/aAAwDAQACEQMRAD8AYitXnMyeMsEmyrFDgpuuouThCTE3oV0hZWWi+v8ATlXcLW8LvkbD lk0gBwi3NJrOU26if5BEFxUQTcOF4d3rJxUnllskZQSoRDSvpVpkJpyJtArWhIoSGT96YMUpjVQV HrcwP7hGwFfjX3odOK2fzv0FIhlFcypaaZA6mOpq+oEIUPuYxuLgFKH7+rY8K7sTQTkn+3H/ALHE J74whqUWn8z/AOLidp3nUx6cno1pP0utxlbO7TJPTVd0e4WCUho0fd3KNoawYbRYyWCMREXCzYJR B0o2TUFuRdcE0FK2d4a3zExnnSQtIqkhSirWnpVZnIryBtIrSpAqRLj964E0oQgBSdSGY0/YY1B+ Fa+1Tpwn6lZe1FABUAOjdD2E/ToHwkEPr+nrVMEFYUNPyj+Hx4T0mQVdh7E8H88IvGOp6XdNl2fb svl5yOy2o0WQzGKutOkwrFgcXdO3yTu0wSE7GoxNrcM4mrJJtDoi5SIV+Cnt3pGFHeZO5MjDxcTZ tly0RsiWUTmKUXp0yiiNyjFoxc7FgbSSlPRhwfdkbbHlTTZufEzLEiFAyG03XEstRRqBRSlef4jj AvkP5WQvI+55rZIHivP8T2cBRbVFp1mwwSNcdXVvJTDR+1sSTBCnU8B/zEm5kFQ7HPxqLCT5A6D3 GnY/bZ7f2vMxzukW6F3BLo/UEZCMChPUk51qNRUDl7cHft2G45cLpiNiAKRay2l6kGtLV5Up6/Hg YcpUb8m7MmlAomRMyiVEzDa6QmIkcw0e4AexSyFUJ1Bb6GAB+/pq4GLM+FE/TY1Qfb/Vwv8AcN3w 4s2SO/UN9r+wP2cN3eHnm1vOxY5oeZapVM8rkHxVynFaTk7mpKuFpWwR0ZSr5C/PeXBdAtTJw/BD PI0xjtUYlIx11xKXt7QRyb5m7IwO293xdxx2yTPu+VkySiRoyoJkiYiIKgKiszD5yx0XXnV1ePe6 pd9wZ8VhF08CGFVKq6kiyQfNedTSMfSBrX3HC6nLTmByg5/W7NL3tef5jW5ahUC0V+NQzSUYxkc4 j5puezSC8m3suqXV65eIOo8pEhQVSKCQdBIY38vWhth8f4HYe1Z2HtP6uSGVrmMzRMQVBQUsWMUo STUHXhX5Xex7m3HGkzekrqCAI0lA1F2t13qB7fjxrPV6/wCPB5eZ1zVNc2evVZV6qNXhnfHVC5PG VZAwhXif9LBco6ISUiTQ4ImjTPYlnLFjRQK+KLoFTDX7Ym8rLsmOr422uemPmfIdGOmtV/SyUatb rXK3Vt0pxHv8fj5t0kLy5SyXcliLafl1WZARSltVDW0u14JX4tYHAmsTyYDGNXtc4grC0ILga48f Z6qnZNixmpBGGiSN+TNyCTUVQM9FQpjNPjEhAAT94imnfOcndT5Gyf8ApYcSNhJP0ehMZATdjXX1 gitANlKXVq3Kmp74yTt5Ytx/4Mk7rZF1epGyUFs9ttZXqfrry9OddBkYxXvHaztdUcWbXdqsdRS/ BGyRDbjmhS3z6rCmmWeKexznKW+kiYssKKxpMzKLeyoxoLlYADoUjg5u7JvK77TlBcbbI3tbWPJe Qg68l/Sx1NfpqwW6l3y14AO3I/Hq7hCYpctm0oHiK6U11aZwPlrdRS1tbdeP/9k= --_008_0368F388C03BB34BBBFA73209849D47A4E290594ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image004.jpg" Content-Description: image004.jpg Content-Disposition: inline; filename="image004.jpg"; size=1696; creation-date="Mon, 31 Oct 2011 15:32:10 GMT"; modification-date="Mon, 31 Oct 2011 15:32:10 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIoAAAIDAQAAAAAAAAAAAAAA AAUGCAkKBwEAAwEBAAAAAAAAAAAAAAAABAYHBQgQAAEEAgEDAwEIAwAAAAAAAAMCBAUGAQcIERIW FBUJACFRoRMjJDRWltcZEQACAQMDAgQDBgcAAAAAAAABAgMRBAUSEwYhBwAxIhRBUUJSI5PUFRdh cdHSJKQW/9oADAMBAAIRAxEAPwDYRLfIbpFhIPGsfE2ywRwTESwsLCb07ERU6zRntRLw7W5bYq1i JDO1JVls5MwAN2HGDgyRuQRV1Sz7PcuvLZLikaFhUqUuWZT9ljFbyJqH1AOSp9LUYECRX/ezhVhd vas7voNNQktVVh5alEtzG+k/SxQBh6lqpBI//oxp3+pXX/LuO3++Pon9luXfOH8O8/KeA/344P8A OX8ax/OeCEV8hmkX8g0ayEVa69HFMNEhYJCb07LxcE0WrCFy0w0pu2LTYhw7Rak5dOQsDjZhzk58 jbjKUYt52f5dZ2z3FI5CoqFVLlWY/ZUyW8aaj9ILgsfStWIBMsO9nCb+7S0V3TWaajJasqj7TCK5 kfSPqYIQo9TUUFhnd4kS8ZZN5aVrktqF9vtjKokGmNUx0nU411YSxmtbBNAdoNebHVKi5HWWkIR7 6Z/INxHSDCUd5khGvsPny3Fpwa8u7XIriZI0iPuSspCBpo0K/cRyyjcLhdUaMRXrRSxHFHbqO1vO 4FlbXuLOYjkkmHtQ0IMhSGVw3+RJFC20qF9MkighelWCg9JY8eeR25LFs2zaU4z2ePo0ZunaVABV 03/TfWhzlMt8tCTtGMeT2Wx9SKrSbIrX1TbBov7MDauTgSMq8xeecN41jrHH8nzUUmVbG205l2Lv 79JoleOb025oZFYNpakvxkRWJA037cc15Tk8hkuK4GWLDrlLqAQ+4sxsPDKySQnVcrURspXUtYvI RuyaWMatntbvrGXtlD2RVpulXCGinw5WvTwgCdiA/jHXp3TZ0zcO4yVipAPfgLtm4cND4SvCCK7V Yw6Y6+xWexQyuGuI7nGyK2l0rSq+YIYBlZTSquqsOlR1HhFyeJy/HcwcTm7aS1ykTLqR6VAY9GVl LK6sK0dGZT1oeh8OvxXy+JDnrxtYd3XLRpe3vT7sK477AHjOcdc9P5/4/Sl3mQjs9kpPnHaj/dtv 6eKV2aWJO8+MiU+pZLo0/nYXP93iwrfuy9laM+Pzl3dtW3OwUCzZ+Rvki3VZK24SxlxRE5yTtQnz drI5Es7BDteUDWUChF6dUJXjuzjMt4phMNybuxx/G5y2iu7L/j8eduQakLJj4ipK1o1Opoaj406e KlyvNZjjPaXkOSwV1NZ3p5lkRuxnS4V8jKGAahK16AlaH4AiviPXzFzEgS1cUZ2YKo8zZuLU+SYf EEgJpCRbYiZZyQ2BoEjKhuZExMIxjCR5MrpjHdnqy9hYY4sHyS2txS3hy1EFahVKSKKefwUCvxoP Onhc79arrkHGbi6NbqfDksxFCzBkc1p/Ek0+FTTz8Uw2DIWu0zA43p3lOAS2GuiydfWqq7TLWiwg ys20nB1FFxdgnWFYWgEmePkCN3eBkPkTZBFtx3bBtkzxiI8qTEKmkbgmctDXV0JMiKmkv1QOtVqq 1YgMYVygYIcslHGmzjXPTSbZUWWm2OgVWZw4joJTGxVqM1FUlQDnnG6/GpfyuH5G+E+/u/IfJ7JP +F+X+5K9x9/94qvj3l3vPd6j1X7/ANX1/M/V6/WxbGx93H7JcF+o7Q29thvbOn06NC7mzppp0+jT Snp8LtxX2knvDyb9O3TubgTZ3dXq3NZ297XXVq+81V1da+G+GzLurpUg8mU8jYOlKi5NeJK0LkrV aB0kTBRbA21nB3NFOYncv4hCgNDpkBsGhyDOoTnI0NyYWba7GBvDxJMI139YhcKu5XoZjEjdQerB l1sAQCtSwaOMDFHkdoOTtyBYtDbZuVDejQdQhV2WtVqEIYRqxDENQKf/2Q== --_008_0368F388C03BB34BBBFA73209849D47A4E290594ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image005.jpg" Content-Description: image005.jpg Content-Disposition: inline; filename="image005.jpg"; size=1656; creation-date="Mon, 31 Oct 2011 15:32:10 GMT"; modification-date="Mon, 31 Oct 2011 15:32:10 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIwAAQEAAwAAAAAAAAAAAAAA AAkIAwUKAQABBAMBAAAAAAAAAAAAAAAEAAMGBwEFCAkQAAEEAgEDBQADAQAAAAAAAAUDBAYHAQII ExQVABESFglCIyYXEQACAQIDBQQIBAcAAAAAAAABAgMRBAASBSETFAYHMUEiMlFhgZEzFRYIwUJi 0nGhsYLCIyT/2gAMAwEAAhEDEQA/AO5YldcXF6AnTto5bjJYeHRiFlSUirqOtZqcM4WyDGRVvKZw DKl3x7DVXZgho3wu+TTyqhoolnXfZ0xEeYgH2/gKYYE+byKxH9u317SDT2YzRu4BEyBsJPEAr2Vx or3Xi5DG5bUpwGS7F44HvewLC7IdMHnZv2ayCvTU26ayW+m3ttrtjC3X6h7m/bhGanare9f3Y2ri x0R6W7wxFZGIFNsdUkXcPYS9aCWeMf2kiCASYlSmo9t74ysqm3Vwgn7qKfFLTffXO5J7CCf4H8QB hcQo2sCF9NVNPcxNPZs7ezBE/pAFfSv81btJxlA1vPqlpYJe1RrRUa4LSkdaVNjRUyhu8VYsW7sg oXerMVR+MNk919mzxXTTGc7eip02Mw7QSf54BtpAGQHYCAPZTA+2BPOUXGuaXfTdNSTlQKh9H1bH BkJj0Shs5dQVlRwCu+CpeNzuNtw0QfAH04k9ryyzPILD11zj9TL9JwjlJFPOBjVWKiuweju2bf64 NVkkCsctSfT622e6mGv4R2nN7O4UfeLIIzMvIj8l5e7JvLDEmQMpXhrLkHeIuukSAaRjQ5scxb1y zFosUnLZFTUfojj2zj2zkmEZgrbfN/lgK5YKWQUpl9P6RXAg8d7+sGxDfJ+V3ZZXJA/rU/FKxeS8 QC1TyfsmgwQnanQMTd5gjIRBNVRzYYdaSZBJN5hLKrHDP5bJud1t9teTtH5o1vXL7VrzW7rUXMFp cXSJBeTW0Y3LfCCReEKwYANSoy1IYknHvlzr0a6cdPOR+neidN9A5Ktm1bmTStCubnVOW9O1u6l+ YiUG/kuL0b1pYWgd2jzhZTLlVoUjVTWA/i3ymZRC0gBP9CL31s5GexyMUqWb3PfbaINDzHE7MSyO yUU1k7nfdzMwIHVFkV31xgWq3U3U13yvjX1JF5b5sFrcxy69fnUTIiQNxFyEBGdnRwJDXOoAVuxC CSDXFT3HW77fn17Rb2y6TcpLyatjcT6pCdH0M3LK/CxW9xbSNaqF4WaVnmgU1uVdVVlEdcRxyJe8 zOHlvREGc5m2Lb5QrD5BIiTQjY04koRNYG4kEYkUTl0Tl8iPNng57kTndksvqmu5HOE1tU2iuPjp FdXv+eOSNaswdYubpyVejSyvH4ZMjxyRyOwKt3EipU5gFbFz8m6J9sP3JdJOY7q06caDoMMIa3WW LT7C3ugJrdJ7e6tby0t4JI5Y89JEVmSOaMxs08ZJaLlsytrKuRyHFvSyTtda8WLd3s0mbUq6JydX iGsGiCtkNZWClKUzYoHx8f3DIPF40RUNPFk8rsEW2yizdIC2SPjtS+nJJOF4W43u8jjzcNUb0bZD XbTatHPcB2Y2Ak1k8m8nHq1DpK331Np3ywJNqLL86DT8CQ1tAtY2bflFuFECqcszPRWKJmnP7Ud2 b8kGMdx9OT6/aSXgH5D4+ElPa4AYHRP7F/1vtvK9Lsv9L1up/D4+rCdeo9WzPH5O5LWvlNMv+yu8 81KeOte7HLFpJ9o+WLdRQZeL/NLzTk+LFm3tYd3wVdzmzf8APky/mxI905ud1f0FQ55anwam0MN7 lydcb0BKpKlFkTkpVspr4KotIbGF7kISPQwgUXkBFMozLKZXdIuemk3Uh+vJc/PLT6xkPd8GOGtN 54wcktBJvK7wtVwe4jF58hyWo6Sa6ft9hsjp3EpvRdTauPEYYhamNr+BnFitvujAtupiaAZUZGJc f//Z --_008_0368F388C03BB34BBBFA73209849D47A4E290594ITREXMBXVS2itro_--