From rodolfo@ubilogix.com Wed Sep 1 17:16:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 795813A68E2 for ; Wed, 1 Sep 2010 17:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.205 X-Spam-Level: ** X-Spam-Status: No, score=2.205 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_20=-0.74, J_CHICKENPOX_45=0.6, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-wjFf4Ap9zY for ; Wed, 1 Sep 2010 17:16:33 -0700 (PDT) Received: from dpmailmta03.doteasy.com (dpmailmta03-07.doteasy.com [65.61.218.47]) by core3.amsl.com (Postfix) with ESMTP id 6BD1D3A6814 for ; Wed, 1 Sep 2010 17:16:33 -0700 (PDT) Received: from dpmail31pro.doteasy.com ([192.168.101.31]) by dpmailrp06.doteasy.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o820Gr3A011197; Wed, 1 Sep 2010 17:16:53 -0700 Received: from 201.143.85.27.dsl.dyn.telnor.net [201.143.85.27] by dpmail31pro.doteasy.com with SMTP; Wed, 1 Sep 2010 17:16:40 -0700 Message-ID: <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> From: "Rodolfo Gonzalez Bernaldez" To: "Alexandru Petrescu" , "Robert Cragie" References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> In-Reply-To: <4C7D6ACF.6040109@gmail.com> Date: Wed, 1 Sep 2010 17:16:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: No geolocation information available for 192.168.101.31 X-CanItPRO-Stream: base:default X-Canit-Stats-ID: 01D1AgRk6 - 5f499dc73783 X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.101.86 X-Originating-IP: 192.168.101.86 Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 02 Sep 2010 00:16:35 -0000 Hello Alex, all My comments in message bracket by -------------------------------------------------- From: "Alexandru Petrescu" Sent: Tuesday, August 31, 2010 1:49 PM To: "Rodolfo Gonzalez Bernaldez" Cc: "Michael Richardson" ; "ROLL WG" Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit > Le 31/08/2010 02:39, Rodolfo Gonzalez Bernaldez a écrit : >> Hello Alex, all >> >> My comments in message bracket by >> >> Best regards >> Rodolfo. >> >> -------------------------------------------------- >> From: "Alexandru Petrescu" >> Sent: Sunday, August 29, 2010 10:45 AM >> To: "Rodolfo Gonzalez Bernaldez" >> Cc: "Michael Richardson" ; "ROLL WG" >> Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit >> >>> Le 28/08/2010 00:50, Rodolfo Gonzalez Bernaldez a écrit : >>>> Hello Alex, all >>>> >>>> CCM* and IPSEC, both provide data authentication and encryption and >>>> it's that what we are looking for >>> >>> [sidenote to clarify terminology as I read: one would compare CCM* to >>> AH (for authentication) and to ESP (for enc + auth). IPsec is more >>> than just these two, often comprising IKE (key generation), databases, >>> rules, policies, firewalls, and more - these are not covered by CCM* >>> but IPsec does.] >>> >> >> Yes I agree, I don't specify clearly my idea here. I was thought >> only in authentication and encryption of the packet, for these reasons I >> focused only in that two features. By the way the zigbeeIP group is >> working on PANA and EAP, in case you are interested >> >>>> Using the security level 5, 6, or 7, you can define the number of >>>> bytes for clear text. >>>> >>>> In CCM* using the security level 5, 6 or 7 may have the next form for >>>> data: A) encrypted data : MAC B) clear text : MAC C) clear text - >>>> encrypted data : MAC >>>> >>>> For example using CCM* level 6 on the next data and an input with 8 >>>> cleartext header octets AES Key = C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB >>>> CC CD CE CF Nonce = 00 00 00 03 02 01 00 A0 A1 A2 A3 A4 A5 Data= 00 >>>> 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 >>>> 18 19 1A 1B 1C 1D 1E we get the next result: CCM* level 6 Data= 00 01 >>>> 02 03 04 05 06 07 58 8C 97 9A 61 C6 63 D2 F0 66 D0 C2 C0 F9 89 80 6D >>>> 5F 6B 61 DA C3 84 17 E8 D1 2C FD F9 26 E0 As you see the first 8 >>>> bytes were unchanged, but were used to create the CBC-MAC. For more >>>> details see rfc3610 packet vector #1 >>>> >>>> With this in mind, lest to suppose that we have the next IPv6 >>>> packet: FF 01 02 03 44 55 66 77 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 >>>> 14 15 16 17 18 19 1A 1B 1C 1D 1E and the byte cero is one of the >>>> mutable fields (e.g. the Hop limit) and the byte 4,5,6, and 7 are a >>>> mutable field but predictable and the predictable values are for byte >>>> 4 = 04, byte 5 = 05, byte 6 = 06 and byte 7 = 07, so now following >>>> the rules of RFC4302 our packet will change to: 00 01 02 03 04 05 06 >>>> 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D >>>> 1E Now lest to use CCM* level 6, the result is the next: 00 01 02 03 >>>> 04 05 06 07 58 8C 97 9A 61 C6 63 D2 F0 66 D0 C2 C0 F9 89 80 6D 5F 6B >>>> 61 DA C3 84 17 E8 D1 2C FD F9 26 E0 >>>> >>>> And the destination node knowing the rules of RFC4302, just needs to >>>> apply the same rules and set the ceros for mutable fields and the >>>> corresponding values for the mutable but predictable fields. >>> >>> That sounds right. Provided the Hop Limit mutable field is set to 0 at >>> MAC computing time by sender, and also by receiver. Your example seems >>> to say so. I agree with it. >>> >>>> The only issue that I see at this moment is were to put the CBC-MAC >>>> data, >>> >>> I agree, that is a right question: where to put the CBC-MAC data? >>> >>>> for example here we have 64 bit of CBC-MAC, we can just leave them at >>>> the end of the packet or maybe create a field at the end of each RPL >>>> frame with security with the name CBC-MAC or something like that. >>> >>> I propose to put the CBC-MAC data in the Authentication Header - the >>> Integrity Check Value (ICV) field of a typical Authentication Header >>> rfc4302, instead of putting it as a field in the RPL header. >>> What do you think about this? Interested people? >>> >> >> >> The only issue that I see with the AH, is the size of the AH header, is >> a big header. >> But if we are talked of MAC security (IEEE 802.15.4-2006-MAC) lest just >> to leave the MIC (CBC-MAC) as is defined by the standard, and the MIC is >> just another field of the MAC frame like the field MFR. What do you >> think about this?. >> > > MAkes sense, one would like to avoid long additional data. Because we are talking about 6LoWPAN and the link-layer used at this moment is IEEE 802.15.4, it worth mentioning that RPL-ROLL is a draft at date, so is not bad idea to leave some bytes free, that is why, yes I think that make sense > > Any more detail of comparison on length you would like to share? > > How long is a "big" header such as AH? And "big" compared to what? Is it > much bigger than the mandatory IPv6 base header? I think that is a "big" header because in the worse case, the link-layer 802.15.4 only gives 81 bytes for IPv6 data. How much bigger than the mandatory IPv6? We are in 6LoWPAN and an IPv6 header using IPHC can be as small as 3 bytes. > > How much additional AH header bytes are added to an RPL (IPv6 base + RPL > ICMP) compared to putting the CBC-MAC in the same packet, as an RPL field. > I think that delta is 96bits (the AH specific fields, figure 1 rfc4302). > This is much shorter than the potentially multiple 128bits of each IPv6 > address potentially in a ROuting Header of RPL. Why a node routing an IPv6 packet will apply security (in this case CCM*) over this packet? Only one CBC-MAC is put on the packet and only one, the originator node of the packet will insert the CBC-MAC, and the nodes routing the packet will modify the IPv6 header for the mutable fields, once the node destiny is reached this will set the mutable fields as rfc4302 and apply ccm* to decrypt. > > There may be certain advantages of AH specific fields: SPI, seqno field. > SPI (Security parm index) helps interoperate with existing databases in > existing firewalls. seqno helps with replay protection. Does CBC-MAC per > se offer replay protection? May be Robert Cragie could show us some alternative options for these purposes > > Reusing AH could help an RPL node to talk to a non-RPL node, > authenticated. > Sorry but I don't understand this part > (for same reusability reasons for which RPL is an ICMP header...) > > Alex > >>> This is a central issue to clarify. Depending on this we can see >>> further. >>> >>> Alex >>> >>>> >>>> The other option is to create a AH for RPL designed for CCM* (I don't >>>> like this idea, because the IEEE 802.15.4-2006 frame already have an >>>> auxiliary security header), or make modifications to IPSEC to >>>> support CCM*. >>>> >>>> Sorry for the long email, comments are welcome. >>>> >>>> Best regards Rodolfo. >>>> >>>> -------------------------------------------------- From: "Alexandru >>>> Petrescu" Sent: Friday, August 27, >>>> 2010 12:34 AM To: "Rodolfo Gonzalez Bernaldez" >>>> Cc: "Michael Richardson" ; >>>> "ROLL WG" Subject: Re: [Roll] Messg Auth Code >>>> covering the mutable IP Hop Limit >>>> >>>>> Le 27/08/2010 00:08, Rodolfo Gonzalez Bernaldez a écrit : >>>>>> Hello Michael, Alex, all >>>>>> >>>>>> >>>>>>> For example, one wouldn't appreciate to have both AH protection >>>>>>> of the entire packet _and_ RPL CCM protection. It is >>>>>>> redundant. >>>>>> >>>>>> >>>>>> Yes I agree, that it is redundant. >>>>>> >>>>>> I was checking the RFC4302 section 3.3.3.1. Handling Mutable >>>>>> Fields, >>>>> >>>>> I think that is the right section to think of. >>>>> >>>>>> and I didn't see any problem to use these rules only with CCM*. >>>>> >>>>> Well, depends how we refer to it. Intuitively, it may be easy >>>>> indeed to apply that "rfc4302 mutable field" rules to CCM*. >>>>> >>>>> However, this may introduce new misunderstandings too. Because >>>>> that section explicitely says "IPsec": >>>>>> [...] If a field is mutable, but its value at the (IPsec) >>>>>> receiver is predictable, then [...] >>>>> >>>>> Here we don't have IPsec receivers, we have CCM* receivers - they >>>>> are very different: CCM* MAC is present in ICMP headers, whereas >>>>> IPsec ICV is present in Authentication Header. >>>>> >>>>> Thus, will that rfc4302 "If" rule apply here or not? If not, then >>>>> we don't know what to do here with CCM* and mutable-but-predictable >>>>> fields. We would have to specify what CCM* does with them, couldn't >>>>> simply refer to rfc4302. >>>>> >>>>> There are several mentionings of "IPsec" in that section, and here >>>>> we don't currently do IPsec. >>>>> >>>>> To solve that, it may lead to copy&paste that section into RPL doc >>>>> and substitute "CCM* MAC" for "ICV", "RPL" for "IPsec", remove >>>>> IPv4, etc. Suddenly that sounds not as a simple straight referral >>>>> to rfc4302. >>>>> >>>>> It may lead to rewriting IPsec specs altogether. >>>>> >>>>>> What do you think of the following statements in the security >>>>>> section: -Any IPv6 frame with security must be prepared as >>>>>> RFC4302 section 3.3.3.1 specified for mutable fields >>>>> >>>>> Ok, sounds good as first step, for mutable fields. >>>>> >>>>> How about the "Mutable but Predictable Fields", i.e. dst address >>>>> in presence of a Routing Header. MAC should cover them too, >>>>> especially knowing that a new Routing Header is under discussion in >>>>> 6MAN WG, for RPL. >>>>> >>>>>> -ccm* computation must take IPv6 header, and/or IPv6 extension >>>>>> headers as clear text, the rest of the packet must be encrypted >>>>> >>>>> I kind of understand and I can agree. >>>>> >>>>> However, will the rest of the packet (encrypted) be also applied >>>>> authentication, or just leave it encrypted. This should be >>>>> clarified one way or another, so implementer knows what to >>>>> implement. This again risks leading to rewriting IPsec >>>>> specifications. >>>>> >>>>> At which point I wonder why all the effort? Wouldn't it be easier >>>>> to identify what's the real core of the RPL security - is it CCM* >>>>> only? If yes - could we use CCM* with IPsec Authentication Header? >>>>> That may be simpler to spec and implement, rather than carrying new >>>>> MAC fields in ICMP. >>>>> >>>>>> Using these two rules statements we would be following the rules >>>>>> of RFC4302, providing authentication for the entire IPv6 frame, >>>>>> and we keeping encrypted RPL data. >>>>> >>>>> Yes, that is one possible way of doing it. >>>>> >>>>> I just wanted to mention that here we have a context: a number of >>>>> IPv6 fields, extension headers and other standards are present - we >>>>> should consider them all. >>>>> >>>>> Alex >>>>> >>>>>> >>>>>> Best regards Rodolfo. >>>>>> -------------------------------------------------- From: >>>>>> "Alexandru Petrescu" Sent: >>>>>> Thursday, August 26, 2010 7:42 AM To: "Michael Richardson" >>>>>> Cc: "Rodolfo Gonzalez Bernaldez" >>>>>> ; "ROLL WG" Subject: Re: >>>>>> [Roll] Messg Auth Code covering the mutable IP Hop Limit >>>>>> >>>>>>> Le 26/08/2010 15:31, Michael Richardson a écrit : >>>>>>>>>>>>> "Alexandru" == Alexandru >>>>>>>>>>>>> Petrescu writes: >>>>>>>> Alexandru> On another hand, risks do exist in the base >>>>>>>> header Alexandru> (spoofing the src address is one widely >>>>>>>> known). It is >>>>>>> >>>> >>>> >>> >>> >> >> > From rodolfo@ubilogix.com Wed Sep 1 17:16:39 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 333213A6A30 for ; Wed, 1 Sep 2010 17:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.136 X-Spam-Level: ** X-Spam-Status: No, score=2.136 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_50=0.001, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArrKTcweIAgw for ; Wed, 1 Sep 2010 17:16:38 -0700 (PDT) Received: from dpmailmta03.doteasy.com (dpmailmta03-07.doteasy.com [65.61.218.47]) by core3.amsl.com (Postfix) with ESMTP id EAC693A6A2E for ; Wed, 1 Sep 2010 17:16:37 -0700 (PDT) Received: from dpmail31pro.doteasy.com ([192.168.101.31]) by dpmailrp06.doteasy.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o820GxlL011220; Wed, 1 Sep 2010 17:16:59 -0700 Received: from 201.143.85.27.dsl.dyn.telnor.net [201.143.85.27] by dpmail31pro.doteasy.com with SMTP; Wed, 1 Sep 2010 17:16:48 -0700 Message-ID: <8A2FA3C50EC246D7AA6C415F501D8D9C@ubilogixrodo> From: "Rodolfo Gonzalez Bernaldez" To: "Alexandru Petrescu" , References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D2596.3090108@gridmerge.com> <4C7D6B9A.6050108@gmail.com> In-Reply-To: <4C7D6B9A.6050108@gmail.com> Date: Wed, 1 Sep 2010 17:16:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: No geolocation information available for 192.168.101.31 X-CanItPRO-Stream: base:default X-Canit-Stats-ID: 01D1AgXka - 44b2761bc729 X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.101.86 X-Originating-IP: 192.168.101.86 Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 02 Sep 2010 00:16:39 -0000 -------------------------------------------------- From: "Alexandru Petrescu" Sent: Tuesday, August 31, 2010 1:52 PM To: Cc: "Rodolfo Gonzalez Bernaldez" ; "ROLL WG" Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit > Le 31/08/2010 17:53, Robert Cragie a écrit : >> Hi Rodolfo, >> >> I agree about treatment of mutable fields. Setting them to 0 for MAC >> calculation is an acceptable way of doing it although it is a little >> clumsy for inline packet security processing (done by certain >> devices). The alternative would be to elide the fields completely but >> this is probably more work in practice. >> >>> That sounds right. Provided the Hop Limit mutable field is set to 0 >>> at MAC computing time by sender, and also by receiver. Your example >>> seems to say so. I agree with it. >>> >>>> The only issue that I see at this moment is were to put the >>>> CBC-MAC data, >>> >>> I agree, that is a right question: where to put the CBC-MAC data? >>> >>>> for example here we have 64 bit of CBC-MAC, we can just leave >>>> them at the end of the packet or maybe create a field at the end >>>> of each RPL frame with security with the name CBC-MAC or >>>> something like that. >>> >>> I propose to put the CBC-MAC data in the Authentication Header - >>> the Integrity Check Value (ICV) field of a typical Authentication >>> Header rfc4302, instead of putting it as a field in the RPL >>> header. What do you think about this? Interested people? >>> >> >> The only issue that I see with the AH, is the size of the AH >> header, is a big header. But if we are talked of MAC security (IEEE >> 802.15.4-2006-MAC) lest just to leave the MIC (CBC-MAC) as is defined >> by the standard, and the MIC is just another field of the MAC frame >> like the field MFR. What do you think about this?. >> >> AES-CCM (SP 800-38C) specifies concatenation of the encrypted MAC >> (MIC, schmac, schmic :-) at the end of the payload. I would keep it >> there. It makes the MPDU larger. If doing it like this, it should be >> shown on Figure 7, appended after the options. > > I think it would be good to agree whether encryption is absolutely > needed in RPL or considered as luxury, assuming that encryption would > take more computing power than very simple authentication. > Yes I agree we still need to define when the use of security is mandatory or optional. I'm not sure what you mean? I quote, "assuming that encryption would take more computing power than very simple authentication", if we handled the CBC-MAC as is defined be the standard, at the transceiver IEEE 802.15.4-2006 with hardware security support could do this without draining to much power from the battery. > About placement: would an MPDU with MAC at its end be understood by a > non-RPL node at the other end of the Internet (but running IPsec)? Do you mean a secured IEEE 802.15.4-2006 MPDU?, if so, why a edge router would sent IEEE 802.15.4 frame (MHR-MACpayload-MFR) to internet? > > Alex > >> >> Robert >> >> Robert Cragie (Pacific Gas & Electric) >> >> Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 >> 1924 910888 +1 415 513 0064 http://www.gridmerge.com >> >> >> > From robert.cragie@gridmerge.com Thu Sep 2 08:55:19 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EDE43A6783 for ; Thu, 2 Sep 2010 08:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.618 X-Spam-Level: X-Spam-Status: No, score=-3.618 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OF+PMeG8LXj2 for ; Thu, 2 Sep 2010 08:55:17 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id C1A663A65A5 for ; Thu, 2 Sep 2010 08:55:16 -0700 (PDT) Received: from client-86-23-94-106.brhm.adsl.virginmedia.com ([86.23.94.106] helo=[192.168.1.66]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1OrC8e-0006us-Th for roll@ietf.org; Thu, 02 Sep 2010 16:55:45 +0100 Message-ID: <4C7FC901.4050204@gridmerge.com> Date: Thu, 02 Sep 2010 16:55:45 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: ROLL WG References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D2596.3090108@gridmerge.com> <4C7D6B9A.6050108@gmail.com> In-Reply-To: <4C7D6B9A.6050108@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020409020407090505040102" Subject: [Roll] Current RPL security concerns X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 15:55:19 -0000 This is a cryptographically signed message in MIME format. --------------ms020409020407090505040102 Content-Type: multipart/alternative; boundary="------------020503080902090200080003" This is a multi-part message in MIME format. --------------020503080902090200080003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable The previous thread was getting a little difficult to follow so I=20 wanted to list the current concerns with RPL security as I see them and=20 get the ball rolling on how we deal with it. Let me know if I haven't=20 summarized correctly or missed anything. Current concerns: 1. Placement of the MAC field 2. Order of processing for checksum and MAC 3. Setting of mutable fields 4. Use of AH instead of RPL security 5. Whether encryption is needed or not _Placement of the MAC field_ AES-CCM concatenates the MAC at the end of the secured data. This is not = particularly clear from the specification. The secured RPL control=20 message could be shown as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= | Type | Code | Checksum |= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= | |= . Security .= . .= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= | |= . Base .= . .= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= | |= . Option(s) .= . .= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= | |= . MAC .= . .= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= Figure 7: Secure RPL Control Message Similar consideration should be given to the signature field. _Order of processing for checksum and MAC_ Given the above packet format, the ICMPv6 checksum needs to be=20 calculated first on the whole packet according to RFC 4443, with the MAC = field set to 0. At this point the packet is ready for security processing= =2E _Setting of mutable fields_ Security processing would involve setting the mutable fields to 0 then=20 running the AES-CCM process according to the level on the packet,=20 excluding the MAC field. The resulting MAC is then placed in the MAC fiel= d. _Use of AH instead of RPL security_ The use if AH (transport mode) would indeed be possible if it is deemed=20 that encryption is not necessary. However, the additional paraphernalia=20 of IPSec needs to be considered too - the security parameters, secure=20 association etc. What is currently specified in RPL is equivalent and=20 self-contained. Replay protection is supported through the use of=20 monotonically increasing or time-based counters. _Whether encryption is needed or not_ The way the spec. is currently written does not mandate encryption as it = can be set in the Security Section.Security Control Field.Level field. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com --------------020503080902090200080003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The previous thread was getting a little difficult to follow so I wanted to list the current concerns with RPL security as I see them and get the ball rolling on how we deal with it. Let me know if I haven't summarized correctly or missed anything.

Current concerns:

  1. Placement of the MAC field
  2. Order of processing for checksum and MAC
  3. Setting of mutable fields
  4. Use of AH instead of RPL security
  5. Whether encryption is needed or not

Placement of the MAC field

AES-CCM concatenates the MAC at the end of the secured data. This is not particularly clear from the specification. The secured RPL control message could be shown as follows:

        0   &nb= sp;           &nbs= p;   1         &nb= sp;         2           =         3
        0 1 2 3 4 5 6 7 8 9 0 1 = 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        |     Type=       |     Code  =     |         = ; Checksum          = ;   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        |           =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   |
       .     = ;            =           Security          = ;            =       .
       .           =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        |           =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   |
       .     = ;            =             Base          &nb= sp;           &nbs= p;       .
       .           =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        |           =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   |
       .     = ;            =           Option(s)         &nbs= p;            = ;     .
       .           =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        |           =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   |
       .     = ;            =              MAC          &nbs= p;            = ;       .
       .           =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           &= nbsp;       Figure 7: Secure RPL Control Me= ssage

Similar consideration should be given to the signature field.

Order of processing for checksum and MAC

Given the above packet format, the ICMPv6 checksum needs to be calculated first on the whole packet according to RFC 4443, with the MAC field set to 0. At this point the packet is ready for security processing.

Setting of mutable fields

Security processing would involve setting the mutable fields to 0 then running the AES-CCM process according to the level on the packet, excluding the MAC field. The resulting MAC is then placed in the MAC field.

Use of AH instead of RPL security

The use if AH (transport mode) would indeed be possible if it is deemed that encryption is not necessary. However, the additional paraphernalia of IPSec needs to be considered too - the security parameters, secure association etc. What is currently specified in RPL is equivalent and self-contained. Replay protection is supported through the use of monotonically increasing or time-based counters.
Whether encryption is needed or not

The way the spec. is currently written does not mandate encryption as it can be set in the Security Section.Security Control Field.Level field.

Robert

Robert Cragie (Pacific Gas & Electric)

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


--------------020503080902090200080003-- --------------ms020409020407090505040102 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwOTAyMTU1NTQ1WjAjBgkqhkiG9w0BCQQxFgQU1B3R 72BPLSEbZwRG/07qVMS1XzkwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEArFn3EcXxdSdFnkzctN0AcBGABWXNROsGDnp1 OJ2wzug9c2sf9JYFfwsvcbF4DxvHgi/2mWo76Cufig6lsFuEWmBI7+a5nr6gFEsd9WwOMGBC 1wDLp9OQrXQbLi6tj4TVSRWSkLFuIVZgMAjXy9Z21onk+OZimDci8Fk+56NmS55RSQhVYv6y OttJnyBVyB9qBEQd7/hX9mvM+oFbUWegyXEbbuElL7vd4AefSmmQ0DbyPujanXuq7FW/CU0a Ya/ADWSW/RIllq89cZdUCa2VDb3bRIO729RRCEaavsI6iOyiCdpNaE9Cynm92+9XYEBQqRqi YJRsKHhYDcyccdHySwAAAAAAAA== --------------ms020409020407090505040102-- From robert.cragie@gridmerge.com Thu Sep 2 08:55:57 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41EEC3A6948 for ; Thu, 2 Sep 2010 08:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.614 X-Spam-Level: X-Spam-Status: No, score=-3.614 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcI4Bif6jooU for ; Thu, 2 Sep 2010 08:55:56 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 8F9663A6783 for ; Thu, 2 Sep 2010 08:55:55 -0700 (PDT) Received: from client-86-23-94-106.brhm.adsl.virginmedia.com ([86.23.94.106] helo=[192.168.1.66]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1OrC9I-0007Tg-Hs for roll@ietf.org; Thu, 02 Sep 2010 16:56:25 +0100 Message-ID: <4C7FC929.4060301@gridmerge.com> Date: Thu, 02 Sep 2010 16:56:25 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: ROLL WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080209030706030205040105" Subject: [Roll] AES-CCM not AES-CCM* X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 15:55:57 -0000 This is a cryptographically signed message in MIME format. --------------ms080209030706030205040105 Content-Type: multipart/alternative; boundary="------------080003020801080508050803" This is a multi-part message in MIME format. --------------080003020801080508050803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I think we should be specifying AES-CCM not AES-CCM* in the RPL=20 specification. There is some IPR surrounding AES-CCM* (US 2005/0154882), = plus only AES-CCM itself is referenced in FIPS 140-2. The only real difference between AES-CCM* and AES-CCM is the encrypt=20 only mode, which is illegal in AES-CCM. However, encrypt only is not=20 used in RPL. Authentication only can be achieved in AES-CCM by setting=20 the A data to the header concatenated with the payload and the payload=20 to be encrypted to the null string and Plen to 0 (see=20 http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C_updated-July= 20_2007.pdf).=20 In practice, this makes no difference to the RPL specification. Robert --=20 Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com --------------080003020801080508050803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think we should be specifying AES-CCM not AES-CCM* in the RPL specification. There is some IPR surrounding AES-CCM* (US 2005/0154882), plus only AES-CCM itself is referenced in FIPS 140-2.<= br>
The only real difference between AES-CCM* and AES-CCM is the encrypt only mode, which is illegal in AES-CCM. However, encrypt only is not used in RPL. Authentication only can be achieved in AES-CCM by setting the A data to the header concatenated with the payload and the payload to be encrypted to the null string and Plen to 0 (see http://csrc.n= ist.gov/publications/nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf). In practice, this makes no difference to the RPL specification.

Robert
--

Robert Cragie (Pacific Gas & Electric)

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

--------------080003020801080508050803-- --------------ms080209030706030205040105 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwOTAyMTU1NjI1WjAjBgkqhkiG9w0BCQQxFgQUjLXW UBXeiFlww+rEqvi4R+qv7wYwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAonkkFd8ftNUgwxeCUQGkdM8eAHDANqVG0sYy Td4PXl39PWjmtA2OcqOCKAZI0Tx3cbFw0JS7NABTkN2A/AxBeLv9cJ88q/BpRViAv0w9mJnh 3rnUIGNqZ5zBqNfyEPmKYcvSTWh0Ut8g+kfTUUmOYgedwCuKxhH3wI+a8/KrBpUdkEStWxMF A4LYSXKItMdapZnHdEC+uz2oECHWEHNlM70Z6qgXRX85xIbiusJcCmtTwcNlcGdPPdwqN5LO W7UsCKgIn78kUoeiZdzs37+Tx9UiEH4vDVvWMJDs3DizoNP7R3pDo/zDspY2Df7levXlzLLj gb9UrJKhubKAQW9yLgAAAAAAAA== --------------ms080209030706030205040105-- From mcr@sandelman.ca Thu Sep 2 09:09:04 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194703A6922 for ; Thu, 2 Sep 2010 09:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KszzV5k2cccb for ; Thu, 2 Sep 2010 09:09:03 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 5B60A3A68D4 for ; Thu, 2 Sep 2010 09:09:03 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id DB17634654 for ; Thu, 2 Sep 2010 12:09:32 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 369F198AA6 for ; Thu, 2 Sep 2010 12:09:32 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <30091.1282776402@marajade.sandelman.ca> References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca> <4C7273DB.5080306@gridmerge.com> <30091.1282776402@marajade.sandelman.ca> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 02 Sep 2010 12:09:32 -0400 Message-ID: <9931.1283443772@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] section 3.3.3: channel binding issue for link-layer security X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 02 Sep 2010 16:09:04 -0000 >>>>> "Michael" == Michael Richardson writes: Michael> I spoke to Robert by phone this morning (sorry for my Michael> crappy headset, I was on a train...) to try to understand Michael> where the disconnect in understanding is. Michael> This is what I propose to write in section 3.3.3: Michael> 3.3.3. Security Michael> RPL supports a built-in message confidentiality and Michael> integrity. It is designed for situations where link-layer Michael> mechanisms can not be used, or where they do not exist. Michael> For some deployment scenarios (cf applicability Michael> statements), link-layer security can be used. I was anticipating some response to this email. From robert.cragie@gridmerge.com Thu Sep 2 10:46:37 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11AE33A6B70 for ; Thu, 2 Sep 2010 10:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5HR-baP0YJW for ; Thu, 2 Sep 2010 10:46:32 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 541583A6B72 for ; Thu, 2 Sep 2010 10:19:50 -0700 (PDT) Received: from client-86-23-94-106.brhm.adsl.virginmedia.com ([86.23.94.106] helo=[192.168.1.66]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1OrDSL-0005WK-0X; Thu, 02 Sep 2010 18:20:09 +0100 Message-ID: <4C7FDCC9.809@gridmerge.com> Date: Thu, 02 Sep 2010 18:20:09 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Michael Richardson References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca> <4C7273DB.5080306@gridmerge.com> <30091.1282776402@marajade.sandelman.ca> In-Reply-To: <30091.1282776402@marajade.sandelman.ca> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000500070700060900050204" Cc: roll@ietf.org Subject: Re: [Roll] section 3.3.3: channel binding issue for link-layer security X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 17:46:37 -0000 This is a cryptographically signed message in MIME format. --------------ms000500070700060900050204 Content-Type: multipart/alternative; boundary="------------050206030404050508000509" This is a multi-part message in MIME format. --------------050206030404050508000509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Michael, I have looked through your suggested changes and my conclusion is that=20 the current text as written is adequate and does not need embellishment=20 in the way you have written. Additional notes below - I hope the substitution syntax "s///"=20 highlighted in red is clear enough. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 25/08/2010 11:46 PM, Michael Richardson wrote: > I spoke to Robert by phone this morning (sorry for my crappy headset, I= > was on a train...) to try to understand where the disconnect in > understanding is. > > This is what I propose to write in section 3.3.3: > > > 3.3.3. Security > > RPL supports a built-in message confidentiality and integrity. > It is designed for situations where link-layer mechanisms can not b= e > used, or where they do not exist. For some deployment scenarios > (cf applicability statements), link-layer security can be used. > > 3.3.3.1 Built-in Security > > When using the built-in security, RPL has three basic security mode= s: > > In the first, called "unsecured," RPL control messages are sent > without any additional security mechanisms. Unsecured mode does no= t > imply that the RPL network is unsecure: it could be using other > present security primitives (e.g. link-layer security) to meet > application security requirements. > > In the second, called "pre-installed," nodes joining a RPL Instance= > have pre-installed keys that enable them to process and generate > secured RPL messages. > > The third mode is called "authenticated." In authenticated mode, > nodes have pre-installed keys as in pre-installed mode, but the pre= - > installed key may only be used to join a RPL Instance as a leaf. > > "Authenticated" vs "pre-installed" is determined by the 'A' flag in= > the DODAG configuration option (section 6.7.6) in the DIO message. > > As these messages are protected bys/an encryption and authenticatio= n > key/a key/, which the leaf node may nots/posess/possess/, the RPL i= nstance joining as > a leaf may need to issue a DODAG Information Solicitation message t= o > request that RPL routers send DIO messagess/with the appropriate > "pre-installed" keys/using an appropriate "pre-installed" key/ tha= t the leaf node possesses. > > In scenarios where asymmetric signature mechanisms are used, and no= > privacy protection is used, then the leaf node may be able to > validate the DIO message without sending a DIS. What do you mean by "no privacy protection"? > > > Tos/joining/join/ an authenticated RPL Instance as a router requir= es obtaining > s/a symmetric key/an additional symmetric key/ from anauthenticati= on s/authority/entity/.s/To join using an > asymetric key may involve interaction with some kind of authorizati= on > authority//. The processes by whichs/these keys\/certificates/the = additional keys/ are > obtained is outside the scope of this specification. Authentication and authorization are two different processes and I=20 think you are confusing them. There is no need to mention=20 authorization. > 3.3.3.2 Link-Layer security > > The details of using link-layer security with RPL is subject to > a detailed explanation for each link-layer supported. > > For many link-layers it is an all-or-nothing connection: the lower > layers may not support providing information to upper layers about = which > encryption/authentication keys were used for reception, and they ma= y > not provide any controls to determine which ones will be used for > transmission. This is a common situation for devices with radios > connected via USB or other commodity buses, where the radio in > question simply presents itself as ethernet. > > For such situations, the DODAG is considered to be in "pre-installe= d" > mode, and the 'A' bit in the DODAG configuration option should be > cleared. I do not think this section is necessary and I would not include=20 it. Layers certainly do not share keys used for packet protection with=20 other layers. There has to be an appropriate management interface at the = layer service access point (SAP) to allow manipulation of keys pertinent = to that layer. If that interface is somehow not available to the overall = management entity of the device, that is a design fault. --------------050206030404050508000509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael,

I have looked through your suggested changes and my conclusion is that the current text as written is adequate and does not need embellishment in the way you have written.

Additional notes below - I hope the substitution syntax "s///" highlighted in red is clear enough.

Robert

Robert Cragie (Pacific Gas & Electric)

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


On 25/08/2010 11:46 PM, Michael Richardson wrote: 
I spoke to Robert by phone this morning (sorry for m=
y crappy headset, I
was on a train...) to try to understand where the disconnect in
understanding is.

This is what I propose to write in section 3.3.3:


3.3.3.  Security

   RPL supports a built-in message confidentiality and integrity.
   It is designed for situations where link-layer mechanisms can not be
   used, or where they do not exist.  For some deployment scenarios=20
   (cf applicability statements), link-layer security can be used.

3.3.3.1 Built-in Security

   When using the built-in security, RPL has three basic security modes:

   In the first, called "unsecured," RPL control messages are sent
   without any additional security mechanisms.  Unsecured mode does not
   imply that the RPL network is unsecure: it could be using other
   present security primitives (e.g. link-layer security) to meet
   application security requirements.

   In the second, called "pre-installed," nodes joining a RPL Instance
   have pre-installed keys that enable them to process and generate
   secured RPL messages.

   The third mode is called "authenticated."  In authenticated mode,
   nodes have pre-installed keys as in pre-installed mode, but the pre-
   installed key may only be used to join a RPL Instance as a leaf.

   "Authenticated" vs "pre-installed" is determined by the 'A' flag in
   the DODAG configuration option (section 6.7.6) in the DIO message.

   As these messages are protected by s/an encryp=
tion and authentication
   key/a key/, which the leaf node may not s/posess/possess/, the RPL instance joining as
   a leaf may need to issue a DODAG Information Solicitation message to
   request that RPL routers send DIO messages s/w=
ith the appropriate
   "pre-installed" keys/using an appropriate "pre-installed" key/ =
that the leaf node possesses.=20

   In scenarios where asymmetric signature mechanisms are used, and no
   privacy protection is used, then the leaf node may be able to
   validate the DIO message without sending a DIS.
<RCC>What do you mean by "no privacy protection"?</RCC> 
 =20
  =20
   To s/joining/join/ an authenticated RPL=
 Instance as a router requires obtaining
   s/a symmetric key/an additional symmetric key/=
 from an authentication s/authority/entity=
/.  s/To join using an
   asymetric key may involve interaction with some kind of authorization
   authority//.  The processes by which s/=
these keys\/certificates/the additional keys/ are
   obtained is outside the scope of this specification.
<RCC>Authentication and authorization are two different processes and I think you are confusing them. There is no need to mention authorization.</RCC>
3.3.3.2 Link-Layer security

   The details of using link-layer security with RPL is subject to=20
   a detailed explanation for each link-layer supported. =20

   For many link-layers it is an all-or-nothing connection: the lower
   layers may not support providing information to upper layers about whi=
ch
   encryption/authentication keys were used for reception, and they may
   not provide any controls to determine which ones will be used for
   transmission.   This is a common situation for devices with radios=20
   connected via USB or other commodity buses, where the radio in
   question simply presents itself as ethernet.

   For such situations, the DODAG is considered to be in "pre-installed"
   mode, and the 'A' bit in the DODAG configuration option should be
   cleared.
<RCC>I do not think this section is necessary and I would not include it. Layers certainly do not share keys used for packet protection with other layers. There has to be an appropriate management interface at the layer service access point (SAP) to allow manipulation of keys pertinent to that layer. If that interface is somehow not available to the overall management entity of the device, that is a design fault.</RCC>

--------------050206030404050508000509-- --------------ms000500070700060900050204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwOTAyMTcyMDA5WjAjBgkqhkiG9w0BCQQxFgQUNCc9 JeDAW5UsHWxCk5AF0j0icvgwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAVje6+3GbVVJYjAx3UAzjmnUQ/uyUi/pQwSW+ 2SUXYiQ+KacS878Y+a5iK0wu91ZwIF3d+rM0/ZmioTcUk8mY+u7X4oistQB0xKuLgE8kd8ey HPPa7wTLVz31AfE4X3wyCtg/C9rmgWV+cuQMduddgSEQ7QTW8UF3D6ilonZxJNYa1H1lxRAB +N+NOjd/EP+Th4gxORl4ZorvuUypJBASJIxKO0jrox2/jbmvhA+qkmH+V30NJLtds+iUWDXn OV/rg0SDfTzqUyXY9PEMefeHlTVLRQtKJhF85PFuqGQ6FAhNzsYvbQQQBWfvybSr+A4B8jGr NjqjYF49nHu+uax+UQAAAAAAAA== --------------ms000500070700060900050204-- From mcr@sandelman.ca Thu Sep 2 11:23:38 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51463A69BC for ; Thu, 2 Sep 2010 11:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjiEHJtNASNs for ; Thu, 2 Sep 2010 11:23:31 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 8C1B93A6AC6 for ; Thu, 2 Sep 2010 11:17:02 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 032BA345D7; Thu, 2 Sep 2010 14:17:32 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 228C098AA6; Thu, 2 Sep 2010 14:17:31 -0400 (EDT) From: Michael Richardson To: robert.cragie@gridmerge.com In-Reply-To: <4C7FDCC9.809@gridmerge.com> References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca> <4C7273DB.5080306@gridmerge.com> <30091.1282776402@marajade.sandelman.ca> <4C7FDCC9.809@gridmerge.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 02 Sep 2010 14:17:31 -0400 Message-ID: <13135.1283451451@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] section 3.3.3: channel binding issue for link-layer security X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 02 Sep 2010 18:23:39 -0000 My comments inline, at column 0. >>>>> "Robert" == Robert Cragie writes: Robert> I have looked through your suggested changes and my Robert> conclusion is that the current text as written is adequate Robert> and does not need embellishment in the way you have written. Robert> Additional notes below - I hope the substitution syntax Robert> "s///" highlighted in red is clear enough. Generally, we avoid HTML email at the IETF, and so markup like "red" does not get through to a lot of people. My display is set to display all email in amber on black (yes, like the terminals of the 1980s, which were determined to be kindnest on one's eyes), in a fixed width font. Fortunately, I can read s/// anyway. I can not fault any of your edits, thank you for them. >> The third mode is called "authenticated." In authenticated mode, >> nodes have pre-installed keys as in pre-installed mode, but the >> pre- installed key may only be used to join a RPL Instance as a >> leaf. >> >> "Authenticated" vs "pre-installed" is determined by the 'A' flag >> in the DODAG configuration option (section 6.7.6) in the DIO >> message. >> >> As these messages are protected bys/an encryption and >> authentication key/a key/, which the leaf node may >> nots/posess/possess/, the RPL instance joining as a leaf may need >> to issue a DODAG Information Solicitation message to request that >> RPL routers send DIO messagess/with the appropriate >> "pre-installed" keys/using an appropriate "pre-installed" key/ >> that the leaf node possesses. >> >> In scenarios where asymmetric signature mechanisms are used, and >> no privacy protection is used, then the leaf node may be able to >> validate the DIO message without sending a DIS. Robert> What do you mean by "no privacy protection"? When a DIO is sent by a router-node using built-in security, the contents of the DIO will be encrypted with the "authenticated" keyset. Afterall, the point of being in the "authenticated" group is that one is router, and only nodes in that group can be trusted to be routers. But, if the security using symmetric keys (i.e. AES-CCM), then in order for another node, such as a new leaf node to: a) decrypt the message to see what is inside. b) validate that the message is from an "authenticated" node, and not from just another leaf node pretending to be a router. it needs to have the right keys. What are those keys? In a symmetric keying system, it is the "authenticated" keyset. If the propective leaf node already has the "authenticated" keyset, then it's not a leaf node. The leaf node seeing these DIO messages which it can neither decrypt, nor validate, sends a DIO Solicitation message, giving a list of security parameters that it understands (specifically, requesting that the DIO be encrypted and validated using the "pre-installed" set). The router RPL node then has to send back a new DIO with the right keyset. The leaf node can now join the RPL as a leaf node... maybe. If it remains a leaf node, and does not "upgrade", then it must repeat the above process every time it sees a DIO sent with the "authenticated" keyset. ** What I do not know is how the leaf node, seeing the message with the ** "pre-installed" keys used to validate can trust that this machine is in ** fact a "router", and not just another leaf node. Therefore, in order to make this kind of scenario work, the DIOs from routers need to be authenticated with an asymmetric key set (i.e. RSA) that the leaf nodes can in fact validate without having to possess the credentials to being "authenticated" themselves. I'm sure that my write up is not clear enough. >> Tos/joining/join/ an authenticated RPL Instance as a router >> requires obtaining s/a symmetric key/an additional symmetric key/ >> from anauthentication s/authority/entity/.s/To join using an >> asymetric key may involve interaction with some kind of >> authorization authority//. The processes by whichs/these >> keys\/certificates/the additional keys/ are obtained is outside >> the scope of this specification. Robert> Authentication and authorization are two different Robert> processes and I think you are confusing them. There is no Robert> need to mention authorization. No, I am not confusing the two, I am drawing attention to the fact that the two have been intertwined. I really know far too much about each of them: I have been asking questions about authorization for IPsec systems since the IETF at 1996. What our protocol has done is to convey authorization to become a router (vs a leaf node) by the possession of particular set of authentication keys. This is not unusual, all of the kerberos ticket system is essentially built in this way. >> 3.3.3.2 Link-Layer security >> >> The details of using link-layer security with RPL is subject to a >> detailed explanation for each link-layer supported. >> >> For many link-layers it is an all-or-nothing connection: the >> lower layers may not support providing information to upper >> layers about which encryption/authentication keys were used for >> reception, and they may not provide any controls to determine >> which ones will be used for transmission. This is a common >> situation for devices with radios connected via USB or other >> commodity buses, where the radio in question simply presents >> itself as ethernet. >> >> For such situations, the DODAG is considered to be in >> "pre-installed" mode, and the 'A' bit in the DODAG configuration >> option should be cleared. Robert> I do not think this section is necessary and I would Robert> not include it. Layers certainly do not share keys used for Robert> packet protection with other layers. There has to be an Robert> appropriate management interface at the layer service access Robert> point (SAP) to allow manipulation of keys pertinent to that Robert> layer. If that interface is somehow not available to the Robert> overall management entity of the device, that is a design Robert> fault. Okay: I certainly agree it is a design fault. I claim that this design fault is rather ubiquitous, and will lead to a market fault when it turns out that everyone has to turn off layer-2 security in order to make things work. -- ] 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 alexandru.petrescu@gmail.com Thu Sep 2 12:16:47 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59DE13A6826 for ; Thu, 2 Sep 2010 12:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[AWL=0.639, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wxuc-3UNScHJ for ; Thu, 2 Sep 2010 12:16:41 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 628943A69AC for ; Thu, 2 Sep 2010 12:16:38 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id EA0C4940019; Thu, 2 Sep 2010 21:17:02 +0200 (CEST) Message-ID: <4C7FF82B.2020004@gmail.com> Date: Thu, 02 Sep 2010 21:16:59 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: roll@ietf.org References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D2596.3090108@gridmerge.com> <4C7D6B9A.6050108@gmail.com> <4C7FC901.4050204@gridmerge.com> In-Reply-To: <4C7FC901.4050204@gridmerge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100902-0, 02/09/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] Current RPL security concerns X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 02 Sep 2010 19:16:48 -0000 Le 02/09/2010 17:55, Robert Cragie a écrit : > The previous thread was getting a little difficult to follow so I > wanted to list the current concerns with RPL security as I see them > and get the ball rolling on how we deal with it. Let me know if I > haven't summarized correctly or missed anything. This is a good list of current concerns we've discussed - thanks! I'm wondering whether the link-layer security aspects discussed in a parallel thread are to be noted here as a concern as well, or whether that could be considered as agreed already. If comments are needed in this list of concerns, per item - I can send. Alex > > Current concerns: > > 1. Placement of the MAC field > 2. Order of processing for checksum and MAC > 3. Setting of mutable fields > 4. Use of AH instead of RPL security > 5. Whether encryption is needed or not > > > _Placement of the MAC field_ > > AES-CCM concatenates the MAC at the end of the secured data. This is not > particularly clear from the specification. The secured RPL control > message could be shown as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Code | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . Security . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . Base . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . Option(s) . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . MAC . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 7: Secure RPL Control Message > > Similar consideration should be given to the signature field. > > _Order of processing for checksum and MAC_ > > Given the above packet format, the ICMPv6 checksum needs to be > calculated first on the whole packet according to RFC 4443, with the MAC > field set to 0. At this point the packet is ready for security processing. > > _Setting of mutable fields_ > > Security processing would involve setting the mutable fields to 0 then > running the AES-CCM process according to the level on the packet, > excluding the MAC field. The resulting MAC is then placed in the MAC field. > > _Use of AH instead of RPL security_ > > The use if AH (transport mode) would indeed be possible if it is deemed > that encryption is not necessary. However, the additional paraphernalia > of IPSec needs to be considered too - the security parameters, secure > association etc. What is currently specified in RPL is equivalent and > self-contained. Replay protection is supported through the use of > monotonically increasing or time-based counters. > > _Whether encryption is needed or not_ > > The way the spec. is currently written does not mandate encryption as it > can be set in the Security Section.Security Control Field.Level field. > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Thu Sep 2 12:27:11 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF2273A68F1 for ; Thu, 2 Sep 2010 12:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1xq-w0ovUFx for ; Thu, 2 Sep 2010 12:27:10 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 30DA13A6781 for ; Thu, 2 Sep 2010 12:27:08 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 43637940036; Thu, 2 Sep 2010 21:27:32 +0200 (CEST) Message-ID: <4C7FFAA1.7000800@gmail.com> Date: Thu, 02 Sep 2010 21:27:29 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Rodolfo Gonzalez Bernaldez References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D2596.3090108@gridmerge.com> <4C7D6B9A.6050108@gmail.com> <8A2FA3C50EC246D7AA6C415F501D8D9C@ubilogixrodo> In-Reply-To: <8A2FA3C50EC246D7AA6C415F501D8D9C@ubilogixrodo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100902-0, 02/09/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 02 Sep 2010 19:27:11 -0000 Le 02/09/2010 02:16, Rodolfo Gonzalez Bernaldez a écrit : > > > -------------------------------------------------- From: "Alexandru > Petrescu" Sent: Tuesday, August 31, > 2010 1:52 PM To: Cc: "Rodolfo Gonzalez > Bernaldez" ; "ROLL WG" Subject: > Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit > >> Le 31/08/2010 17:53, Robert Cragie a écrit : >>> Hi Rodolfo, >>> >>> I agree about treatment of mutable fields. Setting them to 0 for >>> MAC calculation is an acceptable way of doing it although it is a >>> little clumsy for inline packet security processing (done by >>> certain devices). The alternative would be to elide the fields >>> completely but this is probably more work in practice. >>> >>>> That sounds right. Provided the Hop Limit mutable field is set >>>> to 0 at MAC computing time by sender, and also by receiver. >>>> Your example seems to say so. I agree with it. >>>> >>>>> The only issue that I see at this moment is were to put the >>>>> CBC-MAC data, >>>> >>>> I agree, that is a right question: where to put the CBC-MAC >>>> data? >>>> >>>>> for example here we have 64 bit of CBC-MAC, we can just >>>>> leave them at the end of the packet or maybe create a field >>>>> at the end of each RPL frame with security with the name >>>>> CBC-MAC or something like that. >>>> >>>> I propose to put the CBC-MAC data in the Authentication Header >>>> - the Integrity Check Value (ICV) field of a typical >>>> Authentication Header rfc4302, instead of putting it as a field >>>> in the RPL header. What do you think about this? Interested >>>> people? >>>> >>> >>> The only issue that I see with the AH, is the size of the >>> AH header, is a big header. But if we are talked of MAC security >>> (IEEE 802.15.4-2006-MAC) lest just to leave the MIC (CBC-MAC) as >>> is defined by the standard, and the MIC is just another field of >>> the MAC frame like the field MFR. What do you think about this?. >>> >>> >>> AES-CCM (SP 800-38C) specifies concatenation of the encrypted >>> MAC (MIC, schmac, schmic :-) at the end of the payload. I would >>> keep it there. It makes the MPDU larger. If doing it like this, >>> it should be shown on Figure 7, appended after the options. >> >> I think it would be good to agree whether encryption is absolutely >> needed in RPL or considered as luxury, assuming that encryption >> would take more computing power than very simple authentication. >> > > Yes I agree we still need to define when the use of security is > mandatory or optional. I'm not sure what you mean? I meant to say whether authentication is mandatory (vs encryption which would be less mandatory). I agree security overall should be taken into account, but security has authentication and encryption aspects; auth and enc typically require different levels of computing power, I think. > I quote, "assuming that encryption would take more computing power > than very simple authentication", if we handled the CBC-MAC as is > defined be the standard, at the transceiver IEEE 802.15.4-2006 with > hardware security support could do this without draining to much > power from the battery. Would encryption draw more power than authentication? And compute cycles? If one is cheaper than the other in these terms then I believe it should be preferred. >> About placement: would an MPDU with MAC at its end be understood by >> a non-RPL node at the other end of the Internet (but running >> IPsec)? > > Do you mean a secured IEEE 802.15.4-2006 MPDU?, if so, why a > edge router would sent IEEE 802.15.4 frame (MHR-MACpayload-MFR) to > internet? Right, an edge router would not send the MACheaders to the Internet. But an edge router could IP forward that data packet (issued from an RPL router) to a central server - maybe the console querying the sensor data. That central server could run IPsec and it would not necessarily run RPL. In this picture, if the node runs RPL security and the server IPsec security then there may be an interoperability problem: end-to-end security. Alex From alexandru.petrescu@gmail.com Thu Sep 2 12:51:24 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B61AD3A68AB for ; Thu, 2 Sep 2010 12:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.325 X-Spam-Level: X-Spam-Status: No, score=-1.325 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlmhHJYGHPSV for ; Thu, 2 Sep 2010 12:51:23 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id A22933A688C for ; Thu, 2 Sep 2010 12:51:19 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 4D15F940141; Thu, 2 Sep 2010 21:51:43 +0200 (CEST) Message-ID: <4C80004B.4000305@gmail.com> Date: Thu, 02 Sep 2010 21:51:39 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Rodolfo Gonzalez Bernaldez References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> In-Reply-To: <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100902-0, 02/09/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 02 Sep 2010 19:51:24 -0000 Le 02/09/2010 02:16, Rodolfo Gonzalez Bernaldez a écrit : > Hello Alex, all > > My comments in message bracket by > > -------------------------------------------------- From: "Alexandru > Petrescu" Sent: Tuesday, August 31, > 2010 1:49 PM To: "Rodolfo Gonzalez Bernaldez" > Cc: "Michael Richardson" ; "ROLL WG" > Subject: Re: [Roll] Messg Auth Code covering the > mutable IP Hop Limit > >> Le 31/08/2010 02:39, Rodolfo Gonzalez Bernaldez a écrit : >>> Hello Alex, all >>> >>> My comments in message bracket by >>> >>> Best regards Rodolfo. >>> >>> -------------------------------------------------- From: >>> "Alexandru Petrescu" Sent: Sunday, >>> August 29, 2010 10:45 AM To: "Rodolfo Gonzalez Bernaldez" >>> Cc: "Michael Richardson" >>> ; "ROLL WG" Subject: Re: [Roll] >>> Messg Auth Code covering the mutable IP Hop Limit >>> >>>> Le 28/08/2010 00:50, Rodolfo Gonzalez Bernaldez a écrit : >>>>> Hello Alex, all >>>>> >>>>> CCM* and IPSEC, both provide data authentication and >>>>> encryption and it's that what we are looking for >>>> >>>> [sidenote to clarify terminology as I read: one would compare >>>> CCM* to AH (for authentication) and to ESP (for enc + auth). >>>> IPsec is more than just these two, often comprising IKE (key >>>> generation), databases, rules, policies, firewalls, and more - >>>> these are not covered by CCM* but IPsec does.] >>>> >>> >>> Yes I agree, I don't specify clearly my idea here. I was >>> thought only in authentication and encryption of the packet, for >>> these reasons I focused only in that two features. By the way the >>> zigbeeIP group is working on PANA and EAP, in case you are >>> interested >>> >>>>> Using the security level 5, 6, or 7, you can define the >>>>> number of bytes for clear text. >>>>> >>>>> In CCM* using the security level 5, 6 or 7 may have the next >>>>> form for data: A) encrypted data : MAC B) clear text : MAC C) >>>>> clear text - encrypted data : MAC >>>>> >>>>> For example using CCM* level 6 on the next data and an input >>>>> with 8 cleartext header octets AES Key = C0 C1 C2 C3 C4 C5 C6 >>>>> C7 C8 C9 CA CB CC CD CE CF Nonce = 00 00 00 03 02 01 00 A0 A1 >>>>> A2 A3 A4 A5 Data= 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D >>>>> 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E we get the >>>>> next result: CCM* level 6 Data= 00 01 02 03 04 05 06 07 58 8C >>>>> 97 9A 61 C6 63 D2 F0 66 D0 C2 C0 F9 89 80 6D 5F 6B 61 DA C3 >>>>> 84 17 E8 D1 2C FD F9 26 E0 As you see the first 8 bytes were >>>>> unchanged, but were used to create the CBC-MAC. For more >>>>> details see rfc3610 packet vector #1 >>>>> >>>>> With this in mind, lest to suppose that we have the next >>>>> IPv6 packet: FF 01 02 03 44 55 66 77 08 09 0A 0B 0C 0D 0E 0F >>>>> 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E and the byte >>>>> cero is one of the mutable fields (e.g. the Hop limit) and >>>>> the byte 4,5,6, and 7 are a mutable field but predictable and >>>>> the predictable values are for byte 4 = 04, byte 5 = 05, byte >>>>> 6 = 06 and byte 7 = 07, so now following the rules of RFC4302 >>>>> our packet will change to: 00 01 02 03 04 05 06 07 08 09 0A >>>>> 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E >>>>> Now lest to use CCM* level 6, the result is the next: 00 01 >>>>> 02 03 04 05 06 07 58 8C 97 9A 61 C6 63 D2 F0 66 D0 C2 C0 F9 >>>>> 89 80 6D 5F 6B 61 DA C3 84 17 E8 D1 2C FD F9 26 E0 >>>>> >>>>> And the destination node knowing the rules of RFC4302, just >>>>> needs to apply the same rules and set the ceros for mutable >>>>> fields and the corresponding values for the mutable but >>>>> predictable fields. >>>> >>>> That sounds right. Provided the Hop Limit mutable field is set >>>> to 0 at MAC computing time by sender, and also by receiver. >>>> Your example seems to say so. I agree with it. >>>> >>>>> The only issue that I see at this moment is were to put the >>>>> CBC-MAC data, >>>> >>>> I agree, that is a right question: where to put the CBC-MAC >>>> data? >>>> >>>>> for example here we have 64 bit of CBC-MAC, we can just leave >>>>> them at the end of the packet or maybe create a field at the >>>>> end of each RPL frame with security with the name CBC-MAC or >>>>> something like that. >>>> >>>> I propose to put the CBC-MAC data in the Authentication Header >>>> - the Integrity Check Value (ICV) field of a typical >>>> Authentication Header rfc4302, instead of putting it as a field >>>> in the RPL header. What do you think about this? Interested >>>> people? >>>> >>> >>> The only issue that I see with the AH, is the size of the >>> AH header, is a big header. But if we are talked of MAC security >>> (IEEE 802.15.4-2006-MAC) lest just to leave the MIC (CBC-MAC) as >>> is defined by the standard, and the MIC is just another field of >>> the MAC frame like the field MFR. What do you think about this?. >>> >> >> MAkes sense, one would like to avoid long additional data. > > Because we are talking about 6LoWPAN and the link-layer used at > this moment is IEEE 802.15.4, it worth mentioning that RPL-ROLL is a > draft at date, so is not bad idea to leave some bytes free, that is > why, yes I think that make sense I believe the discussion is mostly in the 802.15.4 context. However, there is strong reluctance from stating so in the draft. E.g. apparently PLC (powerline communications, different than 802.15.4) must be in the draft too. In this heterogeneous context it is very hard to agree that RPL is _only_ for 802.15.4. I think I would be happier if the RPL draft said 802.15.4 explicitely, and only it. Many decisions (in addition to security) would be easier. >> >> Any more detail of comparison on length you would like to share? >> >> How long is a "big" header such as AH? And "big" compared to what? >> Is it much bigger than the mandatory IPv6 base header? > > I think that is a "big" header because in the worse case, the > link-layer 802.15.4 only gives 81 bytes for IPv6 data. WEll. That is an MTU problem (Maximum Transmission Unit) as seen by the IPv6 stack. There are fragmentation solutions: the link-layer could fragment, and I think it may be so. There is an RFC IPv6 over 802.15.4 and I believe that requires IPv6 packets to be 1280bytes long: "The MTU size for IPv6 packets over IEEE 802.15.4 is 1280 octets." > I think a single RPL header takes more than 81 bytes How much bigger > than the mandatory IPv6? We are in 6LoWPAN and an IPv6 header using > IPHC can be as small as 3 bytes. Hm. Well... when you say "we are in 6lowpan"... IP Header Compression is good. > > >> >> How much additional AH header bytes are added to an RPL (IPv6 base >> + RPL ICMP) compared to putting the CBC-MAC in the same packet, as >> an RPL field. I think that delta is 96bits (the AH specific fields, >> figure 1 rfc4302). This is much shorter than the potentially >> multiple 128bits of each IPv6 address potentially in a ROuting >> Header of RPL. > > Why a node routing an IPv6 packet will apply security (in this > case CCM*) over this packet? > > Only one CBC-MAC is put on the packet and only one, the > originator node of the packet will insert the CBC-MAC, and the nodes > routing the packet will modify the IPv6 header for the mutable > fields, once the node destiny is reached this will set the mutable > fields as rfc4302 and apply ccm* to decrypt. I agree with this principle: originator sets the MAC, intermediary nodes touch the mutable fields, receiver recomputes MAC and checks. PRovided we agree to put 0 in the mutable fields both at reception and emission and that we ack the attack risks on the mutable fields. IT is also good to set straight the order of MAC, Checksum and mutable field computation: which is first, second, third, etc. >> There may be certain advantages of AH specific fields: SPI, seqno >> field. SPI (Security parm index) helps interoperate with existing >> databases in existing firewalls. seqno helps with replay >> protection. Does CBC-MAC per se offer replay protection? > > May be Robert Cragie could show us some alternative options for > these purposes I read. >> Reusing AH could help an RPL node to talk to a non-RPL node, >> authenticated. >> > > Sorry but I don't understand this part Sorry for being too concise, let me try to expand. RPL node sends data to a central server. Like a console querying sensor data. But that central server does not RPL. How is that IP communication secured? Big server PC would not run RPL, because not every IP node in the Internet runs RPL. One would think that RPL security would cover the RPLnode-to-RPLEdgeRouter security and IPsec would cover RPLEdgeRouter-to-CentralServer security. But IPsec security is often indexed on the src and dst IP addresses of the packet, as "end-to-end" security. This is a good think IMHO, because it is exposed to less risks to intermediary nodes, lets the endnode be smart and the network dumb. It is important that the src and dst addresses of a data packet from an RPL node to a central server be themselves, and not some intermediary edge router. If we follow this logic, then it is very hard to make security work as two different sequential links: RPL up to edge router and IPsec onwards, because edgerouter risks becoming a single point of security failure, which is not good in distributed systems like Internet. I guess this was too long expansion. And I hope it's not flawed :-) Moreover, as with all principle discussions it is subject to many exceptions :-) Alex > >> (for same reusability reasons for which RPL is an ICMP header...) >> >> Alex >> >>>> This is a central issue to clarify. Depending on this we can >>>> see further. >>>> >>>> Alex >>>> >>>>> >>>>> The other option is to create a AH for RPL designed for CCM* >>>>> (I don't like this idea, because the IEEE 802.15.4-2006 frame >>>>> already have an auxiliary security header), or make >>>>> modifications to IPSEC to support CCM*. >>>>> >>>>> Sorry for the long email, comments are welcome. >>>>> >>>>> Best regards Rodolfo. >>>>> >>>>> -------------------------------------------------- From: >>>>> "Alexandru Petrescu" Sent: >>>>> Friday, August 27, 2010 12:34 AM To: "Rodolfo Gonzalez >>>>> Bernaldez" Cc: "Michael Richardson" >>>>> ; "ROLL WG" Subject: Re: >>>>> [Roll] Messg Auth Code covering the mutable IP Hop Limit >>>>> >>>>>> Le 27/08/2010 00:08, Rodolfo Gonzalez Bernaldez a écrit : >>>>>>> Hello Michael, Alex, all >>>>>>> >>>>>>> >>>>>>>> For example, one wouldn't appreciate to have both AH >>>>>>>> protection of the entire packet _and_ RPL CCM >>>>>>>> protection. It is redundant. >>>>>>> >>>>>>> >>>>>>> Yes I agree, that it is redundant. >>>>>>> >>>>>>> I was checking the RFC4302 section 3.3.3.1. Handling >>>>>>> Mutable Fields, >>>>>> >>>>>> I think that is the right section to think of. >>>>>> >>>>>>> and I didn't see any problem to use these rules only with >>>>>>> CCM*. >>>>>> >>>>>> Well, depends how we refer to it. Intuitively, it may be >>>>>> easy indeed to apply that "rfc4302 mutable field" rules to >>>>>> CCM*. >>>>>> >>>>>> However, this may introduce new misunderstandings too. >>>>>> Because that section explicitely says "IPsec": >>>>>>> [...] If a field is mutable, but its value at the >>>>>>> (IPsec) receiver is predictable, then [...] >>>>>> >>>>>> Here we don't have IPsec receivers, we have CCM* receivers >>>>>> - they are very different: CCM* MAC is present in ICMP >>>>>> headers, whereas IPsec ICV is present in Authentication >>>>>> Header. >>>>>> >>>>>> Thus, will that rfc4302 "If" rule apply here or not? If >>>>>> not, then we don't know what to do here with CCM* and >>>>>> mutable-but-predictable fields. We would have to specify >>>>>> what CCM* does with them, couldn't simply refer to >>>>>> rfc4302. >>>>>> >>>>>> There are several mentionings of "IPsec" in that section, >>>>>> and here we don't currently do IPsec. >>>>>> >>>>>> To solve that, it may lead to copy&paste that section into >>>>>> RPL doc and substitute "CCM* MAC" for "ICV", "RPL" for >>>>>> "IPsec", remove IPv4, etc. Suddenly that sounds not as a >>>>>> simple straight referral to rfc4302. >>>>>> >>>>>> It may lead to rewriting IPsec specs altogether. >>>>>> >>>>>>> What do you think of the following statements in the >>>>>>> security section: -Any IPv6 frame with security must be >>>>>>> prepared as RFC4302 section 3.3.3.1 specified for mutable >>>>>>> fields >>>>>> >>>>>> Ok, sounds good as first step, for mutable fields. >>>>>> >>>>>> How about the "Mutable but Predictable Fields", i.e. dst >>>>>> address in presence of a Routing Header. MAC should cover >>>>>> them too, especially knowing that a new Routing Header is >>>>>> under discussion in 6MAN WG, for RPL. >>>>>> >>>>>>> -ccm* computation must take IPv6 header, and/or IPv6 >>>>>>> extension headers as clear text, the rest of the packet >>>>>>> must be encrypted >>>>>> >>>>>> I kind of understand and I can agree. >>>>>> >>>>>> However, will the rest of the packet (encrypted) be also >>>>>> applied authentication, or just leave it encrypted. This >>>>>> should be clarified one way or another, so implementer >>>>>> knows what to implement. This again risks leading to >>>>>> rewriting IPsec specifications. >>>>>> >>>>>> At which point I wonder why all the effort? Wouldn't it be >>>>>> easier to identify what's the real core of the RPL security >>>>>> - is it CCM* only? If yes - could we use CCM* with IPsec >>>>>> Authentication Header? That may be simpler to spec and >>>>>> implement, rather than carrying new MAC fields in ICMP. >>>>>> >>>>>>> Using these two rules statements we would be following >>>>>>> the rules of RFC4302, providing authentication for the >>>>>>> entire IPv6 frame, and we keeping encrypted RPL data. >>>>>> >>>>>> Yes, that is one possible way of doing it. >>>>>> >>>>>> I just wanted to mention that here we have a context: a >>>>>> number of IPv6 fields, extension headers and other >>>>>> standards are present - we should consider them all. >>>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>>> Best regards Rodolfo. >>>>>>> -------------------------------------------------- From: >>>>>>> "Alexandru Petrescu" >>>>>>> Sent: Thursday, August 26, 2010 7:42 AM To: "Michael >>>>>>> Richardson" Cc: "Rodolfo Gonzalez >>>>>>> Bernaldez" ; "ROLL WG" >>>>>>> Subject: Re: [Roll] Messg Auth Code >>>>>>> covering the mutable IP Hop Limit >>>>>>> >>>>>>>> Le 26/08/2010 15:31, Michael Richardson a écrit : >>>>>>>>>>>>>> "Alexandru" == Alexandru >>>>>>>>>>>>>> Petrescu >>>>>>>>>>>>>> writes: >>>>>>>>> Alexandru> On another hand, risks do exist in the >>>>>>>>> base header Alexandru> (spoofing the src address is >>>>>>>>> one widely known). It is >>>>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > From robert.cragie@gridmerge.com Thu Sep 2 14:06:11 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48F203A69F5 for ; Thu, 2 Sep 2010 14:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.609 X-Spam-Level: X-Spam-Status: No, score=-3.609 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+r-KCt7MrI1 for ; Thu, 2 Sep 2010 14:06:08 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 7DE613A6827 for ; Thu, 2 Sep 2010 14:06:06 -0700 (PDT) Received: from client-86-23-94-106.brhm.adsl.virginmedia.com ([86.23.94.106] helo=[192.168.1.66]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1OrGzR-0004Sq-L2; Thu, 02 Sep 2010 22:06:34 +0100 Message-ID: <4C8011DA.4090004@gridmerge.com> Date: Thu, 02 Sep 2010 22:06:34 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Michael Richardson References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca> <4C7273DB.5080306@gridmerge.com> <30091.1282776402@marajade.sandelman.ca> <4C7FDCC9.809@gridmerge.com> <13135.1283451451@marajade.sandelman.ca> In-Reply-To: <13135.1283451451@marajade.sandelman.ca> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070209050504030406010507" Cc: roll@ietf.org Subject: Re: [Roll] section 3.3.3: channel binding issue for link-layer security X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 21:06:11 -0000 This is a cryptographically signed message in MIME format. --------------ms070209050504030406010507 Content-Type: multipart/alternative; boundary="------------070205080409040108080405" This is a multi-part message in MIME format. --------------070205080409040108080405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Michael, Comments inline, bracketed by Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 02/09/2010 7:17 PM, Michael Richardson wrote: > My comments inline, at column 0. > >>>>>> "Robert" =3D=3D Robert Cragie writes= : > Robert> I have looked through your suggested changes and my > Robert> conclusion is that the current text as written is adequat= e > Robert> and does not need embellishment in the way you have writt= en. > > Robert> Additional notes below - I hope the substitution syntax > Robert> "s///" highlighted in red is clear enough. > > Generally, we avoid HTML email at the IETF, and so markup like "red" > does not get through to a lot of people. > My display is set to display all email in amber on black (yes, like the= > terminals of the 1980s, which were determined to be kindnest on one's > eyes), in a fixed width font. Fortunately, I can read s/// anyway. Fair point, I will avoid doing this in the future > I can not fault any of your edits, thank you for them. > > >> The third mode is called "authenticated." In authenticated mo= de, > >> nodes have pre-installed keys as in pre-installed mode, but th= e > >> pre- installed key may only be used to join a RPL Instance as = a > >> leaf. > >> > >> "Authenticated" vs "pre-installed" is determined by the 'A' fl= ag > >> in the DODAG configuration option (section 6.7.6) in the DIO > >> message. > >> > >> As these messages are protected bys/an encryption and > >> authentication key/a key/, which the leaf node may > >> nots/posess/possess/, the RPL instance joining as a leaf may n= eed > >> to issue a DODAG Information Solicitation message to request t= hat > >> RPL routers send DIO messagess/with the appropriate > >> "pre-installed" keys/using an appropriate "pre-installed" key/= > >> that the leaf node possesses. > >> > >> In scenarios where asymmetric signature mechanisms are used, a= nd > >> no privacy protection is used, then the leaf node may be able = to > >> validate the DIO message without sending a DIS. > > Robert> What do you mean by "no privacy protection"? > > When a DIO is sent by a router-node using built-in security, the > contents of the DIO will be encrypted with the "authenticated" keyset. Not necessarily, it depends on the level chosen. > Afterall, the point of being in the "authenticated" group is that one i= s > router, and only nodes in that group can be trusted to be routers. > > But, if the security using symmetric keys (i.e. AES-CCM), then in order= > for another node, such as a new leaf node to: > a) decrypt the message to see what is inside. > b) validate that the message is from an "authenticated" node, > and not from just another leaf node pretending to be a router. > > it needs to have the right keys. What are those keys? In a symmetric > keying system, it is the "authenticated" keyset. If the propective lea= f > node already has the "authenticated" keyset, then it's not a leaf node.= > > The leaf node seeing these DIO messages which it can neither decrypt, > nor validate, sends a DIO Solicitation message, giving a list of > security parameters that it understands (specifically, requesting that > the DIO be encrypted and validated using the "pre-installed" set). > > The router RPL node then has to send back a new DIO with the right > keyset. The leaf node can now join the RPL as a leaf node... maybe. > > If it remains a leaf node, and does not "upgrade", then it must repeat > the above process every time it sees a DIO sent with the "authenticated= " > keyset. > > ** What I do not know is how the leaf node, seeing the message with the= > ** "pre-installed" keys used to validate can trust that this machine is= in > ** fact a "router", and not just another leaf node. > > Therefore, in order to make this kind of scenario work, the DIOs from > routers need to be authenticated with an asymmetric key set (i.e. RSA) > that the leaf nodes can in fact validate without having to possess the > credentials to being "authenticated" themselves. > > I'm sure that my write up is not clear enough. I think that's a good analysis of the scenario. Using pre-installed=20 symmetric keys suffers from catch-22 in that those need to be=20 distributed with appropriate cryptographic protection. This could be=20 done out of band - whilst 'not in scope', to pretend it can be just=20 presumed is probably not very helpful in the grand scheme of things. So=20 this means that some sort of authentication and key establishment will=20 probably be needed anyway. Then the pre-installed key can be used as a=20 shared secret for challenge-response but not much else - certainly not=20 for securing messages. You could indeed sign every DIO message but I don't think this will be=20 practical, not in the sort of RPL networks I'm thinking about anyway=20 (and let's not forget what ROLL stands for). Distributing the public key = across joining nodes still needs to be done but it is less of an issue=20 than the symmetric keys In practice, I don't the leaf node needs to see the DIOs if it is going=20 to be subsequently authenticated. It just needs a viable parent router.=20 If that is a bogus leaf masquerading as a parent router, the process=20 won't get very far. Alternatively, if a rudimentary level of security is required, some=20 pre-installed shared key can be used for message protection (mode 1). So, my conclusion is - I think the modes are adequately described in the = current draft; to describe them in any more detail is probably going out = of scope for the purposes of securing RPL messages. > >> Tos/joining/join/ an authenticated RPL Instance as a router > >> requires obtaining s/a symmetric key/an additional symmetric k= ey/ > >> from anauthentication s/authority/entity/.s/To join using an > >> asymetric key may involve interaction with some kind of > >> authorization authority//. The processes by whichs/these > >> keys\/certificates/the additional keys/ are obtained is outsid= e > >> the scope of this specification. > > Robert> Authentication and authorization are two different > Robert> processes and I think you are confusing them. There is no= > Robert> need to mention authorization. > > No, I am not confusing the two, I am drawing attention to the fact that= > the two have been intertwined. I really know far too much about each o= f > them: I have been asking questions about authorization for IPsec > systems since the IETF at 1996. The two are intertwined but are still separate processes.=20 Authorization is implicit in this case whether a symmetric or asymmetric = key is used as the basis of authentication and key establishment. > > > What our protocol has done is to convey authorization to become a route= r > (vs a leaf node) by the possession of particular set of authentication > keys. This is not unusual, all of the kerberos ticket system is > essentially built in this way. Exactly, it's implicit. What's it got to do explicitly with=20 asymmetric keys? > >> 3.3.3.2 Link-Layer security > >> > >> The details of using link-layer security with RPL is subject t= o a > >> detailed explanation for each link-layer supported. > >> > >> For many link-layers it is an all-or-nothing connection: the > >> lower layers may not support providing information to upper > >> layers about which encryption/authentication keys were used fo= r > >> reception, and they may not provide any controls to determine > >> which ones will be used for transmission. This is a common > >> situation for devices with radios connected via USB or other > >> commodity buses, where the radio in question simply presents > >> itself as ethernet. > >> > >> For such situations, the DODAG is considered to be in > >> "pre-installed" mode, and the 'A' bit in the DODAG configurati= on > >> option should be cleared. > > Robert> I do not think this section is necessary and I would= > Robert> not include it. Layers certainly do not share keys used f= or > Robert> packet protection with other layers. There has to be an > Robert> appropriate management interface at the layer service acc= ess > Robert> point (SAP) to allow manipulation of keys pertinent to th= at > Robert> layer. If that interface is somehow not available to the > Robert> overall management entity of the device, that is a design= > Robert> fault. > > Okay: I certainly agree it is a design fault. > I claim that this design fault is rather ubiquitous, and will lead to a= > market fault when it turns out that everyone has to turn off layer-2 > security in order to make things work. We shall see... --------------070205080409040108080405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael,

Comments inline, bracketed by <RCC2></RCC2>

Robert Cragie (Pacific Gas & Electric)

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


On 02/09/2010 7:17 PM, Michael Richardson wrote: 
My comments inline, at column 0.


"Robert" =3D=3D Robert Cragie <ro=
bert.cragie@gridmerge.com> writes:

    Robert> I have looked through your suggested =
changes and my
    Robert> conclusion is that the current text as written is adequate=

    Robert> and does not need embellishment in the way you have writte=
n.

    Robert> Additional notes below - I hope the substitution syntax
    Robert> "s///" highlighted in red is clear enough.

Generally, we avoid HTML email at the IETF, and so markup like "red"
does not get through to a lot of people.
My display is set to display all email in amber on black (yes, like the
terminals of the 1980s, which were determined to be kindnest on one's
eyes), in a fixed width font. Fortunately, I can read s/// anyway.
<RCC>Fair point, I will avoid doing this in the future</RCC>
I can not fault any of your edits, thank you for them.

    >> The third mode is called "authenticated."  In authenticated =
mode,
    >> nodes have pre-installed keys as in pre-installed mode, but =
the
    >> pre- installed key may only be used to join a RPL Instance a=
s a
    >> leaf.
    >>=20
    >> "Authenticated" vs "pre-installed" is determined by the 'A' =
flag
    >> in the DODAG configuration option (section 6.7.6) in the DIO=

    >> message.
    >>=20
    >> As these messages are protected bys/an encryption and
    >> authentication key/a key/, which the leaf node may
    >> nots/posess/possess/, the RPL instance joining as a leaf may=
 need
    >> to issue a DODAG Information Solicitation message to request=
 that
    >> RPL routers send DIO messagess/with the appropriate
    >> "pre-installed" keys/using an appropriate "pre-installed" ke=
y/
    >> that the leaf node possesses.
    >>=20
    >> In scenarios where asymmetric signature mechanisms are used,=
 and
    >> no privacy protection is used, then the leaf node may be abl=
e to
    >> validate the DIO message without sending a DIS.

    Robert> <RCC>What do you mean by "no privacy protection"?<=
;/RCC>

When a DIO is sent by a router-node using built-in security, the
contents of the DIO will be encrypted with the "authenticated" keyset.
<RCC2>Not necessarily, it depends on the level chosen.</RCC2>
Afterall, the point of being in the "authenticated" group is that one is
router, and only nodes in that group can be trusted to be routers.

But, if the security using symmetric keys (i.e. AES-CCM), then in order
for another node, such as a new leaf node to:
    a) decrypt the message to see what is inside.
    b) validate that the message is from an "authenticated" node,
       and not from just another leaf node pretending to be a router.

it needs to have the right keys. What are those keys?  In a symmetric
keying system, it is the "authenticated" keyset.  If the propective leaf
node already has the "authenticated" keyset, then it's not a leaf node.

The leaf node seeing these DIO messages which it can neither decrypt,
nor validate, sends a DIO Solicitation message, giving a list of
security parameters that it understands (specifically, requesting that
the DIO be encrypted and validated using the "pre-installed" set).

The router RPL node then has to send back a new DIO with the right
keyset.   The leaf node can now join the RPL as a leaf node... maybe.

If it remains a leaf node, and does not "upgrade", then it must repeat
the above process every time it sees a DIO sent with the "authenticated"
keyset. =20

** What I do not know is how the leaf node, seeing the message with the
** "pre-installed" keys used to validate can trust that this machine is i=
n
** fact a "router", and not just another leaf node.

Therefore, in order to make this kind of scenario work, the DIOs from
routers need to be authenticated with an asymmetric key set (i.e. RSA)
that the leaf nodes can in fact validate without having to possess the
credentials to being "authenticated" themselves.

I'm sure that my write up is not clear enough.
<RCC2>
I think that's a good analysis of the scenario. Using pre-installed symmetric keys suffers from catch-22 in that those need to be distributed with appropriate cryptographic protection. This could be done out of band - whilst 'not in scope', to pretend it can be just presumed is probably not very helpful in the grand scheme of things. So this means that some sort of authentication and key establishment will probably be needed anyway. Then the pre-installed key can be used as a shared secret for challenge-response but not much else - certainly not for securing messages.

You could indeed sign every DIO message but I don't think this will be practical, not in the sort of RPL networks I'm thinking about anyway (and let's not forget what ROLL stands for). Distributing the public key across joining nodes still needs to be done but it is less of an issue than the symmetric keys

In practice, I don't the leaf node needs to see the DIOs if it is going to be subsequently authenticated. It just needs a viable parent router. If that is a bogus leaf masquerading as a parent router, the process won't get very far.

Alternatively, if a rudimentary level of security is required, some pre-installed shared key can be used for message protection (mode 1).

So, my conclusion is - I think the modes are adequately described in the current draft; to describe them in any more detail is probably going out of scope for the purposes of securing RPL messages.
</RCC2>

    >> Tos/joining/join/ an authenticated RPL Instance as a router
    >> requires obtaining s/a symmetric key/an additional symmetric=
 key/
    >> from anauthentication s/authority/entity/.s/To join using an=

    >> asymetric key may involve interaction with some kind of
    >> authorization authority//.  The processes by whichs/these
    >> keys\/certificates/the additional keys/ are obtained is outs=
ide
    >> the scope of this specification.

    Robert> <RCC>Authentication and authorization are two differ=
ent
    Robert> processes and I think you are confusing them. There is no
    Robert> need to mention authorization.</RCC>

No, I am not confusing the two, I am drawing attention to the fact that
the two have been intertwined.  I really know far too much about each of
them:  I have been asking questions about authorization for IPsec
systems since the IETF at 1996.
<RCC2>The two are intertwined but are still separate processes. Authorization is implicit in this case whether a symmetric or asymmetric key is used as the basis of authentication and key establishment.</RCC2>
 =20

What our protocol has done is to convey authorization to become a router
(vs a leaf node) by the possession of particular set of authentication
keys.   This is not unusual, all of the kerberos ticket system is
essentially built in this way.
<RCC2>Exactly, it's implicit. What's it got to do explicitly with asymmetric keys?</RCC2>
    >> 3.3.3.2 Link-Layer security
    >>=20
    >> The details of using link-layer security with RPL is subject=
 to a
    >> detailed explanation for each link-layer supported.
    >>=20
    >> For many link-layers it is an all-or-nothing connection: the=

    >> lower layers may not support providing information to upper
    >> layers about which encryption/authentication keys were used =
for
    >> reception, and they may not provide any controls to determin=
e
    >> which ones will be used for transmission.  This is a common
    >> situation for devices with radios connected via USB or other=

    >> commodity buses, where the radio in question simply presents=

    >> itself as ethernet.
    >>=20
    >> For such situations, the DODAG is considered to be in
    >> "pre-installed" mode, and the 'A' bit in the DODAG configura=
tion
    >> option should be cleared.

    Robert> <RCC>I do not think this section is necessary and I =
would
    Robert> not include it. Layers certainly do not share keys used fo=
r
    Robert> packet protection with other layers. There has to be an
    Robert> appropriate management interface at the layer service acce=
ss
    Robert> point (SAP) to allow manipulation of keys pertinent to tha=
t
    Robert> layer. If that interface is somehow not available to the
    Robert> overall management entity of the device, that is a design
    Robert> fault.</RCC>

Okay: I certainly agree it is a design fault.
I claim that this design fault is rather ubiquitous, and will lead to a
market fault when it turns out that everyone has to turn off layer-2
security in order to make things work.
<RCC2>We shall see...</RCC2>
--------------070205080409040108080405-- --------------ms070209050504030406010507 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwOTAyMjEwNjM0WjAjBgkqhkiG9w0BCQQxFgQUR7az +EeCk9vW8mLolWIDgCKCmowwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEATQ1lvpH2m/ZOduO9UX04lanMMUWIFyp7gM7+ pcqcaROwUgIeQCktxCUoPvAOeN6U//LD8OECTgvt3Z99fXE1jneeFtO/oPPPbpaRIQ2AE/Eu jhEtdMD0d/JfPN04ocMvFaHu2PtYcZ9icCY9IDD1L+DthUUAEHLU9h1GmvNeEkQJBYz0vQ/o tDBmjl2hhJ7EG1jbavWgUMNxs9C9NNWdFjOtx9l+9ILsP2epxPXeL/mWzAPEgZNUWZ+ncUqp XTL9WVleS9AoczL0V3axic37C+9fDrth7YLnIofxF6kPblCNUl7TgDeVH8O65BzCFKLrKFk7 SBTzhRamV5UydhUY6gAAAAAAAA== --------------ms070209050504030406010507-- From robert.cragie@gridmerge.com Fri Sep 3 01:59:54 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E9D43A6831 for ; Fri, 3 Sep 2010 01:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.608 X-Spam-Level: X-Spam-Status: No, score=-3.608 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mN0AHD0sx4Iz for ; Fri, 3 Sep 2010 01:59:52 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id EB1A83A6819 for ; Fri, 3 Sep 2010 01:59:51 -0700 (PDT) Received: from client-86-23-94-106.brhm.adsl.virginmedia.com ([86.23.94.106] helo=[192.168.1.66]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1OrS86-0006Vp-I3; Fri, 03 Sep 2010 10:00:15 +0100 Message-ID: <4C80B91E.2050200@gridmerge.com> Date: Fri, 03 Sep 2010 10:00:14 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Alexandru Petrescu References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> In-Reply-To: <4C80004B.4000305@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040808010901050901060409" Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 08:59:54 -0000 This is a cryptographically signed message in MIME format. --------------ms040808010901050901060409 Content-Type: multipart/alternative; boundary="------------060302020304090404060805" This is a multi-part message in MIME format. --------------060302020304090404060805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Alex, Comments below bracketed by . I have shortened the thread=20 content to highlight the salient points for clarity. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 02/09/2010 8:51 PM, Alexandru Petrescu wrote: >>>> >>>> The only issue that I see with the AH, is the size of the >>>> AH header, is a big header. But if we are talked of MAC security >>>> (IEEE 802.15.4-2006-MAC) lest just to leave the MIC (CBC-MAC) as >>>> is defined by the standard, and the MIC is just another field of >>>> the MAC frame like the field MFR. What do you think about this?. >>>> >>> >>> MAkes sense, one would like to avoid long additional data. >> >> Because we are talking about 6LoWPAN and the link-layer used at >> this moment is IEEE 802.15.4, it worth mentioning that RPL-ROLL is a >> draft at date, so is not bad idea to leave some bytes free, that is >> why, yes I think that make sense > > > I believe the discussion is mostly in the 802.15.4 context. However, > there is strong reluctance from stating so in the draft. E.g. > apparently PLC (powerline communications, different than 802.15.4) must= > be in the draft too. > > In this heterogeneous context it is very hard to agree that RPL is > _only_ for 802.15.4. > > I think I would be happier if the RPL draft said 802.15.4 explicitely, > and only it. Many decisions (in addition to security) would be easier.= 1. The discussion is in the context of ROLL, so the type of network is=20 lossy and low power. 802.15.4 is a specific type of lossy and low power=20 network. Therefore the draft should not refer specifically to 802.15.4=20 networks but to lossy and low power networks, which it does. 2. RPL security has nothing to do with 802.15.4 MAC security. They are=20 totally independent. A secured RPL frame with a MIC will just be payload = in an unsecured MAC frame, whatever that MAC happens to be. > >>> >>> Any more detail of comparison on length you would like to share? >>> >>> How long is a "big" header such as AH? And "big" compared to what? >>> Is it much bigger than the mandatory IPv6 base header? >> >> I think that is a "big" header because in the worse case, the >> link-layer 802.15.4 only gives 81 bytes for IPv6 data. > > WEll. That is an MTU problem (Maximum Transmission Unit) as seen by th= e > IPv6 stack. There are fragmentation solutions: the link-layer could > fragment, and I think it may be so. There is an RFC IPv6 over 802.15.4= > and I believe that requires IPv6 packets to be 1280bytes long: "The MTU= > size for IPv6 packets over IEEE 802.15.4 is 1280 octets." > >> I think a single RPL header takes more than 81 bytes How much bigger >> than the mandatory IPv6? We are in 6LoWPAN and an IPv6 header using >> IPHC can be as small as 3 bytes. > > Hm. Well... when you say "we are in 6lowpan"... > > IP Header Compression is good. I don't think we need to get too concerned over the size of the=20 auxiliary security octets. They will be similar for whatever is used. AH = is likely to be a bit larger as it conveys more information (SPI). > >> >> >>> >>> How much additional AH header bytes are added to an RPL (IPv6 base >>> + RPL ICMP) compared to putting the CBC-MAC in the same packet, as >>> an RPL field. I think that delta is 96bits (the AH specific fields, >>> figure 1 rfc4302). This is much shorter than the potentially >>> multiple 128bits of each IPv6 address potentially in a ROuting >>> Header of RPL. >> >> Why a node routing an IPv6 packet will apply security (in this >> case CCM*) over this packet? >> >> Only one CBC-MAC is put on the packet and only one, the >> originator node of the packet will insert the CBC-MAC, and the nodes >> routing the packet will modify the IPv6 header for the mutable >> fields, once the node destiny is reached this will set the mutable >> fields as rfc4302 and apply ccm* to decrypt. > > I agree with this principle: originator sets the MAC, intermediary node= s > touch the mutable fields, receiver recomputes MAC and checks. PRovided= > we agree to put 0 in the mutable fields both at reception and emission > and that we ack the attack risks on the mutable fields. > > IT is also good to set straight the order of MAC, Checksum and mutable > field computation: which is first, second, third, etc. See my other e-mail re. summary of concerns. > Reusing AH could help an RPL node to talk to a non-RPL node, >>> authenticated. >>> >> >> Sorry but I don't understand this part > > Sorry for being too concise, let me try to expand. > > RPL node sends data to a central server. Like a console querying senso= r > data. But that central server does not RPL. > > How is that IP communication secured? Big server PC would not run RPL,= > because not every IP node in the Internet runs RPL. > > One would think that RPL security would cover the > RPLnode-to-RPLEdgeRouter security and IPsec would cover > RPLEdgeRouter-to-CentralServer security. But IPsec security is often > indexed on the src and dst IP addresses of the packet, as "end-to-end" > security. This is a good think IMHO, because it is exposed to less > risks to intermediary nodes, lets the endnode be smart and the network = > dumb. > > It is important that the src and dst addresses of a data packet from an= > RPL node to a central server be themselves, and not some intermediary > edge router. If we follow this logic, then it is very hard to make > security work as two different sequential links: RPL up to edge router > and IPsec onwards, because edgerouter risks becoming a single point of > security failure, which is not good in distributed systems like Interne= t. > > I guess this was too long expansion. And I hope it's not flawed :-) > Moreover, as with all principle discussions it is subject to many > exceptions :-) RPL security is only used for securing RPL control messages. It is=20 not used for securing data messages conveyed through a RPL DODAG;=20 alternative security needs to be used, which could be link layer, IPSec, = TLS etc. RPL control messages will not go beyond the DODAG root. So the=20 scenario you are talking about will never happen wrt. RPL security.= --------------060302020304090404060805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex,

Comments below bracketed by <RCC></RCC>. I have shortened the thread content to highlight the salient points for clarity.

Robert

Robert Cragie (Pacific Gas & Electric)

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


On 02/09/2010 8:51 PM, Alexandru Petrescu wrote:

<RGB> The only issue that I see with the AH, is the size of the
AH header, is a big header. But if we are talked of MAC security
(IEEE 802.15.4-2006-MAC) lest just to leave the MIC (CBC-MAC) as
is defined by the standard, and the MIC is just another field of
the MAC frame like the field MFR. What do you think about this?.
</RGB>

MAkes sense, one would like to avoid long additional data.

<RGB2>Because we are talking about 6LoWPAN and the link-layer used at
 this moment is IEEE 802.15.4, it worth mentioning that RPL-= ROLL is a
 draft at date, so is not bad idea to leave some bytes free,= that is
why, yes I think that make sense</RGB2>


I believe the discussion is mostly in the 802.15.4 context.  However,
there is strong reluctance from stating so in the draft.  E.g.=
apparently PLC (powerline communications, different than 802.15.4) must
be in the draft too.

In this heterogeneous context it is very hard to agree that RPL is
_only_ for 802.15.4.

I think I would be happier if the RPL draft said 802.15.4 explicitely,
and only it.  Many decisions (in addition to security) would b= e easier.
<RCC>
1. The discussion is in the context of ROLL, so the type of network is lossy and low power. 802.15.4 is a specific type of lossy and low power network. Therefore the draft should not refer specifically to 802.15.4 networks but to lossy and low power networks, which it does.
2. RPL security has nothing to do with 802.15.4 MAC security. They are totally independent. A secured RPL frame with a MIC will just be payload in an unsecured MAC frame, whatever that MAC happens to be. </RCC>


Any more detail of comparison on length you would like to share?

How long is a "big" header such as AH? And "big" compared to what?
Is it much bigger than the mandatory IPv6 base header?

<RGB2>I think that is a "big" header because in the worse case, the
link-layer 802.15.4 only gives 81 bytes for IPv6 data.

WEll.  That is an MTU problem (Maximum Transmission Unit) as s= een by the
IPv6 stack.  There are fragmentation solutions: the link-layer= could
fragment, and I think it may be so.  There is an RFC IPv6 over= 802.15.4
and I believe that requires IPv6 packets to be 1280bytes long: "The MTU
size for IPv6 packets over IEEE 802.15.4 is 1280 octets."

I think a single RPL header takes more than 81 bytes How much bigger
than the mandatory IPv6? We are in 6LoWPAN and an IPv6 header using
IPHC can be as small as 3 bytes.

Hm.  Well... when you say "we are in 6lowpan"...

IP Header Compression is good.
<RCC>I don't think we need to get too concerned over the size of the auxiliary security octets. They will be similar for whatever is used. AH is likely to be a bit larger as it conveys more information (SPI).</RCC>

</RGB2>


How much additional AH header bytes are added to an RPL (IPv6 base
+ RPL ICMP) compared to putting the CBC-MAC in the same packet, as
an RPL field. I think that delta is 96bits (the AH specific fields,
 figure 1 rfc4302). This is much shorter than the potentia= lly
multiple 128bits of each IPv6 address potentially in a ROuting
Header of RPL.

<RGB2>Why a node routing an IPv6 packet will apply security (in this
 case CCM*) over this packet?</RGB2>

<RGB2>Only one CBC-MAC is put on the packet and only one, the
originator node of the packet will insert the CBC-MAC, and the nodes
routing the packet will modify the IPv6 header for the mutable
fields, once the node destiny is reached this will set the mutable
fields as rfc4302 and apply ccm* to decrypt. </RGB2>

I agree with this principle: originator sets the MAC, intermediary nodes
touch the mutable fields, receiver recomputes MAC and checks. = PRovided
we agree to put 0 in the mutable fields both at reception and emission
and that we ack the attack risks on the mutable fields.

IT is also good to set straight the order of MAC, Checksum and mutable
field computation: which is first, second, third, etc.
<RCC>See my other e-mail re. summary of concerns.</RCC>
Reusing AH could help an RPL node to talk to a non-RPL node,
authenticated.


<RGB2>Sorry but I don't understand this part</RGB2>

Sorry for being too concise, let me try to expand.

RPL node sends data to a central server.  Like a console query= ing sensor
data.  But that central server does not RPL.

How is that IP communication secured?  Big server PC would not= run RPL,
because not every IP node in the Internet runs RPL.

One would think that RPL security would cover the
RPLnode-to-RPLEdgeRouter security and IPsec would cover
RPLEdgeRouter-to-CentralServer security.  But IPsec security i= s often
indexed on the src and dst IP addresses of the packet, as "end-to-end"
security.  This is a good think IMHO, because it is exposed to= less
risks to intermediary nodes, lets the endnode be smart and the network dumb.

It is important that the src and dst addresses of a data packet from an
RPL node to a central server be themselves, and not some intermediary
edge router.  If we follow this logic, then it is very hard to= make
security work as two different sequential links: RPL up to edge router
and IPsec onwards, because edgerouter risks becoming a single point of
security failure, which is not good in distributed systems like Internet.

I guess this was too long expansion.  And I hope it's not flaw= ed :-)
Moreover, as with all principle discussions it is subject to many
exceptions :-)
<RCC>RPL security is only used for securing RPL control messages. It is not used for securing data messages conveyed through a RPL DODAG; alternative security needs to be used, which could be link layer, IPSec, TLS etc. RPL control messages will not go beyond the DODAG root. So the scenario you are talking about will never happen wrt. RPL security.</RCC>

--------------060302020304090404060805-- --------------ms040808010901050901060409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwOTAzMDkwMDE0WjAjBgkqhkiG9w0BCQQxFgQUG6Ae Y9GWwWJJXG5SIBSSH1lS2XgwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEADQqZr+IErFgFUaJkydNQ+ExJQqz6VMFIrYev sfY9tjcVSw/ZKsAq54ap6aSRnTuK9NICPJmL48I6stilcbK7tkTx+Be+cqYCJ+nXr5r0m2MV wGaSlEMaoF7XmeDA3YDGooupm8lOYd/aUm6dLkwzeiieYW9A0rAVF+2Hj1H9PGRaX7YD8FVr UJXgkfG4blG2I+xAZVOJkaw7UILlE+vhkv5XeFkUl9nCrOxd1eOTr+TR/tKnnZ1PBRPlllvl eOIdGfJ5bPzq58XPVyTOF9TAydTjyWzRtC6p7KU8qLKjsWHDVq1NxHLhK7I4vvSWcqSJz5J7 tPNs7hE+rnobglD04AAAAAAAAA== --------------ms040808010901050901060409-- From alexandru.petrescu@gmail.com Fri Sep 3 02:23:11 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 141233A684D for ; Fri, 3 Sep 2010 02:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.122 X-Spam-Level: X-Spam-Status: No, score=-2.122 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQjuS19N-SYh for ; Fri, 3 Sep 2010 02:23:10 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id E1D463A683E for ; Fri, 3 Sep 2010 02:23:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o839NbXd001156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Sep 2010 11:23:37 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o839NbDg020632; Fri, 3 Sep 2010 11:23:37 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o839NaEk010488; Fri, 3 Sep 2010 11:23:37 +0200 Message-ID: <4C80BE98.80904@gmail.com> Date: Fri, 03 Sep 2010 11:23:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> In-Reply-To: <4C80B91E.2050200@gridmerge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 03 Sep 2010 09:23:11 -0000 Le 03/09/2010 11:00, Robert Cragie a écrit : [...] > RPL security is only used for securing RPL control messages. It > is not used for securing data messages conveyed through a RPL DODAG; > alternative security needs to be used, which could be link layer, > IPSec, TLS etc. RPL control messages will not go beyond the DODAG > root. So the scenario you are talking about will never happen wrt. > RPL security. Yes, data packets are not covered by RPL security, and RPL control packets do not go outside the RPL 'domain'. We could however consider two detail points: Edge Router to Edge Router communication of RPL messages via the backbone: should it be RPL security or IPsec? It is redundant for an RPL node to implement both IPsec (to secure data packets) and RPL security. This may be different keying schemes, double the data structure size, and additional security risks. As a matter of related protocols widely deployed: many protocols at network layer whose goal is not security (ospf, mobile ip, dhcp, icmp) are secured with IPsec AH and ESP. RPL is an ICMP Type. I don't see why RPL not be secured by IPsec. Reusing the IPsec module ensures a secure system - it's proven by earlier experience. We know it worked ok so why avoid using it. Paraphernalia IPsec - I will reply separately. Alex From robert.cragie@gridmerge.com Fri Sep 3 04:48:24 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14D283A685B for ; Fri, 3 Sep 2010 04:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.607 X-Spam-Level: X-Spam-Status: No, score=-3.607 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejp539znvNRl for ; Fri, 3 Sep 2010 04:48:21 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id D5FC33A6861 for ; Fri, 3 Sep 2010 04:48:20 -0700 (PDT) Received: from client-86-23-94-106.brhm.adsl.virginmedia.com ([86.23.94.106] helo=[192.168.1.66]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1OrUlB-0004Zf-I2; Fri, 03 Sep 2010 12:48:46 +0100 Message-ID: <4C80E09D.5040702@gridmerge.com> Date: Fri, 03 Sep 2010 12:48:45 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Alexandru Petrescu References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> In-Reply-To: <4C80BE98.80904@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030905090202030402000307" Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 11:48:24 -0000 This is a cryptographically signed message in MIME format. --------------ms030905090202030402000307 Content-Type: multipart/alternative; boundary="------------030701030402080508050806" This is a multi-part message in MIME format. --------------030701030402080508050806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Alex, Comments inline, bracketed by Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 03/09/2010 10:23 AM, Alexandru Petrescu wrote: > Le 03/09/2010 11:00, Robert Cragie a =E9crit : > [...] >> RPL security is only used for securing RPL control messages. It >> is not used for securing data messages conveyed through a RPL DODAG; >> alternative security needs to be used, which could be link layer, >> IPSec, TLS etc. RPL control messages will not go beyond the DODAG >> root. So the scenario you are talking about will never happen wrt. >> RPL security. > > Yes, data packets are not covered by RPL security, and RPL control > packets do not go outside the RPL 'domain'. > > We could however consider two detail points: > > Edge Router to Edge Router communication of RPL messages via the > backbone: should it be RPL security or IPsec? I think Pascal has done some work in the area of extending DODAGs=20 across backbones. My initial impression was that it seemed overly=20 complex and unnecessary, nevertheless I would defer to him regarding the = appropriate topology and domain clarification and therefore how to=20 secure it appropriately. > > It is redundant for an RPL node to implement both IPsec (to secure data= > packets) and RPL security. This may be different keying schemes, doubl= e > the data structure size, and additional security risks. I agree > > As a matter of related protocols widely deployed: many protocols at > network layer whose goal is not security (ospf, mobile ip, dhcp, icmp) > are secured with IPsec AH and ESP. RPL is an ICMP Type. I don't see > why RPL not be secured by IPsec. Me neither. > > Reusing the IPsec module ensures a secure system - it's proven by > earlier experience. We know it worked ok so why avoid using it. I don't think the specification of RPL security precludes the use=20 of IPSec instead. Does the use of IPSec need to be specified in the RPL=20 specification? --------------030701030402080508050806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex,

Comments inline, bracketed by <RCC></RCC>

Robert

Robert Cragie (Pacific Gas & Electric)

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


On 03/09/2010 10:23 AM, Alexandru Petrescu wrote:
Le 03/09/2010 11:00, Robert Cragie a écrit :
[...]
<RCC>RPL security is only used for securing RPL control messages. It
is not used for securing data messages conveyed through a RPL DODAG;
alternative security needs to be used, which could be link layer,
IPSec, TLS etc. RPL control messages will not go beyond the DODAG
root. So the scenario you are talking about will never happen wrt.
RPL security.</RCC>

Yes, data packets are not covered by RPL security, and RPL control
packets do not go outside the RPL 'domain'.

We could however consider two detail points:

Edge Router to Edge Router communication of RPL messages via the
backbone: should it be RPL security or IPsec?
<RCC>I think Pascal has done some work in the area of extending DODAGs across backbones. My initial impression was that it seemed overly complex and unnecessary, nevertheless I would defer to him regarding the appropriate topology and domain clarification and therefore how to secure it appropriately.</RCC>

It is redundant for an RPL node to implement both IPsec (to secure data
packets) and RPL security.  This may be different keying schem= es, double
the data structure size, and additional security risks.
<RCC>I agree</RCC>

As a matter of related protocols widely deployed: many protocols at
network layer whose goal is not security (ospf, mobile ip, dhcp, icmp)
are secured with IPsec AH and ESP.  RPL is an ICMP Type. = I don't see
why RPL not be secured by IPsec.
<RCC>Me neither.</RCC>

Reusing the IPsec module  ensures a secure system - it's prove= n by
earlier experience.  We know it worked ok so why avoid using i= t.
<RCC>I don't think the specification of RPL security precludes the use of IPSec instead. Does the use of IPSec need to be specified in the RPL specification?</RCC>

--------------030701030402080508050806-- --------------ms030905090202030402000307 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwOTAzMTE0ODQ1WjAjBgkqhkiG9w0BCQQxFgQUSEWl rAQ9JPgtB0xranaX+vpJ6k0wXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAj2CbGkcxBkM3z/fqLDsN0wat7ow3QepjUFR0 yRuDMSiE+LdJzAz0u5JNyCJw4IQlOmqhLiis7657F6WD8XoWZp7qUZ+9EYJ1xKIdet19BO8m TG6aHzwD01iXX62j/Ir6Kh7WYT6i5stgITigLlOZorQu02iMva/nRhApvgJjrWv7Qu5DbEh+ wOZBqu6A7Qf5QvOkzWTu5yO0YaZdFO9ZH2QWjle4qtXxUeDu8h4uJiNNm0EwdJ4k35e7pOFe 3zhsENc0AeFh9cnDKNMKYyBMaU9lKURSmW0I5okMsEp/I8Ss3sgiRmA3Usv56Wn5eSbsh3l4 kG8SKE0OxezLK1moOAAAAAAAAA== --------------ms030905090202030402000307-- From alexandru.petrescu@gmail.com Fri Sep 3 08:37:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9211F3A68FA for ; Fri, 3 Sep 2010 08:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIUVYjz+0j2z for ; Fri, 3 Sep 2010 08:37:33 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 1E7AE3A68F8 for ; Fri, 3 Sep 2010 08:37:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o83Fbv1s029104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Sep 2010 17:37:57 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o83Fbv69017845; Fri, 3 Sep 2010 17:37:57 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.173] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o83FbvPR028019; Fri, 3 Sep 2010 17:37:57 +0200 Message-ID: <4C811655.5000008@gmail.com> Date: Fri, 03 Sep 2010 17:37:57 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> In-Reply-To: <4C80E09D.5040702@gridmerge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 03 Sep 2010 15:37:35 -0000 Le 03/09/2010 13:48, Robert Cragie a écrit : [skipped agreed opinions about IPsec] >> Reusing the IPsec module ensures a secure system - it's proven by >> earlier experience. We know it worked ok so why avoid using it. > > I don't think the specification of RPL security precludes the > use of IPSec instead. Does the use of IPSec need to be specified in > the RPL specification? YEs, the RPL specification must say something about security in its Security Considerations section. That something has to mention something about IPsec. RPL draft is currently silent about IPsec, AH and their respective RFCs. Silence about IPsec in the core RPL spec is not good. There are several ways to put this, but IPsec must be there somehow. One way I tend to disagree with is to start list all the mutable fields, mutable but predictable, replay protection, etc. and rebuild that IPsec behaviour within RPL security. That is a very good first step, but would it be quick enough to agree on? One way I could agree with is something like "Securing RPL messages can be achieved by: IPsec, link-layer security, and RPL-AES-CCM MAC field in RPL header; in that order of preference". Of course things may vary, if we see some example tendency text I could say whether I agree or not. Alex From pekkas@netcore.fi Thu Sep 2 22:53:55 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0B63A66B4; Thu, 2 Sep 2010 22:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_FROM=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHUnoBzL+qjD; Thu, 2 Sep 2010 22:53:54 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id C30413A659A; Thu, 2 Sep 2010 22:53:53 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id o835sHVU008797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Sep 2010 08:54:17 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id o835sGUn008793; Fri, 3 Sep 2010 08:54:16 +0300 Date: Fri, 3 Sep 2010 08:54:16 +0300 (EEST) From: Pekka Savola To: ietf@ietf.org In-Reply-To: <20100818222846.13825.49680.idtracker@localhost> Message-ID: References: <20100818222846.13825.49680.idtracker@localhost> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.96.1 at otso.netcore.fi X-Virus-Status: Clean X-Mailman-Approved-At: Fri, 03 Sep 2010 08:43:30 -0700 Cc: roll@ietf.org, draft-ietf-roll-rpl@tools.ietf.org, roll-chairs@tools.ietf.org Subject: Re: [Roll] Last Call: (RPL: IPv6 Routing Protocol for Low power and Lossy Networks) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 03 Sep 2010 05:53:55 -0000 On Wed, 18 Aug 2010, The IESG wrote: > The IESG has received a request from the Routing Over Low power and Lossy > networks WG (roll) to consider the following document: > - 'RPL: IPv6 Routing Protocol for Low power and Lossy Networks' > as a Proposed Standard I've done a solicited but superficial ops-dir review of draft-ietf-roll-rpl-11. Given the document length (139p) I've had to skim most of it. The IETF Last Call expired two days ago, but for information I'm still copying the IETF list, even though this review is mainly for O&M ADs' and secondarily ROLL WG benefit. A couple of comments: In general, ROLL problem space seems to be very similar to MANETs, and I wonder why a separate protocol needed to be developed here, especially given the amount of scientific research and also IETF effort put into MANETs. ROLL WG charter certainly does not mention this. Copying/modifying various IPv6 ND options for this purpose may be required but I wonder if this could have been done in a simpler fashion, without having to copy the specifications here. For example, using a TLV container option that includes non-TLV options as-is. The document mentions uniquely identifying a DODAG by the use of an IPv6 address. The document does not mention what addresses are to be used for this purpose, how they are assigned, and how these are expected to be unique. (Compare to documents on MANET IPv6 address assignments.) In S 11 on Packet Forwarding: 1. This specification only covers how a successor is selected from the DODAG Version that matches the RPLInstanceID marked in the IPv6 header of the packet being forwarded. [...] ... How is RPLInstanceID marked in the IPv6 header of the packet being forwarded? Are you modifying IPv6 packet forwarding and processing algorithms here (must look into the packets)? That would be a major change. (You're really referring to the hop-by-hop header processing here.) In general the document doesn't seem to be sufficiently upfront on the basic semantics how RPL is going to be used (from "non-RPL" perspective). One could argue Section 3 (some 12 pages) tries to provide an overview, but from IP perspective, it provides too much detail on e.g. tree forming and maintenance. The most important things to bring up clearly should be for example: (1) are there changes to existing packet formats or usage (e.g. does every packet include some kind of header, does this affect MTU usable in the network)?, (2) is support for these required at each node in the network, (3) are there changes to the basic packet processing in associated nodes? Upon closer inspection, some answers to these high-level questions can be found in first paragraph of S 3.3.7 and the last paragraph of S 5, but I'd really have wanted to see one or two paragraphs in Introduction. ... It is a bit strange to see that S 17 on manageability does not mention security management, because one of the key problems there (as argued in the draft as well) is how do you manually configure and maintain shared keys on all these devices. From mcr@sandelman.ca Fri Sep 3 09:01:32 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D97053A690A; Fri, 3 Sep 2010 09:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_05=-1.11, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4dbI-UXOxrE; Fri, 3 Sep 2010 09:01:31 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 9E1513A68DD; Fri, 3 Sep 2010 09:01:31 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 991E534752; Fri, 3 Sep 2010 12:02:00 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id A301D98AA6; Fri, 3 Sep 2010 12:01:59 -0400 (EDT) From: Michael Richardson To: Pekka Savola In-Reply-To: References: <20100818222846.13825.49680.idtracker@localhost> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 03 Sep 2010 12:01:59 -0400 Message-ID: <29670.1283529719@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org, ietf@ietf.org, draft-ietf-roll-rpl@tools.ietf.org, roll-chairs@tools.ietf.org Subject: Re: [Roll] Last Call: (RPL: IPv6 Routing Protocol for Low power and Lossy Networks) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 03 Sep 2010 16:01:32 -0000 Thank you for your review. >>>>> "Pekka" == Pekka Savola writes: Pekka> In S 11 on Packet Forwarding: Pekka> 1. This specification only covers how a successor is Pekka> selected from the DODAG Version that matches the Pekka> RPLInstanceID marked in the IPv6 header of the packet being Pekka> forwarded. [...] Pekka> ... How is RPLInstanceID marked in the IPv6 header of the Pekka> packet being forwarded? Are you modifying IPv6 packet Pekka> forwarding and processing algorithms here (must look into the Pekka> packets)? That would be a major change. (You're really Pekka> referring to the hop-by-hop header processing here.) So, this is a signficant but as yet unsolved problem. No details of the RPL protocol itself depend upon how in, the end, the packets are marked. At the beginning, many of us thought that the FlowLabel was the right thing to use. And it works very well as long as the RPL network does not need to interact with other networks. Applications that run on RPL nodes that need a non-default behaviour need to be aware of what RPLinstanceID to pick (and this is a provionsing issue), and thus it will in fact be the application setting the flow label, not an intermediate node. Pekka> It is a bit strange to see that S 17 on manageability does Pekka> not mention security management, because one of the key Pekka> problems there (as argued in the draft as well) is how do you Pekka> manually configure and maintain shared keys on all these Pekka> devices. I agree that it is a concern --- most of the deployment scenarios (which are in a series of RFCs published by the WG last fall) are installed by a single contractor into a single commercial-building/house/factor/power-transmission-system They initialize all the devices in the test lab, and then deploy them. I think this is because 90% of the participants in the group think that link-layer security provided by Zigbee is going to solve all of their problems. I am very skeptical about this. -- ] 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 stoleru@cse.tamu.edu Sat Sep 4 23:14:02 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D875B3A68C8 for ; Sat, 4 Sep 2010 23:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.75 X-Spam-Level: * X-Spam-Status: No, score=1.75 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_99=3.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HSHos1bqU8f for ; Sat, 4 Sep 2010 23:14:01 -0700 (PDT) Received: from smtp.cs.tamu.edu (smtp.cs.tamu.edu [128.194.138.107]) by core3.amsl.com (Postfix) with ESMTP id 854303A68C6 for ; Sat, 4 Sep 2010 23:14:01 -0700 (PDT) Received: from [128.194.143.227] (radu-pc.cs.tamu.edu [128.194.143.227]) by smtp.cs.tamu.edu (Postfix) with ESMTP id B381A1902A4 for ; Sun, 5 Sep 2010 01:14:30 -0500 (CDT) Message-ID: <4C833546.5010308@cse.tamu.edu> Date: Sun, 05 Sep 2010 01:14:30 -0500 From: Radu Stoleru User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sun, 05 Sep 2010 10:44:13 -0700 Subject: [Roll] ACM SenSys 2010: Call for Participation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 05 Sep 2010 06:14:02 -0000 Please note early registration is open and runs until October 6th. Apologies if you receive multiple copies. ============================================================ ACM SenSys 2010: Call for Participation The 8th ACM Conference on Embedded Networked Sensor Systems November 3-5, 2010 Workshops: November 2nd, 2010 Zurich, Switzerland http://sensys.acm.org/2010/ ============================================================ Sponsored by SIGCOMM, SIGMOBILE, SIGARCH, SIGOPS, SIGMETRICS, SIGBED and NSF. The 8th ACM Conference on Embedded Networked Sensor Systems (SenSys 2010) is a highly selective, single-track forum for the presentation of research results on systems issues in the area of embedded, networked sensors. Distributed systems based on networked sensors and actuators with embedded computation capabilities allow for an instrumentation of the physical world at an unprecedented scale and density, thus enabling a new generation of monitoring and control applications. SenSys provides a cross-disciplinary venue for researchers addressing the rich space of networked sensor system design issues to interact, present and exchange research results, and demonstrate their work in a hands-on research exhibition. ============================================================ Workshops: November 2nd, 2010 This year a Doctoral Colloquium and two workshops will be held in conjunction with SenSys: BuildSys 2010: Second ACM Workshop On Embedded Sensing Systems For Energy-Efficiency In Buildings PhoneSense: International Workshop on Sensing for App Phones ============================================================ SenSys 2010 Organizing Committee: General Chair: Jan Beutel (ETH Zürich) Program Chairs: Deepak Ganesan (UMass Amherst), John Stankovic (University of Virginia) Poster Chairs: Pedro Jose Marron (University of Duisburg-Essen and Fraunhofer IAIS), Guillermo Barrenetxea (EPFL) Demo Chairs: Pei Zhang (CMU), John Regehr (Utah) Steering Committee Chair: Matt Welsh (Harvard University) Local Arrangements Chair: Matthias Woehrle (ETH Zurich) Registration Chair: Philipp Sommer (ETH Zurich) Finance Chair: Monica Fricker (ETH Zurich) Publicity Chair: Radu Stoleru (Texas A&M), Niels Brouwers (TU Delft) Publication Chair: Affan Syed (USC/ISI) Workshop Chair: Antonio Ruzzelli (University College Dublin) N2Women Chair: Anna Foerster (NetLab-SUPSI) Sponsorship Chair: Luca Mottola (SICS) Doctoral Colloquium Chair: Kay Roemer (University of Luebeck and ETH Zurich) Student Travel/Awards Chair: Geoffrey Werner Challen (Harvard University) (NSF-sponsored travel grants will be available with further details shortly). Web Site Chair: Xiaofan Jiang (UC Berkeley) Program Committee: Anish Arora (Ohio State University), Alberto Cerpa (UC Merced), Tanzeem Choudhary (Dartmouth University), Romit Roy Choudhury (Duke University), David Culler (UC Berkeley), Phil Gibbons (Intel Research Pittsburgh), Rick Han (University of Colorado Boulder), Tian He (University of Minnesota), Polly Huang (National Taiwan University), Bhaskar Krishnamachari (University of Southern California), Koen Langendoen (TU Delft), Akos Ledeczi (Vanderbilt University), Suman Nath (Microsoft Research), Raj Rajkumar (Carnegie Mellon University), Umakishore Ramachandran (Georgia Tech), Jakob Eriksson (UIC), Kay Roemer (University of Lubeck and ETH Zurich), Andreas Savvides (Yale University), Jacky Shen (Microsoft Research Asia), Prashant Shenoy (UMass Amherst), Cormac Sreenan (University College Cork), Kamin Whitehouse (University of Virginia), Adam Wolisz (TU Berlin) From jpv@cisco.com Sun Sep 5 10:27:28 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DED43A682B for ; Sun, 5 Sep 2010 10:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.815 X-Spam-Level: X-Spam-Status: No, score=-107.815 tagged_above=-999 required=5 tests=[AWL=-2.117, BAYES_50=0.001, HTML_MESSAGE=0.001, MANGLED_WANT=2.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOiAZd8dVVnu for ; Sun, 5 Sep 2010 10:27:14 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A148E3A6822 for ; Sun, 5 Sep 2010 10:27:14 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocGAA1wg0xAaMHG/2dsb2JhbACTb4UmAYgCcZ41jHWOA4JuARIIgjQEhRSFBIJ+h3I9 X-IronPort-AV: E=Sophos;i="4.56,321,1280707200"; d="scan'208,217";a="181727410" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 05 Sep 2010 17:27:36 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o85HQqb3027353; Sun, 5 Sep 2010 17:27:34 GMT Received: from xfe-bgl-411.cisco.com ([72.163.129.199]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 5 Sep 2010 22:57:05 +0530 Received: from [80.124.208.90] ([10.61.93.200]) by xfe-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 5 Sep 2010 22:56:56 +0530 From: JP Vasseur Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-2-456749292 Date: Sun, 5 Sep 2010 19:10:27 +0200 To: ROLL WG , Tzeta Tsao , Roger Alexander , Mischa Dohler , vanesa.daza@upf.edu, Angel Lozano Message-Id: X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 05 Sep 2010 17:26:56.0767 (UTC) FILETIME=[8A2C38F0:01CB4D1F] X-Mailman-Approved-At: Sun, 05 Sep 2010 10:44:13 -0700 Subject: [Roll] Review Comments on draft-ietf-roll-security-framework X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 05 Sep 2010 17:27:28 -0000 --Apple-Mail-2-456749292 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Please find below some detailed comments - Overall well-written = document. In addition to the comments in-line (search for JP>), I would welcome a = few diagrams especially when you describe the different types of attacks. = Furthermore, as you will see in the comments, be careful not to make the assumption = of wireles links (there are many LLNs with wireless links of course) but this is = not the only=20 type of links. Same comment for the node type (they are not all battery = operated). Thanks ! I will open a ticket capturing all of the comments below. JP> Starting with ID nits: Checking references for intended status: Informational = --------------------------------------------------------------------------= -- =3D=3D Outdated reference: draft-ietf-roll-building-routing-reqs has = been published as RFC 5867 =3D=3D Outdated reference: draft-ietf-roll-home-routing-reqs has been = published as RFC 5826 =3D=3D Outdated reference: A later version (-11) exists of draft-ietf-roll-rpl-07 Networking Working Group T. Tsao, Ed. Internet-Draft R. Alexander, Ed. Intended status: Informational Eka Systems Expires: October 1, 2010 M. Dohler, Ed. CTTC V. Daza, Ed. A. Lozano, Ed. Universitat Pompeu Fabra March 30, 2010 A Security Framework for Routing over Low Power and Lossy Networks draft-ietf-roll-security-framework-00 Abstract This document presents a security framework for routing over low power and lossy networks. =20 JP> Add acronym (LLN) The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and evaluating the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. As an illustration, this framework is applied to RPL. JP> Expand acronym when first used (LLN here). Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Tsao, et al. Expires October 1, 2010 [Page 1] =0C Internet-Draft Security Framework for ROLL March 2010 The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 1, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Tsao, et al. Expires October 1, 2010 [Page 2] =0C Internet-Draft Security Framework for ROLL March 2010 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Considerations on ROLL Security . . . . . . . . . . . . . . . 5 3.1. Routing Assets and Points of Access . . . . . . . . . . . 6 3.2. The CIA Security Reference Model . . . . . . . . . . . . . 8 3.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 9 3.4. ROLL Security Objectives . . . . . . . . . . . . . . . . . 11 4. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 12 4.1. Threats and Attacks on Confidentiality . . . . . . . . . . 12 4.1.1. Routing Exchange Exposure . . . . . . . . . . . . . . 12 4.1.2. Routing Information (Routes and Network Topology) Exposure . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Threats and Attacks on Integrity . . . . . . . . . . . . . 13 4.2.1. Routing Information Manipulation . . . . . . . . . . . 14 4.2.2. Node Identity Misappropriation . . . . . . . . . . . . 14 4.3. Threats and Attacks on Availability . . . . . . . . . . . 15 4.3.1. Routing Exchange Interference or Disruption . . . . . 15 4.3.2. Network Traffic Forwarding Disruption . . . . . . . . 15 4.3.3. Communications Resource Disruption . . . . . . . . . . 15 4.3.4. Node Resource Exhaustion . . . . . . . . . . . . . . . 16 5. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Confidentiality Attack Countermeasures . . . . . . . . . . 17 5.1.1. Countering Deliberate Exposure Attacks . . . . . . . . 17 5.1.2. Countering Sniffing Attacks . . . . . . . . . . . . . 17 5.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 19 5.1.4. Countering Physical Device Compromise . . . . . . . . 19 5.1.5. Countering Remote Device Access Attacks . . . . . . . 21 5.2. Integrity Attack Countermeasures . . . . . . . . . . . . . 21 5.2.1. Countering Tampering Attacks . . . . . . . . . . . . . 22 5.2.2. Countering Overclaiming and Misclaiming Attacks . . . 22 5.2.3. Countering Identity (including Sybil) Attacks . . . . 22 5.2.4. Countering Routing Information Replay Attacks . . . . 23 5.2.5. Countering Byzantine Routing Information Attacks . . . 23 5.3. Availability Attack Countermeasures . . . . . . . . . . . 24 5.3.1. Countering HELLO Flood Attacks and ACK Spoofing Attacks . . . . . . . . . . . . . . . . . . . . . . . 24 5.3.2. Countering Overload Attacks . . . . . . . . . . . . . 26 5.3.3. Countering Selective Forwarding Attacks . . . . . . . 27 5.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 27 5.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 28 6. ROLL Security Features . . . . . . . . . . . . . . . . . . . . 28 6.1. Confidentiality Features . . . . . . . . . . . . . . . . . 29 6.2. Integrity Features . . . . . . . . . . . . . . . . . . . . 30 6.3. Availability Features . . . . . . . . . . . . . . . . . . 31 6.4. Additional Related Features . . . . . . . . . . . . . . . 31 6.5. Consideration on Matching Application Domain Needs . . . . 31 Tsao, et al. Expires October 1, 2010 [Page 3] =0C Internet-Draft Security Framework for ROLL March 2010 6.5.1. Security Architecture . . . . . . . . . . . . . . . . 32 6.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 34 7. Application of ROLL Security Framework to RPL . . . . . . . . 36 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 11.1. Normative References . . . . . . . . . . . . . . . . . . . 38 11.2. Informative References . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Tsao, et al. Expires October 1, 2010 [Page 4] =0C Internet-Draft Security Framework for ROLL March 2010 1. Terminology This document conforms to the terminology defined in [I-D.ietf-roll-terminology]. JP> There are other terms used in the document that could be added here (see below). 2. Introduction In recent times, networked wireless devices have found an increasing number of applications in various fields. Yet, for reasons ranging from operational application to economics, these wireless devices=20 JP> This does not apply only to wireless links (e.g. PLC) are often supplied with minimum physical resources, e.g., limited power reserve, slow speed or low capability computation, or small memory size. As a consequence, the resulting networks are more prone to loss of traffic and other vulnerabilities. The proliferation of these low power and lossy networks (LLNs), however, are drawing efforts to examine and address their potential networking challenges. This document presents a framework for securing routing over low power and lossy networks (ROLL) JP> s/ROLL/LLN through an analysis that starts from the routing basics. The objective is two-fold. First, the framework will be used to identify pertinent security issues. Second, it will facilitate both the assessment of a protocol's security threats and the identification of the necessary features for development of secure protocols for ROLL. JP> s/ROLL/The ROLL Working Group. The approach adopted in this effort proceeds in four steps, to examine ROLL security issues, to analyze threats and attacks, to consider the countermeasures, and then to make recommendations for securing ROLL. JP> Could you just replace "ROLL" by the "the routing protocol developed=20= by the ROLL Working Group" or Define ROLL as Routing Over Low power and Lossy networks. The basis is found on identifying the assets and points of access of routing and evaluating their security needs based on the Confidentiality, Integrity, and Availability (CIA) model in the context of LLN. The utility of this framework is demonstrated with an application to RPL [I-D.ietf-roll-rpl]. 3. Considerations on ROLL Security This section sets the stage for the development of the framework by applying the systematic approach proposed in [Myagmar2005] to the routing security problem, while also drawing references from other reviews and assessments found in the literature, particularly, [RFC4593] and [Karlof2003]. The subsequent subsections begin with a focus on the elements of a generic routing process that is used to establish routing assets and points of access of the routing functionality. Next, the CIA security model is briefly described. Then, consideration is given to issues specific to or amplified in LLNs. This section concludes with the formulation of a set of Tsao, et al. Expires October 1, 2010 [Page 5] =0C Internet-Draft Security Framework for ROLL March 2010 security objectives for ROLL. 3.1. Routing Assets and Points of Access An asset implies important system component (including information, process, or physical resource), the access to, corruption or loss of which adversely affects the system. In network routing, assets lie in the routing information, routing process, and node's physical resources. That is, the access to, corruption, or loss of these elements adversely affects system routing. In network routing, a point of access refers to the point of entry facilitating communication with or other interaction with a system component in order to use system resources to either manipulate information or gain knowledge of the information contained within the system. Security of the routing protocol must be focused on the assets of the routing nodes and the points of access of the information exchanges and information storage that may permit routing compromise. The identification of routing assets and points of access hence provides a basis for the identification of associated threats and attacks. This subsection identifies assets and points of access of a generic routing process with a level-0=20 JP> Explain what you mean by "level-0" data flow diagram. The use of the data flow diagram allows for a clear, concise model of the routing functionality; it also has the benefit of showing the manner in which nodes participate in the routing process, thus providing context when later threats and attacks are considered. The goal of the model is to be as detailed as possible so that corresponding components and mechanisms in an individual routing protocol can be readily identified, but also to be as general as possible to maximize the relevancy of this effort for the various existing and future protocols. Nevertheless, there may be discrepancies, likely in the form of additional elements, when the model is applied to some protocols. For such cases, the analysis approach laid out in this document should still provide a valid and illustrative path for their security assessment. Figure 1 shows that nodes participating in the routing process transmit messages to determine their neighbors (neighbor discovery). Using the neighboring relationships, routing protocols may exchange network topology (including link-specific information) to generate routes or may exchange routes directly as part of a routing exchange; nodes which do not directly participate in the process with a given node will get the route/topology information relayed from others. =20 JP> You can remove the previous sentence (no need to make assumption in in a framework on the mode of operation of the routing protocol). It is likely that a node will store some or all of the routes and topology information according to tradeoffs of node resources and latency associated with the particular routing protocol. =20 JP> Why tradeoff with latency ? The nodes use the derived routes for making forwarding decisions. Tsao, et al. Expires October 1, 2010 [Page 6] =0C Internet-Draft Security Framework for ROLL March 2010 ................................................... : : : _________________ : |Node_i|<------->(Neighbor Discovery)--->Neighbor Topology : : -------+--------- : : | : |Node_j|<------->(Route/Topology +--------+ : : Exchange) | : : | V ______ : : +---->(Route Generation)--->Routes : : ---+-- : : | : : Routing on a Node Node_k | : ................................................... | |Forwarding | On Node_l|<-------------------------------------------+ Notation: (Proc) A process Proc ________ DataBase A data storage DataBase -------- |Node_n| An external entity Node_n -------> Data flow Figure 1: Data Flow Diagram of a Generic Routing Process It is seen from Figure 1 that o Assets include * routing and/or topology information; * communication channel resources (bandwidth); * node resources (computing capacity, memory, and remaining energy); * node identifiers (including node identity and ascribed attributes such as relative or absolute node location). Tsao, et al. Expires October 1, 2010 [Page 7] =0C Internet-Draft Security Framework for ROLL March 2010 o Points of access include * neighbor discovery; * route/topology exchange; * node physical interfaces (including access to data storage). A focus on the above list of assets and points of access enables a more directed assessment of routing security. Indeed, the intention is to be comprehensive; nonetheless, the discussions to follow on physical related issues are not related to routing protocol design but provided for reference since they do have direct consequences on the security of routing. 3.2. The CIA Security Reference Model At the conceptual level, security within an information system in general and applied to ROLL in particular is concerned with the primary issues of confidentiality, integrity, and availability. In the context of ROLL: Confidentiality Confidentiality involves the protection of routing information as well as routing neighbor maintenance exchanges so that only authorized and intended network entities may view or access it. JP> By "neighbor" just mention that we're referring to routing neighbor = in the=20 context on this document. Because of the wireless,=20 JP> Not always wireless ! Just make sure to make it clear even if the = comment below applies to wireless links. and sometimes ad hoc, nature of the network, confidentiality also extends to the neighbor state and database information within the routing device since the deployment of the network creates the potential for unauthorized access to the physical devices themselves. Integrity Integrity, as a security principle, entails the protection of routing information and routing neighbor maintenance exchanges, as well as derived information maintained in the database, from misuse or unauthorized and improper modification. In addition, integrity also requires=20 JP> Is it really integrity that requires authenticity ? the authenticity of claimed identity in the origin and destination of a message, access and removal of data, execution of the routing process, and use of computing and energy resources. Availability Availability ensures that routing information exchanges and forwarding services need to be available when they are required for the functioning of the serving network. Availability will apply to maintaining efficient and correct operation of routing and neighbor discovery exchanges (including needed information) Tsao, et al. Expires October 1, 2010 [Page 8] =0C Internet-Draft Security Framework for ROLL March 2010 and forwarding services so as not to impair or limit the network's central traffic flow function. It is noted that, besides those captured in the CIA model, non- repudiation is a security interest under certain circumstances. With respect to routing, non-repudiation will involve providing some ability to allow traceability or network management review of participants of the routing process including the ability to determine the events and actions leading to a particular routing state. Non-repudiation implies after the fact and thus relies on the logging or other capture of on-going routing exchanges. Given the limited resources of a node and potentially the communication channel, and considering the operating mode associated with LLNs, routing transaction logging or auditing process communication overhead will not be practical; as such, non-repudiation is not further considered as a relevant ROLL security issue. JP> May be one sentence to define "non-repudiation" would be helpful 3.3. Issues Specific to or Amplified in LLNs The work [RFC5548] and [RFC5673], as well as two other ongoing efforts, [I-D.ietf-roll-home-routing-reqs] and [I-D.ietf-roll-building-routing-reqs],=20 JP> Update the draft-ietf references. They are all RFC (5826 and 5867 = respectively). have identified ROLL=20 JP> "ROLL specific" -> "routing requirement specific to LLNs" specific requirements and constraints for the urban, industrial, home automation, and building automation application domains, respectively. The following is a list of observations and evaluation of their impact on routing security considerations. Limited energy reserve JP> s/reserve/resources/ , memory, and processing resources JP> s/processing resources/processing nodes resources/ As a consequence of these constraints, there is an even more critical need than usual for a careful trade study on which and what level of security services are to be afforded during the system design process. In addition, the choices of security mechanisms are more stringent. Synchronization of security states with sleepy nodes is yet another issues. JP>s/issues/issue Large scale of rolled out network JP> You can mention "from a few dozens to several (hundreds) of = thousands of nodes" The possibly numerous nodes to be deployed, as well as the general level of expertise of the installers, make manual on- site configuration unlikely. Prolonged rollout and delayed addition of nodes, which may be from old inventory, over the lifetime of the network, also complicate the operations of key management. Autonomous operations Self-forming and self-organizing are commonly prescribed requirements of ROLL JP> s/ROLL/LLNs . In other words, a ROLL protocol=20 JP> A Routing protocol designed for LLNs needs to contain elements of ad hoc networking and cannot=20 JP> (in most cases) rely on manual configuration for initialization or local filtering rules. Tsao, et al. Expires October 1, 2010 [Page 9] =0C Internet-Draft Security Framework for ROLL March 2010 Network topology/ownership changes, partitioning or merging, as well as node replacement, can all contribute to key management issues. Highly directional traffic Some types of LLNs see a high percentage of their total traffic traverse between the nodes and the gateways=20 JP> Use "LBR" as defined in = http://datatracker.ietf.org/doc/draft-ietf-roll-terminology/ instead of gateway where the LLNs connect to wired networks. =20 JP> s/wired networks/to non LLN network (since wired links may be = present in LLNs) The special routing status of and the greater volume of traffic near the gateways/sinks=20 JP> Same comment use only the LBR terminology throughout the document. have routing security consequences. JP> You can mention that when P2MP and MP2P traffic represents a = majority of the traffic routing attacks consisting of advertising low route cost may cause = serious damages. Unattended locations and limited physical security Many applications have the nodes deployed in unattended or remote locations; furthermore, the nodes themselves are often built with minimal physical protection. These constraints lower the barrier of accessing the data or security material stored on the nodes through physical means. Support for mobility On the one hand, only a number of applications require the support of mobile nodes, e.g., a home LLN that includes nodes on wearable health care devices or an industry LLN that includes nodes on cranes and vehicles. On the other hand, if a routing protocol is indeed used in such applications, it will clearly need to have corresponding security mechanisms. Support for multicast and anycast Support for multicast and anycast is called out chiefly for large-scale networks. As these are relatively new routing technologies,=20 JP> Heu ... Multicast is not really new there has been an ongoing effort devoted to their security mechanisms, e.g., from the IETF Multicast Security working group. However, inclusion of such mechanisms in a routing protocol, and consequently their security analysis, are still areas not fully developed or their impact entirely understood, whether in a more traditional wired or wireless network, or LLN. The above list considers how a LLN's physical constraints, size, operations, and varieties of application areas may impact security. It is noted here also that LLNs commonly have the majority, if not all, of their nodes equipped to route. =20 JP> I would suppress the previous sentence, since in this document we = are=20 only considering nodes acting as routers. One of the consequences is that the distinction between the link and network layers become artificial in some respects. Similarly, the distinction between a host and a router is blurred, especially when the set of applications running on a node is small. =20 JP> Same thing for the previous sentence, which may be misleading. The continued evolution of ROLL and its security functionality requirements need close attention. JP> s/ROLL/routing protocol designed by the ROLL WG Tsao, et al. Expires October 1, 2010 [Page 10] =0C Internet-Draft Security Framework for ROLL March 2010 3.4. ROLL Security Objectives This subsection applies the CIA model to the routing assets and access points, taking into account the LLN issues, to develop a set of ROLL security objectives. Since the fundament function of a routing protocol is to build routes for forwarding packets, it is essential to ensure that o routing/topology information is not tampered during transfer and in storage; o routing/topology information is not misappropriated; o routing/topology information is available when needed. In conjunction, it is necessary to be assured of o the authenticity and legitimacy of the participants of the JP> routing neighbor neighbor discovery process; o the routing/topology information received was faithfully generated according to the protocol design. However, when trust cannot be fully vested through authentication of the principals alone, i.e., concerns of insider attack, assurance of the truthfulness and timeliness of the received routing/topology information is necessary. With regard to confidentiality, protecting the routing/topology information from eavesdropping or unauthorized exposure is in itself less pertinent in general to the routing function. One of the main problems of synchronizing security states of sleepy nodes, as listed in the last subsection, lies in difficulties in authentication; these nodes may not have received in time the most recent update of security material. Similarly, the issues of minimal manual configuration, prolonged rollout and delayed addition of nodes, and network topology changes also complicate key management. Hence, ROLL=20 JP> Change ROLL for routing in LLN needs to bootstrap the authentication process and allow for flexible expiration scheme of authentication credentials. The vulnerability brought forth by some special-function nodes, e.g., gateways/sinks=20 JP> Change for LBR requires the assurance, particularly, o of the availability of communication channels and node resources; JP> but how to ensure and the unavailable of the channels is due to a = security=20 attack as opposed to simply being not operational? o that the neighbor discovery process operates without undermining routing availability. Tsao, et al. Expires October 1, 2010 [Page 11] =0C Internet-Draft Security Framework for ROLL March 2010 There are other factors which are not part of a ROLL protocol but directly affecting its function. These factors include weaker barrier of accessing the data or security material stored on the nodes through physical means; therefore, the internal and external interfaces of a node need to be adequate for guarding the integrity, and possibly the confidentiality, of stored information, as well as the integrity of routing and route generation processes. Each individual system's use and environment will dictate how the above objectives are applied, including the choices of security services as well as the strengths of the mechanisms that must be implemented. The next two sections give a closer look at how the ROLL security objectives may be compromised and countered, respectively. 4. Threats and Attacks This section outlines general categories of threats under the CIA model and highlights the specific attacks in each of these categories for ROLL. As defined in [RFC4949], a threat is "a potential for violation of security, which exists when there is a circumstance, capability, action, or event that could breach security and cause harm." An attack is "an assault on system security that derives from an intelligent threat, i.e., an intelligent act that is a deliberate attempt (especially in the sense of a method or technique) to evade security services and violate the security policy of a system." The subsequent subsections consider the threats and their realizing attacks that can cause security breaches under the CIA model to the assets identified in Section 3.1. The analysis steps through the security concerns of each routing asset and looks at the attacks that can exploit points of access. The manifestation of the attacks is assumed to be from either inside or outside attackers, whose capabilities may be limited to node-equivalent or more sophisticated computing platforms. 4.1. Threats and Attacks on Confidentiality The assessment in Section 3.2 indicates that information assets are exposed to confidentiality threats from all points of access. 4.1.1. Routing Exchange Exposure Routing exchanges include both routing information as well as information associated with the establishment and maintenance of neighbor state information. Tsao, et al. Expires October 1, 2010 [Page 12] =0C Internet-Draft Security Framework for ROLL March 2010 The exposure of routing information exchanged will allow unauthorized sources to gain access to the content of the exchanges between communicating nodes. The exposure of neighbor state information will allow unauthorized sources to gain knowledge of communication links between routing nodes that are necessary to maintain routing information exchanges. The forms of attack that allow unauthorized access or exposure of routing exchange information, as reported in the literature, include o Deliberate exposure; o Sniffing; o Traffic analysis. 4.1.2. Routing Information (Routes and Network Topology) Exposure Routes and neighbor topology information are the products of the routing process that are stored within the node device databases. The exposure of this information will allow unauthorized sources to gain direct access to the configuration and connectivity of the network thereby exposing routing to targeted attacks on key nodes or links. Since routes and neighbor topology information is stored within the node device, threats or attacks on the confidentiality of the information will apply to the physical device including specified and unspecified internal and external interfaces. The forms of attack that allow unauthorized access or exposure of the routing information (other than occurring through explicit node exchanges) will include o Physical device compromise; o Remote device access attacks (including those occurring through remote network management or software/field upgrade interfaces). More detailed descriptions of the exposure attacks on routing exchange and information will be given in Section 5 together with the corresponding countermeasures. 4.2. Threats and Attacks on Integrity The assessment in Section 3.2 indicates that information and identity assets are exposed to integrity threats from all points of access. Tsao, et al. Expires October 1, 2010 [Page 13] =0C Internet-Draft Security Framework for ROLL March 2010 4.2.1. Routing Information Manipulation Manipulation of routing information will allow unauthorized sources to influence the operation and convergence of the routing protocols and ultimately impact the forwarding decisions made in the network. Manipulation of neighbor state (topology)=20 JP> topology and reachability information information will allow unauthorized sources to influence the nodes with which routing information is exchanged and updated. The consequence of manipulating routing exchanges can thus lead to sub-optimality and fragmentation or partitioning of the network by restricting the universe of routers with which associations can be established and maintained. JP> Can also lead to attract traffic, black-holes, ...=20 The forms of attack that allow manipulation to compromise the content and validity of routing information include o Falsification, including overclaiming and misclaiming; o Routing information replay; o Byzantine (internal) attacks that permit corruption of routing information in the node even where the node continues to be a validated entity within the network; o Physical device compromise. 4.2.2. Node Identity Misappropriation Falsification or misappropriation of node identity between routing participants opens the door for other attacks; it can also cause incorrect routing relationships to form and/or topologies to emerge. Routing attacks may also be mounted through less sophisticated node identity misappropriation in which the valid information broadcast or exchanged by a node is replayed without modification. The receipt of seemingly valid information that is however no longer current can result in routing disruption, and instability (including failure to converge). Without measures to authenticate the routing participants and to ensure the freshness and validity of the received information the protocol operation can be compromised. The forms of attack that misuse node identity include o Identity (including Sybil) attacks; o Routing information replay. Tsao, et al. Expires October 1, 2010 [Page 14] =0C Internet-Draft Security Framework for ROLL March 2010 4.3. Threats and Attacks on Availability The assessment in Section 3.2 indicates that the process and resources assets are exposed to availability threats; attacks of this category may exploit directly or indirectly information exchange or forwarding. 4.3.1. Routing Exchange Interference or Disruption Interference or disruption of routing information exchanges will allow unauthorized sources to influence the operation and convergence of the routing protocols by impeding the regularity of routing information exchange. The forms of attack that allow interference or disruption of routing exchange include o Routing information replay; o HELLO flood attacks and ACK spoofing; o Overload attacks. 4.3.2. Network Traffic Forwarding Disruption The disruption of the network traffic forwarding capability of the network will undermine the central function of network routers and the ability to handle user traffic. This threat and the associated attacks affect the availability of the network because of the potential to impair the primary capability of the network. The forms of attack that allows disruption of network traffic forwarding include o Selective forwarding attacks; o Sinkhole attacks; o Wormhole attacks. JP> Can you add reference to sinkhole and wormhole attacks? 4.3.3. Communications Resource Disruption Attacks mounted against the communication channel resource assets needed by the routing protocol can be used as a means of disrupting its operation. However, while various forms of Denial of Service (DoS) attacks on the underlying transport subsystem will affect routing protocol exchanges and operation (for example physical layer RF jamming in a wireless network or link layer attacks), these Tsao, et al. Expires October 1, 2010 [Page 15] =0C Internet-Draft Security Framework for ROLL March 2010 attacks cannot be countered by the routing protocol. As such, the threats to the underlying transport network that supports routing is considered beyond the scope of the current document. Nonetheless, attacks on the subsystem will affect routing operation and so must be directly addressed within the underlying subsystem and its implemented protocol layers. 4.3.4. Node Resource Exhaustion A potential security threat to routing can arise from attempts to exhaust the node resource asset by initiating exchanges that can lead to the undue utilization of exhaustion of processing, memory or energy resources. The establishment and maintenance of routing neighbors opens the routing process to engagement and potential acceptance of multiple neighboring peers. Association information must be stored for each peer entity and for the wireless network operation provisions made to periodically update and reassess the associations. An introduced proliferation of apparent routing peers can therefore have a negative impact on node resources. Node resources may also be unduly consumed by the attackers attempting uncontrolled topology peering or routing exchanges, routing replays, or the generating of other data traffic floods. Beyond the disruption of communications channel resources, these threats may be able to exhaust node resources only where the engagements are able to proceed with the peer routing entities. Routing operation and network forwarding functions can thus be adversely impacted by node resources exhaustion that stems from attacks that include o Identity (including Sybil) attacks; o Routing information replay attacks; o HELLO flood attacks and ACK spoofing; o Overload attacks. 5. Countermeasures By recognizing the characteristics of LLNs that may impact routing and identifying potential countermeasures, this framework provides the basis for developing capabilities within ROLL protocols to deter the identified attacks and mitigate the threats. The following subsections consider such countermeasures by grouping the attacks according to the classification of the CIA model so that associations with the necessary security services are more readily visible. Tsao, et al. Expires October 1, 2010 [Page 16] =0C Internet-Draft Security Framework for ROLL March 2010 However, the considerations here are more systematic than confined to means available only within routing; the next section will then distill and make recommendations appropriate for a secured ROLL protocol. 5.1. Confidentiality Attack Countermeasures Attacks on confidentiality may be mounted at the level of the routing information assets, at the points of access associated with routing exchanges between nodes, or through device interface access. To gain access to routing/topology information, the attacker may rely on a compromised node that deliberately exposes the information during the routing exchange process, may rely on passive sniffing or analysis of routing traffic, or may attempt access through a component or device interface of a tampered routing node. 5.1.1. Countering Deliberate Exposure Attacks A deliberate exposure attack is one in which an entity that is party to the routing process or topology exchange allows the routing/ topology information or generated route information to be exposed to an unauthorized entity during the exchange. A prerequisite to countering this type of confidentiality attacks associated with the routing/topology exchange is to ensure that the communicating nodes are authenticated prior to data encryption applied in the routing exchange. Authentication ensures that the nodes are who they claim to be even though it does not provide an indication of whether the node has been compromised. To prevent deliberate exposure, the process that communicating nodes use for establishing communication session keys must be symmetric at each node so that neither node can independently weaken the confidentiality of the exchange without the knowledge of its communicating peer. A deliberate exposure attack will therefore require more overt and independent action on the part of the offending node. Note that the same measures which apply to securing routing/topology exchanges between operational nodes must also extend to field tools and other devices used in a deployed network where such devices can be configured to participate in routing exchanges. 5.1.2. Countering Sniffing Attacks A sniffing attack seeks to breach routing confidentiality through passive, direct analysis and processing of the information exchanges between nodes. A sniffing attack in an LLN that is not based on a Tsao, et al. Expires October 1, 2010 [Page 17] =0C Internet-Draft Security Framework for ROLL March 2010 physical device compromise will rely on the attacker attempting to directly derive information from the over-the-air routing/topology communication exchange (neighbor discovery exchanges may of necessity be conducted in the clear thus limiting the extent to which the information can be kept confidential). Sniffing attacks can be directly countered through the use of data encryption for all routing exchanges. Only when a validated and authenticated node association is completed will routing exchange be allowed to proceed using established session confidentiality keys and an agreed confidentiality algorithm. =20 JP> Id security is "turned on". Could you specify that the routing = protocol will include security features according to this framework but some = scenario may not require their use, should they be provide by other means or not needed in a specific environment. The level of security applied in providing confidentiality will determine the minimum requirement for an attacker mounting this passive security attack. Because of the resource constraints of LLN devices, symmetric (private) key session security will provide the best tradeoff in terms of node and channel resource overhead and the level of security achieved. This will of course not preclude the use of asymmetric (public) key encryption during the session key establishment phase. As with the key establishment process, data encryption must include an authentication prerequisite to ensure that each node is implementing a level of security that prevents deliberate or inadvertent exposure. The authenticated key establishment will ensure that confidentiality is not compromised by providing the information to an unauthorized entity (see also [Huang2003]). Based on the current state of the art, a minimum 128-bit key length should be applied where robust confidentiality is demanded for routing protection. This session key shall be applied in conjunction with an encryption algorithm that has been publicly vetted and where applicable approved for the level of security desired. Algorithms such as AES (adopted by the U.S. government) or Kasumi-Misty (adopted by the 3GPP 3rd generation wireless mobile consortium) JP> Could you please ad references ? are examples of symmetric-key algorithms capable of ensuring robust confidentiality for routing exchanges. The key length, algorithm and mode of operation will be selected as part of the overall security tradeoff that also achieves a balance with the level of confidentiality afforded by the physical device in protecting the routing assets (see Section 5.1.4 below). As with any encryption algorithm, the use of ciphering synchronization parameters and limitations to the usage duration of established keys should be part of the security specification to reduce the potential for brute force analysis. Tsao, et al. Expires October 1, 2010 [Page 18] =0C Internet-Draft Security Framework for ROLL March 2010 5.1.3. Countering Traffic Analysis Traffic analysis provides an indirect means of subverting confidentiality and gaining access to routing information by allowing an attacker to indirectly map the connectivity or flow patterns (including link-load)=20 JP> Aren't you making the assumption that LLNs only comprise radio link layers ? ** Please make sure that throughout the document you are not making any assumption on the link layer (see other comments above along the same lines). of the network from which other attacks can be mounted. The traffic analysis attack on a LLN may be passive and relying on the ability to read the immutable source/destination routing information that must remain unencrypted to permit network routing. Alternatively, attacks can be active through the injection of unauthorized discovery traffic into the network. By implementing authentication measures between communicating nodes, active traffic analysis attacks can be prevented within the LLN thereby reducing confidentiality vulnerabilities to those associated with passive analysis. One way in which passive traffic analysis attacks can be muted is through the support of load balancing that allows traffic to a given destination to be sent along diverse routing paths. Where the routing protocol supports load balancing along multiple links at each node, the number of routing permutations in a wide area network surges thus increasing the cost of traffic analysis. Network analysis through this passive attack will require a wider array of analysis points and additional processing on the part of the attacker. In LLNs, the diverse radio connectivity and dynamic links (including potential frequency hopping) will help to further mitigate traffic analysis attacks when load balancing is implemented. JP> Please indicate that this is trued if the link layer is wireless. The only means of fully countering a traffic analysis attack is through the use of tunneling (encapsulation) where encryption is applied across the entirety of the original packet source/destination addresses. With tunneling there is a further requirement that the encapsulating intermediate nodes apply an additional layer of routing so that traffic arrives at the destination through dynamic routes. For LLNs, memory and processing constraints as well as the limitations of the communication channel will preclude both the additional routing traffic overhead=20 JP> But tunneling may be used and is actually used in several cases (e.g. this is the situation for example with RPL when an additional = header used for example for loop detection is added to the HbP header for = traffic=20 from outside of the LLN to a node inside the LLN). and the node implementation required for tunneling countermeasures to traffic analysis. 5.1.4. Countering Physical Device Compromise Given the distributed nature of LLNs, confidentiality of routing assets and points of access will rely heavily on the security of the routing devices. One means of precluding attacks on the physical device is to prevent physical access to the node through other external security means. However, given the environment in which LLNs operate, preventing unauthorized access to the physical device cannot be assured. =20 JP> "in some cases" - for example in a Smart Grid environment the = substation has secured access. Countermeasures must therefore be employed at the Tsao, et al. Expires October 1, 2010 [Page 19] =0C Internet-Draft Security Framework for ROLL March 2010 device and component level so that routing/topology or neighbor information and stored route information cannot be accessed even if physical access to the node is obtained. With the physical device in the possession of an attacker, unauthorized information access can be attempted by probing internal interfaces or device components. Device security must therefore move to preventing the reading of device processor code or memory locations without the appropriate security keys and in preventing the access to any information exchanges occurring between individual components. Information access will then be restricted to external interfaces in which confidentiality, integrity and authentication measures can be applied. JP> True but you may want to mention that this is not 'routing security'=20= specific. To prevent component information access, deployed routing devices must ensure that their implementation avoids address or data buses being connected to external general purpose input/output (GPIO) pins. Beyond this measure, an important component interface to be protected against attack is the Joint Test Action Group (JTAG) interface used for component and populated circuit board testing after manufacture. To provide security on the routing devices, components should be employed that allow fuses on the JTAG interfaces to be blown to disable access. This will raise the bar on unauthorized component information access within a captured device. At the device level a key component information exchange is between the microprocessor and it associated external memory. While encryption can be implemented to secure data bus exchanges, the use of integrated physical packaging which avoids inter-component exchanges (other than secure external device exchanges) will increase routing security against a physical device interface attack. With an integrated package and disabled internal component interfaces, the level of physical device security can be controlled by managing the degree to which the device packaging is protected against expert physical decomposition and analysis. The device package should be hardened such that attempts to remove the integrated components will result in damage to access interfaces, ports or pins that prevent retrieval of code or stored information. The degree of VLSI or PCB=20 JP> Could you please expand acronyms when first used ? package security through manufacture can be selected as a tradeoff or desired security consistent with the level of security achieved by measures applied for other routing assets and points of access. With package hardening and restricted component access countermeasures, the security level will be raised to that provided by measures employed at the external communications interfaces. Another area of node interface vulnerability is that associated with Tsao, et al. Expires October 1, 2010 [Page 20] =0C Internet-Draft Security Framework for ROLL March 2010 interfaces provided for remote software or firmware upgrades. This may impact both routing information and routing/topology exchange security where it leads to unauthorized upgrade or change to the routing protocol running on a given node as this type of attack can allow for the execution of compromised or intentionally malicious routing code on multiple nodes. Countermeasures to this device interface confidentiality attack needs to be addressed in the larger context of node remote access security. This will ensure not only the authenticity of the provided code (including routing protocol) but that the process is initiated by an authorized (authenticated) entity. The above identified countermeasures against attacks on routing information confidentiality through internal device interface compromise must be part of the larger LLN system security as they cannot be addressed within the routing protocol itself. Similarly, the use of field tools or other devices that allow explicit access to node information must implement security mechanisms to ensure that routing information can be protected against unauthorized access. These protections will also be external to the routing protocol and hence not part of ROLL. 5.1.5. Countering Remote Device Access Attacks Where LLN nodes are deployed in the field, measures are introduced to allow for remote retrieval of routing data and for software or field upgrades. These paths create the potential for a device to be remotely accessed across the network or through a provided field tool. In the case of network management a node can be directly requested to provide routing tables and neighbor information. To ensure confidentiality of the node routing information against attacks through remote access, any device local or remote requesting routing information must be authenticated to ensure authorized access. Since remote access is not invoked as part of a routing protocol security of routing information stored on the node against remote access will not be addressable as part of the routing protocol. 5.2. Integrity Attack Countermeasures Integrity attack countermeasures address routing information manipulation, as well as node identity and routing information misuse. Manipulation can occur in the form of falsification attack and physical compromise. To be effective, the following development considers the two aspects of falsification, namely, the tampering actions and the overclaiming and misclaiming content. The countering of physical compromise was considered in the previous section and is Tsao, et al. Expires October 1, 2010 [Page 21] =0C Internet-Draft Security Framework for ROLL March 2010 not repeated here. With regard to misuse, there are two types of attacks to be deterred, identity attacks and replay attacks. 5.2.1. Countering Tampering Attacks Tampering may occur in the form of altering the message being transferred or the data stored. Therefore, it is necessary to ensure that only authorized nodes can change the portion of the information that is allowed to be mutable, while the integrity of the rest of the information is protected, e.g., through well-studied cryptographic mechanisms. Tampering may also occur in the form of insertion or deletion of messages during protocol changes. Therefore, the protocol needs to ensure the integrity of the sequence of the exchange sequence. The countermeasure to tampering needs to o implement access control on storage; o provide data integrity service to transferred messages and stored data; o include sequence number under integrity protection. 5.2.2. Countering Overclaiming and Misclaiming Attacks Both overclaiming and misclaiming aim to introduce false routes or topology that would not be generated by the network otherwise, while there is not necessarily tampering. The requisite for a counter is the capability to determine unreasonable routes or topology. The counter to overclaiming and misclaiming may employ o comparison with historical routing/topology data; o designs which restrict realizable network topologies. 5.2.3. Countering Identity (including Sybil) Attacks Identity attacks, sometimes simply called spoofing, seek to gain or damage assets whose access is controlled through identity. In routing, an identity attacker can illegitimately participate in routing exchanges, distribute false routing information, or cause an invalid outcome of a routing process. A perpetrator of Sybil attacks assumes multiple identities. The result is not only an amplification of the damage to routing, but Tsao, et al. Expires October 1, 2010 [Page 22] =0C Internet-Draft Security Framework for ROLL March 2010 extension to new areas, e.g., where geographic distribution is explicit or implicit an asset to an application running on the LLN. JP> You could mentioned that this is a particular concern in LLN where = the traffic flow is mostly P2MP and MP2P. The counter of identity attacks need to ensure the authenticity and liveliness of the parties of a message exchange; the measure may use shared key or public key based authentication scheme. On the one hand, the large-scale nature of the LLNs makes the network-wide shared key scheme undesirable from a security perspective; on the other hand, public-key based approaches generally require more computational resources. =20 JP> Could elaborate a little bit more on the CPU impact when using public-key? Each system will need to make trade-off decisions based on its security requirements. 5.2.4. Countering Routing Information Replay Attacks In routing, message replay can result in false topology and/or routes. The counter of replay attacks need to ensure the freshness of the message. On the one hand, there are a number of mechanisms commonly used for countering replay. =20 JP> Want to add some references? On the other hand, the choice should take into account how a particular mechanism is made available in a LLN. For example, many LLNs have a central source of time and have it distributed by relaying, such that secured time distribution becomes a prerequisite of using timestamping to counter replay. JP> Which means to support clocks, ... 5.2.5. Countering Byzantine Routing Information Attacks Where a node is captured or compromized but continues to operate for a period with valid network security credentials, the potential exists for routing information to be manipulated. This compromise of the routing information could thus exist in spite of security countermeasures that operate between the peer routing devices. Consistent with the end-to-end principle of communications, such an attack can only be fully addressed through measures operating directly between the routing entities themselves or by means of external entities able to access and independently analyze the routing information. Verification of the authenticity and liveliness of the routing principals can therefore only provide a limited counter against internal (Byzantine) node attacks. JP> Agree but this is not particularly tied to the end-to-end principle. For link state routing protocols where information is flooded JP> add "with area (OSPF) or levels (ISIS) countermeasures can be directly applied by the routing entities through the processing and comparison of link state information received from different peers. By comparing the link information from multiple sources decisions can be made by a routing node or external entity with regard to routing information validity. For distance vector protocols where information is aggregated at each routing node it is not possible for nodes to directly detect Tsao, et al. Expires October 1, 2010 [Page 23] =0C Internet-Draft Security Framework for ROLL March 2010 Byzantine information manipulation attacks from the routing information exchange. In such cases, the routing protocol must include and support indirect communications exchanges between non- adjacent routing peers to provide a secondary channel for performing routing information validation. S-RIP [Wan2004] is an example of the implementation of this type of dedicated routing protocol security where the correctness of aggregate distance vector information can only be validated by initiating confirmation exchanges directly between nodes that are not routing neighbors. Alternatively, an entity external to the routing protocol would be required to collect and audit routing information exchanges to detect the Byzantine attack. In the context of the current security framework, any protection against Byzantine routing information attacks will need to be directly included within the mechanisms of the ROLL routing protocol. This can be implemented where such an attack is considered relevant even within the physical device protections discussed in Section 5.1.4 5.3. Availability Attack Countermeasures As alluded to before, availability requires that routing information exchanges and forwarding mechanisms be available when needed so as to guarantee a proper functioning of the network. This may, e.g., include the correct operation of routing information and neighbor state information exchanges, among others. We will highlight the key features of the security threats along with typical countermeasures to prevent or at least mitigate them. We will also note that an availability attack may be facilitated by an identity attack as well as a replay attack, as was addressed in Section 5.2.3 and Section 5.2.4, respectively. 5.3.1. Countering HELLO Flood Attacks and ACK Spoofing Attacks HELLO Flood [Karlof2003],[I-D.suhopark-hello-wsn] and ACK Spoofing attacks are different but highly related forms of attacking a LLN. They essentially lead nodes to believe that suitable routes are available even though they are not and hence constitute a serious availability attack. The origin of facilitating a HELLO flood attack lies in the fact that many wireless routing protocols=20 JP> Please do not use the terms "wireless routing protocols" since by=20 definition of a layered architecture, the routing protocol is not tied = to=20 a particular link layer. Furthermore this also applies to routing = protocols used in non wireless environments. require nodes to send HELLO packets either upon joining or in regular intervals so as to announce or confirm their existence to the network. Those nodes that receive the HELLO packet assume=20 JP> If they receive the packet they *are* in the radio range (again the = link may not be wireless). that they are within radio range of the transmitter by means of a bidirectional communication link. With this in mind, a malicious node can send or replay HELLO packets Tsao, et al. Expires October 1, 2010 [Page 24] =0C Internet-Draft Security Framework for ROLL March 2010 using a higher transmission power. That creates the false illusion of being a neighbor to an increased number of nodes in the network, thereby effectively increasing its unidirectional neighborhood cardinality. The high quality of the falsely advertised link may coerce nodes to route data via the malicious node. However, those affected nodes, for which the malicious node is out of radio range, never succeed in their delivery and the packets are effectively dropped. =20 JP> Mention "if the link layer is wireless". Not that in PLC, this can = happen too. The symptoms are hence similar to those of a sinkhole, wormhole and selective forwarding attack. A malicious HELLO flood attack clearly distorts the network topology. It thus affects protocols building and maintaining the network topology as well as routing protocols as such, since the attack is primarily targeted on protocols that require sharing of information for topology maintenance or flow control. To counter HELLO flood attacks, several mutually non-exclusive methods are feasible: o restricting neighborhood cardinality; o facilitating multipath routing; o verifying bidirectionality. Restricting the neighborhood cardinality prevents malicious nodes from having an extended set of neighbors beyond some tolerated threshold and thereby preventing topologies to be built where malicious nodes have an extended neighborhood set. =20 JP> But thai may artificially reduce the number of "valid" neighbors = too. Furthermore, as shown in [I-D.suhopark-hello-wsn], if the routing protocol supports multiple paths from a sensing node towards several gateways then HELLO flood attacks can also be diminished; however, the energy- efficiency of such approach is clearly sub-optimal. Finally, verifying that the link is truly bidirectional by means of, e.g., an ACK handshake and appropriate security measures ensures that a communication link is only established if not only the affected node is within range of the malicious node but also vice versa. Whilst this does not really eliminate the problem of HELLO flooding, it greatly reduces the number of affected nodes and the probability of such an attack succeeding. JP> Even if there is bi-directinality, the attacked node may thus send = traffic to the attackers that claims to have "good" routes though. As for the latter, the adversary may spoof the ACK messages to convince the affected node that the link is truly bidirectional and thereupon drop, tunnel or selectively forward messages. Such ACK spoofing attack is possible if the malicious node has a receiver which is significantly more sensitive than that of a normal node, thereby effectively extending its range. Since an ACK spoofing attack facilitates a HELLO flood attack, similar countermeasure are Tsao, et al. Expires October 1, 2010 [Page 25] =0C Internet-Draft Security Framework for ROLL March 2010 applicable here. Viable counter and security measures for both attacks have been exposed in [I-D.suhopark-hello-wsn]. 5.3.2. Countering Overload Attacks Overload attacks are a form of DoS attack in that a malicious node overloads the network with irrelevant traffic, thereby draining the nodes' energy budget quicker. =20 JP> Energy indeed (a real issue if node are battery operated or using=20 energy scavengers) but also inject loads and creates congestions. It thus significantly shortens the network lifetime=20 JP> If the LLNs is made of battery-operated nodes. and hence constitutes another serious availability attack. With energy being one of the most precious assets of LLNs, targeting its availability is a fairly obvious attack. Another way of depleting the energy of a LLN node is to have the malicious node overload the network with irrelevant traffic. This impacts availability since certain routes get congested which o renders them useless for affected nodes and data can hence not be delivered; o makes routes longer as shortest path algorithms work with the congested network; JP> Not sure what you meant above o depletes nodes quicker and thus shortens the network's availability at large. JP> Again if nodes are battery operated. Overload attacks can be countered by deploying a series of mutually non-exclusive security measures: o introduce quotas on the traffic rate each node is allowed to send; JP> Also referred to as "traffic shaping" but only possible in some = networks. o isolate nodes which send traffic above a certain threshold; JP> If "Valid" nodes that may attract lots of traffic do no exist in the = network. o allow only trusted data to be received and forwarded. As for the first one, a simple approach to minimize the harmful impact of an overload attack is to introduce traffic quotas. This prevents a malicious node from injecting a large amount of traffic into the network, even though it does not prevent said node from injecting irrelevant traffic at all. Another method is to isolate JP> If you have a wireless link, how do you "isolate" the node ? It can=20= still sends traffic (at least with some MACs). nodes from the network once it has been detected that more traffic is injected into the network than allowed by a prior set or dynamically adjusted threshold. Finally, if communication is sufficiently secured, only trusted nodes can receive and forward traffic which also lowers the risk of an overload attack. Tsao, et al. Expires October 1, 2010 [Page 26] =0C Internet-Draft Security Framework for ROLL March 2010 5.3.3. Countering Selective Forwarding Attacks Selective forwarding attacks are another form of DoS attack which impacts the routing path availability. An insider malicious node basically blends neatly in with the network but then may decide to forward and/or manipulate certain packets. If all packets are dropped, then this attacker is also often referred to as a "black hole". Such a form of attack is particularly dangerous if coupled with sinkhole attacks since inherently a large amount of traffic is attracted to the malicious node and thereby causing significant damage. An outside malicious node would selectively jam overheard data flows, where the thus caused collisions=20 JP> Again is the MAC is a shared media. incur selective forwarding. Selective Forwarding attacks can be countered by deploying a series of mutually non-exclusive security measures: o multipath routing of the same message over disjoint paths; o dynamically select the next hop from a set of candidates. The first measure basically guarantees that if a message gets lost on a particular routing path due to a malicious selective forwarding attack, there will be another route which successfully delivers the data. Such method is inherently suboptimal from an energy consumption point of view. The second method basically involves a constantly changing routing topology in that next-hop routers are chosen from a dynamic set in the hope that the number of malicious nodes in this set is negligible. JP> If the routing protocol allows for disjoint routing paths, this is = even more attractive. 5.3.4. Countering Sinkhole Attacks In sinkhole attacks, the malicious node manages to attract a lot of traffic mainly by advertising the availability of high-quality links even though there are none. It hence constitutes a serious attack on availability. The malicious node creates a sinkhole by attracting a large amount of, if not all, traffic from surrounding neighbors by advertising in and outwards links of superior quality. Affected nodes hence eagerly route their traffic via the malicious node which, if coupled with other attacks such as selective forwarding, may lead to serious availability and security breaches. Such an attack can only be executed by an inside malicious node and is generally very difficult to detect. An ongoing attack has a profound impact on the network topology and essentially becomes a problem of flow control. Tsao, et al. Expires October 1, 2010 [Page 27] =0C Internet-Draft Security Framework for ROLL March 2010 Sinkhole attacks can be countered by deploying a series of mutually non-exclusive security measures: o use geographical insights for flow control; o isolate nodes which receive traffic above a certain threshold; o dynamically pick up next hop from set of candidates; o allow only trusted data to be received and forwarded. Whilst most of these countermeasures have been discussed before, the use of geographical information deserves further attention. Essentially, if geographic positions of nodes are available, then the network can assure that data is actually routed towards the sink(s) and not elsewhere. =20 JP> Yes but it may be wise to route all traffic via a node that is not = closer to=20 the sink but supports interesting capabilities such as aggregation. On the other hand, geographic position is a sensitive information that may have security and/or privacy consequences. 5.3.5. Countering Wormhole Attacks In wormhole attacks at least two malicious nodes shortcut or divert the usual routing path by means of a low-latency out-of-band channel. This changes the availability of certain routing paths and hence constitutes a serious security breach. Essentially, two malicious insider nodes use another, more powerful, radio=20 JP> Once again, if the link in use is wireless. to communicate with each other and thereby distort the would- be-agreed routing path. This distortion could involve shortcutting and hence paralyzing a large part of the network; it could also involve tunneling the information to another region of the network where there are, e.g., more malicious nodes available to aid the intrusion or where messages are replayed, etc. In conjunction with selective forwarding, wormhole attacks can create race conditions which impact topology maintenance, routing protocols as well as any security suits built on "time of check" and "time of use". Wormhole attacks are very difficult to detect in general but can be mitigated using similar strategies as already outlined above in the context of sinkhole attacks. 6. ROLL Security Features The assessments and analysis in Section 4 examined all areas of threats and attacks that could impact routing, and the countermeasures presented in Section 5 were reached without confining the consideration to means only available to routing. This section Tsao, et al. Expires October 1, 2010 [Page 28] =0C Internet-Draft Security Framework for ROLL March 2010 puts the results into perspective and provides a framework for addressing the derived set of security objectives that must be met by the ROLL protocol. =20 JP> s/ROLL protocol/Routing protocol specified by the ROLL Working = Group. It bears emphasizing that the target here is a generic ROLL protocol and the normative keywords are mainly to convey the relative level of urgency of the features specified. The first part of this section, Section 6.1 to Section 6.3, is a prescription of ROLL security features of measures that can be addressed as part of the routing protocol itself. As routing is one component of a LLN system, the actual strength of the security services afforded to it should be made to conform to each system's security policy; how a design may address the needs of the urban, industrial, home automation, and building automation application domains also needs to be considered. The second part of this section, Section 6.4 and Section 6.5, discusses system security aspects that may impact routing but that also require considerations beyond the routing protocol, as well as potential approaches. 6.1. Confidentiality Features With regard to confidentiality, protecting the routing/topology information from eavesdropping or unauthorized exposure is not directly essential to maintaining the routing function. Breaches of confidentiality may lead to other attacks or the focusing of an attacker's resources (see Section 4.1) but does not of itself directly undermine the operation of the routing function. However, to protect against, and improve vulnerability against other more direct attacks, routing information confidentiality should be protected. Thus, a secured ROLL protocol o SHOULD provide payload encryption; o MAY provide tunneling; o MAY provide load balancing; JP> You can add a note and point to the requirement RFCs, where this is=20= listed as a requirement. o SHOULD provide privacy, e.g., when geographic information is used. Where confidentiality is incorporated into the routing exchanges, encryption algorithms and key lengths need to be specified in accordance of the level of protection dictated by the routing protocol and the associated application domain transport network. In terms of the life time of the keys, the opportunity to periodically change the encryption key increases the offered level of security for any given implementation. However, where strong cryptography is employed, physical, procedural, and logical data access protection considerations may have more significant impact on cryptoperiod selection than algorithm and key size factors. Nevertheless, in Tsao, et al. Expires October 1, 2010 [Page 29] =0C Internet-Draft Security Framework for ROLL March 2010 general, shorter cryptoperiods, during which a single key is applied, will enhance security. Given the mandatory protocol requirement to implement routing node authentication as part of routing integrity (see Section 6.2), key exchanges may be coordinated as part of the integrity verification process. This provides an opportunity to increase the frequency of key exchange and shorten the cryptoperiod as a compliment to the key length and encryption algorithm required for a given application domain. For LLNs, the coordination of confidentiality key management with the implementation of node device authentication can thus reduce the overhead associated with supporting data confidentiality. A new ciphering key may therefore be concurrently generated or updated in conjunction with the mandatory authentication exchange occurring with each routing peer association. 6.2. Integrity Features The integrity of routing information provides the basis for ensuring that the function of the routing protocol is achieved and maintained. To protect integrity, a secured ROLL protocol o MUST verify message integrity; o MUST verify the authenticity and liveliness of both principals of a connection; o MUST verify message sequence. Depending on the nature of the routing protocol, e.g., distance vector or link state, additional measures may be necessary when the validity of the routing information is of concern. Specifically, verification of routing peer authenticity and liveliness can be used to build a "chain of trust" along the path the routing information flows, such that network-wide information is validated through the concatenation of trust established at each individual routing peer exchange. This is particularly important in the case of distance vector-based routing protocols, where information is updated at intermediate nodes, In such cases, there are no direct means within routing for a receiver to verify the validity of the routing information beyond the current exchange; as such, nodes would need to be able to communicate and request information from non-adjacent peers (see [Wan2004]) to provide information integrity assurances. With link state-based protocols, on the other hand, routing information can be signed at the source thus providing a means for validating information that originates beyond a routing peer. Therefore, where necessary, a secured ROLL protocol JP> You can remove the "o" below since there is no other ones. Tsao, et al. Expires October 1, 2010 [Page 30] =0C Internet-Draft Security Framework for ROLL March 2010 o MAY use security auditing mechanisms that are external to routing to verify the validity of the routing information content exchanged among routing peers. 6.3. Availability Features Availability of routing information is linked to system and network availability which in the case of LLNs require a broader security view beyond the requirements of the routing entities (see Section 6.5). Where availability of the network is compromised, routing information availability will be accordingly affected. However, to specifically assist in protecting routing availability o MAY restrict neighborhood cardinality; o MAY use multiple paths; o MAY use multiple destinations; o MAY choose randomly if multiple paths are available; o MAY set quotas to limit transmit or receive volume; o MAY use geographic insights for flow control. 6.4. Additional Related Features If a LLN employs multicast and/or anycast, it MUST secure these protocols=20 JP> "protocols" ? with the services listed in this sections. Furthermore, the nodes MUST provide adequate physical tamper resistance to ensure the integrity of stored routing information. The functioning of the security services requires keys and credentials. Therefore, even though not directly a ROLL security requirement, a LLN must include a process for key and credential distribution; a LLN is encouraged to have procedures for their revocation and replacement. 6.5. Consideration on Matching Application Domain Needs As routing is one component of a LLN system, the actual strength of the security services afforded to it should be made to conform to each system's security policy; how a design may address the needs of the urban, industrial, home automation, and building automation application domains is considered as part of the security architecture in Section 6.5.1. The development so far takes into account collectively the impacts of Tsao, et al. Expires October 1, 2010 [Page 31] =0C Internet-Draft Security Framework for ROLL March 2010 the issues gathered from [RFC5548], [RFC5673], [I-D.ietf-roll-home-routing-reqs], and [I-D.ietf-roll-building-routing-reqs]. =20 JP> Update the reference (all RFcs now). The following two subsections first consider from an architectural perspective how the security design of a ROLL protocol may be made to adapt to the four application domains, and then examine mechanism and protocol operations issues. 6.5.1. Security Architecture The first challenge for a ROLL protocol security design is to have an architecture that can adequately address a set of very diversified needs. It is mainly a consequence of the fact that there are both common and non-overlapping requirements from the four application domains, while, conceivably, each individual application will present yet its own unique constraints. For a ROLL protocol, the security requirements defined in Section 6.1 to Section 6.4 can be addressed at two levels: 1) through measures implemented directly within the routing protocol itself and initiated and controlled by the routing protocol entities; or 2) through measures invoked on behalf of the routing protocol entities but implemented within the transport network=20 JP> Be accurate when you used "transport network": you mean "link layer" = ? over which the protocol exchanges occur. Where security is directly implemented as part of the routing protocol the security requirements configured by the user (system administrator) will operate independent of the underlying transport network JP>s/transport network/link layer . OSPFv2 [RFC2328] is an example of such an approach in which security parameters are exchanged and assessed within the routing protocol messages. In this case, the mechanism may be, e.g., a header containing security material of configurable security primitives in the fashion of OSPFv2 or RIPv2 [RFC2453]. Where IPsec [RFC4301] is employed to secure the network, the included protocol- specific (OSPF or RIP) security elements are in addition to and independent of those at the network layer. In the case of LLNs or other networks where system security mandates protective mechanisms at other lower layers of the transport network,=20 JP> "lower layers of the transport network" is ambiguous. security measures implemented as part of the routing protocol will be redundant to security measures implemented elsewhere as part of the transport network. JP> Please replace "transport network" with appropriate terminology = where needed. Thanks. Security mechanisms built into the routing protocol can ensure that all desired countermeasures can be directly addressed by the protocol all the way to the endpoint of the routing exchange. In particular, routing protocol Byzantine attacks by a compromised node that retains valid network security credentials can only be detected at the level of the information exchanged within the routing protocol. Such Tsao, et al. Expires October 1, 2010 [Page 32] =0C Internet-Draft Security Framework for ROLL March 2010 attacks aimed the manipulation of the routing information can only be fully addressed through measures operating directly between the routing entities themselves or external entities able to access and analyze the routing information (see discussion in Section 5.2.5). On the other hand, it is more desirable from a LLN device perspective that the ROLL protocol is integrated into the framework of an overall system architecture where the security facility may be shared by different applications and/or across layers for efficiency, and where security policy and configurations can be consistently specified. See, for example, considerations made in RIPng [RFC2080] or the approach presented in [Messerges2003]. Where the routing protocol is able to rely on security measures configured with the transport network JP> Same comment. What do you mean by "transport network"? , greater system efficiency can be realized by avoiding potentially redundant security. Relying on an open trust model [Messerges2003], the security requirements of the routing protocol can be more flexibly met at different layers of the transport network; measures that must be applied to protect the communications network are concurrently able to provide the needed routing protocol protection. In addition, in the context of the different application domains, it allows the level of security applied for routing to be consistent with that needed for protecting the network itself. For example, where AES-128 JP> Expand terms when first used + add reference is deemed the appropriate standard for network confidentiality of data exchanges at the link layer, that level of security is automatically afforded to routing protocol exchanges. Similarly, where SHA-1=20 JP> Same comment is stipulated as the standard required for authenticating routing protocol peers, the use of SHA-1 at the network layer between communicating routing devices automatically meets the routing protocol security requirement within the context of open trust across layers within the device. A ROLL protocol MUST be made flexible by a design that offers the configuration facility so that the user (network administrator) can choose the security settings that match the application's needs. Furthermore, in the case of LLNs that flexibility should extend to allowing the routing protocol security requirements to be met by measures applied at different protocol layers, provided the identified requirements are collectively met. Since Byzantine attacks that can affect the validity of the information content exchanged between routing entities can only be directly countered at the routing protocol level, the ROLL protocol may support mechanisms for verifying routing data validity that extends beyond the chain of trust created through device authentication. This protocol-specific security mechanism should be Tsao, et al. Expires October 1, 2010 [Page 33] =0C Internet-Draft Security Framework for ROLL March 2010 made optional within the protocol allowing it to be invoked according to the given routing protocol and application domain and as selected by the system user. All other ROLL security mechanisms needed to meet the above identified routing security requirements should be flexibly implemented within the transport network (at the IP network layer or higher or lower protocol layers(s)) according to the particular application domain and user network configuration. Based on device capabilities and the spectrum of operating environments it would be difficult for a single fixed security design to be applied to address the diversified needs of the four ROLL application domains=20 JP> Please list them again (urban, industrial, home/building) + indicate = that this is also true for other application domains. without forcing a very low common denominator set of requirements. On the other hand, providing four individual domain designs that attempt to a priori match each individual domain is also very likely to provide a suitable answer given the degree of network variability even within a given domain. =20 JP> The type of link layers in use within each domain also influences = the overall security. Instead, the framework implementation approach recommended for optional, routing protocol- specific measures together with flexible transport network mechanisms can be the most effective. This approach allows countermeasures against internal attacks to be applied in environments where applicable threats exist. At the same time, it allows routing protocol security to be configured through measures implemented within the transport network that is commensurate and consistent with the level and strength applied in the particular application domain networks. 6.5.2. Mechanisms and Operations With an architecture allowing different configurations to meet the application domain needs, the task is then to find suitable mechanisms. For example, one of the main problems of synchronizing security states of sleepy nodes, as listed in the last subsection, lies in difficulties in authentication; these nodes may not have received in time the most recent update of security material. Similarly, the issues of minimal manual configuration, prolonged rollout and delayed addition of nodes, and network topology changes also complicate security management. In such case the ROLL protocol may need to bootstrap the authentication process and allow for flexible expiration scheme of authentication credentials. This exemplifies the need for the coordination and interoperation between the requirements of the ROLL routing protocol and that of the system security elements. Similarly, the vulnerability brought forth by some special-function nodes, e.g., gateways/sinks requires the assurance, particularly, of the availability of communication channels and node resources, or that the neighbor discovery process operates without undermining routing availability. Tsao, et al. Expires October 1, 2010 [Page 34] =0C Internet-Draft Security Framework for ROLL March 2010 There and other factors which are not part of a ROLL routing protocol can still affect its operation. This includes elements such as weaker barrier to accessing the data or security material stored on the nodes through physical means; therefore, the internal and external interfaces of a node need to be adequate for guarding the integrity, and possibly the confidentiality, of stored information, as well as the integrity of routing and route generation processes. Figure 2 provides an overview of the larger context of system security and the relationship between ROLL requirements and measures and those that relate to the LLN system. Tsao, et al. Expires October 1, 2010 [Page 35] =0C Internet-Draft Security Framework for ROLL March 2010 Security Services for ROLL-Addressable Security Requirements | | +---+ +---+ Node_i | | Node_j _____v___ ___v_____ Specify Security / \ / \ Specify Security Requirements | Routing | | Routing | Requirements +---------| Protocol| | Protocol|---------+ | | Entity | | Entity | | | \_________/ \_________/ | | | | | |ROLL-Specified | | ROLL-Specified| ---Interface | | Interface--- | ...................................... | | : | | : | | : +-----+----+ +----+-----+ : | | : |Transport/| |Transport/| : | ____v___ : +>|Network | |Network |<+ : ___v____ / \ : | +-----+----+ +----+-----+ | : / \ | |-:-+ | | +-:-| | |Security| : +-----+----+ +----+-----+ : |Security| +->|Services|-:-->| Link | | Link |<--:-|Services|<-+ | |Entity | : +-----+----+ +----+-----+ : |Entity | | | | |-:-+ | | +-:-| | | | \________/ : | +-----+----+ +----+-----+ | : \________/ | | : +>| Physical | | Physical |<+ : | Application : +-----+----+ +----+-----+ : Application Domain User : | | : Domain User Configuration : |__Comm. Channel_| : Configuration : : ...Transport Network.................. Figure 2: LLN Device Security Model JP> Great figure. Just clarify "transport/network" 7. Application of ROLL Security Framework to RPL JP> Expand acronym when first used (RPL) This section applies the assessments given in Section 6 to RPL JP> Ad reference (draft-ietf-roll-rpl) as an illustration of the application of the LLN security framework. Specializing the approach used in Section 3.1, Figure 3 gives a level-1 data flow diagram representation of RPL to show the routing "assets" and "points of access" that may be vulnerable and need to be protected. Tsao, et al. Expires October 1, 2010 [Page 36] =0C Internet-Draft Security Framework for ROLL March 2010 ............................................ : : |Link-Local : : Multicast : : or Node_i|<----->(DIO/DIS/DAO)<--------------+ : : ^ | : : | ______V______ : : | Candidate : : V Neighbor List : : (RPL Control incl. ------+------ : : Trickle Timer, | : : Loop Avoidance) V : : ^ (Route Generation) : : | | : : | ______V______ : : +------+ Routing Table : : | ------+------ : : | | : : RPL on Node_j | | : ..................|.............|........... | | |Forwarding V | To/=46rom Node_k|<-------->(Read/Write | Flow Label)<-------+ Figure 3: Data Flow Diagram of RPL =46rom Figure 3, it is seen that threats to the proper operation of = RPL are realized through attacks on its DIO, DIS, and DAO messages, as well as on the information the protocol places on the IPv6 Flow Labels.=20 JP> Please update since information is now carried in the Hop-by-hop = header=20 with the RPL option (draft in 6man). As set forth in Section 6.1 to Section 6.4, the base security requirements concern message integrity, authenticity and liveliness of the principals of a connection, and protection against message replay; message encryption may be desirable. The security objectives for RPL are therefore to ensure that 1. participants of the DIO, DIS, and DAO message exchanges are authentic; 2. the received DIO, DIS, and DAO messages are not modified during transportation; 3. the received DIO, DIS, and DAO messages are not retransmissions of previous messages; 4. the content of the DIO, DIS, and DAO messages may be made legible to only authorized entities. Tsao, et al. Expires October 1, 2010 [Page 37] =0C Internet-Draft Security Framework for ROLL March 2010 In meeting the above objectives, RPL also needs to provide tunable mechanisms both to allow matching the security afforded to the application domain requirements and to enable efficient use of system resources, as discussed in Section 6.5.1 and Section 6.5.2. The functions of the different RPL messages and information placed within the user data plane Flow Labels=20 JP> s/"user data plane"/"user data plane (RPL option TLV carried in the = IPv6 Hop-by-hop header) are factors that can be taken into account when deciding the optional security features and levels of strength to be afforded. For example, the DIO messages build routes to roots while the DAO messages support the building of downward routes to leaf nodes. Consequently, there may be application environments in which the directions of the routes have different importance and thus warrant the use of different security features and/or strength. In other words, it may be desirable to have an RPL security design that extends the tunability of the security features and strengths to message types. The use of a per- message security specification will allow flexibility in permitting application-domain security choices as well as overall tunability. 8. IANA Considerations This memo includes no request to IANA. 9. Security Considerations The framework presented in this document provides security analysis and design guidelines with a scope limited to ROLL. Security services are identified as requirements for securing ROLL. The results are applied to RPL, with consequent recommendations. 10. Acknowledgments The authors would like to acknowledge the review and comments from Rene Struik. 11. References 11.1. Normative References [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Tsao, et al. Expires October 1, 2010 [Page 38] =0C Internet-Draft Security Framework for ROLL March 2010 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. 11.2. Informative References [Huang2003] Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J. Zhang, "Fast Authenticated Key Establishment Protocols for Self-Organizing Sensor Networks", in Proceedings of the 2nd ACM International Conference on Wireless Sensor Networks and Applications, San Diego, CA, USA, pp. 141- 150, Sept. 19 2003. [I-D.ietf-roll-building-routing-reqs] Martocci, J., Riou, N., Mil, P., and W. Vermeylen, "Building Automation Routing Requirements in Low Power and Lossy Networks", draft-ietf-roll-building-routing-reqs-09 (work in progress), January 2010. [I-D.ietf-roll-home-routing-reqs] Brandt, A. and J. Buron, "Home Automation Routing Requirements in Low Power and Lossy Networks", draft-ietf-roll-home-routing-reqs-11 (work in progress), January 2010. JP> Update the two references above. [I-D.ietf-roll-rpl] Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-07 (work in progress), March 2010. [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-03 (work in progress), March 2010. [I-D.suhopark-hello-wsn] Park, S., "Routing Security in Sensor Network: HELLO Flood Attack and Defense", draft-suhopark-hello-wsn-00 (work in progress), December 2005. [Karlof2003] Karlof, C. and D. Wagner, "Secure routing in wireless sensor networks: attacks and countermeasures", Elsevier Tsao, et al. Expires October 1, 2010 [Page 39] =0C Internet-Draft Security Framework for ROLL March 2010 AdHoc Networks Journal, Special Issue on Sensor Network Applications and Protocols, 1(2):293-315, September 2003. [Messerges2003] Messerges, T., Cukier, J., Kevenaar, T., Puhl, L., Struik, R., and E. Callaway, "Low-Power Security for Wireless Sensor Networks", in Proceedings of the 1st ACM Workshop on Security of Ad Hoc and Sensor Networks, Fairfax, VA, USA, pp. 1-11, Oct. 31 2003. [Myagmar2005] Myagmar, S., Lee, AJ., and W. Yurcik, "Threat Modeling as a Basis for Security Requirements", in Proceedings of the Symposium on Requirements Engineering for Information Security (SREIS'05), Paris, France, pp. 94-102, Aug 29, 2005. [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009. [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009. [Wan2004] Wan, T., Kranakis, E., and PC. van Oorschot, "S-RIP: A Secure Distance Vector Routing Protocol", in Proceedings of the 2nd International Conference on Applied Cryptography and Network Security, Yellow Mountain, China, pp. 103-119, Jun. 8-11 2004. Authors' Addresses Tzeta Tsao (editor) Eka Systems 20201 Century Blvd. Suite 250 Germantown, Maryland 20874 USA Email: tzeta.tsao@ekasystems.com Tsao, et al. Expires October 1, 2010 [Page 40] =0C Internet-Draft Security Framework for ROLL March 2010 Roger K. Alexander (editor) Eka Systems 20201 Century Blvd. Suite 250 Germantown, Maryland 20874 USA Email: roger.alexander@ekasystems.com Mischa Dohler (editor) CTTC Parc Mediterrani de la Tecnologia, Av. Canal Olimpic S/N Castelldefels, Barcelona 08860 Spain Email: mischa.dohler@cttc.es Vanesa Daza (editor) Universitat Pompeu Fabra P/ Circumval.lacio 8, Oficina 308 Barcelona 08003 Spain Email: vanesa.daza@upf.edu Angel Lozano (editor) Universitat Pompeu Fabra P/ Circumval.lacio 8, Oficina 309 Barcelona 08003 Spain Email: angel.lozano@upf.edu JP> Are you all editors ? if so, remove the term "Editors" Tsao, et al. Expires October 1, 2010 [Page 41] =0C= --Apple-Mail-2-456749292 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii JP>

Starting with = ID nits:

Checking references for intended status: =
Informational
  =
--------------------------------------------------------------------------=
--

  =3D=3D Outdated reference: draft-ietf-roll-building-routing-reqs has =
been
     published as RFC 5867

  =3D=3D Outdated reference: draft-ietf-roll-home-routing-reqs has been =
published
     as RFC 5826

  =3D=3D Outdated reference: A later version (-11) exists of
     draft-ietf-roll-rpl-07


Networking Working Group                        =
            T. Tsao, Ed.
Internet-Draft                                         R. Alexander, Ed.
Intended status: Informational                               Eka Systems
Expires: October 1, 2010                                  M. Dohler, Ed.
                                                                    CTTC
                                                            V. Daza, Ed.
                                                          A. Lozano, Ed.
                                                Universitat Pompeu Fabra
                                                          March 30, 2010


   A Security Framework for Routing over Low Power and Lossy Networks
                 draft-ietf-roll-security-framework-00

Abstract

   This document presents a security framework for routing over low
   power and lossy networks.  
JP> Add acronym (LLN)
The development builds upon =
previous work
   on routing security and adapts the assessments to the issues and
   constraints specific to low power and lossy networks.  A systematic
   approach is used in defining and evaluating the security threats and
   identifying applicable countermeasures.  These assessments provide
   the basis of the security recommendations for incorporation into low
   power, lossy network routing protocols.  As an illustration, this
   framework is applied to RPL.
JP> Expand acronym when first used (LLN here).

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."




Tsao, et al.             Expires October 1, 2010                [Page 1]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ie=
tf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 1, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/lice=
nse-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.





























Tsao, et al.             Expires October 1, 2010                [Page 2]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Considerations on ROLL Security  . . . . . . . . . . . . . . .  5
     3.1.  Routing Assets and Points of Access  . . . . . . . . . . .  6
     3.2.  The CIA Security Reference Model . . . . . . . . . . . . .  8
     3.3.  Issues Specific to or Amplified in LLNs  . . . . . . . . .  9
     3.4.  ROLL Security Objectives . . . . . . . . . . . . . . . . . 11
   4.  Threats and Attacks  . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Threats and Attacks on Confidentiality . . . . . . . . . . 12
       4.1.1.  Routing Exchange Exposure  . . . . . . . . . . . . . . 12
       4.1.2.  Routing Information (Routes and Network Topology)
               Exposure . . . . . . . . . . . . . . . . . . . . . . . 13
     4.2.  Threats and Attacks on Integrity . . . . . . . . . . . . . 13
       4.2.1.  Routing Information Manipulation . . . . . . . . . . . 14
       4.2.2.  Node Identity Misappropriation . . . . . . . . . . . . 14
     4.3.  Threats and Attacks on Availability  . . . . . . . . . . . 15
       4.3.1.  Routing Exchange Interference or Disruption  . . . . . 15
       4.3.2.  Network Traffic Forwarding Disruption  . . . . . . . . 15
       4.3.3.  Communications Resource Disruption . . . . . . . . . . 15
       4.3.4.  Node Resource Exhaustion . . . . . . . . . . . . . . . 16
   5.  Countermeasures  . . . . . . . . . . . . . . . . . . . . . . . 16
     5.1.  Confidentiality Attack Countermeasures . . . . . . . . . . 17
       5.1.1.  Countering Deliberate Exposure Attacks . . . . . . . . 17
       5.1.2.  Countering Sniffing Attacks  . . . . . . . . . . . . . 17
       5.1.3.  Countering Traffic Analysis  . . . . . . . . . . . . . 19
       5.1.4.  Countering Physical Device Compromise  . . . . . . . . 19
       5.1.5.  Countering Remote Device Access Attacks  . . . . . . . 21
     5.2.  Integrity Attack Countermeasures . . . . . . . . . . . . . 21
       5.2.1.  Countering Tampering Attacks . . . . . . . . . . . . . 22
       5.2.2.  Countering Overclaiming and Misclaiming Attacks  . . . 22
       5.2.3.  Countering Identity (including Sybil) Attacks  . . . . 22
       5.2.4.  Countering Routing Information Replay Attacks  . . . . 23
       5.2.5.  Countering Byzantine Routing Information Attacks . . . 23
     5.3.  Availability Attack Countermeasures  . . . . . . . . . . . 24
       5.3.1.  Countering HELLO Flood Attacks and ACK Spoofing
               Attacks  . . . . . . . . . . . . . . . . . . . . . . . 24
       5.3.2.  Countering Overload Attacks  . . . . . . . . . . . . . 26
       5.3.3.  Countering Selective Forwarding Attacks  . . . . . . . 27
       5.3.4.  Countering Sinkhole Attacks  . . . . . . . . . . . . . 27
       5.3.5.  Countering Wormhole Attacks  . . . . . . . . . . . . . 28
   6.  ROLL Security Features . . . . . . . . . . . . . . . . . . . . 28
     6.1.  Confidentiality Features . . . . . . . . . . . . . . . . . 29
     6.2.  Integrity Features . . . . . . . . . . . . . . . . . . . . 30
     6.3.  Availability Features  . . . . . . . . . . . . . . . . . . 31
     6.4.  Additional Related Features  . . . . . . . . . . . . . . . 31
     6.5.  Consideration on Matching Application Domain Needs . . . . 31



Tsao, et al.             Expires October 1, 2010                [Page 3]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


       6.5.1.  Security Architecture  . . . . . . . . . . . . . . . . 32
       6.5.2.  Mechanisms and Operations  . . . . . . . . . . . . . . 34
   7.  Application of ROLL Security Framework to RPL  . . . . . . . . 36
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 38
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 38
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 38
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 38
     11.2. Informative References . . . . . . . . . . . . . . . . . . 39
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40









































Tsao, et al.             Expires October 1, 2010                [Page 4]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


1.  Terminology

   This document conforms to the terminology defined in
   [I-D.ietf-roll-terminology].

JP> There are other terms used in =
the document that could be added here
(see below).



2.  Introduction

   In recent times, networked wireless devices have found an increasing
   number of applications in various fields.  Yet, for reasons ranging
   from operational application to economics, these wireless =
devices 
JP> This =
does not apply only to wireless links (e.g. PLC)
are
   often supplied with minimum physical resources, e.g., limited power
   reserve, slow speed or low capability computation, or small memory
   size.  As a consequence, the resulting networks are more prone to
   loss of traffic and other vulnerabilities.  The proliferation of
   these low power and lossy networks (LLNs), however, are drawing
   efforts to examine and address their potential networking challenges.

   This document presents a framework for securing routing over low
   power and lossy networks (ROLL)
JP> s/ROLL/LLN
 through an analysis that starts =
from
   the routing basics.  The objective is two-fold.  First, the framework
   will be used to identify pertinent security issues.  Second, it will
   facilitate both the assessment of a protocol's security threats and
   the identification of the necessary features for development of
   secure protocols for ROLL.
JP> s/ROLL/The ROLL Working Group.

   The approach adopted in this effort proceeds in four steps, to
   examine ROLL security issues, to analyze threats and attacks, to
   consider the countermeasures, and then to make recommendations for
   securing ROLL.
JP> Could you just replace "ROLL" by the "the routing =
protocol developed 
by the ROLL Working Group" or Define ROLL as Routing Over Low =
power
and Lossy networks.
  The basis is =
found on identifying the assets and
   points of access of routing and evaluating their security needs based
   on the Confidentiality, Integrity, and Availability (CIA) model in
   the context of LLN.  The utility of this framework is demonstrated
   with an application to RPL [I-D.ietf-roll-rpl].


3.  Considerations on ROLL Security

   This section sets the stage for the development of the framework by
   applying the systematic approach proposed in [Myagmar2005] to the
   routing security problem, while also drawing references from other
   reviews and assessments found in the literature, particularly,
   [RFC4593] and [Karlof2003].  The subsequent subsections begin with a
   focus on the elements of a generic routing process that is used to
   establish routing assets and points of access of the routing
   functionality.  Next, the CIA security model is briefly described.
   Then, consideration is given to issues specific to or amplified in
   LLNs.  This section concludes with the formulation of a set of



Tsao, et al.             Expires October 1, 2010                [Page 5]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   security objectives for ROLL.

3.1.  Routing Assets and Points of Access

   An asset implies important system component (including information,
   process, or physical resource), the access to, corruption or loss of
   which adversely affects the system.  In network routing, assets lie
   in the routing information, routing process, and node's physical
   resources.  That is, the access to, corruption, or loss of these
   elements adversely affects system routing.  In network routing, a
   point of access refers to the point of entry facilitating
   communication with or other interaction with a system component in
   order to use system resources to either manipulate information or
   gain knowledge of the information contained within the system.
   Security of the routing protocol must be focused on the assets of the
   routing nodes and the points of access of the information exchanges
   and information storage that may permit routing compromise.  The
   identification of routing assets and points of access hence provides
   a basis for the identification of associated threats and attacks.

   This subsection identifies assets and points of access of a generic
   routing process with a level-0 
JP> Explain what you mean by "level-0"
data flow =
diagram.  The use of the
   data flow diagram allows for a clear, concise model of the routing
   functionality; it also has the benefit of showing the manner in which
   nodes participate in the routing process, thus providing context when
   later threats and attacks are considered.  The goal of the model is
   to be as detailed as possible so that corresponding components and
   mechanisms in an individual routing protocol can be readily
   identified, but also to be as general as possible to maximize the
   relevancy of this effort for the various existing and future
   protocols.  Nevertheless, there may be discrepancies, likely in the
   form of additional elements, when the model is applied to some
   protocols.  For such cases, the analysis approach laid out in this
   document should still provide a valid and illustrative path for their
   security assessment.

   Figure 1 shows that nodes participating in the routing process
   transmit messages to determine their neighbors (neighbor discovery).
   Using the neighboring relationships, routing protocols may exchange
   network topology (including link-specific information) to generate
   routes or may exchange routes directly as part of a routing exchange;
   nodes which do not directly participate in the process with a given
   node will get the route/topology information relayed from others. =
 
JP> You can remove the =
previous sentence (no need to make assumption in
in a framework on the mode of =
operation of the routing protocol).
It
   is likely that a node will store some or all of the routes and
   topology information according to tradeoffs of node resources and
   latency associated with the particular routing protocol. =
 
JP> Why tradeoff with =
latency ?
The nodes
   use the derived routes for making forwarding decisions.




Tsao, et al.             Expires October 1, 2010                [Page 6]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


               ...................................................
               :                                                 :
               :                            _________________    :
   |Node_i|<------->(Neighbor Discovery)--->Neighbor Topology   =
 :
               :                            -------+---------    :
               :                                   |             :
   |Node_j|<------->(Route/Topology       +--------+             :
               :     Exchange)            |                      :
               :           |              V            ______    :
               :           +---->(Route Generation)--->Routes    :
               :                                       ---+--    :
               :                                          |      :
               : Routing on a Node Node_k                 |      :
               ...................................................
                                                          |
   |Forwarding                                            |
    On Node_l|<-------------------------------------------+


   Notation:

   (Proc)     A process Proc

   ________
   DataBase   A data storage DataBase
   --------

   |Node_n|   An external entity Node_n

   ------->   Data flow


         Figure 1: Data Flow Diagram of a Generic Routing Process

   It is seen from Figure 1 that

   o  Assets include

      *  routing and/or topology information;

      *  communication channel resources (bandwidth);

      *  node resources (computing capacity, memory, and remaining
         energy);

      *  node identifiers (including node identity and ascribed
         attributes such as relative or absolute node location).




Tsao, et al.             Expires October 1, 2010                [Page 7]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   o  Points of access include

      *  neighbor discovery;

      *  route/topology exchange;

      *  node physical interfaces (including access to data storage).

   A focus on the above list of assets and points of access enables a
   more directed assessment of routing security.  Indeed, the intention
   is to be comprehensive; nonetheless, the discussions to follow on
   physical related issues are not related to routing protocol design
   but provided for reference since they do have direct consequences on
   the security of routing.

3.2.  The CIA Security Reference Model

   At the conceptual level, security within an information system in
   general and applied to ROLL in particular is concerned with the
   primary issues of confidentiality, integrity, and availability.  In
   the context of ROLL:

   Confidentiality
         Confidentiality involves the protection of routing information
         as well as routing neighbor maintenance exchanges so that only
         authorized and intended network entities may view or access =
it.
JP> By =
"neighbor" just mention that we're referring to routing neighbor in =
the 
context on =
this document.
         Because of the =
wireless, 
JP> Not always wireless ! Just make sure to make it clear =
even if the comment
below applies to wireless =
links.
and sometimes ad hoc, nature of the
         network, confidentiality also extends to the neighbor state and
         database information within the routing device since the
         deployment of the network creates the potential for
         unauthorized access to the physical devices themselves.

   Integrity
         Integrity, as a security principle, entails the protection of
         routing information and routing neighbor maintenance exchanges,
         as well as derived information maintained in the database, from
         misuse or unauthorized and improper modification.  In addition,
         integrity also requires 
JP> Is it really integrity that =
requires authenticity ?
the authenticity of claimed =
identity in
         the origin and destination of a message, access and removal of
         data, execution of the routing process, and use of computing
         and energy resources.

   Availability
         Availability ensures that routing information exchanges and
         forwarding services need to be available when they are required
         for the functioning of the serving network.  Availability will
         apply to maintaining efficient and correct operation of routing
         and neighbor discovery exchanges (including needed information)



Tsao, et al.             Expires October 1, 2010                [Page 8]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


         and forwarding services so as not to impair or limit the
         network's central traffic flow function.

   It is noted that, besides those captured in the CIA model, non-
   repudiation is a security interest under certain circumstances.  With
   respect to routing, non-repudiation will involve providing some
   ability to allow traceability or network management review of
   participants of the routing process including the ability to
   determine the events and actions leading to a particular routing
   state.  Non-repudiation implies after the fact and thus relies on the
   logging or other capture of on-going routing exchanges.  Given the
   limited resources of a node and potentially the communication
   channel, and considering the operating mode associated with LLNs,
   routing transaction logging or auditing process communication
   overhead will not be practical; as such, non-repudiation is not
   further considered as a relevant ROLL security issue.
JP> May be one =
sentence to define "non-repudiation" would be =
helpful


3.3.  Issues Specific to or Amplified in LLNs

   The work [RFC5548] and [RFC5673], as well as two other ongoing
   efforts, [I-D.ietf-roll-home-routing-reqs] and
   [I-D.ietf-roll-building-routing-reqs], 
JP> Update the =
draft-ietf references. They are all RFC (5826 and 5867 =
respectively).
have identified =
ROLL 
JP> "ROLL specific" -> "routing requirement specific to =
LLNs"
specific
   requirements and constraints for the urban, industrial, home
   automation, and building automation application domains,
   respectively.  The following is a list of observations and evaluation
   of their impact on routing security considerations.

   Limited energy reserve
JP> =
s/reserve/resources/
, memory, and processing =
resources
JP> s/processing resources/processing nodes =
resources/

         As a consequence of these constraints, there is an even more
         critical need than usual for a careful trade study on which and
         what level of security services are to be afforded during the
         system design process.  In addition, the choices of security
         mechanisms are more stringent.  Synchronization of security
         states with sleepy nodes is yet another issues.
JP> You can mention "from a few =
dozens to several (hundreds) of thousands of =
nodes"
         The possibly numerous nodes to be =
deployed, as well as the
         general level of expertise of the installers, make manual on-
         site configuration unlikely.  Prolonged rollout and delayed
         addition of nodes, which may be from old inventory, over the
         lifetime of the network, also complicate the operations of key
         management.

   Autonomous operations
         Self-forming and self-organizing are commonly prescribed
         requirements of ROLL
JP> =
s/ROLL/LLNs
.  In other words, a ROLL =
protocol 
JP> A Routing protocol designed for =
LLNs
needs to
         contain elements of ad hoc networking and =
cannot 
JP> (in most cases)
rely on manual
         configuration for initialization or local filtering rules.



Tsao, et al.             Expires October 1, 2010                [Page 9]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


         Network topology/ownership changes, partitioning or merging, as
         well as node replacement, can all contribute to key management
         issues.

   Highly directional traffic
         Some types of LLNs see a high percentage of their total traffic
         traverse between the nodes and the gateways 
JP> Use "LBR" as =
defined in http=
://datatracker.ietf.org/doc/draft-ietf-roll-terminology/ =
instead
of =
gateway
where the LLNs
         connect to wired networks.  
JP> s/wired networks/to non LLN =
network (since wired links may be present in =
LLNs)
The special routing status of and
         the greater volume of traffic near the =
gateways/sinks 
JP> Same comment use only the LBR =
terminology throughout the document.
have
         routing security consequences.
JP> You can mention that when P2MP =
and MP2P traffic represents a majority of the traffic
routing =
attacks consisting of advertising low route cost may cause serious =
damages.


   Unattended locations and limited physical security
         Many applications have the nodes deployed in unattended or
         remote locations; furthermore, the nodes themselves are often
         built with minimal physical protection.  These constraints
         lower the barrier of accessing the data or security material
         stored on the nodes through physical means.

   Support for mobility
         On the one hand, only a number of applications require the
         support of mobile nodes, e.g., a home LLN that includes nodes
         on wearable health care devices or an industry LLN that
         includes nodes on cranes and vehicles.  On the other hand, if a
         routing protocol is indeed used in such applications, it will
         clearly need to have corresponding security mechanisms.

   Support for multicast and anycast
         Support for multicast and anycast is called out chiefly for
         large-scale networks.  As these are relatively new routing
         technologies, 
JP> Heu ... Multicast is not really =
new
there has been an ongoing effort devoted to =
their
         security mechanisms, e.g., from the IETF Multicast Security
         working group.  However, inclusion of such mechanisms in a
         routing protocol, and consequently their security analysis, are
         still areas not fully developed or their impact entirely
         understood, whether in a more traditional wired or wireless
         network, or LLN.

   The above list considers how a LLN's physical constraints, size,
   operations, and varieties of application areas may impact security.
   It is noted here also that LLNs commonly have the majority, if not
   all, of their nodes equipped to route.  
JP> I would suppress =
the previous sentence, since in this document we =
are 
only =
considering nodes acting as routers.
One of the =
consequences is
   that the distinction between the link and network layers become
   artificial in some respects.  Similarly, the distinction between a
   host and a router is blurred, especially when the set of applications
   running on a node is small.  
JP> Same thing for the previous =
sentence, which may be misleading.
The continued =
evolution of ROLL and its
   security functionality requirements need close attention.
JP> s/ROLL/routing =
protocol designed by the ROLL WG






Tsao, et al.             Expires October 1, 2010               [Page 10]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


3.4.  ROLL Security Objectives

   This subsection applies the CIA model to the routing assets and
   access points, taking into account the LLN issues, to develop a set
   of ROLL security objectives.

   Since the fundament function of a routing protocol is to build routes
   for forwarding packets, it is essential to ensure that

   o  routing/topology information is not tampered during transfer and
      in storage;

   o  routing/topology information is not misappropriated;

   o  routing/topology information is available when needed.

   In conjunction, it is necessary to be assured of

   o  the authenticity and legitimacy of the participants of the

JP> routing =
neighbor
      neighbor discovery process;

   o  the routing/topology information received was faithfully generated
      according to the protocol design.

   However, when trust cannot be fully vested through authentication of
   the principals alone, i.e., concerns of insider attack, assurance of
   the truthfulness and timeliness of the received routing/topology
   information is necessary.  With regard to confidentiality, protecting
   the routing/topology information from eavesdropping or unauthorized
   exposure is in itself less pertinent in general to the routing
   function.

   One of the main problems of synchronizing security states of sleepy
   nodes, as listed in the last subsection, lies in difficulties in
   authentication; these nodes may not have received in time the most
   recent update of security material.  Similarly, the issues of minimal
   manual configuration, prolonged rollout and delayed addition of
   nodes, and network topology changes also complicate key management.
   Hence, ROLL 
JP> Change ROLL for routing in =
LLN

needs to bootstrap the authentication process =
and allow
   for flexible expiration scheme of authentication credentials.

   The vulnerability brought forth by some special-function nodes, e.g.,
   gateways/sinks 
JP> Change for =
LBR
requires the assurance, particularly,

   o  of the availability of communication channels and node resources;

JP> but how =
to ensure and the unavailable of the channels is due to a =
security 
attack as opposed to simply being not =
operational?
   o  that the neighbor discovery =
process operates without undermining
      routing availability.



Tsao, et al.             Expires October 1, 2010               [Page 11]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   There are other factors which are not part of a ROLL protocol but
   directly affecting its function.  These factors include weaker
   barrier of accessing the data or security material stored on the
   nodes through physical means; therefore, the internal and external
   interfaces of a node need to be adequate for guarding the integrity,
   and possibly the confidentiality, of stored information, as well as
   the integrity of routing and route generation processes.

   Each individual system's use and environment will dictate how the
   above objectives are applied, including the choices of security
   services as well as the strengths of the mechanisms that must be
   implemented.  The next two sections give a closer look at how the
   ROLL security objectives may be compromised and countered,
   respectively.


4.  Threats and Attacks

   This section outlines general categories of threats under the CIA
   model and highlights the specific attacks in each of these categories
   for ROLL.  As defined in [RFC4949], a threat is "a potential for
   violation of security, which exists when there is a circumstance,
   capability, action, or event that could breach security and cause
   harm."  An attack is "an assault on system security that derives from
   an intelligent threat, i.e., an intelligent act that is a deliberate
   attempt (especially in the sense of a method or technique) to evade
   security services and violate the security policy of a system."

   The subsequent subsections consider the threats and their realizing
   attacks that can cause security breaches under the CIA model to the
   assets identified in Section 3.1.  The analysis steps through the
   security concerns of each routing asset and looks at the attacks that
   can exploit points of access.  The manifestation of the attacks is
   assumed to be from either inside or outside attackers, whose
   capabilities may be limited to node-equivalent or more sophisticated
   computing platforms.

4.1.  Threats and Attacks on Confidentiality

   The assessment in Section 3.2 indicates that information assets are
   exposed to confidentiality threats from all points of access.

4.1.1.  Routing Exchange Exposure

   Routing exchanges include both routing information as well as
   information associated with the establishment and maintenance of
   neighbor state information.




Tsao, et al.             Expires October 1, 2010               [Page 12]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   The exposure of routing information exchanged will allow unauthorized
   sources to gain access to the content of the exchanges between
   communicating nodes.  The exposure of neighbor state information will
   allow unauthorized sources to gain knowledge of communication links
   between routing nodes that are necessary to maintain routing
   information exchanges.

   The forms of attack that allow unauthorized access or exposure of
   routing exchange information, as reported in the literature, include

   o  Deliberate exposure;

   o  Sniffing;

   o  Traffic analysis.

4.1.2.  Routing Information (Routes and Network Topology) Exposure

   Routes and neighbor topology information are the products of the
   routing process that are stored within the node device databases.

   The exposure of this information will allow unauthorized sources to
   gain direct access to the configuration and connectivity of the
   network thereby exposing routing to targeted attacks on key nodes or
   links.  Since routes and neighbor topology information is stored
   within the node device, threats or attacks on the confidentiality of
   the information will apply to the physical device including specified
   and unspecified internal and external interfaces.

   The forms of attack that allow unauthorized access or exposure of the
   routing information (other than occurring through explicit node
   exchanges) will include

   o  Physical device compromise;

   o  Remote device access attacks (including those occurring through
      remote network management or software/field upgrade interfaces).

   More detailed descriptions of the exposure attacks on routing
   exchange and information will be given in Section 5 together with the
   corresponding countermeasures.

4.2.  Threats and Attacks on Integrity

   The assessment in Section 3.2 indicates that information and identity
   assets are exposed to integrity threats from all points of access.





Tsao, et al.             Expires October 1, 2010               [Page 13]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


4.2.1.  Routing Information Manipulation

   Manipulation of routing information will allow unauthorized sources
   to influence the operation and convergence of the routing protocols
   and ultimately impact the forwarding decisions made in the network.
   Manipulation of neighbor state (topology) 
JP> topology and =
reachability information
information will allow
   unauthorized sources to influence the nodes with which routing
   information is exchanged and updated.  The consequence of
   manipulating routing exchanges can thus lead to sub-optimality and
   fragmentation or partitioning of the network by restricting the
   universe of routers with which associations can be established and
   maintained.

JP> Can =
also lead to attract traffic, black-holes, =
... 
   The forms of attack that allow manipulation =
to compromise the content
   and validity of routing information include

   o  Falsification, including overclaiming and misclaiming;

   o  Routing information replay;

   o  Byzantine (internal) attacks that permit corruption of routing
      information in the node even where the node continues to be a
      validated entity within the network;

   o  Physical device compromise.

4.2.2.  Node Identity Misappropriation

   Falsification or misappropriation of node identity between routing
   participants opens the door for other attacks; it can also cause
   incorrect routing relationships to form and/or topologies to emerge.
   Routing attacks may also be mounted through less sophisticated node
   identity misappropriation in which the valid information broadcast or
   exchanged by a node is replayed without modification.  The receipt of
   seemingly valid information that is however no longer current can
   result in routing disruption, and instability (including failure to
   converge).  Without measures to authenticate the routing participants
   and to ensure the freshness and validity of the received information
   the protocol operation can be compromised.  The forms of attack that
   misuse node identity include

   o  Identity (including Sybil) attacks;

   o  Routing information replay.







Tsao, et al.             Expires October 1, 2010               [Page 14]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


4.3.  Threats and Attacks on Availability

   The assessment in Section 3.2 indicates that the process and
   resources assets are exposed to availability threats; attacks of this
   category may exploit directly or indirectly information exchange or
   forwarding.

4.3.1.  Routing Exchange Interference or Disruption

   Interference or disruption of routing information exchanges will
   allow unauthorized sources to influence the operation and convergence
   of the routing protocols by impeding the regularity of routing
   information exchange.

   The forms of attack that allow interference or disruption of routing
   exchange include

   o  Routing information replay;

   o  HELLO flood attacks and ACK spoofing;

   o  Overload attacks.

4.3.2.  Network Traffic Forwarding Disruption

   The disruption of the network traffic forwarding capability of the
   network will undermine the central function of network routers and
   the ability to handle user traffic.  This threat and the associated
   attacks affect the availability of the network because of the
   potential to impair the primary capability of the network.

   The forms of attack that allows disruption of network traffic
   forwarding include

   o  Selective forwarding attacks;

   o  Sinkhole attacks;

   o  Wormhole attacks.
JP> Can you add reference to =
sinkhole and wormhole attacks?
4.3.3.  =
Communications Resource Disruption

   Attacks mounted against the communication channel resource assets
   needed by the routing protocol can be used as a means of disrupting
   its operation.  However, while various forms of Denial of Service
   (DoS) attacks on the underlying transport subsystem will affect
   routing protocol exchanges and operation (for example physical layer
   RF jamming in a wireless network or link layer attacks), these



Tsao, et al.             Expires October 1, 2010               [Page 15]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   attacks cannot be countered by the routing protocol.  As such, the
   threats to the underlying transport network that supports routing is
   considered beyond the scope of the current document.  Nonetheless,
   attacks on the subsystem will affect routing operation and so must be
   directly addressed within the underlying subsystem and its
   implemented protocol layers.

4.3.4.  Node Resource Exhaustion

   A potential security threat to routing can arise from attempts to
   exhaust the node resource asset by initiating exchanges that can lead
   to the undue utilization of exhaustion of processing, memory or
   energy resources.  The establishment and maintenance of routing
   neighbors opens the routing process to engagement and potential
   acceptance of multiple neighboring peers.  Association information
   must be stored for each peer entity and for the wireless network
   operation provisions made to periodically update and reassess the
   associations.  An introduced proliferation of apparent routing peers
   can therefore have a negative impact on node resources.

   Node resources may also be unduly consumed by the attackers
   attempting uncontrolled topology peering or routing exchanges,
   routing replays, or the generating of other data traffic floods.
   Beyond the disruption of communications channel resources, these
   threats may be able to exhaust node resources only where the
   engagements are able to proceed with the peer routing entities.
   Routing operation and network forwarding functions can thus be
   adversely impacted by node resources exhaustion that stems from
   attacks that include

   o  Identity (including Sybil) attacks;

   o  Routing information replay attacks;

   o  HELLO flood attacks and ACK spoofing;

   o  Overload attacks.


5.  Countermeasures

   By recognizing the characteristics of LLNs that may impact routing
   and identifying potential countermeasures, this framework provides
   the basis for developing capabilities within ROLL protocols to deter
   the identified attacks and mitigate the threats.  The following
   subsections consider such countermeasures by grouping the attacks
   according to the classification of the CIA model so that associations
   with the necessary security services are more readily visible.



Tsao, et al.             Expires October 1, 2010               [Page 16]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   However, the considerations here are more systematic than confined to
   means available only within routing; the next section will then
   distill and make recommendations appropriate for a secured ROLL
   protocol.

5.1.  Confidentiality Attack Countermeasures

   Attacks on confidentiality may be mounted at the level of the routing
   information assets, at the points of access associated with routing
   exchanges between nodes, or through device interface access.  To gain
   access to routing/topology information, the attacker may rely on a
   compromised node that deliberately exposes the information during the
   routing exchange process, may rely on passive sniffing or analysis of
   routing traffic, or may attempt access through a component or device
   interface of a tampered routing node.

5.1.1.  Countering Deliberate Exposure Attacks

   A deliberate exposure attack is one in which an entity that is party
   to the routing process or topology exchange allows the routing/
   topology information or generated route information to be exposed to
   an unauthorized entity during the exchange.

   A prerequisite to countering this type of confidentiality attacks
   associated with the routing/topology exchange is to ensure that the
   communicating nodes are authenticated prior to data encryption
   applied in the routing exchange.  Authentication ensures that the
   nodes are who they claim to be even though it does not provide an
   indication of whether the node has been compromised.

   To prevent deliberate exposure, the process that communicating nodes
   use for establishing communication session keys must be symmetric at
   each node so that neither node can independently weaken the
   confidentiality of the exchange without the knowledge of its
   communicating peer.  A deliberate exposure attack will therefore
   require more overt and independent action on the part of the
   offending node.

   Note that the same measures which apply to securing routing/topology
   exchanges between operational nodes must also extend to field tools
   and other devices used in a deployed network where such devices can
   be configured to participate in routing exchanges.

5.1.2.  Countering Sniffing Attacks

   A sniffing attack seeks to breach routing confidentiality through
   passive, direct analysis and processing of the information exchanges
   between nodes.  A sniffing attack in an LLN that is not based on a



Tsao, et al.             Expires October 1, 2010               [Page 17]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   physical device compromise will rely on the attacker attempting to
   directly derive information from the over-the-air routing/topology
   communication exchange (neighbor discovery exchanges may of necessity
   be conducted in the clear thus limiting the extent to which the
   information can be kept confidential).

   Sniffing attacks can be directly countered through the use of data
   encryption for all routing exchanges.  Only when a validated and
   authenticated node association is completed will routing exchange be
   allowed to proceed using established session confidentiality keys and
   an agreed confidentiality algorithm.  
JP> Id security is "turned on". =
Could you specify that the routing protocol
will include security features =
according to this framework but some scenario
may not =
require their use, should they be provide by other means or =
not
needed in a specific environment.
The level of =
security applied
   in providing confidentiality will determine the minimum requirement
   for an attacker mounting this passive security attack.  Because of
   the resource constraints of LLN devices, symmetric (private) key
   session security will provide the best tradeoff in terms of node and
   channel resource overhead and the level of security achieved.  This
   will of course not preclude the use of asymmetric (public) key
   encryption during the session key establishment phase.

   As with the key establishment process, data encryption must include
   an authentication prerequisite to ensure that each node is
   implementing a level of security that prevents deliberate or
   inadvertent exposure.  The authenticated key establishment will
   ensure that confidentiality is not compromised by providing the
   information to an unauthorized entity (see also [Huang2003]).

   Based on the current state of the art, a minimum 128-bit key length
   should be applied where robust confidentiality is demanded for
   routing protection.  This session key shall be applied in conjunction
   with an encryption algorithm that has been publicly vetted and where
   applicable approved for the level of security desired.  Algorithms
   such as AES (adopted by the U.S. government) or Kasumi-Misty (adopted
   by the 3GPP 3rd generation wireless mobile consortium)
JP> Could you please ad references =
?
 are examples
   of symmetric-key algorithms capable of ensuring robust
   confidentiality for routing exchanges.  The key length, algorithm and
   mode of operation will be selected as part of the overall security
   tradeoff that also achieves a balance with the level of
   confidentiality afforded by the physical device in protecting the
   routing assets (see Section 5.1.4 below).

   As with any encryption algorithm, the use of ciphering
   synchronization parameters and limitations to the usage duration of
   established keys should be part of the security specification to
   reduce the potential for brute force analysis.







Tsao, et al.             Expires October 1, 2010               [Page 18]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


5.1.3.  Countering Traffic Analysis

   Traffic analysis provides an indirect means of subverting
   confidentiality and gaining access to routing information by allowing
   an attacker to indirectly map the connectivity or flow patterns
   (including link-load) 
JP> Aren't you making the assumption that LLNs only comprise =
radio
link layers ? =
** Please make sure that throughout the document you
are not making any assumption on the =
link layer (see other comments
above along the same lines).
of the network from which other =
attacks can be
   mounted.  The traffic analysis attack on a LLN may be passive and
   relying on the ability to read the immutable source/destination
   routing information that must remain unencrypted to permit network
   routing.  Alternatively, attacks can be active through the injection
   of unauthorized discovery traffic into the network.  By implementing
   authentication measures between communicating nodes, active traffic
   analysis attacks can be prevented within the LLN thereby reducing
   confidentiality vulnerabilities to those associated with passive
   analysis.

   One way in which passive traffic analysis attacks can be muted is
   through the support of load balancing that allows traffic to a given
   destination to be sent along diverse routing paths.  Where the
   routing protocol supports load balancing along multiple links at each
   node, the number of routing permutations in a wide area network
   surges thus increasing the cost of traffic analysis.  Network
   analysis through this passive attack will require a wider array of
   analysis points and additional processing on the part of the
   attacker.  In LLNs, the diverse radio connectivity and dynamic links
   (including potential frequency hopping) will help to further mitigate
   traffic analysis attacks when load balancing is =
implemented.
JP> Please =
indicate that this is trued if the link layer is wireless.

   The only means of fully countering a traffic analysis attack is
   through the use of tunneling (encapsulation) where encryption is
   applied across the entirety of the original packet source/destination
   addresses.  With tunneling there is a further requirement that the
   encapsulating intermediate nodes apply an additional layer of routing
   so that traffic arrives at the destination through dynamic routes.
   For LLNs, memory and processing constraints as well as the
   limitations of the communication channel will preclude both the
   additional routing traffic overhead 
JP> But tunneling may be used and is actually used in several =
cases
(e.g. this is the situation for example with RPL when an =
additional header
used for example for loop detection is =
added to the HbP header for traffic 
from outside =
of the LLN to a node inside the LLN).
and the node implementation
   required for tunneling countermeasures to traffic analysis.

5.1.4.  Countering Physical Device Compromise

   Given the distributed nature of LLNs, confidentiality of routing
   assets and points of access will rely heavily on the security of the
   routing devices.  One means of precluding attacks on the physical
   device is to prevent physical access to the node through other
   external security means.  However, given the environment in which
   LLNs operate, preventing unauthorized access to the physical device
   cannot be assured.  
JP> "in some cases" - for example in a Smart Grid environment =
the substation
has secured =
access.
Countermeasures must therefore be employed at =
the



Tsao, et al.             Expires October 1, 2010               [Page 19]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   device and component level so that routing/topology or neighbor
   information and stored route information cannot be accessed even if
   physical access to the node is obtained.

   With the physical device in the possession of an attacker,
   unauthorized information access can be attempted by probing internal
   interfaces or device components.  Device security must therefore move
   to preventing the reading of device processor code or memory
   locations without the appropriate security keys and in preventing the
   access to any information exchanges occurring between individual
   components.  Information access will then be restricted to external
   interfaces in which confidentiality, integrity and authentication
   measures can be applied.
JP> True but you may want to mention that this is not =
'routing security' 
specific.
   To prevent component information access, =
deployed routing devices
   must ensure that their implementation avoids address or data buses
   being connected to external general purpose input/output (GPIO) pins.
   Beyond this measure, an important component interface to be protected
   against attack is the Joint Test Action Group (JTAG) interface used
   for component and populated circuit board testing after manufacture.
   To provide security on the routing devices, components should be
   employed that allow fuses on the JTAG interfaces to be blown to
   disable access.  This will raise the bar on unauthorized component
   information access within a captured device.

   At the device level a key component information exchange is between
   the microprocessor and it associated external memory.  While
   encryption can be implemented to secure data bus exchanges, the use
   of integrated physical packaging which avoids inter-component
   exchanges (other than secure external device exchanges) will increase
   routing security against a physical device interface attack.  With an
   integrated package and disabled internal component interfaces, the
   level of physical device security can be controlled by managing the
   degree to which the device packaging is protected against expert
   physical decomposition and analysis.

   The device package should be hardened such that attempts to remove
   the integrated components will result in damage to access interfaces,
   ports or pins that prevent retrieval of code or stored information.
   The degree of VLSI or PCB 
JP> Could you please expand acronyms when first used =
?
package security through manufacture can be
   selected as a tradeoff or desired security consistent with the level
   of security achieved by measures applied for other routing assets and
   points of access.  With package hardening and restricted component
   access countermeasures, the security level will be raised to that
   provided by measures employed at the external communications
   interfaces.

   Another area of node interface vulnerability is that associated with



Tsao, et al.             Expires October 1, 2010               [Page 20]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   interfaces provided for remote software or firmware upgrades.  This
   may impact both routing information and routing/topology exchange
   security where it leads to unauthorized upgrade or change to the
   routing protocol running on a given node as this type of attack can
   allow for the execution of compromised or intentionally malicious
   routing code on multiple nodes.  Countermeasures to this device
   interface confidentiality attack needs to be addressed in the larger
   context of node remote access security.  This will ensure not only
   the authenticity of the provided code (including routing protocol)
   but that the process is initiated by an authorized (authenticated)
   entity.

   The above identified countermeasures against attacks on routing
   information confidentiality through internal device interface
   compromise must be part of the larger LLN system security as they
   cannot be addressed within the routing protocol itself.  Similarly,
   the use of field tools or other devices that allow explicit access to
   node information must implement security mechanisms to ensure that
   routing information can be protected against unauthorized access.
   These protections will also be external to the routing protocol and
   hence not part of ROLL.

5.1.5.  Countering Remote Device Access Attacks

   Where LLN nodes are deployed in the field, measures are introduced to
   allow for remote retrieval of routing data and for software or field
   upgrades.  These paths create the potential for a device to be
   remotely accessed across the network or through a provided field
   tool.  In the case of network management a node can be directly
   requested to provide routing tables and neighbor information.

   To ensure confidentiality of the node routing information against
   attacks through remote access, any device local or remote requesting
   routing information must be authenticated to ensure authorized
   access.  Since remote access is not invoked as part of a routing
   protocol security of routing information stored on the node against
   remote access will not be addressable as part of the routing
   protocol.

5.2.  Integrity Attack Countermeasures

   Integrity attack countermeasures address routing information
   manipulation, as well as node identity and routing information
   misuse.  Manipulation can occur in the form of falsification attack
   and physical compromise.  To be effective, the following development
   considers the two aspects of falsification, namely, the tampering
   actions and the overclaiming and misclaiming content.  The countering
   of physical compromise was considered in the previous section and is



Tsao, et al.             Expires October 1, 2010               [Page 21]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   not repeated here.  With regard to misuse, there are two types of
   attacks to be deterred, identity attacks and replay attacks.

5.2.1.  Countering Tampering Attacks

   Tampering may occur in the form of altering the message being
   transferred or the data stored.  Therefore, it is necessary to ensure
   that only authorized nodes can change the portion of the information
   that is allowed to be mutable, while the integrity of the rest of the
   information is protected, e.g., through well-studied cryptographic
   mechanisms.

   Tampering may also occur in the form of insertion or deletion of
   messages during protocol changes.  Therefore, the protocol needs to
   ensure the integrity of the sequence of the exchange sequence.

   The countermeasure to tampering needs to

   o  implement access control on storage;

   o  provide data integrity service to transferred messages and stored
      data;

   o  include sequence number under integrity protection.

5.2.2.  Countering Overclaiming and Misclaiming Attacks

   Both overclaiming and misclaiming aim to introduce false routes or
   topology that would not be generated by the network otherwise, while
   there is not necessarily tampering.  The requisite for a counter is
   the capability to determine unreasonable routes or topology.

   The counter to overclaiming and misclaiming may employ

   o  comparison with historical routing/topology data;

   o  designs which restrict realizable network topologies.

5.2.3.  Countering Identity (including Sybil) Attacks

   Identity attacks, sometimes simply called spoofing, seek to gain or
   damage assets whose access is controlled through identity.  In
   routing, an identity attacker can illegitimately participate in
   routing exchanges, distribute false routing information, or cause an
   invalid outcome of a routing process.

   A perpetrator of Sybil attacks assumes multiple identities.  The
   result is not only an amplification of the damage to routing, but



Tsao, et al.             Expires October 1, 2010               [Page 22]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   extension to new areas, e.g., where geographic distribution is
   explicit or implicit an asset to an application running on the LLN.

JP> You could =
mentioned that this is a particular concern in LLN where the =
traffic
flow is mostly =
P2MP and MP2P.
   The counter of identity attacks need to =
ensure the authenticity and
   liveliness of the parties of a message exchange; the measure may use
   shared key or public key based authentication scheme.  On the one
   hand, the large-scale nature of the LLNs makes the network-wide
   shared key scheme undesirable from a security perspective; on the
   other hand, public-key based approaches generally require more
   computational resources.  
JP> Could elaborate a little bit more on the CPU impact when =
using
Each system will need to make trade-off
   decisions based on its security requirements.

5.2.4.  Countering Routing Information Replay Attacks

   In routing, message replay can result in false topology and/or
   routes.  The counter of replay attacks need to ensure the freshness
   of the message.  On the one hand, there are a number of mechanisms
   commonly used for countering replay.  
JP> Want to add some =
references?
On the other hand, the choice
   should take into account how a particular mechanism is made available
   in a LLN.  For example, many LLNs have a central source of time and
   have it distributed by relaying, such that secured time distribution
   becomes a prerequisite of using timestamping to counter =
replay.
JP> Which means to =
support clocks, ...

5.2.5.  Countering Byzantine Routing Information Attacks

   Where a node is captured or compromized but continues to operate for
   a period with valid network security credentials, the potential
   exists for routing information to be manipulated.  This compromise of
   the routing information could thus exist in spite of security
   countermeasures that operate between the peer routing devices.

   Consistent with the end-to-end principle of communications, such an
   attack can only be fully addressed through measures operating
   directly between the routing entities themselves or by means of
   external entities able to access and independently analyze the
   routing information.  Verification of the authenticity and liveliness
   of the routing principals can therefore only provide a limited
   counter against internal (Byzantine) node attacks.
JP> Agree but this is not =
particularly tied to the end-to-end principle.

   For link state routing protocols where information is =
flooded
JP> add "with area =
(OSPF) or levels (ISIS)
   countermeasures can be directly applied by =
the routing entities
   through the processing and comparison of link state information
   received from different peers.  By comparing the link information
   from multiple sources decisions can be made by a routing node or
   external entity with regard to routing information validity.

   For distance vector protocols where information is aggregated at each
   routing node it is not possible for nodes to directly detect



Tsao, et al.             Expires October 1, 2010               [Page 23]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   Byzantine information manipulation attacks from the routing
   information exchange.  In such cases, the routing protocol must
   include and support indirect communications exchanges between non-
   adjacent routing peers to provide a secondary channel for performing
   routing information validation.  S-RIP [Wan2004] is an example of the
   implementation of this type of dedicated routing protocol security
   where the correctness of aggregate distance vector information can
   only be validated by initiating confirmation exchanges directly
   between nodes that are not routing neighbors.

   Alternatively, an entity external to the routing protocol would be
   required to collect and audit routing information exchanges to detect
   the Byzantine attack.  In the context of the current security
   framework, any protection against Byzantine routing information
   attacks will need to be directly included within the mechanisms of
   the ROLL routing protocol.  This can be implemented where such an
   attack is considered relevant even within the physical device
   protections discussed in Section 5.1.4

5.3.  Availability Attack Countermeasures

   As alluded to before, availability requires that routing information
   exchanges and forwarding mechanisms be available when needed so as to
   guarantee a proper functioning of the network.  This may, e.g.,
   include the correct operation of routing information and neighbor
   state information exchanges, among others.  We will highlight the key
   features of the security threats along with typical countermeasures
   to prevent or at least mitigate them.  We will also note that an
   availability attack may be facilitated by an identity attack as well
   as a replay attack, as was addressed in Section 5.2.3 and
   Section 5.2.4, respectively.

5.3.1.  Countering HELLO Flood Attacks and ACK Spoofing Attacks

   HELLO Flood [Karlof2003],[I-D.suhopark-hello-wsn] and ACK Spoofing
   attacks are different but highly related forms of attacking a LLN.
   They essentially lead nodes to believe that suitable routes are
   available even though they are not and hence constitute a serious
   availability attack.

   The origin of facilitating a HELLO flood attack lies in the fact that
   many wireless routing protocols 
JP> Please do not use the terms "wireless routing protocols" =
since by 
definition of a layered architecture, the routing protocol is =
not tied to 
a particular link layer. Furthermore this also applies to =
routing protocols
used in non wireless environments.
require nodes =
to send HELLO packets
   either upon joining or in regular intervals so as to announce or
   confirm their existence to the network.  Those nodes that receive the
   HELLO packet assume 
JP> If they receive the packet they *are* in the radio range =
(again the link
may not be wireless).
that they are within radio range of =
the
   transmitter by means of a bidirectional communication link.

   With this in mind, a malicious node can send or replay HELLO packets



Tsao, et al.             Expires October 1, 2010               [Page 24]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   using a higher transmission power.  That creates the false illusion
   of being a neighbor to an increased number of nodes in the network,
   thereby effectively increasing its unidirectional neighborhood
   cardinality.  The high quality of the falsely advertised link may
   coerce nodes to route data via the malicious node.  However, those
   affected nodes, for which the malicious node is out of radio range,
   never succeed in their delivery and the packets are effectively
   dropped.  
JP> Mention "if the link layer is wireless". Not that in PLC, =
this can happen too.
The symptoms are hence similar to those of a =
sinkhole,
   wormhole and selective forwarding attack.

   A malicious HELLO flood attack clearly distorts the network topology.
   It thus affects protocols building and maintaining the network
   topology as well as routing protocols as such, since the attack is
   primarily targeted on protocols that require sharing of information
   for topology maintenance or flow control.

   To counter HELLO flood attacks, several mutually non-exclusive
   methods are feasible:

   o  restricting neighborhood cardinality;

   o  facilitating multipath routing;

   o  verifying bidirectionality.

   Restricting the neighborhood cardinality prevents malicious nodes
   from having an extended set of neighbors beyond some tolerated
   threshold and thereby preventing topologies to be built where
   malicious nodes have an extended neighborhood set.  
JP> But thai may artificially =
reduce the number of "valid" neighbors too.
Furthermore, as
   shown in [I-D.suhopark-hello-wsn], if the routing protocol supports
   multiple paths from a sensing node towards several gateways then
   HELLO flood attacks can also be diminished; however, the energy-
   efficiency of such approach is clearly sub-optimal.  Finally,
   verifying that the link is truly bidirectional by means of, e.g., an
   ACK handshake and appropriate security measures ensures that a
   communication link is only established if not only the affected node
   is within range of the malicious node but also vice versa.  Whilst
   this does not really eliminate the problem of HELLO flooding, it
   greatly reduces the number of affected nodes and the probability of
   such an attack succeeding.
JP> Even if there is bi-directinality, the attacked node may =
thus send traffic
to the attackers that claims to have "good" routes =
though.
   As for the latter, the adversary may spoof the ACK =
messages to
   convince the affected node that the link is truly bidirectional and
   thereupon drop, tunnel or selectively forward messages.  Such ACK
   spoofing attack is possible if the malicious node has a receiver
   which is significantly more sensitive than that of a normal node,
   thereby effectively extending its range.  Since an ACK spoofing
   attack facilitates a HELLO flood attack, similar countermeasure are



Tsao, et al.             Expires October 1, 2010               [Page 25]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   applicable here.  Viable counter and security measures for both
   attacks have been exposed in [I-D.suhopark-hello-wsn].

5.3.2.  Countering Overload Attacks

   Overload attacks are a form of DoS attack in that a malicious node
   overloads the network with irrelevant traffic, thereby draining the
   nodes' energy budget quicker.  
JP> Energy indeed (a real issue if node are battery operated =
or using 
energy scavengers) but also inject loads and creates =
congestions.
It thus significantly shortens the
   network lifetime 
JP> If the LLNs is made of battery-operated =
nodes.
and hence constitutes another serious availability
   attack.

   With energy being one of the most precious assets of LLNs, targeting
   its availability is a fairly obvious attack.  Another way of
   depleting the energy of a LLN node is to have the malicious node
   overload the network with irrelevant traffic.  This impacts
   availability since certain routes get congested which

   o  renders them useless for affected nodes and data can hence not be
      delivered;

   o  makes routes longer as shortest path algorithms work with the
      congested network;
JP> Not sure what you meant above
   o  depletes =
nodes quicker and thus shortens the network's
      availability at large.
JP> Again if nodes are battery operated.

   Overload attacks can be countered by deploying a series of mutually
   non-exclusive security measures:

   o  introduce quotas on the traffic rate each node is allowed to =
send;
JP> Also referred to =
as "traffic shaping" but only possible in some =
networks.
   o  isolate nodes which send traffic above a certain =
threshold;
JP> If =
"Valid" nodes that may attract lots of traffic do no exist in the =
network.
   o  allow only trusted data to be received and forwarded.

   As for the first one, a simple approach to minimize the harmful
   impact of an overload attack is to introduce traffic quotas.  This
   prevents a malicious node from injecting a large amount of traffic
   into the network, even though it does not prevent said node from
   injecting irrelevant traffic at all.  Another method is to =
isolate
JP> If you have a =
wireless link, how do you "isolate" the node ? It =
can 
still sends =
traffic (at least with some MACs).
   nodes from the network once it =
has been detected that more traffic is
   injected into the network than allowed by a prior set or dynamically
   adjusted threshold.  Finally, if communication is sufficiently
   secured, only trusted nodes can receive and forward traffic which
   also lowers the risk of an overload attack.






Tsao, et al.             Expires October 1, 2010               [Page 26]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


5.3.3.  Countering Selective Forwarding Attacks

   Selective forwarding attacks are another form of DoS attack which
   impacts the routing path availability.

   An insider malicious node basically blends neatly in with the network
   but then may decide to forward and/or manipulate certain packets.  If
   all packets are dropped, then this attacker is also often referred to
   as a "black hole".  Such a form of attack is particularly dangerous
   if coupled with sinkhole attacks since inherently a large amount of
   traffic is attracted to the malicious node and thereby causing
   significant damage.  An outside malicious node would selectively jam
   overheard data flows, where the thus caused =
collisions 
JP> Again =
is the MAC is a shared media.
incur
   selective forwarding.

   Selective Forwarding attacks can be countered by deploying a series
   of mutually non-exclusive security measures:

   o  multipath routing of the same message over disjoint paths;

   o  dynamically select the next hop from a set of candidates.

   The first measure basically guarantees that if a message gets lost on
   a particular routing path due to a malicious selective forwarding
   attack, there will be another route which successfully delivers the
   data.  Such method is inherently suboptimal from an energy
   consumption point of view.  The second method basically involves a
   constantly changing routing topology in that next-hop routers are
   chosen from a dynamic set in the hope that the number of malicious
   nodes in this set is negligible.
JP> If the routing protocol allows for disjoint routing =
paths, this is even more
attractive.
5.3.4.  Countering Sinkhole Attacks

   In sinkhole attacks, the malicious node manages to attract a lot of
   traffic mainly by advertising the availability of high-quality links
   even though there are none.  It hence constitutes a serious attack on
   availability.

   The malicious node creates a sinkhole by attracting a large amount
   of, if not all, traffic from surrounding neighbors by advertising in
   and outwards links of superior quality.  Affected nodes hence eagerly
   route their traffic via the malicious node which, if coupled with
   other attacks such as selective forwarding, may lead to serious
   availability and security breaches.  Such an attack can only be
   executed by an inside malicious node and is generally very difficult
   to detect.  An ongoing attack has a profound impact on the network
   topology and essentially becomes a problem of flow control.




Tsao, et al.             Expires October 1, 2010               [Page 27]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   Sinkhole attacks can be countered by deploying a series of mutually
   non-exclusive security measures:

   o  use geographical insights for flow control;

   o  isolate nodes which receive traffic above a certain threshold;

   o  dynamically pick up next hop from set of candidates;

   o  allow only trusted data to be received and forwarded.

   Whilst most of these countermeasures have been discussed before, the
   use of geographical information deserves further attention.
   Essentially, if geographic positions of nodes are available, then the
   network can assure that data is actually routed towards the sink(s)
   and not elsewhere.  
JP> Yes but it may be wise to route all traffic via a node =
that is not closer to 
the sink but supports interesting capabilities such as =
aggregation.
On the other hand, geographic position is a
   sensitive information that may have security and/or privacy
   consequences.

5.3.5.  Countering Wormhole Attacks

   In wormhole attacks at least two malicious nodes shortcut or divert
   the usual routing path by means of a low-latency out-of-band channel.
   This changes the availability of certain routing paths and hence
   constitutes a serious security breach.

   Essentially, two malicious insider nodes use another, more powerful,
   radio 
JP> Once =
again, if the link in use is wireless.
to communicate =
with each other and thereby distort the would-
   be-agreed routing path.  This distortion could involve shortcutting
   and hence paralyzing a large part of the network; it could also
   involve tunneling the information to another region of the network
   where there are, e.g., more malicious nodes available to aid the
   intrusion or where messages are replayed, etc.  In conjunction with
   selective forwarding, wormhole attacks can create race conditions
   which impact topology maintenance, routing protocols as well as any
   security suits built on "time of check" and "time of use".

   Wormhole attacks are very difficult to detect in general but can be
   mitigated using similar strategies as already outlined above in the
   context of sinkhole attacks.


6.  ROLL Security Features

   The assessments and analysis in Section 4 examined all areas of
   threats and attacks that could impact routing, and the
   countermeasures presented in Section 5 were reached without confining
   the consideration to means only available to routing.  This section



Tsao, et al.             Expires October 1, 2010               [Page 28]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   puts the results into perspective and provides a framework for
   addressing the derived set of security objectives that must be met by
   the ROLL protocol.  
JP> s/ROLL protocol/Routing protocol specified by the ROLL =
Working Group.
It bears emphasizing that the target here is a
   generic ROLL protocol and the normative keywords are mainly to convey
   the relative level of urgency of the features specified.

   The first part of this section, Section 6.1 to Section 6.3, is a
   prescription of ROLL security features of measures that can be
   addressed as part of the routing protocol itself.  As routing is one
   component of a LLN system, the actual strength of the security
   services afforded to it should be made to conform to each system's
   security policy; how a design may address the needs of the urban,
   industrial, home automation, and building automation application
   domains also needs to be considered.  The second part of this
   section, Section 6.4 and Section 6.5, discusses system security
   aspects that may impact routing but that also require considerations
   beyond the routing protocol, as well as potential approaches.

6.1.  Confidentiality Features

   With regard to confidentiality, protecting the routing/topology
   information from eavesdropping or unauthorized exposure is not
   directly essential to maintaining the routing function.  Breaches of
   confidentiality may lead to other attacks or the focusing of an
   attacker's resources (see Section 4.1) but does not of itself
   directly undermine the operation of the routing function.  However,
   to protect against, and improve vulnerability against other more
   direct attacks, routing information confidentiality should be
   protected.  Thus, a secured ROLL protocol

   o  SHOULD provide payload encryption;

   o  MAY provide tunneling;

   o  MAY provide load balancing;
JP> You can add a note and point to the requirement RFCs, =
where this is 
listed as a requirement.
   o  SHOULD provide privacy, e.g., =
when geographic information is used.

   Where confidentiality is incorporated into the routing exchanges,
   encryption algorithms and key lengths need to be specified in
   accordance of the level of protection dictated by the routing
   protocol and the associated application domain transport network.  In
   terms of the life time of the keys, the opportunity to periodically
   change the encryption key increases the offered level of security for
   any given implementation.  However, where strong cryptography is
   employed, physical, procedural, and logical data access protection
   considerations may have more significant impact on cryptoperiod
   selection than algorithm and key size factors.  Nevertheless, in



Tsao, et al.             Expires October 1, 2010               [Page 29]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   general, shorter cryptoperiods, during which a single key is applied,
   will enhance security.

   Given the mandatory protocol requirement to implement routing node
   authentication as part of routing integrity (see Section 6.2), key
   exchanges may be coordinated as part of the integrity verification
   process.  This provides an opportunity to increase the frequency of
   key exchange and shorten the cryptoperiod as a compliment to the key
   length and encryption algorithm required for a given application
   domain.  For LLNs, the coordination of confidentiality key management
   with the implementation of node device authentication can thus reduce
   the overhead associated with supporting data confidentiality.  A new
   ciphering key may therefore be concurrently generated or updated in
   conjunction with the mandatory authentication exchange occurring with
   each routing peer association.

6.2.  Integrity Features

   The integrity of routing information provides the basis for ensuring
   that the function of the routing protocol is achieved and maintained.
   To protect integrity, a secured ROLL protocol

   o  MUST verify message integrity;

   o  MUST verify the authenticity and liveliness of both principals of
      a connection;

   o  MUST verify message sequence.

   Depending on the nature of the routing protocol, e.g., distance
   vector or link state, additional measures may be necessary when the
   validity of the routing information is of concern.  Specifically,
   verification of routing peer authenticity and liveliness can be used
   to build a "chain of trust" along the path the routing information
   flows, such that network-wide information is validated through the
   concatenation of trust established at each individual routing peer
   exchange.  This is particularly important in the case of distance
   vector-based routing protocols, where information is updated at
   intermediate nodes, In such cases, there are no direct means within
   routing for a receiver to verify the validity of the routing
   information beyond the current exchange; as such, nodes would need to
   be able to communicate and request information from non-adjacent
   peers (see [Wan2004]) to provide information integrity assurances.
   With link state-based protocols, on the other hand, routing
   information can be signed at the source thus providing a means for
   validating information that originates beyond a routing peer.
   Therefore, where necessary, a secured ROLL protocol
JP> You can remove the "o" below =
since there is no other ones.




Tsao, et al.             Expires October 1, 2010               [Page 30]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   o  MAY use security auditing mechanisms that are external to routing
      to verify the validity of the routing information content
      exchanged among routing peers.

6.3.  Availability Features

   Availability of routing information is linked to system and network
   availability which in the case of LLNs require a broader security
   view beyond the requirements of the routing entities (see
   Section 6.5).  Where availability of the network is compromised,
   routing information availability will be accordingly affected.
   However, to specifically assist in protecting routing availability

   o  MAY restrict neighborhood cardinality;

   o  MAY use multiple paths;

   o  MAY use multiple destinations;

   o  MAY choose randomly if multiple paths are available;

   o  MAY set quotas to limit transmit or receive volume;

   o  MAY use geographic insights for flow control.

6.4.  Additional Related Features

   If a LLN employs multicast and/or anycast, it MUST secure these
   protocols 
JP> "protocols" ?
with the services listed in this =
sections.  Furthermore,
   the nodes MUST provide adequate physical tamper resistance to ensure
   the integrity of stored routing information.

   The functioning of the security services requires keys and
   credentials.  Therefore, even though not directly a ROLL security
   requirement, a LLN must include a process for key and credential
   distribution; a LLN is encouraged to have procedures for their
   revocation and replacement.

6.5.  Consideration on Matching Application Domain Needs

   As routing is one component of a LLN system, the actual strength of
   the security services afforded to it should be made to conform to
   each system's security policy; how a design may address the needs of
   the urban, industrial, home automation, and building automation
   application domains is considered as part of the security
   architecture in Section 6.5.1.

   The development so far takes into account collectively the impacts of



Tsao, et al.             Expires October 1, 2010               [Page 31]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   the issues gathered from [RFC5548], [RFC5673],
   [I-D.ietf-roll-home-routing-reqs], and
   [I-D.ietf-roll-building-routing-reqs].  
JP> Update the reference (all RFcs =
now).
The following two subsections
   first consider from an architectural perspective how the security
   design of a ROLL protocol may be made to adapt to the four
   application domains, and then examine mechanism and protocol
   operations issues.

6.5.1.  Security Architecture

   The first challenge for a ROLL protocol security design is to have an
   architecture that can adequately address a set of very diversified
   needs.  It is mainly a consequence of the fact that there are both
   common and non-overlapping requirements from the four application
   domains, while, conceivably, each individual application will present
   yet its own unique constraints.

   For a ROLL protocol, the security requirements defined in Section 6.1
   to Section 6.4 can be addressed at two levels: 1) through measures
   implemented directly within the routing protocol itself and initiated
   and controlled by the routing protocol entities; or 2) through
   measures invoked on behalf of the routing protocol entities but
   implemented within the transport network 
JP> Be accurate when you used =
"transport network": you mean "link layer" ?
over which the =
protocol
   exchanges occur.

   Where security is directly implemented as part of the routing
   protocol the security requirements configured by the user (system
   administrator) will operate independent of the underlying transport
   network
.  OSPFv2 =
[RFC2328] is an example of such an approach in which
   security parameters are exchanged and assessed within the routing
   protocol messages.  In this case, the mechanism may be, e.g., a
   header containing security material of configurable security
   primitives in the fashion of OSPFv2 or RIPv2 [RFC2453].  Where IPsec
   [RFC4301] is employed to secure the network, the included protocol-
   specific (OSPF or RIP) security elements are in addition to and
   independent of those at the network layer.  In the case of LLNs or
   other networks where system security mandates protective mechanisms
   at other lower layers of the transport network, 
JP> "lower layers of the transport =
network" is ambiguous.
security measures
   implemented as part of the routing protocol will be redundant to
   security measures implemented elsewhere as part of the transport
   network.
JP> Please =
replace "transport network" with appropriate terminology where =
needed.
   Security mechanisms built into the routing protocol can =
ensure that
   all desired countermeasures can be directly addressed by the protocol
   all the way to the endpoint of the routing exchange.  In particular,
   routing protocol Byzantine attacks by a compromised node that retains
   valid network security credentials can only be detected at the level
   of the information exchanged within the routing protocol.  Such



Tsao, et al.             Expires October 1, 2010               [Page 32]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   attacks aimed the manipulation of the routing information can only be
   fully addressed through measures operating directly between the
   routing entities themselves or external entities able to access and
   analyze the routing information (see discussion in Section 5.2.5).

   On the other hand, it is more desirable from a LLN device perspective
   that the ROLL protocol is integrated into the framework of an overall
   system architecture where the security facility may be shared by
   different applications and/or across layers for efficiency, and where
   security policy and configurations can be consistently specified.
   See, for example, considerations made in RIPng [RFC2080] or the
   approach presented in [Messerges2003].

   Where the routing protocol is able to rely on security measures
   configured with the transport network
JP> Same comment. What do you mean =
by "transport network"?
, greater system efficiency can
   be realized by avoiding potentially redundant security.  Relying on
   an open trust model [Messerges2003], the security requirements of the
   routing protocol can be more flexibly met at different layers of the
   transport network; measures that must be applied to protect the
   communications network are concurrently able to provide the needed
   routing protocol protection.

   In addition, in the context of the different application domains, it
   allows the level of security applied for routing to be consistent
   with that needed for protecting the network itself.  For example,
   where AES-128
JP> Expand terms when first used + add =
reference
 is deemed the appropriate standard for network
   confidentiality of data exchanges at the link layer, that level of
   security is automatically afforded to routing protocol exchanges.
   Similarly, where SHA-1 
JP> Same =
comment
is stipulated as the standard required for
   authenticating routing protocol peers, the use of SHA-1 at the
   network layer between communicating routing devices automatically
   meets the routing protocol security requirement within the context of
   open trust across layers within the device.

   A ROLL protocol MUST be made flexible by a design that offers the
   configuration facility so that the user (network administrator) can
   choose the security settings that match the application's needs.
   Furthermore, in the case of LLNs that flexibility should extend to
   allowing the routing protocol security requirements to be met by
   measures applied at different protocol layers, provided the
   identified requirements are collectively met.

   Since Byzantine attacks that can affect the validity of the
   information content exchanged between routing entities can only be
   directly countered at the routing protocol level, the ROLL protocol
   may support mechanisms for verifying routing data validity that
   extends beyond the chain of trust created through device
   authentication.  This protocol-specific security mechanism should be



Tsao, et al.             Expires October 1, 2010               [Page 33]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   made optional within the protocol allowing it to be invoked according
   to the given routing protocol and application domain and as selected
   by the system user.  All other ROLL security mechanisms needed to
   meet the above identified routing security requirements should be
   flexibly implemented within the transport network (at the IP network
   layer or higher or lower protocol layers(s)) according to the
   particular application domain and user network configuration.

   Based on device capabilities and the spectrum of operating
   environments it would be difficult for a single fixed security design
   to be applied to address the diversified needs of the four ROLL
   application domains 
JP> Please list them again (urban, =
industrial, home/building) + indicate that this is also
true for other application =
domains.
without forcing a very low common denominator =
set
   of requirements.  On the other hand, providing four individual domain
   designs that attempt to a priori match each individual domain is also
   very likely to provide a suitable answer given the degree of network
   variability even within a given domain.  
JP> The type of link =
layers in use within each domain also influences the overall =
security.
Instead, the framework
   implementation approach recommended for optional, routing protocol-
   specific measures together with flexible transport network mechanisms
   can be the most effective.  This approach allows countermeasures
   against internal attacks to be applied in environments where
   applicable threats exist.  At the same time, it allows routing
   protocol security to be configured through measures implemented
   within the transport network that is commensurate and consistent with
   the level and strength applied in the particular application domain
   networks.

6.5.2.  Mechanisms and Operations

   With an architecture allowing different configurations to meet the
   application domain needs, the task is then to find suitable
   mechanisms.  For example, one of the main problems of synchronizing
   security states of sleepy nodes, as listed in the last subsection,
   lies in difficulties in authentication; these nodes may not have
   received in time the most recent update of security material.
   Similarly, the issues of minimal manual configuration, prolonged
   rollout and delayed addition of nodes, and network topology changes
   also complicate security management.  In such case the ROLL protocol
   may need to bootstrap the authentication process and allow for
   flexible expiration scheme of authentication credentials.  This
   exemplifies the need for the coordination and interoperation between
   the requirements of the ROLL routing protocol and that of the system
   security elements.

   Similarly, the vulnerability brought forth by some special-function
   nodes, e.g., gateways/sinks requires the assurance, particularly, of
   the availability of communication channels and node resources, or
   that the neighbor discovery process operates without undermining
   routing availability.



Tsao, et al.             Expires October 1, 2010               [Page 34]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   There and other factors which are not part of a ROLL routing protocol
   can still affect its operation.  This includes elements such as
   weaker barrier to accessing the data or security material stored on
   the nodes through physical means; therefore, the internal and
   external interfaces of a node need to be adequate for guarding the
   integrity, and possibly the confidentiality, of stored information,
   as well as the integrity of routing and route generation processes.

   Figure 2 provides an overview of the larger context of system
   security and the relationship between ROLL requirements and measures
   and those that relate to the LLN system.








































Tsao, et al.             Expires October 1, 2010               [Page 35]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


                           Security Services for
                             ROLL-Addressable
                           Security Requirements
                                |        |
                            +---+        +---+
                Node_i      |                |      Node_j
                       _____v___          ___v_____
     Specify Security /         \        /         \ Specify Security
     Requirements     | Routing |        | Routing |     Requirements
            +---------| Protocol|        | Protocol|---------+
            |         | Entity  |        | Entity  |         |
            |         \_________/        \_________/         |
            |               |                |               |
            |ROLL-Specified |                | ROLL-Specified|
           ---Interface     |                |     Interface---
            |     ......................................     |
            |     :         |                |         :     |
            |     :   +-----+----+      +----+-----+   :     |
            |     :   |Transport/|      |Transport/|   :     |
        ____v___  : +>|Network   |      |Network   |<+ :  ___v____
       /        \ : | +-----+----+      +----+-----+ | : /        \
       |        |-:-+       |                |       +-:-|        |
       |Security| :   +-----+----+      +----+-----+   : |Security|
    +->|Services|-:-->|   Link   |      |   Link   =
|<--:-|Services|<-+
    |  |Entity  | :   +-----+----+      +----+-----+   : |Entity  |  |
    |  |        |-:-+       |                |       +-:-|        |  |
    |  \________/ : | +-----+----+      +----+-----+ | : \________/  |
    |             : +>| Physical |      | Physical |<+ :           =
  |
   Application    :   +-----+----+      +----+-----+   :    Application
   Domain User    :         |                |         :    Domain User
   Configuration  :         |__Comm. Channel_|         :  Configuration
                  :                                    :
                  ...Transport Network..................


                    Figure 2: LLN Device Security Model

JP> Great =
figure. Just clarify =
"transport/network"



7.  Application of ROLL Security Framework to RPL
JP> Expand acronym =
when first used (RPL)


   This section applies the assessments given in Section 6 to =
RPL
JP> Ad =
reference (draft-ietf-roll-rpl)
 as an
   illustration of the application of the LLN security framework.

   Specializing the approach used in Section 3.1, Figure 3 gives a
   level-1 data flow diagram representation of RPL to show the routing
   "assets" and "points of access" that may be vulnerable and need to be
   protected.




Tsao, et al.             Expires October 1, 2010               [Page 36]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


                    ............................................
                    :                                          :
      |Link-Local   :                                          :
       Multicast    :                                          :
       or Node_i|<----->(DIO/DIS/DAO)<--------------+          =
:
                    :          ^                    |          :
                    :          |              ______V______    :
                    :          |              Candidate        :
                    :          V              Neighbor List    :
                    : (RPL Control incl.      ------+------    :
                    :  Trickle Timer,               |          :
                    :  Loop Avoidance)              V          :
                    :          ^            (Route Generation) :
                    :          |                    |          :
                    :          |              ______V______    :
                    :          +------+       Routing Table    :
                    :                 |       ------+------    :
                    :                 |             |          :
                    : RPL on Node_j   |             |          :
                    ..................|.............|...........
                                      |             |
      |Forwarding                     V             |
       To/=46rom Node_k|<-------->(Read/Write         |
                                 Flow Label)<-------+


                    Figure 3: Data Flow Diagram of RPL

   =46rom Figure 3, it is seen that threats to the proper operation of =
RPL
   are realized through attacks on its DIO, DIS, and DAO messages, as
   well as on the information the protocol places on the IPv6 Flow
   Labels. 
JP> Please update since information is now carried in the =
Hop-by-hop header 
with the RPL option (draft in =
6man).
 As set forth in Section 6.1 to Section 6.4, =
the base
   security requirements concern message integrity, authenticity and
   liveliness of the principals of a connection, and protection against
   message replay; message encryption may be desirable.  The security
   objectives for RPL are therefore to ensure that

   1.  participants of the DIO, DIS, and DAO message exchanges are
       authentic;

   2.  the received DIO, DIS, and DAO messages are not modified during
       transportation;

   3.  the received DIO, DIS, and DAO messages are not retransmissions
       of previous messages;

   4.  the content of the DIO, DIS, and DAO messages may be made legible
       to only authorized entities.



Tsao, et al.             Expires October 1, 2010               [Page 37]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   In meeting the above objectives, RPL also needs to provide tunable
   mechanisms both to allow matching the security afforded to the
   application domain requirements and to enable efficient use of system
   resources, as discussed in Section 6.5.1 and Section 6.5.2.

   The functions of the different RPL messages and information placed
   within the user data plane Flow Labels 
JP> s/"user data =
plane"/"user data plane (RPL option TLV carried in the IPv6 Hop-by-hop =
header)
are factors that can be taken
   into account when deciding the optional security features and levels
   of strength to be afforded.  For example, the DIO messages build
   routes to roots while the DAO messages support the building of
   downward routes to leaf nodes.  Consequently, there may be
   application environments in which the directions of the routes have
   different importance and thus warrant the use of different security
   features and/or strength.  In other words, it may be desirable to
   have an RPL security design that extends the tunability of the
   security features and strengths to message types.  The use of a per-
   message security specification will allow flexibility in permitting
   application-domain security choices as well as overall tunability.


8.  IANA Considerations

   This memo includes no request to IANA.


9.  Security Considerations

   The framework presented in this document provides security analysis
   and design guidelines with a scope limited to ROLL.  Security
   services are identified as requirements for securing ROLL.  The
   results are applied to RPL, with consequent recommendations.


10.  Acknowledgments

   The authors would like to acknowledge the review and comments from
   Rene Struik.


11.  References

11.1.  Normative References

   [RFC2080]  Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
              January 1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.



Tsao, et al.             Expires October 1, 2010               [Page 38]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC2453]  Malkin, G., "RIP Version 2", STD 56, RFC 2453,
              November 1998.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

11.2.  Informative References

   [Huang2003]
              Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J.
              Zhang, "Fast Authenticated Key Establishment Protocols for
              Self-Organizing Sensor Networks", in Proceedings of the
              2nd ACM International Conference on Wireless Sensor
              Networks and Applications, San Diego, CA, USA, pp. 141-
              150, Sept. 19 2003.

   [I-D.ietf-roll-building-routing-reqs]
              Martocci, J., Riou, N., Mil, P., and W. Vermeylen,
              "Building Automation Routing Requirements in Low Power and
              Lossy Networks", draft-ietf-roll-building-routing-reqs-09
              (work in progress), January 2010.

   [I-D.ietf-roll-home-routing-reqs]
              Brandt, A. and J. Buron, "Home Automation Routing
              Requirements in Low Power and Lossy Networks",
              draft-ietf-roll-home-routing-reqs-11 (work in progress),
              January 2010.

JP> Update =
the two references above.
   =
[I-D.ietf-roll-rpl]
              Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing
              Protocol for Low power and Lossy Networks",
              draft-ietf-roll-rpl-07 (work in progress), March 2010.

   [I-D.ietf-roll-terminology]
              Vasseur, J., "Terminology in Low power And Lossy
              Networks", draft-ietf-roll-terminology-03 (work in
              progress), March 2010.

   [I-D.suhopark-hello-wsn]
              Park, S., "Routing Security in Sensor Network: HELLO Flood
              Attack and Defense", draft-suhopark-hello-wsn-00 (work in
              progress), December 2005.

   [Karlof2003]
              Karlof, C. and D. Wagner, "Secure routing in wireless
              sensor networks: attacks and countermeasures", Elsevier



Tsao, et al.             Expires October 1, 2010               [Page 39]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


              AdHoc Networks Journal, Special Issue on Sensor Network
              Applications and Protocols, 1(2):293-315, September 2003.

   [Messerges2003]
              Messerges, T., Cukier, J., Kevenaar, T., Puhl, L., Struik,
              R., and E. Callaway, "Low-Power Security for Wireless
              Sensor Networks", in Proceedings of the 1st ACM Workshop
              on Security of Ad Hoc and Sensor Networks, Fairfax, VA,
              USA, pp. 1-11, Oct. 31 2003.

   [Myagmar2005]
              Myagmar, S., Lee, AJ., and W. Yurcik, "Threat Modeling as
              a Basis for Security Requirements", in Proceedings of the
              Symposium on Requirements Engineering for Information
              Security (SREIS'05), Paris, France, pp. 94-102, Aug
              29, 2005.

   [RFC4593]  Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
              Routing Protocols", RFC 4593, October 2006.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              RFC 4949, August 2007.

   [RFC5548]  Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
              "Routing Requirements for Urban Low-Power and Lossy
              Networks", RFC 5548, May 2009.

   [RFC5673]  Pister, K., Thubert, P., Dwars, S., and T. Phinney,
              "Industrial Routing Requirements in Low-Power and Lossy
              Networks", RFC 5673, October 2009.

   [Wan2004]  Wan, T., Kranakis, E., and PC. van Oorschot, "S-RIP: A
              Secure Distance Vector Routing Protocol", in Proceedings
              of the 2nd International Conference on Applied
              Cryptography and Network Security, Yellow Mountain, China,
              pp. 103-119, Jun. 8-11 2004.


Authors' Addresses

   Tzeta Tsao (editor)
   Eka Systems
   20201 Century Blvd. Suite 250
   Germantown, Maryland  20874
   USA

   Email: tzeta.tsao@ekasystems.com




Tsao, et al.             Expires October 1, 2010               [Page 40]
=0C
Internet-Draft         Security Framework for ROLL            March 2010


   Roger K. Alexander (editor)
   Eka Systems
   20201 Century Blvd. Suite 250
   Germantown, Maryland  20874
   USA

   Email: roger.alexander@ekasystems.=
com


   Mischa Dohler (editor)
   CTTC
   Parc Mediterrani de la Tecnologia, Av. Canal Olimpic S/N
   Castelldefels, Barcelona  08860
   Spain

   Email: mischa.dohler@cttc.es


   Vanesa Daza (editor)
   Universitat Pompeu Fabra
   P/ Circumval.lacio 8, Oficina 308
   Barcelona  08003
   Spain

   Email: vanesa.daza@upf.edu


   Angel Lozano (editor)
   Universitat Pompeu Fabra
   P/ Circumval.lacio 8, Oficina 309
   Barcelona  08003
   Spain

   Email: angel.lozano@upf.edu

JP> Are you all =
editors ? if so, remove the term "Editors"


















Tsao, et al.             Expires October 1, 2010               [Page 41]
=0C
= --Apple-Mail-2-456749292-- From trac@tools.ietf.org Sun Sep 5 10:47:25 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319403A681E for ; Sun, 5 Sep 2010 10:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.425 X-Spam-Level: X-Spam-Status: No, score=-101.425 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, MANGLED_WANT=2.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkvmcYkShVuF for ; Sun, 5 Sep 2010 10:47:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9D4213A67E1 for ; Sun, 5 Sep 2010 10:47:04 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OsJJT-0003Lr-Te; Sun, 05 Sep 2010 10:47:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: roger.alexander@ekasystems.com, jpv@cisco.com X-Trac-Project: roll Date: Sun, 05 Sep 2010 17:47:31 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/roll/trac/ticket/77 Message-ID: <055.670184ba815b637b18e2d9ec4c4599d6@tools.ietf.org> X-Trac-Ticket-ID: 77 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: roger.alexander@ekasystems.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #77: Comments during Security FW Last Call X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@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: Sun, 05 Sep 2010 17:47:26 -0000 #77: Comments during Security FW Last Call --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: tzeta.tsao@… Type: defect | Status: new Priority: major | Milestone: Component: security-framework | Version: Severity: In WG Last Call | Keywords: --------------------------------+------------------------------------------- Hi, Please find below some detailed comments - Overall well-written document. In addition to the comments in-line (search for JP>), I would welcome a few diagrams especially when you describe the different types of attacks. Furthermore, as you will see in the comments, be careful not to make the assumption of wireles links (there are many LLNs with wireless links of course) but this is not the only type of links. Same comment for the node type (they are not all battery operated). Thanks ! I will open a ticket capturing all of the comments below. JP> Starting with ID nits: Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-roll-building-routing-reqs has been published as RFC 5867 == Outdated reference: draft-ietf-roll-home-routing-reqs has been published as RFC 5826 == Outdated reference: A later version (-11) exists of draft-ietf-roll-rpl-07 Networking Working Group T. Tsao, Ed. Internet-Draft R. Alexander, Ed. Intended status: Informational Eka Systems Expires: October 1, 2010 M. Dohler, Ed. CTTC V. Daza, Ed. A. Lozano, Ed. Universitat Pompeu Fabra March 30, 2010 A Security Framework for Routing over Low Power and Lossy Networks draft-ietf-roll-security-framework-00 Abstract This document presents a security framework for routing over low power and lossy networks. JP> Add acronym (LLN) The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and evaluating the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. As an illustration, this framework is applied to RPL. JP> Expand acronym when first used (LLN here). Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Tsao, et al. Expires October 1, 2010 [Page 1] Internet-Draft Security Framework for ROLL March 2010 The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 1, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Tsao, et al. Expires October 1, 2010 [Page 2] Internet-Draft Security Framework for ROLL March 2010 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Considerations on ROLL Security . . . . . . . . . . . . . . . 5 3.1. Routing Assets and Points of Access . . . . . . . . . . . 6 3.2. The CIA Security Reference Model . . . . . . . . . . . . . 8 3.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 9 3.4. ROLL Security Objectives . . . . . . . . . . . . . . . . . 11 4. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 12 4.1. Threats and Attacks on Confidentiality . . . . . . . . . . 12 4.1.1. Routing Exchange Exposure . . . . . . . . . . . . . . 12 4.1.2. Routing Information (Routes and Network Topology) Exposure . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Threats and Attacks on Integrity . . . . . . . . . . . . . 13 4.2.1. Routing Information Manipulation . . . . . . . . . . . 14 4.2.2. Node Identity Misappropriation . . . . . . . . . . . . 14 4.3. Threats and Attacks on Availability . . . . . . . . . . . 15 4.3.1. Routing Exchange Interference or Disruption . . . . . 15 4.3.2. Network Traffic Forwarding Disruption . . . . . . . . 15 4.3.3. Communications Resource Disruption . . . . . . . . . . 15 4.3.4. Node Resource Exhaustion . . . . . . . . . . . . . . . 16 5. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Confidentiality Attack Countermeasures . . . . . . . . . . 17 5.1.1. Countering Deliberate Exposure Attacks . . . . . . . . 17 5.1.2. Countering Sniffing Attacks . . . . . . . . . . . . . 17 5.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 19 5.1.4. Countering Physical Device Compromise . . . . . . . . 19 5.1.5. Countering Remote Device Access Attacks . . . . . . . 21 5.2. Integrity Attack Countermeasures . . . . . . . . . . . . . 21 5.2.1. Countering Tampering Attacks . . . . . . . . . . . . . 22 5.2.2. Countering Overclaiming and Misclaiming Attacks . . . 22 5.2.3. Countering Identity (including Sybil) Attacks . . . . 22 5.2.4. Countering Routing Information Replay Attacks . . . . 23 5.2.5. Countering Byzantine Routing Information Attacks . . . 23 5.3. Availability Attack Countermeasures . . . . . . . . . . . 24 5.3.1. Countering HELLO Flood Attacks and ACK Spoofing Attacks . . . . . . . . . . . . . . . . . . . . . . . 24 5.3.2. Countering Overload Attacks . . . . . . . . . . . . . 26 5.3.3. Countering Selective Forwarding Attacks . . . . . . . 27 5.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 27 5.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 28 6. ROLL Security Features . . . . . . . . . . . . . . . . . . . . 28 6.1. Confidentiality Features . . . . . . . . . . . . . . . . . 29 6.2. Integrity Features . . . . . . . . . . . . . . . . . . . . 30 6.3. Availability Features . . . . . . . . . . . . . . . . . . 31 6.4. Additional Related Features . . . . . . . . . . . . . . . 31 6.5. Consideration on Matching Application Domain Needs . . . . 31 Tsao, et al. Expires October 1, 2010 [Page 3] Internet-Draft Security Framework for ROLL March 2010 6.5.1. Security Architecture . . . . . . . . . . . . . . . . 32 6.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 34 7. Application of ROLL Security Framework to RPL . . . . . . . . 36 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 11.1. Normative References . . . . . . . . . . . . . . . . . . . 38 11.2. Informative References . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Tsao, et al. Expires October 1, 2010 [Page 4] Internet-Draft Security Framework for ROLL March 2010 1. Terminology This document conforms to the terminology defined in [I-D.ietf-roll-terminology]. JP> There are other terms used in the document that could be added here (see below). 2. Introduction In recent times, networked wireless devices have found an increasing number of applications in various fields. Yet, for reasons ranging from operational application to economics, these wireless devices JP> This does not apply only to wireless links (e.g. PLC) are often supplied with minimum physical resources, e.g., limited power reserve, slow speed or low capability computation, or small memory size. As a consequence, the resulting networks are more prone to loss of traffic and other vulnerabilities. The proliferation of these low power and lossy networks (LLNs), however, are drawing efforts to examine and address their potential networking challenges. This document presents a framework for securing routing over low power and lossy networks (ROLL) JP> s/ROLL/LLN through an analysis that starts from the routing basics. The objective is two-fold. First, the framework will be used to identify pertinent security issues. Second, it will facilitate both the assessment of a protocol's security threats and the identification of the necessary features for development of secure protocols for ROLL. JP> s/ROLL/The ROLL Working Group. The approach adopted in this effort proceeds in four steps, to examine ROLL security issues, to analyze threats and attacks, to consider the countermeasures, and then to make recommendations for securing ROLL. JP> Could you just replace "ROLL" by the "the routing protocol developed by the ROLL Working Group" or Define ROLL as Routing Over Low power and Lossy networks. The basis is found on identifying the assets and points of access of routing and evaluating their security needs based on the Confidentiality, Integrity, and Availability (CIA) model in the context of LLN. The utility of this framework is demonstrated with an application to RPL [I-D.ietf-roll-rpl]. 3. Considerations on ROLL Security This section sets the stage for the development of the framework by applying the systematic approach proposed in [Myagmar2005] to the routing security problem, while also drawing references from other reviews and assessments found in the literature, particularly, [RFC4593] and [Karlof2003]. The subsequent subsections begin with a focus on the elements of a generic routing process that is used to establish routing assets and points of access of the routing functionality. Next, the CIA security model is briefly described. Then, consideration is given to issues specific to or amplified in LLNs. This section concludes with the formulation of a set of Tsao, et al. Expires October 1, 2010 [Page 5] Internet-Draft Security Framework for ROLL March 2010 security objectives for ROLL. 3.1. Routing Assets and Points of Access An asset implies important system component (including information, process, or physical resource), the access to, corruption or loss of which adversely affects the system. In network routing, assets lie in the routing information, routing process, and node's physical resources. That is, the access to, corruption, or loss of these elements adversely affects system routing. In network routing, a point of access refers to the point of entry facilitating communication with or other interaction with a system component in order to use system resources to either manipulate information or gain knowledge of the information contained within the system. Security of the routing protocol must be focused on the assets of the routing nodes and the points of access of the information exchanges and information storage that may permit routing compromise. The identification of routing assets and points of access hence provides a basis for the identification of associated threats and attacks. This subsection identifies assets and points of access of a generic routing process with a level-0 JP> Explain what you mean by "level-0" data flow diagram. The use of the data flow diagram allows for a clear, concise model of the routing functionality; it also has the benefit of showing the manner in which nodes participate in the routing process, thus providing context when later threats and attacks are considered. The goal of the model is to be as detailed as possible so that corresponding components and mechanisms in an individual routing protocol can be readily identified, but also to be as general as possible to maximize the relevancy of this effort for the various existing and future protocols. Nevertheless, there may be discrepancies, likely in the form of additional elements, when the model is applied to some protocols. For such cases, the analysis approach laid out in this document should still provide a valid and illustrative path for their security assessment. Figure 1 shows that nodes participating in the routing process transmit messages to determine their neighbors (neighbor discovery). Using the neighboring relationships, routing protocols may exchange network topology (including link-specific information) to generate routes or may exchange routes directly as part of a routing exchange; nodes which do not directly participate in the process with a given node will get the route/topology information relayed from others. JP> You can remove the previous sentence (no need to make assumption in in a framework on the mode of operation of the routing protocol). It is likely that a node will store some or all of the routes and topology information according to tradeoffs of node resources and latency associated with the particular routing protocol. JP> Why tradeoff with latency ? The nodes use the derived routes for making forwarding decisions. Tsao, et al. Expires October 1, 2010 [Page 6] Internet-Draft Security Framework for ROLL March 2010 ................................................... : : : _________________ : |Node_i|<------->(Neighbor Discovery)--->Neighbor Topology : : -------+--------- : : | : |Node_j|<------->(Route/Topology +--------+ : : Exchange) | : : | V ______ : : +---->(Route Generation)--->Routes : : ---+-- : : | : : Routing on a Node Node_k | : ................................................... | |Forwarding | On Node_l|<-------------------------------------------+ Notation: (Proc) A process Proc ________ DataBase A data storage DataBase -------- |Node_n| An external entity Node_n -------> Data flow Figure 1: Data Flow Diagram of a Generic Routing Process It is seen from Figure 1 that o Assets include * routing and/or topology information; * communication channel resources (bandwidth); * node resources (computing capacity, memory, and remaining energy); * node identifiers (including node identity and ascribed attributes such as relative or absolute node location). Tsao, et al. Expires October 1, 2010 [Page 7] Internet-Draft Security Framework for ROLL March 2010 o Points of access include * neighbor discovery; * route/topology exchange; * node physical interfaces (including access to data storage). A focus on the above list of assets and points of access enables a more directed assessment of routing security. Indeed, the intention is to be comprehensive; nonetheless, the discussions to follow on physical related issues are not related to routing protocol design but provided for reference since they do have direct consequences on the security of routing. 3.2. The CIA Security Reference Model At the conceptual level, security within an information system in general and applied to ROLL in particular is concerned with the primary issues of confidentiality, integrity, and availability. In the context of ROLL: Confidentiality Confidentiality involves the protection of routing information as well as routing neighbor maintenance exchanges so that only authorized and intended network entities may view or access it. JP> By "neighbor" just mention that we're referring to routing neighbor in the context on this document. Because of the wireless, JP> Not always wireless ! Just make sure to make it clear even if the comment below applies to wireless links. and sometimes ad hoc, nature of the network, confidentiality also extends to the neighbor state and database information within the routing device since the deployment of the network creates the potential for unauthorized access to the physical devices themselves. Integrity Integrity, as a security principle, entails the protection of routing information and routing neighbor maintenance exchanges, as well as derived information maintained in the database, from misuse or unauthorized and improper modification. In addition, integrity also requires JP> Is it really integrity that requires authenticity ? the authenticity of claimed identity in the origin and destination of a message, access and removal of data, execution of the routing process, and use of computing and energy resources. Availability Availability ensures that routing information exchanges and forwarding services need to be available when they are required for the functioning of the serving network. Availability will apply to maintaining efficient and correct operation of routing and neighbor discovery exchanges (including needed information) Tsao, et al. Expires October 1, 2010 [Page 8] Internet-Draft Security Framework for ROLL March 2010 and forwarding services so as not to impair or limit the network's central traffic flow function. It is noted that, besides those captured in the CIA model, non- repudiation is a security interest under certain circumstances. With respect to routing, non-repudiation will involve providing some ability to allow traceability or network management review of participants of the routing process including the ability to determine the events and actions leading to a particular routing state. Non-repudiation implies after the fact and thus relies on the logging or other capture of on-going routing exchanges. Given the limited resources of a node and potentially the communication channel, and considering the operating mode associated with LLNs, routing transaction logging or auditing process communication overhead will not be practical; as such, non-repudiation is not further considered as a relevant ROLL security issue. JP> May be one sentence to define "non-repudiation" would be helpful 3.3. Issues Specific to or Amplified in LLNs The work [RFC5548] and [RFC5673], as well as two other ongoing efforts, [I-D.ietf-roll-home-routing-reqs] and [I-D.ietf-roll-building-routing-reqs], JP> Update the draft-ietf references. They are all RFC (5826 and 5867 respectively). have identified ROLL JP> "ROLL specific" -> "routing requirement specific to LLNs" specific requirements and constraints for the urban, industrial, home automation, and building automation application domains, respectively. The following is a list of observations and evaluation of their impact on routing security considerations. Limited energy reserve JP> s/reserve/resources/ , memory, and processing resources JP> s/processing resources/processing nodes resources/ As a consequence of these constraints, there is an even more critical need than usual for a careful trade study on which and what level of security services are to be afforded during the system design process. In addition, the choices of security mechanisms are more stringent. Synchronization of security states with sleepy nodes is yet another issues. JP>s/issues/issue Large scale of rolled out network JP> You can mention "from a few dozens to several (hundreds) of thousands of nodes" The possibly numerous nodes to be deployed, as well as the general level of expertise of the installers, make manual on- site configuration unlikely. Prolonged rollout and delayed addition of nodes, which may be from old inventory, over the lifetime of the network, also complicate the operations of key management. Autonomous operations Self-forming and self-organizing are commonly prescribed requirements of ROLL JP> s/ROLL/LLNs . In other words, a ROLL protocol JP> A Routing protocol designed for LLNs needs to contain elements of ad hoc networking and cannot JP> (in most cases) rely on manual configuration for initialization or local filtering rules. Tsao, et al. Expires October 1, 2010 [Page 9] Internet-Draft Security Framework for ROLL March 2010 Network topology/ownership changes, partitioning or merging, as well as node replacement, can all contribute to key management issues. Highly directional traffic Some types of LLNs see a high percentage of their total traffic traverse between the nodes and the gateways JP> Use "LBR" as defined in http://datatracker.ietf.org/doc/draft-ietf- roll-terminology/ instead of gateway where the LLNs connect to wired networks. JP> s/wired networks/to non LLN network (since wired links may be present in LLNs) The special routing status of and the greater volume of traffic near the gateways/sinks JP> Same comment use only the LBR terminology throughout the document. have routing security consequences. JP> You can mention that when P2MP and MP2P traffic represents a majority of the traffic routing attacks consisting of advertising low route cost may cause serious damages. Unattended locations and limited physical security Many applications have the nodes deployed in unattended or remote locations; furthermore, the nodes themselves are often built with minimal physical protection. These constraints lower the barrier of accessing the data or security material stored on the nodes through physical means. Support for mobility On the one hand, only a number of applications require the support of mobile nodes, e.g., a home LLN that includes nodes on wearable health care devices or an industry LLN that includes nodes on cranes and vehicles. On the other hand, if a routing protocol is indeed used in such applications, it will clearly need to have corresponding security mechanisms. Support for multicast and anycast Support for multicast and anycast is called out chiefly for large-scale networks. As these are relatively new routing technologies, JP> Heu ... Multicast is not really new there has been an ongoing effort devoted to their security mechanisms, e.g., from the IETF Multicast Security working group. However, inclusion of such mechanisms in a routing protocol, and consequently their security analysis, are still areas not fully developed or their impact entirely understood, whether in a more traditional wired or wireless network, or LLN. The above list considers how a LLN's physical constraints, size, operations, and varieties of application areas may impact security. It is noted here also that LLNs commonly have the majority, if not all, of their nodes equipped to route. JP> I would suppress the previous sentence, since in this document we are only considering nodes acting as routers. One of the consequences is that the distinction between the link and network layers become artificial in some respects. Similarly, the distinction between a host and a router is blurred, especially when the set of applications running on a node is small. JP> Same thing for the previous sentence, which may be misleading. The continued evolution of ROLL and its security functionality requirements need close attention. JP> s/ROLL/routing protocol designed by the ROLL WG Tsao, et al. Expires October 1, 2010 [Page 10] Internet-Draft Security Framework for ROLL March 2010 3.4. ROLL Security Objectives This subsection applies the CIA model to the routing assets and access points, taking into account the LLN issues, to develop a set of ROLL security objectives. Since the fundament function of a routing protocol is to build routes for forwarding packets, it is essential to ensure that o routing/topology information is not tampered during transfer and in storage; o routing/topology information is not misappropriated; o routing/topology information is available when needed. In conjunction, it is necessary to be assured of o the authenticity and legitimacy of the participants of the JP> routing neighbor neighbor discovery process; o the routing/topology information received was faithfully generated according to the protocol design. However, when trust cannot be fully vested through authentication of the principals alone, i.e., concerns of insider attack, assurance of the truthfulness and timeliness of the received routing/topology information is necessary. With regard to confidentiality, protecting the routing/topology information from eavesdropping or unauthorized exposure is in itself less pertinent in general to the routing function. One of the main problems of synchronizing security states of sleepy nodes, as listed in the last subsection, lies in difficulties in authentication; these nodes may not have received in time the most recent update of security material. Similarly, the issues of minimal manual configuration, prolonged rollout and delayed addition of nodes, and network topology changes also complicate key management. Hence, ROLL JP> Change ROLL for routing in LLN needs to bootstrap the authentication process and allow for flexible expiration scheme of authentication credentials. The vulnerability brought forth by some special-function nodes, e.g., gateways/sinks JP> Change for LBR requires the assurance, particularly, o of the availability of communication channels and node resources; JP> but how to ensure and the unavailable of the channels is due to a security attack as opposed to simply being not operational? o that the neighbor discovery process operates without undermining routing availability. Tsao, et al. Expires October 1, 2010 [Page 11] Internet-Draft Security Framework for ROLL March 2010 There are other factors which are not part of a ROLL protocol but directly affecting its function. These factors include weaker barrier of accessing the data or security material stored on the nodes through physical means; therefore, the internal and external interfaces of a node need to be adequate for guarding the integrity, and possibly the confidentiality, of stored information, as well as the integrity of routing and route generation processes. Each individual system's use and environment will dictate how the above objectives are applied, including the choices of security services as well as the strengths of the mechanisms that must be implemented. The next two sections give a closer look at how the ROLL security objectives may be compromised and countered, respectively. 4. Threats and Attacks This section outlines general categories of threats under the CIA model and highlights the specific attacks in each of these categories for ROLL. As defined in [RFC4949], a threat is "a potential for violation of security, which exists when there is a circumstance, capability, action, or event that could breach security and cause harm." An attack is "an assault on system security that derives from an intelligent threat, i.e., an intelligent act that is a deliberate attempt (especially in the sense of a method or technique) to evade security services and violate the security policy of a system." The subsequent subsections consider the threats and their realizing attacks that can cause security breaches under the CIA model to the assets identified in Section 3.1. The analysis steps through the security concerns of each routing asset and looks at the attacks that can exploit points of access. The manifestation of the attacks is assumed to be from either inside or outside attackers, whose capabilities may be limited to node-equivalent or more sophisticated computing platforms. 4.1. Threats and Attacks on Confidentiality The assessment in Section 3.2 indicates that information assets are exposed to confidentiality threats from all points of access. 4.1.1. Routing Exchange Exposure Routing exchanges include both routing information as well as information associated with the establishment and maintenance of neighbor state information. Tsao, et al. Expires October 1, 2010 [Page 12] Internet-Draft Security Framework for ROLL March 2010 The exposure of routing information exchanged will allow unauthorized sources to gain access to the content of the exchanges between communicating nodes. The exposure of neighbor state information will allow unauthorized sources to gain knowledge of communication links between routing nodes that are necessary to maintain routing information exchanges. The forms of attack that allow unauthorized access or exposure of routing exchange information, as reported in the literature, include o Deliberate exposure; o Sniffing; o Traffic analysis. 4.1.2. Routing Information (Routes and Network Topology) Exposure Routes and neighbor topology information are the products of the routing process that are stored within the node device databases. The exposure of this information will allow unauthorized sources to gain direct access to the configuration and connectivity of the network thereby exposing routing to targeted attacks on key nodes or links. Since routes and neighbor topology information is stored within the node device, threats or attacks on the confidentiality of the information will apply to the physical device including specified and unspecified internal and external interfaces. The forms of attack that allow unauthorized access or exposure of the routing information (other than occurring through explicit node exchanges) will include o Physical device compromise; o Remote device access attacks (including those occurring through remote network management or software/field upgrade interfaces). More detailed descriptions of the exposure attacks on routing exchange and information will be given in Section 5 together with the corresponding countermeasures. 4.2. Threats and Attacks on Integrity The assessment in Section 3.2 indicates that information and identity assets are exposed to integrity threats from all points of access. Tsao, et al. Expires October 1, 2010 [Page 13] Internet-Draft Security Framework for ROLL March 2010 4.2.1. Routing Information Manipulation Manipulation of routing information will allow unauthorized sources to influence the operation and convergence of the routing protocols and ultimately impact the forwarding decisions made in the network. Manipulation of neighbor state (topology) JP> topology and reachability information information will allow unauthorized sources to influence the nodes with which routing information is exchanged and updated. The consequence of manipulating routing exchanges can thus lead to sub-optimality and fragmentation or partitioning of the network by restricting the universe of routers with which associations can be established and maintained. JP> Can also lead to attract traffic, black-holes, ... The forms of attack that allow manipulation to compromise the content and validity of routing information include o Falsification, including overclaiming and misclaiming; o Routing information replay; o Byzantine (internal) attacks that permit corruption of routing information in the node even where the node continues to be a validated entity within the network; o Physical device compromise. 4.2.2. Node Identity Misappropriation Falsification or misappropriation of node identity between routing participants opens the door for other attacks; it can also cause incorrect routing relationships to form and/or topologies to emerge. Routing attacks may also be mounted through less sophisticated node identity misappropriation in which the valid information broadcast or exchanged by a node is replayed without modification. The receipt of seemingly valid information that is however no longer current can result in routing disruption, and instability (including failure to converge). Without measures to authenticate the routing participants and to ensure the freshness and validity of the received information the protocol operation can be compromised. The forms of attack that misuse node identity include o Identity (including Sybil) attacks; o Routing information replay. Tsao, et al. Expires October 1, 2010 [Page 14] Internet-Draft Security Framework for ROLL March 2010 4.3. Threats and Attacks on Availability The assessment in Section 3.2 indicates that the process and resources assets are exposed to availability threats; attacks of this category may exploit directly or indirectly information exchange or forwarding. 4.3.1. Routing Exchange Interference or Disruption Interference or disruption of routing information exchanges will allow unauthorized sources to influence the operation and convergence of the routing protocols by impeding the regularity of routing information exchange. The forms of attack that allow interference or disruption of routing exchange include o Routing information replay; o HELLO flood attacks and ACK spoofing; o Overload attacks. 4.3.2. Network Traffic Forwarding Disruption The disruption of the network traffic forwarding capability of the network will undermine the central function of network routers and the ability to handle user traffic. This threat and the associated attacks affect the availability of the network because of the potential to impair the primary capability of the network. The forms of attack that allows disruption of network traffic forwarding include o Selective forwarding attacks; o Sinkhole attacks; o Wormhole attacks. JP> Can you add reference to sinkhole and wormhole attacks? 4.3.3. Communications Resource Disruption Attacks mounted against the communication channel resource assets needed by the routing protocol can be used as a means of disrupting its operation. However, while various forms of Denial of Service (DoS) attacks on the underlying transport subsystem will affect routing protocol exchanges and operation (for example physical layer RF jamming in a wireless network or link layer attacks), these Tsao, et al. Expires October 1, 2010 [Page 15] Internet-Draft Security Framework for ROLL March 2010 attacks cannot be countered by the routing protocol. As such, the threats to the underlying transport network that supports routing is considered beyond the scope of the current document. Nonetheless, attacks on the subsystem will affect routing operation and so must be directly addressed within the underlying subsystem and its implemented protocol layers. 4.3.4. Node Resource Exhaustion A potential security threat to routing can arise from attempts to exhaust the node resource asset by initiating exchanges that can lead to the undue utilization of exhaustion of processing, memory or energy resources. The establishment and maintenance of routing neighbors opens the routing process to engagement and potential acceptance of multiple neighboring peers. Association information must be stored for each peer entity and for the wireless network operation provisions made to periodically update and reassess the associations. An introduced proliferation of apparent routing peers can therefore have a negative impact on node resources. Node resources may also be unduly consumed by the attackers attempting uncontrolled topology peering or routing exchanges, routing replays, or the generating of other data traffic floods. Beyond the disruption of communications channel resources, these threats may be able to exhaust node resources only where the engagements are able to proceed with the peer routing entities. Routing operation and network forwarding functions can thus be adversely impacted by node resources exhaustion that stems from attacks that include o Identity (including Sybil) attacks; o Routing information replay attacks; o HELLO flood attacks and ACK spoofing; o Overload attacks. 5. Countermeasures By recognizing the characteristics of LLNs that may impact routing and identifying potential countermeasures, this framework provides the basis for developing capabilities within ROLL protocols to deter the identified attacks and mitigate the threats. The following subsections consider such countermeasures by grouping the attacks according to the classification of the CIA model so that associations with the necessary security services are more readily visible. Tsao, et al. Expires October 1, 2010 [Page 16] Internet-Draft Security Framework for ROLL March 2010 However, the considerations here are more systematic than confined to means available only within routing; the next section will then distill and make recommendations appropriate for a secured ROLL protocol. 5.1. Confidentiality Attack Countermeasures Attacks on confidentiality may be mounted at the level of the routing information assets, at the points of access associated with routing exchanges between nodes, or through device interface access. To gain access to routing/topology information, the attacker may rely on a compromised node that deliberately exposes the information during the routing exchange process, may rely on passive sniffing or analysis of routing traffic, or may attempt access through a component or device interface of a tampered routing node. 5.1.1. Countering Deliberate Exposure Attacks A deliberate exposure attack is one in which an entity that is party to the routing process or topology exchange allows the routing/ topology information or generated route information to be exposed to an unauthorized entity during the exchange. A prerequisite to countering this type of confidentiality attacks associated with the routing/topology exchange is to ensure that the communicating nodes are authenticated prior to data encryption applied in the routing exchange. Authentication ensures that the nodes are who they claim to be even though it does not provide an indication of whether the node has been compromised. To prevent deliberate exposure, the process that communicating nodes use for establishing communication session keys must be symmetric at each node so that neither node can independently weaken the confidentiality of the exchange without the knowledge of its communicating peer. A deliberate exposure attack will therefore require more overt and independent action on the part of the offending node. Note that the same measures which apply to securing routing/topology exchanges between operational nodes must also extend to field tools and other devices used in a deployed network where such devices can be configured to participate in routing exchanges. 5.1.2. Countering Sniffing Attacks A sniffing attack seeks to breach routing confidentiality through passive, direct analysis and processing of the information exchanges between nodes. A sniffing attack in an LLN that is not based on a Tsao, et al. Expires October 1, 2010 [Page 17] Internet-Draft Security Framework for ROLL March 2010 physical device compromise will rely on the attacker attempting to directly derive information from the over-the-air routing/topology communication exchange (neighbor discovery exchanges may of necessity be conducted in the clear thus limiting the extent to which the information can be kept confidential). Sniffing attacks can be directly countered through the use of data encryption for all routing exchanges. Only when a validated and authenticated node association is completed will routing exchange be allowed to proceed using established session confidentiality keys and an agreed confidentiality algorithm. JP> Id security is "turned on". Could you specify that the routing protocol will include security features according to this framework but some scenario may not require their use, should they be provide by other means or not needed in a specific environment. The level of security applied in providing confidentiality will determine the minimum requirement for an attacker mounting this passive security attack. Because of the resource constraints of LLN devices, symmetric (private) key session security will provide the best tradeoff in terms of node and channel resource overhead and the level of security achieved. This will of course not preclude the use of asymmetric (public) key encryption during the session key establishment phase. As with the key establishment process, data encryption must include an authentication prerequisite to ensure that each node is implementing a level of security that prevents deliberate or inadvertent exposure. The authenticated key establishment will ensure that confidentiality is not compromised by providing the information to an unauthorized entity (see also [Huang2003]). Based on the current state of the art, a minimum 128-bit key length should be applied where robust confidentiality is demanded for routing protection. This session key shall be applied in conjunction with an encryption algorithm that has been publicly vetted and where applicable approved for the level of security desired. Algorithms such as AES (adopted by the U.S. government) or Kasumi-Misty (adopted by the 3GPP 3rd generation wireless mobile consortium) JP> Could you please ad references ? are examples of symmetric-key algorithms capable of ensuring robust confidentiality for routing exchanges. The key length, algorithm and mode of operation will be selected as part of the overall security tradeoff that also achieves a balance with the level of confidentiality afforded by the physical device in protecting the routing assets (see Section 5.1.4 below). As with any encryption algorithm, the use of ciphering synchronization parameters and limitations to the usage duration of established keys should be part of the security specification to reduce the potential for brute force analysis. Tsao, et al. Expires October 1, 2010 [Page 18] Internet-Draft Security Framework for ROLL March 2010 5.1.3. Countering Traffic Analysis Traffic analysis provides an indirect means of subverting confidentiality and gaining access to routing information by allowing an attacker to indirectly map the connectivity or flow patterns (including link-load) JP> Aren't you making the assumption that LLNs only comprise radio link layers ? ** Please make sure that throughout the document you are not making any assumption on the link layer (see other comments above along the same lines). of the network from which other attacks can be mounted. The traffic analysis attack on a LLN may be passive and relying on the ability to read the immutable source/destination routing information that must remain unencrypted to permit network routing. Alternatively, attacks can be active through the injection of unauthorized discovery traffic into the network. By implementing authentication measures between communicating nodes, active traffic analysis attacks can be prevented within the LLN thereby reducing confidentiality vulnerabilities to those associated with passive analysis. One way in which passive traffic analysis attacks can be muted is through the support of load balancing that allows traffic to a given destination to be sent along diverse routing paths. Where the routing protocol supports load balancing along multiple links at each node, the number of routing permutations in a wide area network surges thus increasing the cost of traffic analysis. Network analysis through this passive attack will require a wider array of analysis points and additional processing on the part of the attacker. In LLNs, the diverse radio connectivity and dynamic links (including potential frequency hopping) will help to further mitigate traffic analysis attacks when load balancing is implemented. JP> Please indicate that this is trued if the link layer is wireless. The only means of fully countering a traffic analysis attack is through the use of tunneling (encapsulation) where encryption is applied across the entirety of the original packet source/destination addresses. With tunneling there is a further requirement that the encapsulating intermediate nodes apply an additional layer of routing so that traffic arrives at the destination through dynamic routes. For LLNs, memory and processing constraints as well as the limitations of the communication channel will preclude both the additional routing traffic overhead JP> But tunneling may be used and is actually used in several cases (e.g. this is the situation for example with RPL when an additional header used for example for loop detection is added to the HbP header for traffic from outside of the LLN to a node inside the LLN). and the node implementation required for tunneling countermeasures to traffic analysis. 5.1.4. Countering Physical Device Compromise Given the distributed nature of LLNs, confidentiality of routing assets and points of access will rely heavily on the security of the routing devices. One means of precluding attacks on the physical device is to prevent physical access to the node through other external security means. However, given the environment in which LLNs operate, preventing unauthorized access to the physical device cannot be assured. JP> "in some cases" - for example in a Smart Grid environment the substation has secured access. Countermeasures must therefore be employed at the Tsao, et al. Expires October 1, 2010 [Page 19] Internet-Draft Security Framework for ROLL March 2010 device and component level so that routing/topology or neighbor information and stored route information cannot be accessed even if physical access to the node is obtained. With the physical device in the possession of an attacker, unauthorized information access can be attempted by probing internal interfaces or device components. Device security must therefore move to preventing the reading of device processor code or memory locations without the appropriate security keys and in preventing the access to any information exchanges occurring between individual components. Information access will then be restricted to external interfaces in which confidentiality, integrity and authentication measures can be applied. JP> True but you may want to mention that this is not 'routing security' specific. To prevent component information access, deployed routing devices must ensure that their implementation avoids address or data buses being connected to external general purpose input/output (GPIO) pins. Beyond this measure, an important component interface to be protected against attack is the Joint Test Action Group (JTAG) interface used for component and populated circuit board testing after manufacture. To provide security on the routing devices, components should be employed that allow fuses on the JTAG interfaces to be blown to disable access. This will raise the bar on unauthorized component information access within a captured device. At the device level a key component information exchange is between the microprocessor and it associated external memory. While encryption can be implemented to secure data bus exchanges, the use of integrated physical packaging which avoids inter-component exchanges (other than secure external device exchanges) will increase routing security against a physical device interface attack. With an integrated package and disabled internal component interfaces, the level of physical device security can be controlled by managing the degree to which the device packaging is protected against expert physical decomposition and analysis. The device package should be hardened such that attempts to remove the integrated components will result in damage to access interfaces, ports or pins that prevent retrieval of code or stored information. The degree of VLSI or PCB JP> Could you please expand acronyms when first used ? package security through manufacture can be selected as a tradeoff or desired security consistent with the level of security achieved by measures applied for other routing assets and points of access. With package hardening and restricted component access countermeasures, the security level will be raised to that provided by measures employed at the external communications interfaces. Another area of node interface vulnerability is that associated with Tsao, et al. Expires October 1, 2010 [Page 20] Internet-Draft Security Framework for ROLL March 2010 interfaces provided for remote software or firmware upgrades. This may impact both routing information and routing/topology exchange security where it leads to unauthorized upgrade or change to the routing protocol running on a given node as this type of attack can allow for the execution of compromised or intentionally malicious routing code on multiple nodes. Countermeasures to this device interface confidentiality attack needs to be addressed in the larger context of node remote access security. This will ensure not only the authenticity of the provided code (including routing protocol) but that the process is initiated by an authorized (authenticated) entity. The above identified countermeasures against attacks on routing information confidentiality through internal device interface compromise must be part of the larger LLN system security as they cannot be addressed within the routing protocol itself. Similarly, the use of field tools or other devices that allow explicit access to node information must implement security mechanisms to ensure that routing information can be protected against unauthorized access. These protections will also be external to the routing protocol and hence not part of ROLL. 5.1.5. Countering Remote Device Access Attacks Where LLN nodes are deployed in the field, measures are introduced to allow for remote retrieval of routing data and for software or field upgrades. These paths create the potential for a device to be remotely accessed across the network or through a provided field tool. In the case of network management a node can be directly requested to provide routing tables and neighbor information. To ensure confidentiality of the node routing information against attacks through remote access, any device local or remote requesting routing information must be authenticated to ensure authorized access. Since remote access is not invoked as part of a routing protocol security of routing information stored on the node against remote access will not be addressable as part of the routing protocol. 5.2. Integrity Attack Countermeasures Integrity attack countermeasures address routing information manipulation, as well as node identity and routing information misuse. Manipulation can occur in the form of falsification attack and physical compromise. To be effective, the following development considers the two aspects of falsification, namely, the tampering actions and the overclaiming and misclaiming content. The countering of physical compromise was considered in the previous section and is Tsao, et al. Expires October 1, 2010 [Page 21] Internet-Draft Security Framework for ROLL March 2010 not repeated here. With regard to misuse, there are two types of attacks to be deterred, identity attacks and replay attacks. 5.2.1. Countering Tampering Attacks Tampering may occur in the form of altering the message being transferred or the data stored. Therefore, it is necessary to ensure that only authorized nodes can change the portion of the information that is allowed to be mutable, while the integrity of the rest of the information is protected, e.g., through well-studied cryptographic mechanisms. Tampering may also occur in the form of insertion or deletion of messages during protocol changes. Therefore, the protocol needs to ensure the integrity of the sequence of the exchange sequence. The countermeasure to tampering needs to o implement access control on storage; o provide data integrity service to transferred messages and stored data; o include sequence number under integrity protection. 5.2.2. Countering Overclaiming and Misclaiming Attacks Both overclaiming and misclaiming aim to introduce false routes or topology that would not be generated by the network otherwise, while there is not necessarily tampering. The requisite for a counter is the capability to determine unreasonable routes or topology. The counter to overclaiming and misclaiming may employ o comparison with historical routing/topology data; o designs which restrict realizable network topologies. 5.2.3. Countering Identity (including Sybil) Attacks Identity attacks, sometimes simply called spoofing, seek to gain or damage assets whose access is controlled through identity. In routing, an identity attacker can illegitimately participate in routing exchanges, distribute false routing information, or cause an invalid outcome of a routing process. A perpetrator of Sybil attacks assumes multiple identities. The result is not only an amplification of the damage to routing, but Tsao, et al. Expires October 1, 2010 [Page 22] Internet-Draft Security Framework for ROLL March 2010 extension to new areas, e.g., where geographic distribution is explicit or implicit an asset to an application running on the LLN. JP> You could mentioned that this is a particular concern in LLN where the traffic flow is mostly P2MP and MP2P. The counter of identity attacks need to ensure the authenticity and liveliness of the parties of a message exchange; the measure may use shared key or public key based authentication scheme. On the one hand, the large-scale nature of the LLNs makes the network-wide shared key scheme undesirable from a security perspective; on the other hand, public-key based approaches generally require more computational resources. JP> Could elaborate a little bit more on the CPU impact when using public-key? Each system will need to make trade-off decisions based on its security requirements. 5.2.4. Countering Routing Information Replay Attacks In routing, message replay can result in false topology and/or routes. The counter of replay attacks need to ensure the freshness of the message. On the one hand, there are a number of mechanisms commonly used for countering replay. JP> Want to add some references? On the other hand, the choice should take into account how a particular mechanism is made available in a LLN. For example, many LLNs have a central source of time and have it distributed by relaying, such that secured time distribution becomes a prerequisite of using timestamping to counter replay. JP> Which means to support clocks, ... 5.2.5. Countering Byzantine Routing Information Attacks Where a node is captured or compromized but continues to operate for a period with valid network security credentials, the potential exists for routing information to be manipulated. This compromise of the routing information could thus exist in spite of security countermeasures that operate between the peer routing devices. Consistent with the end-to-end principle of communications, such an attack can only be fully addressed through measures operating directly between the routing entities themselves or by means of external entities able to access and independently analyze the routing information. Verification of the authenticity and liveliness of the routing principals can therefore only provide a limited counter against internal (Byzantine) node attacks. JP> Agree but this is not particularly tied to the end-to-end principle. For link state routing protocols where information is flooded JP> add "with area (OSPF) or levels (ISIS) countermeasures can be directly applied by the routing entities through the processing and comparison of link state information received from different peers. By comparing the link information from multiple sources decisions can be made by a routing node or external entity with regard to routing information validity. For distance vector protocols where information is aggregated at each routing node it is not possible for nodes to directly detect Tsao, et al. Expires October 1, 2010 [Page 23] Internet-Draft Security Framework for ROLL March 2010 Byzantine information manipulation attacks from the routing information exchange. In such cases, the routing protocol must include and support indirect communications exchanges between non- adjacent routing peers to provide a secondary channel for performing routing information validation. S-RIP [Wan2004] is an example of the implementation of this type of dedicated routing protocol security where the correctness of aggregate distance vector information can only be validated by initiating confirmation exchanges directly between nodes that are not routing neighbors. Alternatively, an entity external to the routing protocol would be required to collect and audit routing information exchanges to detect the Byzantine attack. In the context of the current security framework, any protection against Byzantine routing information attacks will need to be directly included within the mechanisms of the ROLL routing protocol. This can be implemented where such an attack is considered relevant even within the physical device protections discussed in Section 5.1.4 5.3. Availability Attack Countermeasures As alluded to before, availability requires that routing information exchanges and forwarding mechanisms be available when needed so as to guarantee a proper functioning of the network. This may, e.g., include the correct operation of routing information and neighbor state information exchanges, among others. We will highlight the key features of the security threats along with typical countermeasures to prevent or at least mitigate them. We will also note that an availability attack may be facilitated by an identity attack as well as a replay attack, as was addressed in Section 5.2.3 and Section 5.2.4, respectively. 5.3.1. Countering HELLO Flood Attacks and ACK Spoofing Attacks HELLO Flood [Karlof2003],[I-D.suhopark-hello-wsn] and ACK Spoofing attacks are different but highly related forms of attacking a LLN. They essentially lead nodes to believe that suitable routes are available even though they are not and hence constitute a serious availability attack. The origin of facilitating a HELLO flood attack lies in the fact that many wireless routing protocols JP> Please do not use the terms "wireless routing protocols" since by definition of a layered architecture, the routing protocol is not tied to a particular link layer. Furthermore this also applies to routing protocols used in non wireless environments. require nodes to send HELLO packets either upon joining or in regular intervals so as to announce or confirm their existence to the network. Those nodes that receive the HELLO packet assume JP> If they receive the packet they *are* in the radio range (again the link may not be wireless). that they are within radio range of the transmitter by means of a bidirectional communication link. With this in mind, a malicious node can send or replay HELLO packets Tsao, et al. Expires October 1, 2010 [Page 24] Internet-Draft Security Framework for ROLL March 2010 using a higher transmission power. That creates the false illusion of being a neighbor to an increased number of nodes in the network, thereby effectively increasing its unidirectional neighborhood cardinality. The high quality of the falsely advertised link may coerce nodes to route data via the malicious node. However, those affected nodes, for which the malicious node is out of radio range, never succeed in their delivery and the packets are effectively dropped. JP> Mention "if the link layer is wireless". Not that in PLC, this can happen too. The symptoms are hence similar to those of a sinkhole, wormhole and selective forwarding attack. A malicious HELLO flood attack clearly distorts the network topology. It thus affects protocols building and maintaining the network topology as well as routing protocols as such, since the attack is primarily targeted on protocols that require sharing of information for topology maintenance or flow control. To counter HELLO flood attacks, several mutually non-exclusive methods are feasible: o restricting neighborhood cardinality; o facilitating multipath routing; o verifying bidirectionality. Restricting the neighborhood cardinality prevents malicious nodes from having an extended set of neighbors beyond some tolerated threshold and thereby preventing topologies to be built where malicious nodes have an extended neighborhood set. JP> But thai may artificially reduce the number of "valid" neighbors too. Furthermore, as shown in [I-D.suhopark-hello-wsn], if the routing protocol supports multiple paths from a sensing node towards several gateways then HELLO flood attacks can also be diminished; however, the energy- efficiency of such approach is clearly sub-optimal. Finally, verifying that the link is truly bidirectional by means of, e.g., an ACK handshake and appropriate security measures ensures that a communication link is only established if not only the affected node is within range of the malicious node but also vice versa. Whilst this does not really eliminate the problem of HELLO flooding, it greatly reduces the number of affected nodes and the probability of such an attack succeeding. JP> Even if there is bi-directinality, the attacked node may thus send traffic to the attackers that claims to have "good" routes though. As for the latter, the adversary may spoof the ACK messages to convince the affected node that the link is truly bidirectional and thereupon drop, tunnel or selectively forward messages. Such ACK spoofing attack is possible if the malicious node has a receiver which is significantly more sensitive than that of a normal node, thereby effectively extending its range. Since an ACK spoofing attack facilitates a HELLO flood attack, similar countermeasure are Tsao, et al. Expires October 1, 2010 [Page 25] Internet-Draft Security Framework for ROLL March 2010 applicable here. Viable counter and security measures for both attacks have been exposed in [I-D.suhopark-hello-wsn]. 5.3.2. Countering Overload Attacks Overload attacks are a form of DoS attack in that a malicious node overloads the network with irrelevant traffic, thereby draining the nodes' energy budget quicker. JP> Energy indeed (a real issue if node are battery operated or using energy scavengers) but also inject loads and creates congestions. It thus significantly shortens the network lifetime JP> If the LLNs is made of battery-operated nodes. and hence constitutes another serious availability attack. With energy being one of the most precious assets of LLNs, targeting its availability is a fairly obvious attack. Another way of depleting the energy of a LLN node is to have the malicious node overload the network with irrelevant traffic. This impacts availability since certain routes get congested which o renders them useless for affected nodes and data can hence not be delivered; o makes routes longer as shortest path algorithms work with the congested network; JP> Not sure what you meant above o depletes nodes quicker and thus shortens the network's availability at large. JP> Again if nodes are battery operated. Overload attacks can be countered by deploying a series of mutually non-exclusive security measures: o introduce quotas on the traffic rate each node is allowed to send; JP> Also referred to as "traffic shaping" but only possible in some networks. o isolate nodes which send traffic above a certain threshold; JP> If "Valid" nodes that may attract lots of traffic do no exist in the network. o allow only trusted data to be received and forwarded. As for the first one, a simple approach to minimize the harmful impact of an overload attack is to introduce traffic quotas. This prevents a malicious node from injecting a large amount of traffic into the network, even though it does not prevent said node from injecting irrelevant traffic at all. Another method is to isolate JP> If you have a wireless link, how do you "isolate" the node ? It can still sends traffic (at least with some MACs). nodes from the network once it has been detected that more traffic is injected into the network than allowed by a prior set or dynamically adjusted threshold. Finally, if communication is sufficiently secured, only trusted nodes can receive and forward traffic which also lowers the risk of an overload attack. Tsao, et al. Expires October 1, 2010 [Page 26] Internet-Draft Security Framework for ROLL March 2010 5.3.3. Countering Selective Forwarding Attacks Selective forwarding attacks are another form of DoS attack which impacts the routing path availability. An insider malicious node basically blends neatly in with the network but then may decide to forward and/or manipulate certain packets. If all packets are dropped, then this attacker is also often referred to as a "black hole". Such a form of attack is particularly dangerous if coupled with sinkhole attacks since inherently a large amount of traffic is attracted to the malicious node and thereby causing significant damage. An outside malicious node would selectively jam overheard data flows, where the thus caused collisions JP> Again is the MAC is a shared media. incur selective forwarding. Selective Forwarding attacks can be countered by deploying a series of mutually non-exclusive security measures: o multipath routing of the same message over disjoint paths; o dynamically select the next hop from a set of candidates. The first measure basically guarantees that if a message gets lost on a particular routing path due to a malicious selective forwarding attack, there will be another route which successfully delivers the data. Such method is inherently suboptimal from an energy consumption point of view. The second method basically involves a constantly changing routing topology in that next-hop routers are chosen from a dynamic set in the hope that the number of malicious nodes in this set is negligible. JP> If the routing protocol allows for disjoint routing paths, this is even more attractive. 5.3.4. Countering Sinkhole Attacks In sinkhole attacks, the malicious node manages to attract a lot of traffic mainly by advertising the availability of high-quality links even though there are none. It hence constitutes a serious attack on availability. The malicious node creates a sinkhole by attracting a large amount of, if not all, traffic from surrounding neighbors by advertising in and outwards links of superior quality. Affected nodes hence eagerly route their traffic via the malicious node which, if coupled with other attacks such as selective forwarding, may lead to serious availability and security breaches. Such an attack can only be executed by an inside malicious node and is generally very difficult to detect. An ongoing attack has a profound impact on the network topology and essentially becomes a problem of flow control. Tsao, et al. Expires October 1, 2010 [Page 27] Internet-Draft Security Framework for ROLL March 2010 Sinkhole attacks can be countered by deploying a series of mutually non-exclusive security measures: o use geographical insights for flow control; o isolate nodes which receive traffic above a certain threshold; o dynamically pick up next hop from set of candidates; o allow only trusted data to be received and forwarded. Whilst most of these countermeasures have been discussed before, the use of geographical information deserves further attention. Essentially, if geographic positions of nodes are available, then the network can assure that data is actually routed towards the sink(s) and not elsewhere. JP> Yes but it may be wise to route all traffic via a node that is not closer to the sink but supports interesting capabilities such as aggregation. On the other hand, geographic position is a sensitive information that may have security and/or privacy consequences. 5.3.5. Countering Wormhole Attacks In wormhole attacks at least two malicious nodes shortcut or divert the usual routing path by means of a low-latency out-of-band channel. This changes the availability of certain routing paths and hence constitutes a serious security breach. Essentially, two malicious insider nodes use another, more powerful, radio JP> Once again, if the link in use is wireless. to communicate with each other and thereby distort the would- be-agreed routing path. This distortion could involve shortcutting and hence paralyzing a large part of the network; it could also involve tunneling the information to another region of the network where there are, e.g., more malicious nodes available to aid the intrusion or where messages are replayed, etc. In conjunction with selective forwarding, wormhole attacks can create race conditions which impact topology maintenance, routing protocols as well as any security suits built on "time of check" and "time of use". Wormhole attacks are very difficult to detect in general but can be mitigated using similar strategies as already outlined above in the context of sinkhole attacks. 6. ROLL Security Features The assessments and analysis in Section 4 examined all areas of threats and attacks that could impact routing, and the countermeasures presented in Section 5 were reached without confining the consideration to means only available to routing. This section Tsao, et al. Expires October 1, 2010 [Page 28] Internet-Draft Security Framework for ROLL March 2010 puts the results into perspective and provides a framework for addressing the derived set of security objectives that must be met by the ROLL protocol. JP> s/ROLL protocol/Routing protocol specified by the ROLL Working Group. It bears emphasizing that the target here is a generic ROLL protocol and the normative keywords are mainly to convey the relative level of urgency of the features specified. The first part of this section, Section 6.1 to Section 6.3, is a prescription of ROLL security features of measures that can be addressed as part of the routing protocol itself. As routing is one component of a LLN system, the actual strength of the security services afforded to it should be made to conform to each system's security policy; how a design may address the needs of the urban, industrial, home automation, and building automation application domains also needs to be considered. The second part of this section, Section 6.4 and Section 6.5, discusses system security aspects that may impact routing but that also require considerations beyond the routing protocol, as well as potential approaches. 6.1. Confidentiality Features With regard to confidentiality, protecting the routing/topology information from eavesdropping or unauthorized exposure is not directly essential to maintaining the routing function. Breaches of confidentiality may lead to other attacks or the focusing of an attacker's resources (see Section 4.1) but does not of itself directly undermine the operation of the routing function. However, to protect against, and improve vulnerability against other more direct attacks, routing information confidentiality should be protected. Thus, a secured ROLL protocol o SHOULD provide payload encryption; o MAY provide tunneling; o MAY provide load balancing; JP> You can add a note and point to the requirement RFCs, where this is listed as a requirement. o SHOULD provide privacy, e.g., when geographic information is used. Where confidentiality is incorporated into the routing exchanges, encryption algorithms and key lengths need to be specified in accordance of the level of protection dictated by the routing protocol and the associated application domain transport network. In terms of the life time of the keys, the opportunity to periodically change the encryption key increases the offered level of security for any given implementation. However, where strong cryptography is employed, physical, procedural, and logical data access protection considerations may have more significant impact on cryptoperiod selection than algorithm and key size factors. Nevertheless, in Tsao, et al. Expires October 1, 2010 [Page 29] Internet-Draft Security Framework for ROLL March 2010 general, shorter cryptoperiods, during which a single key is applied, will enhance security. Given the mandatory protocol requirement to implement routing node authentication as part of routing integrity (see Section 6.2), key exchanges may be coordinated as part of the integrity verification process. This provides an opportunity to increase the frequency of key exchange and shorten the cryptoperiod as a compliment to the key length and encryption algorithm required for a given application domain. For LLNs, the coordination of confidentiality key management with the implementation of node device authentication can thus reduce the overhead associated with supporting data confidentiality. A new ciphering key may therefore be concurrently generated or updated in conjunction with the mandatory authentication exchange occurring with each routing peer association. 6.2. Integrity Features The integrity of routing information provides the basis for ensuring that the function of the routing protocol is achieved and maintained. To protect integrity, a secured ROLL protocol o MUST verify message integrity; o MUST verify the authenticity and liveliness of both principals of a connection; o MUST verify message sequence. Depending on the nature of the routing protocol, e.g., distance vector or link state, additional measures may be necessary when the validity of the routing information is of concern. Specifically, verification of routing peer authenticity and liveliness can be used to build a "chain of trust" along the path the routing information flows, such that network-wide information is validated through the concatenation of trust established at each individual routing peer exchange. This is particularly important in the case of distance vector-based routing protocols, where information is updated at intermediate nodes, In such cases, there are no direct means within routing for a receiver to verify the validity of the routing information beyond the current exchange; as such, nodes would need to be able to communicate and request information from non-adjacent peers (see [Wan2004]) to provide information integrity assurances. With link state-based protocols, on the other hand, routing information can be signed at the source thus providing a means for validating information that originates beyond a routing peer. Therefore, where necessary, a secured ROLL protocol JP> You can remove the "o" below since there is no other ones. Tsao, et al. Expires October 1, 2010 [Page 30] Internet-Draft Security Framework for ROLL March 2010 o MAY use security auditing mechanisms that are external to routing to verify the validity of the routing information content exchanged among routing peers. 6.3. Availability Features Availability of routing information is linked to system and network availability which in the case of LLNs require a broader security view beyond the requirements of the routing entities (see Section 6.5). Where availability of the network is compromised, routing information availability will be accordingly affected. However, to specifically assist in protecting routing availability o MAY restrict neighborhood cardinality; o MAY use multiple paths; o MAY use multiple destinations; o MAY choose randomly if multiple paths are available; o MAY set quotas to limit transmit or receive volume; o MAY use geographic insights for flow control. 6.4. Additional Related Features If a LLN employs multicast and/or anycast, it MUST secure these protocols JP> "protocols" ? with the services listed in this sections. Furthermore, the nodes MUST provide adequate physical tamper resistance to ensure the integrity of stored routing information. The functioning of the security services requires keys and credentials. Therefore, even though not directly a ROLL security requirement, a LLN must include a process for key and credential distribution; a LLN is encouraged to have procedures for their revocation and replacement. 6.5. Consideration on Matching Application Domain Needs As routing is one component of a LLN system, the actual strength of the security services afforded to it should be made to conform to each system's security policy; how a design may address the needs of the urban, industrial, home automation, and building automation application domains is considered as part of the security architecture in Section 6.5.1. The development so far takes into account collectively the impacts of Tsao, et al. Expires October 1, 2010 [Page 31] Internet-Draft Security Framework for ROLL March 2010 the issues gathered from [RFC5548], [RFC5673], [I-D.ietf-roll-home-routing-reqs], and [I-D.ietf-roll-building-routing-reqs]. JP> Update the reference (all RFcs now). The following two subsections first consider from an architectural perspective how the security design of a ROLL protocol may be made to adapt to the four application domains, and then examine mechanism and protocol operations issues. 6.5.1. Security Architecture The first challenge for a ROLL protocol security design is to have an architecture that can adequately address a set of very diversified needs. It is mainly a consequence of the fact that there are both common and non-overlapping requirements from the four application domains, while, conceivably, each individual application will present yet its own unique constraints. For a ROLL protocol, the security requirements defined in Section 6.1 to Section 6.4 can be addressed at two levels: 1) through measures implemented directly within the routing protocol itself and initiated and controlled by the routing protocol entities; or 2) through measures invoked on behalf of the routing protocol entities but implemented within the transport network JP> Be accurate when you used "transport network": you mean "link layer" ? over which the protocol exchanges occur. Where security is directly implemented as part of the routing protocol the security requirements configured by the user (system administrator) will operate independent of the underlying transport network JP>s/transport network/link layer . OSPFv2 [RFC2328] is an example of such an approach in which security parameters are exchanged and assessed within the routing protocol messages. In this case, the mechanism may be, e.g., a header containing security material of configurable security primitives in the fashion of OSPFv2 or RIPv2 [RFC2453]. Where IPsec [RFC4301] is employed to secure the network, the included protocol- specific (OSPF or RIP) security elements are in addition to and independent of those at the network layer. In the case of LLNs or other networks where system security mandates protective mechanisms at other lower layers of the transport network, JP> "lower layers of the transport network" is ambiguous. security measures implemented as part of the routing protocol will be redundant to security measures implemented elsewhere as part of the transport network. JP> Please replace "transport network" with appropriate terminology where needed. Thanks. Security mechanisms built into the routing protocol can ensure that all desired countermeasures can be directly addressed by the protocol all the way to the endpoint of the routing exchange. In particular, routing protocol Byzantine attacks by a compromised node that retains valid network security credentials can only be detected at the level of the information exchanged within the routing protocol. Such Tsao, et al. Expires October 1, 2010 [Page 32] Internet-Draft Security Framework for ROLL March 2010 attacks aimed the manipulation of the routing information can only be fully addressed through measures operating directly between the routing entities themselves or external entities able to access and analyze the routing information (see discussion in Section 5.2.5). On the other hand, it is more desirable from a LLN device perspective that the ROLL protocol is integrated into the framework of an overall system architecture where the security facility may be shared by different applications and/or across layers for efficiency, and where security policy and configurations can be consistently specified. See, for example, considerations made in RIPng [RFC2080] or the approach presented in [Messerges2003]. Where the routing protocol is able to rely on security measures configured with the transport network JP> Same comment. What do you mean by "transport network"? , greater system efficiency can be realized by avoiding potentially redundant security. Relying on an open trust model [Messerges2003], the security requirements of the routing protocol can be more flexibly met at different layers of the transport network; measures that must be applied to protect the communications network are concurrently able to provide the needed routing protocol protection. In addition, in the context of the different application domains, it allows the level of security applied for routing to be consistent with that needed for protecting the network itself. For example, where AES-128 JP> Expand terms when first used + add reference is deemed the appropriate standard for network confidentiality of data exchanges at the link layer, that level of security is automatically afforded to routing protocol exchanges. Similarly, where SHA-1 JP> Same comment is stipulated as the standard required for authenticating routing protocol peers, the use of SHA-1 at the network layer between communicating routing devices automatically meets the routing protocol security requirement within the context of open trust across layers within the device. A ROLL protocol MUST be made flexible by a design that offers the configuration facility so that the user (network administrator) can choose the security settings that match the application's needs. Furthermore, in the case of LLNs that flexibility should extend to allowing the routing protocol security requirements to be met by measures applied at different protocol layers, provided the identified requirements are collectively met. Since Byzantine attacks that can affect the validity of the information content exchanged between routing entities can only be directly countered at the routing protocol level, the ROLL protocol may support mechanisms for verifying routing data validity that extends beyond the chain of trust created through device authentication. This protocol-specific security mechanism should be Tsao, et al. Expires October 1, 2010 [Page 33] Internet-Draft Security Framework for ROLL March 2010 made optional within the protocol allowing it to be invoked according to the given routing protocol and application domain and as selected by the system user. All other ROLL security mechanisms needed to meet the above identified routing security requirements should be flexibly implemented within the transport network (at the IP network layer or higher or lower protocol layers(s)) according to the particular application domain and user network configuration. Based on device capabilities and the spectrum of operating environments it would be difficult for a single fixed security design to be applied to address the diversified needs of the four ROLL application domains JP> Please list them again (urban, industrial, home/building) + indicate that this is also true for other application domains. without forcing a very low common denominator set of requirements. On the other hand, providing four individual domain designs that attempt to a priori match each individual domain is also very likely to provide a suitable answer given the degree of network variability even within a given domain. JP> The type of link layers in use within each domain also influences the overall security. Instead, the framework implementation approach recommended for optional, routing protocol- specific measures together with flexible transport network mechanisms can be the most effective. This approach allows countermeasures against internal attacks to be applied in environments where applicable threats exist. At the same time, it allows routing protocol security to be configured through measures implemented within the transport network that is commensurate and consistent with the level and strength applied in the particular application domain networks. 6.5.2. Mechanisms and Operations With an architecture allowing different configurations to meet the application domain needs, the task is then to find suitable mechanisms. For example, one of the main problems of synchronizing security states of sleepy nodes, as listed in the last subsection, lies in difficulties in authentication; these nodes may not have received in time the most recent update of security material. Similarly, the issues of minimal manual configuration, prolonged rollout and delayed addition of nodes, and network topology changes also complicate security management. In such case the ROLL protocol may need to bootstrap the authentication process and allow for flexible expiration scheme of authentication credentials. This exemplifies the need for the coordination and interoperation between the requirements of the ROLL routing protocol and that of the system security elements. Similarly, the vulnerability brought forth by some special-function nodes, e.g., gateways/sinks requires the assurance, particularly, of the availability of communication channels and node resources, or that the neighbor discovery process operates without undermining routing availability. Tsao, et al. Expires October 1, 2010 [Page 34] Internet-Draft Security Framework for ROLL March 2010 There and other factors which are not part of a ROLL routing protocol can still affect its operation. This includes elements such as weaker barrier to accessing the data or security material stored on the nodes through physical means; therefore, the internal and external interfaces of a node need to be adequate for guarding the integrity, and possibly the confidentiality, of stored information, as well as the integrity of routing and route generation processes. Figure 2 provides an overview of the larger context of system security and the relationship between ROLL requirements and measures and those that relate to the LLN system. Tsao, et al. Expires October 1, 2010 [Page 35] Internet-Draft Security Framework for ROLL March 2010 Security Services for ROLL-Addressable Security Requirements | | +---+ +---+ Node_i | | Node_j _____v___ ___v_____ Specify Security / \ / \ Specify Security Requirements | Routing | | Routing | Requirements +---------| Protocol| | Protocol|---------+ | | Entity | | Entity | | | \_________/ \_________/ | | | | | |ROLL-Specified | | ROLL-Specified| ---Interface | | Interface--- | ...................................... | | : | | : | | : +-----+----+ +----+-----+ : | | : |Transport/| |Transport/| : | ____v___ : +>|Network | |Network |<+ : ___v____ / \ : | +-----+----+ +----+-----+ | : / \ | |-:-+ | | +-:-| | |Security| : +-----+----+ +----+-----+ : |Security| +->|Services|-:-->| Link | | Link |<--:-|Services|<-+ | |Entity | : +-----+----+ +----+-----+ : |Entity | | | | |-:-+ | | +-:-| | | | \________/ : | +-----+----+ +----+-----+ | : \________/ | | : +>| Physical | | Physical |<+ : | Application : +-----+----+ +----+-----+ : Application Domain User : | | : Domain User Configuration : |__Comm. Channel_| : Configuration : : ...Transport Network.................. Figure 2: LLN Device Security Model JP> Great figure. Just clarify "transport/network" 7. Application of ROLL Security Framework to RPL JP> Expand acronym when first used (RPL) This section applies the assessments given in Section 6 to RPL JP> Ad reference (draft-ietf-roll-rpl) as an illustration of the application of the LLN security framework. Specializing the approach used in Section 3.1, Figure 3 gives a level-1 data flow diagram representation of RPL to show the routing "assets" and "points of access" that may be vulnerable and need to be protected. Tsao, et al. Expires October 1, 2010 [Page 36] Internet-Draft Security Framework for ROLL March 2010 ............................................ : : |Link-Local : : Multicast : : or Node_i|<----->(DIO/DIS/DAO)<--------------+ : : ^ | : : | ______V______ : : | Candidate : : V Neighbor List : : (RPL Control incl. ------+------ : : Trickle Timer, | : : Loop Avoidance) V : : ^ (Route Generation) : : | | : : | ______V______ : : +------+ Routing Table : : | ------+------ : : | | : : RPL on Node_j | | : ..................|.............|........... | | |Forwarding V | To/From Node_k|<-------->(Read/Write | Flow Label)<-------+ Figure 3: Data Flow Diagram of RPL From Figure 3, it is seen that threats to the proper operation of RPL are realized through attacks on its DIO, DIS, and DAO messages, as well as on the information the protocol places on the IPv6 Flow Labels. JP> Please update since information is now carried in the Hop-by-hop header with the RPL option (draft in 6man). As set forth in Section 6.1 to Section 6.4, the base security requirements concern message integrity, authenticity and liveliness of the principals of a connection, and protection against message replay; message encryption may be desirable. The security objectives for RPL are therefore to ensure that 1. participants of the DIO, DIS, and DAO message exchanges are authentic; 2. the received DIO, DIS, and DAO messages are not modified during transportation; 3. the received DIO, DIS, and DAO messages are not retransmissions of previous messages; 4. the content of the DIO, DIS, and DAO messages may be made legible to only authorized entities. Tsao, et al. Expires October 1, 2010 [Page 37] Internet-Draft Security Framework for ROLL March 2010 In meeting the above objectives, RPL also needs to provide tunable mechanisms both to allow matching the security afforded to the application domain requirements and to enable efficient use of system resources, as discussed in Section 6.5.1 and Section 6.5.2. The functions of the different RPL messages and information placed within the user data plane Flow Labels JP> s/"user data plane"/"user data plane (RPL option TLV carried in the IPv6 Hop-by-hop header) are factors that can be taken into account when deciding the optional security features and levels of strength to be afforded. For example, the DIO messages build routes to roots while the DAO messages support the building of downward routes to leaf nodes. Consequently, there may be application environments in which the directions of the routes have different importance and thus warrant the use of different security features and/or strength. In other words, it may be desirable to have an RPL security design that extends the tunability of the security features and strengths to message types. The use of a per- message security specification will allow flexibility in permitting application-domain security choices as well as overall tunability. 8. IANA Considerations This memo includes no request to IANA. 9. Security Considerations The framework presented in this document provides security analysis and design guidelines with a scope limited to ROLL. Security services are identified as requirements for securing ROLL. The results are applied to RPL, with consequent recommendations. 10. Acknowledgments The authors would like to acknowledge the review and comments from Rene Struik. 11. References 11.1. Normative References [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Tsao, et al. Expires October 1, 2010 [Page 38] Internet-Draft Security Framework for ROLL March 2010 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. 11.2. Informative References [Huang2003] Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J. Zhang, "Fast Authenticated Key Establishment Protocols for Self-Organizing Sensor Networks", in Proceedings of the 2nd ACM International Conference on Wireless Sensor Networks and Applications, San Diego, CA, USA, pp. 141- 150, Sept. 19 2003. [I-D.ietf-roll-building-routing-reqs] Martocci, J., Riou, N., Mil, P., and W. Vermeylen, "Building Automation Routing Requirements in Low Power and Lossy Networks", draft-ietf-roll-building-routing-reqs-09 (work in progress), January 2010. [I-D.ietf-roll-home-routing-reqs] Brandt, A. and J. Buron, "Home Automation Routing Requirements in Low Power and Lossy Networks", draft-ietf-roll-home-routing-reqs-11 (work in progress), January 2010. JP> Update the two references above. [I-D.ietf-roll-rpl] Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-07 (work in progress), March 2010. [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-03 (work in progress), March 2010. [I-D.suhopark-hello-wsn] Park, S., "Routing Security in Sensor Network: HELLO Flood Attack and Defense", draft-suhopark-hello-wsn-00 (work in progress), December 2005. [Karlof2003] Karlof, C. and D. Wagner, "Secure routing in wireless sensor networks: attacks and countermeasures", Elsevier Tsao, et al. Expires October 1, 2010 [Page 39] Internet-Draft Security Framework for ROLL March 2010 AdHoc Networks Journal, Special Issue on Sensor Network Applications and Protocols, 1(2):293-315, September 2003. [Messerges2003] Messerges, T., Cukier, J., Kevenaar, T., Puhl, L., Struik, R., and E. Callaway, "Low-Power Security for Wireless Sensor Networks", in Proceedings of the 1st ACM Workshop on Security of Ad Hoc and Sensor Networks, Fairfax, VA, USA, pp. 1-11, Oct. 31 2003. [Myagmar2005] Myagmar, S., Lee, AJ., and W. Yurcik, "Threat Modeling as a Basis for Security Requirements", in Proceedings of the Symposium on Requirements Engineering for Information Security (SREIS'05), Paris, France, pp. 94-102, Aug 29, 2005. [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009. [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009. [Wan2004] Wan, T., Kranakis, E., and PC. van Oorschot, "S-RIP: A Secure Distance Vector Routing Protocol", in Proceedings of the 2nd International Conference on Applied Cryptography and Network Security, Yellow Mountain, China, pp. 103-119, Jun. 8-11 2004. Authors' Addresses Tzeta Tsao (editor) Eka Systems 20201 Century Blvd. Suite 250 Germantown, Maryland 20874 USA Email: tzeta.tsao@ekasystems.com Tsao, et al. Expires October 1, 2010 [Page 40] Internet-Draft Security Framework for ROLL March 2010 Roger K. Alexander (editor) Eka Systems 20201 Century Blvd. Suite 250 Germantown, Maryland 20874 USA Email: roger.alexander@ekasystems.com Mischa Dohler (editor) CTTC Parc Mediterrani de la Tecnologia, Av. Canal Olimpic S/N Castelldefels, Barcelona 08860 Spain Email: mischa.dohler@cttc.es Vanesa Daza (editor) Universitat Pompeu Fabra P/ Circumval.lacio 8, Oficina 308 Barcelona 08003 Spain Email: vanesa.daza@upf.edu Angel Lozano (editor) Universitat Pompeu Fabra P/ Circumval.lacio 8, Oficina 309 Barcelona 08003 Spain Email: angel.lozano@upf.edu JP> Are you all editors ? if so, remove the term "Editors" Tsao, et al. Expires October 1, 2010 [Page 41] -- Ticket URL: roll From root@core3.amsl.com Sun Sep 5 14:15:01 2010 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D0AEF3A6826; Sun, 5 Sep 2010 14:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100905211501.D0AEF3A6826@core3.amsl.com> Date: Sun, 5 Sep 2010 14:15:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 05 Sep 2010 21:15:02 -0000 --NextPart 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 : Routing Metrics used for Path Calculation in Low Power and Lossy Networks Author(s) : J. Vasseur, et al. Filename : draft-ietf-roll-routing-metrics-09.txt Pages : 31 Date : 2010-09-05 Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks that require the specification of new routing metrics and constraints. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing for Low Power and lossy networks (RPL) routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-routing-metrics-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-09-05141152.I-D@ietf.org> --NextPart-- From rstruik.ext@gmail.com Mon Sep 6 06:01:48 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 819CD3A68E3 for ; Mon, 6 Sep 2010 06:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzqrPxTqg-4i for ; Mon, 6 Sep 2010 06:01:47 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 1AA713A67FF for ; Mon, 6 Sep 2010 06:01:46 -0700 (PDT) Received: by iwn3 with SMTP id 3so4790618iwn.31 for ; Mon, 06 Sep 2010 06:02:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:content-type; bh=p+eMrk9CyR6y469PdPHpj6rQaMZBtqhsV/HQ+g0FSw8=; b=c+3OZmRmkz9M4iPZDwQ3PhTtYhevH5biz1yj+6A4FRdwQvda/vtS1nVnNnHhx9ZvE1 7+2ybC6tpAE9URtpZxryjCtJ4a9qvvWyreapsBTC3qROMCrgLwgQskP11p15lUgs2Cao O/oEx1aNrJKzcwOE9zWS5SHUjzO03wGN6sSt0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type; b=NTtxHr3mPF3bpL7Y1i37CV8I6PW1efvq+Hm/kdoDbl70CPL0953OKxM1BQ6e9aUB+o mT1YPgqDAWhrVQuMSwPiQy85WzbFTOjzWfhfHmyyR6LMtEC/ijGapA9Sr11jYf3m4MDf N5i2GT9CEru2AiB/1J3wgOzs3epK1iMbSGbKg= Received: by 10.231.130.99 with SMTP id r35mr5508487ibs.171.1283778135527; Mon, 06 Sep 2010 06:02:15 -0700 (PDT) Received: from [192.168.0.246] ([216.104.121.201]) by mx.google.com with ESMTPS id g31sm5883369ibh.16.2010.09.06.06.02.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 06 Sep 2010 06:02:14 -0700 (PDT) Message-ID: <4C84E64D.7020005@gmail.com> Date: Mon, 06 Sep 2010 09:02:05 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Tzeta Tsao , Roger Alexander , culler , JP Vasseur Content-Type: multipart/alternative; boundary="------------060601050307040504040203" Cc: roll@ietf.org Subject: [Roll] Some comments on draft-ietf-roll-security-framework-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 06 Sep 2010 13:01:48 -0000 This is a multi-part message in MIME format. --------------060601050307040504040203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please find below some comments on the IETF RoLL draft "A Security Framework for Routing over Low Power and Lossy Networks" (draft-ietf-roll-security-framework-00). I did provide comments on an earlier version of this draft (before this was elevated from individual draft to working group draft), but did not check whether these have all been considered, so would encourage the authors to do so (and will be happy to work with them). Comments below are based on giving this a "fresh" look. Section 2, l.1: Networks could be compromised of any mixture of wireless and wired devices, since part of all communication links could be wired (an example of a partially wired network being one with a wireless sensor network that communicates to a wired back-end network via a gateway device). Section 2, l.2-6: The constraints include those on computational resources (RAM, clock speed, storage), communication resources (duty cycle, packet size, etc.), but also form factors that may rule out use of batteries (e.g., the housing of a small stick-on switch), or simply safety considerations (e.g., with gas meters). Section 3, l. -1: The security framework could potentially also be applied outside RoLL (cf. also Section 2 and Section 9). This brings to mind that it could be of interest to relate this effort to IETF draft draft-ietf-opsec-routing-protocols-crypto-issues-07, which discusses routing security issues as well. Section 3.1: Simplistically, security entails implementing measures to ensure controlled state changes on devices and networks only, both based on external inputs (received via communications) or internal inputs (physical security of device itself and parameters maintained by the device, including, e.g., clock). State changes would thereby involve proper authorization for actions, authentication, (potentially) confidentiality), but also proper order of state changes, and, e.g., timeliness (for seriously delayed state changes, such as commands or updates of routing tables, may negatively impact system operation). Section 3, 3rd para: Some routing attacks could be viewed as misrepresenting routing topology (e.g., device closeby/far-off). Section 3.1, Fig. 1: One should perhaps separate route establishment and rout maintenance. Section 3.2: The description of "integrity" seems to encompass authorization as well (l. 6-8). It may be useful to introduce data authenticity (and mention that non repudiation provided by signatures may not be that useful for sensors, but using signatures for source authentication in multicast settings may be). Furthermore, one may benefit from emphasizing that one complements security constructs with security policy enforcement mechanisms (authorization, possibly depending on device role, etc.; acceptance of incoming msgs dependent on policy checks, etc.). Section 3.4, 2nd para below bulletized list, l.3: This reiterates the importance of timeliness aspects. Sectionj 3.4, l. -1: "may be compromised and countered" should read "may be compromised and how this potential compromise is countered". Section 6: Currently, the relationship between Section 6 and Sections 4 and 5 (threat and countermeasure sections) is rather weak, since it seems one can correlate Section 6 to Section 3.4 instead and skip over Sections 4 and 5 (esp. given knowledge of the survey paper by Wagner and Karlof [Karlof2003]). Section 11.2: The references may need updating, since most RoLL-related drafts have seen revisions (or issued as RFC document) since the time of publication of the current draft on March 30, 2010. -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 --------------060601050307040504040203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please find below some comments on the IETF RoLL draft "A Security Framework for Routing over Low Power and Lossy Networks" (draft-ietf-roll-security-framework-00).

I did provide comments on an earlier version of this draft (before this was elevated from individual draft to working group draft), but did not check whether these have all been considered, so would encourage the authors to do so (and will be happy to work with them). Comments below are based on giving this a "fresh" look.

Section 2, l.1:
Networks could be compromised of any mixture of wireless and wired devices, since part of all communication links could be wired (an example of a partially wired network being one with a wireless sensor network that communicates to a wired back-end network via a gateway device).

Section 2, l.2-6:
The constraints include those on computational resources (RAM, clock speed, storage), communication resources (duty cycle, packet size, etc.), but also form factors that may rule out use of batteries (e.g., the housing of a small stick-on switch), or simply safety considerations (e.g., with gas meters).

Section 3, l. -1:
The security framework could potentially also be applied outside RoLL (cf. also Section 2 and Section 9). This brings to mind that it could be of interest to relate this effort to IETF draft draft-ietf-opsec-routing-protocols-crypto-issues-07, which discusses routing security issues as well.
Section 3.1:
Simplistically, security entails implementing measures to ensure controlled state changes on devices and networks only, both based on external inputs (received via communications) or internal inputs (physical security of device itself and parameters maintained by the device, including, e.g., clock). State changes would thereby involve proper authorization for actions, authentication, (potentially) confidentiality), but also proper order of state changes, and, e.g., timeliness (for seriously delayed state changes, such as commands or updates of routing tables, may negatively impact system operation).

Section 3, 3rd para:
 Some routing attacks could be viewed as misrepresenting routing topology (e.g., device closeby/far-off).

Section 3.1, Fig. 1:
One should perhaps separate route establishment and rout maintenance.

Section 3.2:
The description of "integrity" seems to encompass authorization as well (l. 6-8). It may be useful to introduce data authenticity (and mention that non repudiation provided by signatures may not be that useful for sensors, but using signatures for source authentication in multicast settings may be). Furthermore, one may benefit from emphasizing that one complements security constructs with security policy enforcement mechanisms (authorization, possibly depending on device role, etc.; acceptance of incoming msgs dependent on policy checks, etc.).

Section 3.4, 2nd para below bulletized list, l.3:
This reiterates the importance of timeliness aspects.

Sectionj 3.4, l. -1:
"may be compromised and countered" should read "may be compromised and how this potential compromise is countered".

Section 6:
Currently, the relationship between Section 6 and Sections 4 and 5 (threat and countermeasure sections) is rather weak, since it seems one can correlate Section 6 to Section 3.4 instead and skip over Sections 4 and 5 (esp. given knowledge of the survey paper by Wagner and Karlof [Karlof2003]).

Section 11.2:
The references may need updating, since most RoLL-related drafts have seen revisions (or issued as RFC document) since the time of publication of the current draft on March 30, 2010.



 
-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
--------------060601050307040504040203-- From trac@tools.ietf.org Mon Sep 6 15:01:47 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D83D3A6995 for ; Mon, 6 Sep 2010 15:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PARg+a-sCD9G for ; Mon, 6 Sep 2010 15:01:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3D24E3A6992 for ; Mon, 6 Sep 2010 15:01:36 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OsjlM-0003yV-Ob; Mon, 06 Sep 2010 15:02:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Mon, 06 Sep 2010 22:02:04 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/78 Message-ID: <055.56dba789f46f1dc24b6ca59bb855f138@tools.ietf.org> X-Trac-Ticket-ID: 78 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #78: Comments from R. Struik during WG LC of draft-ietf-roll-security-framework X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@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, 06 Sep 2010 22:01:47 -0000 #78: Comments from R. Struik during WG LC of draft-ietf-roll-security-framework --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: tzeta.tsao@… Type: defect | Status: new Priority: major | Milestone: Component: security-framework | Version: Severity: In WG Last Call | Keywords: --------------------------------+------------------------------------------- Please find below some comments on the IETF RoLL draft "A Security Framework for Routing over Low Power and Lossy Networks" (draft-ietf-roll- security-framework-00). I did provide comments on an earlier version of this draft (before this was elevated from individual draft to working group draft), but did not check whether these have all been considered, so would encourage the authors to do so (and will be happy to work with them). Comments below are based on giving this a "fresh" look. Section 2, l.1: Networks could be compromised of any mixture of wireless and wired devices, since part of all communication links could be wired (an example of a partially wired network being one with a wireless sensor network that communicates to a wired back-end network via a gateway device). Section 2, l.2-6: The constraints include those on computational resources (RAM, clock speed, storage), communication resources (duty cycle, packet size, etc.), but also form factors that may rule out use of batteries (e.g., the housing of a small stick-on switch), or simply safety considerations (e.g., with gas meters). Section 3, l. -1: The security framework could potentially also be applied outside RoLL (cf. also Section 2 and Section 9). This brings to mind that it could be of interest to relate this effort to IETF draft draft-ietf-opsec-routing- protocols-crypto-issues-07, which discusses routing security issues as well. Section 3.1: Simplistically, security entails implementing measures to ensure controlled state changes on devices and networks only, both based on external inputs (received via communications) or internal inputs (physical security of device itself and parameters maintained by the device, including, e.g., clock). State changes would thereby involve proper authorization for actions, authentication, (potentially) confidentiality), but also proper order of state changes, and, e.g., timeliness (for seriously delayed state changes, such as commands or updates of routing tables, may negatively impact system operation). Section 3, 3rd para: Some routing attacks could be viewed as misrepresenting routing topology (e.g., device closeby/far-off). Section 3.1, Fig. 1: One should perhaps separate route establishment and rout maintenance. Section 3.2: The description of "integrity" seems to encompass authorization as well (l. 6-8). It may be useful to introduce data authenticity (and mention that non repudiation provided by signatures may not be that useful for sensors, but using signatures for source authentication in multicast settings may be). Furthermore, one may benefit from emphasizing that one complements security constructs with security policy enforcement mechanisms (authorization, possibly depending on device role, etc.; acceptance of incoming msgs dependent on policy checks, etc.). Section 3.4, 2nd para below bulletized list, l.3: This reiterates the importance of timeliness aspects. Sectionj 3.4, l. -1: "may be compromised and countered" should read "may be compromised and how this potential compromise is countered". Section 6: Currently, the relationship between Section 6 and Sections 4 and 5 (threat and countermeasure sections) is rather weak, since it seems one can correlate Section 6 to Section 3.4 instead and skip over Sections 4 and 5 (esp. given knowledge of the survey paper by Wagner and Karlof [Karlof2003]). Section 11.2: The references may need updating, since most RoLL-related drafts have seen revisions (or issued as RFC document) since the time of publication of the current draft on March 30, 2010. -- Ticket URL: roll From trac@tools.ietf.org Mon Sep 6 15:06:00 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 540F03A6998 for ; Mon, 6 Sep 2010 15:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.639 X-Spam-Level: X-Spam-Status: No, score=-101.639 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_20=-0.74, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KR0cHvk3byVf for ; Mon, 6 Sep 2010 15:05:59 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8F7F93A6992 for ; Mon, 6 Sep 2010 15:05:59 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Osjpa-0004lb-45; Mon, 06 Sep 2010 15:06:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dominique.barthel@orange-ftgroup.com, jpv@cisco.com X-Trac-Project: roll Date: Mon, 06 Sep 2010 22:06:25 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/75#comment:2 Message-ID: <064.57907e8295dba65f7c66480c2b7c53ca@tools.ietf.org> References: <055.5ecdc999e878316f774932679577d0fb@tools.ietf.org> X-Trac-Ticket-ID: 75 In-Reply-To: <055.5ecdc999e878316f774932679577d0fb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dominique.barthel@orange-ftgroup.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #75: Option Len Field mismatch in metric doc. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@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, 06 Sep 2010 22:06:00 -0000 #75: Option Len Field mismatch in metric doc. --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: dominique.barthel@… Type: defect | Status: closed Priority: major | Milestone: Component: routing-metrics | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Issue fixed in revision 09. -- Ticket URL: roll From jpv@cisco.com Mon Sep 6 15:08:07 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 064663A6992 for ; Mon, 6 Sep 2010 15:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaL3akXi8yRd for ; Mon, 6 Sep 2010 15:08:06 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0F48D3A699C for ; Mon, 6 Sep 2010 15:08:06 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFoDhUyrRN+J/2dsb2JhbACgcnGiQJsQhT0EhEOFVYJ+ X-IronPort-AV: E=Sophos;i="4.56,327,1280707200"; d="scan'208";a="584465487" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 06 Sep 2010 22:08:34 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o86M8YT2017498; Mon, 6 Sep 2010 22:08:34 GMT Received: from xfe-sjc-221.amer.cisco.com ([128.107.191.32]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Sep 2010 15:08:34 -0700 Received: from [10.2.104.130] ([10.21.125.97]) by xfe-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Sep 2010 15:08:33 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: Date: Mon, 6 Sep 2010 15:08:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: ROLL WG X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 06 Sep 2010 22:08:33.0955 (UTC) FILETIME=[0C183F30:01CB4E10] Cc: vanesa.daza@upf.edu, Roger Alexander , Angel Lozano Subject: Re: [Roll] WG Last Call on draft-ietf-roll-security-framework X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 06 Sep 2010 22:08:07 -0000 Dear WG, The WG Last Call on draft-ietf-roll-security-framework has now ended = (two tickets have been opened to capture the comments). Authors, please = address the comments and post a new revision before publication request. Thanks. JP. On Aug 15, 2010, at 3:25 PM, JP Vasseur wrote: > Dear all, >=20 > draft-ietf-roll-security-framework = (http://datatracker.ietf.org/doc/draft-ietf-roll-security-framework/) = has now been presented and discussed for a while and is ready for WG = Last Call. >=20 > This starts a 3-week Working Group Last Call that will end on = September 6 at 9:00am ET. Please send your comments to the authors and = copy the mailing list. >=20 > Thanks. >=20 > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From rodolfo@ubilogix.com Mon Sep 6 17:45:15 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E20F3A68E2 for ; Mon, 6 Sep 2010 17:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.114 X-Spam-Level: ** X-Spam-Status: No, score=2.114 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3sxBa66eYQP for ; Mon, 6 Sep 2010 17:45:13 -0700 (PDT) Received: from dpmailmta03.doteasy.com (dpmailmta03-16.doteasy.com [65.61.218.56]) by core3.amsl.com (Postfix) with ESMTP id 7BD473A6844 for ; Mon, 6 Sep 2010 17:45:03 -0700 (PDT) Received: from dpmail31pro.doteasy.com ([192.168.101.31]) by dpmailrp06.doteasy.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o870jNNS010183; Mon, 6 Sep 2010 17:45:23 -0700 Received: from 201.143.187.190.dsl.dyn.telnor.net [201.143.187.190] by dpmail31pro.doteasy.com with SMTP; Mon, 6 Sep 2010 17:45:01 -0700 Message-ID: From: "Rodolfo Gonzalez Bernaldez" To: , "ROLL WG" References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com><41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo><4C7D2596.3090108@gridmerge.com> <4C7D6B9A.6050108@gmail.com> <4C7FC901.4050204@gridmerge.com> In-Reply-To: <4C7FC901.4050204@gridmerge.com> Date: Mon, 6 Sep 2010 17:45:03 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0919_01CB4DEB.3C57EE40" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: No geolocation information available for 192.168.101.31 X-CanItPRO-Stream: base:default X-Canit-Stats-ID: 01D3AJnJG - 39b7a611d73c X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.101.86 X-Originating-IP: 192.168.101.86 Subject: Re: [Roll] Current RPL security concerns X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 07 Sep 2010 00:45:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0919_01CB4DEB.3C57EE40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Robert, Alex, all I agree with these proposed treatments for the data, I feel that this = covers most of the questions and issues discussed. If we agree with = this, what remains is to define the text that will be included to the = spec. Sorry for the late replay. Rodolfo. From: Robert Cragie=20 Sent: Thursday, September 02, 2010 8:55 AM To: ROLL WG=20 Subject: [Roll] Current RPL security concerns The previous thread was getting a little difficult to follow so I wanted = to list the current concerns with RPL security as I see them and get the = ball rolling on how we deal with it. Let me know if I haven't summarized = correctly or missed anything. Current concerns: 1.. Placement of the MAC field=20 2.. Order of processing for checksum and MAC=20 3.. Setting of mutable fields 4.. Use of AH instead of RPL security=20 5.. Whether encryption is needed or not=20 Placement of the MAC field AES-CCM concatenates the MAC at the end of the secured data. This is not = particularly clear from the specification. The secured RPL control = message could be shown as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Security . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Base . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Option(s) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . MAC . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Secure RPL Control Message Similar consideration should be given to the signature field. Order of processing for checksum and MAC Given the above packet format, the ICMPv6 checksum needs to be = calculated first on the whole packet according to RFC 4443, with the MAC = field set to 0. At this point the packet is ready for security = processing. Setting of mutable fields Security processing would involve setting the mutable fields to 0 then = running the AES-CCM process according to the level on the packet, = excluding the MAC field. The resulting MAC is then placed in the MAC = field. Use of AH instead of RPL security The use if AH (transport mode) would indeed be possible if it is deemed = that encryption is not necessary. However, the additional paraphernalia = of IPSec needs to be considered too - the security parameters, secure = association etc. What is currently specified in RPL is equivalent and = self-contained. Replay protection is supported through the use of = monotonically increasing or time-based counters. Whether encryption is needed or not The way the spec. is currently written does not mandate encryption as it = can be set in the Security Section.Security Control Field.Level field. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com -------------------------------------------------------------------------= ------- _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_0919_01CB4DEB.3C57EE40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Robert, Alex, all
 
I agree with these proposed treatments = for the=20 data, I feel that this covers most of the questions and issues = discussed. If we=20 agree with this, what remains is to define the text that will be = included to the=20 spec.
 
Sorry for the late replay.
 
Rodolfo.
 
From: Robert Cragie
Sent: Thursday, September 02, 2010 8:55 AM
To: ROLL WG=20
Subject: [Roll] Current RPL security = concerns

The previous thread was getting a little = difficult=20 to follow so I wanted to list the current concerns with RPL security as = I see=20 them and get the ball rolling on how we deal with it. Let me know if I = haven't=20 summarized correctly or missed anything.

Current = concerns:

  1. Placement of the MAC field=20
  2. Order of processing for checksum and MAC=20
  3. Setting of mutable fields
  4. Use of AH instead of RPL security=20
  5. Whether encryption is needed or not

Placement of the MAC field

AES-CCM = concatenates the MAC at the end of the secured data. This is not = particularly=20 clear from the specification. The secured RPL control message could be = shown as=20 follows:

       =20 0            =       =20 1            =       =20 2            =       =20 3
        0 1 2 3 4 5 6 7 8 9 0 1 = 2 3 4 5=20 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;     =20 |     Type     =20 |     Code     =20 |         =20 Checksum           = ; =20 |
      =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;     =20 |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20 |
      =20 .            =             &= nbsp; =20 Security           = ;            =     =20 .
      =20 .            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20 .
      =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;     =20 |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20 |
      =20 .            =             &= nbsp;   =20 Base           &nb= sp;           &nbs= p;     =20 .
      =20 .            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20 .
      =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;     =20 |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20 |
      =20 .            =             &= nbsp; =20 Option(s)          &nbs= p;            = ;   =20 .
      =20 .            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20 .
      =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;     =20 |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20 |
      =20 .            =             &= nbsp;    =20 MAC           &nbs= p;            = ;     =20 .
      =20 .            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20 .
      =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=             &= nbsp;     =20 Figure 7: Secure RPL Control Message

Similar consideration = should be=20 given to the signature field.

Order of = processing for=20 checksum and MAC

Given the above packet format, the ICMPv6 = checksum=20 needs to be calculated first on the whole packet according to RFC 4443, = with the=20 MAC field set to 0. At this point the packet is ready for security=20 processing.

Setting of mutable fields

Security = processing=20 would involve setting the mutable fields to 0 then running the AES-CCM = process=20 according to the level on the packet, excluding the MAC field. The = resulting MAC=20 is then placed in the MAC field.

Use of AH instead of RPL=20 security

The use if AH (transport mode) would indeed be = possible if=20 it is deemed that encryption is not necessary. However, the additional=20 paraphernalia of IPSec needs to be considered too - the security = parameters,=20 secure association etc. What is currently specified in RPL is equivalent = and=20 self-contained. Replay protection is supported through the use of = monotonically=20 increasing or time-based counters.

Whether encryption is = needed or=20 not

The way the spec. is currently written does not mandate=20 encryption as it can be set in the Security Section.Security Control = Field.Level=20 field.

Robert

Robert Cragie (Pacific Gas & Electric)

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

=

_______________________________________________
Roll mailing=20 list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
------=_NextPart_000_0919_01CB4DEB.3C57EE40-- From rodolfo@ubilogix.com Mon Sep 6 17:48:33 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079AB3A6843 for ; Mon, 6 Sep 2010 17:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.102 X-Spam-Level: ** X-Spam-Status: No, score=2.102 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_50=0.001, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFXDg2jYyt7T for ; Mon, 6 Sep 2010 17:48:32 -0700 (PDT) Received: from dpmailmta03.doteasy.com (dpmailmta03-16.doteasy.com [65.61.218.56]) by core3.amsl.com (Postfix) with ESMTP id EDFD93A6839 for ; Mon, 6 Sep 2010 17:48:31 -0700 (PDT) Received: from dpmail31pro.doteasy.com ([192.168.101.31]) by dpmailrp06.doteasy.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o870mmdq010310; Mon, 6 Sep 2010 17:48:48 -0700 Received: from 201.143.187.190.dsl.dyn.telnor.net [201.143.187.190] by dpmail31pro.doteasy.com with SMTP; Mon, 6 Sep 2010 17:48:26 -0700 Message-ID: <2E900F804B524AA1B59DEE358CC47315@ubilogixrodo> From: "Rodolfo Gonzalez Bernaldez" To: "Alexandru Petrescu" , References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> In-Reply-To: <4C811655.5000008@gmail.com> Date: Mon, 6 Sep 2010 17:48:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: No geolocation information available for 192.168.101.31 X-CanItPRO-Stream: base:default X-Canit-Stats-ID: 01D3AMMKk - 64a00b5d197d X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.101.86 X-Originating-IP: 192.168.101.86 Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 07 Sep 2010 00:48:34 -0000 Hello Alex, all > One way I could agree with is something like "Securing RPL messages can > be achieved by: IPsec, link-layer security, and RPL-AES-CCM MAC field in > RPL header; in that order of preference". I know that ROLL is not focusing in any specified link-layer, but if we are in the Low power networks, many of the devices used in this field will be devices with limited hardware features (RAM, ROM, CPU) and given the size of an implementation of IPsec, I think that if we are planning to include IPsec in the RPL specification, we need to be very carefull and consider those limitations. What I mean is that we should include in the spec "... MAY IPsec be used" or "... SHOULD IPsec be used". In this way under certain circumstances, IPsec may not be included. Best regards Rodolfo. -------------------------------------------------- From: "Alexandru Petrescu" Sent: Friday, September 03, 2010 8:37 AM To: Cc: "Rodolfo Gonzalez Bernaldez" ; "Michael Richardson" ; "ROLL WG" Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit > Le 03/09/2010 13:48, Robert Cragie a écrit : > [skipped agreed opinions about IPsec] >>> Reusing the IPsec module ensures a secure system - it's proven by >>> earlier experience. We know it worked ok so why avoid using it. >> >> I don't think the specification of RPL security precludes the >> use of IPSec instead. Does the use of IPSec need to be specified in >> the RPL specification? > > YEs, the RPL specification must say something about security in its > Security Considerations section. That something has to mention > something about IPsec. RPL draft is currently silent about IPsec, AH > and their respective RFCs. Silence about IPsec in the core RPL spec is > not good. > > There are several ways to put this, but IPsec must be there somehow. > > One way I tend to disagree with is to start list all the mutable fields, > mutable but predictable, replay protection, etc. and rebuild that IPsec > behaviour within RPL security. That is a very good first step, but > would it be quick enough to agree on? > > One way I could agree with is something like "Securing RPL messages can > be achieved by: IPsec, link-layer security, and RPL-AES-CCM MAC field in > RPL header; in that order of preference". > > Of course things may vary, if we see some example tendency text I could > say whether I agree or not. > > Alex From alexandru.petrescu@gmail.com Mon Sep 6 23:31:20 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B78FF3A677D for ; Mon, 6 Sep 2010 23:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.825 X-Spam-Level: X-Spam-Status: No, score=-0.825 tagged_above=-999 required=5 tests=[AWL=-1.176, BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZDoj7Hg+gqa for ; Mon, 6 Sep 2010 23:31:19 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id D2E023A6782 for ; Mon, 6 Sep 2010 23:31:18 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o876VjHO008828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Sep 2010 08:31:45 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o876VjPC024707; Tue, 7 Sep 2010 08:31:45 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o876VhEo005065; Tue, 7 Sep 2010 08:31:45 +0200 Message-ID: <4C85DC4F.7030105@gmail.com> Date: Tue, 07 Sep 2010 08:31:43 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Rodolfo Gonzalez Bernaldez References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> <2E900F804B524AA1B59DEE358CC47315@ubilogixrodo> In-Reply-To: <2E900F804B524AA1B59DEE358CC47315@ubilogixrodo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 07 Sep 2010 06:31:20 -0000 Le 07/09/2010 02:48, Rodolfo Gonzalez Bernaldez a écrit : > Hello Alex, all > > >> One way I could agree with is something like "Securing RPL >> messages can be achieved by: IPsec, link-layer security, and >> RPL-AES-CCM MAC field in RPL header; in that order of preference". > > > I know that ROLL is not focusing in any specified link-layer, but if > we are in the Low power networks, many of the devices used in this > field will be devices with limited hardware features (RAM, ROM, CPU) > and given the size of an implementation of IPsec, I think that if we > are planning to include IPsec in the RPL specification, we need to be > very carefull and consider those limitations. I agree. In support of IPsec I can say that there exist very lightweight software implementations of IPsec AH, SAdb and SPdb. Actually I am surprised of the reluctance and fear of large IPsec (paraphernalia?). IPsec AH processing is very simple and does not require much CPU nor memory. The heavy load is on the algorithm proper doing the ciphering rounds - that is CCM, DES or MD4 or what have you. The IPsec (database search, header construction and checking) are very simple and are equivalent in computing power to what RPL MAC computation is right now. IKE (key exchange and generation) is indeed heavy load, tens of additional messages exchanged; but we seem to agree to not include key generation exchange distribution in RPL discussion. > What I mean is that we should include in the spec "... MAY IPsec be > used" or "... SHOULD IPsec be used". In this way under certain > circumstances, IPsec may not be included. I think that way of starting writing the text may sound good. I could agree with it. Alex > > Best regards Rodolfo. > > -------------------------------------------------- From: "Alexandru > Petrescu" Sent: Friday, September 03, > 2010 8:37 AM To: Cc: "Rodolfo Gonzalez > Bernaldez" ; "Michael Richardson" > ; "ROLL WG" Subject: Re: [Roll] > Messg Auth Code covering the mutable IP Hop Limit > >> Le 03/09/2010 13:48, Robert Cragie a écrit : [skipped agreed >> opinions about IPsec] >>>> Reusing the IPsec module ensures a secure system - it's proven >>>> by earlier experience. We know it worked ok so why avoid using >>>> it. >>> >>> I don't think the specification of RPL security precludes >>> the use of IPSec instead. Does the use of IPSec need to be >>> specified in the RPL specification? >> >> YEs, the RPL specification must say something about security in its >> Security Considerations section. That something has to mention >> something about IPsec. RPL draft is currently silent about IPsec, >> AH and their respective RFCs. Silence about IPsec in the core RPL >> spec is not good. >> >> There are several ways to put this, but IPsec must be there >> somehow. >> >> One way I tend to disagree with is to start list all the mutable >> fields, mutable but predictable, replay protection, etc. and >> rebuild that IPsec behaviour within RPL security. That is a very >> good first step, but would it be quick enough to agree on? >> >> One way I could agree with is something like "Securing RPL >> messages can be achieved by: IPsec, link-layer security, and >> RPL-AES-CCM MAC field in RPL header; in that order of preference". >> >> Of course things may vary, if we see some example tendency text I >> could say whether I agree or not. >> >> Alex > > > From alexandru.petrescu@gmail.com Mon Sep 6 23:32:49 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FBCC3A659B for ; Mon, 6 Sep 2010 23:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.812 X-Spam-Level: X-Spam-Status: No, score=-0.812 tagged_above=-999 required=5 tests=[AWL=-1.163, BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ks3iCVTDk59g for ; Mon, 6 Sep 2010 23:32:47 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 85B183A6765 for ; Mon, 6 Sep 2010 23:32:47 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o876XFpC009719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Sep 2010 08:33:15 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o876XEBa025002; Tue, 7 Sep 2010 08:33:15 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o876XEOU005452; Tue, 7 Sep 2010 08:33:14 +0200 Message-ID: <4C85DCAA.3010608@gmail.com> Date: Tue, 07 Sep 2010 08:33:14 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Rodolfo Gonzalez Bernaldez References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com><41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo><4C7D2596.3090108@gridmerge.com> <4C7D6B9A.6050108@gmail.com> <4C7FC901.4050204@gridmerge.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Current RPL security concerns X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 07 Sep 2010 06:32:49 -0000 Le 07/09/2010 02:45, Rodolfo Gonzalez Bernaldez a écrit : > Hi Robert, Alex, all I agree with these proposed treatments for the > data, I feel that this covers most of the questions and issues > discussed. If we agree with this, what remains is to define the text > that will be included to the spec. I agree. I am willing to participate with feedback and text proposal to security discussion in the RPL spec, in order to solve the security concerns we raised. How to proceed further? What should we do? Alex > Sorry for the late replay. Rodolfo. *From:* Robert Cragie > *Sent:* Thursday, September 02, > 2010 8:55 AM *To:* ROLL WG *Subject:* [Roll] > Current RPL security concerns > > The previous thread was getting a little difficult to follow so I > wanted to list the current concerns with RPL security as I see them > and get the ball rolling on how we deal with it. Let me know if I > haven't summarized correctly or missed anything. > > Current concerns: > > 1. Placement of the MAC field 2. Order of processing for checksum and > MAC 3. Setting of mutable fields 4. Use of AH instead of RPL > security 5. Whether encryption is needed or not > > > _Placement of the MAC field_ > > AES-CCM concatenates the MAC at the end of the secured data. This is > not particularly clear from the specification. The secured RPL > control message could be shown as follows: > > 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 > 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Type | Code | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | . Security . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | . Base . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | . Option(s) . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | . MAC . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 7: Secure RPL Control Message > > Similar consideration should be given to the signature field. > > _Order of processing for checksum and MAC_ > > Given the above packet format, the ICMPv6 checksum needs to be > calculated first on the whole packet according to RFC 4443, with the > MAC field set to 0. At this point the packet is ready for security > processing. > > _Setting of mutable fields_ > > Security processing would involve setting the mutable fields to 0 > then running the AES-CCM process according to the level on the > packet, excluding the MAC field. The resulting MAC is then placed in > the MAC field. > > _Use of AH instead of RPL security_ > > The use if AH (transport mode) would indeed be possible if it is > deemed that encryption is not necessary. However, the additional > paraphernalia of IPSec needs to be considered too - the security > parameters, secure association etc. What is currently specified in > RPL is equivalent and self-contained. Replay protection is supported > through the use of monotonically increasing or time-based counters. > > _Whether encryption is needed or not_ > > The way the spec. is currently written does not mandate encryption as > it can be set in the Security Section.Security Control Field.Level > field. > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 > 1924 910888 +1 415 513 0064 http://www.gridmerge.com > > > > ------------------------------------------------------------------------ > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Mon Sep 6 23:40:31 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFED83A6782 for ; Mon, 6 Sep 2010 23:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_05=-1.11, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIgyy2tBK-2I for ; Mon, 6 Sep 2010 23:40:30 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 34B623A659B for ; Mon, 6 Sep 2010 23:40:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o876ei3C014171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 7 Sep 2010 08:40:44 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o876ehbo026587 for ; Tue, 7 Sep 2010 08:40:43 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o876ehiX021313 for ; Tue, 7 Sep 2010 08:40:43 +0200 Message-ID: <4C85DE6B.3020701@gmail.com> Date: Tue, 07 Sep 2010 08:40:43 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] On IPsec CPU and memory requirements X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 07 Sep 2010 06:40:31 -0000 During recent discussions of security concerns of RPL it was mentioned that IPsec could be used to secure the RPL messages. One concern of using IPsec is the reluctance facing its supposedly large requirements on CPU and memory. I think IPsec AH with HMAC and MD4 may not need large computing ressources. Moreover, I think it may need less than AES and RPL with CCM (current RPL spec). Detractor texters of IPsec seem to assume "IPsec" to be: IKE key generation exchange Diffie-Hellman, RC5, firewalls and ACLs, ESP encapsulation. Were it so then I'd agree that that "IPsec" to be too much for little RPL nodes. However, some reduced form of "IPsec" could be just AH header, ICV value containing the CCM (or HMAC-MD4) value, and a data structure containing entries of the form dstaddress-key, and SPI (security parm index). That is very simple and easy to implement, documented, software exists. This kind of "IPsec" would have very little CPU and memory requirements. Alex From alexandru.petrescu@gmail.com Mon Sep 6 23:51:56 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6C1D3A6832 for ; Mon, 6 Sep 2010 23:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.163 X-Spam-Level: X-Spam-Status: No, score=-1.163 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_20=-0.74, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtrOI1QqLVzd for ; Mon, 6 Sep 2010 23:51:56 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id A605A3A682D for ; Mon, 6 Sep 2010 23:51:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o876qMP7002186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 7 Sep 2010 08:52:22 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o876qMeD029487 for ; Tue, 7 Sep 2010 08:52:22 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o876qLp7011137 for ; Tue, 7 Sep 2010 08:52:21 +0200 Message-ID: <4C85E125.8010903@gmail.com> Date: Tue, 07 Sep 2010 08:52:21 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] Unique shared key for the entire RPL network vs Privacy? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 07 Sep 2010 06:51:57 -0000 RPL text often mentions a "shared key", which does not seem to depend on the IP address of the devices to which it is dedicated - is it a single "shared key" across the entire RPL network? This may be an assumption about the keys which ignores privacy. It seems that all node in the RPL network to share the same key, proper to a network; just as a Bluetooth PIN code is shared by all devices in a piconet. There are alternatives to this. For example, a pair of IP communicating nodes may share one key, and everybody else not able to listen to their conversation. This stems from a Privacy requirement. Alex From henning.rogge@fkie.fraunhofer.de Mon Sep 6 23:57:31 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 979CA3A6835 for ; Mon, 6 Sep 2010 23:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.685 X-Spam-Level: X-Spam-Status: No, score=-0.685 tagged_above=-999 required=5 tests=[AWL=-1.941, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVQQ8X3ZUh1U for ; Mon, 6 Sep 2010 23:57:30 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by core3.amsl.com (Postfix) with ESMTP id 1D57F3A682D for ; Mon, 6 Sep 2010 23:57:30 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Oss7x-0007gR-Hs; Tue, 07 Sep 2010 08:57:57 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Oss7x-0004fm-9P; Tue, 07 Sep 2010 08:57:57 +0200 From: Henning Rogge To: roll@ietf.org Date: Tue, 7 Sep 2010 08:57:43 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-24-generic; KDE/4.4.5; i686; ; ) References: <4C85E125.8010903@gmail.com> In-Reply-To: <4C85E125.8010903@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3952769.0PN0xzKGiT"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201009070857.53957.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.96.1/11822/Tue Sep 7 00:49:44 2010) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 9bea0208ff5bf14e461e230ff4736cfe Subject: Re: [Roll] Unique shared key for the entire RPL network vs Privacy? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 07 Sep 2010 06:57:31 -0000 --nextPart3952769.0PN0xzKGiT Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tue September 7 2010 08:52:21 Alexandru Petrescu wrote: > RPL text often mentions a "shared key", which does not seem to depend on > the IP address of the devices to which it is dedicated - is it a single > "shared key" across the entire RPL network? >=20 > This may be an assumption about the keys which ignores privacy. It > seems that all node in the RPL network to share the same key, proper to > a network; just as a Bluetooth PIN code is shared by all devices in a > piconet. > > There are alternatives to this. For example, a pair of IP communicating > nodes may share one key, and everybody else not able to listen to their > conversation. This stems from a Privacy requirement. This adds a LOT complexity to a security schema (and key generation) for a= =20 routing protocol and prevents using symmetric cryptography for broadcasts=20 (unless you want to generate a unique "group key") for every broadcast grou= p. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart3952769.0PN0xzKGiT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkyF4mcACgkQRIfGfFXsz+C1bwCeJ6Fgj/6NCmGN0lxkn1VNrBO2 t1UAoIq9djCZaWh5xb984L79u3XW6dQz =csFq -----END PGP SIGNATURE----- --nextPart3952769.0PN0xzKGiT-- From alexandru.petrescu@gmail.com Tue Sep 7 00:18:50 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D77613A6954 for ; Tue, 7 Sep 2010 00:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.877 X-Spam-Level: X-Spam-Status: No, score=-0.877 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_40=-0.185, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7T-x6S2We06 for ; Tue, 7 Sep 2010 00:18:48 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id B24A93A6900 for ; Tue, 7 Sep 2010 00:18:47 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o877JCNc012871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Sep 2010 09:19:12 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o877JC4k005322; Tue, 7 Sep 2010 09:19:12 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o877JB2i021432; Tue, 7 Sep 2010 09:19:11 +0200 Message-ID: <4C85E76F.5090702@gmail.com> Date: Tue, 07 Sep 2010 09:19:11 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Henning Rogge References: <4C85E125.8010903@gmail.com> <201009070857.53957.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <201009070857.53957.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] Unique shared key for the entire RPL network vs Privacy? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 07 Sep 2010 07:18:50 -0000 Le 07/09/2010 08:57, Henning Rogge a écrit : > On Tue September 7 2010 08:52:21 Alexandru Petrescu wrote: >> RPL text often mentions a "shared key", which does not seem to >> depend on the IP address of the devices to which it is dedicated - >> is it a single "shared key" across the entire RPL network? >> >> This may be an assumption about the keys which ignores privacy. It >> seems that all node in the RPL network to share the same key, >> proper to a network; just as a Bluetooth PIN code is shared by all >> devices in a piconet. >> >> There are alternatives to this. For example, a pair of IP >> communicating nodes may share one key, and everybody else not able >> to listen to their conversation. This stems from a Privacy >> requirement. > > This adds a LOT complexity to a security schema (and key generation) > for a routing protocol and prevents using symmetric cryptography for > broadcasts (unless you want to generate a unique "group key") for > every broadcast group. Hmmm... it is relatively straightforward to use an IPsec Security Association and each node to keep a shared per-destination key (manually installed) (shared between two nodes only). The only issue may be that of the memory size to keep a key per dst. To how many nodes would that scale. Would this memory be worth theprivacy it affords, and the numerous key generation messages it avoids. Secure group communications with dynamically generated keys are indeed harder to achieve - a LOT more complexity and more messages exchanged; but shared key per-network as RPL puts it - symmetric crypto for broadcast addresses as you put it - is a wrong solution. It has many security risks, including privacy. This puts the entire network at the mercy of a single malicious node. This is hardly acceptable. (I do agree with what you seem to imply that the use of symmetric crypto for a multicast group (not broadcast) would indeed be very good here. But I don't think RPL security offers it.) Alex > > Henning Rogge > From libra.andy@gmail.com Tue Sep 7 05:43:56 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FA583A6A0C for ; Tue, 7 Sep 2010 05:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKX32IunHJei for ; Tue, 7 Sep 2010 05:43:55 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 111913A68FE for ; Tue, 7 Sep 2010 05:43:54 -0700 (PDT) Received: by gwb20 with SMTP id 20so2350615gwb.31 for ; Tue, 07 Sep 2010 05:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=0VR0/EN7Y5QPrLPNH80SlDXnaPrD6NkqOzIDWNbxwfY=; b=Wg3JHAKE3ZJGlCtI/rWP4znzExpGtW5sVEuePWih48UKgBt4G4FSbRtWZr37CAImqF SUh0+/k67yOWzYzKcdWMzOOJNHGrJ34N/j4GBZr6euwvLt49txKAJBoIfKh4ab8ZCmFD oXINfZU21gYBOa/FaJx+LFyAxzatOg5up/NrU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ATlz743shK7DRwNlPekFfbOv8tAwQDW98tw1uzCbaCM6HkXXOzIArlu2e39v0QOBnE X31A5GDTcPY7rbSfkErNFpPB3wRbD/68SSIui6JSNMjX88CB8i/82GEiKJr8hHiU+IAJ a0TnQ+XV4ozUcAuN885jk2o317VC804zHTkpg= MIME-Version: 1.0 Received: by 10.100.137.11 with SMTP id k11mr1382477and.103.1283863462951; Tue, 07 Sep 2010 05:44:22 -0700 (PDT) Received: by 10.100.247.11 with HTTP; Tue, 7 Sep 2010 05:44:22 -0700 (PDT) In-Reply-To: <4C85E76F.5090702@gmail.com> References: <4C85E125.8010903@gmail.com> <201009070857.53957.henning.rogge@fkie.fraunhofer.de> <4C85E76F.5090702@gmail.com> Date: Tue, 7 Sep 2010 20:44:22 +0800 Message-ID: From: Andy Zhou To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=0016e645ab24a63bf3048faac176 Cc: roll@ietf.org Subject: Re: [Roll] Unique shared key for the entire RPL network vs Privacy? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 07 Sep 2010 12:43:56 -0000 --0016e645ab24a63bf3048faac176 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It may depend on what level of security you want. In some case, the public shared key is enough to provide the security and privacy. However, it will waste a lot of resource if every node shares a pair-key. I= t also a big challenge to build the pair wise key between the nodes. On Tue, Sep 7, 2010 at 3:19 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Le 07/09/2010 08:57, Henning Rogge a =E9crit : > > On Tue September 7 2010 08:52:21 Alexandru Petrescu wrote: >> >>> RPL text often mentions a "shared key", which does not seem to >>> depend on the IP address of the devices to which it is dedicated - >>> is it a single "shared key" across the entire RPL network? >>> >>> This may be an assumption about the keys which ignores privacy. It >>> seems that all node in the RPL network to share the same key, >>> proper to a network; just as a Bluetooth PIN code is shared by all >>> devices in a piconet. >>> >>> There are alternatives to this. For example, a pair of IP >>> communicating nodes may share one key, and everybody else not able >>> to listen to their conversation. This stems from a Privacy >>> requirement. >>> >> >> This adds a LOT complexity to a security schema (and key generation) >> for a routing protocol and prevents using symmetric cryptography for >> broadcasts (unless you want to generate a unique "group key") for >> every broadcast group. >> > > Hmmm... it is relatively straightforward to use an IPsec > Security Association and each node to keep a shared per-destination key > (manually installed) (shared between two nodes only). > > The only issue may be that of the memory size to keep a key per dst. To > how many nodes would that scale. Would this memory be worth theprivacy > it affords, and the numerous key generation messages it avoids. > > Secure group communications with dynamically generated keys are indeed > harder to achieve - a LOT more complexity and more messages exchanged; > but shared key per-network as RPL puts it - symmetric crypto for > broadcast addresses as you put it - is a wrong solution. It has many > security risks, including privacy. This puts the entire network at > the mercy of a single malicious node. > > This is hardly acceptable. > > (I do agree with what you seem to imply that the use of symmetric crypto > for a multicast group (not broadcast) would indeed be very good here. > But I don't think RPL security offers it.) > > Alex > > >> Henning Rogge >> >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --=20 Thanks & Best Wishes Zhou, Yaowei (Andy) MSN: Libra.andy@hotmail.com --0016e645ab24a63bf3048faac176 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It may depend on what level of security you want. In some case, the public = shared key is enough to provide the security=A0 and privacy.
However, it= will waste a lot of resource if every node shares a pair-key. It also a bi= g challenge=A0 to build the pair wise key between the nodes.


On Tue, Sep 7, 2010 at 3:19 PM, Alexandr= u Petrescu <alexandru.petrescu@gmail.com> wrote:
Le 07/09/2010 08:57, Henning Rogge a =E9crit :

On Tue September 7 2010 08:52:21 Alexandru Petrescu wrote:
RPL text often mentions a "shared key", which does not seem to depend on the IP address of the devices to which it is dedicated -
=A0is it a single "shared key" across the entire RPL network?

This may be an assumption about the keys which ignores privacy. It
seems that all node in the RPL network to share the same key,
proper to a network; just as a Bluetooth PIN code is shared by all
=A0devices in a piconet.

There are alternatives to this. =A0For example, a pair of IP
communicating nodes may share one key, and everybody else not able
=A0to listen to their conversation. =A0This stems from a Privacy
requirement.

This adds a LOT complexity to a security schema (and key generation)
=A0for a routing protocol and prevents using symmetric cryptography for
=A0broadcasts (unless you want to generate a unique "group key") = for
every broadcast group.

Hmmm... it is relatively straightforward to use an IPsec
Security Association and each node to keep a shared per-destination key
(manually installed) (shared between two nodes only).

The only issue may be that of the memory size to keep a key per dst. =A0To<= br> how many nodes would that scale. =A0Would this memory be worth theprivacy it affords, and the numerous key generation messages it avoids.

Secure group communications with dynamically generated keys are indeed
harder to achieve - a LOT more complexity and more messages exchanged;
but shared key per-network as RPL puts it - symmetric crypto for
broadcast addresses as you put it - is a wrong solution. =A0It has many
security risks, including privacy. =A0This puts the entire network at
the mercy of a single malicious node.

This is hardly acceptable.

(I do agree with what you seem to imply that the use of symmetric crypto for a multicast group (not broadcast) would indeed be very good here.
But I don't think RPL security offers it.)

Alex


Henning Rogge



_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll



--
Thanks &= ; Best Wishes

Zhou, Yaowei (Andy)

MSN: Libra.andy@hotmail.com
--0016e645ab24a63bf3048faac176-- From alexandru.petrescu@gmail.com Tue Sep 7 23:36:41 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18E883A6768 for ; Tue, 7 Sep 2010 23:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rdiLCAQDS+5 for ; Tue, 7 Sep 2010 23:36:39 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 7A3203A657C for ; Tue, 7 Sep 2010 23:36:39 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o886b10M022573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Sep 2010 08:37:01 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o886b1SZ016933; Wed, 8 Sep 2010 08:37:01 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o886b0BL022020; Wed, 8 Sep 2010 08:37:01 +0200 Message-ID: <4C872F0C.8000608@gmail.com> Date: Wed, 08 Sep 2010 08:37:00 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Andy Zhou References: <4C85E125.8010903@gmail.com> <201009070857.53957.henning.rogge@fkie.fraunhofer.de> <4C85E76F.5090702@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] Unique shared key for the entire RPL network vs Privacy? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 06:36:41 -0000 Le 07/09/2010 14:44, Andy Zhou a écrit : > It may depend on what level of security you want. In some case, the > public shared key is enough to provide the security and privacy. Hi... would you please mention one such case, with an existing IP protocol? I am personally not aware of any IP protocol using a common shared key between more than two communication ends. > However, it will waste a lot of resource if every node shares a > pair-key. I agree using a key per pair of communicating nodes may need more memory in a node than if only one key were used for the entire network. One particular node would store 1 key if there are two nodes in the network, and n-1 keys if there are n nodes. With a 64bit key and a 100 node network, this would be 800Kbyte memory requirement to store keys. I don't think it is very much. > It also a big challenge to build the pair wise key between the > nodes. I agree. Dynamically generating keys on a per-pair basis may require many messages exchanged - each node would have to develop a security relationship with each other node. However, I assume in a first step to manually configure keys, or to hardcode keys in devices of a deployed network. There is one additional point worth mentioning: it seems an RPL network is relatively static, with devices not moving much. It seems one particular node would communicate directly with only a few other nodes (DAG pictures show a max of 2 or 3). This would involve only a few keys stored. Alex > > > On Tue, Sep 7, 2010 at 3:19 PM, Alexandru Petrescu > > > wrote: > > Le 07/09/2010 08:57, Henning Rogge a écrit : > > On Tue September 7 2010 08:52:21 Alexandru Petrescu wrote: > > RPL text often mentions a "shared key", which does not seem to depend > on the IP address of the devices to which it is dedicated - is it a > single "shared key" across the entire RPL network? > > This may be an assumption about the keys which ignores privacy. It > seems that all node in the RPL network to share the same key, proper > to a network; just as a Bluetooth PIN code is shared by all devices > in a piconet. > > There are alternatives to this. For example, a pair of IP > communicating nodes may share one key, and everybody else not able to > listen to their conversation. This stems from a Privacy > requirement. > > > This adds a LOT complexity to a security schema (and key generation) > for a routing protocol and prevents using symmetric cryptography for > broadcasts (unless you want to generate a unique "group key") for > every broadcast group. > > > Hmmm... it is relatively straightforward to use an IPsec Security > Association and each node to keep a shared per-destination key > (manually installed) (shared between two nodes only). > > The only issue may be that of the memory size to keep a key per dst. > To how many nodes would that scale. Would this memory be worth > theprivacy it affords, and the numerous key generation messages it > avoids. > > Secure group communications with dynamically generated keys are > indeed harder to achieve - a LOT more complexity and more messages > exchanged; but shared key per-network as RPL puts it - symmetric > crypto for broadcast addresses as you put it - is a wrong solution. > It has many security risks, including privacy. This puts the entire > network at the mercy of a single malicious node. > > This is hardly acceptable. > > (I do agree with what you seem to imply that the use of symmetric > crypto for a multicast group (not broadcast) would indeed be very > good here. But I don't think RPL security offers it.) > > Alex > > > Henning Rogge > > > > _______________________________________________ Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > > > -- Thanks & Best Wishes > > Zhou, Yaowei (Andy) > > MSN: Libra.andy@hotmail.com From henning.rogge@fkie.fraunhofer.de Tue Sep 7 23:46:14 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC1723A6768 for ; Tue, 7 Sep 2010 23:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=-0.516, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOKGARq3mCv2 for ; Tue, 7 Sep 2010 23:46:13 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by core3.amsl.com (Postfix) with ESMTP id 6FA303A67AE for ; Tue, 7 Sep 2010 23:46:10 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1OtEQX-0000VA-Pr; Wed, 08 Sep 2010 08:46:37 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1OtEQX-0001Vx-HK; Wed, 08 Sep 2010 08:46:37 +0200 From: Henning Rogge To: Alexandru Petrescu Date: Wed, 8 Sep 2010 08:46:29 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-24-generic; KDE/4.4.5; i686; ; ) References: <4C85E125.8010903@gmail.com> <4C872F0C.8000608@gmail.com> In-Reply-To: <4C872F0C.8000608@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1369808.dyLSCACQth"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201009080846.34422.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.96.1/11841/Wed Sep 8 05:37:41 2010) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 4752504f224081e57c30a21c7b02e935 Cc: roll@ietf.org, Andy Zhou Subject: Re: [Roll] Unique shared key for the entire RPL network vs Privacy? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 06:46:15 -0000 --nextPart1369808.dyLSCACQth Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Wed September 8 2010 08:37:00 Alexandru Petrescu wrote: > With a 64bit key and a 100 node network, this would be 800Kbyte memory > requirement to store keys. I don't think it is very much. You mean 800 bytes. It's more a problem how to create the keys, especially when you extend an=20 existing network and if you need to support rekeying and revokation of keys. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart1369808.dyLSCACQth Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkyHMUUACgkQRIfGfFXsz+CQ0QCaApJgOHyf9ulVXITtO5UTM0Mi yzgAniQ4cN2C+1ELJjeFx7ccnO8TcaFN =EdS/ -----END PGP SIGNATURE----- --nextPart1369808.dyLSCACQth-- From alexandru.petrescu@gmail.com Tue Sep 7 23:52:48 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EDDB3A67AE; Tue, 7 Sep 2010 23:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.924 X-Spam-Level: X-Spam-Status: No, score=-0.924 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_FROM=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WR4-iC4j+Fq; Tue, 7 Sep 2010 23:52:46 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 9950A3A6768; Tue, 7 Sep 2010 23:52:46 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o886rDkS018596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Sep 2010 08:53:13 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o886rDu9020484; Wed, 8 Sep 2010 08:53:13 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o886rDgX026638; Wed, 8 Sep 2010 08:53:13 +0200 Message-ID: <4C8732D9.5010809@gmail.com> Date: Wed, 08 Sep 2010 08:53:13 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: ietf@ietf.org References: <20100818222846.13825.49680.idtracker@localhost> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG , draft-ietf-roll-rpl@tools.ietf.org, roll-chairs@tools.ietf.org Subject: Re: [Roll] Last Call: (RPL: IPv6 Routing Protocol for Low power and Lossy Networks) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 06:52:48 -0000 Le 03/09/2010 07:54, Pekka Savola a écrit : > On Wed, 18 Aug 2010, The IESG wrote: >> The IESG has received a request from the Routing Over Low power and >> Lossy networks WG (roll) to consider the following document: - >> 'RPL: IPv6 Routing Protocol for Low power and Lossy Networks' >> as a Proposed Standard > > I've done a solicited but superficial ops-dir review of > draft-ietf-roll-rpl-11. Given the document length (139p) I've had to > skim most of it. The IETF Last Call expired two days ago, but for > information I'm still copying the IETF list, even though this review > is mainly for O&M ADs' and secondarily ROLL WG benefit. > > A couple of comments: > > In general, ROLL problem space seems to be very similar to MANETs, > and I wonder why a separate protocol needed to be developed here, > especially given the amount of scientific research and also IETF > effort put into MANETs. ROLL WG charter certainly does not mention > this. I think this comment makes sense. There was an important draft at some point discussing why MANET protocols are not enough and why new protocol was needed. That WG item was used to motivate the new at that time ROLL Charter requesting a new protocol design. However, that draft was discard soon after and not revived. I believe that was an error: WG items are never dropped, even less when they're used to motivate further Charterer work. That can still be corrected (revive draft-ietf-roll-protocols-survey-07). > Copying/modifying various IPv6 ND options for this purpose may be > required but I wonder if this could have been done in a simpler > fashion, without having to copy the specifications here. For example, > using a TLV container option that includes non-TLV options as-is. > > The document mentions uniquely identifying a DODAG by the use of an > IPv6 address. The document does not mention what addresses are to be > used for this purpose, how they are assigned, and how these are > expected to be unique. (Compare to documents on MANET IPv6 address > assignments.) I agree the document is not very clear about how address configuration is performed. For example, it says nothing about the use of link-local addresses - this silence is very wrong. Another potential error lies in this RPL text: > Prefix Length 8-bit unsigned integer. The number of leading bits > in the Prefix that are valid. The value ranges from 0 to 128. The > prefix length field provides necessary information for on- link > determination (when combined with the L flag in the prefix > information option). It also assists with address autoconfiguration > as specified in [RFC4862], for which there may be more restrictions > on the prefix length. Does this mean that the prefix in a DIO is used for address autoconfiguration, instead of a PIO in rfc4861? I guess yes, and it is wrong, because it is a new address autoconfiguration mechanism and it says nothing about how it interacts with the old. > In S 11 on Packet Forwarding: > > 1. This specification only covers how a successor is selected from > the DODAG Version that matches the RPLInstanceID marked in the IPv6 > header of the packet being forwarded. [...] > > ... How is RPLInstanceID marked in the IPv6 header of the packet > being forwarded? Are you modifying IPv6 packet forwarding and > processing algorithms here (must look into the packets)? That would > be a major change. (You're really referring to the hop-by-hop header > processing here.) > > In general the document doesn't seem to be sufficiently upfront on > the basic semantics how RPL is going to be used (from "non-RPL" > perspective). I agree! The RPL protocol seems to be designed for a non-Internet network. It seems to need more refinement before interoperating with other IPv6 nodes. Alex > One could argue Section 3 (some 12 pages) tries to provide an > overview, but from IP perspective, it provides too much detail on > e.g. tree forming and maintenance. The most important things to > bring up clearly should be for example: (1) are there changes to > existing packet formats or usage (e.g. does every packet include some > kind of header, does this affect MTU usable in the network)?, (2) is > support for these required at each node in the network, (3) are > there changes to the basic packet processing in associated nodes? > > Upon closer inspection, some answers to these high-level questions > can be found in first paragraph of S 3.3.7 and the last paragraph of > S 5, but I'd really have wanted to see one or two paragraphs in > Introduction. > > ... > > It is a bit strange to see that S 17 on manageability does not > mention security management, because one of the key problems there > (as argued in the draft as well) is how do you manually configure and > maintain shared keys on all these devices. > > _______________________________________________ Ietf mailing list > Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf > From alexandru.petrescu@gmail.com Wed Sep 8 00:00:43 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D0483A67B6 for ; Wed, 8 Sep 2010 00:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5npZZRE8qS4 for ; Wed, 8 Sep 2010 00:00:42 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 24F043A659A for ; Wed, 8 Sep 2010 00:00:41 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o88714qD009738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Sep 2010 09:01:04 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o88714O1022826; Wed, 8 Sep 2010 09:01:04 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o88713Iw008138; Wed, 8 Sep 2010 09:01:04 +0200 Message-ID: <4C8734AF.6090605@gmail.com> Date: Wed, 08 Sep 2010 09:01:03 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Henning Rogge References: <4C85E125.8010903@gmail.com> <4C872F0C.8000608@gmail.com> <201009080846.34422.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <201009080846.34422.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org, Andy Zhou Subject: Re: [Roll] Unique shared key for the entire RPL network vs Privacy? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 07:00:43 -0000 Le 08/09/2010 08:46, Henning Rogge a écrit : > On Wed September 8 2010 08:37:00 Alexandru Petrescu wrote: >> With a 64bit key and a 100 node network, this would be 800Kbyte >> memory requirement to store keys. I don't think it is very much. > > You mean 800 bytes. Right, thanks. 800bytes is even less than 800kbyte, which is better news. > It's more a problem how to create the keys, especially when you > extend an existing network and if you need to support rekeying and > revokation of keys. I agree fully: dynamically generating these keys, rekeying upon network expansion, key revocation - are all much harder to do when per-pair keys are used (instead of a single per-network key). The dynamic generation of a single key for the entire network, its revocation and regeneration - is also difficult to do. However, I think it is good to clarify whether we look at this in a perspective where - now - the dynamic key generation is out of scope and only manual configuration, administrative key provisioning, hardcoded keys, preinstalled keys are in scope. Alex > > Henning Rogge > From prvs=860e1a20e=bora@pnl.gov Wed Sep 8 08:57:33 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19BD3A68DC for ; Wed, 8 Sep 2010 08:57:32 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDMZKzyERIGt for ; Wed, 8 Sep 2010 08:57:28 -0700 (PDT) Received: from emailgw03.pnl.gov (emailgw03.pnl.gov [192.101.109.31]) by core3.amsl.com (Postfix) with ESMTP id 712523A697B for ; Wed, 8 Sep 2010 08:57:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,335,1280732400"; d="scan'208";a="27470890" Received: from emailhub02.pnl.gov ([130.20.251.62]) by emailgw03.pnl.gov with ESMTP/TLS/AES128-SHA; 08 Sep 2010 08:57:56 -0700 Received: from Email05.pnl.gov ([169.254.1.114]) by emailhub02.pnl.gov ([130.20.251.62]) with mapi; Wed, 8 Sep 2010 08:57:56 -0700 From: "Akyol, Bora A" To: Alexandru Petrescu Date: Wed, 8 Sep 2010 08:57:55 -0700 Thread-Topic: [Roll] Unique shared key for the entire RPL network vs Privacy? Thread-Index: ActPbpoLAixxNsJHTzqu7ke3je22kw== Message-ID: <96CEE5A6-74A6-4F1C-8553-2523E0808743@pnl.gov> References: <4C85E125.8010903@gmail.com> <201009070857.53957.henning.rogge@fkie.fraunhofer.de> <4C85E76F.5090702@gmail.com> <4C872F0C.8000608@gmail.com> In-Reply-To: <4C872F0C.8000608@gmail.com> 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" , Andy Zhou Subject: Re: [Roll] Unique shared key for the entire RPL network vs Privacy? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 15:57:33 -0000 Do you mean GDOI does not fit the bill? http://www.ietf.org/rfc/rfc3547.txt On Sep 7, 2010, at 11:37 PM, Alexandru Petrescu wrote: > Le 07/09/2010 14:44, Andy Zhou a =E9crit : >> It may depend on what level of security you want. In some case, the >> public shared key is enough to provide the security and privacy. >=20 > Hi... would you please mention one such case, with an existing IP > protocol? I am personally not aware of any IP protocol using a common > shared key between more than two communication ends. From alexandru.petrescu@gmail.com Wed Sep 8 09:16:22 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF973A68AD for ; Wed, 8 Sep 2010 09:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLGebR-FMP4D for ; Wed, 8 Sep 2010 09:16:21 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id A4D7F3A69A9 for ; Wed, 8 Sep 2010 09:15:38 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o88GG53O017149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Sep 2010 18:16:05 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o88GG5nr019764; Wed, 8 Sep 2010 18:16:05 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o88GG4bL029696; Wed, 8 Sep 2010 18:16:04 +0200 Message-ID: <4C87B6C4.4050301@gmail.com> Date: Wed, 08 Sep 2010 18:16:04 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: "Akyol, Bora A" References: <4C85E125.8010903@gmail.com> <201009070857.53957.henning.rogge@fkie.fraunhofer.de> <4C85E76F.5090702@gmail.com> <4C872F0C.8000608@gmail.com> <96CEE5A6-74A6-4F1C-8553-2523E0808743@pnl.gov> In-Reply-To: <96CEE5A6-74A6-4F1C-8553-2523E0808743@pnl.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "roll@ietf.org" , Andy Zhou Subject: Re: [Roll] Unique shared key for the entire RPL network vs Privacy? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 16:16:22 -0000 That GDOI is for group communications of Security Associations of IPsec, right? It could probably work for RPL. It would need SAs to work, which I could agree to. I wonder which other protocol uses these group keys and SAs. (like for example is DHCP protected by GDOI? Or is some proprietary video streaming protocol protected by GDOI?). Alex Le 08/09/2010 17:57, Akyol, Bora A a écrit : > Do you mean GDOI does not fit the bill? > > http://www.ietf.org/rfc/rfc3547.txt > > > > On Sep 7, 2010, at 11:37 PM, Alexandru Petrescu wrote: > >> Le 07/09/2010 14:44, Andy Zhou a écrit : >>> It may depend on what level of security you want. In some case, >>> the public shared key is enough to provide the security and >>> privacy. >> >> Hi... would you please mention one such case, with an existing IP >> protocol? I am personally not aware of any IP protocol using a >> common shared key between more than two communication ends. > > From prvs=860e1a20e=bora@pnl.gov Wed Sep 8 09:19:04 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC01D3A68DC for ; Wed, 8 Sep 2010 09:19:04 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISK1KC8MW2pJ for ; Wed, 8 Sep 2010 09:19:03 -0700 (PDT) Received: from emailgw03.pnl.gov (emailgw03.pnl.gov [192.101.109.31]) by core3.amsl.com (Postfix) with ESMTP id 6EA923A6962 for ; Wed, 8 Sep 2010 09:18:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,335,1280732400"; d="scan'208";a="27473040" Received: from emailhub01.pnl.gov ([130.20.251.61]) by emailgw03.pnl.gov with ESMTP/TLS/AES128-SHA; 08 Sep 2010 09:19:23 -0700 Received: from Email05.pnl.gov ([169.254.1.114]) by emailhub01.pnl.gov ([130.20.251.61]) with mapi; Wed, 8 Sep 2010 09:19:23 -0700 From: "Akyol, Bora A" To: Alexandru Petrescu , "bew@cisco.com" Date: Wed, 8 Sep 2010 09:19:22 -0700 Thread-Topic: [Roll] Unique shared key for the entire RPL network vs Privacy? Thread-Index: ActPcZkLj3VvApq2QzSmeCpnteCNFQ== Message-ID: <3DA16EC4-738A-45A0-94BF-D73A22FE11F1@pnl.gov> References: <4C85E125.8010903@gmail.com> <201009070857.53957.henning.rogge@fkie.fraunhofer.de> <4C85E76F.5090702@gmail.com> <4C872F0C.8000608@gmail.com> <96CEE5A6-74A6-4F1C-8553-2523E0808743@pnl.gov> <4C87B6C4.4050301@gmail.com> In-Reply-To: <4C87B6C4.4050301@gmail.com> 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" , Andy Zhou Subject: Re: [Roll] Unique shared key for the entire RPL network vs Privacy? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 16:19:05 -0000 GDOI establishes group-wise keys that can be used for multi-party communica= tion. This way you will not need N^2 SAs in storage and the shared key can be rek= eyed quickly. I cc-d Brian Weis to comment further on this as he is the expert on this. Regards Bora On Sep 8, 2010, at 9:16 AM, Alexandru Petrescu wrote: > That GDOI is for group communications of Security Associations of IPsec, > right? It could probably work for RPL. It would need SAs to work, > which I could agree to. >=20 > I wonder which other protocol uses these group keys and SAs. (like for > example is DHCP protected by GDOI? Or is some proprietary video > streaming protocol protected by GDOI?). >=20 > Alex >=20 > Le 08/09/2010 17:57, Akyol, Bora A a =E9crit : >> Do you mean GDOI does not fit the bill? >>=20 >> http://www.ietf.org/rfc/rfc3547.txt >>=20 >>=20 >>=20 >> On Sep 7, 2010, at 11:37 PM, Alexandru Petrescu wrote: >>=20 >>> Le 07/09/2010 14:44, Andy Zhou a =E9crit : >>>> It may depend on what level of security you want. In some case, >>>> the public shared key is enough to provide the security and >>>> privacy. >>>=20 >>> Hi... would you please mention one such case, with an existing IP >>> protocol? I am personally not aware of any IP protocol using a >>> common shared key between more than two communication ends. >>=20 >>=20 >=20 >=20 From mcr@sandelman.ca Wed Sep 8 10:09:05 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0E093A67B3 for ; Wed, 8 Sep 2010 10:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.757 X-Spam-Level: X-Spam-Status: No, score=-1.757 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pf58OlXYp14R for ; Wed, 8 Sep 2010 10:09:04 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id EEDBC3A6807 for ; Wed, 8 Sep 2010 10:09:03 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id C103A34740; Wed, 8 Sep 2010 13:09:31 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id E5E5C98A9F; Wed, 8 Sep 2010 13:09:30 -0400 (EDT) From: Michael Richardson To: Alexandru Petrescu In-Reply-To: <4C872F0C.8000608@gmail.com> References: <4C85E125.8010903@gmail.com> <201009070857.53957.henning.rogge@fkie.fraunhofer.de> <4C85E76F.5090702@gmail.com> <4C872F0C.8000608@gmail.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 08 Sep 2010 13:09:30 -0400 Message-ID: <22303.1283965770@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org, Andy Zhou Subject: Re: [Roll] Unique shared key for the entire RPL network vs Privacy? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 17:09:05 -0000 >>>>> "Alexandru" =3D=3D Alexandru Petrescu = writes: Alexandru> Le 07/09/2010 14:44, Andy Zhou a =E9crit : >> It may depend on what level of security you want. In some case, >> the public shared key is enough to provide the security and >> privacy. Alexandru> Hi... would you please mention one such case, with an Alexandru> existing IP protocol? I am personally not aware of any Alexandru> IP protocol using a common shared key between more than Alexandru> two communication ends. multicast IPsec. --=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 From pal@cs.stanford.edu Wed Sep 8 10:14:18 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11DCE3A6885 for ; Wed, 8 Sep 2010 10:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.383 X-Spam-Level: X-Spam-Status: No, score=-6.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjLeiOLsV+FT for ; Wed, 8 Sep 2010 10:14:16 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id AF2D33A67B3 for ; Wed, 8 Sep 2010 10:14:16 -0700 (PDT) Received: from dn0a210364.sunet ([10.33.3.100]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OtOBU-00073X-An; Wed, 08 Sep 2010 10:11:44 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Philip Levis In-Reply-To: <4C811655.5000008@gmail.com> Date: Wed, 8 Sep 2010 09:15:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <519A78D0-77BC-466C-BAFF-084DEF5D9CB5@cs.stanford.edu> References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) X-Scan-Signature: acf3039aa8d32d1ac60a71149e52b94c Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 17:14:18 -0000 On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote: > Le 03/09/2010 13:48, Robert Cragie a =E9crit : > [skipped agreed opinions about IPsec] >>> Reusing the IPsec module ensures a secure system - it's proven by >>> earlier experience. We know it worked ok so why avoid using it. >>=20 >> I don't think the specification of RPL security precludes the >> use of IPSec instead. Does the use of IPSec need to be specified in >> the RPL specification? >=20 > YEs, the RPL specification must say something about security in its > Security Considerations section. That something has to mention > something about IPsec.=20 Why does it have to do so? In theory, RPL should be entirely independent = of IPSec. There have already been numerous discussions about why simply = relying on IPSec would be problematic. Unfortunately you seem to forget = these points every few weeks and rehash the same discussion. At some = point it becomes a waste of everyone's time. Phil= From pal@cs.stanford.edu Wed Sep 8 10:14:22 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E1A53A6888 for ; Wed, 8 Sep 2010 10:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.391 X-Spam-Level: X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WD0UQwrOSr5I for ; Wed, 8 Sep 2010 10:14:19 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 5390E3A67A6 for ; Wed, 8 Sep 2010 10:14:19 -0700 (PDT) Received: from dn0a210364.sunet ([10.33.3.100]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OtOBQ-00073X-Se; Wed, 08 Sep 2010 10:11:41 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4C7D6B9A.6050108@gmail.com> Date: Wed, 8 Sep 2010 09:04:54 -0700 Content-Transfer-Encoding: 7bit Message-Id: <08D94BE0-6FBD-41CB-9038-40C1F1A95A45@cs.stanford.edu> References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D2596.3090108@gridmerge.com> <4C7D6B9A.6050108@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 5fb79390a4aad79c01ba7e4883e5f1df Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 17:14:22 -0000 On Aug 31, 2010, at 1:52 PM, Alexandru Petrescu wrote: >> > > I think it would be good to agree whether encryption is absolutely > needed in RPL or considered as luxury, assuming that encryption would > take more computing power than very simple authentication. Alex, please go read the application requirement documents. Phil From pal@cs.stanford.edu Wed Sep 8 10:14:25 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29D043A68B5 for ; Wed, 8 Sep 2010 10:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g62cb3Kp811R for ; Wed, 8 Sep 2010 10:14:23 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id E87593A67A6 for ; Wed, 8 Sep 2010 10:14:22 -0700 (PDT) Received: from dn0a210364.sunet ([10.33.3.100]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OtOBR-00073X-UR; Wed, 08 Sep 2010 10:11:42 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4C7FFAA1.7000800@gmail.com> Date: Wed, 8 Sep 2010 09:10:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D2596.3090108@gridmerge.com> <4C7D6B9A.6050108@gmail.com> <8A2FA3C50EC246D7AA6C415F501D8D9C@ubilogixrodo> <4C7FFAA1.7000800@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 2d1a4fa5d0150c38835749a59b44c419 Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 17:14:25 -0000 On Sep 2, 2010, at 12:27 PM, Alexandru Petrescu wrote: >>=20 >> Yes I agree we still need to define when the use of security is >> mandatory or optional. I'm not sure what you mean? >=20 > I meant to say whether authentication is mandatory (vs encryption = which > would be less mandatory). I agree security overall should be taken = into > account, but security has authentication and encryption aspects; auth > and enc typically require different levels of computing power, I = think. >=20 >> I quote, "assuming that encryption would take more computing power >> than very simple authentication", if we handled the CBC-MAC as is >> defined be the standard, at the transceiver IEEE 802.15.4-2006 with >> hardware security support could do this without draining to much >> power from the battery. >=20 > Would encryption draw more power than authentication? And compute > cycles? If one is cheaper than the other in these terms then I = believe > it should be preferred. Alex, I don't think this is a helpful thread of discussion. It all = depends on the algorithms; some authentication/integrity mechanisms are = computationally intensive, while others are cheap. The same is true for = encryption. It is trivial to choose a pair of algorithms such that = authentication is more expensive or a different pair of algorithms such = that encryption is more expensive. This thread of thought is bad engineering design; based on a = hypothetical belief of particular tradeoffs, it it argues for design = decisions that have significant application-level implications. Phil= From alexandru.petrescu@gmail.com Wed Sep 8 10:26:07 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01B073A67B1 for ; Wed, 8 Sep 2010 10:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S50TcuVZ1I7x for ; Wed, 8 Sep 2010 10:26:06 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id BE52D3A67A6 for ; Wed, 8 Sep 2010 10:26:05 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o88HQNYg028905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Sep 2010 19:26:23 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o88HQMe3028762; Wed, 8 Sep 2010 19:26:23 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o88HQMnY009128; Wed, 8 Sep 2010 19:26:22 +0200 Message-ID: <4C87C73E.1040806@gmail.com> Date: Wed, 08 Sep 2010 19:26:22 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Philip Levis References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> <519A78D0-77BC-466C-BAFF-084DEF5D9CB5@cs.stanford.edu> In-Reply-To: <519A78D0-77BC-466C-BAFF-084DEF5D9CB5@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 17:26:07 -0000 Le 08/09/2010 18:15, Philip Levis a écrit : > > On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote: > >> Le 03/09/2010 13:48, Robert Cragie a écrit : [skipped agreed >> opinions about IPsec] >>>> Reusing the IPsec module ensures a secure system - it's proven >>>> by earlier experience. We know it worked ok so why avoid using >>>> it. >>> >>> I don't think the specification of RPL security precludes >>> the use of IPSec instead. Does the use of IPSec need to be >>> specified in the RPL specification? >> >> YEs, the RPL specification must say something about security in its >> Security Considerations section. That something has to mention >> something about IPsec. > > Why does it have to do so? In theory, RPL should be entirely > independent of IPSec. There have already been numerous discussions > about why simply relying on IPSec would be problematic. > Unfortunately you seem to forget these points every few weeks and > rehash the same discussion. At some point it becomes a waste of > everyone's time. Phil - if RPL says "security" then it must understand that Internet security is usually IPsec. This is truer with IPv6 (as opposed to IPv4) where IPsec is very much integrated in the design (mutable fields, etc.) Have you checked the mutable field discussion? Do you agree that mutable fields must be taken into account? Please read that around 3 people agreed on a list of items which are worth discussion of security and IPsec - mutable fields is one such item. As such this discussion is not a waste of everyone's time. Alex > > Phil From alexandru.petrescu@gmail.com Wed Sep 8 10:29:22 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4B233A67A6 for ; Wed, 8 Sep 2010 10:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qih9UCxIjJTc for ; Wed, 8 Sep 2010 10:29:21 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 5E55E3A688E for ; Wed, 8 Sep 2010 10:29:21 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o88HThdX030260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Sep 2010 19:29:43 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o88HThp4028938; Wed, 8 Sep 2010 19:29:43 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o88HTgA2009486; Wed, 8 Sep 2010 19:29:43 +0200 Message-ID: <4C87C806.2040100@gmail.com> Date: Wed, 08 Sep 2010 19:29:42 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Philip Levis References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D2596.3090108@gridmerge.com> <4C7D6B9A.6050108@gmail.com> <8A2FA3C50EC246D7AA6C415F501D8D9C@ubilogixrodo> <4C7FFAA1.7000800@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 17:29:22 -0000 Le 08/09/2010 18:10, Philip Levis a écrit : > On Sep 2, 2010, at 12:27 PM, Alexandru Petrescu wrote: > >>> >>> Yes I agree we still need to define when the use of >>> security is mandatory or optional. I'm not sure what you mean? >> >> I meant to say whether authentication is mandatory (vs encryption >> which would be less mandatory). I agree security overall should be >> taken into account, but security has authentication and encryption >> aspects; auth and enc typically require different levels of >> computing power, I think. >> >>> I quote, "assuming that encryption would take more computing >>> power than very simple authentication", if we handled the CBC-MAC >>> as is defined be the standard, at the transceiver IEEE >>> 802.15.4-2006 with hardware security support could do this >>> without draining to much power from the battery. >> >> Would encryption draw more power than authentication? And compute >> cycles? If one is cheaper than the other in these terms then I >> believe it should be preferred. > > Alex, I don't think this is a helpful thread of discussion. It all > depends on the algorithms; some authentication/integrity mechanisms > are computationally intensive, while others are cheap. This is right. > The same is true for encryption. It is trivial to choose a pair of > algorithms such that authentication is more expensive or a different > pair of algorithms such that encryption is more expensive. At the same level of computing power I think it is safer to assume better authentication protection than encryption. > This thread of thought is bad engineering design; Phil - please read about the mutable field discussion. Please understand that the current RPL spec is flawed with respect to security, at least because it does not say how the mutable fields are computed. Alex > based on a hypothetical belief of particular tradeoffs, it it argues > for design decisions that have significant application-level > implications. > > Phil From pal@cs.stanford.edu Wed Sep 8 10:48:43 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65A13A677C for ; Wed, 8 Sep 2010 10:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.404 X-Spam-Level: X-Spam-Status: No, score=-6.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLH-USrnRyI6 for ; Wed, 8 Sep 2010 10:48:42 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id EA4643A694F for ; Wed, 8 Sep 2010 10:47:55 -0700 (PDT) Received: from dn0a210364.sunet ([10.33.3.100]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OtOBT-00073X-3p; Wed, 08 Sep 2010 10:11:43 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4C80B91E.2050200@gridmerge.com> Date: Wed, 8 Sep 2010 09:13:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9FF16CF7-13F1-47A3-AA91-758EC4395198@cs.stanford.edu> References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 980022258218d8e0da9e8fd80fb6777b Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 17:48:43 -0000 On Sep 3, 2010, at 2:00 AM, Robert Cragie wrote: > > 1. The discussion is in the context of ROLL, so the type of network is = lossy and low power. 802.15.4 is a specific type of lossy and low power = network. Therefore the draft should not refer specifically to 802.15.4 = networks but to lossy and low power networks, which it does. > 2. RPL security has nothing to do with 802.15.4 MAC security. They are = totally independent. A secured RPL frame with a MIC will just be payload = in an unsecured MAC frame, whatever that MAC happens to be. > Yes, both are 100% correct and I agree with #1 completely. > RPL security is only used for securing RPL control messages. It = is not used for securing data messages conveyed through a RPL DODAG; = alternative security needs to be used, which could be link layer, IPSec, = TLS etc. RPL control messages will not go beyond the DODAG root. So the = scenario you are talking about will never happen wrt. RPL = security. Correct. I personally feel that much of this discussion comes from = Alex's misunderstanding of the protocol and its design considerations. Phil= From pal@cs.stanford.edu Wed Sep 8 10:51:29 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C2B63A6836 for ; Wed, 8 Sep 2010 10:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lbx-rZ6YTs8z for ; Wed, 8 Sep 2010 10:51:26 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id AE9723A66B4 for ; Wed, 8 Sep 2010 10:51:25 -0700 (PDT) Received: from dn0a210364.sunet ([10.33.3.100]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OtOBV-00073X-Lo; Wed, 08 Sep 2010 10:11:45 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Philip Levis In-Reply-To: <4C85DC4F.7030105@gmail.com> Date: Wed, 8 Sep 2010 09:20:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5EE6D4AF-05B6-474E-BF4C-890BFA74A676@cs.stanford.edu> References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> <2E900F804B524AA1B59DEE358CC47315@ubilogixrodo> <4C85DC4F.7030105@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 2d1a4fa5d0150c38835749a59b44c419 Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 17:51:29 -0000 On Sep 6, 2010, at 11:31 PM, Alexandru Petrescu wrote: > Le 07/09/2010 02:48, Rodolfo Gonzalez Bernaldez a =E9crit : >> Hello Alex, all >>=20 >> >>> One way I could agree with is something like "Securing RPL >>> messages can be achieved by: IPsec, link-layer security, and >>> RPL-AES-CCM MAC field in RPL header; in that order of preference". >> >>=20 >> I know that ROLL is not focusing in any specified link-layer, but if >> we are in the Low power networks, many of the devices used in this >> field will be devices with limited hardware features (RAM, ROM, CPU) >> and given the size of an implementation of IPsec, I think that if we >> are planning to include IPsec in the RPL specification, we need to be >> very carefull and consider those limitations. >=20 > I agree. In support of IPsec I can say that there exist very > lightweight software implementations of IPsec AH, SAdb and SPdb. > Actually I am surprised of the reluctance and fear of large IPsec > (paraphernalia?). Lightweight in the context of 32-bit architectures with >100 MHz = processors, or lightweight in the context of (much weaker) LLN class = devices?=20 Alex, RPL is past last call. Based on the security requirements laid out = by the application drafts, and experience from people who have built = secured LLN networks, the conclusion was that simply applying IPSec was = not a good solution. Please review the numerous prior discussions on = this topic. If you strongly believe that RPL should use IPSec, then you = should write a draft describing exactly how it works, so that we can = have a technical, rather than ideological, discussion. Phil= From alexandru.petrescu@gmail.com Wed Sep 8 13:43:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB4703A684A for ; Wed, 8 Sep 2010 13:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkV1mxr+T53K for ; Wed, 8 Sep 2010 13:43:32 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 651813A682F for ; Wed, 8 Sep 2010 13:43:30 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 76EC4940041; Wed, 8 Sep 2010 22:43:53 +0200 (CEST) Message-ID: <4C87F587.3020100@gmail.com> Date: Wed, 08 Sep 2010 22:43:51 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Michael Richardson References: <4C85E125.8010903@gmail.com> <201009070857.53957.henning.rogge@fkie.fraunhofer.de> <4C85E76F.5090702@gmail.com> <4C872F0C.8000608@gmail.com> <22303.1283965770@marajade.sandelman.ca> In-Reply-To: <22303.1283965770@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100908-1, 08/09/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org, Andy Zhou Subject: Re: [Roll] Unique shared key for the entire RPL network vs Privacy? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 20:43:34 -0000 Le 08/09/2010 19:09, Michael Richardson a écrit : > >>>>>> "Alexandru" == Alexandru >>>>>> Petrescu writes: > Alexandru> Le 07/09/2010 14:44, Andy Zhou a écrit : >>> It may depend on what level of security you want. In some case, >>> the public shared key is enough to provide the security and >>> privacy. > > Alexandru> Hi... would you please mention one such case, with an > Alexandru> existing IP protocol? I am personally not aware of any > Alexandru> IP protocol using a common shared key between more than > Alexandru> two communication ends. > > multicast IPsec. YEs that is good, as well as the GDOI RFC. Reads IPsec and I agree with it. (I could explain why people may think I don't understand IPsec: maybe the alea of email conversation, or anything you prefer; but the Security Considerations section being silent of IPsec really itches.) Alex From alexandru.petrescu@gmail.com Thu Sep 9 00:05:36 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 981D13A6403 for ; Thu, 9 Sep 2010 00:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qHtI1glXd45 for ; Thu, 9 Sep 2010 00:05:35 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 5BC1E3A6359 for ; Thu, 9 Sep 2010 00:05:35 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o8975ume006449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Sep 2010 09:05:56 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o8975uj1017937; Thu, 9 Sep 2010 09:05:56 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o8975upR031469; Thu, 9 Sep 2010 09:05:56 +0200 Message-ID: <4C888754.2020709@gmail.com> Date: Thu, 09 Sep 2010 09:05:56 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Philip Levis References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> <2E900F804B524AA1B59DEE358CC47315@ubilogixrodo> <4C85DC4F.7030105@gmail.com> <5EE6D4AF-05B6-474E-BF4C-890BFA74A676@cs.stanford.edu> In-Reply-To: <5EE6D4AF-05B6-474E-BF4C-890BFA74A676@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Sep 2010 07:05:36 -0000 Le 08/09/2010 18:20, Philip Levis a écrit : > > On Sep 6, 2010, at 11:31 PM, Alexandru Petrescu wrote: > >> Le 07/09/2010 02:48, Rodolfo Gonzalez Bernaldez a écrit : >>> Hello Alex, all >>> >>> >>>> One way I could agree with is something like "Securing RPL >>>> messages can be achieved by: IPsec, link-layer security, and >>>> RPL-AES-CCM MAC field in RPL header; in that order of >>>> preference". >>> >>> >>> I know that ROLL is not focusing in any specified link-layer, >>> but if we are in the Low power networks, many of the devices used >>> in this field will be devices with limited hardware features >>> (RAM, ROM, CPU) and given the size of an implementation of IPsec, >>> I think that if we are planning to include IPsec in the RPL >>> specification, we need to be very carefull and consider those >>> limitations. >> >> I agree. In support of IPsec I can say that there exist very >> lightweight software implementations of IPsec AH, SAdb and SPdb. >> Actually I am surprised of the reluctance and fear of large IPsec >> (paraphernalia?). > > Lightweight in the context of 32-bit architectures with>100 MHz > processors, or lightweight in the context of (much weaker) LLN class > devices? Actually I don't see anything in the current RPL security which makes it particularly adapted to LLN class devices. It talks same security paradigm of enc and auth with particular ciphering algorithms. The only difference from IPsec is that it places the security signature elsewhere than AH does, and that for no particular reason. It's not memory/CPU constraints who make that MAC field be in the ICMP payload instead of AH, it's something else that I don't understand. The same ciphering algorithms dear to RPL security (CCM? ECC?) could very well be used in an AH. I don't really understand why not. Were RPL security be adapted for constrained devices it would talk other paradigms than ciphering enc and auth. For example it could talk methods not relying on compute power to encode something, but rely on secretly agreed methods about time ("if you receive a duplicate message around 12pm+exp(12) then it's me, otherwise not") or about the physical environment (temperature, anything in the landscape, etc). These kinds of methods have 0 memory size requirements. > Alex, RPL is past last call. Based on the security requirements laid > out by the application drafts, and experience from people who have > built secured LLN networks, the conclusion was that simply applying > IPSec was not a good solution. Please review the numerous prior > discussions on this topic. If you strongly believe that RPL should > use IPSec, then you should write a draft describing exactly how it > works, so that we can have a technical, rather than ideological, > discussion. Note taken. I have been pondering over this since some time now. I think the header formats are pretty much straightforward. It could be very short and half-dozen references or so. However, I would need a willing co-author (would you be interested?) and some reassurance of the I-D being pursued and not killed by strange reasons. There is a doubtful point on the use of SAs with multicast addresses too. RPL uses exclusively a multicast address, but multicast support in RPL is completely unclear. The subnet notion, or the number of interfaces per device is foggy. In this sense it's hard to secure something unknown. I could leave this discussion out of the draft. And this does not mean IPsec is not appropriate for multicast use - it is, but RPL multicast and subnet is unknown. Alex From alexandru.petrescu@gmail.com Thu Sep 9 01:19:28 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062473A6A04 for ; Thu, 9 Sep 2010 01:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHcfUnsWWUEI for ; Thu, 9 Sep 2010 01:19:27 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id A3F193A67AC for ; Thu, 9 Sep 2010 01:19:26 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o898Jl1u024976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Sep 2010 10:19:47 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o898Jlqx012448; Thu, 9 Sep 2010 10:19:47 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o898Jlbc004061; Thu, 9 Sep 2010 10:19:47 +0200 Message-ID: <4C8898A3.10601@gmail.com> Date: Thu, 09 Sep 2010 10:19:47 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Philip Levis References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <9FF16CF7-13F1-47A3-AA91-758EC4395198@cs.stanford.edu> In-Reply-To: <9FF16CF7-13F1-47A3-AA91-758EC4395198@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Sep 2010 08:19:28 -0000 Le 08/09/2010 18:13, Philip Levis a écrit : > > On Sep 3, 2010, at 2:00 AM, Robert Cragie wrote: > >> 1. The discussion is in the context of ROLL, so the type of >> network is lossy and low power. 802.15.4 is a specific type of >> lossy and low power network. Therefore the draft should not refer >> specifically to 802.15.4 networks but to lossy and low power >> networks, which it does. 2. RPL security has nothing to do with >> 802.15.4 MAC security. They are totally independent. A secured RPL >> frame with a MIC will just be payload in an unsecured MAC frame, >> whatever that MAC happens to be. > > Yes, both are 100% correct and I agree with #1 completely. > >> RPL security is only used for securing RPL control messages. >> It is not used for securing data messages conveyed through a RPL >> DODAG; alternative security needs to be used, which could be link >> layer, IPSec, TLS etc. RPL control messages will not go beyond the >> DODAG root. So the scenario you are talking about will never >> happen wrt. RPL security. > > Correct. I personally feel that much of this discussion comes from > Alex's misunderstanding of the protocol and its design > considerations. Phil - an RPL node would be useful only if it talked to another Internet node, run an app. To secure that it would need to use the same security mechanism as that Internet node. Would you like to see a constrained RPL node required to implement _both_ RPL security _and_ IPsec? Alex > Phil From Chris.Dearlove@baesystems.com Thu Sep 9 03:53:51 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 373C53A6840; Thu, 9 Sep 2010 03:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.642 X-Spam-Level: X-Spam-Status: No, score=-6.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSk8Wyf03c1u; Thu, 9 Sep 2010 03:53:49 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 9B8A73A67D4; Thu, 9 Sep 2010 03:53:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,338,1280703600"; d="scan'208";a="86445145" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 09 Sep 2010 11:54:15 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o89AsEet011022; Thu, 9 Sep 2010 11:54:14 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Sep 2010 11:54:14 +0100 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: 7bit Date: Thu, 9 Sep 2010 11:54:13 +0100 Message-ID: In-Reply-To: <4C8732D9.5010809@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: (RPL: IPv6 RoutingProtocol for Low power and Lossy Networks) to Proposed Standard Thread-Index: ActPIohRUaPMjigkQyWcPWvMW/KdZgA4wXnw References: <20100818222846.13825.49680.idtracker@localhost> <4C8732D9.5010809@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , X-OriginalArrivalTime: 09 Sep 2010 10:54:14.0564 (UTC) FILETIME=[57A85E40:01CB500D] Cc: ROLL WG , draft-ietf-roll-rpl@tools.ietf.org, roll-chairs@tools.ietf.org Subject: Re: [Roll] Last Call: (RPL: IPv6 RoutingProtocol for Low power and Lossy Networks) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Sep 2010 10:53:51 -0000 > That can still be corrected (revive draft-ietf-roll-protocols-survey-07). That was dropped because some people had various issues with it. That draft, very roughly speaking, said "none of these existing protocols do what we want because they fail to meet the ideal we have set for these various reasons". The issues were over whether all such characteristions were accurate. (Note that absolute accuracy may not be essential to make a WG decision, but a higher standard is needed in an RFC. But I do not recall what the specific issues were.) What I'd find interesting is whether RPL meets all of those ideals itself. (That's a genuine question, I don't know.) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From culler@cs.berkeley.edu Thu Sep 9 07:59:01 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC39C3A6A9A for ; Thu, 9 Sep 2010 07:59: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbtGOuucpHxu for ; Thu, 9 Sep 2010 07:59:00 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 579713A6AB6 for ; Thu, 9 Sep 2010 07:58:41 -0700 (PDT) Received: from [192.168.7.94] (69-12-164-134.sfo.archrock.com [69.12.164.134]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o89Ex4Pt024304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 9 Sep 2010 07:59:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: David Culler In-Reply-To: <4C87C73E.1040806@gmail.com> Date: Thu, 9 Sep 2010 07:59:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca> <4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com> <4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> <519A78D0-77BC-466C-BAFF-084DEF5D9CB5@cs.stanford.edu> <4C87C73E.1040806@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Sep 2010 14:59:01 -0000 The RPL charter calls for us to address routing security considerations. = Not security in general. Not application security. Not link level. = Routing security. It is focused for good reason. On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote: > Le 08/09/2010 18:15, Philip Levis a =E9crit : >>=20 >> On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote: >>=20 >>> Le 03/09/2010 13:48, Robert Cragie a =E9crit : [skipped agreed >>> opinions about IPsec] >>>>> Reusing the IPsec module ensures a secure system - it's proven >>>>> by earlier experience. We know it worked ok so why avoid using >>>>> it. >>>>=20 >>>> I don't think the specification of RPL security precludes >>>> the use of IPSec instead. Does the use of IPSec need to be >>>> specified in the RPL specification? >>>=20 >>> YEs, the RPL specification must say something about security in its >>> Security Considerations section. That something has to mention >>> something about IPsec. >>=20 >> Why does it have to do so? In theory, RPL should be entirely >> independent of IPSec. There have already been numerous discussions >> about why simply relying on IPSec would be problematic. >> Unfortunately you seem to forget these points every few weeks and >> rehash the same discussion. At some point it becomes a waste of >> everyone's time. >=20 > Phil - if RPL says "security" then it must understand that Internet > security is usually IPsec. This is truer with IPv6 (as opposed to = IPv4) > where IPsec is very much integrated in the design (mutable fields, = etc.) >=20 > Have you checked the mutable field discussion? Do you agree that > mutable fields must be taken into account? >=20 > Please read that around 3 people agreed on a list of items which are > worth discussion of security and IPsec - mutable fields is one such = item. >=20 > As such this discussion is not a waste of everyone's time. >=20 > Alex >=20 >>=20 >> Phil >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll David Culler culler@cs.berkeley.edu Chair Computer Science Associate Chair EECS From alexandru.petrescu@gmail.com Thu Sep 9 08:28:54 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 439753A6ABD for ; Thu, 9 Sep 2010 08:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwYvxUaTiSFy for ; Thu, 9 Sep 2010 08:28:53 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id B567E3A6AB8 for ; Thu, 9 Sep 2010 08:28:52 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o89FTBj6020947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Sep 2010 17:29:11 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o89FTA1F018071; Thu, 9 Sep 2010 17:29:11 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o89FT9JR030390; Thu, 9 Sep 2010 17:29:10 +0200 Message-ID: <4C88FD45.60004@gmail.com> Date: Thu, 09 Sep 2010 17:29:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: David Culler References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca> <4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com> <4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> <519A78D0-77BC-466C-BAFF-084DEF5D9CB5@cs.stanford.edu> <4C87C73E.1040806@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Sep 2010 15:28:54 -0000 Le 09/09/2010 16:59, David Culler a écrit : > The RPL charter calls for us to address routing security > considerations. Not security in general. Not application security. > Not link level. Routing security. It is focused for good reason. Routing security like OSPF using IPsec? "Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP)." says rfc5340... why does RPL need to be different in this respect? Alex > > On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote: > >> Le 08/09/2010 18:15, Philip Levis a écrit : >>> >>> On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote: >>> >>>> Le 03/09/2010 13:48, Robert Cragie a écrit : [skipped agreed >>>> opinions about IPsec] >>>>>> Reusing the IPsec module ensures a secure system - it's >>>>>> proven by earlier experience. We know it worked ok so why >>>>>> avoid using it. >>>>> >>>>> I don't think the specification of RPL security >>>>> precludes the use of IPSec instead. Does the use of IPSec >>>>> need to be specified in the RPL specification? >>>> >>>> YEs, the RPL specification must say something about security >>>> in its Security Considerations section. That something has to >>>> mention something about IPsec. >>> >>> Why does it have to do so? In theory, RPL should be entirely >>> independent of IPSec. There have already been numerous >>> discussions about why simply relying on IPSec would be >>> problematic. Unfortunately you seem to forget these points every >>> few weeks and rehash the same discussion. At some point it >>> becomes a waste of everyone's time. >> >> Phil - if RPL says "security" then it must understand that Internet >> security is usually IPsec. This is truer with IPv6 (as opposed to >> IPv4) where IPsec is very much integrated in the design (mutable >> fields, etc.) >> >> Have you checked the mutable field discussion? Do you agree that >> mutable fields must be taken into account? >> >> Please read that around 3 people agreed on a list of items which >> are worth discussion of security and IPsec - mutable fields is one >> such item. >> >> As such this discussion is not a waste of everyone's time. >> >> Alex >> >>> >>> Phil >> >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > David Culler culler@cs.berkeley.edu Chair Computer Science Associate > Chair EECS > > > > From jpv@cisco.com Thu Sep 9 11:47:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 522A83A67F6 for ; Thu, 9 Sep 2010 11:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.599 X-Spam-Level: X-Spam-Status: No, score=-112.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIUFSnKlONWZ for ; Thu, 9 Sep 2010 11:47:26 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 46D0E3A66B4 for ; Thu, 9 Sep 2010 11:47:24 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPvIiEyrR7H+/2dsb2JhbAChHHGldIs+kBCFPQSERYVbgnwH X-IronPort-AV: E=Sophos;i="4.56,341,1280707200"; d="scan'208,217";a="237776223" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 09 Sep 2010 18:47:51 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o89IlpL9014158 for ; Thu, 9 Sep 2010 18:47:51 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); Thu, 9 Sep 2010 11:47:51 -0700 Received: from [10.2.104.130] ([10.21.122.107]) by xfe-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Sep 2010 11:47:51 -0700 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-240-808193255 Date: Thu, 9 Sep 2010 11:47:51 -0700 References: <20100907205554.DB2973A6ACE@core3.amsl.com> To: ROLL WG Message-Id: <5755F46F-0CAA-42EA-A5F0-871F68F80A76@cisco.com> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 09 Sep 2010 18:47:51.0341 (UTC) FILETIME=[81606DD0:01CB504F] Subject: [Roll] Fwd: IETF 79 - Meeting Information X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Sep 2010 18:47:34 -0000 --Apple-Mail-240-808193255 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: IETF Secretariat > Date: September 7, 2010 1:55:54 PM PDT > To: IETF Announcement list > Cc: wgchairs@ietf.org > Subject: IETF 79 - Meeting Information > > 79th IETF Meeting > Beijing, China > November 7-12, 2010 > Host: Tsinghua University > > Register online at: http://www.ietf.org/meetings/79/ > > 1. Registration > 2. Meeting and Training Schedule > 3. Visas & Letters of Invitation > 4. Accommodations, Breakfast and Cancellation Policy > > 1. Registration > A. Early-Bird Registration - USD 635.00 Pay by Friday, 29 October > 2010 17:00 PT (24:00 UTC) > B. After Early-Bird cutoff - USD 785.00 > C. Full-time Student Registrations - USD 150.00 (with proper ID) > D. One Day Pass Registration - USD 350.00 > E. Registration Cancellation > Cut-off for registration cancellation is Monday, > 1 November 2010 at 17:00 PT (24:00 UTC). Cancellations > are subject to a 10% (ten percent) cancellation fee if > requested by that date and time. > F. Online Registration ends Friday, 5 Nov 2010, 17:00 local time > (02:00 PT, 09:00 UTC). > G. On-site Registration starting Sunday, 7 November at 11:00 AM > local Beijing time. > > 2. Meeting and Training Schedule: > A. Meeting starts Monday morning and runs through Friday at > 15:15 local time. > B. Most training sessions will take place on Sunday afternoon > 7 November 2010. The following tutorials are being offered: > Newcomer's Training (English and Mandarin), Security Tutorial, > Document Lifecycle Tutorial and Routing, Bridging and Switching > Tutorial. You can read a description of each tutorial at: > http://www.ietf.org/meeting/79/tutorials.html > > 3. Visas & Letters of Invitation: There are two types of visa you can use > to enter China: Tourist (L) or Business (F). We recommend you allow at > least one month to complete the visa application process. > > A. Tourist Visa (L) > Does not require a letter of invitation from the Host or the > IETF. According to the Host this is appropriate if you intend > to do sightseeing in China before or after the meeting. > > B. Business Visa (F) > An official letter of invitation from the meeting host, > Tsinghua University, is required. You can request this letter > after registering for IETF 79. > > For more detailed information see: > http://www.ietf.org/meetin/79/visa.html > > 4. Accommodations, Breakfast and Cancellation Policy > There are a block of guest room for the IETF at two hotels > in Beijing, the main meeting venue - the Shangri-La Hotel > Beijing, and the Hotel Nikko New Century Beijing. > Additional hotel information and instructions on making your > reservation and receiving the IETF group rate can be found at: > http://www.ietf.org/meeting/79/hotel.html > > Room rates are inclusive of daily breakfast and in room > high-speed Internet access. > > Reservations Cut off Date: October 22, 2010 > > Guaranteed Reservations to be Held: guaranteed reservations > will be held until the night of the arrival date. All > reservations must be accompanied by a valid credit card that > shall be charged on the cut off date (October 22, 2010) for > one night room and tax, which is refundable up to 72 hours > prior to scheduled arrival date. > > Guest Cancellation: Individuals can cancel a reservation > without penalty until 3 days prior to check-in/arrival. In > case of cancellation less than 3 days to 1 day prior to > expected arrival day, the Hotel will charge 2 nights of the > room charges and a service charge. For non-arrival or no-show > on expected arrival day, the Hotel holds the right to charge > the individuals for 3 nights of the room charges and a service > charge as cancellation fees. > > Check in time: 15:00; Check out time: 12:00 > > Early Departure Fee: An early departure fee of original duration > at daily group rate and service charge will be applied to all > rooms that do not notify the front desk within 24 hours of an > early check out. Hotel will confirm with guest at the time of > check in on the scheduled departure date. If guest gives the > Hotel an advance notice of 24 hours, the Hotel will not charge > any penalty. > > NOTE: The distance between the Hotel Nikko and the Shangri-La > Hotel is approximately 2.2 kilometers (1.37 miles) 8-10 minutes > by cab or bus (depending on traffic) and 20-30 minutes walking > (though not recommended, it may be rather cold). A shuttle bus > will be provided between the two venues running continually > between the hotels for 1 hour prior and 1 hour after the event > everyday from November 7-12, 2010. During the conference hours > on November 8-12, 2010 the shuttle bus will be running between > the two hotels every 1 hour. > > Cab prices between the Shangri-La and Nikko will cost > approximately RMB 10-15. (approximately USD 2.20; EUR 1.75, > JPY 186) > > Only 60 days until the Beijing IETF! > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-240-808193255 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: IETF Secretariat = <ietf-secretariat@ietf.org>= ;
Date: September 7, 2010 1:55:54 PM PDT
To: IETF Announcement = list <ietf-announce@ietf.org>
<= /span>
Subject: IETF 79 - = Meeting Information

79th IETF = Meeting
Beijing, China
November 7-12, 2010
Host: Tsinghua = University

Register online at: http://www.ietf.org/meetings/79/=

1.  Registration
2.  Meeting and Training = Schedule
3.  Visas & Letters of Invitation
4. =  Accommodations, Breakfast and Cancellation Policy

1. = Registration
= A. Early-Bird Registration - USD 635.00 Pay by Friday, 29 = October
= 2010 17:00 PT (24:00 UTC)
B. After Early-Bird cutoff - USD = 785.00
= C. Full-time Student Registrations - USD 150.00 (with proper = ID)
= D. One Day Pass Registration - USD 350.00
E. = Registration Cancellation
Cut-off for registration = cancellation is Monday,
1 November 2010 at 17:00 PT = (24:00 UTC). Cancellations
are subject to a 10% (ten = percent) cancellation fee if
requested by that date and = time.
= F.  Online Registration ends Friday, 5 Nov 2010, 17:00 local = time
= (02:00 PT, 09:00 UTC).
G. On-site Registration starting = Sunday, 7 November at 11:00 AM
local Beijing time.

2. = Meeting and Training Schedule:
A. Meeting starts Monday morning = and runs through Friday at
15:15 local time.
B. Most = training sessions will take place on Sunday afternoon
7 = November 2010. The following tutorials are being offered:
= Newcomer's Training (English and Mandarin), Security = Tutorial,
= Document Lifecycle Tutorial and Routing, Bridging and = Switching
= Tutorial.  You can read a description of each tutorial = at:
= http://www.ietf.org= /meeting/79/tutorials.html

3. Visas & Letters of = Invitation: There are two types of visa you can use
to enter China: = Tourist (L) or Business (F). We recommend you allow at
least one = month to complete the visa application process.

A. =  Tourist Visa (L)
Does not require a letter of = invitation from the Host or the
IETF. According to the Host this = is appropriate if you intend
to do sightseeing in China before = or after the meeting.

B.  Business Visa = (F)
= An official letter of invitation from the meeting host,
Tsinghua = University, is required. You can request this letter
after = registering for IETF 79.

For more detailed information = see:
= http://www.ietf.org/meetin/79/visa.html

4. =  Accommodations, Breakfast and Cancellation Policy
There are = a block of guest room for the IETF at two hotels
in = Beijing, the main meeting venue - the Shangri-La Hotel
Beijing, = and the Hotel Nikko New Century Beijing.
= Additional hotel information and instructions on making your =
= reservation and receiving the IETF group rate can be found at: =
= = http://www.ietf.org/meeting/79/hotel.html

Room = rates are inclusive of daily breakfast and in room
= high-speed Internet access.

Reservations Cut off Date: = October 22, 2010

Guaranteed Reservations to be = Held: guaranteed reservations
will be held until the night of = the arrival date. All
reservations must be accompanied = by a valid credit card that
shall be charged on the cut off = date (October 22, 2010) for
one night room and tax, which is = refundable up to 72 hours
prior to scheduled arrival = date.

= Guest Cancellation: Individuals can cancel a reservation =
= without penalty until 3 days prior to check-in/arrival. In =
= case of cancellation less than 3 days to 1 day prior to
expected = arrival day, the Hotel will charge 2 nights of the
room = charges and a service charge. For non-arrival or no-show
on = expected arrival day, the Hotel holds the right to charge
the = individuals for 3 nights of the room charges and a service
charge as = cancellation fees.

Check in time: 15:00; Check out = time: 12:00

Early Departure Fee: An early = departure fee of original duration
at daily group rate and service = charge will be applied to all
rooms that do not notify the = front desk within 24 hours of an
early check out. Hotel will = confirm with guest at the time of
check in on the scheduled = departure date. If guest gives the
Hotel an advance notice of 24 = hours, the Hotel will not charge
any penalty.

NOTE: The = distance between the Hotel Nikko and the Shangri-La
Hotel is = approximately 2.2 kilometers (1.37 miles) 8-10 minutes
by cab or = bus (depending on traffic) and 20-30 minutes walking
(though = not recommended, it may be rather cold). A shuttle bus
will be = provided between the two venues running continually
between = the hotels for 1 hour prior and 1 hour after the event
everyday = from November 7-12, 2010. During the conference hours
on = November 8-12, 2010 the shuttle bus will be running between
the two = hotels every 1 hour.

Cab prices between the Shangri-La = and Nikko will cost
approximately RMB 10-15. = (approximately USD 2.20; EUR 1.75,
JPY 186)

Only 60 days = until the Beijing = IETF!
_______________________________________________
IETF-Announce = mailing = list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ie= tf-announce

= --Apple-Mail-240-808193255-- From culler@cs.berkeley.edu Thu Sep 9 14:00:55 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 185493A67F9 for ; Thu, 9 Sep 2010 14:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bnf-9n6aCWDV for ; Thu, 9 Sep 2010 14:00:54 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 68F313A6904 for ; Thu, 9 Sep 2010 14:00:53 -0700 (PDT) Received: from dhcp-45-99.eecs.berkeley.edu (dhcp-45-99.EECS.Berkeley.EDU [128.32.45.99]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o89L1JdK004884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 9 Sep 2010 14:01:20 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1081) From: David Culler In-Reply-To: <4C88FD45.60004@gmail.com> Date: Thu, 9 Sep 2010 13:33:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8556A091-D8F9-4B6B-8F49-4260005C577C@cs.berkeley.edu> References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca> <4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com> <4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> <519A78D0-77BC-466C-BAFF-084DEF5D9CB5@cs.stanford.edu> <4C87C73E.1040806@gmail.com> <4C88FD45.60004@gmail.com> To: ROLL WG X-Mailer: Apple Mail (2.1081) Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Sep 2010 21:00:55 -0000 Dear Alex, Thank you for focusing on the question of routing security, rather = than internet security in general. Yes, IPSec has been utilized to = secure routing protocols. Now please take the next step and focus on = routing for low power and lossy networks. Obviously, IPSec has to be = the first thing considered. And it was. Dating back to the earliest = security framework discussions it was considered many times. We = returned to the IPSec issue extensively back in June on the mailing = list. I won't reiterate the discussion on the storage and time = complexity, nor the message overhead implications that were in those = prior postings. But I will observe that no one suggested that they saw = their way to a full IPSec implementation within the constraints = articulated in the Routing Requirements documents. The WG group has = long since reached a rough consensus on this matter and moved on. That = is the nature of a group process and specifically the role of WG LC. At = some point, we commit to certain things and stop revisiting them from = first principles. That allows us to focus more sharply on the selected = approach and refine it more completely. For example, in security, we = have specifics to resolve, such as which header fields need to be = skipped. It is not a matter of "but I imagine that there may be = alternatives". There might be. But we don't just turn the same rocks = over and over again. We carve the rough stone, we chisel the details, = we sand, we polish. =20 So I assume that the point of your posting is that you want to be = sure that the justification for the choices that the WG made are = properly documented in the WG documents. If you feel that they are not, = perhaps you could point to the document and section that you feel should = contain this material more substantially. D. For reference, http://www.ietf.org/tao.html section 7.4 On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote: > Le 09/09/2010 16:59, David Culler a =E9crit : >> The RPL charter calls for us to address routing security >> considerations. Not security in general. Not application security. >> Not link level. Routing security. It is focused for good reason. >=20 > Routing security like OSPF using IPsec? "Authentication has been = removed > from the OSPF protocol and instead relies on IPv6's Authentication > Header and Encapsulating Security Payload (ESP)." says rfc5340... why > does RPL need to be different in this respect? >=20 > Alex >=20 >>=20 >> On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote: >>=20 >>> Le 08/09/2010 18:15, Philip Levis a =E9crit : >>>>=20 >>>> On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote: >>>>=20 >>>>> Le 03/09/2010 13:48, Robert Cragie a =E9crit : [skipped agreed >>>>> opinions about IPsec] >>>>>>> Reusing the IPsec module ensures a secure system - it's >>>>>>> proven by earlier experience. We know it worked ok so why >>>>>>> avoid using it. >>>>>>=20 >>>>>> I don't think the specification of RPL security >>>>>> precludes the use of IPSec instead. Does the use of IPSec >>>>>> need to be specified in the RPL specification? >>>>>=20 >>>>> YEs, the RPL specification must say something about security >>>>> in its Security Considerations section. That something has to >>>>> mention something about IPsec. >>>>=20 >>>> Why does it have to do so? In theory, RPL should be entirely >>>> independent of IPSec. There have already been numerous >>>> discussions about why simply relying on IPSec would be >>>> problematic. Unfortunately you seem to forget these points every >>>> few weeks and rehash the same discussion. At some point it >>>> becomes a waste of everyone's time. >>>=20 >>> Phil - if RPL says "security" then it must understand that Internet >>> security is usually IPsec. This is truer with IPv6 (as opposed to >>> IPv4) where IPsec is very much integrated in the design (mutable >>> fields, etc.) >>>=20 >>> Have you checked the mutable field discussion? Do you agree that >>> mutable fields must be taken into account? >>>=20 >>> Please read that around 3 people agreed on a list of items which >>> are worth discussion of security and IPsec - mutable fields is one >>> such item. >>>=20 >>> As such this discussion is not a waste of everyone's time. >>>=20 >>> Alex >>>=20 >>>>=20 >>>> Phil >>>=20 >>>=20 >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>=20 >> David Culler culler@cs.berkeley.edu Chair Computer Science Associate >> Chair EECS >>=20 >>=20 >>=20 >>=20 >=20 >=20 David Culler culler@cs.berkeley.edu Chair Computer Science Associate Chair EECS From alexandru.petrescu@gmail.com Fri Sep 10 01:01:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DED103A659C for ; Fri, 10 Sep 2010 01:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9wNErwD+45g for ; Fri, 10 Sep 2010 01:01:34 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 48C413A6966 for ; Fri, 10 Sep 2010 01:01:33 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o8A820P5013675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 10 Sep 2010 10:02:00 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o8A820BP011319 for ; Fri, 10 Sep 2010 10:02:00 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o8A820kQ006750 for ; Fri, 10 Sep 2010 10:02:00 +0200 Message-ID: <4C89E5F8.6020007@gmail.com> Date: Fri, 10 Sep 2010 10:02:00 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: roll@ietf.org References: <13773.1282327971@marajade.sandelman.ca> <4C72AF1E.9050200@gmail.com> <4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> <519A78D0-77BC-466C-BAFF-084DEF5D9CB5@cs.stanford.edu> <4C87C73E.1040806@gmail.com> <4C88FD45.60004@gmail.com> <8556A091-D8F9-4B6B-8F49-4260005C577C@cs.berkeley.edu> In-Reply-To: <8556A091-D8F9-4B6B-8F49-4260005C577C@cs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 10 Sep 2010 08:01:36 -0000 Le 09/09/2010 22:33, David Culler a écrit : > Dear Alex, Thank you for focusing on the question of routing > security, rather than internet security in general. Yes, IPSec has > been utilized to secure routing protocols. Now please take the next > step and focus on routing for low power and lossy networks. > Obviously, IPSec has to be the first thing considered. And it was. > Dating back to the earliest security framework discussions it was > considered many times. We returned to the IPSec issue extensively > back in June on the mailing list. I won't reiterate the discussion > on the storage and time complexity, nor the message overhead > implications that were in those prior postings. But I will observe > that no one suggested that they saw their way to a full IPSec > implementation within the constraints articulated in the Routing > Requirements documents. The WG group has long since reached a > rough consensus on this matter and moved on. That is the nature of a > group process and specifically the role of WG LC. Thanks for clarification. > At some point, we commit to certain things and stop revisiting them > from first principles. That allows us to focus more sharply on the > selected approach and refine it more completely. For example, in > security, we have specifics to resolve, such as which header fields > need to be skipped. It is not a matter of "but I imagine that there > may be alternatives". There might be. But we don't just turn the > same rocks over and over again. We carve the rough stone, we chisel > the details, we sand, we polish. Suggestive and I agree we are in finalizing steps. About proposing IPsec - I am not the best proponent of it, may not be even useful, but here goes a line of thought: The fact that mutable fields were not considered is just one step. Next step is to realize about mutable but predictable fields. That will come when we talk Routing Header for RPL. Then we'll wonder again how to secure it ok because the existing RPL security does not consider it. Then we'll ask again whether IPsec were better at it. > So I assume that the point of your posting is that you want to be > sure that the justification for the choices that the WG made are > properly documented in the WG documents. If you feel that they are > not, perhaps you could point to the document and section that you > feel should contain this material more substantially. I believe the Security Considerations section in the RPL document should contain more talk about IPsec. Even if it just said "MAY". This is something that was said on the list not only by me. Am I understanding you correctly? Is this what you ask? If yes, should we proceed to propose IPsec-MAY text to the Security Considerations section? Alex > > D. > > For reference, http://www.ietf.org/tao.html section 7.4 > > > On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote: > >> Le 09/09/2010 16:59, David Culler a écrit : >>> The RPL charter calls for us to address routing security >>> considerations. Not security in general. Not application >>> security. Not link level. Routing security. It is focused for >>> good reason. >> >> Routing security like OSPF using IPsec? "Authentication has been >> removed from the OSPF protocol and instead relies on IPv6's >> Authentication Header and Encapsulating Security Payload (ESP)." >> says rfc5340... why does RPL need to be different in this respect? >> >> Alex >> >>> >>> On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote: >>> >>>> Le 08/09/2010 18:15, Philip Levis a écrit : >>>>> >>>>> On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote: >>>>> >>>>>> Le 03/09/2010 13:48, Robert Cragie a écrit : [skipped >>>>>> agreed opinions about IPsec] >>>>>>>> Reusing the IPsec module ensures a secure system - it's >>>>>>>> proven by earlier experience. We know it worked ok so >>>>>>>> why avoid using it. >>>>>>> >>>>>>> I don't think the specification of RPL security >>>>>>> precludes the use of IPSec instead. Does the use of IPSec >>>>>>> need to be specified in the RPL specification? >>>>>> >>>>>> YEs, the RPL specification must say something about >>>>>> security in its Security Considerations section. That >>>>>> something has to mention something about IPsec. >>>>> >>>>> Why does it have to do so? In theory, RPL should be entirely >>>>> independent of IPSec. There have already been numerous >>>>> discussions about why simply relying on IPSec would be >>>>> problematic. Unfortunately you seem to forget these points >>>>> every few weeks and rehash the same discussion. At some >>>>> point it becomes a waste of everyone's time. >>>> >>>> Phil - if RPL says "security" then it must understand that >>>> Internet security is usually IPsec. This is truer with IPv6 >>>> (as opposed to IPv4) where IPsec is very much integrated in >>>> the design (mutable fields, etc.) >>>> >>>> Have you checked the mutable field discussion? Do you agree >>>> that mutable fields must be taken into account? >>>> >>>> Please read that around 3 people agreed on a list of items >>>> which are worth discussion of security and IPsec - mutable >>>> fields is one such item. >>>> >>>> As such this discussion is not a waste of everyone's time. >>>> >>>> Alex >>>> >>>>> >>>>> Phil >>>> >>>> >>>> _______________________________________________ Roll mailing >>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> >>> David Culler culler@cs.berkeley.edu Chair Computer Science >>> Associate Chair EECS >>> >>> >>> >>> >> >> > > David Culler culler@cs.berkeley.edu Chair Computer Science Associate > Chair EECS > > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From robert.cragie@gridmerge.com Fri Sep 10 02:55:24 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0135B3A6359 for ; Fri, 10 Sep 2010 02:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.606 X-Spam-Level: X-Spam-Status: No, score=-3.606 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUyJ+GU-RUzP for ; Fri, 10 Sep 2010 02:55:21 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 831203A67CC for ; Fri, 10 Sep 2010 02:55:05 -0700 (PDT) Received: from client-86-23-76-166.brhm.adsl.virginmedia.com ([86.23.76.166] helo=[192.168.1.72]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1Ou0KL-0007Lb-1M; Fri, 10 Sep 2010 10:55:27 +0100 Message-ID: <4C8A008C.7080406@gridmerge.com> Date: Fri, 10 Sep 2010 10:55:24 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: David Culler References: <13773.1282327971@marajade.sandelman.ca> <4C72AF1E.9050200@gmail.com> <4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> <519A78D0-77BC-466C-BAFF-084DEF5D9CB5@cs.stanford.edu> <4C87C73E.1040806@gmail.com> <4C88FD45.60004@gmail.com> <8556A091-D8F9-4B6B-8F49-4260005C577C@cs.berkeley.edu> In-Reply-To: <8556A091-D8F9-4B6B-8F49-4260005C577C@cs.berkeley.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010709030808000608050507" Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 09:55:24 -0000 This is a cryptographically signed message in MIME format. --------------ms010709030808000608050507 Content-Type: multipart/alternative; boundary="------------010900010103070108060209" This is a multi-part message in MIME format. --------------010900010103070108060209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable David, I totally agree with what you say. Thank you for restating generally=20 that IPSec has already been extensively considered - I use the term=20 'paraphernalia' as a general term for the overheads. Alex - can we please drop the IPSec discussion and move on and=20 concentrate on the things which do need to sorted out? You are of course = entitled to your opinion but progress is only made in the IETF through=20 rough consensus. Consensus does not mean unanimous agreement; if we can=20 all at least consent to a solution then the process will run a lot more=20 smoothly and we will all benefit. Continual dissent will only serve to=20 hinder this progress. I think the consensus is clear: * We do not mention IPSec in RPL security * The mutable field discussion is entirely independent from IPSec Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 09/09/2010 9:33 PM, David Culler wrote: > Dear Alex, > Thank you for focusing on the question of routing security, rather = than internet security in general. Yes, IPSec has been utilized to secur= e routing protocols. Now please take the next step and focus on routing = for low power and lossy networks. Obviously, IPSec has to be the first t= hing considered. And it was. Dating back to the earliest security frame= work discussions it was considered many times. We returned to the IPSec= issue extensively back in June on the mailing list. I won't reiterate = the discussion on the storage and time complexity, nor the message overhe= ad implications that were in those prior postings. But I will observe th= at no one suggested that they saw their way to a full IPSec implementatio= n within the constraints articulated in the Routing Requirements document= s. The WG group has long since reached a rough consensus on this matter= and moved on. That is the nature of a group process and specifically th= e role of WG LC. At some point, we commit to certain things and stop rev= isiting them from first principles. That allows us to focus more sharpl= y on the selected approach and refine it more completely. For example, i= n security, we have specifics to resolve, such as which header fields nee= d to be skipped. It is not a matter of "but I imagine that there may be = alternatives". There might be. But we don't just turn the same rocks ov= er and over again. We carve the rough stone, we chisel the details, we s= and, we polish. > > So I assume that the point of your posting is that you want to be s= ure that the justification for the choices that the WG made are properly = documented in the WG documents. If you feel that they are not, perhaps y= ou could point to the document and section that you feel should contain t= his material more substantially. > > D. > > For reference, http://www.ietf.org/tao.html section 7.4 > > > On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote: > >> Le 09/09/2010 16:59, David Culler a =E9crit : >>> The RPL charter calls for us to address routing security >>> considerations. Not security in general. Not application security. >>> Not link level. Routing security. It is focused for good reason. >> Routing security like OSPF using IPsec? "Authentication has been remov= ed >> from the OSPF protocol and instead relies on IPv6's Authentication >> Header and Encapsulating Security Payload (ESP)." says rfc5340... why >> does RPL need to be different in this respect? >> >> Alex >> >>> On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote: >>> >>>> Le 08/09/2010 18:15, Philip Levis a =E9crit : >>>>> On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote: >>>>> >>>>>> Le 03/09/2010 13:48, Robert Cragie a =E9crit : [skipped agreed >>>>>> opinions about IPsec] >>>>>>>> Reusing the IPsec module ensures a secure system - it's >>>>>>>> proven by earlier experience. We know it worked ok so why >>>>>>>> avoid using it. >>>>>>> I don't think the specification of RPL security >>>>>>> precludes the use of IPSec instead. Does the use of IPSec >>>>>>> need to be specified in the RPL specification? >>>>>> YEs, the RPL specification must say something about security >>>>>> in its Security Considerations section. That something has to >>>>>> mention something about IPsec. >>>>> Why does it have to do so? In theory, RPL should be entirely >>>>> independent of IPSec. There have already been numerous >>>>> discussions about why simply relying on IPSec would be >>>>> problematic. Unfortunately you seem to forget these points every >>>>> few weeks and rehash the same discussion. At some point it >>>>> becomes a waste of everyone's time. >>>> Phil - if RPL says "security" then it must understand that Internet >>>> security is usually IPsec. This is truer with IPv6 (as opposed to >>>> IPv4) where IPsec is very much integrated in the design (mutable >>>> fields, etc.) >>>> >>>> Have you checked the mutable field discussion? Do you agree that >>>> mutable fields must be taken into account? >>>> >>>> Please read that around 3 people agreed on a list of items which >>>> are worth discussion of security and IPsec - mutable fields is one >>>> such item. >>>> >>>> As such this discussion is not a waste of everyone's time. >>>> >>>> Alex >>>> >>>>> Phil >>>> >>>> _______________________________________________ Roll mailing list >>>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> David Culler culler@cs.berkeley.edu Chair Computer Science Associate >>> Chair EECS >>> >>> >>> >>> >> > David Culler > culler@cs.berkeley.edu > Chair Computer Science > Associate Chair EECS > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------010900010103070108060209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable David,

I totally agree with what you say. Thank you for restating generally that IPSec has already been extensively considered - I use the term 'paraphernalia' as a general term for the overheads.

Alex - can we please drop the IPSec discussion and move on and concentrate on the things which do need to sorted out? You are of course entitled to your opinion but progress is only made in the IETF through rough consensus. Consensus does not mean unanimous agreement; if we can all at least consent to a solution then the process will run a lot more smoothly and we will all benefit. Continual dissent will only serve to hinder this progress.

I think the consensus is clear:
  • We do not mention IPSec in RPL security
  • The mutable field discussion is entirely independent from IPSec
Robert

Robert Cragie (Pacific Gas & Electric)

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


On 09/09/2010 9:33 PM, David Culler wrote: 
Dear Alex,
   Thank you for focusing on the question of routing security, rather tha=
n internet security in general.  Yes, IPSec has been utilized to secure r=
outing protocols.  Now please take the next step and focus on routing for=
 low power and lossy networks.  Obviously, IPSec has to be the first thin=
g considered.  And it was.  Dating back to the earliest security framewor=
k discussions it was considered many times.   We returned to the IPSec is=
sue extensively back in June on the mailing list.   I won't reiterate the=
 discussion on the storage and time complexity, nor the message overhead =
implications that were in those prior postings.  But I will observe that =
no one suggested that they saw their way to a full IPSec implementation w=
ithin the constraints articulated in the Routing Requirements documents. =
  The WG group has long since reached a rough consensus on this matter an=
d moved on.  That is the nature of a group process and specifically the r=
ole of WG LC.  At some point, we commit=20
to certain things and stop revisiting them from first principles.   That =
allows us to focus more sharply on the selected approach and refine it mo=
re completely.  For example, in security, we have specifics to resolve, s=
uch as which header fields need to be skipped.  It is not a matter of "bu=
t I imagine that there may be alternatives".  There might be.  But we don=
't just turn the same rocks over and over again.  We carve the rough ston=
e, we chisel the details, we sand, we polish. =20

   So I assume that the point of your posting is that you want to be sure=
 that the justification for the choices that the WG made are properly doc=
umented in the WG documents.  If you feel that they are not, perhaps you =
could point to the document and section that you feel should contain this=
 material more substantially.

 D.

For reference, http://www.ietf.org/tao.html section 7.4


On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote:


Le 09/09/2010 16:59, David Culler a écrit :=


The RPL charter calls for us to address routing =
security
considerations.  Not security in general.  Not application security.
Not link level.  Routing security.  It is focused for good reason.

Routing security like OSPF using IPsec? "Authentication has been removed
from the OSPF protocol and instead relies on IPv6's Authentication
Header and Encapsulating Security Payload (ESP)." says rfc5340... why
does RPL need to be different in this respect?

Alex


On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote:


Le 08/09/2010 18:15, Philip Levis a écr=
it :

On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote:


Le 03/09/2010 13:48, Robert Cragie a &eacu=
te;crit : [skipped agreed
opinions about IPsec]

Reusing the IPsec module ensures a sec=
ure system - it's
proven by earlier experience. We know it worked ok so why
avoid using it.

<RCC>I don't think the specification of RPL security
precludes the use of IPSec instead. Does the use of IPSec
need to be specified in the RPL specification?</RCC>

YEs, the RPL specification must say something about security
in its Security Considerations section.  That something has to
mention something about IPsec.

Why does it have to do so? In theory, RPL should be entirely
independent of IPSec. There have already been numerous
discussions about why simply relying on IPSec would be
problematic. Unfortunately you seem to forget these points every
few weeks and rehash the same discussion. At some point it
becomes a waste of everyone's time.

Phil - if RPL says "security" then it must understand that Internet
security is usually IPsec.  This is truer with IPv6 (as opposed to
IPv4) where IPsec is very much integrated in the design (mutable
fields, etc.)

Have you checked the mutable field discussion?  Do you agree that
mutable fields must be taken into account?

Please read that around 3 people agreed on a list of items which
are worth discussion of security and IPsec - mutable fields is one
such item.

As such this discussion is not a waste of everyone's time.

Alex


Phil


_______________________________________________ Roll mailing list
Roll@=
ietf.org https://www.ietf.org/mailman/listinfo/roll=


David Culler culler@cs.berkeley.edu Chair Computer Science Associ=
ate
Chair EECS







David Culler
culler@cs.berkeley.edu
Chair Computer Science
Associate Chair EECS



_______________________________________________
Roll mailing list
Roll@=
ietf.org
https://www.ietf.org/mailman/listinfo/roll
--------------010900010103070108060209-- --------------ms010709030808000608050507 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwOTEwMDk1NTI0WjAjBgkqhkiG9w0BCQQxFgQUS9rU 1ztywC5DLP4yp39lpWMJn3gwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEANV0YpnsX+hib4MomM5tkfZGNrDfCwYIxt8+c RmQBIKdXZalMRLZYwnHN/VKdA6AcBEcnmOQ4DI4bTctgxjI51Lb73dCNC6d7dmo/Wyx56GqS O+G9qlI/m8KdGIAYxLPpWHICkHK7r+d7Wl6z9VwWFqIU8BiuKBCktVvZU9ZKejF50xAFPsYq ctLO4uqlWCyIxs/G5P7Wh507ccpqwC2gVL3wyKkJDcpcLtnLx/tRlfpHit7Pxj+RJIb5dDKz pF2sZZX4oKgAGapPK8L30XpAe20fTImh3XT5rpfgWRtwT3XmB9BSV1mJIuUWG0vNtPU4dSvE /Dm3P9O1I3/nGfKt/AAAAAAAAA== --------------ms010709030808000608050507-- From alexandru.petrescu@gmail.com Fri Sep 10 08:21:38 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8403A6843 for ; Fri, 10 Sep 2010 08:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlNChVyc9cjy for ; Fri, 10 Sep 2010 08:21:36 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 1D69F3A6835 for ; Fri, 10 Sep 2010 08:21:35 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o8AFM2N8017516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 10 Sep 2010 17:22:02 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o8AFM2Dh006812 for ; Fri, 10 Sep 2010 17:22:02 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o8AFM1wp012702 for ; Fri, 10 Sep 2010 17:22:02 +0200 Message-ID: <4C8A4D19.40202@gmail.com> Date: Fri, 10 Sep 2010 17:22:01 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: roll@ietf.org References: <13773.1282327971@marajade.sandelman.ca> <4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> <519A78D0-77BC-466C-BAFF-084DEF5D9CB5@cs.stanford.edu> <4C87C73E.1040806@gmail.com> <4C88FD45.60004@gmail.com> <8556A091-D8F9-4B6B-8F49-4260005C577C@cs.berkeley.edu> <4C8A008C.7080406@gridmerge.com> In-Reply-To: <4C8A008C.7080406@gridmerge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 10 Sep 2010 15:21:38 -0000 Le 10/09/2010 11:55, Robert Cragie a écrit : > David, > > I totally agree with what you say. Thank you for restating generally > that IPSec has already been extensively considered - I use the term > 'paraphernalia' as a general term for the overheads. > > Alex - can we please drop the IPSec discussion and move on and > concentrate on the things which do need to sorted out? Ok... let me try to avoid dissent and do what you ask. Let's come back to RPL-11 text: > 3. If the packet header specifies a source route by including a RH4 > header as specified in [I-D.ietf-6man-rpl-routing-header] then draft-ietf-6man-rpl-routing-header-00 says: > else { swap the IPv6 Destination Address and Address[i] That means that there is a mutable but predictable field (IPv6 Destination Addess) in RH of RPL. But RPL Security doesn't understand mutable but predictable fields (only mutable as per recent discussion). RPL Security covers "entire IPv6 packet", which changes enroute despite RPL Security's expectation it won't change. So the question is: does RPL Security secure the RH4 header? I think it does not, because its MAC computation does not say how are the mutable but predictable fields covered. For example, a sender builds a packet with Dst address1, computes MAC, inserts MAC. Then intermediary routers process that packet and replace that Dst address1 with address2 from the Routing Header. Now the packet is received at address1. The MAC can't be meaningfully computed on the receiver, because the "IPv6 entire packet" has changed, it is not the same as at emission. I think this example is correct. It can't be solved in the same way we solved the mutability of "Hop Limit" (we said to make HopLimit set to 0 for MAC calculation), because if we do so then we have a higher risk of attack than when left HopLimit unsecure. If we set to 0 de Dst for MAC calculation then the risk of implication of forged IP dst addresses is higher than forged HopLimit. Forging an IP dst address is stronger security attack than forging HopLimit, intuitively speaking. Besides, whereas the receiver has really no idea about what could the original HopLimit be, it knows precisely what the original Dst address was (it's in the RH4, swapped). Thus the securing solution should be different - it should be as smart as RH4 is. Knowing the previous discussion, it may be possible that people will request we refer to that Authentication Header RFC which tells how mutable, mutable but predictable fields are dealt with. At that point we come back to IPsec, but I will abstain from saying so if you wish. There is also the fact that previous IPsec talk says RH0 whereas here we have RH4 and things may be different. That's too long for anyone to read, but you get the point. Alex You are of course > entitled to your opinion but progress is only made in the IETF > through rough consensus. Consensus does not mean unanimous agreement; > if we can all at least consent to a solution then the process will > run a lot more smoothly and we will all benefit. Continual dissent > will only serve to hinder this progress. > > I think the consensus is clear: > > * We do not mention IPSec in RPL security * The mutable field > discussion is entirely independent from IPSec > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 > 1924 910888 +1 415 513 0064 http://www.gridmerge.com > > > > On 09/09/2010 9:33 PM, David Culler wrote: >> Dear Alex, Thank you for focusing on the question of routing >> security, rather than internet security in general. Yes, IPSec has >> been utilized to secure routing protocols. Now please take the >> next step and focus on routing for low power and lossy networks. >> Obviously, IPSec has to be the first thing considered. And it was. >> Dating back to the earliest security framework discussions it was >> considered many times. We returned to the IPSec issue extensively >> back in June on the mailing list. I won't reiterate the >> discussion on the storage and time complexity, nor the message >> overhead implications that were in those prior postings. But I >> will observe that no one suggested that they saw their way to a >> full IPSec implementation within the constraints articulated in the >> Routing Requirements documents. The WG group has long since >> reached a rough consensus on this matter and moved on. That is the >> nature of a group process and specifically the role of WG LC. At >> some point, we commit to certain things and stop revisiting them >> from first principles. That allows us to focus more sharply on >> the selected approach and refine it more completely. For example, >> in security, we have specifics to resolve, such as which header >> fields need to be skipped. It is not a matter of "but I imagine >> that there may be alternatives". There might be. But we don't >> just turn the same rocks over and over again. We carve the rough >> stone, we chisel the details, we sand, we polish. >> >> So I assume that the point of your posting is that you want to be >> sure that the justification for the choices that the WG made are >> properly documented in the WG documents. If you feel that they are >> not, perhaps you could point to the document and section that you >> feel should contain this material more substantially. >> >> D. >> >> For reference,http://www.ietf.org/tao.html section 7.4 >> >> >> On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote: >> >>> Le 09/09/2010 16:59, David Culler aécrit : >>>> The RPL charter calls for us to address routing security >>>> considerations. Not security in general. Not application >>>> security. Not link level. Routing security. It is focused for >>>> good reason. >>> Routing security like OSPF using IPsec? "Authentication has been >>> removed from the OSPF protocol and instead relies on IPv6's >>> Authentication Header and Encapsulating Security Payload (ESP)." >>> says rfc5340... why does RPL need to be different in this >>> respect? >>> >>> Alex >>> >>>> On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote: >>>> >>>>> Le 08/09/2010 18:15, Philip Levis aécrit : >>>>>> On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote: >>>>>> >>>>>>> Le 03/09/2010 13:48, Robert Cragie aécrit : [skipped >>>>>>> agreed opinions about IPsec] >>>>>>>>> Reusing the IPsec module ensures a secure system - >>>>>>>>> it's proven by earlier experience. We know it worked >>>>>>>>> ok so why avoid using it. >>>>>>>> I don't think the specification of RPL security >>>>>>>> precludes the use of IPSec instead. Does the use of >>>>>>>> IPSec need to be specified in the RPL >>>>>>>> specification? >>>>>>> YEs, the RPL specification must say something about >>>>>>> security in its Security Considerations section. That >>>>>>> something has to mention something about IPsec. >>>>>> Why does it have to do so? In theory, RPL should be >>>>>> entirely independent of IPSec. There have already been >>>>>> numerous discussions about why simply relying on IPSec >>>>>> would be problematic. Unfortunately you seem to forget >>>>>> these points every few weeks and rehash the same >>>>>> discussion. At some point it becomes a waste of everyone's >>>>>> time. >>>>> Phil - if RPL says "security" then it must understand that >>>>> Internet security is usually IPsec. This is truer with IPv6 >>>>> (as opposed to IPv4) where IPsec is very much integrated in >>>>> the design (mutable fields, etc.) >>>>> >>>>> Have you checked the mutable field discussion? Do you agree >>>>> that mutable fields must be taken into account? >>>>> >>>>> Please read that around 3 people agreed on a list of items >>>>> which are worth discussion of security and IPsec - mutable >>>>> fields is one such item. >>>>> >>>>> As such this discussion is not a waste of everyone's time. >>>>> >>>>> Alex >>>>> >>>>>> Phil >>>>> >>>>> _______________________________________________ Roll mailing >>>>> list Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>> David Cullerculler@cs.berkeley.edu Chair Computer Science >>>> Associate Chair EECS >>>> >>>> >>>> >>>> >>> >> David Culler culler@cs.berkeley.edu Chair Computer Science >> Associate Chair EECS >> >> >> >> _______________________________________________ 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 robert.cragie@gridmerge.com Fri Sep 10 09:47:50 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84CB63A6860 for ; Fri, 10 Sep 2010 09:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.605 X-Spam-Level: X-Spam-Status: No, score=-3.605 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00HeGX5vGhPY for ; Fri, 10 Sep 2010 09:47:44 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id E33E93A68CE for ; Fri, 10 Sep 2010 09:47:39 -0700 (PDT) Received: from client-86-23-76-166.brhm.adsl.virginmedia.com ([86.23.76.166] helo=[192.168.1.72]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1Ou6lh-0005Oe-0K; Fri, 10 Sep 2010 17:48:06 +0100 Message-ID: <4C8A6144.1070401@gridmerge.com> Date: Fri, 10 Sep 2010 17:48:04 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: Alexandru Petrescu References: <13773.1282327971@marajade.sandelman.ca> <4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> <519A78D0-77BC-466C-BAFF-084DEF5D9CB5@cs.stanford.edu> <4C87C73E.1040806@gmail.com> <4C88FD45.60004@gmail.com> <8556A091-D8F9-4B6B-8F49-4260005C577C@cs.berkeley.edu> <4C8A008C.7080406@gridmerge.com> <4C8A4D19.40202@gmai l.com> In-Reply-To: <4C8A4D19.40202@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040403030608070304050109" Cc: roll@ietf.org Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 16:47:50 -0000 This is a cryptographically signed message in MIME format. --------------ms040403030608070304050109 Content-Type: multipart/alternative; boundary="------------070303040201040809040700" This is a multi-part message in MIME format. --------------070303040201040809040700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Alex, Thank you for focusing on a pertinent issue. You are right to highlight=20 what we do with a RH4 header as I believe secured DAO ACK is the (only)=20 RPL control message which requires RH4 in non-storing mode. So, to follow the rules for mutable and predictable fields (see RFC=20 4302), we can resubstitute at the end: Consider the following: A -> B -> C -> D -> E A -> B: |Src|Dst|RH4 | | | |Seq|A0 |A1 |A2 | ------------------------- | A | B | 3 | C | D | E | B -> C: |Src|Dst|RH4 | | | |Seq|A0 |A1 |A2 | ------------------------- | A | C | 2 | B | D | E | C -> D: |Src|Dst|RH4 | | | |Seq|A0 |A1 |A2 | ------------------------- | A | D | 1 | B | C | E | D -> E: |Src|Dst|RH4 | | | |Seq|A0 |A1 |A2 | ------------------------- | A | E | 0 | B | C | D | When the packet arrives at E, recreate the original RH4 header for MAC=20 computation: n =3D ((Hdr Ext Len * 8) - Pad) / (16 - Comp) tmp =3D Dst Dst =3D RH4.A[0] RH4.Seq =3D n for (k =3D 1; k < n; k++) { RH4.A[k-1] =3D RH4.A[k] } RH4.A[k] =3D tmp |Src|Dst|RH4 | | | |Seq|L0 |L1 |L2 | ------------------------- | A | B | 3 | C | D | E | Is that acceptable? Now, just because I refer to IPSec AH, it doesn't mean I am suggesting=20 we use it. I am suggesting we can use the fundamental principles from=20 IPSec for an equivalent operation. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 10/09/2010 4:22 PM, Alexandru Petrescu wrote: > Le 10/09/2010 11:55, Robert Cragie a =E9crit : >> David, >> >> I totally agree with what you say. Thank you for restating generally >> that IPSec has already been extensively considered - I use the term >> 'paraphernalia' as a general term for the overheads. >> >> Alex - can we please drop the IPSec discussion and move on and >> concentrate on the things which do need to sorted out? > > Ok... let me try to avoid dissent and do what you ask. > > Let's come back to RPL-11 text: >> 3. If the packet header specifies a source route by including a RH4 >> header as specified in [I-D.ietf-6man-rpl-routing-header] > > then draft-ietf-6man-rpl-routing-header-00 says: >> else { swap the IPv6 Destination Address and Address[i] > > That means that there is a mutable but predictable field (IPv6 > Destination Addess) in RH of RPL. But RPL Security doesn't understand > mutable but predictable fields (only mutable as per recent discussion).= > RPL Security covers "entire IPv6 packet", which changes enroute despit= e > RPL Security's expectation it won't change. > > So the question is: does RPL Security secure the RH4 header? I think i= t > does not, because its MAC computation does not say how are the mutable > but predictable fields covered. > > For example, a sender builds a packet with Dst address1, computes MAC, > inserts MAC. Then intermediary routers process that packet and replace= > that Dst address1 with address2 from the Routing Header. Now the packe= t > is received at address1. The MAC can't be meaningfully computed on the= > receiver, because the "IPv6 entire packet" has changed, it is not the > same as at emission. > > I think this example is correct. > > It can't be solved in the same way we solved the mutability of "Hop > Limit" (we said to make HopLimit set to 0 for MAC calculation), because= > if we do so then we have a higher risk of attack than when left HopLimi= t > unsecure. If we set to 0 de Dst for MAC calculation then the risk of > implication of forged IP dst addresses is higher than forged HopLimit. > Forging an IP dst address is stronger security attack than forging > HopLimit, intuitively speaking. > > Besides, whereas the receiver has really no idea about what could the > original HopLimit be, it knows precisely what the original Dst address > was (it's in the RH4, swapped). Thus the securing solution should be > different - it should be as smart as RH4 is. > > Knowing the previous discussion, it may be possible that people will > request we refer to that Authentication Header RFC which tells how > mutable, mutable but predictable fields are dealt with. At that point > we come back to IPsec, but I will abstain from saying so if you wish. > There is also the fact that previous IPsec talk says RH0 whereas here w= e > have RH4 and things may be different. > > That's too long for anyone to read, but you get the point. > > Alex > > > > > You are of course >> entitled to your opinion but progress is only made in the IETF >> through rough consensus. Consensus does not mean unanimous agreement; >> if we can all at least consent to a solution then the process will >> run a lot more smoothly and we will all benefit. Continual dissent >> will only serve to hinder this progress. >> >> I think the consensus is clear: >> >> * We do not mention IPSec in RPL security * The mutable field >> discussion is entirely independent from IPSec >> >> Robert >> >> Robert Cragie (Pacific Gas & Electric) >> >> Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 >> 1924 910888 +1 415 513 0064 http://www.gridmerge.com >> >> >> >> On 09/09/2010 9:33 PM, David Culler wrote: >>> Dear Alex, Thank you for focusing on the question of routing >>> security, rather than internet security in general. Yes, IPSec has >>> been utilized to secure routing protocols. Now please take the >>> next step and focus on routing for low power and lossy networks. >>> Obviously, IPSec has to be the first thing considered. And it was. >>> Dating back to the earliest security framework discussions it was >>> considered many times. We returned to the IPSec issue extensively >>> back in June on the mailing list. I won't reiterate the >>> discussion on the storage and time complexity, nor the message >>> overhead implications that were in those prior postings. But I >>> will observe that no one suggested that they saw their way to a >>> full IPSec implementation within the constraints articulated in the >>> Routing Requirements documents. The WG group has long since >>> reached a rough consensus on this matter and moved on. That is the >>> nature of a group process and specifically the role of WG LC. At >>> some point, we commit to certain things and stop revisiting them >>> from first principles. That allows us to focus more sharply on >>> the selected approach and refine it more completely. For example, >>> in security, we have specifics to resolve, such as which header >>> fields need to be skipped. It is not a matter of "but I imagine >>> that there may be alternatives". There might be. But we don't >>> just turn the same rocks over and over again. We carve the rough >>> stone, we chisel the details, we sand, we polish. >>> >>> So I assume that the point of your posting is that you want to be >>> sure that the justification for the choices that the WG made are >>> properly documented in the WG documents. If you feel that they are >>> not, perhaps you could point to the document and section that you >>> feel should contain this material more substantially. >>> >>> D. >>> >>> For reference,http://www.ietf.org/tao.html section 7.4 >>> >>> >>> On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote: >>> >>>> Le 09/09/2010 16:59, David Culler a=E9crit : >>>>> The RPL charter calls for us to address routing security >>>>> considerations. Not security in general. Not application >>>>> security. Not link level. Routing security. It is focused for >>>>> good reason. >>>> Routing security like OSPF using IPsec? "Authentication has been >>>> removed from the OSPF protocol and instead relies on IPv6's >>>> Authentication Header and Encapsulating Security Payload (ESP)." >>>> says rfc5340... why does RPL need to be different in this >>>> respect? >>>> >>>> Alex >>>> >>>>> On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote: >>>>> >>>>>> Le 08/09/2010 18:15, Philip Levis a=E9crit : >>>>>>> On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote: >>>>>>> >>>>>>>> Le 03/09/2010 13:48, Robert Cragie a=E9crit : [skipped >>>>>>>> agreed opinions about IPsec] >>>>>>>>>> Reusing the IPsec module ensures a secure system - >>>>>>>>>> it's proven by earlier experience. We know it worked >>>>>>>>>> ok so why avoid using it. >>>>>>>>> I don't think the specification of RPL security >>>>>>>>> precludes the use of IPSec instead. Does the use of >>>>>>>>> IPSec need to be specified in the RPL >>>>>>>>> specification? >>>>>>>> YEs, the RPL specification must say something about >>>>>>>> security in its Security Considerations section. That >>>>>>>> something has to mention something about IPsec. >>>>>>> Why does it have to do so? In theory, RPL should be >>>>>>> entirely independent of IPSec. There have already been >>>>>>> numerous discussions about why simply relying on IPSec >>>>>>> would be problematic. Unfortunately you seem to forget >>>>>>> these points every few weeks and rehash the same >>>>>>> discussion. At some point it becomes a waste of everyone's >>>>>>> time. >>>>>> Phil - if RPL says "security" then it must understand that >>>>>> Internet security is usually IPsec. This is truer with IPv6 >>>>>> (as opposed to IPv4) where IPsec is very much integrated in >>>>>> the design (mutable fields, etc.) >>>>>> >>>>>> Have you checked the mutable field discussion? Do you agree >>>>>> that mutable fields must be taken into account? >>>>>> >>>>>> Please read that around 3 people agreed on a list of items >>>>>> which are worth discussion of security and IPsec - mutable >>>>>> fields is one such item. >>>>>> >>>>>> As such this discussion is not a waste of everyone's time. >>>>>> >>>>>> Alex >>>>>> >>>>>>> Phil >>>>>> >>>>>> _______________________________________________ Roll mailing >>>>>> list Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>> David Cullerculler@cs.berkeley.edu Chair Computer Science >>>>> Associate Chair EECS >>>>> >>>>> >>>>> >>>>> >>>> >>> David Culler culler@cs.berkeley.edu Chair Computer Science >>> Associate Chair EECS >>> >>> >>> >>> _______________________________________________ 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 > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------070303040201040809040700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex,

Thank you for focusing on a pertinent issue. You are right to highlight what we do with a RH4 header as I believe secured DAO ACK is the (only) RPL control message which requires RH4 in non-storing mode.

So, to follow the rules for mutable and predictable fields (see RFC 4302), we can resubstitute at the end:

Consider the following:

A -> B -> C -> D -> E

A -> B:

|Src|Dst|RH4         &= nbsp;  |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
 | A | B | 3 | C | D | E |
B -> C:

|Src|Dst|RH4         &= nbsp;  |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
 | A | C | 2 | B | D | E |
C -> D:

|Src|Dst|RH4         &= nbsp;  |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
 | A | D | 1 | B | C | E |
D -> E:

|Src|Dst|RH4         &= nbsp;  |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
 | A | E | 0 | B | C | D |
When the packet arrives at E, recreate the original RH4 header for MAC computation:

n =3D ((Hdr Ext Len * 8) - Pad) / (16 - Comp)
tmp =3D Dst
Dst =3D RH4.A[0]
RH4.Seq =3D n
for (k =3D 1; k < n; k++)
{
  RH4.A[k-1] =3D RH4.A[k]
}
RH4.A[k] =3D tmp

|Src|Dst|RH4         = ;   |
|   |   |Seq|L0 |L1 |L2 |
-------------------------
 | A | B | 3 | C | D | E |
Is that acceptable?

Now, just because I refer to IPSec AH, it doesn't mean I am suggesting we use it. I am suggesting we can use the fundamental principles from IPSec for an equivalent operation.

Robert

Robert Cragie (Pacific Gas & Electric)

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


On 10/09/2010 4:22 PM, Alexandru Petrescu wrote:
Le 10/09/2010 11:55, Robert Cragie a écrit :
David,

I totally agree with what you say. Thank you for restating generally
 that IPSec has already been extensively considered - I use = the term
 'paraphernalia' as a general term for the overheads.

Alex - can we please drop the IPSec discussion and move on and
concentrate on the things which do need to sorted out?

Ok... let me try to avoid dissent and do what you ask.

Let's come back to RPL-11 text:
3.  If the packet header specifies a= source route by including a RH4
header as specified in [I-D.ietf-6man-rpl-routing-header]

then draft-ietf-6man-rpl-routing-header-00 says:
else { swap the IPv6 Destination Address and Address[i]

That means that there is a mutable but predictable field (IPv6
Destination Addess) in RH of RPL.  But RPL Security doesn't understand
mutable but predictable fields (only mutable as per recent discussion).
 RPL Security covers "entire IPv6 packet", which changes enrou= te despite
RPL Security's expectation it won't change.

So the question is: does RPL Security secure the RH4 header?  = I think it
does not, because its MAC computation does not say how are the mutable
but predictable fields covered.

For example, a sender builds a packet with Dst address1, computes MAC,
inserts MAC.  Then intermediary routers process that packet an= d replace
that Dst address1 with address2 from the Routing Header.  Now = the packet
is received at address1.  The MAC can't be meaningfully comput= ed on the
receiver, because the "IPv6 entire packet" has changed, it is not the
same as at emission.

I think this example is correct.

It can't be solved in the same way we solved the mutability of "Hop
Limit" (we said to make HopLimit set to 0 for MAC calculation), because
if we do so then we have a higher risk of attack than when left HopLimit
unsecure.  If we set to 0 de Dst for MAC calculation then the = risk of
implication of forged IP dst addresses is higher than forged HopLimit.
Forging an IP dst address is stronger security attack than forging
HopLimit, intuitively speaking.

Besides, whereas the receiver has really no idea about what could the
original HopLimit be, it knows precisely what the original Dst address
was (it's in the RH4, swapped).  Thus the securing solution sh= ould be
different - it should be as smart as RH4 is.

Knowing the previous discussion, it may be possible that people will
request we refer to that Authentication Header RFC which tells how
mutable, mutable but predictable fields are dealt with.  At th= at point
we come back to IPsec, but I will abstain from saying so if you wish.
There is also the fact that previous IPsec talk says RH0 whereas here we
have RH4 and things may be different.

That's too long for anyone to read, but you get the point.

Alex




 You are of course
entitled to your opinion but progress is only made in the IETF
through rough consensus. Consensus does not mean unanimous agreement;
if we can all at least consent to a solution then the process will
run a lot more smoothly and we will all benefit. Continual dissent
will only serve to hinder this progress.

I think the consensus is clear:

* We do not mention IPSec in RPL security * The mutable field
discussion is entirely independent from IPSec

Robert

Robert Cragie (Pacific Gas & Electric)

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


On 09/09/2010 9:33 PM, David Culler wrote:
Dear Alex, Thank you for focusing on th= e question of routing
security, rather than internet security in general.  Yes, IPSec has
been utilized to secure routing protocols.  Now please tak= e the
next step and focus on routing for low power and lossy networks.
Obviously, IPSec has to be the first thing considered.  An= d it was.
Dating back to the earliest security framework discussions it was
considered many times.   We returned to the IPSec iss= ue extensively
back in June on the mailing list.   I won't reiterate= the
discussion on the storage and time complexity, nor the message
overhead implications that were in those prior postings.  = But I
will observe that no one suggested that they saw their way to a
full IPSec implementation within the constraints articulated in the
Routing Requirements documents.   The WG group has lo= ng since
reached a rough consensus on this matter and moved on.  Th= at is the
nature of a group process and specifically the role of WG LC.&n= bsp; At
some point, we commit to certain things and stop revisiting them
from first principles.   That allows us to focus more= sharply on
the selected approach and refine it more completely.  For example,
in security, we have specifics to resolve, such as which header
fields need to be skipped.  It is not a matter of "but I imagine
that there may be alternatives".  There might be.  Bu= t we don't
just turn the same rocks over and over again.  We carve th= e rough
stone, we chisel the details, we sand, we polish.

So I assume that the point of your posting is that you want to be
sure that the justification for the choices that the WG made are
properly documented in the WG documents.  If you feel that= they are
not, perhaps you could point to the document and section that you
feel should contain this material more substantially.

D.

For reference,http://www.ietf.org/tao.html  section 7.= 4


On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote:

Le 09/09/2010 16:59, David Culler aécrit :
The RPL charter calls for us to address routing security
considerations.  Not security in general.  Not ap= plication
security. Not link level.  Routing security.  It = is focused for
good reason.
Routing security like OSPF using IPsec? "Authentication has been
removed from the OSPF protocol and instead relies on IPv6's
Authentication Header and Encapsulating Security Payload (ESP)."
says rfc5340... why does RPL need to be different in this
respect?

Alex

On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote:

Le 08/09/2010 18:15, Philip Levis= aécrit :
On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote:

Le 03/09/2010 13:48, Robert Cragie aécrit : [skipped
agreed opinions about IPsec]
Reusing the IPsec module ensures a secure system -
it's proven by earlier experience. We know it worked
ok so why avoid using it.
<RCC>I don't think the specification of RPL security
precludes the use of IPSec instead. Does the use of
IPSec need to be specified in the RPL
specification?</RCC>
YEs, the RPL specification must say something about
security in its Security Considerations section. = ; That
something has to mention something about IPsec.
Why does it have to do so? In theory, RPL should be
entirely independent of IPSec. There have already been
numerous discussions about why simply relying on IPSec
would be problematic. Unfortunately you seem to forget
these points every few weeks and rehash the same
discussion. At some point it becomes a waste of everyone's
time.
Phil - if RPL says "security" then it must understand that
Internet security is usually IPsec.  This is truer w= ith IPv6
(as opposed to IPv4) where IPsec is very much integrated in
the design (mutable fields, etc.)

Have you checked the mutable field discussion?  Do y= ou agree
that mutable fields must be taken into account?

Please read that around 3 people agreed on a list of items
which are worth discussion of security and IPsec - mutable
fields is one such item.

As such this discussion is not a waste of everyone's time.

Alex

Phil

_______________________________________________ Roll mailing
list Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll<= /a>
David Cullerculler@cs.berkeley.edu  Chai= r Computer Science
Associate Chair EECS





David Culler culler@cs.berkeley.edu Chair Computer Scie= nce
Associate Chair EECS



_______________________________________________ Roll mailing list
Roll@ietf.org https://www.ietf.org/mailman/listinf= o/roll



_______________________________________________ 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

--------------070303040201040809040700-- --------------ms040403030608070304050109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwOTEwMTY0ODA0WjAjBgkqhkiG9w0BCQQxFgQUTdtE PCVAAP81UIbq1+ioPsG25dwwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAC0QjFHwszqO8++MWHvM1P+zw9EMMnMNiCyMR OSx0AXP7EhwkjsNKwAe9EoSbGqlYCEZNpMx4SnThqikSmVQM72OoaBPA/TA+ShC9rxs7z0zN NOhwyRevhOoh0K6KCz0FUj9MCyTi/MmkuDW8AlvRh6YxMxCuhoewNmISEgTuQtH9R9lAvHK0 YpxEzK7ITdg/kY7AuQlYwlsVFeFhSHUCfSSUsB/tCJ5GPwrMJR+l3wJRlOMhJ+G7dWfzUd85 LrrKOItOujSooErd7BDdvTPN1fQzs41h+3JBD+Ian6IRmkL7LDg2/fA0N5X5Dh0dPo3UQphO 7HqIocjFFkQNQNnnmAAAAAAAAA== --------------ms040403030608070304050109-- From alexandru.petrescu@gmail.com Fri Sep 10 10:54:45 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847E53A685C for ; Fri, 10 Sep 2010 10:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2M2olbT+kkRU for ; Fri, 10 Sep 2010 10:54:37 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 8BD923A67EB for ; Fri, 10 Sep 2010 10:54:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o8AHstZI017005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Sep 2010 19:54:55 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o8AHst3l025570; Fri, 10 Sep 2010 19:54:55 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o8AHss2r011600; Fri, 10 Sep 2010 19:54:55 +0200 Message-ID: <4C8A70EE.1050301@gmail.com> Date: Fri, 10 Sep 2010 19:54:54 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <13773.1282327971@marajade.sandelman.ca> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> <519A78D0-77BC-466C-BAFF-084DEF5D9CB5@cs.stanford.edu> <4C87C73E.1040806@gmail.com> <4C88FD45.60004@gmail.com> <8556A091-D8F9-4B6B-8F49-4260005C577C@cs.berkeley.edu> <4C8A008C.7080406@gridmerge.com> <4C8A4D19.40202@gmai l.com> <4C8A6144.1070401@gridme! rge.com> In-Reply-To: <4C8A6144.1070401@gridmerge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 10 Sep 2010 17:54:45 -0000 Le 10/09/2010 18:48, Robert Cragie a écrit : > Hi Alex, > > Thank you for focusing on a pertinent issue. You are right to highlight > what we do with a RH4 header as I believe secured DAO ACK is the (only) > RPL control message which requires RH4 in non-storing mode. Sounds reassuring to know RH4 is only for DAO ACK and only for non-storing mode. And in storing mode? Is RH4 present in other than DAO ACK? Just to make sure I understand you. > So, to follow the rules for mutable and predictable fields (see RFC > 4302), we can resubstitute at the end: > > Consider the following: > > A -> B -> C -> D -> E > > A -> B: > > |Src|Dst|RH4 | > | | |Seq|A0 |A1 |A2 | > ------------------------- > | A | B | 3 | C | D | E | > > B -> C: > > |Src|Dst|RH4 | > | | |Seq|A0 |A1 |A2 | > ------------------------- > | A | C | 2 | B | D | E | > > C -> D: > > |Src|Dst|RH4 | > | | |Seq|A0 |A1 |A2 | > ------------------------- > | A | D | 1 | B | C | E | > > D -> E: > > |Src|Dst|RH4 | > | | |Seq|A0 |A1 |A2 | > ------------------------- > | A | E | 0 | B | C | D | > > When the packet arrives at E, recreate the original RH4 header for MAC > computation: > > n = ((Hdr Ext Len * 8) - Pad) / (16 - Comp) > tmp = Dst > Dst = RH4.A[0] > RH4.Seq = n > for (k = 1; k < n; k++) > { > RH4.A[k-1] = RH4.A[k] > } > RH4.A[k] = tmp > > |Src|Dst|RH4 | > | | |Seq|L0 |L1 |L2 | > ------------------------- > | A | B | 3 | C | D | E | > > Is that acceptable? Thanks for the method - it reads reasonable. It is a good way (one way? are there others? are there little bugs in that code?) to specify MAC over RH4 coherently - reconstruct the RH at reception. This solution is different than solving the mutability of the Hop Limit field. Can we see further - RH4 draft also says IPv6-in-IPv6 tunnelling must be used sometime, together with RH4. This raises the obvious question about: is the header of the encapsulating packet also protected by the MAC of RPL? Or not? RPL spec currently says the "entire IPv6 packet" is covered by its MAC. But does that cover the IPv6 base header of the encapsulating header? Or not? And in which order? > Now, just because I refer to IPSec AH, it doesn't mean I am suggesting > we use it. I am suggesting we can use the fundamental principles from > IPSec for an equivalent operation. I understand. I am just afraid sometimes we try to rewrite much parts of it. For example, I wonder how to you plan to refer to that RFC document? Just wondering. Alex > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com > > > On 10/09/2010 4:22 PM, Alexandru Petrescu wrote: >> Le 10/09/2010 11:55, Robert Cragie a écrit : >>> David, >>> >>> I totally agree with what you say. Thank you for restating generally >>> that IPSec has already been extensively considered - I use the term >>> 'paraphernalia' as a general term for the overheads. >>> >>> Alex - can we please drop the IPSec discussion and move on and >>> concentrate on the things which do need to sorted out? >> >> Ok... let me try to avoid dissent and do what you ask. >> >> Let's come back to RPL-11 text: >>> 3. If the packet header specifies a source route by including a RH4 >>> header as specified in [I-D.ietf-6man-rpl-routing-header] >> >> then draft-ietf-6man-rpl-routing-header-00 says: >>> else { swap the IPv6 Destination Address and Address[i] >> >> That means that there is a mutable but predictable field (IPv6 >> Destination Addess) in RH of RPL. But RPL Security doesn't understand >> mutable but predictable fields (only mutable as per recent discussion). >> RPL Security covers "entire IPv6 packet", which changes enroute despite >> RPL Security's expectation it won't change. >> >> So the question is: does RPL Security secure the RH4 header? I think it >> does not, because its MAC computation does not say how are the mutable >> but predictable fields covered. >> >> For example, a sender builds a packet with Dst address1, computes MAC, >> inserts MAC. Then intermediary routers process that packet and replace >> that Dst address1 with address2 from the Routing Header. Now the packet >> is received at address1. The MAC can't be meaningfully computed on the >> receiver, because the "IPv6 entire packet" has changed, it is not the >> same as at emission. >> >> I think this example is correct. >> >> It can't be solved in the same way we solved the mutability of "Hop >> Limit" (we said to make HopLimit set to 0 for MAC calculation), because >> if we do so then we have a higher risk of attack than when left HopLimit >> unsecure. If we set to 0 de Dst for MAC calculation then the risk of >> implication of forged IP dst addresses is higher than forged HopLimit. >> Forging an IP dst address is stronger security attack than forging >> HopLimit, intuitively speaking. >> >> Besides, whereas the receiver has really no idea about what could the >> original HopLimit be, it knows precisely what the original Dst address >> was (it's in the RH4, swapped). Thus the securing solution should be >> different - it should be as smart as RH4 is. >> >> Knowing the previous discussion, it may be possible that people will >> request we refer to that Authentication Header RFC which tells how >> mutable, mutable but predictable fields are dealt with. At that point >> we come back to IPsec, but I will abstain from saying so if you wish. >> There is also the fact that previous IPsec talk says RH0 whereas here we >> have RH4 and things may be different. >> >> That's too long for anyone to read, but you get the point. >> >> Alex >> >> >> >> >> You are of course >>> entitled to your opinion but progress is only made in the IETF >>> through rough consensus. Consensus does not mean unanimous agreement; >>> if we can all at least consent to a solution then the process will >>> run a lot more smoothly and we will all benefit. Continual dissent >>> will only serve to hinder this progress. >>> >>> I think the consensus is clear: >>> >>> * We do not mention IPSec in RPL security * The mutable field >>> discussion is entirely independent from IPSec >>> >>> Robert >>> >>> Robert Cragie (Pacific Gas & Electric) >>> >>> Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 >>> 1924 910888 +1 415 513 0064 http://www.gridmerge.com >>> >>> >>> >>> On 09/09/2010 9:33 PM, David Culler wrote: >>>> Dear Alex, Thank you for focusing on the question of routing >>>> security, rather than internet security in general. Yes, IPSec has >>>> been utilized to secure routing protocols. Now please take the >>>> next step and focus on routing for low power and lossy networks. >>>> Obviously, IPSec has to be the first thing considered. And it was. >>>> Dating back to the earliest security framework discussions it was >>>> considered many times. We returned to the IPSec issue extensively >>>> back in June on the mailing list. I won't reiterate the >>>> discussion on the storage and time complexity, nor the message >>>> overhead implications that were in those prior postings. But I >>>> will observe that no one suggested that they saw their way to a >>>> full IPSec implementation within the constraints articulated in the >>>> Routing Requirements documents. The WG group has long since >>>> reached a rough consensus on this matter and moved on. That is the >>>> nature of a group process and specifically the role of WG LC. At >>>> some point, we commit to certain things and stop revisiting them >>>> from first principles. That allows us to focus more sharply on >>>> the selected approach and refine it more completely. For example, >>>> in security, we have specifics to resolve, such as which header >>>> fields need to be skipped. It is not a matter of "but I imagine >>>> that there may be alternatives". There might be. But we don't >>>> just turn the same rocks over and over again. We carve the rough >>>> stone, we chisel the details, we sand, we polish. >>>> >>>> So I assume that the point of your posting is that you want to be >>>> sure that the justification for the choices that the WG made are >>>> properly documented in the WG documents. If you feel that they are >>>> not, perhaps you could point to the document and section that you >>>> feel should contain this material more substantially. >>>> >>>> D. >>>> >>>> For reference,http://www.ietf.org/tao.html section 7.4 >>>> >>>> >>>> On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote: >>>> >>>>> Le 09/09/2010 16:59, David Culler aécrit : >>>>>> The RPL charter calls for us to address routing security >>>>>> considerations. Not security in general. Not application >>>>>> security. Not link level. Routing security. It is focused for >>>>>> good reason. >>>>> Routing security like OSPF using IPsec? "Authentication has been >>>>> removed from the OSPF protocol and instead relies on IPv6's >>>>> Authentication Header and Encapsulating Security Payload (ESP)." >>>>> says rfc5340... why does RPL need to be different in this >>>>> respect? >>>>> >>>>> Alex >>>>> >>>>>> On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote: >>>>>> >>>>>>> Le 08/09/2010 18:15, Philip Levis aécrit : >>>>>>>> On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote: >>>>>>>> >>>>>>>>> Le 03/09/2010 13:48, Robert Cragie aécrit : [skipped >>>>>>>>> agreed opinions about IPsec] >>>>>>>>>>> Reusing the IPsec module ensures a secure system - >>>>>>>>>>> it's proven by earlier experience. We know it worked >>>>>>>>>>> ok so why avoid using it. >>>>>>>>>> I don't think the specification of RPL security >>>>>>>>>> precludes the use of IPSec instead. Does the use of >>>>>>>>>> IPSec need to be specified in the RPL >>>>>>>>>> specification? >>>>>>>>> YEs, the RPL specification must say something about >>>>>>>>> security in its Security Considerations section. That >>>>>>>>> something has to mention something about IPsec. >>>>>>>> Why does it have to do so? In theory, RPL should be >>>>>>>> entirely independent of IPSec. There have already been >>>>>>>> numerous discussions about why simply relying on IPSec >>>>>>>> would be problematic. Unfortunately you seem to forget >>>>>>>> these points every few weeks and rehash the same >>>>>>>> discussion. At some point it becomes a waste of everyone's >>>>>>>> time. >>>>>>> Phil - if RPL says "security" then it must understand that >>>>>>> Internet security is usually IPsec. This is truer with IPv6 >>>>>>> (as opposed to IPv4) where IPsec is very much integrated in >>>>>>> the design (mutable fields, etc.) >>>>>>> >>>>>>> Have you checked the mutable field discussion? Do you agree >>>>>>> that mutable fields must be taken into account? >>>>>>> >>>>>>> Please read that around 3 people agreed on a list of items >>>>>>> which are worth discussion of security and IPsec - mutable >>>>>>> fields is one such item. >>>>>>> >>>>>>> As such this discussion is not a waste of everyone's time. >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>>> Phil >>>>>>> >>>>>>> _______________________________________________ Roll mailing >>>>>>> list Roll@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>> David Cullerculler@cs.berkeley.edu Chair Computer Science >>>>>> Associate Chair EECS >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> David Culler culler@cs.berkeley.edu Chair Computer Science >>>> Associate Chair EECS >>>> >>>> >>>> >>>> _______________________________________________ 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 >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> From joakime@sics.se Sat Sep 11 01:29:47 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC3C3A68BF for ; Sat, 11 Sep 2010 01:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_05=-1.11, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSPRUnpC1qTW for ; Sat, 11 Sep 2010 01:29:46 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 087963A68A7 for ; Sat, 11 Sep 2010 01:29:45 -0700 (PDT) Received: from [192.168.1.3] (c-9214e455.013-276-73746f7.cust.bredbandsbolaget.se [85.228.20.146]) (Authenticated sender: joakime@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 19356400E6; Sat, 11 Sep 2010 10:30:11 +0200 (CEST) Message-ID: <4C8B3E18.2050308@sics.se> Date: Sat, 11 Sep 2010 10:30:16 +0200 From: Joakim Eriksson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: roll@ietf.org References: <20100818222846.13825.49680.idtracker@localhost> <4C8732D9.5010809@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] Last Call: (RPL: IPv6 RoutingProtocol for Low power and Lossy Networks) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 11 Sep 2010 08:29:47 -0000 Hello, I read the "RPL Constants and Variables" again and it feels like some values might not be appropriate for the networks RPL is targeting. Consider the following constants: DEFAULT_DIO_INTERVAL_MIN => 8 ms DEFAULT_DIO_REDUNDANCY_CONSTANT = 10 These values correspond to 4 ms sending time and 10 packets (DIO) to send during that time. If am not wrong 4ms in 802.15.4 roughly correspond to a full radio packet (~125 bytes). This means that it will not at all be possible to send 10 packets (nor receive and handle 10 packets) during 4 ms. My belief was that these default values should be reasonable values for the types of networks the specific protocol was aimed at, but now it seems like RPL is aiming at Ethernet (10Mbit maybe?) networks? Given that many of the protocols (MAC/Duty-cycling) above the 802.15.4 PHY will either do duty cycling or TDMA (TSMP) it is even worse. I would say that a more reasonable minimum interval would be closer to a second. Best regards, -- Joakim Eriksson, SICS From yoav@yitran.com Sat Sep 11 01:47:59 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C91623A6887 for ; Sat, 11 Sep 2010 01:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.276 X-Spam-Level: X-Spam-Status: No, score=-6.276 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRjDMsJSAZg9 for ; Sat, 11 Sep 2010 01:47:54 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id 6676A3A63C9 for ; Sat, 11 Sep 2010 01:47:54 -0700 (PDT) Received: from source ([209.85.214.52]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTItCVelTodPArlm7+G9glpe0GUdUOTUd@postini.com; Sat, 11 Sep 2010 01:48:21 PDT Received: by mail-bw0-f52.google.com with SMTP id 5so3889096bwz.39 for ; Sat, 11 Sep 2010 01:48:21 -0700 (PDT) Received: by 10.204.120.79 with SMTP id c15mr1302772bkr.188.1284194892759; Sat, 11 Sep 2010 01:48:12 -0700 (PDT) From: Yoav Ben-Yehezkel References: <20100818222846.13825.49680.idtracker@localhost> <4C8732D9.5010809@gmail.com> <4C8B3E18.2050308@sics.se> In-Reply-To: <4C8B3E18.2050308@sics.se> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActRi5J6PeoM+EwKQLmFNTdR86mnwwAAfmjw Date: Sat, 11 Sep 2010 11:48:16 +0300 Message-ID: <008faa3823b41320b1f9693abef73481@mail.gmail.com> To: Joakim Eriksson , roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Roll] Last Call: (RPL: IPv6 RoutingProtocol for Low power and Lossy Networks) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 11 Sep 2010 08:47:59 -0000 +1 The recommendation in the trickle draft is 4 times the worst case L2 latency. I think this should not be a constant at all, as RPL is not intended for 802.15.4 networks only. See below trickle draft reference: " 5. Using Trickle A protocol specification that uses Trickle MUST specify: o Default values for Imin, Imax, and k. Because link layers can vary widely in their properties, the default value of Imin SHOULD be specified in terms of the worst-case latency of a link layer transmission. For example, a specification should say "the default value of Imin is 4 times the worst case link layer latency" and should not say "the default value of Imin is 500 milliseconds." Worst case latency is approximately time until the first link-layer transmission of the frame assuming an idle channel (does not include backoff, virtual carrier sense, etc.). ... " Thanks, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Joakim Eriksson Sent: Saturday, September 11, 2010 11:30 AM To: roll@ietf.org Subject: Re: [Roll] Last Call: (RPL: IPv6 RoutingProtocol for Low power and Lossy Networks) to Proposed Standard Hello, I read the "RPL Constants and Variables" again and it feels like some values might not be appropriate for the networks RPL is targeting. Consider the following constants: DEFAULT_DIO_INTERVAL_MIN => 8 ms DEFAULT_DIO_REDUNDANCY_CONSTANT = 10 These values correspond to 4 ms sending time and 10 packets (DIO) to send during that time. If am not wrong 4ms in 802.15.4 roughly correspond to a full radio packet (~125 bytes). This means that it will not at all be possible to send 10 packets (nor receive and handle 10 packets) during 4 ms. My belief was that these default values should be reasonable values for the types of networks the specific protocol was aimed at, but now it seems like RPL is aiming at Ethernet (10Mbit maybe?) networks? Given that many of the protocols (MAC/Duty-cycling) above the 802.15.4 PHY will either do duty cycling or TDMA (TSMP) it is even worse. I would say that a more reasonable minimum interval would be closer to a second. Best regards, -- Joakim Eriksson, SICS _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From coflynn@newae.com Sat Sep 11 02:27:01 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84D23A67F0 for ; Sat, 11 Sep 2010 02:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.273 X-Spam-Level: X-Spam-Status: No, score=0.273 tagged_above=-999 required=5 tests=[AWL=-2.128, BAYES_00=-2.599, GB_SUMOF=5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZoQ7LELQFn1 for ; Sat, 11 Sep 2010 02:27:00 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 42AB03A659B for ; Sat, 11 Sep 2010 02:27:00 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1OuMMn-0000bE-Jm; Sat, 11 Sep 2010 05:27:26 -0400 From: "Colin O'Flynn" To: "'Joakim Eriksson'" , References: <20100818222846.13825.49680.idtracker@localhost> <4C8732D9.5010809@gmail.com> <4C8B3E18.2050308@sics.se> In-Reply-To: <4C8B3E18.2050308@sics.se> Date: Sat, 11 Sep 2010 10:27:16 +0100 Message-ID: <000301cb5193$8969dd50$9c3d97f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActRi5FJL2WjySt5SfixBuIZhaJY8wAAaN2g Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Roll] Last Call: (RPL: IPv6 RoutingProtocol for Low power and Lossy Networks) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 11 Sep 2010 09:27:02 -0000 Hi Joakim, I agree with you here. FWIW I think it would also be useful to have a description in Trickle similar to what is in Levis04 to clearly example how the Trickle constants link to the transmissions. From Levis04 (with tau changed to I): Using the Trickle algorithm, each mote broadcasts a summary of its data at most once per period I . If a mote hears k motes with the same program before it transmits, it suppresses its own transmission. In perfect network conditions - a lossless, single-hop topology - there will be k transmissions every I . If there are n motes and m non-interfering single-hop networks, there will be km transmissions, which is independent of n. Instead of fixing the per-mote send rate, Trickle dynamically regulates its send rate to the network density to meet a communication rate, requiring no a priori assumptions on the topology. In each interval I , the sum of receptions and sends of each mote is k. I think confusion on exactly what the end result of the Trickle timer should be has hampered people testing the constants "properly". Regards, -Colin -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Joakim Eriksson Sent: September 11, 2010 9:30 AM To: roll@ietf.org Subject: Re: [Roll] Last Call: (RPL: IPv6 RoutingProtocol for Low power and Lossy Networks) to Proposed Standard Hello, I read the "RPL Constants and Variables" again and it feels like some values might not be appropriate for the networks RPL is targeting. Consider the following constants: DEFAULT_DIO_INTERVAL_MIN => 8 ms DEFAULT_DIO_REDUNDANCY_CONSTANT = 10 These values correspond to 4 ms sending time and 10 packets (DIO) to send during that time. If am not wrong 4ms in 802.15.4 roughly correspond to a full radio packet (~125 bytes). This means that it will not at all be possible to send 10 packets (nor receive and handle 10 packets) during 4 ms. My belief was that these default values should be reasonable values for the types of networks the specific protocol was aimed at, but now it seems like RPL is aiming at Ethernet (10Mbit maybe?) networks? Given that many of the protocols (MAC/Duty-cycling) above the 802.15.4 PHY will either do duty cycling or TDMA (TSMP) it is even worse. I would say that a more reasonable minimum interval would be closer to a second. Best regards, -- Joakim Eriksson, SICS _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From c.chauvenet@watteco.com Sat Sep 11 13:43:29 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D73013A67DB for ; Sat, 11 Sep 2010 13:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIbDvhkR22Kr for ; Sat, 11 Sep 2010 13:43:27 -0700 (PDT) Received: from mail.abrisite.fr (mx197.abrisite.fr [85.31.209.197]) by core3.amsl.com (Postfix) with ESMTP id 316133A66B4 for ; Sat, 11 Sep 2010 13:43:26 -0700 (PDT) Received: from [192.168.0.3] ([78.232.65.23]) by mail.abrisite.fr (POL Mail Securise v2.0) with ASMTP id TDC15649; Sat, 11 Sep 2010 22:43:49 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Chauvenet_C=E9dric?= In-Reply-To: <4C8B3E18.2050308@sics.se> Date: Sat, 11 Sep 2010 22:43:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <66F4D5E4-2DDB-4E34-9FAC-DF5762CF3C0A@watteco.com> References: <20100818222846.13825.49680.idtracker@localhost> <4C8732D9.5010809@gmail.com> <4C8B3E18.2050308@sics.se> To: Joakim Eriksson X-Mailer: Apple Mail (2.1081) Cc: roll@ietf.org Subject: Re: [Roll] Last Call: (RPL: IPv6 RoutingProtocol for Low power and Lossy Networks) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 11 Sep 2010 20:43:29 -0000 Hi Joakim,=20 I totally agree with your point. 4 ms is a very narrow time for LLNs. A static value seems unsuitable here, considering various data-rate and = MAC protocols. The Trickle reference Yoav pointed out sounds better. Regards, C=E9dric CHAUVENET. Le 11 sept. 2010 =E0 10:30, Joakim Eriksson a =E9crit : > Hello, >=20 > I read the "RPL Constants and Variables" again and it feels like > some values might not be appropriate for the networks RPL is > targeting. Consider the following constants: >=20 > DEFAULT_DIO_INTERVAL_MIN =3D> 8 ms >=20 > DEFAULT_DIO_REDUNDANCY_CONSTANT =3D 10 >=20 > These values correspond to 4 ms sending time and 10 > packets (DIO) to send during that time. > If am not wrong 4ms in 802.15.4 roughly correspond to > a full radio packet (~125 bytes). This means that it > will not at all be possible to send 10 packets (nor > receive and handle 10 packets) during 4 ms. >=20 > My belief was that these default values should be > reasonable values for the types of networks the specific > protocol was aimed at, but now it seems like RPL is aiming > at Ethernet (10Mbit maybe?) networks? >=20 > Given that many of the protocols (MAC/Duty-cycling) above the > 802.15.4 PHY will either do duty cycling or TDMA (TSMP) it is > even worse. I would say that a more reasonable minimum interval > would be closer to a second. >=20 >=20 > Best regards, > -- Joakim Eriksson, SICS > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From robert.cragie@gridmerge.com Mon Sep 13 03:50:58 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 637D33A6969 for ; Mon, 13 Sep 2010 03:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gk1+wSHV+va0 for ; Mon, 13 Sep 2010 03:50:55 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 6607C3A695A for ; Mon, 13 Sep 2010 03:50:53 -0700 (PDT) Received: from client-86-27-28-240.glfd.adsl.virginmedia.com ([86.27.28.240] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1Ov6d4-0007L8-07; Mon, 13 Sep 2010 11:51:19 +0100 Message-ID: <4C8E0226.3000101@gridmerge.com> Date: Mon, 13 Sep 2010 11:51:18 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: Alexandru Petrescu References: <13773.1282327971@marajade.sandelman.ca> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> <519A78D0-77BC-466C-BAFF-084DEF5D9CB5@cs.stanford.edu> <4C87C73E.1040806@gmail.com> <4C88FD45.60004@gmail.com> <8556A091-D8F9-4B6B-8F49-4260005C577C@cs.berkeley.edu> <4C8A008C.7080406@gridmerge.com> <4C8A4D19.40202@gmai l.com> <4C8A6144.1070401@gridme! rge.com> <4C8A70EE.1050301@gmail.com> In-Reply-To: <4C8A70EE.1050301@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000301030605050404080105" Cc: roll@ietf.org Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 10:50:58 -0000 This is a cryptographically signed message in MIME format. --------------ms000301030605050404080105 Content-Type: multipart/alternative; boundary="------------010603070906020300050900" This is a multi-part message in MIME format. --------------010603070906020300050900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Alex, Comments inline, bracketed by Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 10/09/2010 6:54 PM, Alexandru Petrescu wrote: > Le 10/09/2010 18:48, Robert Cragie a =E9crit : >> Hi Alex, >> >> Thank you for focusing on a pertinent issue. You are right to highligh= t >> what we do with a RH4 header as I believe secured DAO ACK is the (only= ) >> RPL control message which requires RH4 in non-storing mode. > > Sounds reassuring to know RH4 is only for DAO ACK and only for > non-storing mode. > > And in storing mode? Is RH4 present in other than DAO ACK? Just to make= > sure I understand you. Here is my analysis (please correct if wrong): * Storing mode doesn't require the RH4 header as there is no need to carry the routing information. * DIS is one hop (link local) * DIO is multicast * DAO is routed up the DODAG to the root therefore is not source rout= ed * That leaves DAO ACK in storing mode > >> So, to follow the rules for mutable and predictable fields (see RFC >> 4302), we can resubstitute at the end: >> >> Consider the following: >> >> A -> B -> C -> D -> E >> >> A -> B: >> >> |Src|Dst|RH4 | >> | | |Seq|A0 |A1 |A2 | >> ------------------------- >> | A | B | 3 | C | D | E | >> >> B -> C: >> >> |Src|Dst|RH4 | >> | | |Seq|A0 |A1 |A2 | >> ------------------------- >> | A | C | 2 | B | D | E | >> >> C -> D: >> >> |Src|Dst|RH4 | >> | | |Seq|A0 |A1 |A2 | >> ------------------------- >> | A | D | 1 | B | C | E | >> >> D -> E: >> >> |Src|Dst|RH4 | >> | | |Seq|A0 |A1 |A2 | >> ------------------------- >> | A | E | 0 | B | C | D | >> >> When the packet arrives at E, recreate the original RH4 header for MAC= >> computation: >> >> n =3D ((Hdr Ext Len * 8) - Pad) / (16 - Comp) >> tmp =3D Dst >> Dst =3D RH4.A[0] >> RH4.Seq =3D n >> for (k =3D 1; k < n; k++) >> { >> RH4.A[k-1] =3D RH4.A[k] >> } >> RH4.A[k] =3D tmp >> >> |Src|Dst|RH4 | >> | | |Seq|L0 |L1 |L2 | >> ------------------------- >> | A | B | 3 | C | D | E | >> >> Is that acceptable? > > Thanks for the method - it reads reasonable. It is a good way (one=20 > way? are there others? are there little bugs in that code?) Probably :-) > to specify MAC over RH4 coherently - reconstruct the RH at reception. = > This solution is different than solving the mutability of the Hop=20 > Limit field. It is the method stated in RFC 4302 section 3.3.3.1. The fields in = this case are predictable this can be reconstructed, as RH4 is similar=20 to RH0 which is listed in Appendix A.2 as mutable but predictable. So,=20 reading this actually suggests the MAC should be computed based on what=20 the final destination will see - it is fundamentally the same=20 principle. > > Can we see further - RH4 draft also says IPv6-in-IPv6 tunnelling must=20 > be used sometime, together with RH4. This raises the obvious question = > about: is the header of the encapsulating packet also protected by the = > MAC of RPL? Or not? Not for DAO ACK as it is wholly within the RPL domain (case 1 in=20 Section 2 of=20 http://tools.ietf.org/html/draft-ietf-6man-rpl-routing-header-00) > > RPL spec currently says the "entire IPv6 packet" is covered by its=20 > MAC. But does that cover the IPv6 base header of the encapsulating=20 > header? Or not? And in which order? It doesn't apply in this case. > >> Now, just because I refer to IPSec AH, it doesn't mean I am suggesting= >> we use it. I am suggesting we can use the fundamental principles from >> IPSec for an equivalent operation. > > I understand. I am just afraid sometimes we try to rewrite much parts = > of it. > > For example, I wonder how to you plan to refer to that RFC document?=20 > Just wondering. I don't think there is any need to refer to RFC 4302. The=20 fundamental principles regarding mutable fields are general and do not=20 apply solely to IPSec. On the other hand, it would help to be explicit=20 in the RPL draft regarding mutability but I think that is already=20 agreed. > > Alex > >> >> Robert >> >> Robert Cragie (Pacific Gas & Electric) >> >> Gridmerge Ltd. >> 89 Greenfield Crescent, >> Wakefield, WF4 4WA, UK >> +44 1924 910888 >> +1 415 513 0064 >> http://www.gridmerge.com >> >> >> On 10/09/2010 4:22 PM, Alexandru Petrescu wrote: >>> Le 10/09/2010 11:55, Robert Cragie a =E9crit : >>>> David, >>>> >>>> I totally agree with what you say. Thank you for restating generally= >>>> that IPSec has already been extensively considered - I use the term >>>> 'paraphernalia' as a general term for the overheads. >>>> >>>> Alex - can we please drop the IPSec discussion and move on and >>>> concentrate on the things which do need to sorted out? >>> >>> Ok... let me try to avoid dissent and do what you ask. >>> >>> Let's come back to RPL-11 text: >>>> 3. If the packet header specifies a source route by including a RH4 >>>> header as specified in [I-D.ietf-6man-rpl-routing-header] >>> >>> then draft-ietf-6man-rpl-routing-header-00 says: >>>> else { swap the IPv6 Destination Address and Address[i] >>> >>> That means that there is a mutable but predictable field (IPv6 >>> Destination Addess) in RH of RPL. But RPL Security doesn't understand= >>> mutable but predictable fields (only mutable as per recent discussion= ). >>> RPL Security covers "entire IPv6 packet", which changes enroute despi= te >>> RPL Security's expectation it won't change. >>> >>> So the question is: does RPL Security secure the RH4 header? I think = it >>> does not, because its MAC computation does not say how are the mutabl= e >>> but predictable fields covered. >>> >>> For example, a sender builds a packet with Dst address1, computes MAC= , >>> inserts MAC. Then intermediary routers process that packet and replac= e >>> that Dst address1 with address2 from the Routing Header. Now the pack= et >>> is received at address1. The MAC can't be meaningfully computed on th= e >>> receiver, because the "IPv6 entire packet" has changed, it is not the= >>> same as at emission. >>> >>> I think this example is correct. >>> >>> It can't be solved in the same way we solved the mutability of "Hop >>> Limit" (we said to make HopLimit set to 0 for MAC calculation), becau= se >>> if we do so then we have a higher risk of attack than when left=20 >>> HopLimit >>> unsecure. If we set to 0 de Dst for MAC calculation then the risk of >>> implication of forged IP dst addresses is higher than forged HopLimit= =2E >>> Forging an IP dst address is stronger security attack than forging >>> HopLimit, intuitively speaking. >>> >>> Besides, whereas the receiver has really no idea about what could the= >>> original HopLimit be, it knows precisely what the original Dst addres= s >>> was (it's in the RH4, swapped). Thus the securing solution should be >>> different - it should be as smart as RH4 is. >>> >>> Knowing the previous discussion, it may be possible that people will >>> request we refer to that Authentication Header RFC which tells how >>> mutable, mutable but predictable fields are dealt with. At that point= >>> we come back to IPsec, but I will abstain from saying so if you wish.= >>> There is also the fact that previous IPsec talk says RH0 whereas=20 >>> here we >>> have RH4 and things may be different. >>> >>> That's too long for anyone to read, but you get the point. >>> >>> Alex >>> >>> >>> >>> >>> You are of course >>>> entitled to your opinion but progress is only made in the IETF >>>> through rough consensus. Consensus does not mean unanimous agreement= ; >>>> if we can all at least consent to a solution then the process will >>>> run a lot more smoothly and we will all benefit. Continual dissent >>>> will only serve to hinder this progress. >>>> >>>> I think the consensus is clear: >>>> >>>> * We do not mention IPSec in RPL security * The mutable field >>>> discussion is entirely independent from IPSec >>>> >>>> Robert >>>> >>>> Robert Cragie (Pacific Gas & Electric) >>>> >>>> Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 >>>> 1924 910888 +1 415 513 0064 http://www.gridmerge.com >>>> >>>> >>>> >>>> On 09/09/2010 9:33 PM, David Culler wrote: >>>>> Dear Alex, Thank you for focusing on the question of routing >>>>> security, rather than internet security in general. Yes, IPSec has >>>>> been utilized to secure routing protocols. Now please take the >>>>> next step and focus on routing for low power and lossy networks. >>>>> Obviously, IPSec has to be the first thing considered. And it was. >>>>> Dating back to the earliest security framework discussions it was >>>>> considered many times. We returned to the IPSec issue extensively >>>>> back in June on the mailing list. I won't reiterate the >>>>> discussion on the storage and time complexity, nor the message >>>>> overhead implications that were in those prior postings. But I >>>>> will observe that no one suggested that they saw their way to a >>>>> full IPSec implementation within the constraints articulated in the= >>>>> Routing Requirements documents. The WG group has long since >>>>> reached a rough consensus on this matter and moved on. That is the >>>>> nature of a group process and specifically the role of WG LC. At >>>>> some point, we commit to certain things and stop revisiting them >>>>> from first principles. That allows us to focus more sharply on >>>>> the selected approach and refine it more completely. For example, >>>>> in security, we have specifics to resolve, such as which header >>>>> fields need to be skipped. It is not a matter of "but I imagine >>>>> that there may be alternatives". There might be. But we don't >>>>> just turn the same rocks over and over again. We carve the rough >>>>> stone, we chisel the details, we sand, we polish. >>>>> >>>>> So I assume that the point of your posting is that you want to be >>>>> sure that the justification for the choices that the WG made are >>>>> properly documented in the WG documents. If you feel that they are >>>>> not, perhaps you could point to the document and section that you >>>>> feel should contain this material more substantially. >>>>> >>>>> D. >>>>> >>>>> For reference,http://www.ietf.org/tao.html section 7.4 >>>>> >>>>> >>>>> On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote: >>>>> >>>>>> Le 09/09/2010 16:59, David Culler a=E9crit : >>>>>>> The RPL charter calls for us to address routing security >>>>>>> considerations. Not security in general. Not application >>>>>>> security. Not link level. Routing security. It is focused for >>>>>>> good reason. >>>>>> Routing security like OSPF using IPsec? "Authentication has been >>>>>> removed from the OSPF protocol and instead relies on IPv6's >>>>>> Authentication Header and Encapsulating Security Payload (ESP)." >>>>>> says rfc5340... why does RPL need to be different in this >>>>>> respect? >>>>>> >>>>>> Alex >>>>>> >>>>>>> On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote: >>>>>>> >>>>>>>> Le 08/09/2010 18:15, Philip Levis a=E9crit : >>>>>>>>> On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote: >>>>>>>>> >>>>>>>>>> Le 03/09/2010 13:48, Robert Cragie a=E9crit : [skipped >>>>>>>>>> agreed opinions about IPsec] >>>>>>>>>>>> Reusing the IPsec module ensures a secure system - >>>>>>>>>>>> it's proven by earlier experience. We know it worked >>>>>>>>>>>> ok so why avoid using it. >>>>>>>>>>> I don't think the specification of RPL security >>>>>>>>>>> precludes the use of IPSec instead. Does the use of >>>>>>>>>>> IPSec need to be specified in the RPL >>>>>>>>>>> specification? >>>>>>>>>> YEs, the RPL specification must say something about >>>>>>>>>> security in its Security Considerations section. That >>>>>>>>>> something has to mention something about IPsec. >>>>>>>>> Why does it have to do so? In theory, RPL should be >>>>>>>>> entirely independent of IPSec. There have already been >>>>>>>>> numerous discussions about why simply relying on IPSec >>>>>>>>> would be problematic. Unfortunately you seem to forget >>>>>>>>> these points every few weeks and rehash the same >>>>>>>>> discussion. At some point it becomes a waste of everyone's >>>>>>>>> time. >>>>>>>> Phil - if RPL says "security" then it must understand that >>>>>>>> Internet security is usually IPsec. This is truer with IPv6 >>>>>>>> (as opposed to IPv4) where IPsec is very much integrated in >>>>>>>> the design (mutable fields, etc.) >>>>>>>> >>>>>>>> Have you checked the mutable field discussion? Do you agree >>>>>>>> that mutable fields must be taken into account? >>>>>>>> >>>>>>>> Please read that around 3 people agreed on a list of items >>>>>>>> which are worth discussion of security and IPsec - mutable >>>>>>>> fields is one such item. >>>>>>>> >>>>>>>> As such this discussion is not a waste of everyone's time. >>>>>>>> >>>>>>>> Alex >>>>>>>> >>>>>>>>> Phil >>>>>>>> >>>>>>>> _______________________________________________ Roll mailing >>>>>>>> list Roll@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>> David Cullerculler@cs.berkeley.edu Chair Computer Science >>>>>>> Associate Chair EECS >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> David Culler culler@cs.berkeley.edu Chair Computer Science >>>>> Associate Chair EECS >>>>> >>>>> >>>>> >>>>> _______________________________________________ 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 >>> >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> > > > --------------010603070906020300050900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex,

Comments inline, bracketed by <RCC2></RCC2>

Robert

Robert Cragie (Pacific Gas & Electric)

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


On 10/09/2010 6:54 PM, Alexandru Petrescu wrote:
Le 10/09/2010 18:48, Robert Cragie a écrit :
  Hi Alex,

Thank you for focusing on a pertinent issue. You are right to highlight
what we do with a RH4 header as I believe secured DAO ACK is the (only)
RPL control message which requires RH4 in non-storing mode.

Sounds reassuring to know RH4 is only for DAO ACK and only for
non-storing mode.

And in storing mode? Is RH4 present in other than DAO ACK? Just to make
sure I understand you.
<RCC2>
Here is my analysis (please correct if wrong):
  • Storing mode doesn't require the RH4 header as there is no need to carry the routing information.
  • DIS is one hop (link local)
  • DIO is multicast
  • DAO is routed up the DODAG to the root therefore is not source routed
  • That leaves DAO ACK in storing mode
</RCC2>

So, to follow the rules for mutable and predictable fields (see RFC
4302), we can resubstitute at the end:

Consider the following:

A -> B -> C -> D -> E

A -> B:

|Src|Dst|RH4 |
| | |Seq|A0 |A1 |A2 |
-------------------------
| A | B | 3 | C | D | E |

B -> C:

|Src|Dst|RH4 |
| | |Seq|A0 |A1 |A2 |
-------------------------
| A | C | 2 | B | D | E |

C -> D:

|Src|Dst|RH4 |
| | |Seq|A0 |A1 |A2 |
-------------------------
| A | D | 1 | B | C | E |

D -> E:

|Src|Dst|RH4 |
| | |Seq|A0 |A1 |A2 |
-------------------------
| A | E | 0 | B | C | D |

When the packet arrives at E, recreate the original RH4 header for MAC
computation:

n =3D ((Hdr Ext Len * 8) - Pad) / (16 - Comp)
tmp =3D Dst
Dst =3D RH4.A[0]
RH4.Seq =3D n
for (k =3D 1; k < n; k++)
{
RH4.A[k-1] =3D RH4.A[k]
}
RH4.A[k] =3D tmp

|Src|Dst|RH4 |
| | |Seq|L0 |L1 |L2 |
-------------------------
| A | B | 3 | C | D | E |

Is that acceptable?

Thanks for the method - it reads reasonable.  It is a good way= (one way?  are there others? are there little bugs in that cod= e?)
<RCC2>Probably :-)</RCC2>
to= specify MAC over RH4 coherently - reconstruct the RH at reception.  This solution is different than solving the mutabi= lity of the Hop Limit field.
<RCC2>It is the method stated in RFC 4302 section 3.3.3.1. The fields in this case are predictable this can be reconstructed, as RH4 is similar to RH0 which is listed in Appendix A.2 as mutable but predictable. So, reading this actually suggests the MAC should be computed based on what the final destination will see - it is fundamentally the same principle.</RCC2>

Can we see further - RH4 draft also says IPv6-in-IPv6 tunnelling must be used sometime, together with RH4.  This raises the obv= ious question about: is the header of the encapsulating packet also protected by the MAC of RPL?  Or not?
<RCC2>Not for DAO ACK as it is wholly within the RPL domain (case 1 in Section 2 of http://tools.ietf.org/html/draft-ietf-6man-rpl-routing-header-00)</RCC2>

RPL spec currently says the "entire IPv6 packet" is covered by its MAC.  But does that cover the IPv6 base header of the encapsulating header?  Or not?  And in which order?
<RCC2>It doesn't apply  in this case.</RCC2>

Now, just because I refer to IPSec AH, it= doesn't mean I am suggesting
we use it. I am suggesting we can use the fundamental principles from
IPSec for an equivalent operation.

I understand.  I am just afraid sometimes we try to rewrite mu= ch parts of it.

For example, I wonder how to you plan to refer to that RFC document? Just wondering.
<RCC2>I don't think there is any need to refer to RFC 4302. The fundamental principles regarding mutable fields are general and do not apply solely to IPSec. On the other hand, it would help to be explicit in the RPL draft regarding mutability but I think that is already agreed.</RCC2>

Alex


Robert

Robert Cragie (Pacific Gas & Electric)

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


On 10/09/2010 4:22 PM, Alexandru Petrescu wrote:
Le 10/09/2010 11:55, Robert Cragie a écrit :
David,

I totally agree with what you say. Thank you for restating generally
that IPSec has already been extensively considered - I use the term
'paraphernalia' as a general term for the overheads.

Alex - can we please drop the IPSec discussion and move on and
concentrate on the things which do need to sorted out?

Ok... let me try to avoid dissent and do what you ask.

Let's come back to RPL-11 text:
3. If the packet header specifies a source route by including a RH4
header as specified in [I-D.ietf-6man-rpl-routing-header]

then draft-ietf-6man-rpl-routing-header-00 says:
else { swap the IPv6 Destination Address and Address[i]

That means that there is a mutable but predictable field (IPv6
Destination Addess) in RH of RPL. But RPL Security doesn't understand
mutable but predictable fields (only mutable as per recent discussion).
RPL Security covers "entire IPv6 packet", which changes enroute despite
RPL Security's expectation it won't change.

So the question is: does RPL Security secure the RH4 header? I think it
does not, because its MAC computation does not say how are the mutable
but predictable fields covered.

For example, a sender builds a packet with Dst address1, computes MAC,
inserts MAC. Then intermediary routers process that packet and replace
that Dst address1 with address2 from the Routing Header. Now the packet
is received at address1. The MAC can't be meaningfully computed on the
receiver, because the "IPv6 entire packet" has changed, it is not the
same as at emission.

I think this example is correct.

It can't be solved in the same way we solved the mutability of "Hop
Limit" (we said to make HopLimit set to 0 for MAC calculation), because
if we do so then we have a higher risk of attack than when left HopLimit
unsecure. If we set to 0 de Dst for MAC calculation then the risk of
implication of forged IP dst addresses is higher than forged HopLimit.
Forging an IP dst address is stronger security attack than forging
HopLimit, intuitively speaking.

Besides, whereas the receiver has really no idea about what could the
original HopLimit be, it knows precisely what the original Dst address
was (it's in the RH4, swapped). Thus the securing solution should be
different - it should be as smart as RH4 is.

Knowing the previous discussion, it may be possible that people will
request we refer to that Authentication Header RFC which tells how
mutable, mutable but predictable fields are dealt with. At that point
we come back to IPsec, but I will abstain from saying so if you wish.
There is also the fact that previous IPsec talk says RH0 whereas here we
have RH4 and things may be different.

That's too long for anyone to read, but you get the point.

Alex




You are of course
entitled to your opinion but progress= is only made in the IETF
through rough consensus. Consensus does not mean unanimous agreement;
if we can all at least consent to a solution then the process will
run a lot more smoothly and we will all benefit. Continual dissent
will only serve to hinder this progress.

I think the consensus is clear:

* We do not mention IPSec in RPL security * The mutable field
discussion is entirely independent from IPSec

Robert

Robert Cragie (Pacific Gas & Electric)

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


On 09/09/2010 9:33 PM, David Culler wrote:
Dear Alex, Thank you for focusing o= n the question of routing
security, rather than internet security in general. Yes, IPSec has
been utilized to secure routing protocols. Now please take the
next step and focus on routing for low power and lossy networks.
Obviously, IPSec has to be the first thing considered. And it was.
Dating back to the earliest security framework discussions it was
considered many times. We returned to the IPSec issue extensively
back in June on the mailing list. I won't reiterate the
discussion on the storage and time complexity, nor the message
overhead implications that were in those prior postings. But I
will observe that no one suggested that they saw their way to a
full IPSec implementation within the constraints articulated in the
Routing Requirements documents. The WG group has long since
reached a rough consensus on this matter and moved on. That is the
nature of a group process and specifically the role of WG LC. At
some point, we commit to certain things and stop revisiting them
from first principles. That allows us to focus more sharply on
the selected approach and refine it more completely. For example,
in security, we have specifics to resolve, such as which header
fields need to be skipped. It is not a matter of "but I imagine
that there may be alternatives". There might be. But we don't
just turn the same rocks over and over again. We carve the rough
stone, we chisel the details, we sand, we polish.

So I assume that the point of your posting is that you want to be
sure that the justification for the choices that the WG made are
properly documented in the WG documents. If you feel that they are
not, perhaps you could point to the document and section that you
feel should contain this material more substantially.

D.

For reference,http://www.ietf.org/tao.html section 7.4


On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote:

Le 09/09/2010 16:59, David Culler= aécrit :
The RPL charter calls for us to= address routing security
considerations. Not security in general. Not application
security. Not link level. Routing security. It is focused for
good reason.
Routing security like OSPF using IPsec? "Authentication has been
removed from the OSPF protocol and instead relies on IPv6's
Authentication Header and Encapsulating Security Payload (ESP)."
says rfc5340... why does RPL need to be different in this
respect?

Alex

On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote:

Le 08/09/2010 18:15, Philip Levis aécrit :
On Sep 3, 2010, at 8:37 AM,= Alexandru Petrescu wrote:

Le 03/09/2010 13:48, Robert Cragie aécrit : [skipped
agreed opinions about IPsec]
Reusing the IPsec module ensures a secure system -
it's proven by earlier experience. We know it worked
ok so why avoid using it.
<RCC>I don't think the specification of RPL security
precludes the use of IPSec instead. Does the use of
IPSec need to be specified in the RPL
specification?</RCC>
YEs, the RPL specification must say something about
security in its Security Considerations section. That
something has to mention something about IPsec.
Why does it have to do so? In theory, RPL should be
entirely independent of IPSec. There have already been
numerous discussions about why simply relying on IPSec
would be problematic. Unfortunately you seem to forget
these points every few weeks and rehash the same
discussion. At some point it becomes a waste of everyone's
time.
Phil - if RPL says "security" then it must understand that
Internet security is usually IPsec. This is truer with IPv6
(as opposed to IPv4) where IPsec is very much integrated in
the design (mutable fields, etc.)

Have you checked the mutable field discussion? Do you agree
that mutable fields must be taken into account?

Please read that around 3 people agreed on a list of items
which are worth discussion of security and IPsec - mutable
fields is one such item.

As such this discussion is not a waste of everyone's time.

Alex

Phil

_______________________________________________ Roll mailing
list Roll@ietf.org
https://www.ietf.org/mailman/listinfo/r= oll
David Cullerculler@cs.berkeley.edu Chair = Computer Science
Associate Chair EECS





David Culler culler@cs.berkeley.edu Chair Computer = Science
Associate Chair EECS



_______________________________________________ Roll mailing list
Roll@ietf.org https://www.ietf.org/mailman/lis= tinfo/roll



_______________________________________________ Roll mailing list
Roll@ietf.org https://www.ietf.org/mailman/listi= nfo/roll


_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll




--------------010603070906020300050900-- --------------ms000301030605050404080105 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwOTEzMTA1MTE4WjAjBgkqhkiG9w0BCQQxFgQUbxYD 5MfaE+gb8yewK4I6NLGlhmYwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEASQDP1aEpptl9AZtQG4yywsq6zJ4vgP7OHjBx 7Gkx9Hb20wDAubPxpFCoe26pCSOLKgPjLn+99hf5RFXFHvxNNVKkbyDJZKD5SzAOmymsNDUw tTu9W6uZss3vVrq9yu80gNPBjEMgCeyBIB7KbeBPNF3/hN92lLd0j3hJkdxCMiNV2QAP5Qlp cJ/NxvYlLi8H+h5tJl6bhPXovFAEyuWeN4KCqh1SdhtehOWhFResxsIBptqsWF9riZkp9LCa XXEhMGZlVg8c6uX9EZ6cMk0uRxJLKxqRChIH1c9fsr2z+7MQPrZ9Er141HZTsYPvazdgbUgF SljMWuYGpbloRv92mwAAAAAAAA== --------------ms000301030605050404080105-- From rodolfo@ubilogix.com Mon Sep 13 12:22:45 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5DDC3A6A90 for ; Mon, 13 Sep 2010 12:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.531 X-Spam-Level: X-Spam-Status: No, score=-0.531 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HX14jW-FOndS for ; Mon, 13 Sep 2010 12:22:42 -0700 (PDT) Received: from dpmailmta03.doteasy.com (dpmailmta03-36.doteasy.com [65.61.219.56]) by core3.amsl.com (Postfix) with ESMTP id 1E7283A6A21 for ; Mon, 13 Sep 2010 12:22:40 -0700 (PDT) Received: from dpmail31pro.doteasy.com ([192.168.101.31]) by dpmailrp06.doteasy.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o8DJMvji007225; Mon, 13 Sep 2010 12:22:58 -0700 Received: from 201.171.215.118.dsl.dyn.telnor.net [201.171.215.118] by dpmail31pro.doteasy.com with SMTP; Mon, 13 Sep 2010 12:22:37 -0700 Message-ID: <922E7FA7C3F145FF931551134477ED4F@ubilogixrodo> From: "Rodolfo Gonzalez Bernaldez" To: , "Alexandru Petrescu" References: <13773.1282327971@marajade.sandelman.ca> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> <519A78D0-77BC-466C-BAFF-084DEF5D9CB5@cs.stanford.edu> <4C87C73E.1040806@gmail.com> <4C88FD45.60004@gmail.com> <8556A091-D8F9-4B6B-8F49-4260005C577C@cs.berkeley.edu> <4C8A008C.7080406@gridmerge.com><4C8A4D19.40202@gmai l.com> <4C8A6144.1070401@gridme! rge.com><4C8A70EE.1050301@gmail.com> <4C8E0226.3000101@gridmerge.com> In-Reply-To: <4C8E0226.3000101@gridmerge.com> Date: Mon, 13 Sep 2010 12:22:38 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01CB533E.5A86C2D0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: No geolocation information available for 192.168.101.31 X-CanItPRO-Stream: base:default X-Canit-Stats-ID: 01D6jmVIW - 38f2e8c49835 X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.101.86 X-Originating-IP: 192.168.101.86 Cc: roll@ietf.org Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Sep 2010 19:22:45 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0049_01CB533E.5A86C2D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Robert, Alex, all I agree with Robert, a reference to the RFC 4302 is not necessary, = referencing it could bring confusion. About to be explicit in the RPL = draft regarding the mutability, I think that a graphic example must be = included. Now, just because I refer to IPSec AH, it doesn't mean I am suggesting = we use it. I am suggesting we can use the fundamental principles from=20 IPSec for an equivalent operation.=20 I understand. I am just afraid sometimes we try to rewrite much parts = of it.=20 For example, I wonder how to you plan to refer to that RFC document? = Just wondering.=20 I don't think there is any need to refer to RFC 4302. The = fundamental principles regarding mutable fields are general and do not = apply solely to IPSec. On the other hand, it would help to be explicit = in the RPL draft regarding mutability but I think that is already = agreed. Best regards Rodolfo. From: Robert Cragie=20 Sent: Monday, September 13, 2010 3:51 AM To: Alexandru Petrescu=20 Cc: roll@ietf.org=20 Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit Hi Alex, Comments inline, bracketed by Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 10/09/2010 6:54 PM, Alexandru Petrescu wrote:=20 Le 10/09/2010 18:48, Robert Cragie a =E9crit :=20 Hi Alex,=20 Thank you for focusing on a pertinent issue. You are right to = highlight=20 what we do with a RH4 header as I believe secured DAO ACK is the = (only)=20 RPL control message which requires RH4 in non-storing mode.=20 Sounds reassuring to know RH4 is only for DAO ACK and only for=20 non-storing mode.=20 And in storing mode? Is RH4 present in other than DAO ACK? Just to = make=20 sure I understand you.=20 Here is my analysis (please correct if wrong): a.. Storing mode doesn't require the RH4 header as there is no need to = carry the routing information.=20 b.. DIS is one hop (link local)=20 c.. DIO is multicast=20 d.. DAO is routed up the DODAG to the root therefore is not source = routed=20 e.. That leaves DAO ACK in storing mode=20 So, to follow the rules for mutable and predictable fields (see RFC=20 4302), we can resubstitute at the end:=20 Consider the following:=20 A -> B -> C -> D -> E=20 A -> B:=20 |Src|Dst|RH4 |=20 | | |Seq|A0 |A1 |A2 |=20 -------------------------=20 | A | B | 3 | C | D | E |=20 B -> C:=20 |Src|Dst|RH4 |=20 | | |Seq|A0 |A1 |A2 |=20 -------------------------=20 | A | C | 2 | B | D | E |=20 C -> D:=20 |Src|Dst|RH4 |=20 | | |Seq|A0 |A1 |A2 |=20 -------------------------=20 | A | D | 1 | B | C | E |=20 D -> E:=20 |Src|Dst|RH4 |=20 | | |Seq|A0 |A1 |A2 |=20 -------------------------=20 | A | E | 0 | B | C | D |=20 When the packet arrives at E, recreate the original RH4 header for = MAC=20 computation:=20 n =3D ((Hdr Ext Len * 8) - Pad) / (16 - Comp)=20 tmp =3D Dst=20 Dst =3D RH4.A[0]=20 RH4.Seq =3D n=20 for (k =3D 1; k < n; k++)=20 {=20 RH4.A[k-1] =3D RH4.A[k]=20 }=20 RH4.A[k] =3D tmp=20 |Src|Dst|RH4 |=20 | | |Seq|L0 |L1 |L2 |=20 -------------------------=20 | A | B | 3 | C | D | E |=20 Is that acceptable?=20 Thanks for the method - it reads reasonable. It is a good way (one = way? are there others? are there little bugs in that code?) Probably :-) to specify MAC over RH4 coherently - reconstruct the RH at reception. = This solution is different than solving the mutability of the Hop Limit = field.=20 It is the method stated in RFC 4302 section 3.3.3.1. The fields in = this case are predictable this can be reconstructed, as RH4 is similar = to RH0 which is listed in Appendix A.2 as mutable but predictable. So, = reading this actually suggests the MAC should be computed based on what = the final destination will see - it is fundamentally the same = principle. Can we see further - RH4 draft also says IPv6-in-IPv6 tunnelling must = be used sometime, together with RH4. This raises the obvious question = about: is the header of the encapsulating packet also protected by the = MAC of RPL? Or not?=20 Not for DAO ACK as it is wholly within the RPL domain (case 1 in = Section 2 of = http://tools.ietf.org/html/draft-ietf-6man-rpl-routing-header-00) RPL spec currently says the "entire IPv6 packet" is covered by its = MAC. But does that cover the IPv6 base header of the encapsulating = header? Or not? And in which order?=20 It doesn't apply in this case. Now, just because I refer to IPSec AH, it doesn't mean I am = suggesting=20 we use it. I am suggesting we can use the fundamental principles = from=20 IPSec for an equivalent operation.=20 I understand. I am just afraid sometimes we try to rewrite much parts = of it.=20 For example, I wonder how to you plan to refer to that RFC document? = Just wondering.=20 I don't think there is any need to refer to RFC 4302. The = fundamental principles regarding mutable fields are general and do not = apply solely to IPSec. On the other hand, it would help to be explicit = in the RPL draft regarding mutability but I think that is already = agreed. Alex=20 Robert=20 Robert Cragie (Pacific Gas & Electric)=20 Gridmerge Ltd.=20 89 Greenfield Crescent,=20 Wakefield, WF4 4WA, UK=20 +44 1924 910888=20 +1 415 513 0064=20 http://www.gridmerge.com =20 On 10/09/2010 4:22 PM, Alexandru Petrescu wrote:=20 Le 10/09/2010 11:55, Robert Cragie a =E9crit :=20 David,=20 I totally agree with what you say. Thank you for restating = generally=20 that IPSec has already been extensively considered - I use the = term=20 'paraphernalia' as a general term for the overheads.=20 Alex - can we please drop the IPSec discussion and move on and=20 concentrate on the things which do need to sorted out?=20 Ok... let me try to avoid dissent and do what you ask.=20 Let's come back to RPL-11 text:=20 3. If the packet header specifies a source route by including a = RH4=20 header as specified in [I-D.ietf-6man-rpl-routing-header]=20 then draft-ietf-6man-rpl-routing-header-00 says:=20 else { swap the IPv6 Destination Address and Address[i]=20 That means that there is a mutable but predictable field (IPv6=20 Destination Addess) in RH of RPL. But RPL Security doesn't = understand=20 mutable but predictable fields (only mutable as per recent = discussion).=20 RPL Security covers "entire IPv6 packet", which changes enroute = despite=20 RPL Security's expectation it won't change.=20 So the question is: does RPL Security secure the RH4 header? I = think it=20 does not, because its MAC computation does not say how are the = mutable=20 but predictable fields covered.=20 For example, a sender builds a packet with Dst address1, computes = MAC,=20 inserts MAC. Then intermediary routers process that packet and = replace=20 that Dst address1 with address2 from the Routing Header. Now the = packet=20 is received at address1. The MAC can't be meaningfully computed on = the=20 receiver, because the "IPv6 entire packet" has changed, it is not = the=20 same as at emission.=20 I think this example is correct.=20 It can't be solved in the same way we solved the mutability of = "Hop=20 Limit" (we said to make HopLimit set to 0 for MAC calculation), = because=20 if we do so then we have a higher risk of attack than when left = HopLimit=20 unsecure. If we set to 0 de Dst for MAC calculation then the risk = of=20 implication of forged IP dst addresses is higher than forged = HopLimit.=20 Forging an IP dst address is stronger security attack than forging = HopLimit, intuitively speaking.=20 Besides, whereas the receiver has really no idea about what could = the=20 original HopLimit be, it knows precisely what the original Dst = address=20 was (it's in the RH4, swapped). Thus the securing solution should = be=20 different - it should be as smart as RH4 is.=20 Knowing the previous discussion, it may be possible that people = will=20 request we refer to that Authentication Header RFC which tells how = mutable, mutable but predictable fields are dealt with. At that = point=20 we come back to IPsec, but I will abstain from saying so if you = wish.=20 There is also the fact that previous IPsec talk says RH0 whereas = here we=20 have RH4 and things may be different.=20 That's too long for anyone to read, but you get the point.=20 Alex=20 You are of course=20 entitled to your opinion but progress is only made in the IETF=20 through rough consensus. Consensus does not mean unanimous = agreement;=20 if we can all at least consent to a solution then the process = will=20 run a lot more smoothly and we will all benefit. Continual = dissent=20 will only serve to hinder this progress.=20 I think the consensus is clear:=20 * We do not mention IPSec in RPL security * The mutable field=20 discussion is entirely independent from IPSec=20 Robert=20 Robert Cragie (Pacific Gas & Electric)=20 Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK = +44=20 1924 910888 +1 415 513 0064 http://www.gridmerge.com=20 =20 On 09/09/2010 9:33 PM, David Culler wrote:=20 Dear Alex, Thank you for focusing on the question of routing=20 security, rather than internet security in general. Yes, IPSec = has=20 been utilized to secure routing protocols. Now please take the = next step and focus on routing for low power and lossy = networks.=20 Obviously, IPSec has to be the first thing considered. And it = was.=20 Dating back to the earliest security framework discussions it = was=20 considered many times. We returned to the IPSec issue = extensively=20 back in June on the mailing list. I won't reiterate the=20 discussion on the storage and time complexity, nor the message = overhead implications that were in those prior postings. But I = will observe that no one suggested that they saw their way to = a=20 full IPSec implementation within the constraints articulated = in the=20 Routing Requirements documents. The WG group has long since=20 reached a rough consensus on this matter and moved on. That is = the=20 nature of a group process and specifically the role of WG LC. = At=20 some point, we commit to certain things and stop revisiting = them=20 from first principles. That allows us to focus more sharply on = the selected approach and refine it more completely. For = example,=20 in security, we have specifics to resolve, such as which = header=20 fields need to be skipped. It is not a matter of "but I = imagine=20 that there may be alternatives". There might be. But we don't=20 just turn the same rocks over and over again. We carve the = rough=20 stone, we chisel the details, we sand, we polish.=20 So I assume that the point of your posting is that you want to = be=20 sure that the justification for the choices that the WG made = are=20 properly documented in the WG documents. If you feel that they = are=20 not, perhaps you could point to the document and section that = you=20 feel should contain this material more substantially.=20 D.=20 For reference,http://www.ietf.org/tao.html section 7.4=20 On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote:=20 Le 09/09/2010 16:59, David Culler a=E9crit :=20 The RPL charter calls for us to address routing security=20 considerations. Not security in general. Not application=20 security. Not link level. Routing security. It is focused = for=20 good reason.=20 Routing security like OSPF using IPsec? "Authentication has = been=20 removed from the OSPF protocol and instead relies on IPv6's=20 Authentication Header and Encapsulating Security Payload = (ESP)."=20 says rfc5340... why does RPL need to be different in this=20 respect?=20 Alex=20 On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote:=20 Le 08/09/2010 18:15, Philip Levis a=E9crit :=20 On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote:=20 Le 03/09/2010 13:48, Robert Cragie a=E9crit : = [skipped=20 agreed opinions about IPsec]=20 Reusing the IPsec module ensures a secure system = -=20 it's proven by earlier experience. We know it = worked=20 ok so why avoid using it.=20 I don't think the specification of RPL = security=20 precludes the use of IPSec instead. Does the use = of=20 IPSec need to be specified in the RPL=20 specification?=20 YEs, the RPL specification must say something about=20 security in its Security Considerations section. = That=20 something has to mention something about IPsec.=20 Why does it have to do so? In theory, RPL should be=20 entirely independent of IPSec. There have already been = numerous discussions about why simply relying on IPSec = would be problematic. Unfortunately you seem to forget = these points every few weeks and rehash the same=20 discussion. At some point it becomes a waste of = everyone's=20 time.=20 Phil - if RPL says "security" then it must understand = that=20 Internet security is usually IPsec. This is truer with = IPv6=20 (as opposed to IPv4) where IPsec is very much integrated = in=20 the design (mutable fields, etc.)=20 Have you checked the mutable field discussion? Do you = agree=20 that mutable fields must be taken into account?=20 Please read that around 3 people agreed on a list of = items=20 which are worth discussion of security and IPsec - = mutable=20 fields is one such item.=20 As such this discussion is not a waste of everyone's = time.=20 Alex=20 Phil=20 _______________________________________________ Roll = mailing=20 list Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 David Cullerculler@cs.berkeley.edu Chair Computer Science=20 Associate Chair EECS=20 David Culler culler@cs.berkeley.edu Chair Computer Science=20 Associate Chair EECS=20 _______________________________________________ Roll mailing = list=20 Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________ Roll mailing = list=20 Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 -------------------------------------------------------------------------= ------- _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_0049_01CB533E.5A86C2D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello Robert, Alex, all
 
I agree with Robert, a reference = to=20 the RFC 4302 is not necessary, referencing it could bring = confusion. About to be explicit in the RPL draft regarding the = mutability, I=20 think that a graphic example must be included.
 
<QUOTE>
Now, just because I refer to IPSec AH, it = doesn't mean=20 I am suggesting
we use it. I am suggesting we can use the = fundamental=20 principles from
IPSec for an equivalent operation. =

I=20 understand.  I am just afraid sometimes we try to rewrite much = parts of it.=20

For example, I wonder how to you plan to refer to that RFC = document?=20 Just wondering.
<RCC2>I don't think there is any need to refer = to RFC=20 4302. The fundamental principles regarding mutable fields are general = and do not=20 apply solely to IPSec. On the other hand, it would help to be explicit = in the=20 RPL draft regarding mutability but I think that is already=20 agreed.</RCC2>
</QUOTE>
 
Best regards
Rodolfo.

From: Robert Cragie
Sent: Monday, September 13, 2010 3:51 AM
Subject: Re: [Roll] Messg Auth Code covering the mutable IP = Hop=20 Limit

Hi Alex,

Comments inline, bracketed = by=20 <RCC2></RCC2>

Robert

Robert Cragie (Pacific Gas & Electric)

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

<= BR>On=20 10/09/2010 6:54 PM, Alexandru Petrescu wrote:=20
Le = 10/09/2010=20 18:48, Robert Cragie a =E9crit :
  Hi Alex,

Thank you for = focusing on a=20 pertinent issue. You are right to highlight
what we do with a = RH4 header=20 as I believe secured DAO ACK is the (only)
RPL control message = which=20 requires RH4 in non-storing mode.

Sounds = reassuring to=20 know RH4 is only for DAO ACK and only for
non-storing mode. =

And in=20 storing mode? Is RH4 present in other than DAO ACK? Just to make =
sure I=20 understand you.
<RCC2>
Here is my analysis = (please=20 correct if wrong):
  • Storing mode doesn't require the RH4 header as there is no need to = carry=20 the routing information.=20
  • DIS is one hop (link local)=20
  • DIO is multicast=20
  • DAO is routed up the DODAG to the root therefore is not source = routed=20
  • That leaves DAO ACK in storing mode
</RCC2>

So, to follow the rules for mutable and = predictable=20 fields (see RFC
4302), we can resubstitute at the end: =

Consider=20 the following:

A -> B -> C -> D -> E

A = -> B:=20

|Src|Dst|RH4 |
| | |Seq|A0 |A1 |A2 |=20
-------------------------
| A | B | 3 | C | D | E | =

B ->=20 C:

|Src|Dst|RH4 |
| | |Seq|A0 |A1 |A2 |=20
-------------------------
| A | C | 2 | B | D | E | =

C ->=20 D:

|Src|Dst|RH4 |
| | |Seq|A0 |A1 |A2 |=20
-------------------------
| A | D | 1 | B | C | E | =

D ->=20 E:

|Src|Dst|RH4 |
| | |Seq|A0 |A1 |A2 |=20
-------------------------
| A | E | 0 | B | C | D | =

When the=20 packet arrives at E, recreate the original RH4 header for MAC=20
computation:

n =3D ((Hdr Ext Len * 8) - Pad) / (16 - = Comp)
tmp=20 =3D Dst
Dst =3D RH4.A[0]
RH4.Seq =3D n
for (k =3D 1; k = < n; k++)=20
{
RH4.A[k-1] =3D RH4.A[k]
}
RH4.A[k] =3D tmp=20

|Src|Dst|RH4 |
| | |Seq|L0 |L1 |L2 |=20
-------------------------
| A | B | 3 | C | D | E | =

Is that=20 acceptable?

Thanks for the method - it reads=20 reasonable.  It is a good way (one way?  are there others? = are there=20 little bugs in that code?)
<RCC2>Probably = :-)</RCC2>
to = specify MAC=20 over RH4 coherently - reconstruct the RH at reception.  This = solution is=20 different than solving the mutability of the Hop Limit field.=20
<RCC2>It is the method stated in RFC 4302 section = 3.3.3.1. The fields in this case are predictable this can be = reconstructed, as=20 RH4 is similar to RH0 which is listed in Appendix A.2 as mutable but=20 predictable. So, reading this actually suggests the MAC should be = computed based=20 on what the final destination will see - it is fundamentally the same=20 principle.</RCC2>

Can we see further - RH4 draft also says = IPv6-in-IPv6=20 tunnelling must be used sometime, together with RH4.  This raises = the=20 obvious question about: is the header of the encapsulating packet also = protected by the MAC of RPL?  Or not? =
<RCC2>Not for=20 DAO ACK as it is wholly within the RPL domain (case 1 in Section 2 of http://tools.ietf.org/html/draft-ietf-6man-rpl-routing-header-00)<= ;/RCC2>

RPL spec currently says the "entire IPv6 = packet" is=20 covered by its MAC.  But does that cover the IPv6 base header of = the=20 encapsulating header?  Or not?  And in which order?=20
<RCC2>It doesn't apply  in this=20 case.</RCC2>

Now, just because I refer to IPSec AH, it = doesn't=20 mean I am suggesting
we use it. I am suggesting we can use the=20 fundamental principles from
IPSec for an equivalent operation.=20

I understand.  I am just afraid sometimes we = try to=20 rewrite much parts of it.

For example, I wonder how to you = plan to=20 refer to that RFC document? Just wondering. =
<RCC2>I don't=20 think there is any need to refer to RFC 4302. The fundamental principles = regarding mutable fields are general and do not apply solely to IPSec. = On the=20 other hand, it would help to be explicit in the RPL draft regarding = mutability=20 but I think that is already agreed.</RCC2>

Alex


Robert =

Robert=20 Cragie (Pacific Gas & Electric)

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


On 10/09/2010 4:22 PM, Alexandru Petrescu wrote:
Le 10/09/2010 11:55, Robert Cragie a = =E9crit :
David,

I totally agree with what = you=20 say. Thank you for restating generally
that IPSec has = already been=20 extensively considered - I use the term
'paraphernalia' as a = general=20 term for the overheads.

Alex - can we please drop the = IPSec=20 discussion and move on and
concentrate on the things which = do need=20 to sorted out?

Ok... let me try to avoid = dissent and=20 do what you ask.

Let's come back to RPL-11 text:
3. If the packet header specifies a = source route=20 by including a RH4
header as specified in=20 [I-D.ietf-6man-rpl-routing-header]

then=20 draft-ietf-6man-rpl-routing-header-00 says:
else { swap the IPv6 Destination Address = and=20 Address[i]

That means that there is a = mutable but=20 predictable field (IPv6
Destination Addess) in RH of RPL. But = RPL=20 Security doesn't understand
mutable but predictable fields = (only=20 mutable as per recent discussion).
RPL Security covers "entire = IPv6=20 packet", which changes enroute despite
RPL Security's = expectation it=20 won't change.

So the question is: does RPL Security secure = the RH4=20 header? I think it
does not, because its MAC computation does = not say=20 how are the mutable
but predictable fields covered. =

For=20 example, a sender builds a packet with Dst address1, computes MAC, =
inserts MAC. Then intermediary routers process that packet and = replace=20
that Dst address1 with address2 from the Routing Header. Now = the=20 packet
is received at address1. The MAC can't be meaningfully = computed=20 on the
receiver, because the "IPv6 entire packet" has changed, = it is=20 not the
same as at emission.

I think this example is = correct.=20

It can't be solved in the same way we solved the = mutability of=20 "Hop
Limit" (we said to make HopLimit set to 0 for MAC = calculation),=20 because
if we do so then we have a higher risk of attack than = when=20 left HopLimit
unsecure. If we set to 0 de Dst for MAC = calculation then=20 the risk of
implication of forged IP dst addresses is higher = than=20 forged HopLimit.
Forging an IP dst address is stronger = security attack=20 than forging
HopLimit, intuitively speaking.

Besides, = whereas=20 the receiver has really no idea about what could the
original = HopLimit=20 be, it knows precisely what the original Dst address
was (it's = in the=20 RH4, swapped). Thus the securing solution should be
different = - it=20 should be as smart as RH4 is.

Knowing the previous = discussion, it=20 may be possible that people will
request we refer to that=20 Authentication Header RFC which tells how
mutable, mutable but = predictable fields are dealt with. At that point
we come back = to=20 IPsec, but I will abstain from saying so if you wish.
There is = also=20 the fact that previous IPsec talk says RH0 whereas here we =
have RH4=20 and things may be different.

That's too long for anyone to = read,=20 but you get the point.

Alex




You are of = course=20
entitled to your opinion but progress is = only=20 made in the IETF
through rough consensus. Consensus does not = mean=20 unanimous agreement;
if we can all at least consent to a = solution=20 then the process will
run a lot more smoothly and we will = all=20 benefit. Continual dissent
will only serve to hinder this = progress.=20

I think the consensus is clear:

* We do not = mention=20 IPSec in RPL security * The mutable field
discussion is = entirely=20 independent from IPSec

Robert

Robert Cragie = (Pacific Gas=20 & Electric)

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


On 09/09/2010 9:33 PM, David Culler wrote:
Dear Alex, Thank you for focusing on = the=20 question of routing
security, rather than internet = security in=20 general. Yes, IPSec has
been utilized to secure routing = protocols.=20 Now please take the
next step and focus on routing for low = power=20 and lossy networks.
Obviously, IPSec has to be the first = thing=20 considered. And it was.
Dating back to the earliest = security=20 framework discussions it was
considered many times. We = returned to=20 the IPSec issue extensively
back in June on the mailing = list. I=20 won't reiterate the
discussion on the storage and time = complexity,=20 nor the message
overhead implications that were in those = prior=20 postings. But I
will observe that no one suggested that = they saw=20 their way to a
full IPSec implementation within the = constraints=20 articulated in the
Routing Requirements documents. The WG = group=20 has long since
reached a rough consensus on this matter = and moved=20 on. That is the
nature of a group process and specifically = the=20 role of WG LC. At
some point, we commit to certain things = and stop=20 revisiting them
from first principles. That allows us to = focus=20 more sharply on
the selected approach and refine it more=20 completely. For example,
in security, we have specifics to = resolve, such as which header
fields need to be skipped. = It is not=20 a matter of "but I imagine
that there may be = alternatives". There=20 might be. But we don't
just turn the same rocks over and = over=20 again. We carve the rough
stone, we chisel the details, we = sand,=20 we polish.

So I assume that the point of your posting = is that=20 you want to be
sure that the justification for the choices = that=20 the WG made are
properly documented in the WG documents. = If you=20 feel that they are
not, perhaps you could point to the = document=20 and section that you
feel should contain this material = more=20 substantially.

D.

For reference,http://www.ietf.org/tao.html=20 section 7.4


On Sep 9, 2010, at 8:29 AM, Alexandru = Petrescu=20 wrote:

Le 09/09/2010 16:59, David Culler = a=E9crit :=20
The RPL charter calls for us to = address=20 routing security
considerations. Not security in = general. Not=20 application
security. Not link level. Routing = security. It is=20 focused for
good reason.
Routing = security like=20 OSPF using IPsec? "Authentication has been
removed from = the OSPF=20 protocol and instead relies on IPv6's
Authentication = Header and=20 Encapsulating Security Payload (ESP)."
says rfc5340... = why does=20 RPL need to be different in this
respect?

Alex =

On Sep 8, 2010, at 10:26 AM, = Alexandru=20 Petrescu wrote:

Le 08/09/2010 18:15, Philip = Levis a=E9crit=20 :
On Sep 3, 2010, at 8:37 AM, = Alexandru=20 Petrescu wrote:

Le 03/09/2010 13:48, Robert = Cragie=20 a=E9crit : [skipped
agreed opinions about IPsec] =
Reusing the IPsec module = ensures=20 a secure system -
it's proven by earlier = experience.=20 We know it worked
ok so why avoid using it.=20
<RCC>I don't think the=20 specification of RPL security
precludes the = use of=20 IPSec instead. Does the use of
IPSec need to = be=20 specified in the RPL =
specification?</RCC>=20
YEs, the RPL specification must say = something about
security in its Security = Considerations=20 section. That
something has to mention something = about=20 IPsec.
Why does it have to do so? = In theory,=20 RPL should be
entirely independent of IPSec. There = have=20 already been
numerous discussions about why simply = relying=20 on IPSec
would be problematic. Unfortunately you = seem to=20 forget
these points every few weeks and rehash the = same=20
discussion. At some point it becomes a waste of = everyone's=20
time.
Phil - if RPL says = "security" then it=20 must understand that
Internet security is usually = IPsec.=20 This is truer with IPv6
(as opposed to IPv4) where = IPsec is=20 very much integrated in
the design (mutable fields, = etc.)=20

Have you checked the mutable field discussion? = Do you=20 agree
that mutable fields must be taken into = account?=20

Please read that around 3 people agreed on a = list of=20 items
which are worth discussion of security and = IPsec -=20 mutable
fields is one such item.

As such = this=20 discussion is not a waste of everyone's time. =

Alex=20

Phil=20 =

_______________________________________________=20 Roll mailing
list Roll@ietf.org
https://www.ietf.org/= mailman/listinfo/roll=20
David Cullerculler@cs.berkeley.edu= =20 Chair Computer Science
Associate Chair EECS=20





David = Culler culler@cs.berkeley.edu Chair=20 Computer Science
Associate Chair EECS=20 =



_______________________________________________ Roll=20 mailing list
Roll@ietf.org https://www.ietf.org/= mailman/listinfo/roll=20 =



____________________________________________= ___=20 Roll mailing list
Roll@ietf.org https://www.ietf.org/= mailman/listinfo/roll=20 =


_______________________________________________ =
Roll mailing list
Roll@ietf.org
https://www.ietf.org/= mailman/listinfo/roll=20




_______________________________________________
Roll mailing=20 list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
------=_NextPart_000_0049_01CB533E.5A86C2D0-- From erik.nordmark@oracle.com Tue Sep 14 19:36:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AF2B3A6B68; Tue, 14 Sep 2010 19:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.356 X-Spam-Level: X-Spam-Status: No, score=-106.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UQ6-Pw9JVPu; Tue, 14 Sep 2010 19:36:30 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 103A13A6B63; Tue, 14 Sep 2010 19:36:28 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o8F2ajeL028125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Sep 2010 02:36:47 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o8E1e5Pp010150; Wed, 15 Sep 2010 02:36:44 GMT Received: from abhmt010.oracle.com by acsmt355.oracle.com with ESMTP id 596093921284518134; Tue, 14 Sep 2010 19:35:34 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 14 Sep 2010 19:35:33 -0700 Message-ID: <4C9030FF.6060302@oracle.com> Date: Tue, 14 Sep 2010 19:35:43 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.7) Gecko/20100817 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: Philip Levis References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Carsten Bormann , roll@ietf.org, Brian E Carpenter Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Sep 2010 02:36:34 -0000 On 08/11/10 04:41 PM, Philip Levis wrote: > Basically, RPL puts up to two pieces information in packets that it > routes. The first is which routing topology this packet should be > routed on: RPL supports multiple parallel topologies, e.g., one > optimized for low latency and a second optimized for low energy. This > information is called the RPLInstanceId. > > The second is information about the "cost" of the forwarder's route > to the destination. This hop-by-hop "cost" information is called > Rank. Rank is needed to detect routing loops: if a router receives a > packet whose prior router's Rank is less than or equal to its own, > Rank is not strictly decreasing and there may be a routing loop. > > Being able to embed this information in the flow label, rather than > requiring additional headers and IP-in-IP, would greatly reduce > header overhead. In RPL, we're often concerned about very short, such > as 10 byte, packets, so this could be a big savings. > > The challenge is that the RPLInstanceId is 8 bits and Rank is 16 > bits. I realize that taking 48 bytes to carry 3 bytes of content (IP-in-IP plus a min size option is 48 bytes) seems a bit silly. Has anybody discussed adding a header with just the 3 bytes you need *before* the IP header? That avoids the overhead. The downside is that you need a new code point (for demux) in the different layer2s that you want to run this on. But it seems a lot simpler than trying to overload some existing IPv6 header field. Erik From jpv@cisco.com Wed Sep 15 13:02:43 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53D483A6A7F; Wed, 15 Sep 2010 13:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.399 X-Spam-Level: X-Spam-Status: No, score=-111.399 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRKJMNG7QD5H; Wed, 15 Sep 2010 13:02:42 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 567AA3A6A7C; Wed, 15 Sep 2010 13:02:42 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIPDkEyrR7Hu/2dsb2JhbAChbnGrOJwmhUEEhEqFYoME X-IronPort-AV: E=Sophos;i="4.56,372,1280707200"; d="scan'208";a="187181816" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 15 Sep 2010 20:03:06 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o8FK36Rk006318; Wed, 15 Sep 2010 20:03:06 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Sep 2010 13:03:06 -0700 Received: from dhcp-128-107-108-191.cisco.com ([128.107.108.191]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Sep 2010 13:03:05 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <1C65D00D-7447-4DB6-8EAA-D1760D30ADFA@cisco.com> Date: Wed, 15 Sep 2010 13:03:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com> <4C9030FF.6060302@oracle.com> <1C65D00D-7447-4DB6-8EAA-D1760D30ADFA@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 15 Sep 2010 20:03:05.0946 (UTC) FILETIME=[02C4FBA0:01CB5511] Cc: Carsten Bormann , ROLL WG , IPv6 WG Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Sep 2010 20:02:43 -0000 On Sep 15, 2010, at 7:19 AM, Fred Baker wrote: > So that might use the mesh network header part of the 6lowpan header? We would need be using the compressed ID header >=20 > On Sep 15, 2010, at 12:06 AM, Carsten Bormann wrote: >=20 >>> Has anybody discussed adding a header with just the 3 bytes you need = *before* the IP header? >>=20 >> Yes. Ever since you proposed pretty much that at a previous IETF = meeting, I've been thinking that architecturally it makes a lot of sense = to think about ROLL as a sub-IP protocol. >>=20 >>> The downside is that you need a new code point (for demux) in the = different layer2s that you want to run this on. >>=20 >> And that is exactly the non-starter about the general proposal. >> It is not acceptable to require a new spec for each of the many link = layers we want to run ROLL on, in particular for those who don't really = care that much about the overhead. >>=20 >> However, it would be pretty easy to put something in 6lowpan to carry = those 3 bytes. >> (Consider it an advanced form of header compression for the 48-byte = IP-in-IP thing, if you don't like the sub-IP thinking.) >> Consult http://tools.ietf.org/html/draft-bormann-6lowpan-ext-hdr-00 = for a sample base design. >> Such a simple extension may actually be a preferable way to carry = ROLL in 6lowpan. >>=20 >> Gruesse, Carsten >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From pthubert@cisco.com Thu Sep 16 05:07:17 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90BD33A6B14; Thu, 16 Sep 2010 05:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.473 X-Spam-Level: X-Spam-Status: No, score=-10.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zb3jtWuQD8u3; Thu, 16 Sep 2010 05:07:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E0BB53A6B1C; Thu, 16 Sep 2010 05:07:14 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEKlkUyQ/khN/2dsb2JhbACheXGkKJw5hUEEjTCICQ X-IronPort-AV: E=Sophos;i="4.56,376,1280707200"; d="scan'208";a="64504734" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 16 Sep 2010 12:07:39 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o8GC7dNO003038; Thu, 16 Sep 2010 12:07:39 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Sep 2010 14:07:39 +0200 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: Thu, 16 Sep 2010 14:07:36 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02C593B6@XMB-AMS-107.cisco.com> In-Reply-To: <4C9030FF.6060302@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Flow Label: 12 bits mutable and 8 bits immutable Thread-Index: ActUft0wCAOcPkI8TM2fipYCgGEZDwBFaVuw References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com> <4C9030FF.6060302@oracle.com> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" , "Philip Levis" X-OriginalArrivalTime: 16 Sep 2010 12:07:39.0397 (UTC) FILETIME=[C208CB50:01CB5597] Cc: Carsten Bormann , roll@ietf.org, ipv6@ietf.org, Brian E Carpenter Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Sep 2010 12:07:17 -0000 Hi Erik: > > The challenge is that the RPLInstanceId is 8 bits and Rank is 16 bits. This much of the challenge can be absorbed by RPL. In most reasonable cases, we could can make the floor(Rank) 8 or less bits, and that's all we need to accomplish the purpose of this header. > I realize that taking 48 bytes to carry 3 bytes of content (IP-in-IP plus a min size > option is 48 bytes) seems a bit silly. Most certainly. Some people will say that we can live without IP in IP. Other that we can make sure we always emit the compressed form which hopefully would not be a lot more than the original bits. > Has anybody discussed adding a header with just the 3 bytes you need > *before* the IP header? We've discussed using forms of tag switching from the beginning of the WG but there must be an IP based reference model before we start doing the tricks. As it goes, RPL till v07 was using the flow label, using a mutable but recoverable model. Let's see whether 6MAN allows us to make the field mutable in the first place. Pascal > -----Original Message----- > From: Erik Nordmark [mailto:erik.nordmark@oracle.com] > Sent: Wednesday, September 15, 2010 4:36 AM > To: Philip Levis > Cc: Pascal Thubert (pthubert); Carsten Bormann; roll@ietf.org; ipv6@ietf.org; > mcr@sandelman.ca; Brian E Carpenter > Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable >=20 > On 08/11/10 04:41 PM, Philip Levis wrote: >=20 > > Basically, RPL puts up to two pieces information in packets that it > > routes. The first is which routing topology this packet should be > > routed on: RPL supports multiple parallel topologies, e.g., one > > optimized for low latency and a second optimized for low energy. This > > information is called the RPLInstanceId. > > > > The second is information about the "cost" of the forwarder's route to > > the destination. This hop-by-hop "cost" information is called Rank. > > Rank is needed to detect routing loops: if a router receives a packet > > whose prior router's Rank is less than or equal to its own, Rank is > > not strictly decreasing and there may be a routing loop. > > > > Being able to embed this information in the flow label, rather than > > requiring additional headers and IP-in-IP, would greatly reduce header > > overhead. In RPL, we're often concerned about very short, such as 10 > > byte, packets, so this could be a big savings. > > > > The challenge is that the RPLInstanceId is 8 bits and Rank is 16 bits. >=20 > I realize that taking 48 bytes to carry 3 bytes of content (IP-in-IP plus a min size > option is 48 bytes) seems a bit silly. >=20 > Has anybody discussed adding a header with just the 3 bytes you need > *before* the IP header? > That avoids the overhead. The downside is that you need a new code point (for > demux) in the different layer2s that you want to run this on. > But it seems a lot simpler than trying to overload some existing IPv6 header > field. >=20 > Erik From culler@cs.berkeley.edu Thu Sep 16 06:55:57 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17C13A680B for ; Thu, 16 Sep 2010 06:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSgvH4jPOrqJ for ; Thu, 16 Sep 2010 06:55:52 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id CA42E3A6AFC for ; Thu, 16 Sep 2010 06:55:52 -0700 (PDT) Received: from [192.168.2.106] (64-142-4-199.dsl.static.sonic.net [64.142.4.199]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o8GDuELd019299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 16 Sep 2010 06:56:16 -0700 (PDT) From: David Culler Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Sep 2010 06:56:13 -0700 Message-Id: To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Sep 2010 13:55:57 -0000 The routing metrics draft has now gone through 9 revisions over the past = 16 months, the diffs have narrowed to essentially wording and editorial = changes, and the comments are few and non-controversial. Thus, it = appears that consensus has emerged and we can LC this I-D. This email is to announce Working Group Last Call on = draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST, Sept. = 30 2010. Please read it thoroughly and forward all final comments to = the authors and the WG mailing list. =20 Thanks all for your good work. We're on a ROLL.= From erik.nordmark@oracle.com Thu Sep 16 09:43:40 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EA713A6BB4; Thu, 16 Sep 2010 09:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.368 X-Spam-Level: X-Spam-Status: No, score=-106.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tu0dge4B1fVH; Thu, 16 Sep 2010 09:43:39 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 5A8963A6BAB; Thu, 16 Sep 2010 09:43:38 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o8GGhtIh029889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Sep 2010 16:43:56 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o8GGhsHG015493; Thu, 16 Sep 2010 16:43:54 GMT Received: from abhmt021.oracle.com by acsmt354.oracle.com with ESMTP id 603481671284655412; Thu, 16 Sep 2010 09:43:32 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 Sep 2010 09:43:30 -0700 Message-ID: <4C92493E.8090406@oracle.com> Date: Thu, 16 Sep 2010 09:43:42 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.7) Gecko/20100817 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com> <4C9030FF.6060302@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02C593B6@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02C593B6@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Carsten Bormann , roll@ietf.org, Brian E Carpenter Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Sep 2010 16:43:40 -0000 On 09/16/10 05:07 AM, Pascal Thubert (pthubert) wrote: >> Has anybody discussed adding a header with just the 3 bytes you need >> *before* the IP header? > > We've discussed using forms of tag switching from the beginning of the > WG but there must be an IP based reference model before we start doing > the tricks. You can have a reference model which uses IP-in-IP plus a destination options to carry the 3 bytes, and then have an optimization for low speed networks like 6lowpan that sticks those bytes somewhere else as Carsten suggested. Architecturally, in both cases, we'd end up with the 3 bytes before the (inner) IP header. Erik From alexandru.petrescu@gmail.com Thu Sep 16 10:24:10 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1114C3A689B for ; Thu, 16 Sep 2010 10:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.793 X-Spam-Level: X-Spam-Status: No, score=-0.793 tagged_above=-999 required=5 tests=[AWL=-1.144, BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-ChE4-+PoIr for ; Thu, 16 Sep 2010 10:24:08 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 8F83B3A6857 for ; Thu, 16 Sep 2010 10:24:07 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o8GHOQ20027779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Sep 2010 19:24:26 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o8GHOQWc001808; Thu, 16 Sep 2010 19:24:26 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o8GHOQd4013116; Thu, 16 Sep 2010 19:24:26 +0200 Message-ID: <4C9252CA.5050608@gmail.com> Date: Thu, 16 Sep 2010 19:24:26 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <13773.1282327971@marajade.sandelman.ca> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> <519A78D0-77BC-466C-BAFF-084DEF5D9CB5@cs.stanford.edu> <4C87C73E.1040806@gmail.com> <4C88FD45.60004@gmail.com> <8556A091-D8F9-4B6B-8F49-4260005C577C@cs.berkeley.edu> <4C8A008C.7080406@gridmerge.com> <4C8A4D19.40202@gmai l.com> <4C8A6144.1070401@gridme! rge.com> <4C8A70EE.1050301@gmail.com> <4C8E0226.3000101@gridmerge.com> In-Reply-To: <4C8E0226.3000101@gridmerge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Sep 2010 17:24:10 -0000 Hi Robert, Le 13/09/2010 12:51, Robert Cragie a écrit : > Hi Alex, > > Comments inline, bracketed by > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com > > > On 10/09/2010 6:54 PM, Alexandru Petrescu wrote: >> Le 10/09/2010 18:48, Robert Cragie a écrit : >>> Hi Alex, >>> >>> Thank you for focusing on a pertinent issue. You are right to highlight >>> what we do with a RH4 header as I believe secured DAO ACK is the (only) >>> RPL control message which requires RH4 in non-storing mode. >> >> Sounds reassuring to know RH4 is only for DAO ACK and only for >> non-storing mode. >> >> And in storing mode? Is RH4 present in other than DAO ACK? Just to make >> sure I understand you. > > Here is my analysis (please correct if wrong): > > * Storing mode doesn't require the RH4 header as there is no need to > carry the routing information. > * DIS is one hop (link local) > * DIO is multicast > * DAO is routed up the DODAG to the root therefore is not source routed > * That leaves DAO ACK in storing mode > > I do not follow the logic, but it is because of my non-understanding. I will look at it later when security is more clear. >>> So, to follow the rules for mutable and predictable fields (see RFC >>> 4302), we can resubstitute at the end: >>> >>> Consider the following: >>> >>> A -> B -> C -> D -> E >>> >>> A -> B: >>> >>> |Src|Dst|RH4 | >>> | | |Seq|A0 |A1 |A2 | >>> ------------------------- >>> | A | B | 3 | C | D | E | >>> >>> B -> C: >>> >>> |Src|Dst|RH4 | >>> | | |Seq|A0 |A1 |A2 | >>> ------------------------- >>> | A | C | 2 | B | D | E | >>> >>> C -> D: >>> >>> |Src|Dst|RH4 | >>> | | |Seq|A0 |A1 |A2 | >>> ------------------------- >>> | A | D | 1 | B | C | E | >>> >>> D -> E: >>> >>> |Src|Dst|RH4 | >>> | | |Seq|A0 |A1 |A2 | >>> ------------------------- >>> | A | E | 0 | B | C | D | >>> >>> When the packet arrives at E, recreate the original RH4 header for MAC >>> computation: >>> >>> n = ((Hdr Ext Len * 8) - Pad) / (16 - Comp) >>> tmp = Dst >>> Dst = RH4.A[0] >>> RH4.Seq = n >>> for (k = 1; k < n; k++) >>> { >>> RH4.A[k-1] = RH4.A[k] >>> } >>> RH4.A[k] = tmp >>> >>> |Src|Dst|RH4 | >>> | | |Seq|L0 |L1 |L2 | >>> ------------------------- >>> | A | B | 3 | C | D | E | >>> >>> Is that acceptable? >> >> Thanks for the method - it reads reasonable. It is a good way (one >> way? are there others? are there little bugs in that code?) > Probably :-) >> to specify MAC over RH4 coherently - reconstruct the RH at reception. >> This solution is different than solving the mutability of the Hop >> Limit field. > > It is the method stated in RFC 4302 section 3.3.3.1. The fields in > this case are predictable this can be reconstructed, as RH4 is similar > to RH0 which is listed in Appendix A.2 as mutable but predictable. So, > reading this actually suggests the MAC should be computed based on what > the final destination will see - it is fundamentally the same > principle. I agree. Remark this way _is_ written down in that RFC. Without it being written down an implementer is facing the dilemma of whether s/he should reconstruct the header in that way at the receiver or sender? Somebody _should_ reconstruct that way but is it sender or receiver? Contrary to obvious IPsec expectation one may like that a packet sent to several destinations would better reconstruct prior to sending rather than each receiver reconstructing: it is less computing power, LLNs. But different than IPsec. One may like better IPsec because it's specified. But without this order specified two implementers can write non-interoperable code and this is what happens in practice. It is good to write that order down. Worse, with current RPL spec we don't even consider RH. >> Can we see further - RH4 draft also says IPv6-in-IPv6 tunnelling must >> be used sometime, together with RH4. This raises the obvious question >> about: is the header of the encapsulating packet also protected by the >> MAC of RPL? Or not? > Not for DAO ACK as it is wholly within the RPL domain (case 1 in > Section 2 of > http://tools.ietf.org/html/draft-ietf-6man-rpl-routing-header-00) So does that mean that this packet: > +------+------+------+------+------+--------//-+ > | IPv6 | IPv6 | IPv6 | IPv6 | IPv6 | Packet | > | Src | Dst | RH4 | Src | Dst | Payload | > +------+------+------+------+------+--------//-+ > <--- Original Packet ---> > <--- Tunneled Packet ---> has RH4 secured with RPL security and outer src/dst addresses secured with IPsec? (encapsulating IPv6-IPv6 uses IPsec); does it mean that the Border Router must run both IPsec and RPL security? does it mean that the server on the Internet must implement RPL security? Is that RH4 protected by RPL Security? If yes - does the packet originator implement RPL Security? If yes - is that originator a machine outside the RPL domain? > Note that the outer header (including the RH4) is added and removed > by the RPL Border Router. Does the BR remove the outer header each time it receives a packet from a server on the Internet? Or does it _add_ an outer header each time it receives a packet from the server on the Internet? I am not sure how to formulate this, and sorry for looking as too much questioning, this is just comments. [...] >> For example, I wonder how to you plan to refer to that RFC document? >> Just wondering. > > I don't think there is any need to refer to RFC 4302. The > fundamental principles regarding mutable fields are general and do not > apply solely to IPSec. On the other hand, it would help to be explicit > in the RPL draft regarding mutability but I think that is already > agreed. Well - I agree it would help to agree and be explicit about the mutability of fields with respect to RPL computation. That is agreed. Alex >> >> Alex >> >>> >>> Robert >>> >>> Robert Cragie (Pacific Gas & Electric) >>> >>> Gridmerge Ltd. >>> 89 Greenfield Crescent, >>> Wakefield, WF4 4WA, UK >>> +44 1924 910888 >>> +1 415 513 0064 >>> http://www.gridmerge.com >>> >>> >>> On 10/09/2010 4:22 PM, Alexandru Petrescu wrote: >>>> Le 10/09/2010 11:55, Robert Cragie a écrit : >>>>> David, >>>>> >>>>> I totally agree with what you say. Thank you for restating generally >>>>> that IPSec has already been extensively considered - I use the term >>>>> 'paraphernalia' as a general term for the overheads. >>>>> >>>>> Alex - can we please drop the IPSec discussion and move on and >>>>> concentrate on the things which do need to sorted out? >>>> >>>> Ok... let me try to avoid dissent and do what you ask. >>>> >>>> Let's come back to RPL-11 text: >>>>> 3. If the packet header specifies a source route by including a RH4 >>>>> header as specified in [I-D.ietf-6man-rpl-routing-header] >>>> >>>> then draft-ietf-6man-rpl-routing-header-00 says: >>>>> else { swap the IPv6 Destination Address and Address[i] >>>> >>>> That means that there is a mutable but predictable field (IPv6 >>>> Destination Addess) in RH of RPL. But RPL Security doesn't understand >>>> mutable but predictable fields (only mutable as per recent discussion). >>>> RPL Security covers "entire IPv6 packet", which changes enroute despite >>>> RPL Security's expectation it won't change. >>>> >>>> So the question is: does RPL Security secure the RH4 header? I think it >>>> does not, because its MAC computation does not say how are the mutable >>>> but predictable fields covered. >>>> >>>> For example, a sender builds a packet with Dst address1, computes MAC, >>>> inserts MAC. Then intermediary routers process that packet and replace >>>> that Dst address1 with address2 from the Routing Header. Now the packet >>>> is received at address1. The MAC can't be meaningfully computed on the >>>> receiver, because the "IPv6 entire packet" has changed, it is not the >>>> same as at emission. >>>> >>>> I think this example is correct. >>>> >>>> It can't be solved in the same way we solved the mutability of "Hop >>>> Limit" (we said to make HopLimit set to 0 for MAC calculation), because >>>> if we do so then we have a higher risk of attack than when left >>>> HopLimit >>>> unsecure. If we set to 0 de Dst for MAC calculation then the risk of >>>> implication of forged IP dst addresses is higher than forged HopLimit. >>>> Forging an IP dst address is stronger security attack than forging >>>> HopLimit, intuitively speaking. >>>> >>>> Besides, whereas the receiver has really no idea about what could the >>>> original HopLimit be, it knows precisely what the original Dst address >>>> was (it's in the RH4, swapped). Thus the securing solution should be >>>> different - it should be as smart as RH4 is. >>>> >>>> Knowing the previous discussion, it may be possible that people will >>>> request we refer to that Authentication Header RFC which tells how >>>> mutable, mutable but predictable fields are dealt with. At that point >>>> we come back to IPsec, but I will abstain from saying so if you wish. >>>> There is also the fact that previous IPsec talk says RH0 whereas >>>> here we >>>> have RH4 and things may be different. >>>> >>>> That's too long for anyone to read, but you get the point. >>>> >>>> Alex >>>> >>>> >>>> >>>> >>>> You are of course >>>>> entitled to your opinion but progress is only made in the IETF >>>>> through rough consensus. Consensus does not mean unanimous agreement; >>>>> if we can all at least consent to a solution then the process will >>>>> run a lot more smoothly and we will all benefit. Continual dissent >>>>> will only serve to hinder this progress. >>>>> >>>>> I think the consensus is clear: >>>>> >>>>> * We do not mention IPSec in RPL security * The mutable field >>>>> discussion is entirely independent from IPSec >>>>> >>>>> Robert >>>>> >>>>> Robert Cragie (Pacific Gas & Electric) >>>>> >>>>> Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 >>>>> 1924 910888 +1 415 513 0064 http://www.gridmerge.com >>>>> >>>>> >>>>> >>>>> On 09/09/2010 9:33 PM, David Culler wrote: >>>>>> Dear Alex, Thank you for focusing on the question of routing >>>>>> security, rather than internet security in general. Yes, IPSec has >>>>>> been utilized to secure routing protocols. Now please take the >>>>>> next step and focus on routing for low power and lossy networks. >>>>>> Obviously, IPSec has to be the first thing considered. And it was. >>>>>> Dating back to the earliest security framework discussions it was >>>>>> considered many times. We returned to the IPSec issue extensively >>>>>> back in June on the mailing list. I won't reiterate the >>>>>> discussion on the storage and time complexity, nor the message >>>>>> overhead implications that were in those prior postings. But I >>>>>> will observe that no one suggested that they saw their way to a >>>>>> full IPSec implementation within the constraints articulated in the >>>>>> Routing Requirements documents. The WG group has long since >>>>>> reached a rough consensus on this matter and moved on. That is the >>>>>> nature of a group process and specifically the role of WG LC. At >>>>>> some point, we commit to certain things and stop revisiting them >>>>>> from first principles. That allows us to focus more sharply on >>>>>> the selected approach and refine it more completely. For example, >>>>>> in security, we have specifics to resolve, such as which header >>>>>> fields need to be skipped. It is not a matter of "but I imagine >>>>>> that there may be alternatives". There might be. But we don't >>>>>> just turn the same rocks over and over again. We carve the rough >>>>>> stone, we chisel the details, we sand, we polish. >>>>>> >>>>>> So I assume that the point of your posting is that you want to be >>>>>> sure that the justification for the choices that the WG made are >>>>>> properly documented in the WG documents. If you feel that they are >>>>>> not, perhaps you could point to the document and section that you >>>>>> feel should contain this material more substantially. >>>>>> >>>>>> D. >>>>>> >>>>>> For reference,http://www.ietf.org/tao.html section 7.4 >>>>>> >>>>>> >>>>>> On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote: >>>>>> >>>>>>> Le 09/09/2010 16:59, David Culler aécrit : >>>>>>>> The RPL charter calls for us to address routing security >>>>>>>> considerations. Not security in general. Not application >>>>>>>> security. Not link level. Routing security. It is focused for >>>>>>>> good reason. >>>>>>> Routing security like OSPF using IPsec? "Authentication has been >>>>>>> removed from the OSPF protocol and instead relies on IPv6's >>>>>>> Authentication Header and Encapsulating Security Payload (ESP)." >>>>>>> says rfc5340... why does RPL need to be different in this >>>>>>> respect? >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>>> On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote: >>>>>>>> >>>>>>>>> Le 08/09/2010 18:15, Philip Levis aécrit : >>>>>>>>>> On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote: >>>>>>>>>> >>>>>>>>>>> Le 03/09/2010 13:48, Robert Cragie aécrit : [skipped >>>>>>>>>>> agreed opinions about IPsec] >>>>>>>>>>>>> Reusing the IPsec module ensures a secure system - >>>>>>>>>>>>> it's proven by earlier experience. We know it worked >>>>>>>>>>>>> ok so why avoid using it. >>>>>>>>>>>> I don't think the specification of RPL security >>>>>>>>>>>> precludes the use of IPSec instead. Does the use of >>>>>>>>>>>> IPSec need to be specified in the RPL >>>>>>>>>>>> specification? >>>>>>>>>>> YEs, the RPL specification must say something about >>>>>>>>>>> security in its Security Considerations section. That >>>>>>>>>>> something has to mention something about IPsec. >>>>>>>>>> Why does it have to do so? In theory, RPL should be >>>>>>>>>> entirely independent of IPSec. There have already been >>>>>>>>>> numerous discussions about why simply relying on IPSec >>>>>>>>>> would be problematic. Unfortunately you seem to forget >>>>>>>>>> these points every few weeks and rehash the same >>>>>>>>>> discussion. At some point it becomes a waste of everyone's >>>>>>>>>> time. >>>>>>>>> Phil - if RPL says "security" then it must understand that >>>>>>>>> Internet security is usually IPsec. This is truer with IPv6 >>>>>>>>> (as opposed to IPv4) where IPsec is very much integrated in >>>>>>>>> the design (mutable fields, etc.) >>>>>>>>> >>>>>>>>> Have you checked the mutable field discussion? Do you agree >>>>>>>>> that mutable fields must be taken into account? >>>>>>>>> >>>>>>>>> Please read that around 3 people agreed on a list of items >>>>>>>>> which are worth discussion of security and IPsec - mutable >>>>>>>>> fields is one such item. >>>>>>>>> >>>>>>>>> As such this discussion is not a waste of everyone's time. >>>>>>>>> >>>>>>>>> Alex >>>>>>>>> >>>>>>>>>> Phil >>>>>>>>> >>>>>>>>> _______________________________________________ Roll mailing >>>>>>>>> list Roll@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>>> David Cullerculler@cs.berkeley.edu Chair Computer Science >>>>>>>> Associate Chair EECS >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> David Culler culler@cs.berkeley.edu Chair Computer Science >>>>>> Associate Chair EECS >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ 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 >>>> >>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>> >> >> >> From alexandru.petrescu@gmail.com Thu Sep 16 10:25:05 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 287E63A69CF for ; Thu, 16 Sep 2010 10:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.784 X-Spam-Level: X-Spam-Status: No, score=-0.784 tagged_above=-999 required=5 tests=[AWL=-1.135, BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E32Wfix2kyZr for ; Thu, 16 Sep 2010 10:25:03 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id E853E3A69E2 for ; Thu, 16 Sep 2010 10:25:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o8GHPRVk028233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Sep 2010 19:25:27 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o8GHPQ82001960; Thu, 16 Sep 2010 19:25:26 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o8GHPQqb013334; Thu, 16 Sep 2010 19:25:26 +0200 Message-ID: <4C925306.2030203@gmail.com> Date: Thu, 16 Sep 2010 19:25:26 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Rodolfo Gonzalez Bernaldez References: <13773.1282327971@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> <519A78D0-77BC-466C-BAFF-084DEF5D9CB5@cs.stanford.edu> <4C87C73E.1040806@gmail.com> <4C88FD45.60004@gmail.com> <8556A091-D8F9-4B6B-8F49-4260005C577C@cs.berkeley.edu> <4C8A008C.7080406@gridmerge.com><4C8A4D19.40202@gmai l.com> <4C8A6144.1070401@gridme! rge.com><4C8A70EE.1050301@gmail.com> <4C8E0226.3000101@gridmerge.com> <922E7FA7C3F145FF931551134477ED4F@ubilogixrodo> In-Reply-To: <922E7FA7C3F145FF931551134477ED4F@ubilogixrodo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Sep 2010 17:25:05 -0000 Le 13/09/2010 21:22, Rodolfo Gonzalez Bernaldez a écrit : > Hello Robert, Alex, all > I agree with Robert, a reference to the RFC 4302 is not necessary, > referencing it could bring confusion. About to be explicit in the RPL > draft regarding the mutability, I think that a graphic example must be > included. > I agree. Alex >> Now, just because I refer to IPSec AH, it doesn't mean I am suggesting >> we use it. I am suggesting we can use the fundamental principles from >> IPSec for an equivalent operation. > > I understand. I am just afraid sometimes we try to rewrite much parts of > it. > > For example, I wonder how to you plan to refer to that RFC document? > Just wondering. > I don't think there is any need to refer to RFC 4302. The > fundamental principles regarding mutable fields are general and do not > apply solely to IPSec. On the other hand, it would help to be explicit > in the RPL draft regarding mutability but I think that is already > agreed. > > Best regards > Rodolfo. > > *From:* Robert Cragie > *Sent:* Monday, September 13, 2010 3:51 AM > *To:* Alexandru Petrescu > *Cc:* roll@ietf.org > *Subject:* Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit > > Hi Alex, > > Comments inline, bracketed by > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com > > > On 10/09/2010 6:54 PM, Alexandru Petrescu wrote: >> Le 10/09/2010 18:48, Robert Cragie a écrit : >>> Hi Alex, >>> >>> Thank you for focusing on a pertinent issue. You are right to highlight >>> what we do with a RH4 header as I believe secured DAO ACK is the (only) >>> RPL control message which requires RH4 in non-storing mode. >> >> Sounds reassuring to know RH4 is only for DAO ACK and only for >> non-storing mode. >> >> And in storing mode? Is RH4 present in other than DAO ACK? Just to make >> sure I understand you. > > Here is my analysis (please correct if wrong): > > * Storing mode doesn't require the RH4 header as there is no need to > carry the routing information. > * DIS is one hop (link local) > * DIO is multicast > * DAO is routed up the DODAG to the root therefore is not source routed > * That leaves DAO ACK in storing mode > > >> >>> So, to follow the rules for mutable and predictable fields (see RFC >>> 4302), we can resubstitute at the end: >>> >>> Consider the following: >>> >>> A -> B -> C -> D -> E >>> >>> A -> B: >>> >>> |Src|Dst|RH4 | >>> | | |Seq|A0 |A1 |A2 | >>> ------------------------- >>> | A | B | 3 | C | D | E | >>> >>> B -> C: >>> >>> |Src|Dst|RH4 | >>> | | |Seq|A0 |A1 |A2 | >>> ------------------------- >>> | A | C | 2 | B | D | E | >>> >>> C -> D: >>> >>> |Src|Dst|RH4 | >>> | | |Seq|A0 |A1 |A2 | >>> ------------------------- >>> | A | D | 1 | B | C | E | >>> >>> D -> E: >>> >>> |Src|Dst|RH4 | >>> | | |Seq|A0 |A1 |A2 | >>> ------------------------- >>> | A | E | 0 | B | C | D | >>> >>> When the packet arrives at E, recreate the original RH4 header for MAC >>> computation: >>> >>> n = ((Hdr Ext Len * 8) - Pad) / (16 - Comp) >>> tmp = Dst >>> Dst = RH4.A[0] >>> RH4.Seq = n >>> for (k = 1; k < n; k++) >>> { >>> RH4.A[k-1] = RH4.A[k] >>> } >>> RH4.A[k] = tmp >>> >>> |Src|Dst|RH4 | >>> | | |Seq|L0 |L1 |L2 | >>> ------------------------- >>> | A | B | 3 | C | D | E | >>> >>> Is that acceptable? >> >> Thanks for the method - it reads reasonable. It is a good way (one >> way? are there others? are there little bugs in that code?) > Probably :-) >> to specify MAC over RH4 coherently - reconstruct the RH at reception. >> This solution is different than solving the mutability of the Hop >> Limit field. > It is the method stated in RFC 4302 section 3.3.3.1. The fields in > this case are predictable this can be reconstructed, as RH4 is similar > to RH0 which is listed in Appendix A.2 as mutable but predictable. So, > reading this actually suggests the MAC should be computed based on what > the final destination will see - it is fundamentally the same > principle. >> >> Can we see further - RH4 draft also says IPv6-in-IPv6 tunnelling must >> be used sometime, together with RH4. This raises the obvious question >> about: is the header of the encapsulating packet also protected by the >> MAC of RPL? Or not? > Not for DAO ACK as it is wholly within the RPL domain (case 1 in > Section 2 of > http://tools.ietf.org/html/draft-ietf-6man-rpl-routing-header-00) >> >> RPL spec currently says the "entire IPv6 packet" is covered by its >> MAC. But does that cover the IPv6 base header of the encapsulating >> header? Or not? And in which order? > It doesn't apply in this case. >> >>> Now, just because I refer to IPSec AH, it doesn't mean I am suggesting >>> we use it. I am suggesting we can use the fundamental principles from >>> IPSec for an equivalent operation. >> >> I understand. I am just afraid sometimes we try to rewrite much parts >> of it. >> >> For example, I wonder how to you plan to refer to that RFC document? >> Just wondering. > I don't think there is any need to refer to RFC 4302. The > fundamental principles regarding mutable fields are general and do not > apply solely to IPSec. On the other hand, it would help to be explicit > in the RPL draft regarding mutability but I think that is already > agreed. >> >> Alex >> >>> >>> Robert >>> >>> Robert Cragie (Pacific Gas & Electric) >>> >>> Gridmerge Ltd. >>> 89 Greenfield Crescent, >>> Wakefield, WF4 4WA, UK >>> +44 1924 910888 >>> +1 415 513 0064 >>> http://www.gridmerge.com >>> >>> >>> On 10/09/2010 4:22 PM, Alexandru Petrescu wrote: >>>> Le 10/09/2010 11:55, Robert Cragie a écrit : >>>>> David, >>>>> >>>>> I totally agree with what you say. Thank you for restating generally >>>>> that IPSec has already been extensively considered - I use the term >>>>> 'paraphernalia' as a general term for the overheads. >>>>> >>>>> Alex - can we please drop the IPSec discussion and move on and >>>>> concentrate on the things which do need to sorted out? >>>> >>>> Ok... let me try to avoid dissent and do what you ask. >>>> >>>> Let's come back to RPL-11 text: >>>>> 3. If the packet header specifies a source route by including a RH4 >>>>> header as specified in [I-D.ietf-6man-rpl-routing-header] >>>> >>>> then draft-ietf-6man-rpl-routing-header-00 says: >>>>> else { swap the IPv6 Destination Address and Address[i] >>>> >>>> That means that there is a mutable but predictable field (IPv6 >>>> Destination Addess) in RH of RPL. But RPL Security doesn't understand >>>> mutable but predictable fields (only mutable as per recent discussion). >>>> RPL Security covers "entire IPv6 packet", which changes enroute despite >>>> RPL Security's expectation it won't change. >>>> >>>> So the question is: does RPL Security secure the RH4 header? I think it >>>> does not, because its MAC computation does not say how are the mutable >>>> but predictable fields covered. >>>> >>>> For example, a sender builds a packet with Dst address1, computes MAC, >>>> inserts MAC. Then intermediary routers process that packet and replace >>>> that Dst address1 with address2 from the Routing Header. Now the packet >>>> is received at address1. The MAC can't be meaningfully computed on the >>>> receiver, because the "IPv6 entire packet" has changed, it is not the >>>> same as at emission. >>>> >>>> I think this example is correct. >>>> >>>> It can't be solved in the same way we solved the mutability of "Hop >>>> Limit" (we said to make HopLimit set to 0 for MAC calculation), because >>>> if we do so then we have a higher risk of attack than when left >>>> HopLimit >>>> unsecure. If we set to 0 de Dst for MAC calculation then the risk of >>>> implication of forged IP dst addresses is higher than forged HopLimit. >>>> Forging an IP dst address is stronger security attack than forging >>>> HopLimit, intuitively speaking. >>>> >>>> Besides, whereas the receiver has really no idea about what could the >>>> original HopLimit be, it knows precisely what the original Dst address >>>> was (it's in the RH4, swapped). Thus the securing solution should be >>>> different - it should be as smart as RH4 is. >>>> >>>> Knowing the previous discussion, it may be possible that people will >>>> request we refer to that Authentication Header RFC which tells how >>>> mutable, mutable but predictable fields are dealt with. At that point >>>> we come back to IPsec, but I will abstain from saying so if you wish. >>>> There is also the fact that previous IPsec talk says RH0 whereas >>>> here we >>>> have RH4 and things may be different. >>>> >>>> That's too long for anyone to read, but you get the point. >>>> >>>> Alex >>>> >>>> >>>> >>>> >>>> You are of course >>>>> entitled to your opinion but progress is only made in the IETF >>>>> through rough consensus. Consensus does not mean unanimous agreement; >>>>> if we can all at least consent to a solution then the process will >>>>> run a lot more smoothly and we will all benefit. Continual dissent >>>>> will only serve to hinder this progress. >>>>> >>>>> I think the consensus is clear: >>>>> >>>>> * We do not mention IPSec in RPL security * The mutable field >>>>> discussion is entirely independent from IPSec >>>>> >>>>> Robert >>>>> >>>>> Robert Cragie (Pacific Gas & Electric) >>>>> >>>>> Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 >>>>> 1924 910888 +1 415 513 0064 http://www.gridmerge.com >>>>> >>>>> >>>>> >>>>> On 09/09/2010 9:33 PM, David Culler wrote: >>>>>> Dear Alex, Thank you for focusing on the question of routing >>>>>> security, rather than internet security in general. Yes, IPSec has >>>>>> been utilized to secure routing protocols. Now please take the >>>>>> next step and focus on routing for low power and lossy networks. >>>>>> Obviously, IPSec has to be the first thing considered. And it was. >>>>>> Dating back to the earliest security framework discussions it was >>>>>> considered many times. We returned to the IPSec issue extensively >>>>>> back in June on the mailing list. I won't reiterate the >>>>>> discussion on the storage and time complexity, nor the message >>>>>> overhead implications that were in those prior postings. But I >>>>>> will observe that no one suggested that they saw their way to a >>>>>> full IPSec implementation within the constraints articulated in the >>>>>> Routing Requirements documents. The WG group has long since >>>>>> reached a rough consensus on this matter and moved on. That is the >>>>>> nature of a group process and specifically the role of WG LC. At >>>>>> some point, we commit to certain things and stop revisiting them >>>>>> from first principles. That allows us to focus more sharply on >>>>>> the selected approach and refine it more completely. For example, >>>>>> in security, we have specifics to resolve, such as which header >>>>>> fields need to be skipped. It is not a matter of "but I imagine >>>>>> that there may be alternatives". There might be. But we don't >>>>>> just turn the same rocks over and over again. We carve the rough >>>>>> stone, we chisel the details, we sand, we polish. >>>>>> >>>>>> So I assume that the point of your posting is that you want to be >>>>>> sure that the justification for the choices that the WG made are >>>>>> properly documented in the WG documents. If you feel that they are >>>>>> not, perhaps you could point to the document and section that you >>>>>> feel should contain this material more substantially. >>>>>> >>>>>> D. >>>>>> >>>>>> For reference,http://www.ietf.org/tao.html section 7.4 >>>>>> >>>>>> >>>>>> On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote: >>>>>> >>>>>>> Le 09/09/2010 16:59, David Culler aécrit : >>>>>>>> The RPL charter calls for us to address routing security >>>>>>>> considerations. Not security in general. Not application >>>>>>>> security. Not link level. Routing security. It is focused for >>>>>>>> good reason. >>>>>>> Routing security like OSPF using IPsec? "Authentication has been >>>>>>> removed from the OSPF protocol and instead relies on IPv6's >>>>>>> Authentication Header and Encapsulating Security Payload (ESP)." >>>>>>> says rfc5340... why does RPL need to be different in this >>>>>>> respect? >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>>> On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote: >>>>>>>> >>>>>>>>> Le 08/09/2010 18:15, Philip Levis aécrit : >>>>>>>>>> On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote: >>>>>>>>>> >>>>>>>>>>> Le 03/09/2010 13:48, Robert Cragie aécrit : [skipped >>>>>>>>>>> agreed opinions about IPsec] >>>>>>>>>>>>> Reusing the IPsec module ensures a secure system - >>>>>>>>>>>>> it's proven by earlier experience. We know it worked >>>>>>>>>>>>> ok so why avoid using it. >>>>>>>>>>>> I don't think the specification of RPL security >>>>>>>>>>>> precludes the use of IPSec instead. Does the use of >>>>>>>>>>>> IPSec need to be specified in the RPL >>>>>>>>>>>> specification? >>>>>>>>>>> YEs, the RPL specification must say something about >>>>>>>>>>> security in its Security Considerations section. That >>>>>>>>>>> something has to mention something about IPsec. >>>>>>>>>> Why does it have to do so? In theory, RPL should be >>>>>>>>>> entirely independent of IPSec. There have already been >>>>>>>>>> numerous discussions about why simply relying on IPSec >>>>>>>>>> would be problematic. Unfortunately you seem to forget >>>>>>>>>> these points every few weeks and rehash the same >>>>>>>>>> discussion. At some point it becomes a waste of everyone's >>>>>>>>>> time. >>>>>>>>> Phil - if RPL says "security" then it must understand that >>>>>>>>> Internet security is usually IPsec. This is truer with IPv6 >>>>>>>>> (as opposed to IPv4) where IPsec is very much integrated in >>>>>>>>> the design (mutable fields, etc.) >>>>>>>>> >>>>>>>>> Have you checked the mutable field discussion? Do you agree >>>>>>>>> that mutable fields must be taken into account? >>>>>>>>> >>>>>>>>> Please read that around 3 people agreed on a list of items >>>>>>>>> which are worth discussion of security and IPsec - mutable >>>>>>>>> fields is one such item. >>>>>>>>> >>>>>>>>> As such this discussion is not a waste of everyone's time. >>>>>>>>> >>>>>>>>> Alex >>>>>>>>> >>>>>>>>>> Phil >>>>>>>>> >>>>>>>>> _______________________________________________ Roll mailing >>>>>>>>> list Roll@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>>> David Cullerculler@cs.berkeley.edu Chair Computer Science >>>>>>>> Associate Chair EECS >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> David Culler culler@cs.berkeley.edu Chair Computer Science >>>>>> Associate Chair EECS >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 pthubert@cisco.com Thu Sep 16 11:19:07 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05E5B3A6B3B; Thu, 16 Sep 2010 11:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.474 X-Spam-Level: X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8Go1IzKKXrs; Thu, 16 Sep 2010 11:19:05 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id BEE313A6AD5; Thu, 16 Sep 2010 11:19:05 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPv7kUyrRN+K/2dsb2JhbACiC3GodJxHhUEEjTM X-IronPort-AV: E=Sophos;i="4.56,377,1280707200"; d="scan'208";a="279291954" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 16 Sep 2010 18:19:31 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o8GIJUZS018200; Thu, 16 Sep 2010 18:19:30 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Sep 2010 20:19: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Sep 2010 20:19:25 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02C595B1@XMB-AMS-107.cisco.com> In-Reply-To: <4C92493E.8090406@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Flow Label: 12 bits mutable and 8 bits immutable Thread-Index: ActVvmAFZu7xD61VSse5wb7yzQVXxAADL/8g References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com> <4C9030FF.6060302@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02C593B6@XMB-AMS-107.cisco.com> <4C92493E.8090406@oracle.com> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" X-OriginalArrivalTime: 16 Sep 2010 18:19:29.0411 (UTC) FILETIME=[B3D6C530:01CB55CB] Cc: ipv6@ietf.org, Carsten Bormann , roll@ietf.org, Brian E Carpenter Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Sep 2010 18:19:07 -0000 Hi erik, If we compress IP in IP and a HbH header, we can hardly make that 0 bits overhead. The FL allows a total cost of 20 bits, whereas the compression will end up with 5 or 6 octets minimum... Pascal > -----Original Message----- > From: Erik Nordmark [mailto:erik.nordmark@oracle.com] > Sent: Thursday, September 16, 2010 6:44 PM > To: Pascal Thubert (pthubert) > Cc: Philip Levis; Carsten Bormann; roll@ietf.org; ipv6@ietf.org; > mcr@sandelman.ca; Brian E Carpenter > Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable >=20 > On 09/16/10 05:07 AM, Pascal Thubert (pthubert) wrote: >=20 > >> Has anybody discussed adding a header with just the 3 bytes you need > >> *before* the IP header? > > > > We've discussed using forms of tag switching from the beginning of the > > WG but there must be an IP based reference model before we start doing > > the tricks. >=20 > You can have a reference model which uses IP-in-IP plus a destination options > to carry the 3 bytes, and then have an optimization for low speed networks like > 6lowpan that sticks those bytes somewhere else as Carsten suggested. >=20 > Architecturally, in both cases, we'd end up with the 3 bytes before the > (inner) IP header. >=20 > Erik From remi.despres@free.fr Wed Sep 15 03:31:49 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 234CA3A6B90; Wed, 15 Sep 2010 03:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.329 X-Spam-Level: X-Spam-Status: No, score=-1.329 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hiAfW1TIUza; Wed, 15 Sep 2010 03:31:48 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.3]) by core3.amsl.com (Postfix) with ESMTP id A41223A6AD0; Wed, 15 Sep 2010 03:31:47 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2113.sfr.fr (SMTP Server) with ESMTP id 96DD8700008B; Wed, 15 Sep 2010 12:32:12 +0200 (CEST) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2113.sfr.fr (SMTP Server) with ESMTP id 95C127000088; Wed, 15 Sep 2010 12:32:11 +0200 (CEST) X-SFR-UUID: 20100915103211613.95C127000088@msfrf2113.sfr.fr Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4C9030FF.6060302@oracle.com> Date: Wed, 15 Sep 2010 12:32:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <24F3ABB7-C683-4D4C-838D-ED392C02591D@free.fr> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com> <4C9030FF.6060302@oracle.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Fri, 17 Sep 2010 08:07:03 -0700 Cc: ipv6@ietf.org, Carsten Bormann , roll@ietf.org, Brian E Carpenter Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Sep 2010 10:31:49 -0000 Le 15 sept. 2010 =E0 04:35, Erik Nordmark a =E9crit : > ... Has anybody discussed adding a header with just the 3 bytes you = need *before* the IP header? > That avoids the overhead. In www.ietf.org/mail-archive/web/ipv6/current/msg12204, I essentially = proposed that (quote below). > The downside is that you need a new code point (for demux) in the = different layer2s that you want to run this on. If this header could be made mandatory for RPL interfaces, this wouldn't = even be necessary. > But it seems a lot simpler than trying to overload some existing IPv6 = header field. Full agreement. Regards, RD QUOTE: <<< De : R=E9mi Despr=E9s > Date : 12 ao=FBt 2010 14:54:46 HAEC > ... >> There is certainly a strong benefit in Low Power Lossy Networks to = make >> the flow label mutable. >=20 > How strong the benefit isn't clear to me. > Since RPL networks are recognized as such by hosts, it seems easy to = add a short field, just before the IP header, to contain whatever is = useful for this kind of network. > Mixing functions with those of FLs would thus be avoided. >>> From fred@cisco.com Wed Sep 15 10:01:40 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01E4D3A69E9; Wed, 15 Sep 2010 10:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.075 X-Spam-Level: X-Spam-Status: No, score=-110.075 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THx1KasGwURr; Wed, 15 Sep 2010 10:01:39 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0515D3A69ED; Wed, 15 Sep 2010 10:01:39 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPOYkEyrR7Ht/2dsb2JhbAChZnGpZJwjhUEEhEqFYoJ+ X-IronPort-AV: E=Sophos;i="4.56,371,1280707200"; d="scan'208";a="589701927" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 15 Sep 2010 17:02:04 +0000 Received: from Freds-Computer.local (sjc-vpn3-595.cisco.com [10.21.66.83]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o8FH1ca2001134; Wed, 15 Sep 2010 17:01:58 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Wed, 15 Sep 2010 12:02:03 -0500 X-PGP-Universal: processed; by Freds-Computer.local on Wed, 15 Sep 2010 12:02:03 -0500 Mime-Version: 1.0 (Apple Message framework v1081) From: Fred Baker In-Reply-To: Date: Wed, 15 Sep 2010 09:19:22 -0500 Message-Id: <1C65D00D-7447-4DB6-8EAA-D1760D30ADFA@cisco.com> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com> <4C9030FF.6060302@oracle.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 17 Sep 2010 08:07:03 -0700 Cc: IPv6 WG , ROLL WG Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Sep 2010 17:01:40 -0000 So that might use the mesh network header part of the 6lowpan header? On Sep 15, 2010, at 12:06 AM, Carsten Bormann wrote: >> Has anybody discussed adding a header with just the 3 bytes you need = *before* the IP header? >=20 > Yes. Ever since you proposed pretty much that at a previous IETF = meeting, I've been thinking that architecturally it makes a lot of sense = to think about ROLL as a sub-IP protocol. >=20 >> The downside is that you need a new code point (for demux) in the = different layer2s that you want to run this on. >=20 > And that is exactly the non-starter about the general proposal. > It is not acceptable to require a new spec for each of the many link = layers we want to run ROLL on, in particular for those who don't really = care that much about the overhead. >=20 > However, it would be pretty easy to put something in 6lowpan to carry = those 3 bytes. > (Consider it an advanced form of header compression for the 48-byte = IP-in-IP thing, if you don't like the sub-IP thinking.) > Consult http://tools.ietf.org/html/draft-bormann-6lowpan-ext-hdr-00 = for a sample base design. > Such a simple extension may actually be a preferable way to carry ROLL = in 6lowpan. >=20 > Gruesse, Carsten >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From cabocabo@gmail.com Wed Sep 15 12:06:09 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E9C43A6A27; Wed, 15 Sep 2010 12:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.66 X-Spam-Level: X-Spam-Status: No, score=-0.66 tagged_above=-999 required=5 tests=[AWL=-1.939, BAYES_00=-2.599, FRT_ROLEX=3.878] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMSwnCuMsJsG; Wed, 15 Sep 2010 12:06:08 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 0931B3A69B4; Wed, 15 Sep 2010 12:06:07 -0700 (PDT) Received: by bwz9 with SMTP id 9so1164893bwz.31 for ; Wed, 15 Sep 2010 12:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=dYPtWKp7V/3E1BXyyLXRsOdJ7Lc5x589Zy7ZyFpA4NM=; b=JWfJi8BQ4y+KeZZpS/sHUjlkpUpwPwVqMLXZkTMTXTP9icREmvkGix+kTjowwd2YNA ijUm5XtwYBiJdOJcPyFzwn4gb8ENT0D8hEr8nl8t1W9vapXnUSfylNO5vNSf71vDredY rEaPyDD7+a0f7rerxlAsgmho/C3Zh8SzA399s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=MvJcYfP+Y2sgd9E3oUqRBYo212QwkWU6Z3ACM0IAV7iJ1eI/doFrb4a4V8ksJwp4+/ Ez+z7HkeTAYRKx0YiielFWX9+zw2KkU6fFUeas7E/ZFlGw5QJd8i6+qiv1HU2TNjufsf OTLjUOe7u4DKSftqjB1q8EZY4Y+wBsdQ4b86Y= Received: by 10.204.82.18 with SMTP id z18mr1581044bkk.125.1284577592617; Wed, 15 Sep 2010 12:06:32 -0700 (PDT) Received: from [192.168.217.101] (p5489A764.dip.t-dialin.net [84.137.167.100]) by mx.google.com with ESMTPS id g12sm1643150bkb.14.2010.09.15.12.06.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 15 Sep 2010 12:06:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <1C65D00D-7447-4DB6-8EAA-D1760D30ADFA@cisco.com> Date: Wed, 15 Sep 2010 21:06:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <69ECAC23-4D20-4EDD-AA75-FFC9A67A5E2E@gmail.com> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com> <4C9030FF.6060302@oracle.com> <1C65D00D-7447-4DB6-8EAA-D1760D30ADFA@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Fri, 17 Sep 2010 08:07:03 -0700 Cc: ROLL WG , IPv6 WG Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Sep 2010 19:06:09 -0000 On Sep 15, 2010, at 16:19, Fred Baker wrote: > So that might use the mesh network header part of the 6lowpan header? That would be a bit more radical, I think (and there is no place to put = a rank or instance ID in RFC 4944). But the effect is similar, as the ROLL-specific information would = precede the (compressed) IP header. The difference is in handling fragmentation: in mesh-under, each = fragment is l2-routed separately; here, we route entire IP packets. (The relationship of this extension header with fragmentation headers = needs to be defined, but this seems quite simple to me: It only ever = would appear on first fragments. If you want to do the per-fragment = forwarding trick instead of reassemble-before-foward, the ROLL extension = header information just goes into the tag cache together with the IP = header.) Gruesse, Carsten >=20 > On Sep 15, 2010, at 12:06 AM, Carsten Bormann wrote: >=20 >>> Has anybody discussed adding a header with just the 3 bytes you need = *before* the IP header? >>=20 >> Yes. Ever since you proposed pretty much that at a previous IETF = meeting, I've been thinking that architecturally it makes a lot of sense = to think about ROLL as a sub-IP protocol. >>=20 >>> The downside is that you need a new code point (for demux) in the = different layer2s that you want to run this on. >>=20 >> And that is exactly the non-starter about the general proposal. >> It is not acceptable to require a new spec for each of the many link = layers we want to run ROLL on, in particular for those who don't really = care that much about the overhead. >>=20 >> However, it would be pretty easy to put something in 6lowpan to carry = those 3 bytes. >> (Consider it an advanced form of header compression for the 48-byte = IP-in-IP thing, if you don't like the sub-IP thinking.) >> Consult http://tools.ietf.org/html/draft-bormann-6lowpan-ext-hdr-00 = for a sample base design. >> Such a simple extension may actually be a preferable way to carry = ROLL in 6lowpan. >>=20 >> Gruesse, Carsten >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From cabo@tzi.org Fri Sep 17 10:11:03 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66093A68A5; Fri, 17 Sep 2010 10:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.156 X-Spam-Level: X-Spam-Status: No, score=-106.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xScPns4nWpIU; Fri, 17 Sep 2010 10:10:58 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id D13973A6868; Fri, 17 Sep 2010 10:10:51 -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 o8F6pLxl011055; Wed, 15 Sep 2010 08:51:21 +0200 (CEST) Received: from eduroam-0016.wlan.uni-bremen.de (eduroam-0016.wlan.uni-bremen.de [134.102.16.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5FC42F5B; Wed, 15 Sep 2010 08:51:21 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4C9030FF.6060302@oracle.com> Date: Wed, 15 Sep 2010 08:51:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com> <4C9030FF.6060302@oracle.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1081) Cc: ROLL WG , IPv6 WG Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 17 Sep 2010 17:11:03 -0000 > Has anybody discussed adding a header with just the 3 bytes you need = *before* the IP header? Yes. Ever since you proposed pretty much that at a previous IETF = meeting, I've been thinking that architecturally it makes a lot of sense = to think about ROLL as a sub-IP protocol. > The downside is that you need a new code point (for demux) in the = different layer2s that you want to run this on. And that is exactly the non-starter about the general proposal. It is not acceptable to require a new spec for each of the many link = layers we want to run ROLL on, in particular for those who don't really = care that much about the overhead. However, it would be pretty easy to put something in 6lowpan to carry = those 3 bytes. (Consider it an advanced form of header compression for the 48-byte = IP-in-IP thing, if you don't like the sub-IP thinking.) Consult http://tools.ietf.org/html/draft-bormann-6lowpan-ext-hdr-00 for = a sample base design. Such a simple extension may actually be a preferable way to carry ROLL = in 6lowpan. Gruesse, Carsten From alexandru.petrescu@gmail.com Fri Sep 17 15:04:51 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932813A6924 for ; Fri, 17 Sep 2010 15:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwXJt8NyyXOj for ; Fri, 17 Sep 2010 15:04:50 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF1B3A68E6 for ; Fri, 17 Sep 2010 15:04:48 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id C2A609400E3; Sat, 18 Sep 2010 00:05:07 +0200 (CEST) Message-ID: <4C93E611.5070703@gmail.com> Date: Sat, 18 Sep 2010 00:05:05 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: JP Vasseur References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> <028401caf6e5$c5592d60$500b8820$@com> <039a01caf88d$5b4e5d60$11eb1820$@com> <1274424605.3101.128.camel@d430> <115B81B3-7678-4293-BE38-F35E7ACA2D8D@cisco.com> In-Reply-To: <115B81B3-7678-4293-BE38-F35E7ACA2D8D@cisco.com> Content-Type: multipart/mixed; boundary="------------040801070907060508060304" X-Antivirus: avast! (VPS 100917-1, 17/09/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] whither draft-ietf-roll-protocols-survey-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 17 Sep 2010 22:04:51 -0000 This is a multi-part message in MIME format. --------------040801070907060508060304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit JP, this is an old thread. Le 21/05/2010 12:25, JP Vasseur a écrit : > > On May 21, 2010, at 8:50 AM, Geoff Mulligan wrote: > >> What ever happened to the protocol survey draft? >> >> Samita's message about the proliferation of drafts that atrophy got >> me wondering about the protocol survey draft. This is a working >> group document and is part of the milestones and charter of the >> ROLL WG, but this draft has long since expired. >> >> It was supposed to be submitted to the IESG as an informational RFC >> back in Feb 2009. It was last updated in April of 2009 so I would >> think that it is complete. Why hasn't it been submitted to the >> IESG? Given that it was THIS document that was the basis for the >> decision to create a new routing protocol it is important that this >> information is not lost. >> >> Did the WG ever even Last Call this document? > > The decision was made not to publish it as an RFC (see WG minutes), > also in agreement with our AD. > > This will be reflected in the Milestone when we will work on them, > with the WG. The mails from WG members that I read do not seem to indicate silence about this draft. Milestone, AD, RFC, minutes, WG are hard to corelate. What happens to this draft-ietf-roll-protocols-survey-07? What happens to RPL meeting all of those ideals itself (attached email)? I am asking because I have personally put much energy into discussing this draft and I find very strange to drop a WG item. I think there exist no IETF procedure to drop a WG item (it is the first time I see.) IMHO, Alex > > Thanks. > > JP. > >> >> geoff >> >> >> _______________________________________________ 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 > --------------040801070907060508060304 Content-Type: message/rfc822; name="Message joint" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Message joint" Return-Path: alexandru.petrescu+caf_=alexandru.petrescu=incognitus.eu@gmail.com Received: from zimbra31-e6.priv.proxad.net (LHLO zimbra31-e6.priv.proxad.net) (172.20.243.181) by zimbra31-e6.priv.proxad.net with LMTP; Thu, 9 Sep 2010 12:54:18 +0200 (CEST) Received: from relay1-d.mail.gandi.net (mx23-g26.priv.proxad.net [172.20.243.93]) by zimbra31-e6.priv.proxad.net (Postfix) with ESMTP id 2D9CB118C71 for ; Thu, 9 Sep 2010 12:54:18 +0200 (CEST) Received: from relay1-d.mail.gandi.net ([217.70.183.193]) by mx1-g20.free.fr (MXproxy) for alexandru.petrescu@free.fr ; Thu, 9 Sep 2010 12:54:18 +0200 (CEST) X-ProXaD-SC: state=HAM score=0 X-Originating-IP: 10.0.21.74 Received: from spool.mail.gandi.net (mspool4-v.mgt.gandi.net [10.0.21.74]) by relay1-d.mail.gandi.net (Postfix) with ESMTP id 133E82552F9; Thu, 9 Sep 2010 12:54:18 +0200 (CEST) Received: from mfilter3-v.gandi.net (mfilter3-v.gandi.net [217.70.178.37]) by spool.mail.gandi.net (Postfix) with ESMTP id EA96A2DC062; Thu, 9 Sep 2010 12:54:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter3-v.gandi.net Received: from spool.mail.gandi.net ([10.0.21.74]) by mfilter3-v.gandi.net (mfilter3-v.gandi.net [217.70.178.37]) (amavisd-new, port 10024) with ESMTP id F3JDrEIqHnIE; Thu, 9 Sep 2010 12:54:17 +0200 (CEST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by spool.mail.gandi.net (Postfix) with ESMTP id 2BECA2DC060 for ; Thu, 9 Sep 2010 12:54:17 +0200 (CEST) Received: by bwz20 with SMTP id 20so1388226bwz.27 for ; Thu, 09 Sep 2010 03:54:16 -0700 (PDT) Received: by 10.204.102.141 with SMTP id g13mr661597bko.200.1284029656779; Thu, 09 Sep 2010 03:54:16 -0700 (PDT) X-Forwarded-To: alexandru.petrescu@incognitus.eu X-Forwarded-For: alexandru.petrescu@gmail.com alexandru.petrescu@incognitus.eu Delivered-To: alexandru.petrescu@gmail.com Received: by 10.204.51.82 with SMTP id c18cs46128bkg; Thu, 9 Sep 2010 03:54:16 -0700 (PDT) Received: by 10.216.145.199 with SMTP id p49mr145628wej.18.1284029655505; Thu, 09 Sep 2010 03:54:15 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by mx.google.com with ESMTP id v63si1477389weq.10.2010.09.09.03.54.15; Thu, 09 Sep 2010 03:54:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of Chris.Dearlove@baesystems.com designates 20.133.40.55 as permitted sender) client-ip=20.133.40.55; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of Chris.Dearlove@baesystems.com designates 20.133.40.55 as permitted sender) smtp.mail=Chris.Dearlove@baesystems.com X-IronPort-AV: E=Sophos;i="4.56,338,1280703600"; d="scan'208";a="86445145" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 09 Sep 2010 11:54:15 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o89AsEet011022; Thu, 9 Sep 2010 11:54:14 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Sep 2010 11:54:14 +0100 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: 7bit Subject: RE: Last Call: (RPL: IPv6 RoutingProtocol for Low power and Lossy Networks) to Proposed Standard Date: Thu, 9 Sep 2010 11:54:13 +0100 Message-ID: In-Reply-To: <4C8732D9.5010809@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: (RPL: IPv6 RoutingProtocol for Low power and Lossy Networks) to Proposed Standard Thread-Index: ActPIohRUaPMjigkQyWcPWvMW/KdZgA4wXnw References: <20100818222846.13825.49680.idtracker@localhost> <4C8732D9.5010809@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , Cc: "ROLL WG" , , X-OriginalArrivalTime: 09 Sep 2010 10:54:14.0564 (UTC) FILETIME=[57A85E40:01CB500D] X-Antivirus: avast! (VPS 100909-0, 09/09/2010), Inbound message X-Antivirus-Status: Clean > That can still be corrected (revive draft-ietf-roll-protocols-survey-07). That was dropped because some people had various issues with it. That draft, very roughly speaking, said "none of these existing protocols do what we want because they fail to meet the ideal we have set for these various reasons". The issues were over whether all such characteristions were accurate. (Note that absolute accuracy may not be essential to make a WG decision, but a higher standard is needed in an RFC. But I do not recall what the specific issues were.) What I'd find interesting is whether RPL meets all of those ideals itself. (That's a genuine question, I don't know.) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --------------040801070907060508060304-- From alexandru.petrescu@gmail.com Fri Sep 17 15:12:25 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49F1C3A692A for ; Fri, 17 Sep 2010 15:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.683 X-Spam-Level: X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIPfB1VDVr3u for ; Fri, 17 Sep 2010 15:12:24 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id B18753A6922 for ; Fri, 17 Sep 2010 15:12:22 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 530249400A4 for ; Sat, 18 Sep 2010 00:12:42 +0200 (CEST) Message-ID: <4C93E7D7.3000603@gmail.com> Date: Sat, 18 Sep 2010 00:12:39 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100917-1, 17/09/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 17 Sep 2010 22:12:25 -0000 David, Thanks for this Last Call on the RoLL routing metrics draft. I reply now just to make sure I replied before the September 30th, 2010, the deadline Chair set and that I consider. I have proposed last year to have energy link metrics: how much energy in Joules is required on a particular link to send 1280bytes as an IPv6 packet. I have proposed this link metric also as an extension to the ripless draft-mulligan-roll-ripless-01. In draft-ietf-roll-routing-metrics energy _is_ used as a metric but as node energy only, not link energy. Link metrics _are_ considered in draft-ietf-roll-routing-metrics but not as energy. Private discussion pointed me unilaterally I may be wrong but I think publicly I may be right. I will send more comments later. Alex Le 16/09/2010 15:56, David Culler a écrit : > The routing metrics draft has now gone through 9 revisions over the > past 16 months, the diffs have narrowed to essentially wording and > editorial changes, and the comments are few and non-controversial. > Thus, it appears that consensus has emerged and we can LC this I-D. > > This email is to announce Working Group Last Call on > draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST, > Sept. 30 2010. Please read it thoroughly and forward all final > comments to the authors and the WG mailing list. > > Thanks all for your good work. We're on a ROLL. > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From erik.nordmark@oracle.com Fri Sep 17 15:55:48 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA58C3A692A; Fri, 17 Sep 2010 15:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.337 X-Spam-Level: X-Spam-Status: No, score=-106.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-62jGda7srs; Fri, 17 Sep 2010 15:55:47 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 6B6B13A68F3; Fri, 17 Sep 2010 15:55:47 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o8HMu42p012617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Sep 2010 22:56:05 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o8HMH4J3017374; Fri, 17 Sep 2010 22:56:01 GMT Received: from abhmt010.oracle.com by acsmt353.oracle.com with ESMTP id 608677601284764101; Fri, 17 Sep 2010 15:55:01 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 Sep 2010 15:55:01 -0700 Message-ID: <4C93F1D4.1030909@oracle.com> Date: Fri, 17 Sep 2010 15:55:16 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.7) Gecko/20100817 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com> <4C9030FF.6060302@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02C593B6@XMB-AMS-107.cisco.com> <4C92493E.8090406@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02C595B1@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02C595B1@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Carsten Bormann , roll@ietf.org, Brian E Carpenter Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 17 Sep 2010 22:55:48 -0000 On 09/16/10 11:19 AM, Pascal Thubert (pthubert) wrote: > Hi erik, > > If we compress IP in IP and a HbH header, we can hardly make that 0 bits > overhead. The FL allows a total cost of 20 bits, whereas the > compression will end up with 5 or 6 octets minimum... You misunderstood my suggestion. Erik > Pascal > > >> -----Original Message----- >> From: Erik Nordmark [mailto:erik.nordmark@oracle.com] >> Sent: Thursday, September 16, 2010 6:44 PM >> To: Pascal Thubert (pthubert) >> Cc: Philip Levis; Carsten Bormann; roll@ietf.org; ipv6@ietf.org; >> mcr@sandelman.ca; Brian E Carpenter >> Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable >> >> On 09/16/10 05:07 AM, Pascal Thubert (pthubert) wrote: >> >>>> Has anybody discussed adding a header with just the 3 bytes you > need >>>> *before* the IP header? >>> >>> We've discussed using forms of tag switching from the beginning of > the >>> WG but there must be an IP based reference model before we start > doing >>> the tricks. >> >> You can have a reference model which uses IP-in-IP plus a destination > options >> to carry the 3 bytes, and then have an optimization for low speed > networks like >> 6lowpan that sticks those bytes somewhere else as Carsten suggested. >> >> Architecturally, in both cases, we'd end up with the 3 bytes before > the >> (inner) IP header. >> >> Erik From jpv@cisco.com Sat Sep 18 02:54:58 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E95C3A68F5 for ; Sat, 18 Sep 2010 02:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.883 X-Spam-Level: X-Spam-Status: No, score=-109.883 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlTt9tYv4j2i for ; Sat, 18 Sep 2010 02:54:56 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 866623A69CF for ; Sat, 18 Sep 2010 02:54:56 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQFAI4plEyrR7Ht/2dsb2JhbAAwogJxowacPoVABIozgn4G X-IronPort-AV: E=Sophos;i="4.56,385,1280707200"; d="scan'208,217";a="188510510" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 18 Sep 2010 09:55:20 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o8I9tJi3000289; Sat, 18 Sep 2010 09:55:20 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 18 Sep 2010 11:55:19 +0200 Received: from [10.144.2.36] ([10.55.87.95]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 18 Sep 2010 11:55:17 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-21--634387718 From: JP Vasseur In-Reply-To: <4C93E611.5070703@gmail.com> Date: Sat, 18 Sep 2010 00:36:13 +0200 Message-Id: <883E4EB2-3793-4A22-B399-020ECC217C21@cisco.com> References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> <028401caf6e5$c5592d60$500b8820$@com> <039a01caf88d$5b4e5d60$11eb1820$@com> <1274424605.3101.128.camel@d430> <115B81B3-7678-4293-BE38-F35E7ACA2D8D@cisco.com> <4C93E611.5070703@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 18 Sep 2010 09:55:18.0007 (UTC) FILETIME=[996C5870:01CB5717] Cc: roll@ietf.org Subject: Re: [Roll] whither draft-ietf-roll-protocols-survey-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 18 Sep 2010 09:54:58 -0000 --Apple-Mail-21--634387718 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Alex, You may want to refer to the minutes IETF-75 (July 2009): 2) WG Status (Chairs - 10 mn) [15] Slides: http://www.ietf.org/proceedings/75/slides/roll-0.ppt (Unfortunately, no pdf version supplied) Rene Struik has joined as Technical advisor / security advisor - Welcome Rene First RFC 5548 out Various routing reqd. I-Ds still pending discusses=20 for a couple of documents, WG chairs iterating with the ADs to resolve issues. Protocol survey - all issues resolved, tremendous=20 amount of work, thanks to the team working on this.=20 Allowed rechartering, and served its purpose. No plan for publishing of this document.=20 ROLL charter will be updated in a near future. Thanks. JP. On Sep 18, 2010, at 12:05 AM, Alexandru Petrescu wrote: > JP, this is an old thread. >=20 > Le 21/05/2010 12:25, JP Vasseur a =E9crit : >>=20 >> On May 21, 2010, at 8:50 AM, Geoff Mulligan wrote: >>=20 >>> What ever happened to the protocol survey draft? >>>=20 >>> Samita's message about the proliferation of drafts that atrophy got >>> me wondering about the protocol survey draft. This is a working >>> group document and is part of the milestones and charter of the >>> ROLL WG, but this draft has long since expired. >>>=20 >>> It was supposed to be submitted to the IESG as an informational RFC >>> back in Feb 2009. It was last updated in April of 2009 so I would >>> think that it is complete. Why hasn't it been submitted to the >>> IESG? Given that it was THIS document that was the basis for the >>> decision to create a new routing protocol it is important that this >>> information is not lost. >>>=20 >>> Did the WG ever even Last Call this document? >>=20 >> The decision was made not to publish it as an RFC (see WG minutes), >> also in agreement with our AD. >>=20 >> This will be reflected in the Milestone when we will work on them, >> with the WG. >=20 > The mails from WG members that I read do not seem to indicate silence = about this draft. >=20 > Milestone, AD, RFC, minutes, WG are hard to corelate. >=20 > What happens to this draft-ietf-roll-protocols-survey-07? >=20 > What happens to RPL meeting all of those ideals itself (attached = email)? >=20 > I am asking because I have personally put much energy into discussing > this draft and I find very strange to drop a WG item. I think there = exist no IETF procedure to drop a WG item (it is the first time I see.) >=20 > IMHO, >=20 > Alex >=20 >>=20 >> Thanks. >>=20 >> JP. >>=20 >>>=20 >>> geoff >>>=20 >>>=20 >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>=20 >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-21--634387718 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Alex,

You may want to refer to the minutes IETF-75 = (July 2009):

2) WG Status (Chairs - 10 = mn) [15]

= (Unfortunately, no pdf version = supplied)

= Rene Struik has joined as Technical advisor = /
security advisor - Welcome = Rene

First RFC 5548 = out

Various routing reqd. I-Ds = still pending discusses 
for a couple of documents, = WG chairs iterating with
the ADs to resolve = issues.

Protocol survey - all = issues resolved, tremendous 
= amount of work, thanks to the team working on = this. 
Allowed rechartering, and = served its purpose.
No plan for publishing of = this document. 

ROLL charter = will be updated in a near = future.

Thanks.

JP.

On Sep 18, 2010, at 12:05 AM, Alexandru Petrescu = wrote:

JP, this is an old thread.

Le 21/05/2010 12:25, JP = Vasseur a =E9crit :

On May 21, = 2010, at 8:50 AM, Geoff Mulligan wrote:

What ever happened to the protocol survey = draft?

Samita's message about the = proliferation of drafts that atrophy = got
me wondering about the protocol survey draft. This is a = working
group document and is part of the milestones and charter = of the
ROLL WG, but this draft has long since = expired.

It was supposed to be submitted = to the IESG as an informational = RFC
back in Feb 2009. It was last updated in April of 2009 so = I would
think that it is complete. Why hasn't it been submitted = to the
IESG? Given that it was THIS document that was the basis = for the
decision to create a new routing protocol it is important = that this
information is not = lost.

Did the WG ever even Last Call = this document?

The decision = was made not to publish it as an RFC (see WG = minutes),
also in agreement = with our AD.

This will be = reflected in the Milestone when we will work on = them,
with the = WG.

The mails from WG members that I read do not = seem to indicate silence about this draft.

Milestone, AD, RFC, = minutes, WG are hard to corelate.

What happens to this = draft-ietf-roll-protocols-survey-07?

What happens to RPL meeting = all of those ideals itself (attached email)?

I am asking because = I have personally put much energy into discussing
this draft and I = find very strange to drop a WG item.  I think there exist no IETF = procedure to drop a WG item (it is the first time I = see.)

IMHO,

Alex


Thanks.

JP.


geoff


_______________________________________________ Roll = mailing list
Roll@ietf.org https://www.ietf.org/m= ailman/listinfo/roll

_______________________________________________ Roll = mailing list
Roll@ietf.org https://www.ietf.org/m= ailman/listinfo/roll


<Message = joint.eml>_______________________________________________
Rol= l mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-21--634387718-- From jpv@cisco.com Sat Sep 18 03:24:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55CE23A6908; Sat, 18 Sep 2010 03:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.879 X-Spam-Level: X-Spam-Status: No, score=-109.879 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kH5qG5pW2Ff; Sat, 18 Sep 2010 03:24:34 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id EF61F3A68B8; Sat, 18 Sep 2010 03:24:33 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQFANIwlEyQ/khL/2dsb2JhbAAwogJxommcOYVABIozgn4G X-IronPort-AV: E=Sophos;i="4.56,385,1280707200"; d="scan'208";a="64642882" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 18 Sep 2010 10:24:57 +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 o8IAOvHq022981; Sat, 18 Sep 2010 10:24:57 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 18 Sep 2010 12:24:57 +0200 Received: from [10.144.2.36] ([10.55.87.95]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 18 Sep 2010 12:24:56 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: Date: Sat, 18 Sep 2010 02:22:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com> <4C9030FF.6060302@oracle.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 18 Sep 2010 10:24:56.0816 (UTC) FILETIME=[BDAD0F00:01CB571B] Cc: IPv6 WG , ROLL WG Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 18 Sep 2010 10:24:35 -0000 On Sep 15, 2010, at 8:51 AM, Carsten Bormann wrote: >> Has anybody discussed adding a header with just the 3 bytes you need = *before* the IP header? >=20 > Yes. Ever since you proposed pretty much that at a previous IETF = meeting, I've been thinking that architecturally it makes a lot of sense = to think about ROLL as a sub-IP protocol. Architecturally RPL is not a "sub-IP" protocol, but lies at the = networking layer. Remember that RPL is link layer "agnostic" and no = assumption is made on the link layer. >=20 >> The downside is that you need a new code point (for demux) in the = different layer2s that you want to run this on. >=20 > And that is exactly the non-starter about the general proposal. > It is not acceptable to require a new spec for each of the many link = layers we want to run ROLL on, in particular for those who don't really = care that much about the overhead. >=20 > However, it would be pretty easy to put something in 6lowpan to carry = those 3 bytes. > (Consider it an advanced form of header compression for the 48-byte = IP-in-IP thing, if you don't like the sub-IP thinking.) > Consult http://tools.ietf.org/html/draft-bormann-6lowpan-ext-hdr-00 = for a sample base design. > Such a simple extension may actually be a preferable way to carry ROLL = in 6lowpan. "preferable" in which sense ? Thanks. JP. >=20 > Gruesse, Carsten >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Sat Sep 18 07:16:24 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06F923A68E1 for ; Sat, 18 Sep 2010 07:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[AWL=1.560, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUHhUO1rAmUS for ; Sat, 18 Sep 2010 07:16:22 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 220EB3A688C for ; Sat, 18 Sep 2010 07:16:20 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id ADB1C940135; Sat, 18 Sep 2010 16:16:39 +0200 (CEST) Message-ID: <4C94C9C4.7070805@gmail.com> Date: Sat, 18 Sep 2010 16:16:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: JP Vasseur References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> <028401caf6e5$c5592d60$500b8820$@com> <039a01caf88d$5b4e5d60$11eb1820$@com> <1274424605.3101.128.camel@d430> <115B81B3-7678-4293-BE38-F35E7ACA2D8D@cisco.com> <4C93E611.5070703@gmail.com> <883E4EB2-3793-4A22-B399-020ECC217C21@cisco.com> In-Reply-To: <883E4EB2-3793-4A22-B399-020ECC217C21@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100918-0, 18/09/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] whither draft-ietf-roll-protocols-survey-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 18 Sep 2010 14:16:24 -0000 Hi JP, thanks for identifying the proper minutes. Minutes are logs of a meeting reflect who said what. Often authors of these statements request clarifying the proper reproduction of their statements in the minutes. Le 18/09/2010 00:36, JP Vasseur a écrit : > Hi Alex, > > You may want to refer to the minutes IETF-75 (July 2009): [...] > / //Protocol survey - all issues resolved, tremendous / / //amount of > work, thanks to the team working on this. / / //Allowed rechartering, > and served its purpose./ / //No plan for publishing of this document. > / Who said there is no plan for publishing this document? (I know, it may look as lack of courtesy to ask "who". It is not courteus on my part to do so and I take the blame and the risk. I insist on this because I noticed in more RoLL minutes that the statements are absolutely not attributed to persons; often statements are entirely missing too; this is why it is hard to identify why things happen the way they happen - in our case it is an invitation for unilateral unaccounted for action.) > ROLL charter will be updated in a near future. Thanks for indication. I hope this update process is more transparent to avoid frustration. I personally see this rechartering indication first time now. Alex > > Thanks. > > JP. > > On Sep 18, 2010, at 12:05 AM, Alexandru Petrescu wrote: > >> JP, this is an old thread. >> >> Le 21/05/2010 12:25, JP Vasseur a écrit : >>> >>> On May 21, 2010, at 8:50 AM, Geoff Mulligan wrote: >>> >>>> What ever happened to the protocol survey draft? >>>> >>>> Samita's message about the proliferation of drafts that atrophy >>>> got me wondering about the protocol survey draft. This is a >>>> working group document and is part of the milestones and >>>> charter of the ROLL WG, but this draft has long since expired. >>>> >>>> It was supposed to be submitted to the IESG as an informational >>>> RFC back in Feb 2009. It was last updated in April of 2009 so I >>>> would think that it is complete. Why hasn't it been submitted >>>> to the IESG? Given that it was THIS document that was the basis >>>> for the decision to create a new routing protocol it is >>>> important that this information is not lost. >>>> >>>> Did the WG ever even Last Call this document? >>> >>> The decision was made not to publish it as an RFC (see WG >>> minutes), also in agreement with our AD. >>> >>> This will be reflected in the Milestone when we will work on >>> them, with the WG. >> >> The mails from WG members that I read do not seem to indicate >> silence about this draft. >> >> Milestone, AD, RFC, minutes, WG are hard to corelate. >> >> What happens to this draft-ietf-roll-protocols-survey-07? >> >> What happens to RPL meeting all of those ideals itself (attached >> email)? >> >> I am asking because I have personally put much energy into >> discussing this draft and I find very strange to drop a WG item. I >> think there exist no IETF procedure to drop a WG item (it is the >> first time I see.) >> >> IMHO, >> >> Alex >> >>> >>> Thanks. >>> >>> JP. >>> >>>> >>>> geoff >>>> >>>> >>>> _______________________________________________ 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 >>> >> >> _______________________________________________ >> Roll mailing list Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Sat Sep 18 07:36:15 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BDA93A659B for ; Sat, 18 Sep 2010 07:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.496 X-Spam-Level: X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_40=-0.185, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SoOSaaXyYqe for ; Sat, 18 Sep 2010 07:36:12 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id E69193A657C for ; Sat, 18 Sep 2010 07:36:09 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 401559400F2 for ; Sat, 18 Sep 2010 16:36:29 +0200 (CEST) Message-ID: <4C94CE6A.6060505@gmail.com> Date: Sat, 18 Sep 2010 16:36:26 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100918-0, 18/09/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] My statements in the minutes of the last RoLL meeting in Maastricht X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 18 Sep 2010 14:36:15 -0000 Hi RoLL, Let me clarify what I said during the last meeting in Maastricht. I believe this is not reflected in the official minutes. > Q. when will V11 be posted?] I think that Q. is myself. However, I don't think I asked only when will V11 be posted. I rather asked whether V11 is under discussion or not. > A. Today or tomorrow. > > David> Going forward, we are NOT raising new issues. There may be > editorial corrections. > Question (?): could you please share some documents, publications on > the mechanisms used in RPL on the mailing list? I wonder who asked this? And I think the question was more about RPL motivating documents, and from a commercial perspective, documents we could reuse outside IETF. This is vague recollection on my side. I am wondering who asked this, for my own information. This is Question that I agree with. > Answer: sure. I wonder who said sure? If I knew then I could approach that person and gently remind it would be interesting to actually send these documents. This is again just gentle approaching. If I had the names in the minutes I could do that. > 5) The Trickle Algorithm - draft-levis-roll-trickle-02 (Phil - 5mn) > [160] Quick update on the changes in -02. Currently in LC. JP> ID is > a normative reference in RPL core spec (thus we have a downref). > Discussion on ID status I was part of that discussion. At some point I said that there are at least two ways of solving the issue, one being to set the RPL status to something else than Proposed Standards. That remark was heard because some people laughed. However that remark is not reflected in the minutes. (yes, email discussion followed publicly on the mailing list and we clarify and agreed on the intended status of this draft, but minutes are absent about this discussion). > JP> Will come back to the list to consider status change > (informational to standard track) Yes, this happened. > Discussion on complexity I was part of this discussion. Actually I was not the only one saying the text is complex. Somebody else too said it actually first, then I followed. That makes 2 statements about complexity. > Answer: many implementations in the field, takes very limited > resources. Thomas CLausen: We have an implementation of RPL. Works > fine with trickle just took a few days of coding. Yes, Thomas did say that implementation worked fine, although I don't remember him saying just a few days of coding. It may be so. > Overall discussion. More discussion to take place on the mailing > list. YEs, it so happened. There is no indication in the minutes that the meeting was adjourned, and the initially planned second meeting is not to take place. The only indication of this happening is is a verbal statement by Chair at the mic seeing "see you in Beijing" which is fine, a smart person could conclude the second meeting is cancelled. However, a public announcement on the mic saying "2nd meeting cancelled" and minutes saying so would be probably better. Again, this is simple clarification not any unpolite intention on my side. Alex From pal@cs.stanford.edu Sat Sep 18 09:10:44 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793063A6953 for ; Sat, 18 Sep 2010 09:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Xd3Quwmk7sS for ; Sat, 18 Sep 2010 09:10:36 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 71B4B3A694F for ; Sat, 18 Sep 2010 09:10:28 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.133]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Ox000-000087-9I; Sat, 18 Sep 2010 09:10:48 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4C93E7D7.3000603@gmail.com> Date: Sat, 18 Sep 2010 09:10:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> References: <4C93E7D7.3000603@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 993826b9125cbf1b907f71dc54053338 Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 18 Sep 2010 16:10:44 -0000 On Sep 17, 2010, at 3:12 PM, Alexandru Petrescu wrote: > David, >=20 > Thanks for this Last Call on the RoLL routing metrics draft. >=20 > I reply now just to make sure I replied before the September 30th, = 2010, > the deadline Chair set and that I consider. >=20 > I have proposed last year to have energy link metrics: how much energy > in Joules is required on a particular link to send 1280bytes as an = IPv6 > packet. >=20 > I have proposed this link metric also as an extension to the ripless > draft-mulligan-roll-ripless-01. >=20 > In draft-ietf-roll-routing-metrics energy _is_ used as a metric but as > node energy only, not link energy. >=20 > Link metrics _are_ considered in draft-ietf-roll-routing-metrics but > not as energy. >=20 > Private discussion pointed me unilaterally I may be wrong but I think > publicly I may be right. >=20 > I will send more comments later. Alex, Can you point me to an application requirements doc, or a concrete = application someone is building today, where link energy is needed? = Given the tremendous size and diversity of the industries around LLNs, = as well as the application experience, I think our goal is to = standardize current practice rather than invent new mechanisms. Phil= From alexandru.petrescu@gmail.com Sat Sep 18 10:34:03 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825B03A6822 for ; Sat, 18 Sep 2010 10:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.768 X-Spam-Level: X-Spam-Status: No, score=-0.768 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_20=-0.74, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 570JJ-Eexu0R for ; Sat, 18 Sep 2010 10:34:02 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 4F5843A6820 for ; Sat, 18 Sep 2010 10:34:00 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id CBBD3940161; Sat, 18 Sep 2010 19:34:19 +0200 (CEST) Message-ID: <4C94F819.9050002@gmail.com> Date: Sat, 18 Sep 2010 19:34:17 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Philip Levis References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> In-Reply-To: <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100918-0, 18/09/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 18 Sep 2010 17:34:03 -0000 Le 18/09/2010 18:10, Philip Levis a écrit : > > On Sep 17, 2010, at 3:12 PM, Alexandru Petrescu wrote: > >> David, >> >> Thanks for this Last Call on the RoLL routing metrics draft. >> >> I reply now just to make sure I replied before the September 30th, >> 2010, the deadline Chair set and that I consider. >> >> I have proposed last year to have energy link metrics: how much >> energy in Joules is required on a particular link to send 1280bytes >> as an IPv6 packet. >> >> I have proposed this link metric also as an extension to the >> ripless draft-mulligan-roll-ripless-01. >> >> In draft-ietf-roll-routing-metrics energy _is_ used as a metric but >> as node energy only, not link energy. >> >> Link metrics _are_ considered in draft-ietf-roll-routing-metrics >> but not as energy. >> >> Private discussion pointed me unilaterally I may be wrong but I >> think publicly I may be right. >> >> I will send more comments later. > > Alex, > > Can you point me to an application requirements doc, or a concrete > application someone is building today, where link energy is needed? > Given the tremendous size and diversity of the industries around > LLNs, as well as the application experience, I think our goal is to > standardize current practice rather than invent new mechanisms. Mechanisms required by link energy are not new inventions. The first transatlantic wireless transmissions had a need of so much energy that new power generators were built only for transmitting 3 dots. These days I need to turn off my wifi on PDA if battery is too low. Machine devices have similar energy requirements to Tx. In these devices there is a direct relationship between energy and Tx. This is a difference in perspective. Draft seems to consider only the energy of the computing in these devices (residual energy left on the node) because that's what intelligent LiIon batteries report. There exist devices which don't have these intelligent LiIon batteries but much simpler batteries. When so, there's no need to stay bound on what manufacturer reports as residual energy. But there is still need to know how much energy is needed to transmit data. And that can be measured offline, independent of the battery type. It depends mainly on the coding scheme, range, frequency. If a metric shows the node energy is so large compared to the energy needed to transmit data then we have a hard time using that node metric in a routing protocol. This is because when we analyze the granularity of expressing that node energy we get 3: mains, battery, scavenger (in the draft). Only these 3 can not compare among themselves, which is not good either (is "battery" more than "scavenger"? which battery? which scavenger?). Being on "battery" does not tell a routing protocol whether transmitting data on a node's wifi vs its bluetooth is better. Whereas a routing protocol chooses outgoing interfaces (based on metrics) - that's its goal. The goal of a routing protocol is not optimize the node energy, it is to optimize paths. If one needs a node energy optimization protocol, or a network energy optimization protocol - then yes, node energy metrics are paramount. This is a requirements discussion we never had anyways but which is pertinent. (draft typo says "These include main-powered" - that is mains-powered). I understand the need to stay as simple as possible between Watt, Ah, A and other manufacturer-dependent ways of expressing node energy. But I think the result of a 3-value space, uncomparable values, node-energy only, is questionable. Alex > > Phil From coflynn@newae.com Sat Sep 18 10:38:17 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E02143A683A for ; Sat, 18 Sep 2010 10:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TX9GhjtcNNqr for ; Sat, 18 Sep 2010 10:38:15 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 43C253A6847 for ; Sat, 18 Sep 2010 10:37:45 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1Ox1Lq-0007DA-JK; Sat, 18 Sep 2010 13:37:26 -0400 From: "Colin O'Flynn" To: "'Philip Levis'" , "'Alexandru Petrescu'" References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> In-Reply-To: <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> Date: Sat, 18 Sep 2010 18:37:20 +0100 Message-ID: <006501cb5758$27f3aa90$77daffb0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActXTB8ICfxB5p7yS6K4IQFDswUAgwAAchDQ Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 18 Sep 2010 17:38:17 -0000 Caveat emptor: I have not read the entire metrics-09 at this point, but wanted to comment anyway. I think the idea of "link energy" would be without much merit, of course I'm open to being wrong. My reasoning is as follows: 1) There will not be much difference between the energy it takes to transmit a packet within a RPL network. They will all be using similar link layers, and much of the power of actually transmitting a packet is not related to TX power but getting everything else up (such as CPU running & processing, PLL being active and locked, CSMA being performed). As an example for one specific radio, the ATMega128RFA1, the values of current vs power output (from datasheet @ 3.0V): RX PWR | Supply 3dBm | 14.5mA 1dBm | 10mA -3dBm | 9mA -17dBm | 8mA Converting both to mW (= mJ/s) RX PWR | Supply 2.00 | 43.5 1.26 | 30 0.50 | 27 0.02 | 24 This is just current during active TX. There are some additional things that are TX power independent, but I think for any reasonable length 6LoWPAN packet they are much smaller than the values I have here. 2) Receiving takes around the same amount of power as transmitting for most 802.15.4 nodes. For the previously used example that is around 12mA in fact. Thus the problem is not only TX power, but RX power. How do you encapsulate that in "link energy" accurately? If you do it in simple ways with "fudge factors" you've probably lost enough accuracy to bother doing it at all. 3) Link energy on its own would result in selecting lowest energy paths I assume. Low power nodes which advertise smaller link energies have probably gone to great lengths to get low link energies, since they have low available power. The nodes which are wall-powered won't try to get link energy as low since they are free to transmit at highest energy and not worry too much about power saving tricks. This would be the opposite of what you want, so obviously you combine link energy with available energy. Combining link energy with available energy would be incredibly complex to get perfect. Worse if you do it wrong you end up with the exact opposite of what you want since low-power paths are used at the expense of battery life. At least there is some obvious connection between a simple "available energy" value and "am I likely to be used to route a packet". 4) Transmit energy also depends on link reliability for most wireless networks, since they have an acknowledgment system. Thus an unreliable link may actually take much more than the expected power to transmit every frame, since it's often doing retries. I would expect a few retransmissions to basically nullify a lot of work selecting the "most optimum" routes from an energy perspective. 6) My conclusion from the above points is that the entire question of RX/TX power is too complex to bother doing perfectly in these networks. A simplification that can at least be easily understood and specified would be more useful to everyone in the end than something that is more complex and might not even work. Using such a metric DOES require external documents to specify how the metric is used. But requiring external specification to work out details seems inline with the rest of RPL so shouldn't be a problem. And if in the future I'm completely wrong and someone needs link energy, I don't see a problem of fitting the link energy into a TLV in the "node energy object". Warm Regards, -Colin O'Flynn -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: September 18, 2010 5:11 PM To: Alexandru Petrescu Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt On Sep 17, 2010, at 3:12 PM, Alexandru Petrescu wrote: > David, > > Thanks for this Last Call on the RoLL routing metrics draft. > > I reply now just to make sure I replied before the September 30th, 2010, > the deadline Chair set and that I consider. > > I have proposed last year to have energy link metrics: how much energy > in Joules is required on a particular link to send 1280bytes as an IPv6 > packet. > > I have proposed this link metric also as an extension to the ripless > draft-mulligan-roll-ripless-01. > > In draft-ietf-roll-routing-metrics energy _is_ used as a metric but as > node energy only, not link energy. > > Link metrics _are_ considered in draft-ietf-roll-routing-metrics but > not as energy. > > Private discussion pointed me unilaterally I may be wrong but I think > publicly I may be right. > > I will send more comments later. Alex, Can you point me to an application requirements doc, or a concrete application someone is building today, where link energy is needed? Given the tremendous size and diversity of the industries around LLNs, as well as the application experience, I think our goal is to standardize current practice rather than invent new mechanisms. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Sat Sep 18 10:44:25 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D0403A67B1 for ; Sat, 18 Sep 2010 10:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LceQllNcCqKI for ; Sat, 18 Sep 2010 10:44:21 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id EC1843A680E for ; Sat, 18 Sep 2010 10:43:21 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.133]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Ox1Ry-0001ME-A0; Sat, 18 Sep 2010 10:43:46 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4C94F819.9050002@gmail.com> Date: Sat, 18 Sep 2010 10:43:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <196A8A29-F0B6-403D-858B-BE310DC31DD0@cs.stanford.edu> References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> <4C94F819.9050002@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 1c1d34d4ae2aac1d1f929c6f17b0cb0c Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 18 Sep 2010 17:44:26 -0000 On Sep 18, 2010, at 10:34 AM, Alexandru Petrescu wrote: > Mechanisms required by link energy are not new inventions. The first > transatlantic wireless transmissions had a need of so much energy that > new power generators were built only for transmitting 3 dots. >=20 > These days I need to turn off my wifi on PDA if battery is too low. > Machine devices have similar energy requirements to Tx. In these > devices there is a direct relationship between energy and Tx. >=20 > This is a difference in perspective. Draft seems to consider only the > energy of the computing in these devices (residual energy left on the > node) because that's what intelligent LiIon batteries report. >=20 > There exist devices which don't have these intelligent LiIon batteries > but much simpler batteries. When so, there's no need to stay bound on > what manufacturer reports as residual energy. But there is still need > to know how much energy is needed to transmit data. And that can be > measured offline, independent of the battery type. It depends mainly = on > the coding scheme, range, frequency. >=20 > If a metric shows the node energy is so large compared to the energy > needed to transmit data then we have a hard time using that node > metric in a routing protocol. This is because when we analyze the > granularity of expressing that node energy we get 3: mains, battery, > scavenger (in the draft). Only these 3 can not compare among > themselves, which is not good either (is "battery" more than > "scavenger"? which battery? which scavenger?). >=20 > Being on "battery" does not tell a routing protocol whether = transmitting > data on a node's wifi vs its bluetooth is better. Whereas a routing > protocol chooses outgoing interfaces (based on metrics) - that's its = goal. >=20 > The goal of a routing protocol is not optimize the node energy, it is = to > optimize paths. >=20 > If one needs a node energy optimization protocol, or a network energy > optimization protocol - then yes, node energy metrics are paramount. >=20 > This is a requirements discussion we never had anyways but which is > pertinent. >=20 > (draft typo says "These include main-powered" - that is = mains-powered). >=20 > I understand the need to stay as simple as possible between Watt, Ah, = A > and other manufacturer-dependent ways of expressing node energy. But = I > think the result of a 3-value space, uncomparable values, node-energy > only, is questionable. Alex, I'm sorry, but this is all fluffy hand-waving. I'll repeat:=20 Can you point me to an application requirements doc, or a concrete LLN = application someone is building today, where link energy is needed? Phil= From coflynn@newae.com Sat Sep 18 10:44:54 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3463A6876 for ; Sat, 18 Sep 2010 10:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.430, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pvg-RD-EkiIp for ; Sat, 18 Sep 2010 10:44:50 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 417573A682E for ; Sat, 18 Sep 2010 10:44:20 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1Ox1So-0000TW-1p; Sat, 18 Sep 2010 13:44:38 -0400 From: "Colin O'Flynn" To: "'Alexandru Petrescu'" , "'Philip Levis'" References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> <4C94F819.9050002@gmail.com> In-Reply-To: <4C94F819.9050002@gmail.com> Date: Sat, 18 Sep 2010 18:44:30 +0100 Message-ID: <006801cb5759$29124480$7b36cd80$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActXV8BJERD3oXdqR5eY03clMJHtSQAAHGmg Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 18 Sep 2010 17:44:54 -0000 Ah looks like I missed this message by a minute or two, I just sent out = some comments of my own.=20 >But I >think the result of a 3-value space, uncomparable values, node-energy >only, is questionable. The important consideration for this group: is the default 3-value space suggested enough for the most basic case? I think the answer is 'yes' = but would appreciate other comments. Additional TLVs can be proposed later to expand on node energy. But the = most basic form should surely include only the minimal required amount of information. Regards, -Colin -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: September 18, 2010 6:34 PM To: Philip Levis Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on = draft-ietf-roll-routing-metrics-09.txt Le 18/09/2010 18:10, Philip Levis a =E9crit : > > On Sep 17, 2010, at 3:12 PM, Alexandru Petrescu wrote: > >> David, >> >> Thanks for this Last Call on the RoLL routing metrics draft. >> >> I reply now just to make sure I replied before the September 30th, >> 2010, the deadline Chair set and that I consider. >> >> I have proposed last year to have energy link metrics: how much >> energy in Joules is required on a particular link to send 1280bytes >> as an IPv6 packet. >> >> I have proposed this link metric also as an extension to the >> ripless draft-mulligan-roll-ripless-01. >> >> In draft-ietf-roll-routing-metrics energy _is_ used as a metric but >> as node energy only, not link energy. >> >> Link metrics _are_ considered in draft-ietf-roll-routing-metrics >> but not as energy. >> >> Private discussion pointed me unilaterally I may be wrong but I >> think publicly I may be right. >> >> I will send more comments later. > > Alex, > > Can you point me to an application requirements doc, or a concrete > application someone is building today, where link energy is needed? > Given the tremendous size and diversity of the industries around > LLNs, as well as the application experience, I think our goal is to > standardize current practice rather than invent new mechanisms. Mechanisms required by link energy are not new inventions. The first transatlantic wireless transmissions had a need of so much energy that new power generators were built only for transmitting 3 dots. These days I need to turn off my wifi on PDA if battery is too low. Machine devices have similar energy requirements to Tx. In these devices there is a direct relationship between energy and Tx. This is a difference in perspective. Draft seems to consider only the energy of the computing in these devices (residual energy left on the node) because that's what intelligent LiIon batteries report. There exist devices which don't have these intelligent LiIon batteries but much simpler batteries. When so, there's no need to stay bound on what manufacturer reports as residual energy. But there is still need to know how much energy is needed to transmit data. And that can be measured offline, independent of the battery type. It depends mainly on the coding scheme, range, frequency. If a metric shows the node energy is so large compared to the energy needed to transmit data then we have a hard time using that node metric in a routing protocol. This is because when we analyze the granularity of expressing that node energy we get 3: mains, battery, scavenger (in the draft). Only these 3 can not compare among themselves, which is not good either (is "battery" more than "scavenger"? which battery? which scavenger?). Being on "battery" does not tell a routing protocol whether transmitting data on a node's wifi vs its bluetooth is better. Whereas a routing protocol chooses outgoing interfaces (based on metrics) - that's its = goal. The goal of a routing protocol is not optimize the node energy, it is to optimize paths. If one needs a node energy optimization protocol, or a network energy optimization protocol - then yes, node energy metrics are paramount. This is a requirements discussion we never had anyways but which is pertinent. (draft typo says "These include main-powered" - that is mains-powered). I understand the need to stay as simple as possible between Watt, Ah, A and other manufacturer-dependent ways of expressing node energy. But I think the result of a 3-value space, uncomparable values, node-energy only, is questionable. Alex > > Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Sat Sep 18 11:15:47 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86D483A6832 for ; Sat, 18 Sep 2010 11:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.694 X-Spam-Level: X-Spam-Status: No, score=-1.694 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNRilIo2-VKX for ; Sat, 18 Sep 2010 11:15:46 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 0BB723A685D for ; Sat, 18 Sep 2010 11:15:19 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 5BC1C94015D; Sat, 18 Sep 2010 20:15:38 +0200 (CEST) Message-ID: <4C9501C7.2060400@gmail.com> Date: Sat, 18 Sep 2010 20:15:35 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Colin O'Flynn References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> <006501cb5758$27f3aa90$77daffb0$@com> In-Reply-To: <006501cb5758$27f3aa90$77daffb0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100918-0, 18/09/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 18 Sep 2010 18:15:47 -0000 Le 18/09/2010 19:37, Colin O'Flynn a écrit : > Caveat emptor: I have not read the entire metrics-09 at this point, but > wanted to comment anyway. > > I think the idea of "link energy" would be without much merit, of course I'm > open to being wrong. My reasoning is as follows: > > 1) There will not be much difference between the energy it takes to transmit > a packet within a RPL network. They will all be using similar link layers, Take a car: all devices are on a single unique battery, yet many different copper, light and ether links in terms of energy needed. (in a car - how would a "battery" value of the metric which assumes each IP addressable device has its own "battery" work with RPL? All devices in the car are on the same unique battery, and sometimes on car engine electricity generator. Add to this the Electric Vehicle and you see.) > and much of the power of actually transmitting a packet is not related to TX > power but getting everything else up (such as CPU running& processing, PLL > being active and locked, CSMA being performed). That is right. Each transmitting device has CPU chipset to compute wireless coding and that takes energy. That energy is in higher orders of magnitude than actually transmitting. However the energy used to actual Tx (and Rx as in GPS devices) can be clearly distinguished. > As an example for one specific radio, the ATMega128RFA1, the values of > current vs power output (from datasheet @ 3.0V): > RX PWR | Supply > 3dBm | 14.5mA > 1dBm | 10mA > -3dBm | 9mA > -17dBm | 8mA > > Converting both to mW (= mJ/s) > RX PWR | Supply > 2.00 | 43.5 > 1.26 | 30 > 0.50 | 27 > 0.02 | 24 > > This is just current during active TX. That sounds exellent startpoint for design a link energy metric! To eliminate the time paramter (mJ/s) to get to the J only we could decide that we need to transmit 1280bytes of data - the IPv6 minimal MTU. > There are some additional things that > are TX power independent, but I think for any reasonable length 6LoWPAN > packet they are much smaller than the values I have here. Are we IPv6 perspective or not. If yes IPv6 stack needs to know how much energy is needed 1280bytes of data, a minimally sized IPv6 packet. The stack reasons in terms of packets of that or larger size. > 2) Receiving takes around the same amount of power as transmitting for most > 802.15.4 nodes. For the previously used example that is around 12mA in fact. > Thus the problem is not only TX power, but RX power. With GPS devices it is even truer, because they only receive. > How do you encapsulate > that in "link energy" accurately? Well I proposed a metric bit encoding for it - should I send again? > If you do it in simple ways with "fudge > factors" you've probably lost enough accuracy to bother doing it at all. I don't propose fudge factors. > 3) Link energy on its own would result in selecting lowest energy paths I > assume. Low power nodes which advertise smaller link energies have probably > gone to great lengths to get low link energies, since they have low > available power. The nodes which are wall-powered won't try to get link > energy as low since they are free to transmit at highest energy and not > worry too much about power saving tricks. This would be the opposite of what > you want, so obviously you combine link energy with available energy. I would not combine. > Combining link energy with available energy would be incredibly complex to > get perfect. Worse if you do it wrong you end up with the exact opposite of > what you want since low-power paths are used at the expense of battery life. What is battery life when birth and death is turning an engine on/off? Or when plugging the device on a docking. Or when plugging a vehicle on an outlet. > At least there is some obvious connection between a simple "available > energy" value and "am I likely to be used to route a packet". Node energy helps it that way, yes. > 4) Transmit energy also depends on link reliability for most wireless > networks, since they have an acknowledgment system. Yes, retransmissions at link layer are a link layer problem, dealt with by power management of the link layer. IP stack cares about TCP retransmissions or above. > Thus an unreliable link > may actually take much more than the expected power to transmit every frame, > since it's often doing retries. I would expect a few retransmissions to > basically nullify a lot of work selecting the "most optimum" routes from an > energy perspective. Hmmm... retransmissions may happen too for a node energy metric and that may nullify its effect too. > 6) My conclusion from the above points is that the entire question of RX/TX > power is too complex to bother doing perfectly in these networks. A > simplification that can at least be easily understood and specified would be > more useful to everyone in the end than something that is more complex and > might not even work. If we wish we could discuss separately the actual use of the existing node energy metric and I think it's not that simple either. > Using such a metric DOES require external documents to specify how the > metric is used. But requiring external specification to work out details > seems inline with the rest of RPL so shouldn't be a problem. > > And if in the future I'm completely wrong and someone needs link energy, I > don't see a problem of fitting the link energy into a TLV in the "node > energy object". I am happy to see openness to include link energy metric and I take note for future discussion. But link energy is link energy not node energy. We saw it in the above mAmpere discussion where you eliminated the computing power to which I agreed; yet it doesn't make sense conceptually to put link energy into a node energy container. Link energy values are distinct from node energy values. Alex > > Warm Regards, > > -Colin O'Flynn > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Philip Levis > Sent: September 18, 2010 5:11 PM > To: Alexandru Petrescu > Cc: roll@ietf.org > Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt > > > On Sep 17, 2010, at 3:12 PM, Alexandru Petrescu wrote: > >> David, >> >> Thanks for this Last Call on the RoLL routing metrics draft. >> >> I reply now just to make sure I replied before the September 30th, 2010, >> the deadline Chair set and that I consider. >> >> I have proposed last year to have energy link metrics: how much energy >> in Joules is required on a particular link to send 1280bytes as an IPv6 >> packet. >> >> I have proposed this link metric also as an extension to the ripless >> draft-mulligan-roll-ripless-01. >> >> In draft-ietf-roll-routing-metrics energy _is_ used as a metric but as >> node energy only, not link energy. >> >> Link metrics _are_ considered in draft-ietf-roll-routing-metrics but >> not as energy. >> >> Private discussion pointed me unilaterally I may be wrong but I think >> publicly I may be right. >> >> I will send more comments later. > > Alex, > > Can you point me to an application requirements doc, or a concrete > application someone is building today, where link energy is needed? Given > the tremendous size and diversity of the industries around LLNs, as well as > the application experience, I think our goal is to standardize current > practice rather than invent new mechanisms. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > From alexandru.petrescu@gmail.com Sat Sep 18 11:17:30 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E321F3A687B for ; Sat, 18 Sep 2010 11:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTnf0UFRwkRu for ; Sat, 18 Sep 2010 11:17:22 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id C66543A6825 for ; Sat, 18 Sep 2010 11:17:17 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 6AC6294013A; Sat, 18 Sep 2010 20:17:36 +0200 (CEST) Message-ID: <4C95023D.9070600@gmail.com> Date: Sat, 18 Sep 2010 20:17:33 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Colin O'Flynn References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> <4C94F819.9050002@gmail.com> <006801cb5759$29124480$7b36cd80$@com> In-Reply-To: <006801cb5759$29124480$7b36cd80$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100918-0, 18/09/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 18 Sep 2010 18:17:30 -0000 Le 18/09/2010 19:44, Colin O'Flynn a écrit : > Ah looks like I missed this message by a minute or two, I just sent out some > comments of my own. > >> But I >> think the result of a 3-value space, uncomparable values, node-energy >> only, is questionable. > > The important consideration for this group: is the default 3-value space > suggested enough for the most basic case? I think the answer is 'yes' but > would appreciate other comments. My comment is no. Node energy metric assumes each node is on its own power, it doesn't treat more complex powering systems as in a car which does need LLN-kind of networks. Alex > > Additional TLVs can be proposed later to expand on node energy. But the most > basic form should surely include only the minimal required amount of > information. > > Regards, > > -Colin > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: September 18, 2010 6:34 PM > To: Philip Levis > Cc: roll@ietf.org > Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt > > Le 18/09/2010 18:10, Philip Levis a écrit : >> >> On Sep 17, 2010, at 3:12 PM, Alexandru Petrescu wrote: >> >>> David, >>> >>> Thanks for this Last Call on the RoLL routing metrics draft. >>> >>> I reply now just to make sure I replied before the September 30th, >>> 2010, the deadline Chair set and that I consider. >>> >>> I have proposed last year to have energy link metrics: how much >>> energy in Joules is required on a particular link to send 1280bytes >>> as an IPv6 packet. >>> >>> I have proposed this link metric also as an extension to the >>> ripless draft-mulligan-roll-ripless-01. >>> >>> In draft-ietf-roll-routing-metrics energy _is_ used as a metric but >>> as node energy only, not link energy. >>> >>> Link metrics _are_ considered in draft-ietf-roll-routing-metrics >>> but not as energy. >>> >>> Private discussion pointed me unilaterally I may be wrong but I >>> think publicly I may be right. >>> >>> I will send more comments later. >> >> Alex, >> >> Can you point me to an application requirements doc, or a concrete >> application someone is building today, where link energy is needed? >> Given the tremendous size and diversity of the industries around >> LLNs, as well as the application experience, I think our goal is to >> standardize current practice rather than invent new mechanisms. > > Mechanisms required by link energy are not new inventions. The first > transatlantic wireless transmissions had a need of so much energy that > new power generators were built only for transmitting 3 dots. > > These days I need to turn off my wifi on PDA if battery is too low. > Machine devices have similar energy requirements to Tx. In these > devices there is a direct relationship between energy and Tx. > > This is a difference in perspective. Draft seems to consider only the > energy of the computing in these devices (residual energy left on the > node) because that's what intelligent LiIon batteries report. > > There exist devices which don't have these intelligent LiIon batteries > but much simpler batteries. When so, there's no need to stay bound on > what manufacturer reports as residual energy. But there is still need > to know how much energy is needed to transmit data. And that can be > measured offline, independent of the battery type. It depends mainly on > the coding scheme, range, frequency. > > If a metric shows the node energy is so large compared to the energy > needed to transmit data then we have a hard time using that node > metric in a routing protocol. This is because when we analyze the > granularity of expressing that node energy we get 3: mains, battery, > scavenger (in the draft). Only these 3 can not compare among > themselves, which is not good either (is "battery" more than > "scavenger"? which battery? which scavenger?). > > Being on "battery" does not tell a routing protocol whether transmitting > data on a node's wifi vs its bluetooth is better. Whereas a routing > protocol chooses outgoing interfaces (based on metrics) - that's its goal. > > The goal of a routing protocol is not optimize the node energy, it is to > optimize paths. > > If one needs a node energy optimization protocol, or a network energy > optimization protocol - then yes, node energy metrics are paramount. > > This is a requirements discussion we never had anyways but which is > pertinent. > > (draft typo says "These include main-powered" - that is mains-powered). > > I understand the need to stay as simple as possible between Watt, Ah, A > and other manufacturer-dependent ways of expressing node energy. But I > think the result of a 3-value space, uncomparable values, node-energy > only, is questionable. > > Alex > >> >> Phil > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > From alexandru.petrescu@gmail.com Sat Sep 18 11:18:13 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AC5D3A6825 for ; Sat, 18 Sep 2010 11:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.704 X-Spam-Level: X-Spam-Status: No, score=-1.704 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPAvz6B6fzF5 for ; Sat, 18 Sep 2010 11:18:12 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3E73A6856 for ; Sat, 18 Sep 2010 11:18:08 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id DCC399400FD; Sat, 18 Sep 2010 20:18:27 +0200 (CEST) Message-ID: <4C950271.9060806@gmail.com> Date: Sat, 18 Sep 2010 20:18:25 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Philip Levis References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> <4C94F819.9050002@gmail.com> <196A8A29-F0B6-403D-858B-BE310DC31DD0@cs.stanford.edu> In-Reply-To: <196A8A29-F0B6-403D-858B-BE310DC31DD0@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100918-0, 18/09/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 18 Sep 2010 18:18:13 -0000 Le 18/09/2010 19:43, Philip Levis a écrit : > > On Sep 18, 2010, at 10:34 AM, Alexandru Petrescu wrote: > >> Mechanisms required by link energy are not new inventions. The >> first transatlantic wireless transmissions had a need of so much >> energy that new power generators were built only for transmitting 3 >> dots. >> >> These days I need to turn off my wifi on PDA if battery is too >> low. Machine devices have similar energy requirements to Tx. In >> these devices there is a direct relationship between energy and >> Tx. >> >> This is a difference in perspective. Draft seems to consider only >> the energy of the computing in these devices (residual energy left >> on the node) because that's what intelligent LiIon batteries >> report. >> >> There exist devices which don't have these intelligent LiIon >> batteries but much simpler batteries. When so, there's no need to >> stay bound on what manufacturer reports as residual energy. But >> there is still need to know how much energy is needed to transmit >> data. And that can be measured offline, independent of the battery >> type. It depends mainly on the coding scheme, range, frequency. >> >> If a metric shows the node energy is so large compared to the >> energy needed to transmit data then we have a hard time using that >> node metric in a routing protocol. This is because when we analyze >> the granularity of expressing that node energy we get 3: mains, >> battery, scavenger (in the draft). Only these 3 can not compare >> among themselves, which is not good either (is "battery" more than >> "scavenger"? which battery? which scavenger?). >> >> Being on "battery" does not tell a routing protocol whether >> transmitting data on a node's wifi vs its bluetooth is better. >> Whereas a routing protocol chooses outgoing interfaces (based on >> metrics) - that's its goal. >> >> The goal of a routing protocol is not optimize the node energy, it >> is to optimize paths. >> >> If one needs a node energy optimization protocol, or a network >> energy optimization protocol - then yes, node energy metrics are >> paramount. >> >> This is a requirements discussion we never had anyways but which >> is pertinent. >> >> (draft typo says "These include main-powered" - that is >> mains-powered). >> >> I understand the need to stay as simple as possible between Watt, >> Ah, A and other manufacturer-dependent ways of expressing node >> energy. But I think the result of a 3-value space, uncomparable >> values, node-energy only, is questionable. > > Alex, I'm sorry, but this is all fluffy hand-waving. I'll repeat: > > Can you point me to an application requirements doc, or a concrete > LLN application someone is building today, where link energy is > needed? Why do you ask? You think I can't? Alex > > Phil From alexandru.petrescu@gmail.com Sat Sep 18 11:20:54 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFC6A3A685D for ; Sat, 18 Sep 2010 11:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmM-ktpWkowD for ; Sat, 18 Sep 2010 11:20:53 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 82C0E3A6858 for ; Sat, 18 Sep 2010 11:20:51 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 562B0940078; Sat, 18 Sep 2010 20:21:11 +0200 (CEST) Message-ID: <4C950314.9080501@gmail.com> Date: Sat, 18 Sep 2010 20:21:08 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Philip Levis References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> <4C94F819.9050002@gmail.com> <196A8A29-F0B6-403D-858B-BE310DC31DD0@cs.stanford.edu> In-Reply-To: <196A8A29-F0B6-403D-858B-BE310DC31DD0@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100918-0, 18/09/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] fluffy-handwaving (was: WG Last Call on draft-ietf-roll-routing-metrics-09.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 18 Sep 2010 18:20:54 -0000 I consider I don't do fluffy handwaving. I can send significant comments on the draft if you're open to them. I just don't want to waste my time only to receive "no" comments. Alex Le 18/09/2010 19:43, Philip Levis a écrit : > > On Sep 18, 2010, at 10:34 AM, Alexandru Petrescu wrote: > >> Mechanisms required by link energy are not new inventions. The first >> transatlantic wireless transmissions had a need of so much energy that >> new power generators were built only for transmitting 3 dots. >> >> These days I need to turn off my wifi on PDA if battery is too low. >> Machine devices have similar energy requirements to Tx. In these >> devices there is a direct relationship between energy and Tx. >> >> This is a difference in perspective. Draft seems to consider only the >> energy of the computing in these devices (residual energy left on the >> node) because that's what intelligent LiIon batteries report. >> >> There exist devices which don't have these intelligent LiIon batteries >> but much simpler batteries. When so, there's no need to stay bound on >> what manufacturer reports as residual energy. But there is still need >> to know how much energy is needed to transmit data. And that can be >> measured offline, independent of the battery type. It depends mainly on >> the coding scheme, range, frequency. >> >> If a metric shows the node energy is so large compared to the energy >> needed to transmit data then we have a hard time using that node >> metric in a routing protocol. This is because when we analyze the >> granularity of expressing that node energy we get 3: mains, battery, >> scavenger (in the draft). Only these 3 can not compare among >> themselves, which is not good either (is "battery" more than >> "scavenger"? which battery? which scavenger?). >> >> Being on "battery" does not tell a routing protocol whether transmitting >> data on a node's wifi vs its bluetooth is better. Whereas a routing >> protocol chooses outgoing interfaces (based on metrics) - that's its goal. >> >> The goal of a routing protocol is not optimize the node energy, it is to >> optimize paths. >> >> If one needs a node energy optimization protocol, or a network energy >> optimization protocol - then yes, node energy metrics are paramount. >> >> This is a requirements discussion we never had anyways but which is >> pertinent. >> >> (draft typo says "These include main-powered" - that is mains-powered). >> >> I understand the need to stay as simple as possible between Watt, Ah, A >> and other manufacturer-dependent ways of expressing node energy. But I >> think the result of a 3-value space, uncomparable values, node-energy >> only, is questionable. > > Alex, I'm sorry, but this is all fluffy hand-waving. I'll repeat: > > Can you point me to an application requirements doc, or a concrete LLN application someone is building today, where link energy is needed? > > Phil From coflynn@newae.com Sat Sep 18 14:49:38 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A61DA3A68FD for ; Sat, 18 Sep 2010 14:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJdw+KXcFLy1 for ; Sat, 18 Sep 2010 14:49:37 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id CBAEB3A68D2 for ; Sat, 18 Sep 2010 14:49:31 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1Ox5IA-0003ye-HJ; Sat, 18 Sep 2010 17:49:55 -0400 From: "Colin O'Flynn" To: "'Alexandru Petrescu'" References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> <006501cb5758$27f3aa90$77daffb0$@com> <4C9501C7.2060400@gmail.com> In-Reply-To: <4C9501C7.2060400@gmail.com> Date: Sat, 18 Sep 2010 22:49:46 +0100 Message-ID: <006b01cb577b$6c2f1550$448d3ff0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActXXYLntd/MgiroSfKuwFBpEYXsBgAGNvvw Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 18 Sep 2010 21:49:38 -0000 Hi Alex, I think we have some different assumptions about the usage model. It = would be useful to clarify some of that first. I'm not claiming my assumptions = are correct or consistent with the ROLL/RPL basis, these are simply my view = of how I imagined it would all fit together: 1) A single RPL network itself does not cross multiple PHY layers. = Crossing PHY layers would complicate the decision on "best routes" partially for = the reasons you mention. My comments before showing TX power vs current was showing that for the same PHY layer you can have a huge swing of TX = power yet minimal impact on energy required to transmit a packet (100x change = in RF energy =3D less than 2x change in total energy). =20 2) Routing metrics are not universal, but will somewhat be application-dependant. Thus you can change the metrics for different = nodes as required, and metrics might not make sense between different RPL = networks (this fits in with assumption #1).=20 Thus my view was the metrics should be simple, as you hide any required customization. If you want to select the outgoing interface you have = some artificial change in the metric, where the administrator has basically forced the device to prefer interface 1 over interface 2.=20 In your given example of an automotive system where they all work on a common power source, the nodes have a specific routing metric where a certain "fudge factor" has been worked into the different nodes. Thus = all other things being equal, the advertised metric of a node which takes a = lot of energy to transmit is made such that it is less preferred over = another node. I think you are assuming that (1) you can have different PHYs within the = RPL network, and (2) the routing metrics are more universal, so you can = compare two different RPL networks. Is this correct? I've included some clarifications below as well (see ), but = I think the above two points are most important to understanding why we = may see such a wide difference of opinion. Regards, -Colin -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: September 18, 2010 7:16 PM To: Colin O'Flynn Cc: 'Philip Levis'; roll@ietf.org Subject: Re: [Roll] WG Last Call on = draft-ietf-roll-routing-metrics-09.txt Le 18/09/2010 19:37, Colin O'Flynn a =E9crit : > Caveat emptor: I have not read the entire metrics-09 at this point, = but > wanted to comment anyway. > > I think the idea of "link energy" would be without much merit, of = course I'm > open to being wrong. My reasoning is as follows: > > 1) There will not be much difference between the energy it takes to transmit > a packet within a RPL network. They will all be using similar link = layers, Take a car: all devices are on a single unique battery, yet many=20 different copper, light and ether links in terms of energy needed. (in a car - how would a "battery" value of the metric which assumes each IP addressable device has its own "battery" work with RPL? All devices in the car are on the same unique battery, and sometimes on car engine electricity generator. Add to this the Electric Vehicle and you see.) > and much of the power of actually transmitting a packet is not related = to TX > power but getting everything else up (such as CPU running& = processing, PLL > being active and locked, CSMA being performed). That is right. Each transmitting device has CPU chipset to compute=20 wireless coding and that takes energy. That energy is in higher orders=20 of magnitude than actually transmitting. However the energy used to actual Tx (and Rx as in GPS devices) can be=20 clearly distinguished. I meant that you would then require information on both TX & RX = power if you wanted to be accurate. So you'd have to add more metrics there, = and add two values for every hop. > As an example for one specific radio, the ATMega128RFA1, the values of > current vs power output (from datasheet @ 3.0V): > RX PWR | Supply > 3dBm | 14.5mA > 1dBm | 10mA > -3dBm | 9mA > -17dBm | 8mA > > Converting both to mW (=3D mJ/s) > RX PWR | Supply > 2.00 | 43.5 > 1.26 | 30 > 0.50 | 27 > 0.02 | 24 > > This is just current during active TX. That sounds exellent startpoint for design a link energy metric! To=20 eliminate the time paramter (mJ/s) to get to the J only we could decide = that we need to transmit 1280bytes of data - the IPv6 minimal MTU. > There are some additional things that > are TX power independent, but I think for any reasonable length = 6LoWPAN > packet they are much smaller than the values I have here. Are we IPv6 perspective or not. If yes IPv6 stack needs to know how=20 much energy is needed 1280bytes of data, a minimally sized IPv6 packet.=20 The stack reasons in terms of packets of that or larger size. My example is 802.15.4/6LoWPAN specific, as that was just 802.15.4 packets. I just meant for any reasonable size 802.15.4 packet seen on a 6lowpan/IPv6 network you don't need to worry about CSMA time for = example, as it's fairly minimal by comparison. > 2) Receiving takes around the same amount of power as transmitting for most > 802.15.4 nodes. For the previously used example that is around 12mA in fact. > Thus the problem is not only TX power, but RX power. With GPS devices it is even truer, because they only receive. > How do you encapsulate > that in "link energy" accurately? Well I proposed a metric bit encoding for it - should I send again? I looked back to I think may 2009 when I saw a discussion about it, = if it was before that I probably missed it. > If you do it in simple ways with "fudge > factors" you've probably lost enough accuracy to bother doing it at = all. I don't propose fudge factors. > 3) Link energy on its own would result in selecting lowest energy = paths I > assume. Low power nodes which advertise smaller link energies have probably > gone to great lengths to get low link energies, since they have low > available power. The nodes which are wall-powered won't try to get = link > energy as low since they are free to transmit at highest energy and = not > worry too much about power saving tricks. This would be the opposite = of what > you want, so obviously you combine link energy with available energy. I would not combine. Combine was a poor choice of words on my part. I meant it uses = both the link energy & node energy, and "combines" them to create a routing solution. So if you had separate link energy & node energy, figuring out = how to use both of them would be a complex problem. > Combining link energy with available energy would be incredibly = complex to > get perfect. Worse if you do it wrong you end up with the exact = opposite of > what you want since low-power paths are used at the expense of battery life. What is battery life when birth and death is turning an engine on/off?=20 Or when plugging the device on a docking. Or when plugging a vehicle on = an outlet. > At least there is some obvious connection between a simple "available > energy" value and "am I likely to be used to route a packet". Node energy helps it that way, yes. > 4) Transmit energy also depends on link reliability for most wireless > networks, since they have an acknowledgment system. Yes, retransmissions at link layer are a link layer problem, dealt with=20 by power management of the link layer. IP stack cares about TCP=20 retransmissions or above. > Thus an unreliable link > may actually take much more than the expected power to transmit every frame, > since it's often doing retries. I would expect a few retransmissions = to > basically nullify a lot of work selecting the "most optimum" routes = from an > energy perspective. Hmmm... retransmissions may happen too for a node energy metric and that = may nullify its effect too. I don't mean retransmission of the metric, I just meant = retransmissions in general. It's a question of all this overhead exchanging metrics to maintain a perfect route, when in the end you spent more time maintain = your route than routing data! So I think for link energy to be 'accurate', = you'd also need to keep the ETX object updated for example. > 6) My conclusion from the above points is that the entire question of RX/TX > power is too complex to bother doing perfectly in these networks. A > simplification that can at least be easily understood and specified = would be > more useful to everyone in the end than something that is more complex = and > might not even work. If we wish we could discuss separately the actual use of the existing=20 node energy metric and I think it's not that simple either. > Using such a metric DOES require external documents to specify how the > metric is used. But requiring external specification to work out = details > seems inline with the rest of RPL so shouldn't be a problem. > > And if in the future I'm completely wrong and someone needs link = energy, I > don't see a problem of fitting the link energy into a TLV in the "node > energy object". I am happy to see openness to include link energy metric and I take note = for future discussion. But link energy is link energy not node energy. We saw it in the above=20 mAmpere discussion where you eliminated the computing power to which I=20 agreed; yet it doesn't make sense conceptually to put link energy into a = node energy container. Link energy values are distinct from node energy = values. Alex > > Warm Regards, > > -Colin O'Flynn > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of > Philip Levis > Sent: September 18, 2010 5:11 PM > To: Alexandru Petrescu > Cc: roll@ietf.org > Subject: Re: [Roll] WG Last Call on = draft-ietf-roll-routing-metrics-09.txt > > > On Sep 17, 2010, at 3:12 PM, Alexandru Petrescu wrote: > >> David, >> >> Thanks for this Last Call on the RoLL routing metrics draft. >> >> I reply now just to make sure I replied before the September 30th, = 2010, >> the deadline Chair set and that I consider. >> >> I have proposed last year to have energy link metrics: how much = energy >> in Joules is required on a particular link to send 1280bytes as an = IPv6 >> packet. >> >> I have proposed this link metric also as an extension to the ripless >> draft-mulligan-roll-ripless-01. >> >> In draft-ietf-roll-routing-metrics energy _is_ used as a metric but = as >> node energy only, not link energy. >> >> Link metrics _are_ considered in draft-ietf-roll-routing-metrics but >> not as energy. >> >> Private discussion pointed me unilaterally I may be wrong but I think >> publicly I may be right. >> >> I will send more comments later. > > Alex, > > Can you point me to an application requirements doc, or a concrete > application someone is building today, where link energy is needed? = Given > the tremendous size and diversity of the industries around LLNs, as = well as > the application experience, I think our goal is to standardize current > practice rather than invent new mechanisms. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > From cabo@tzi.org Sat Sep 18 18:09:26 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47B3B3A6900; Sat, 18 Sep 2010 18:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.069 X-Spam-Level: X-Spam-Status: No, score=-106.069 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QswxuYVJLbq9; Sat, 18 Sep 2010 18:09:25 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by core3.amsl.com (Postfix) with ESMTP id 979843A67B3; Sat, 18 Sep 2010 18:09:24 -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 o8IDhEOR007951; Sat, 18 Sep 2010 15:43:14 +0200 (CEST) Received: from [192.168.217.101] (p5489A3F7.dip.t-dialin.net [84.137.163.247]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DFEF2B53; Sat, 18 Sep 2010 15:43:12 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Sat, 18 Sep 2010 15:43:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3A0EB9F4-1A88-40ED-8DAF-678300C4B227@tzi.org> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com> <4C9030FF.6060302@oracle.com> To: JP Vasseur X-Mailer: Apple Mail (2.1081) Cc: IPv6 WG , ROLL WG Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 19 Sep 2010 01:09:26 -0000 On Sep 18, 2010, at 02:22, JP Vasseur wrote: >=20 > On Sep 15, 2010, at 8:51 AM, Carsten Bormann wrote: >=20 >>> Has anybody discussed adding a header with just the 3 bytes you need = *before* the IP header? >>=20 >> Yes. Ever since you proposed pretty much that at a previous IETF = meeting, I've been thinking that architecturally it makes a lot of sense = to think about ROLL as a sub-IP protocol. >=20 > Architecturally RPL is not a "sub-IP" protocol,=20 You are right, I was too terse: it contains one. Architecturally, the instance-id acts a lot like a VLAN tag, and the = rank is something that happens "alongside" IP forwarding -- whether = that's below, above, or sideways depends on your vantage point. But we probably don't need to discuss the fine architectural points = here. (After thirty years, I'm a bit tired of trying to compress complex = reality into "layers".) My point is not about labelling RPL as anything, but about making use of = knowledge we already have. Erik's comments have been pretty eye-opening here for me. >>> The downside is that you need a new code point (for demux) in the = different layer2s that you want to run this on. >>=20 >> And that is exactly the non-starter about the general proposal. >> It is not acceptable to require a new spec for each of the many link = layers we want to run ROLL on, in particular for those who don't really = care that much about the overhead. >>=20 >> However, it would be pretty easy to put something in 6lowpan to carry = those 3 bytes. >> (Consider it an advanced form of header compression for the 48-byte = IP-in-IP thing, if you don't like the sub-IP thinking.) >> Consult http://tools.ietf.org/html/draft-bormann-6lowpan-ext-hdr-00 = for a sample base design. >> Such a simple extension may actually be a preferable way to carry = ROLL in 6lowpan. >=20 > "preferable" in which sense ? In the sense of good performance and minimal impact. Again, just think of it as a 6lowpan-optimized form of = header-compressing the 56-byte*) IP-in-IP/extension-header wrapper that = other link layers will happily carry. Gruesse, Carsten *) (Note that 6lowpan-HC as is will probably already compress that = wrapper to approximately 14 bytes -- I haven't done a fully worked = example yet, though, as the RPL option processing is not yet fully = defined, and there is a lot of complexity to get down to those ~ 14 = bytes.) From alexandru.petrescu@gmail.com Sun Sep 19 12:28:59 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C20833A6880 for ; Sun, 19 Sep 2010 12:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.507 X-Spam-Level: X-Spam-Status: No, score=-0.507 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_40=-0.185, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0BRfL4eYXIC for ; Sun, 19 Sep 2010 12:28:58 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 803553A687B for ; Sun, 19 Sep 2010 12:28:55 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 1B1E99400E5; Sun, 19 Sep 2010 21:29:13 +0200 (CEST) Message-ID: <4C966485.3070206@gmail.com> Date: Sun, 19 Sep 2010 21:29:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Colin O'Flynn References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> <006501cb5758$27f3aa90$77daffb0$@com> <4C9501C7.2060400@gmail.com> <006b01cb577b$6c2f1550$448d3ff0$@com> In-Reply-To: <006b01cb577b$6c2f1550$448d3ff0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100919-0, 19/09/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 19 Sep 2010 19:28:59 -0000 [my summary: it is worth clarifying (1) whether RPL runs in a single PHY or multiple PHY network, and (2) whether metrics for RPL should be understood in RPL network only or more universal like across the Internet. There are also points about whether Rx link energy is as important as Tx link energy and its usability overall.] Hi Colin, It does make sense to clarify the usage model first, especially the assumptions of whether or not RPL runs exclusively on networks made of single PHY, or multiple PHYs. I consider IP kind of work (do we say IPv6? 'router'?) is needed only if we consider multiple kinds of PHYs in the same network. Otherwise bridges, range extenders and other L2 tools are better appropriate than IP routers. During RPL comments we commented whether RPL draft text should say _only_ 802.15.4 or would it include PLC too. I think RPL draft text saying _only_ 802.15.4 would make subsequent metrics and security text much easier. However, it was insisted PLC should be there in the draft. So I am in that perspective now. But does that mean that RPL runs only on a network consisting of PLC devices, and on another network of 15.4 devices (separated by an Edge Router)? Or does it mean RPL runs in a network mixing 15.4 devices with PLC devices each being an RPL router? This was never clear. Le 18/09/2010 23:49, Colin O'Flynn a écrit : > Hi Alex, > > I think we have some different assumptions about the usage model. It > would be useful to clarify some of that first. I'm not claiming my > assumptions are correct or consistent with the ROLL/RPL basis, these > are simply my view of how I imagined it would all fit together: > > 1) A single RPL network itself does not cross multiple PHY layers. > Crossing PHY layers would complicate the decision on "best routes" > partially for the reasons you mention. My comments before showing TX > power vs current was showing that for the same PHY layer you can > have a huge swing of TX power yet minimal impact on energy required > to transmit a packet (100x change in RF energy = less than 2x change > in total energy). (The energy used for transmission is the one measured by setting a highres ampermeter serially with the transmitting device, its battery and a shunt, make it send an IPv6 packet (type ping). That shows the energy used for transmission. This is just a rough view, but basically that is. There are related measurement tools like antena placed near emitter (the ones used to measure the DAS of mobile phones W/Kg).) > 2) Routing metrics are not universal, but will somewhat be > application-dependant. Thus you can change the metrics for different > nodes as required, and metrics might not make sense between > different RPL networks (this fits in with assumption #1). > > Thus my view was the metrics should be simple, as you hide any > required customization. If you want to select the outgoing interface > you have some artificial change in the metric, where the > administrator has basically forced the device to prefer interface 1 > over interface 2. Yes, the metric should be simple. The simplest relates much to what exists in terms of how IP routers select their output interface without artificial human intervention. > In your given example of an automotive system where they all work on > a common power source, the nodes have a specific routing metric > where a certain "fudge factor" has been worked into the different > nodes. Thus all other things being equal, the advertised metric of a > node which takes a lot of energy to transmit is made such that it is > less preferred over another node. > > I think you are assuming that (1) you can have different PHYs within > the RPL network, and (2) the routing metrics are more universal, so > you can compare two different RPL networks. Is this correct? Yes, right, that is my assumption: different PHYs within an RPL network and routing metrics more universal - they'd work within the RPL network and across the Internet (like the simple hopcount metric), and one could also compare different RPL networks. Do we want metrics that work _only_ within an RPL network? Or more universal like across the Internet? Or both? This is also a requirement discussion which is worth clarifying. > I've included some clarifications below as well (see ), > but I think the above two points are most important to understanding > why we may see such a wide difference of opinion. YEs, the above points about RPL running in a single PHY or multiple PHY network, and metric only worth in RPL or across the Internet, are important to clarify. > Regards, > > -Colin > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Sent: September 18, 2010 7:16 > PM To: Colin O'Flynn Cc: 'Philip Levis'; roll@ietf.org Subject: Re: > [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt > > Le 18/09/2010 19:37, Colin O'Flynn a écrit : >> Caveat emptor: I have not read the entire metrics-09 at this >> point, but wanted to comment anyway. >> >> I think the idea of "link energy" would be without much merit, of >> course > I'm >> open to being wrong. My reasoning is as follows: >> >> 1) There will not be much difference between the energy it takes >> to > transmit >> a packet within a RPL network. They will all be using similar link >> layers, > > Take a car: all devices are on a single unique battery, yet many > different copper, light and ether links in terms of energy needed. > > (in a car - how would a "battery" value of the metric which assumes > each IP addressable device has its own "battery" work with RPL? All > devices in the car are on the same unique battery, and sometimes on > car engine electricity generator. Add to this the Electric Vehicle > and you see.) > >> and much of the power of actually transmitting a packet is not >> related to > TX >> power but getting everything else up (such as CPU running& >> processing, > PLL >> being active and locked, CSMA being performed). > > That is right. Each transmitting device has CPU chipset to compute > wireless coding and that takes energy. That energy is in higher > orders of magnitude than actually transmitting. > > However the energy used to actual Tx (and Rx as in GPS devices) can > be clearly distinguished. > > I meant that you would then require information on both TX& RX > power if you wanted to be accurate. So you'd have to add more > metrics there, and add two values for every hop. Hmmm... that sounds right. To be better accurate about link energy metrics one would have to do both Tx metric and Rx metric. This could be done. I was thinking that presenting first the Tx link energy metric it would be easier to understand and then add the Rx metric too, naturally. >> As an example for one specific radio, the ATMega128RFA1, the >> values of current vs power output (from datasheet @ 3.0V): RX PWR >> | Supply 3dBm | 14.5mA 1dBm | 10mA -3dBm | 9mA -17dBm | 8mA >> >> Converting both to mW (= mJ/s) RX PWR | Supply 2.00 | 43.5 1.26 | >> 30 0.50 | 27 0.02 | 24 >> >> This is just current during active TX. > > That sounds exellent startpoint for design a link energy metric! To > eliminate the time paramter (mJ/s) to get to the J only we could > decide that we need to transmit 1280bytes of data - the IPv6 minimal > MTU. > >> There are some additional things that are TX power independent, >> but I think for any reasonable length 6LoWPAN packet they are much >> smaller than the values I have here. > > Are we IPv6 perspective or not. If yes IPv6 stack needs to know how > much energy is needed 1280bytes of data, a minimally sized IPv6 > packet. The stack reasons in terms of packets of that or larger > size. > > My example is 802.15.4/6LoWPAN specific, as that was just > 802.15.4 packets. I just meant for any reasonable size 802.15.4 > packet seen on a 6lowpan/IPv6 network you don't need to worry about > CSMA time for example, as it's fairly minimal by comparison. Well, IPv6 for 802.15.4 RFC says clearly this is minimal IPv6 MTU 1280bytes. I am not sure I understand why should IPv6 stack worry about smaller data-link packets but I have to dig this, e.g. see whether the linux stack does consider smaller than 1280bytes or not. >> 2) Receiving takes around the same amount of power as transmitting >> for > most >> 802.15.4 nodes. For the previously used example that is around >> 12mA in > fact. >> Thus the problem is not only TX power, but RX power. > > With GPS devices it is even truer, because they only receive. > >> How do you encapsulate that in "link energy" accurately? > > Well I proposed a metric bit encoding for it - should I send again? > > I looked back to I think may 2009 when I saw a discussion about > it, if it was before that I probably missed it. Ok, I will resend tomorrow an an example of encoding energy link metric for RA (it's on my office desktop). >> If you do it in simple ways with "fudge factors" you've probably >> lost enough accuracy to bother doing it at all. > > I don't propose fudge factors. > >> 3) Link energy on its own would result in selecting lowest energy >> paths I assume. Low power nodes which advertise smaller link >> energies have > probably >> gone to great lengths to get low link energies, since they have low >> available power. The nodes which are wall-powered won't try to get >> link energy as low since they are free to transmit at highest >> energy and not worry too much about power saving tricks. This >> would be the opposite of > what >> you want, so obviously you combine link energy with available >> energy. > > I would not combine. > > Combine was a poor choice of words on my part. I meant it > uses both the link energy& node energy, and "combines" them to > create a routing solution. So if you had separate link energy& node > energy, figuring out how to use both of them would be a complex > problem. I agree using both node and link energy in a single metric would make it more complex. >> Combining link energy with available energy would be incredibly >> complex to get perfect. Worse if you do it wrong you end up with >> the exact opposite > of >> what you want since low-power paths are used at the expense of >> battery > life. > > What is battery life when birth and death is turning an engine > on/off? Or when plugging the device on a docking. Or when plugging > a vehicle on an outlet. > >> At least there is some obvious connection between a simple >> "available energy" value and "am I likely to be used to route a >> packet". > > Node energy helps it that way, yes. > >> 4) Transmit energy also depends on link reliability for most >> wireless networks, since they have an acknowledgment system. > > Yes, retransmissions at link layer are a link layer problem, dealt > with by power management of the link layer. IP stack cares about TCP > retransmissions or above. > >> Thus an unreliable link may actually take much more than the >> expected power to transmit every > frame, >> since it's often doing retries. I would expect a few >> retransmissions to basically nullify a lot of work selecting the >> "most optimum" routes from > an >> energy perspective. > > Hmmm... retransmissions may happen too for a node energy metric and > that may nullify its effect too. > > I don't mean retransmission of the metric, I just meant > retransmissions in general. It's a question of all this overhead > exchanging metrics to maintain a perfect route, when in the end you > spent more time maintain your route than routing data! So I think > for link energy to be 'accurate', you'd also need to keep the ETX > object updated for example. ETX has been so largely published and apparently implemented that I can't disagree with it. However, I see it as a different metric than the link energy metric. I guess one could use it differently than using an IP link energy metric. I think ETX is good when considering particular wireless MAC layer, but wouldn't be useful to qualify other links in the Internet like fiber, for example. It is very relevant for the MACs considered by LLNs, I think. Alex > >> 6) My conclusion from the above points is that the entire question >> of > RX/TX >> power is too complex to bother doing perfectly in these networks. A >> simplification that can at least be easily understood and specified >> would > be >> more useful to everyone in the end than something that is more >> complex and might not even work. > > If we wish we could discuss separately the actual use of the existing > node energy metric and I think it's not that simple either. > >> Using such a metric DOES require external documents to specify how >> the metric is used. But requiring external specification to work >> out details seems inline with the rest of RPL so shouldn't be a >> problem. >> >> And if in the future I'm completely wrong and someone needs link >> energy, I don't see a problem of fitting the link energy into a >> TLV in the "node energy object". > > I am happy to see openness to include link energy metric and I take > note for future discussion. > > But link energy is link energy not node energy. We saw it in the > above mAmpere discussion where you eliminated the computing power to > which I agreed; yet it doesn't make sense conceptually to put link > energy into a node energy container. Link energy values are > distinct from node energy values. > > Alex > >> >> Warm Regards, >> >> -Colin O'Flynn >> >> >> -----Original Message----- From: roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: >> September 18, 2010 5:11 PM To: Alexandru Petrescu Cc: roll@ietf.org >> Subject: Re: [Roll] WG Last Call on >> draft-ietf-roll-routing-metrics-09.txt >> >> >> On Sep 17, 2010, at 3:12 PM, Alexandru Petrescu wrote: >> >>> David, >>> >>> Thanks for this Last Call on the RoLL routing metrics draft. >>> >>> I reply now just to make sure I replied before the September >>> 30th, 2010, the deadline Chair set and that I consider. >>> >>> I have proposed last year to have energy link metrics: how much >>> energy in Joules is required on a particular link to send >>> 1280bytes as an IPv6 packet. >>> >>> I have proposed this link metric also as an extension to the >>> ripless draft-mulligan-roll-ripless-01. >>> >>> In draft-ietf-roll-routing-metrics energy _is_ used as a metric >>> but as node energy only, not link energy. >>> >>> Link metrics _are_ considered in draft-ietf-roll-routing-metrics >>> but not as energy. >>> >>> Private discussion pointed me unilaterally I may be wrong but I >>> think publicly I may be right. >>> >>> I will send more comments later. >> >> Alex, >> >> Can you point me to an application requirements doc, or a concrete >> application someone is building today, where link energy is >> needed? Given the tremendous size and diversity of the industries >> around LLNs, as well > as >> the application experience, I think our goal is to standardize >> current practice rather than invent new mechanisms. >> >> Phil _______________________________________________ Roll mailing >> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> >> > > > From yoav@yitran.com Sun Sep 19 13:11:06 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 679C73A69C5 for ; Sun, 19 Sep 2010 13:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.967 X-Spam-Level: X-Spam-Status: No, score=-4.967 tagged_above=-999 required=5 tests=[AWL=-1.590, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sx8A0aoC89je for ; Sun, 19 Sep 2010 13:11:03 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by core3.amsl.com (Postfix) with SMTP id 0CBB53A6958 for ; Sun, 19 Sep 2010 13:10:45 -0700 (PDT) Received: from source ([209.85.214.41]) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKTJZuXbucVB0Az/MBHtGZe3D0CC1gM83t@postini.com; Sun, 19 Sep 2010 13:11:10 PDT Received: by bwz10 with SMTP id 10so5389220bwz.0 for ; Sun, 19 Sep 2010 13:11:09 -0700 (PDT) Received: by 10.204.55.135 with SMTP id u7mr6034118bkg.122.1284927068843; Sun, 19 Sep 2010 13:11:08 -0700 (PDT) From: Yoav Ben-Yehezkel References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> <006501cb5758$27f3aa90$77daffb0$@com> <4C9501C7.2060400@gmail.com> <006b01cb577b$6c2f1550$448d3ff0$@com> <4C966485.3070206@gmail.com> In-Reply-To: <4C966485.3070206@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActYMPrTZuxL1BJ0Qbuc37+Z+62oTQABBpuw Date: Sun, 19 Sep 2010 22:11:03 +0200 Message-ID: To: Alexandru Petrescu , "Colin O'Flynn" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 19 Sep 2010 20:11:08 -0000 Thanks Alex/Colin for bringing this up for discussion. My two cents: I always saw the ability to operate at multiple media as one of the strongest points in favor of RPL (and L3 routing protocols) over specific L1/2 bridging techniques. The smart grid will most probably need to operate using both PLC or wireless media for the same utility owned networks in some cases. Consider the typical Multiple Dwelling Unit (MDU) use case where wireless meters reside outside apartments in sealed cabinets, and in-home displays are installed inside the apartments. RF cannot pass thick walls, so a selection of an L3 router via a PLC node is a natural (from the cabinet to the home). Another use case is of course to connect a wireless battery operated sensor (say on the ceiling) with a PLC device that needs the sensor inputs (such as PCTs). These smart-grid devices "belong" to the same utility network or sub-network (though using different medias sometimes)... RPL (or any L3 routing protocol as I understand it) supported by multiple PHY layers seems to me like an excellent choice for covering these use cases while inherently taking the routing metric into consideration when choosing which media is the most suitable for the next transmission to the final destination. I am seeking for WG confirmation that these use cases are covered well by RPL (as a route over media and link layer agnostic protocol). Otherwise, I think this is a significant short-coming of the protocol. The WG thoughts are very much appreciated. Best regards, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: Sunday, September 19, 2010 9:29 PM To: Colin O'Flynn Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt [my summary: it is worth clarifying (1) whether RPL runs in a single PHY or multiple PHY network, and (2) whether metrics for RPL should be understood in RPL network only or more universal like across the Internet. There are also points about whether Rx link energy is as important as Tx link energy and its usability overall.] Hi Colin, It does make sense to clarify the usage model first, especially the assumptions of whether or not RPL runs exclusively on networks made of single PHY, or multiple PHYs. I consider IP kind of work (do we say IPv6? 'router'?) is needed only if we consider multiple kinds of PHYs in the same network. Otherwise bridges, range extenders and other L2 tools are better appropriate than IP routers. During RPL comments we commented whether RPL draft text should say _only_ 802.15.4 or would it include PLC too. I think RPL draft text saying _only_ 802.15.4 would make subsequent metrics and security text much easier. However, it was insisted PLC should be there in the draft. So I am in that perspective now. But does that mean that RPL runs only on a network consisting of PLC devices, and on another network of 15.4 devices (separated by an Edge Router)? Or does it mean RPL runs in a network mixing 15.4 devices with PLC devices each being an RPL router? This was never clear. Le 18/09/2010 23:49, Colin O'Flynn a =E9crit : > Hi Alex, > > I think we have some different assumptions about the usage model. It > would be useful to clarify some of that first. I'm not claiming my > assumptions are correct or consistent with the ROLL/RPL basis, these > are simply my view of how I imagined it would all fit together: > > 1) A single RPL network itself does not cross multiple PHY layers. > Crossing PHY layers would complicate the decision on "best routes" > partially for the reasons you mention. My comments before showing TX > power vs current was showing that for the same PHY layer you can > have a huge swing of TX power yet minimal impact on energy required > to transmit a packet (100x change in RF energy =3D less than 2x change > in total energy). (The energy used for transmission is the one measured by setting a highres ampermeter serially with the transmitting device, its battery and a shunt, make it send an IPv6 packet (type ping). That shows the energy used for transmission. This is just a rough view, but basically that is. There are related measurement tools like antena placed near emitter (the ones used to measure the DAS of mobile phones W/Kg).) > 2) Routing metrics are not universal, but will somewhat be > application-dependant. Thus you can change the metrics for different > nodes as required, and metrics might not make sense between > different RPL networks (this fits in with assumption #1). > > Thus my view was the metrics should be simple, as you hide any > required customization. If you want to select the outgoing interface > you have some artificial change in the metric, where the > administrator has basically forced the device to prefer interface 1 > over interface 2. Yes, the metric should be simple. The simplest relates much to what exists in terms of how IP routers select their output interface without artificial human intervention. > In your given example of an automotive system where they all work on > a common power source, the nodes have a specific routing metric > where a certain "fudge factor" has been worked into the different > nodes. Thus all other things being equal, the advertised metric of a > node which takes a lot of energy to transmit is made such that it is > less preferred over another node. > > I think you are assuming that (1) you can have different PHYs within > the RPL network, and (2) the routing metrics are more universal, so > you can compare two different RPL networks. Is this correct? Yes, right, that is my assumption: different PHYs within an RPL network and routing metrics more universal - they'd work within the RPL network and across the Internet (like the simple hopcount metric), and one could also compare different RPL networks. Do we want metrics that work _only_ within an RPL network? Or more universal like across the Internet? Or both? This is also a requirement discussion which is worth clarifying. > I've included some clarifications below as well (see ), > but I think the above two points are most important to understanding > why we may see such a wide difference of opinion. YEs, the above points about RPL running in a single PHY or multiple PHY network, and metric only worth in RPL or across the Internet, are important to clarify. > Regards, > > -Colin > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Sent: September 18, 2010 7:16 > PM To: Colin O'Flynn Cc: 'Philip Levis'; roll@ietf.org Subject: Re: > [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt > > Le 18/09/2010 19:37, Colin O'Flynn a =E9crit : >> Caveat emptor: I have not read the entire metrics-09 at this >> point, but wanted to comment anyway. >> >> I think the idea of "link energy" would be without much merit, of >> course > I'm >> open to being wrong. My reasoning is as follows: >> >> 1) There will not be much difference between the energy it takes >> to > transmit >> a packet within a RPL network. They will all be using similar link >> layers, > > Take a car: all devices are on a single unique battery, yet many > different copper, light and ether links in terms of energy needed. > > (in a car - how would a "battery" value of the metric which assumes > each IP addressable device has its own "battery" work with RPL? All > devices in the car are on the same unique battery, and sometimes on > car engine electricity generator. Add to this the Electric Vehicle > and you see.) > >> and much of the power of actually transmitting a packet is not >> related to > TX >> power but getting everything else up (such as CPU running& >> processing, > PLL >> being active and locked, CSMA being performed). > > That is right. Each transmitting device has CPU chipset to compute > wireless coding and that takes energy. That energy is in higher > orders of magnitude than actually transmitting. > > However the energy used to actual Tx (and Rx as in GPS devices) can > be clearly distinguished. > > I meant that you would then require information on both TX& RX > power if you wanted to be accurate. So you'd have to add more > metrics there, and add two values for every hop. Hmmm... that sounds right. To be better accurate about link energy metrics one would have to do both Tx metric and Rx metric. This could be done. I was thinking that presenting first the Tx link energy metric it would be easier to understand and then add the Rx metric too, naturally. >> As an example for one specific radio, the ATMega128RFA1, the >> values of current vs power output (from datasheet @ 3.0V): RX PWR >> | Supply 3dBm | 14.5mA 1dBm | 10mA -3dBm | 9mA -17dBm | 8mA >> >> Converting both to mW (=3D mJ/s) RX PWR | Supply 2.00 | 43.5 1.26 | >> 30 0.50 | 27 0.02 | 24 >> >> This is just current during active TX. > > That sounds exellent startpoint for design a link energy metric! To > eliminate the time paramter (mJ/s) to get to the J only we could > decide that we need to transmit 1280bytes of data - the IPv6 minimal > MTU. > >> There are some additional things that are TX power independent, >> but I think for any reasonable length 6LoWPAN packet they are much >> smaller than the values I have here. > > Are we IPv6 perspective or not. If yes IPv6 stack needs to know how > much energy is needed 1280bytes of data, a minimally sized IPv6 > packet. The stack reasons in terms of packets of that or larger > size. > > My example is 802.15.4/6LoWPAN specific, as that was just > 802.15.4 packets. I just meant for any reasonable size 802.15.4 > packet seen on a 6lowpan/IPv6 network you don't need to worry about > CSMA time for example, as it's fairly minimal by comparison. Well, IPv6 for 802.15.4 RFC says clearly this is minimal IPv6 MTU 1280bytes. I am not sure I understand why should IPv6 stack worry about smaller data-link packets but I have to dig this, e.g. see whether the linux stack does consider smaller than 1280bytes or not. >> 2) Receiving takes around the same amount of power as transmitting >> for > most >> 802.15.4 nodes. For the previously used example that is around >> 12mA in > fact. >> Thus the problem is not only TX power, but RX power. > > With GPS devices it is even truer, because they only receive. > >> How do you encapsulate that in "link energy" accurately? > > Well I proposed a metric bit encoding for it - should I send again? > > I looked back to I think may 2009 when I saw a discussion about > it, if it was before that I probably missed it. Ok, I will resend tomorrow an an example of encoding energy link metric for RA (it's on my office desktop). >> If you do it in simple ways with "fudge factors" you've probably >> lost enough accuracy to bother doing it at all. > > I don't propose fudge factors. > >> 3) Link energy on its own would result in selecting lowest energy >> paths I assume. Low power nodes which advertise smaller link >> energies have > probably >> gone to great lengths to get low link energies, since they have low >> available power. The nodes which are wall-powered won't try to get >> link energy as low since they are free to transmit at highest >> energy and not worry too much about power saving tricks. This >> would be the opposite of > what >> you want, so obviously you combine link energy with available >> energy. > > I would not combine. > > Combine was a poor choice of words on my part. I meant it > uses both the link energy& node energy, and "combines" them to > create a routing solution. So if you had separate link energy& node > energy, figuring out how to use both of them would be a complex > problem. I agree using both node and link energy in a single metric would make it more complex. >> Combining link energy with available energy would be incredibly >> complex to get perfect. Worse if you do it wrong you end up with >> the exact opposite > of >> what you want since low-power paths are used at the expense of >> battery > life. > > What is battery life when birth and death is turning an engine > on/off? Or when plugging the device on a docking. Or when plugging > a vehicle on an outlet. > >> At least there is some obvious connection between a simple >> "available energy" value and "am I likely to be used to route a >> packet". > > Node energy helps it that way, yes. > >> 4) Transmit energy also depends on link reliability for most >> wireless networks, since they have an acknowledgment system. > > Yes, retransmissions at link layer are a link layer problem, dealt > with by power management of the link layer. IP stack cares about TCP > retransmissions or above. > >> Thus an unreliable link may actually take much more than the >> expected power to transmit every > frame, >> since it's often doing retries. I would expect a few >> retransmissions to basically nullify a lot of work selecting the >> "most optimum" routes from > an >> energy perspective. > > Hmmm... retransmissions may happen too for a node energy metric and > that may nullify its effect too. > > I don't mean retransmission of the metric, I just meant > retransmissions in general. It's a question of all this overhead > exchanging metrics to maintain a perfect route, when in the end you > spent more time maintain your route than routing data! So I think > for link energy to be 'accurate', you'd also need to keep the ETX > object updated for example. ETX has been so largely published and apparently implemented that I can't disagree with it. However, I see it as a different metric than the link energy metric. I guess one could use it differently than using an IP link energy metric. I think ETX is good when considering particular wireless MAC layer, but wouldn't be useful to qualify other links in the Internet like fiber, for example. It is very relevant for the MACs considered by LLNs, I think. Alex > >> 6) My conclusion from the above points is that the entire question >> of > RX/TX >> power is too complex to bother doing perfectly in these networks. A >> simplification that can at least be easily understood and specified >> would > be >> more useful to everyone in the end than something that is more >> complex and might not even work. > > If we wish we could discuss separately the actual use of the existing > node energy metric and I think it's not that simple either. > >> Using such a metric DOES require external documents to specify how >> the metric is used. But requiring external specification to work >> out details seems inline with the rest of RPL so shouldn't be a >> problem. >> >> And if in the future I'm completely wrong and someone needs link >> energy, I don't see a problem of fitting the link energy into a >> TLV in the "node energy object". > > I am happy to see openness to include link energy metric and I take > note for future discussion. > > But link energy is link energy not node energy. We saw it in the > above mAmpere discussion where you eliminated the computing power to > which I agreed; yet it doesn't make sense conceptually to put link > energy into a node energy container. Link energy values are > distinct from node energy values. > > Alex > >> >> Warm Regards, >> >> -Colin O'Flynn >> >> >> -----Original Message----- From: roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: >> September 18, 2010 5:11 PM To: Alexandru Petrescu Cc: roll@ietf.org >> Subject: Re: [Roll] WG Last Call on >> draft-ietf-roll-routing-metrics-09.txt >> >> >> On Sep 17, 2010, at 3:12 PM, Alexandru Petrescu wrote: >> >>> David, >>> >>> Thanks for this Last Call on the RoLL routing metrics draft. >>> >>> I reply now just to make sure I replied before the September >>> 30th, 2010, the deadline Chair set and that I consider. >>> >>> I have proposed last year to have energy link metrics: how much >>> energy in Joules is required on a particular link to send >>> 1280bytes as an IPv6 packet. >>> >>> I have proposed this link metric also as an extension to the >>> ripless draft-mulligan-roll-ripless-01. >>> >>> In draft-ietf-roll-routing-metrics energy _is_ used as a metric >>> but as node energy only, not link energy. >>> >>> Link metrics _are_ considered in draft-ietf-roll-routing-metrics >>> but not as energy. >>> >>> Private discussion pointed me unilaterally I may be wrong but I >>> think publicly I may be right. >>> >>> I will send more comments later. >> >> Alex, >> >> Can you point me to an application requirements doc, or a concrete >> application someone is building today, where link energy is >> needed? Given the tremendous size and diversity of the industries >> around LLNs, as well > as >> the application experience, I think our goal is to standardize >> current practice rather than invent new mechanisms. >> >> Phil _______________________________________________ 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 jpv@cisco.com Mon Sep 20 00:21:17 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA2453A698F for ; Mon, 20 Sep 2010 00:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.411 X-Spam-Level: X-Spam-Status: No, score=-110.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tI231ij-dsIY for ; Mon, 20 Sep 2010 00:21:15 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 6B52B3A698D for ; Mon, 20 Sep 2010 00:21:15 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADuolkyrR7Hu/2dsb2JhbACbY4ZCcacRm1CCc4JOBIo4gwSCXA X-IronPort-AV: E=Sophos;i="4.56,391,1280707200"; d="scan'208";a="188922451" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 20 Sep 2010 07:21:39 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o8K7LZBx024983; Mon, 20 Sep 2010 07:21:38 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Sep 2010 09:21:36 +0200 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Sep 2010 09:21:35 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: JP Vasseur In-Reply-To: <4C966485.3070206@gmail.com> Date: Mon, 20 Sep 2010 09:21:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9FB3AA8F-037A-4399-BEF9-38749BB38122@cisco.com> References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> <006501cb5758$27f3aa90$77daffb0$@com> <4C9501C7.2060400@gmail.com> <006b01cb577b$6c2f1550$448d3ff0$@com> <4C966485.3070206@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 20 Sep 2010 07:21:35.0458 (UTC) FILETIME=[752E8C20:01CB5894] Cc: roll@ietf.org Subject: [Roll] ** Multiple PHY/MAC ** Re: WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 20 Sep 2010 07:21:17 -0000 Hold-on ... RPL is a L3 routing protocol, which by itself answers = (hopefully) your first question. Further, this is clearly stated in the charter. With = regards to your=20 second question, these metrics are RPL metrics. On Sep 19, 2010, at 9:29 PM, Alexandru Petrescu wrote: > [my summary: it is worth clarifying (1) whether RPL runs in a single > PHY or multiple PHY network, and (2) whether metrics for RPL should be > understood in RPL network only or more universal like across the > Internet. There are also points about whether Rx link energy is as > important as Tx link energy and its usability overall.] >=20 > Hi Colin, >=20 > It does make sense to clarify the usage model first, especially the > assumptions of whether or not RPL runs exclusively on networks made of > single PHY, or multiple PHYs. >=20 > I consider IP kind of work (do we say IPv6? 'router'?) is needed only = if > we consider multiple kinds of PHYs in the same network. Otherwise > bridges, range extenders and other L2 tools are better appropriate = than > IP routers. >=20 > During RPL comments we commented whether RPL draft text should say > _only_ 802.15.4 or would it include PLC too. I think RPL draft text > saying _only_ 802.15.4 would make subsequent metrics and security text > much easier. However, it was insisted PLC should be there in the = draft. > So I am in that perspective now. >=20 > But does that mean that RPL runs only on a network consisting of PLC > devices, and on another network of 15.4 devices (separated by an Edge > Router)? Or does it mean RPL runs in a network mixing 15.4 devices > with PLC devices each being an RPL router? >=20 > This was never clear. >=20 > Le 18/09/2010 23:49, Colin O'Flynn a =E9crit : >> Hi Alex, >>=20 >> I think we have some different assumptions about the usage model. It >> would be useful to clarify some of that first. I'm not claiming my >> assumptions are correct or consistent with the ROLL/RPL basis, these >> are simply my view of how I imagined it would all fit together: >>=20 >> 1) A single RPL network itself does not cross multiple PHY layers. >> Crossing PHY layers would complicate the decision on "best routes" >> partially for the reasons you mention. My comments before showing TX >> power vs current was showing that for the same PHY layer you can >> have a huge swing of TX power yet minimal impact on energy required >> to transmit a packet (100x change in RF energy =3D less than 2x = change >> in total energy). >=20 > (The energy used for transmission is the one measured by setting a = highres ampermeter serially with the transmitting device, its battery = and a shunt, make it send an IPv6 packet (type ping). That shows the = energy used for transmission. This is just a rough view, but basically = that is. There are related measurement tools like antena placed near = emitter (the ones used to measure the DAS of mobile phones W/Kg).) >=20 >> 2) Routing metrics are not universal, but will somewhat be >> application-dependant. Thus you can change the metrics for different >> nodes as required, and metrics might not make sense between >> different RPL networks (this fits in with assumption #1). >>=20 >> Thus my view was the metrics should be simple, as you hide any >> required customization. If you want to select the outgoing interface >> you have some artificial change in the metric, where the >> administrator has basically forced the device to prefer interface 1 >> over interface 2. >=20 > Yes, the metric should be simple. The simplest relates much to what = exists in terms of how IP routers select their output interface without = artificial human intervention. >=20 >> In your given example of an automotive system where they all work on >> a common power source, the nodes have a specific routing metric >> where a certain "fudge factor" has been worked into the different >> nodes. Thus all other things being equal, the advertised metric of a >> node which takes a lot of energy to transmit is made such that it is >> less preferred over another node. >>=20 >> I think you are assuming that (1) you can have different PHYs within >> the RPL network, and (2) the routing metrics are more universal, so >> you can compare two different RPL networks. Is this correct? >=20 > Yes, right, that is my assumption: different PHYs within an RPL = network > and routing metrics more universal - they'd work within the RPL = network > and across the Internet (like the simple hopcount metric), and one = could > also compare different RPL networks. >=20 > Do we want metrics that work _only_ within an RPL network? Or more = universal like across the Internet? Or both? This is also a = requirement discussion which is worth clarifying. >=20 >> I've included some clarifications below as well (see ), >> but I think the above two points are most important to understanding >> why we may see such a wide difference of opinion. >=20 > YEs, the above points about RPL running in a single PHY or multiple = PHY network, and metric only worth in RPL or across the Internet, are = important to clarify. >=20 >> Regards, >>=20 >> -Colin >>=20 >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: September 18, 2010 7:16 >> PM To: Colin O'Flynn Cc: 'Philip Levis'; roll@ietf.org Subject: Re: >> [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt >>=20 >> Le 18/09/2010 19:37, Colin O'Flynn a =E9crit : >>> Caveat emptor: I have not read the entire metrics-09 at this >>> point, but wanted to comment anyway. >>>=20 >>> I think the idea of "link energy" would be without much merit, of >>> course >> I'm >>> open to being wrong. My reasoning is as follows: >>>=20 >>> 1) There will not be much difference between the energy it takes >>> to >> transmit >>> a packet within a RPL network. They will all be using similar link >>> layers, >>=20 >> Take a car: all devices are on a single unique battery, yet many >> different copper, light and ether links in terms of energy needed. >>=20 >> (in a car - how would a "battery" value of the metric which assumes >> each IP addressable device has its own "battery" work with RPL? All >> devices in the car are on the same unique battery, and sometimes on >> car engine electricity generator. Add to this the Electric Vehicle >> and you see.) >>=20 >>> and much of the power of actually transmitting a packet is not >>> related to >> TX >>> power but getting everything else up (such as CPU running& >>> processing, >> PLL >>> being active and locked, CSMA being performed). >>=20 >> That is right. Each transmitting device has CPU chipset to compute >> wireless coding and that takes energy. That energy is in higher >> orders of magnitude than actually transmitting. >>=20 >> However the energy used to actual Tx (and Rx as in GPS devices) can >> be clearly distinguished. >>=20 >> I meant that you would then require information on both TX& RX >> power if you wanted to be accurate. So you'd have to add more >> metrics there, and add two values for every hop. >=20 > Hmmm... that sounds right. To be better accurate about link energy > metrics one would have to do both Tx metric and Rx metric. This could > be done. I was thinking that presenting first the Tx link energy = metric > it would be easier to understand and then add the Rx metric too, = naturally. >=20 >>> As an example for one specific radio, the ATMega128RFA1, the >>> values of current vs power output (from datasheet @ 3.0V): RX PWR >>> | Supply 3dBm | 14.5mA 1dBm | 10mA -3dBm | 9mA -17dBm | 8mA >>>=20 >>> Converting both to mW (=3D mJ/s) RX PWR | Supply 2.00 | 43.5 1.26 = | >>> 30 0.50 | 27 0.02 | 24 >>>=20 >>> This is just current during active TX. >>=20 >> That sounds exellent startpoint for design a link energy metric! To >> eliminate the time paramter (mJ/s) to get to the J only we could >> decide that we need to transmit 1280bytes of data - the IPv6 minimal >> MTU. >>=20 >>> There are some additional things that are TX power independent, >>> but I think for any reasonable length 6LoWPAN packet they are much >>> smaller than the values I have here. >>=20 >> Are we IPv6 perspective or not. If yes IPv6 stack needs to know how >> much energy is needed 1280bytes of data, a minimally sized IPv6 >> packet. The stack reasons in terms of packets of that or larger >> size. >>=20 >> My example is 802.15.4/6LoWPAN specific, as that was just >> 802.15.4 packets. I just meant for any reasonable size 802.15.4 >> packet seen on a 6lowpan/IPv6 network you don't need to worry about >> CSMA time for example, as it's fairly minimal by comparison. >=20 > Well, IPv6 for 802.15.4 RFC says clearly this is minimal IPv6 MTU > 1280bytes. I am not sure I understand why should IPv6 stack worry = about > smaller data-link packets but I have to dig this, e.g. see whether the > linux stack does consider smaller than 1280bytes or not. >=20 >>> 2) Receiving takes around the same amount of power as transmitting >>> for >> most >>> 802.15.4 nodes. For the previously used example that is around >>> 12mA in >> fact. >>> Thus the problem is not only TX power, but RX power. >>=20 >> With GPS devices it is even truer, because they only receive. >>=20 >>> How do you encapsulate that in "link energy" accurately? >>=20 >> Well I proposed a metric bit encoding for it - should I send again? >>=20 >> I looked back to I think may 2009 when I saw a discussion about >> it, if it was before that I probably missed it. >=20 > Ok, I will resend tomorrow an an example of encoding energy link = metric > for RA (it's on my office desktop). >=20 >>> If you do it in simple ways with "fudge factors" you've probably >>> lost enough accuracy to bother doing it at all. >>=20 >> I don't propose fudge factors. >>=20 >>> 3) Link energy on its own would result in selecting lowest energy >>> paths I assume. Low power nodes which advertise smaller link >>> energies have >> probably >>> gone to great lengths to get low link energies, since they have low >>> available power. The nodes which are wall-powered won't try to get >>> link energy as low since they are free to transmit at highest >>> energy and not worry too much about power saving tricks. This >>> would be the opposite of >> what >>> you want, so obviously you combine link energy with available >>> energy. >>=20 >> I would not combine. >>=20 >> Combine was a poor choice of words on my part. I meant it >> uses both the link energy& node energy, and "combines" them to >> create a routing solution. So if you had separate link energy& node >> energy, figuring out how to use both of them would be a complex >> problem. >=20 > I agree using both node and link energy in a single metric would make = it > more complex. >=20 >>> Combining link energy with available energy would be incredibly >>> complex to get perfect. Worse if you do it wrong you end up with >>> the exact opposite >> of >>> what you want since low-power paths are used at the expense of >>> battery >> life. >>=20 >> What is battery life when birth and death is turning an engine >> on/off? Or when plugging the device on a docking. Or when plugging >> a vehicle on an outlet. >>=20 >>> At least there is some obvious connection between a simple >>> "available energy" value and "am I likely to be used to route a >>> packet". >>=20 >> Node energy helps it that way, yes. >>=20 >>> 4) Transmit energy also depends on link reliability for most >>> wireless networks, since they have an acknowledgment system. >>=20 >> Yes, retransmissions at link layer are a link layer problem, dealt >> with by power management of the link layer. IP stack cares about TCP >> retransmissions or above. >>=20 >>> Thus an unreliable link may actually take much more than the >>> expected power to transmit every >> frame, >>> since it's often doing retries. I would expect a few >>> retransmissions to basically nullify a lot of work selecting the >>> "most optimum" routes from >> an >>> energy perspective. >>=20 >> Hmmm... retransmissions may happen too for a node energy metric and >> that may nullify its effect too. >>=20 >> I don't mean retransmission of the metric, I just meant >> retransmissions in general. It's a question of all this overhead >> exchanging metrics to maintain a perfect route, when in the end you >> spent more time maintain your route than routing data! So I think >> for link energy to be 'accurate', you'd also need to keep the ETX >> object updated for example. >=20 > ETX has been so largely published and apparently implemented that I > can't disagree with it. However, I see it as a different metric than > the link energy metric. I guess one could use it differently than = using > an IP link energy metric. >=20 > I think ETX is good when considering particular wireless MAC layer, = but > wouldn't be useful to qualify other links in the Internet like fiber, > for example. It is very relevant for the MACs considered by LLNs, I = think. >=20 > Alex >=20 >=20 >>=20 >>> 6) My conclusion from the above points is that the entire question >>> of >> RX/TX >>> power is too complex to bother doing perfectly in these networks. A >>> simplification that can at least be easily understood and specified >>> would >> be >>> more useful to everyone in the end than something that is more >>> complex and might not even work. >>=20 >> If we wish we could discuss separately the actual use of the existing >> node energy metric and I think it's not that simple either. >>=20 >>> Using such a metric DOES require external documents to specify how >>> the metric is used. But requiring external specification to work >>> out details seems inline with the rest of RPL so shouldn't be a >>> problem. >>>=20 >>> And if in the future I'm completely wrong and someone needs link >>> energy, I don't see a problem of fitting the link energy into a >>> TLV in the "node energy object". >>=20 >> I am happy to see openness to include link energy metric and I take >> note for future discussion. >>=20 >> But link energy is link energy not node energy. We saw it in the >> above mAmpere discussion where you eliminated the computing power to >> which I agreed; yet it doesn't make sense conceptually to put link >> energy into a node energy container. Link energy values are >> distinct from node energy values. >>=20 >> Alex >>=20 >>>=20 >>> Warm Regards, >>>=20 >>> -Colin O'Flynn >>>=20 >>>=20 >>> -----Original Message----- From: roll-bounces@ietf.org >>> [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: >>> September 18, 2010 5:11 PM To: Alexandru Petrescu Cc: roll@ietf.org >>> Subject: Re: [Roll] WG Last Call on >>> draft-ietf-roll-routing-metrics-09.txt >>>=20 >>>=20 >>> On Sep 17, 2010, at 3:12 PM, Alexandru Petrescu wrote: >>>=20 >>>> David, >>>>=20 >>>> Thanks for this Last Call on the RoLL routing metrics draft. >>>>=20 >>>> I reply now just to make sure I replied before the September >>>> 30th, 2010, the deadline Chair set and that I consider. >>>>=20 >>>> I have proposed last year to have energy link metrics: how much >>>> energy in Joules is required on a particular link to send >>>> 1280bytes as an IPv6 packet. >>>>=20 >>>> I have proposed this link metric also as an extension to the >>>> ripless draft-mulligan-roll-ripless-01. >>>>=20 >>>> In draft-ietf-roll-routing-metrics energy _is_ used as a metric >>>> but as node energy only, not link energy. >>>>=20 >>>> Link metrics _are_ considered in draft-ietf-roll-routing-metrics >>>> but not as energy. >>>>=20 >>>> Private discussion pointed me unilaterally I may be wrong but I >>>> think publicly I may be right. >>>>=20 >>>> I will send more comments later. >>>=20 >>> Alex, >>>=20 >>> Can you point me to an application requirements doc, or a concrete >>> application someone is building today, where link energy is >>> needed? Given the tremendous size and diversity of the industries >>> around LLNs, as well >> as >>> the application experience, I think our goal is to standardize >>> current practice rather than invent new mechanisms. >>>=20 >>> Phil _______________________________________________ Roll mailing >>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From coflynn@newae.com Mon Sep 20 02:40:49 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8B513A68FE for ; Mon, 20 Sep 2010 02:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irJ6hntyHSIb for ; Mon, 20 Sep 2010 02:40:47 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 332293A6A3A for ; Mon, 20 Sep 2010 02:39:52 -0700 (PDT) Received: from static-93.158.79.103.got.public.icomera.com ([93.158.79.103] helo=COLINNETBOOK) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1OxcqQ-0003fz-R1; Mon, 20 Sep 2010 05:40:12 -0400 From: "Colin O'Flynn" To: "'JP Vasseur'" References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> <006501cb5758$27f3aa90$77daffb0$@com> <4C9501C7.2060400@gmail.com> <006b01cb577b$6c2f1550$448d3ff0$@com> <4C966485.3070206@gmail.com> <9FB3AA8F-037A-4399-BEF9-38749BB38122@cisco.com> In-Reply-To: <9FB3AA8F-037A-4399-BEF9-38749BB38122@cisco.com> Date: Mon, 20 Sep 2010 10:37:32 +0100 Message-ID: <000001cb58a7$bc501a20$34f04e60$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActYlHpFhEN7E8x1SOOlhmsJ84FE4gACLbaQ Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: roll@ietf.org Subject: Re: [Roll] ** Multiple PHY/MAC ** Re: WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 20 Sep 2010 09:40:49 -0000 Hi JP, I think the problem was around the routing metrics themselves somehow = being L2 dependant. Let me see if I can summarize: Thus while there is nothing to stop RPL working between multiple PHY = layers, as any L3 routing protocol would, there is a question around how the = metrics reflect different L2 hops.=20 Say you had a network with WiFi, 802.15.4, and PLC nodes, with some of = the nodes having one interface, some having two or more. Does RPL run a = *single* RPLInstance across the entire network? Alex's concern is that the routing metric only tells you information = about how much energy a node has available, not the cost of routing on that = link when you have vastly different L2 technologies. Thus for example a battery powered 802.15.4 node and a battery powered cellular node are both reachable and possible paths to a destination. = The 802.15.4 node may advertise itself as having a certain amount of energy = to spare, and a cellular node may advertise itself as having less energy to spare (smaller E-E value). However this does not reflect the fact the 802.15.4 node is currently handling no routes, and the cellular node is handling ten. The incremental cost of adding a single route to the = 802.15.4 is higher than for cellular. In this case you need to somehow advertise = not only how much energy you have or are using, but how much energy you = would have after carrying a packet. In my example you may end up oscillating, = as once the 802.15.4 node starts carrying traffic it advertises itself as having much less available energy and tries to dump the route. Have I summarized this correctly Alex? Perhaps it does make sense to adjust the 'node energy' metric to = advertise not the currently available power/lifetime as is worded in the draft, = but somehow work in the power it would take to carry a route/packet relative = to your available power. So the estimate in E-E is not the current value, = but the expected value after sending some defined number of packets. This = would at least let you know if you have a node with a tiny battery that just happens to have no other draw, or a node connected to a car battery that = can handle your extra packets. Regards, -Colin -----Original Message----- From: JP Vasseur [mailto:jpv@cisco.com]=20 Sent: September 20, 2010 8:22 AM To: Alexandru Petrescu Cc: Colin O'Flynn; roll@ietf.org Subject: ** Multiple PHY/MAC ** Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt Hold-on ... RPL is a L3 routing protocol, which by itself answers (hopefully) your first question. Further, this is clearly stated in the charter. With = regards to your=20 second question, these metrics are RPL metrics. On Sep 19, 2010, at 9:29 PM, Alexandru Petrescu wrote: > [my summary: it is worth clarifying (1) whether RPL runs in a single > PHY or multiple PHY network, and (2) whether metrics for RPL should be > understood in RPL network only or more universal like across the > Internet. There are also points about whether Rx link energy is as > important as Tx link energy and its usability overall.] >=20 > Hi Colin, >=20 > It does make sense to clarify the usage model first, especially the > assumptions of whether or not RPL runs exclusively on networks made of > single PHY, or multiple PHYs. >=20 > I consider IP kind of work (do we say IPv6? 'router'?) is needed only = if > we consider multiple kinds of PHYs in the same network. Otherwise > bridges, range extenders and other L2 tools are better appropriate = than > IP routers. >=20 > During RPL comments we commented whether RPL draft text should say > _only_ 802.15.4 or would it include PLC too. I think RPL draft text > saying _only_ 802.15.4 would make subsequent metrics and security text > much easier. However, it was insisted PLC should be there in the = draft. > So I am in that perspective now. >=20 > But does that mean that RPL runs only on a network consisting of PLC > devices, and on another network of 15.4 devices (separated by an Edge > Router)? Or does it mean RPL runs in a network mixing 15.4 devices > with PLC devices each being an RPL router? >=20 > This was never clear. >=20 > Le 18/09/2010 23:49, Colin O'Flynn a =E9crit : >> Hi Alex, >>=20 >> I think we have some different assumptions about the usage model. It >> would be useful to clarify some of that first. I'm not claiming my >> assumptions are correct or consistent with the ROLL/RPL basis, these >> are simply my view of how I imagined it would all fit together: >>=20 >> 1) A single RPL network itself does not cross multiple PHY layers. >> Crossing PHY layers would complicate the decision on "best routes" >> partially for the reasons you mention. My comments before showing TX >> power vs current was showing that for the same PHY layer you can >> have a huge swing of TX power yet minimal impact on energy required >> to transmit a packet (100x change in RF energy =3D less than 2x = change >> in total energy). >=20 > (The energy used for transmission is the one measured by setting a = highres ampermeter serially with the transmitting device, its battery and a = shunt, make it send an IPv6 packet (type ping). That shows the energy used for transmission. This is just a rough view, but basically that is. There = are related measurement tools like antena placed near emitter (the ones used = to measure the DAS of mobile phones W/Kg).) >=20 >> 2) Routing metrics are not universal, but will somewhat be >> application-dependant. Thus you can change the metrics for different >> nodes as required, and metrics might not make sense between >> different RPL networks (this fits in with assumption #1). >>=20 >> Thus my view was the metrics should be simple, as you hide any >> required customization. If you want to select the outgoing interface >> you have some artificial change in the metric, where the >> administrator has basically forced the device to prefer interface 1 >> over interface 2. >=20 > Yes, the metric should be simple. The simplest relates much to what exists in terms of how IP routers select their output interface without artificial human intervention. >=20 >> In your given example of an automotive system where they all work on >> a common power source, the nodes have a specific routing metric >> where a certain "fudge factor" has been worked into the different >> nodes. Thus all other things being equal, the advertised metric of a >> node which takes a lot of energy to transmit is made such that it is >> less preferred over another node. >>=20 >> I think you are assuming that (1) you can have different PHYs within >> the RPL network, and (2) the routing metrics are more universal, so >> you can compare two different RPL networks. Is this correct? >=20 > Yes, right, that is my assumption: different PHYs within an RPL = network > and routing metrics more universal - they'd work within the RPL = network > and across the Internet (like the simple hopcount metric), and one = could > also compare different RPL networks. >=20 > Do we want metrics that work _only_ within an RPL network? Or more universal like across the Internet? Or both? This is also a = requirement discussion which is worth clarifying. >=20 >> I've included some clarifications below as well (see ), >> but I think the above two points are most important to understanding >> why we may see such a wide difference of opinion. >=20 > YEs, the above points about RPL running in a single PHY or multiple = PHY network, and metric only worth in RPL or across the Internet, are = important to clarify. >=20 >> Regards, >>=20 >> -Colin >>=20 >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: September 18, 2010 7:16 >> PM To: Colin O'Flynn Cc: 'Philip Levis'; roll@ietf.org Subject: Re: >> [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt >>=20 >> Le 18/09/2010 19:37, Colin O'Flynn a =E9crit : >>> Caveat emptor: I have not read the entire metrics-09 at this >>> point, but wanted to comment anyway. >>>=20 >>> I think the idea of "link energy" would be without much merit, of >>> course >> I'm >>> open to being wrong. My reasoning is as follows: >>>=20 >>> 1) There will not be much difference between the energy it takes >>> to >> transmit >>> a packet within a RPL network. They will all be using similar link >>> layers, >>=20 >> Take a car: all devices are on a single unique battery, yet many >> different copper, light and ether links in terms of energy needed. >>=20 >> (in a car - how would a "battery" value of the metric which assumes >> each IP addressable device has its own "battery" work with RPL? All >> devices in the car are on the same unique battery, and sometimes on >> car engine electricity generator. Add to this the Electric Vehicle >> and you see.) >>=20 >>> and much of the power of actually transmitting a packet is not >>> related to >> TX >>> power but getting everything else up (such as CPU running& >>> processing, >> PLL >>> being active and locked, CSMA being performed). >>=20 >> That is right. Each transmitting device has CPU chipset to compute >> wireless coding and that takes energy. That energy is in higher >> orders of magnitude than actually transmitting. >>=20 >> However the energy used to actual Tx (and Rx as in GPS devices) can >> be clearly distinguished. >>=20 >> I meant that you would then require information on both TX& RX >> power if you wanted to be accurate. So you'd have to add more >> metrics there, and add two values for every hop. >=20 > Hmmm... that sounds right. To be better accurate about link energy > metrics one would have to do both Tx metric and Rx metric. This could > be done. I was thinking that presenting first the Tx link energy = metric > it would be easier to understand and then add the Rx metric too, naturally. >=20 >>> As an example for one specific radio, the ATMega128RFA1, the >>> values of current vs power output (from datasheet @ 3.0V): RX PWR >>> | Supply 3dBm | 14.5mA 1dBm | 10mA -3dBm | 9mA -17dBm | 8mA >>>=20 >>> Converting both to mW (=3D mJ/s) RX PWR | Supply 2.00 | 43.5 1.26 = | >>> 30 0.50 | 27 0.02 | 24 >>>=20 >>> This is just current during active TX. >>=20 >> That sounds exellent startpoint for design a link energy metric! To >> eliminate the time paramter (mJ/s) to get to the J only we could >> decide that we need to transmit 1280bytes of data - the IPv6 minimal >> MTU. >>=20 >>> There are some additional things that are TX power independent, >>> but I think for any reasonable length 6LoWPAN packet they are much >>> smaller than the values I have here. >>=20 >> Are we IPv6 perspective or not. If yes IPv6 stack needs to know how >> much energy is needed 1280bytes of data, a minimally sized IPv6 >> packet. The stack reasons in terms of packets of that or larger >> size. >>=20 >> My example is 802.15.4/6LoWPAN specific, as that was just >> 802.15.4 packets. I just meant for any reasonable size 802.15.4 >> packet seen on a 6lowpan/IPv6 network you don't need to worry about >> CSMA time for example, as it's fairly minimal by comparison. >=20 > Well, IPv6 for 802.15.4 RFC says clearly this is minimal IPv6 MTU > 1280bytes. I am not sure I understand why should IPv6 stack worry = about > smaller data-link packets but I have to dig this, e.g. see whether the > linux stack does consider smaller than 1280bytes or not. >=20 >>> 2) Receiving takes around the same amount of power as transmitting >>> for >> most >>> 802.15.4 nodes. For the previously used example that is around >>> 12mA in >> fact. >>> Thus the problem is not only TX power, but RX power. >>=20 >> With GPS devices it is even truer, because they only receive. >>=20 >>> How do you encapsulate that in "link energy" accurately? >>=20 >> Well I proposed a metric bit encoding for it - should I send again? >>=20 >> I looked back to I think may 2009 when I saw a discussion about >> it, if it was before that I probably missed it. >=20 > Ok, I will resend tomorrow an an example of encoding energy link = metric > for RA (it's on my office desktop). >=20 >>> If you do it in simple ways with "fudge factors" you've probably >>> lost enough accuracy to bother doing it at all. >>=20 >> I don't propose fudge factors. >>=20 >>> 3) Link energy on its own would result in selecting lowest energy >>> paths I assume. Low power nodes which advertise smaller link >>> energies have >> probably >>> gone to great lengths to get low link energies, since they have low >>> available power. The nodes which are wall-powered won't try to get >>> link energy as low since they are free to transmit at highest >>> energy and not worry too much about power saving tricks. This >>> would be the opposite of >> what >>> you want, so obviously you combine link energy with available >>> energy. >>=20 >> I would not combine. >>=20 >> Combine was a poor choice of words on my part. I meant it >> uses both the link energy& node energy, and "combines" them to >> create a routing solution. So if you had separate link energy& node >> energy, figuring out how to use both of them would be a complex >> problem. >=20 > I agree using both node and link energy in a single metric would make = it > more complex. >=20 >>> Combining link energy with available energy would be incredibly >>> complex to get perfect. Worse if you do it wrong you end up with >>> the exact opposite >> of >>> what you want since low-power paths are used at the expense of >>> battery >> life. >>=20 >> What is battery life when birth and death is turning an engine >> on/off? Or when plugging the device on a docking. Or when plugging >> a vehicle on an outlet. >>=20 >>> At least there is some obvious connection between a simple >>> "available energy" value and "am I likely to be used to route a >>> packet". >>=20 >> Node energy helps it that way, yes. >>=20 >>> 4) Transmit energy also depends on link reliability for most >>> wireless networks, since they have an acknowledgment system. >>=20 >> Yes, retransmissions at link layer are a link layer problem, dealt >> with by power management of the link layer. IP stack cares about TCP >> retransmissions or above. >>=20 >>> Thus an unreliable link may actually take much more than the >>> expected power to transmit every >> frame, >>> since it's often doing retries. I would expect a few >>> retransmissions to basically nullify a lot of work selecting the >>> "most optimum" routes from >> an >>> energy perspective. >>=20 >> Hmmm... retransmissions may happen too for a node energy metric and >> that may nullify its effect too. >>=20 >> I don't mean retransmission of the metric, I just meant >> retransmissions in general. It's a question of all this overhead >> exchanging metrics to maintain a perfect route, when in the end you >> spent more time maintain your route than routing data! So I think >> for link energy to be 'accurate', you'd also need to keep the ETX >> object updated for example. >=20 > ETX has been so largely published and apparently implemented that I > can't disagree with it. However, I see it as a different metric than > the link energy metric. I guess one could use it differently than = using > an IP link energy metric. >=20 > I think ETX is good when considering particular wireless MAC layer, = but > wouldn't be useful to qualify other links in the Internet like fiber, > for example. It is very relevant for the MACs considered by LLNs, I think. >=20 > Alex >=20 >=20 >>=20 >>> 6) My conclusion from the above points is that the entire question >>> of >> RX/TX >>> power is too complex to bother doing perfectly in these networks. A >>> simplification that can at least be easily understood and specified >>> would >> be >>> more useful to everyone in the end than something that is more >>> complex and might not even work. >>=20 >> If we wish we could discuss separately the actual use of the existing >> node energy metric and I think it's not that simple either. >>=20 >>> Using such a metric DOES require external documents to specify how >>> the metric is used. But requiring external specification to work >>> out details seems inline with the rest of RPL so shouldn't be a >>> problem. >>>=20 >>> And if in the future I'm completely wrong and someone needs link >>> energy, I don't see a problem of fitting the link energy into a >>> TLV in the "node energy object". >>=20 >> I am happy to see openness to include link energy metric and I take >> note for future discussion. >>=20 >> But link energy is link energy not node energy. We saw it in the >> above mAmpere discussion where you eliminated the computing power to >> which I agreed; yet it doesn't make sense conceptually to put link >> energy into a node energy container. Link energy values are >> distinct from node energy values. >>=20 >> Alex >>=20 >>>=20 >>> Warm Regards, >>>=20 >>> -Colin O'Flynn >>>=20 >>>=20 >>> -----Original Message----- From: roll-bounces@ietf.org >>> [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: >>> September 18, 2010 5:11 PM To: Alexandru Petrescu Cc: roll@ietf.org >>> Subject: Re: [Roll] WG Last Call on >>> draft-ietf-roll-routing-metrics-09.txt >>>=20 >>>=20 >>> On Sep 17, 2010, at 3:12 PM, Alexandru Petrescu wrote: >>>=20 >>>> David, >>>>=20 >>>> Thanks for this Last Call on the RoLL routing metrics draft. >>>>=20 >>>> I reply now just to make sure I replied before the September >>>> 30th, 2010, the deadline Chair set and that I consider. >>>>=20 >>>> I have proposed last year to have energy link metrics: how much >>>> energy in Joules is required on a particular link to send >>>> 1280bytes as an IPv6 packet. >>>>=20 >>>> I have proposed this link metric also as an extension to the >>>> ripless draft-mulligan-roll-ripless-01. >>>>=20 >>>> In draft-ietf-roll-routing-metrics energy _is_ used as a metric >>>> but as node energy only, not link energy. >>>>=20 >>>> Link metrics _are_ considered in draft-ietf-roll-routing-metrics >>>> but not as energy. >>>>=20 >>>> Private discussion pointed me unilaterally I may be wrong but I >>>> think publicly I may be right. >>>>=20 >>>> I will send more comments later. >>>=20 >>> Alex, >>>=20 >>> Can you point me to an application requirements doc, or a concrete >>> application someone is building today, where link energy is >>> needed? Given the tremendous size and diversity of the industries >>> around LLNs, as well >> as >>> the application experience, I think our goal is to standardize >>> current practice rather than invent new mechanisms. >>>=20 >>> Phil _______________________________________________ Roll mailing >>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From c.chauvenet@watteco.com Mon Sep 20 03:16:14 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96F373A688A for ; Mon, 20 Sep 2010 03:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, HELO_EQ_FR=0.35, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFppFSyEFgu0 for ; Mon, 20 Sep 2010 03:16:11 -0700 (PDT) Received: from mail.abrisite.fr (mx197.abrisite.fr [85.31.209.197]) by core3.amsl.com (Postfix) with ESMTP id 52C4E3A6901 for ; Mon, 20 Sep 2010 03:16:08 -0700 (PDT) Received: from PCdePoste9 ([82.241.54.131]) by mail.abrisite.fr (POL Mail Securise v2.0) with ASMTP id CTK92129; Mon, 20 Sep 2010 12:16:29 +0200 Message-ID: <65A138E36AEC4C33A84FB9AE922D58D6@PCdePoste9> From: "Cedric Chauvenet" To: "Yoav Ben-Yehezkel" , "Alexandru Petrescu" , "Colin O'Flynn" References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu><006501cb5758$27f3aa90$77daffb0$@com> <4C9501C7.2060400@gmail.com><006b01cb577b$6c2f1550$448d3ff0$@com> <4C966485.3070206@gmail.com> In-Reply-To: Date: Mon, 20 Sep 2010 12:16:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18263 Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 20 Sep 2010 10:16:14 -0000 Hi all, I fully support PHY diversity in RPL networks. I also think it is pretty clear in WG drafts that we are not relying on particular PHY/MAC, so this diversity has been apporved by ROLL. Yoav pointed out very concrete usecases where Media diversity is needed. We can also think about Wireless nodes that would rely on a PLC backbone in a smart Home Context, to minimize Wireless hops and indeed the global energy consumption. PLC could also provide a suitable solution to cross Wireless barriers suh as metal. RPL PHY diversity has already been demonstrated during the first IPSO interop in march 2010, where a RPL network has been builded over 3 different media (802.15.4 RF, Ethernet and Low Power PLC). Regards, Cédric ----- Original Message ----- From: "Yoav Ben-Yehezkel" To: "Alexandru Petrescu" ; "Colin O'Flynn" Cc: Sent: Sunday, September 19, 2010 10:11 PM Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt Thanks Alex/Colin for bringing this up for discussion. My two cents: I always saw the ability to operate at multiple media as one of the strongest points in favor of RPL (and L3 routing protocols) over specific L1/2 bridging techniques. The smart grid will most probably need to operate using both PLC or wireless media for the same utility owned networks in some cases. Consider the typical Multiple Dwelling Unit (MDU) use case where wireless meters reside outside apartments in sealed cabinets, and in-home displays are installed inside the apartments. RF cannot pass thick walls, so a selection of an L3 router via a PLC node is a natural (from the cabinet to the home). Another use case is of course to connect a wireless battery operated sensor (say on the ceiling) with a PLC device that needs the sensor inputs (such as PCTs). These smart-grid devices "belong" to the same utility network or sub-network (though using different medias sometimes)... RPL (or any L3 routing protocol as I understand it) supported by multiple PHY layers seems to me like an excellent choice for covering these use cases while inherently taking the routing metric into consideration when choosing which media is the most suitable for the next transmission to the final destination. I am seeking for WG confirmation that these use cases are covered well by RPL (as a route over media and link layer agnostic protocol). Otherwise, I think this is a significant short-coming of the protocol. The WG thoughts are very much appreciated. Best regards, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: Sunday, September 19, 2010 9:29 PM To: Colin O'Flynn Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt [my summary: it is worth clarifying (1) whether RPL runs in a single PHY or multiple PHY network, and (2) whether metrics for RPL should be understood in RPL network only or more universal like across the Internet. There are also points about whether Rx link energy is as important as Tx link energy and its usability overall.] Hi Colin, It does make sense to clarify the usage model first, especially the assumptions of whether or not RPL runs exclusively on networks made of single PHY, or multiple PHYs. I consider IP kind of work (do we say IPv6? 'router'?) is needed only if we consider multiple kinds of PHYs in the same network. Otherwise bridges, range extenders and other L2 tools are better appropriate than IP routers. During RPL comments we commented whether RPL draft text should say _only_ 802.15.4 or would it include PLC too. I think RPL draft text saying _only_ 802.15.4 would make subsequent metrics and security text much easier. However, it was insisted PLC should be there in the draft. So I am in that perspective now. But does that mean that RPL runs only on a network consisting of PLC devices, and on another network of 15.4 devices (separated by an Edge Router)? Or does it mean RPL runs in a network mixing 15.4 devices with PLC devices each being an RPL router? This was never clear. Le 18/09/2010 23:49, Colin O'Flynn a écrit : > Hi Alex, > > I think we have some different assumptions about the usage model. It > would be useful to clarify some of that first. I'm not claiming my > assumptions are correct or consistent with the ROLL/RPL basis, these > are simply my view of how I imagined it would all fit together: > > 1) A single RPL network itself does not cross multiple PHY layers. > Crossing PHY layers would complicate the decision on "best routes" > partially for the reasons you mention. My comments before showing TX > power vs current was showing that for the same PHY layer you can > have a huge swing of TX power yet minimal impact on energy required > to transmit a packet (100x change in RF energy = less than 2x change > in total energy). (The energy used for transmission is the one measured by setting a highres ampermeter serially with the transmitting device, its battery and a shunt, make it send an IPv6 packet (type ping). That shows the energy used for transmission. This is just a rough view, but basically that is. There are related measurement tools like antena placed near emitter (the ones used to measure the DAS of mobile phones W/Kg).) > 2) Routing metrics are not universal, but will somewhat be > application-dependant. Thus you can change the metrics for different > nodes as required, and metrics might not make sense between > different RPL networks (this fits in with assumption #1). > > Thus my view was the metrics should be simple, as you hide any > required customization. If you want to select the outgoing interface > you have some artificial change in the metric, where the > administrator has basically forced the device to prefer interface 1 > over interface 2. Yes, the metric should be simple. The simplest relates much to what exists in terms of how IP routers select their output interface without artificial human intervention. > In your given example of an automotive system where they all work on > a common power source, the nodes have a specific routing metric > where a certain "fudge factor" has been worked into the different > nodes. Thus all other things being equal, the advertised metric of a > node which takes a lot of energy to transmit is made such that it is > less preferred over another node. > > I think you are assuming that (1) you can have different PHYs within > the RPL network, and (2) the routing metrics are more universal, so > you can compare two different RPL networks. Is this correct? Yes, right, that is my assumption: different PHYs within an RPL network and routing metrics more universal - they'd work within the RPL network and across the Internet (like the simple hopcount metric), and one could also compare different RPL networks. Do we want metrics that work _only_ within an RPL network? Or more universal like across the Internet? Or both? This is also a requirement discussion which is worth clarifying. > I've included some clarifications below as well (see ), > but I think the above two points are most important to understanding > why we may see such a wide difference of opinion. YEs, the above points about RPL running in a single PHY or multiple PHY network, and metric only worth in RPL or across the Internet, are important to clarify. > Regards, > > -Colin > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Sent: September 18, 2010 7:16 > PM To: Colin O'Flynn Cc: 'Philip Levis'; roll@ietf.org Subject: Re: > [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt > > Le 18/09/2010 19:37, Colin O'Flynn a écrit : >> Caveat emptor: I have not read the entire metrics-09 at this >> point, but wanted to comment anyway. >> >> I think the idea of "link energy" would be without much merit, of >> course > I'm >> open to being wrong. My reasoning is as follows: >> >> 1) There will not be much difference between the energy it takes >> to > transmit >> a packet within a RPL network. They will all be using similar link >> layers, > > Take a car: all devices are on a single unique battery, yet many > different copper, light and ether links in terms of energy needed. > > (in a car - how would a "battery" value of the metric which assumes > each IP addressable device has its own "battery" work with RPL? All > devices in the car are on the same unique battery, and sometimes on > car engine electricity generator. Add to this the Electric Vehicle > and you see.) > >> and much of the power of actually transmitting a packet is not >> related to > TX >> power but getting everything else up (such as CPU running& >> processing, > PLL >> being active and locked, CSMA being performed). > > That is right. Each transmitting device has CPU chipset to compute > wireless coding and that takes energy. That energy is in higher > orders of magnitude than actually transmitting. > > However the energy used to actual Tx (and Rx as in GPS devices) can > be clearly distinguished. > > I meant that you would then require information on both TX& RX > power if you wanted to be accurate. So you'd have to add more > metrics there, and add two values for every hop. Hmmm... that sounds right. To be better accurate about link energy metrics one would have to do both Tx metric and Rx metric. This could be done. I was thinking that presenting first the Tx link energy metric it would be easier to understand and then add the Rx metric too, naturally. >> As an example for one specific radio, the ATMega128RFA1, the >> values of current vs power output (from datasheet @ 3.0V): RX PWR >> | Supply 3dBm | 14.5mA 1dBm | 10mA -3dBm | 9mA -17dBm | 8mA >> >> Converting both to mW (= mJ/s) RX PWR | Supply 2.00 | 43.5 1.26 | >> 30 0.50 | 27 0.02 | 24 >> >> This is just current during active TX. > > That sounds exellent startpoint for design a link energy metric! To > eliminate the time paramter (mJ/s) to get to the J only we could > decide that we need to transmit 1280bytes of data - the IPv6 minimal > MTU. > >> There are some additional things that are TX power independent, >> but I think for any reasonable length 6LoWPAN packet they are much >> smaller than the values I have here. > > Are we IPv6 perspective or not. If yes IPv6 stack needs to know how > much energy is needed 1280bytes of data, a minimally sized IPv6 > packet. The stack reasons in terms of packets of that or larger > size. > > My example is 802.15.4/6LoWPAN specific, as that was just > 802.15.4 packets. I just meant for any reasonable size 802.15.4 > packet seen on a 6lowpan/IPv6 network you don't need to worry about > CSMA time for example, as it's fairly minimal by comparison. Well, IPv6 for 802.15.4 RFC says clearly this is minimal IPv6 MTU 1280bytes. I am not sure I understand why should IPv6 stack worry about smaller data-link packets but I have to dig this, e.g. see whether the linux stack does consider smaller than 1280bytes or not. >> 2) Receiving takes around the same amount of power as transmitting >> for > most >> 802.15.4 nodes. For the previously used example that is around >> 12mA in > fact. >> Thus the problem is not only TX power, but RX power. > > With GPS devices it is even truer, because they only receive. > >> How do you encapsulate that in "link energy" accurately? > > Well I proposed a metric bit encoding for it - should I send again? > > I looked back to I think may 2009 when I saw a discussion about > it, if it was before that I probably missed it. Ok, I will resend tomorrow an an example of encoding energy link metric for RA (it's on my office desktop). >> If you do it in simple ways with "fudge factors" you've probably >> lost enough accuracy to bother doing it at all. > > I don't propose fudge factors. > >> 3) Link energy on its own would result in selecting lowest energy >> paths I assume. Low power nodes which advertise smaller link >> energies have > probably >> gone to great lengths to get low link energies, since they have low >> available power. The nodes which are wall-powered won't try to get >> link energy as low since they are free to transmit at highest >> energy and not worry too much about power saving tricks. This >> would be the opposite of > what >> you want, so obviously you combine link energy with available >> energy. > > I would not combine. > > Combine was a poor choice of words on my part. I meant it > uses both the link energy& node energy, and "combines" them to > create a routing solution. So if you had separate link energy& node > energy, figuring out how to use both of them would be a complex > problem. I agree using both node and link energy in a single metric would make it more complex. >> Combining link energy with available energy would be incredibly >> complex to get perfect. Worse if you do it wrong you end up with >> the exact opposite > of >> what you want since low-power paths are used at the expense of >> battery > life. > > What is battery life when birth and death is turning an engine > on/off? Or when plugging the device on a docking. Or when plugging > a vehicle on an outlet. > >> At least there is some obvious connection between a simple >> "available energy" value and "am I likely to be used to route a >> packet". > > Node energy helps it that way, yes. > >> 4) Transmit energy also depends on link reliability for most >> wireless networks, since they have an acknowledgment system. > > Yes, retransmissions at link layer are a link layer problem, dealt > with by power management of the link layer. IP stack cares about TCP > retransmissions or above. > >> Thus an unreliable link may actually take much more than the >> expected power to transmit every > frame, >> since it's often doing retries. I would expect a few >> retransmissions to basically nullify a lot of work selecting the >> "most optimum" routes from > an >> energy perspective. > > Hmmm... retransmissions may happen too for a node energy metric and > that may nullify its effect too. > > I don't mean retransmission of the metric, I just meant > retransmissions in general. It's a question of all this overhead > exchanging metrics to maintain a perfect route, when in the end you > spent more time maintain your route than routing data! So I think > for link energy to be 'accurate', you'd also need to keep the ETX > object updated for example. ETX has been so largely published and apparently implemented that I can't disagree with it. However, I see it as a different metric than the link energy metric. I guess one could use it differently than using an IP link energy metric. I think ETX is good when considering particular wireless MAC layer, but wouldn't be useful to qualify other links in the Internet like fiber, for example. It is very relevant for the MACs considered by LLNs, I think. Alex > >> 6) My conclusion from the above points is that the entire question >> of > RX/TX >> power is too complex to bother doing perfectly in these networks. A >> simplification that can at least be easily understood and specified >> would > be >> more useful to everyone in the end than something that is more >> complex and might not even work. > > If we wish we could discuss separately the actual use of the existing > node energy metric and I think it's not that simple either. > >> Using such a metric DOES require external documents to specify how >> the metric is used. But requiring external specification to work >> out details seems inline with the rest of RPL so shouldn't be a >> problem. >> >> And if in the future I'm completely wrong and someone needs link >> energy, I don't see a problem of fitting the link energy into a >> TLV in the "node energy object". > > I am happy to see openness to include link energy metric and I take > note for future discussion. > > But link energy is link energy not node energy. We saw it in the > above mAmpere discussion where you eliminated the computing power to > which I agreed; yet it doesn't make sense conceptually to put link > energy into a node energy container. Link energy values are > distinct from node energy values. > > Alex > >> >> Warm Regards, >> >> -Colin O'Flynn >> >> >> -----Original Message----- From: roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: >> September 18, 2010 5:11 PM To: Alexandru Petrescu Cc: roll@ietf.org >> Subject: Re: [Roll] WG Last Call on >> draft-ietf-roll-routing-metrics-09.txt >> >> >> On Sep 17, 2010, at 3:12 PM, Alexandru Petrescu wrote: >> >>> David, >>> >>> Thanks for this Last Call on the RoLL routing metrics draft. >>> >>> I reply now just to make sure I replied before the September >>> 30th, 2010, the deadline Chair set and that I consider. >>> >>> I have proposed last year to have energy link metrics: how much >>> energy in Joules is required on a particular link to send >>> 1280bytes as an IPv6 packet. >>> >>> I have proposed this link metric also as an extension to the >>> ripless draft-mulligan-roll-ripless-01. >>> >>> In draft-ietf-roll-routing-metrics energy _is_ used as a metric >>> but as node energy only, not link energy. >>> >>> Link metrics _are_ considered in draft-ietf-roll-routing-metrics >>> but not as energy. >>> >>> Private discussion pointed me unilaterally I may be wrong but I >>> think publicly I may be right. >>> >>> I will send more comments later. >> >> Alex, >> >> Can you point me to an application requirements doc, or a concrete >> application someone is building today, where link energy is >> needed? Given the tremendous size and diversity of the industries >> around LLNs, as well > as >> the application experience, I think our goal is to standardize >> current practice rather than invent new mechanisms. >> >> Phil _______________________________________________ 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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Mon Sep 20 08:04:52 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2AD93A69D2 for ; Mon, 20 Sep 2010 08:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.412 X-Spam-Level: X-Spam-Status: No, score=-110.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edISNSOdklLw for ; Mon, 20 Sep 2010 08:04:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 90DDE3A6948 for ; Mon, 20 Sep 2010 08:04:49 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHIVl0yQ/khN/2dsb2JhbACiFnGlVpwJgnOCTgSKOIMEglw X-IronPort-AV: E=Sophos;i="4.56,394,1280707200"; d="scan'208";a="64754391" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 20 Sep 2010 15:05:12 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o8KF5CFt023511; Mon, 20 Sep 2010 15:05:12 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Sep 2010 17:05:12 +0200 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Sep 2010 17:05:11 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: JP Vasseur X-Priority: 3 In-Reply-To: <65A138E36AEC4C33A84FB9AE922D58D6@PCdePoste9> Date: Mon, 20 Sep 2010 17:05:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5B535024-4A56-44AD-AC91-62B0984A8F38@cisco.com> References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu><006501cb5758$27f3aa90$77daffb0$@com> <4C9501C7.2060400@gmail.com><006b01cb577b$6c2f1550$448d3ff0$@com> <4C966485.3070206@gmail.com> <65A138E36AEC4C33A84FB9AE922D58D6@PCdePoste9> To: Cedric Chauvenet X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 20 Sep 2010 15:05:11.0573 (UTC) FILETIME=[38E0DC50:01CB58D5] Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 20 Sep 2010 15:04:52 -0000 Yes I do not even know why the topic was brought up. RPL is a L3 protocol. JP. On Sep 20, 2010, at 12:16 PM, Cedric Chauvenet wrote: > Hi all, >=20 > I fully support PHY diversity in RPL networks. > I also think it is pretty clear in WG drafts that we are not relying = on particular PHY/MAC, so this diversity has been apporved by ROLL. >=20 > Yoav pointed out very concrete usecases where Media diversity is = needed. > We can also think about Wireless nodes that would rely on a PLC = backbone in a smart Home Context, to minimize Wireless hops and indeed = the global energy consumption. > PLC could also provide a suitable solution to cross Wireless barriers = suh as metal. >=20 > RPL PHY diversity has already been demonstrated during the first IPSO = interop in march 2010, where a RPL network has been builded over 3 = different media (802.15.4 RF, Ethernet and Low Power PLC). >=20 > Regards, > C=E9dric >=20 > ----- Original Message ----- From: "Yoav Ben-Yehezkel" = > To: "Alexandru Petrescu" ; "Colin = O'Flynn" > Cc: > Sent: Sunday, September 19, 2010 10:11 PM > Subject: Re: [Roll] WG Last Call on = draft-ietf-roll-routing-metrics-09.txt >=20 >=20 > Thanks Alex/Colin for bringing this up for discussion. >=20 > My two cents: >=20 > I always saw the ability to operate at multiple media as one of the > strongest points in favor of RPL (and L3 routing protocols) over = specific > L1/2 bridging techniques. >=20 > The smart grid will most probably need to operate using both PLC or > wireless media for the same utility owned networks in some cases. >=20 > Consider the typical Multiple Dwelling Unit (MDU) use case where = wireless > meters reside outside apartments in sealed cabinets, and in-home = displays > are installed inside the apartments. RF cannot pass thick walls, so a > selection of an L3 router via a PLC node is a natural (from the = cabinet to > the home). >=20 > Another use case is of course to connect a wireless battery operated > sensor (say on the ceiling) with a PLC device that needs the sensor = inputs > (such as PCTs). >=20 > These smart-grid devices "belong" to the same utility network or > sub-network (though using different medias sometimes)... >=20 > RPL (or any L3 routing protocol as I understand it) supported by = multiple > PHY layers seems to me like an excellent choice for covering these use > cases while inherently taking the routing metric into consideration = when > choosing which media is the most suitable for the next transmission to = the > final destination. >=20 > I am seeking for WG confirmation that these use cases are covered well = by > RPL (as a route over media and link layer agnostic protocol). = Otherwise, I > think this is a significant short-coming of the protocol. >=20 > The WG thoughts are very much appreciated. >=20 > Best regards, > Yoav >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of > Alexandru Petrescu > Sent: Sunday, September 19, 2010 9:29 PM > To: Colin O'Flynn > Cc: roll@ietf.org > Subject: Re: [Roll] WG Last Call on = draft-ietf-roll-routing-metrics-09.txt >=20 > [my summary: it is worth clarifying (1) whether RPL runs in a single > PHY or multiple PHY network, and (2) whether metrics for RPL should be > understood in RPL network only or more universal like across the > Internet. There are also points about whether Rx link energy is as > important as Tx link energy and its usability overall.] >=20 > Hi Colin, >=20 > It does make sense to clarify the usage model first, especially the > assumptions of whether or not RPL runs exclusively on networks made of > single PHY, or multiple PHYs. >=20 > I consider IP kind of work (do we say IPv6? 'router'?) is needed only = if > we consider multiple kinds of PHYs in the same network. Otherwise > bridges, range extenders and other L2 tools are better appropriate = than > IP routers. >=20 > During RPL comments we commented whether RPL draft text should say > _only_ 802.15.4 or would it include PLC too. I think RPL draft text > saying _only_ 802.15.4 would make subsequent metrics and security text > much easier. However, it was insisted PLC should be there in the = draft. > So I am in that perspective now. >=20 > But does that mean that RPL runs only on a network consisting of PLC > devices, and on another network of 15.4 devices (separated by an Edge > Router)? Or does it mean RPL runs in a network mixing 15.4 devices > with PLC devices each being an RPL router? >=20 > This was never clear. >=20 > Le 18/09/2010 23:49, Colin O'Flynn a =E9crit : >> Hi Alex, >>=20 >> I think we have some different assumptions about the usage model. It >> would be useful to clarify some of that first. I'm not claiming my >> assumptions are correct or consistent with the ROLL/RPL basis, these >> are simply my view of how I imagined it would all fit together: >>=20 >> 1) A single RPL network itself does not cross multiple PHY layers. >> Crossing PHY layers would complicate the decision on "best routes" >> partially for the reasons you mention. My comments before showing TX >> power vs current was showing that for the same PHY layer you can >> have a huge swing of TX power yet minimal impact on energy required >> to transmit a packet (100x change in RF energy =3D less than 2x = change >> in total energy). >=20 > (The energy used for transmission is the one measured by setting a > highres ampermeter serially with the transmitting device, its battery > and a shunt, make it send an IPv6 packet (type ping). That shows the > energy used for transmission. This is just a rough view, but = basically > that is. There are related measurement tools like antena placed near > emitter (the ones used to measure the DAS of mobile phones W/Kg).) >=20 >> 2) Routing metrics are not universal, but will somewhat be >> application-dependant. Thus you can change the metrics for different >> nodes as required, and metrics might not make sense between >> different RPL networks (this fits in with assumption #1). >>=20 >> Thus my view was the metrics should be simple, as you hide any >> required customization. If you want to select the outgoing interface >> you have some artificial change in the metric, where the >> administrator has basically forced the device to prefer interface 1 >> over interface 2. >=20 > Yes, the metric should be simple. The simplest relates much to what > exists in terms of how IP routers select their output interface = without > artificial human intervention. >=20 >> In your given example of an automotive system where they all work on >> a common power source, the nodes have a specific routing metric >> where a certain "fudge factor" has been worked into the different >> nodes. Thus all other things being equal, the advertised metric of a >> node which takes a lot of energy to transmit is made such that it is >> less preferred over another node. >>=20 >> I think you are assuming that (1) you can have different PHYs within >> the RPL network, and (2) the routing metrics are more universal, so >> you can compare two different RPL networks. Is this correct? >=20 > Yes, right, that is my assumption: different PHYs within an RPL = network > and routing metrics more universal - they'd work within the RPL = network > and across the Internet (like the simple hopcount metric), and one = could > also compare different RPL networks. >=20 > Do we want metrics that work _only_ within an RPL network? Or more > universal like across the Internet? Or both? This is also a > requirement discussion which is worth clarifying. >=20 >> I've included some clarifications below as well (see ), >> but I think the above two points are most important to understanding >> why we may see such a wide difference of opinion. >=20 > YEs, the above points about RPL running in a single PHY or multiple = PHY > network, and metric only worth in RPL or across the Internet, are > important to clarify. >=20 >> Regards, >>=20 >> -Colin >>=20 >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: September 18, 2010 7:16 >> PM To: Colin O'Flynn Cc: 'Philip Levis'; roll@ietf.org Subject: Re: >> [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt >>=20 >> Le 18/09/2010 19:37, Colin O'Flynn a =E9crit : >>> Caveat emptor: I have not read the entire metrics-09 at this >>> point, but wanted to comment anyway. >>>=20 >>> I think the idea of "link energy" would be without much merit, of >>> course >> I'm >>> open to being wrong. My reasoning is as follows: >>>=20 >>> 1) There will not be much difference between the energy it takes >>> to >> transmit >>> a packet within a RPL network. They will all be using similar link >>> layers, >>=20 >> Take a car: all devices are on a single unique battery, yet many >> different copper, light and ether links in terms of energy needed. >>=20 >> (in a car - how would a "battery" value of the metric which assumes >> each IP addressable device has its own "battery" work with RPL? All >> devices in the car are on the same unique battery, and sometimes on >> car engine electricity generator. Add to this the Electric Vehicle >> and you see.) >>=20 >>> and much of the power of actually transmitting a packet is not >>> related to >> TX >>> power but getting everything else up (such as CPU running& >>> processing, >> PLL >>> being active and locked, CSMA being performed). >>=20 >> That is right. Each transmitting device has CPU chipset to compute >> wireless coding and that takes energy. That energy is in higher >> orders of magnitude than actually transmitting. >>=20 >> However the energy used to actual Tx (and Rx as in GPS devices) can >> be clearly distinguished. >>=20 >> I meant that you would then require information on both TX& RX >> power if you wanted to be accurate. So you'd have to add more >> metrics there, and add two values for every hop. >=20 > Hmmm... that sounds right. To be better accurate about link energy > metrics one would have to do both Tx metric and Rx metric. This could > be done. I was thinking that presenting first the Tx link energy = metric > it would be easier to understand and then add the Rx metric too, > naturally. >=20 >>> As an example for one specific radio, the ATMega128RFA1, the >>> values of current vs power output (from datasheet @ 3.0V): RX PWR >>> | Supply 3dBm | 14.5mA 1dBm | 10mA -3dBm | 9mA -17dBm | 8mA >>>=20 >>> Converting both to mW (=3D mJ/s) RX PWR | Supply 2.00 | 43.5 1.26 = | >>> 30 0.50 | 27 0.02 | 24 >>>=20 >>> This is just current during active TX. >>=20 >> That sounds exellent startpoint for design a link energy metric! To >> eliminate the time paramter (mJ/s) to get to the J only we could >> decide that we need to transmit 1280bytes of data - the IPv6 minimal >> MTU. >>=20 >>> There are some additional things that are TX power independent, >>> but I think for any reasonable length 6LoWPAN packet they are much >>> smaller than the values I have here. >>=20 >> Are we IPv6 perspective or not. If yes IPv6 stack needs to know how >> much energy is needed 1280bytes of data, a minimally sized IPv6 >> packet. The stack reasons in terms of packets of that or larger >> size. >>=20 >> My example is 802.15.4/6LoWPAN specific, as that was just >> 802.15.4 packets. I just meant for any reasonable size 802.15.4 >> packet seen on a 6lowpan/IPv6 network you don't need to worry about >> CSMA time for example, as it's fairly minimal by comparison. >=20 > Well, IPv6 for 802.15.4 RFC says clearly this is minimal IPv6 MTU > 1280bytes. I am not sure I understand why should IPv6 stack worry = about > smaller data-link packets but I have to dig this, e.g. see whether the > linux stack does consider smaller than 1280bytes or not. >=20 >>> 2) Receiving takes around the same amount of power as transmitting >>> for >> most >>> 802.15.4 nodes. For the previously used example that is around >>> 12mA in >> fact. >>> Thus the problem is not only TX power, but RX power. >>=20 >> With GPS devices it is even truer, because they only receive. >>=20 >>> How do you encapsulate that in "link energy" accurately? >>=20 >> Well I proposed a metric bit encoding for it - should I send again? >>=20 >> I looked back to I think may 2009 when I saw a discussion about >> it, if it was before that I probably missed it. >=20 > Ok, I will resend tomorrow an an example of encoding energy link = metric > for RA (it's on my office desktop). >=20 >>> If you do it in simple ways with "fudge factors" you've probably >>> lost enough accuracy to bother doing it at all. >>=20 >> I don't propose fudge factors. >>=20 >>> 3) Link energy on its own would result in selecting lowest energy >>> paths I assume. Low power nodes which advertise smaller link >>> energies have >> probably >>> gone to great lengths to get low link energies, since they have low >>> available power. The nodes which are wall-powered won't try to get >>> link energy as low since they are free to transmit at highest >>> energy and not worry too much about power saving tricks. This >>> would be the opposite of >> what >>> you want, so obviously you combine link energy with available >>> energy. >>=20 >> I would not combine. >>=20 >> Combine was a poor choice of words on my part. I meant it >> uses both the link energy& node energy, and "combines" them to >> create a routing solution. So if you had separate link energy& node >> energy, figuring out how to use both of them would be a complex >> problem. >=20 > I agree using both node and link energy in a single metric would make = it > more complex. >=20 >>> Combining link energy with available energy would be incredibly >>> complex to get perfect. Worse if you do it wrong you end up with >>> the exact opposite >> of >>> what you want since low-power paths are used at the expense of >>> battery >> life. >>=20 >> What is battery life when birth and death is turning an engine >> on/off? Or when plugging the device on a docking. Or when plugging >> a vehicle on an outlet. >>=20 >>> At least there is some obvious connection between a simple >>> "available energy" value and "am I likely to be used to route a >>> packet". >>=20 >> Node energy helps it that way, yes. >>=20 >>> 4) Transmit energy also depends on link reliability for most >>> wireless networks, since they have an acknowledgment system. >>=20 >> Yes, retransmissions at link layer are a link layer problem, dealt >> with by power management of the link layer. IP stack cares about TCP >> retransmissions or above. >>=20 >>> Thus an unreliable link may actually take much more than the >>> expected power to transmit every >> frame, >>> since it's often doing retries. I would expect a few >>> retransmissions to basically nullify a lot of work selecting the >>> "most optimum" routes from >> an >>> energy perspective. >>=20 >> Hmmm... retransmissions may happen too for a node energy metric and >> that may nullify its effect too. >>=20 >> I don't mean retransmission of the metric, I just meant >> retransmissions in general. It's a question of all this overhead >> exchanging metrics to maintain a perfect route, when in the end you >> spent more time maintain your route than routing data! So I think >> for link energy to be 'accurate', you'd also need to keep the ETX >> object updated for example. >=20 > ETX has been so largely published and apparently implemented that I > can't disagree with it. However, I see it as a different metric than > the link energy metric. I guess one could use it differently than = using > an IP link energy metric. >=20 > I think ETX is good when considering particular wireless MAC layer, = but > wouldn't be useful to qualify other links in the Internet like fiber, > for example. It is very relevant for the MACs considered by LLNs, I > think. >=20 > Alex >=20 >=20 >>=20 >>> 6) My conclusion from the above points is that the entire question >>> of >> RX/TX >>> power is too complex to bother doing perfectly in these networks. A >>> simplification that can at least be easily understood and specified >>> would >> be >>> more useful to everyone in the end than something that is more >>> complex and might not even work. >>=20 >> If we wish we could discuss separately the actual use of the existing >> node energy metric and I think it's not that simple either. >>=20 >>> Using such a metric DOES require external documents to specify how >>> the metric is used. But requiring external specification to work >>> out details seems inline with the rest of RPL so shouldn't be a >>> problem. >>>=20 >>> And if in the future I'm completely wrong and someone needs link >>> energy, I don't see a problem of fitting the link energy into a >>> TLV in the "node energy object". >>=20 >> I am happy to see openness to include link energy metric and I take >> note for future discussion. >>=20 >> But link energy is link energy not node energy. We saw it in the >> above mAmpere discussion where you eliminated the computing power to >> which I agreed; yet it doesn't make sense conceptually to put link >> energy into a node energy container. Link energy values are >> distinct from node energy values. >>=20 >> Alex >>=20 >>>=20 >>> Warm Regards, >>>=20 >>> -Colin O'Flynn >>>=20 >>>=20 >>> -----Original Message----- From: roll-bounces@ietf.org >>> [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: >>> September 18, 2010 5:11 PM To: Alexandru Petrescu Cc: roll@ietf.org >>> Subject: Re: [Roll] WG Last Call on >>> draft-ietf-roll-routing-metrics-09.txt >>>=20 >>>=20 >>> On Sep 17, 2010, at 3:12 PM, Alexandru Petrescu wrote: >>>=20 >>>> David, >>>>=20 >>>> Thanks for this Last Call on the RoLL routing metrics draft. >>>>=20 >>>> I reply now just to make sure I replied before the September >>>> 30th, 2010, the deadline Chair set and that I consider. >>>>=20 >>>> I have proposed last year to have energy link metrics: how much >>>> energy in Joules is required on a particular link to send >>>> 1280bytes as an IPv6 packet. >>>>=20 >>>> I have proposed this link metric also as an extension to the >>>> ripless draft-mulligan-roll-ripless-01. >>>>=20 >>>> In draft-ietf-roll-routing-metrics energy _is_ used as a metric >>>> but as node energy only, not link energy. >>>>=20 >>>> Link metrics _are_ considered in draft-ietf-roll-routing-metrics >>>> but not as energy. >>>>=20 >>>> Private discussion pointed me unilaterally I may be wrong but I >>>> think publicly I may be right. >>>>=20 >>>> I will send more comments later. >>>=20 >>> Alex, >>>=20 >>> Can you point me to an application requirements doc, or a concrete >>> application someone is building today, where link energy is >>> needed? Given the tremendous size and diversity of the industries >>> around LLNs, as well >> as >>> the application experience, I think our goal is to standardize >>> current practice rather than invent new mechanisms. >>>=20 >>> Phil _______________________________________________ Roll mailing >>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > 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=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From remi.despres@free.fr Sat Sep 18 07:52:41 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1A603A657C; Sat, 18 Sep 2010 07:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.64 X-Spam-Level: X-Spam-Status: No, score=-1.64 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqAFS6fq3ZyF; Sat, 18 Sep 2010 07:52:41 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by core3.amsl.com (Postfix) with ESMTP id C674E3A694F; Sat, 18 Sep 2010 07:52:39 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2209.sfr.fr (SMTP Server) with ESMTP id F03B1700008C; Sat, 18 Sep 2010 16:53:02 +0200 (CEST) Received: from [192.168.1.29] (unknown [89.170.204.31]) by msfrf2209.sfr.fr (SMTP Server) with ESMTP id 7C20F700008D; Sat, 18 Sep 2010 16:53:02 +0200 (CEST) X-SFR-UUID: 20100918145302508.7C20F700008D@msfrf2209.sfr.fr Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Sat, 18 Sep 2010 16:53:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com> <4C9030FF.6060302@oracle.com> To: JP Vasseur X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Mon, 20 Sep 2010 08:05:12 -0700 Cc: IPv6 WG , ROLL WG Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 18 Sep 2010 14:52:42 -0000 Le 18 sept. 2010 =E0 02:22, JP Vasseur a =E9crit : > On Sep 15, 2010, at 8:51 AM, Carsten Bormann wrote: > ... >>=20 >> However, it would be pretty easy to put something in 6lowpan to carry = those 3 bytes. >> (Consider it an advanced form of header compression for the 48-byte = IP-in-IP thing, if you don't like the sub-IP thinking.) >> Consult http://tools.ietf.org/html/draft-bormann-6lowpan-ext-hdr-00 = for a sample base design. >> Such a simple extension may actually be a preferable way to carry = ROLL in 6lowpan. >=20 > "preferable" in which sense ? At least, IMHO, in that it eliminates the motivation to interfere with = the current discussion on improving flow-label utilization. Regards, RD From root@core3.amsl.com Mon Sep 20 08:45:45 2010 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 533023A6AA9; Mon, 20 Sep 2010 08:45:10 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100920154542.533023A6AA9@core3.amsl.com> Date: Mon, 20 Sep 2010 08:45:11 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-terminology-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 20 Sep 2010 15:45:45 -0000 --NextPart 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 : Terminology in Low power And Lossy Networks Author(s) : J. Vasseur Filename : draft-ietf-roll-terminology-04.txt Pages : 8 Date : 2010-09-20 The documents defines a terminology for discussing routing requirements and solutions for networks referred to as Low power and Lossy Networks (LLN). A LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g. Heating, Ventilating, Air Conditioning, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking, refrigeration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-terminology-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-terminology-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-09-20083603.I-D@ietf.org> --NextPart-- From jpv@cisco.com Mon Sep 20 08:57:17 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE3A3A69A4 for ; Mon, 20 Sep 2010 08:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.412 X-Spam-Level: X-Spam-Status: No, score=-110.412 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4lR2jthbPoj for ; Mon, 20 Sep 2010 08:57:16 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 01D673A6988 for ; Mon, 20 Sep 2010 08:57:15 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkLAO8gl0yrR7Ht/2dsb2JhbACaHocdW3GmPJwRhUEEijiDBA X-IronPort-AV: E=Sophos;i="4.56,394,1280707200"; d="scan'208,217";a="189181424" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 20 Sep 2010 15:57:39 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o8KFvD6b024504 for ; Mon, 20 Sep 2010 15:57:39 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Sep 2010 17:57:14 +0200 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Sep 2010 17:57:13 +0200 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-16--399128315 Date: Mon, 20 Sep 2010 17:57:13 +0200 References: <20100920154542.533023A6AA9@core3.amsl.com> To: ROLL WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 20 Sep 2010 15:57:13.0826 (UTC) FILETIME=[7DE2DC20:01CB58DC] Subject: [Roll] Fwd: I-D Action:draft-ietf-roll-terminology-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 20 Sep 2010 15:57:17 -0000 --Apple-Mail-16--399128315 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just a refresh. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: September 20, 2010 5:45:11 PM GMT+02:00 > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: [Roll] I-D Action:draft-ietf-roll-terminology-04.txt >=20 > 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. >=20 >=20 > Title : Terminology in Low power And Lossy Networks > Author(s) : J. Vasseur > Filename : draft-ietf-roll-terminology-04.txt > Pages : 8 > Date : 2010-09-20 >=20 > The documents defines a terminology for discussing routing > requirements and solutions for networks referred to as Low power and > Lossy Networks (LLN). A LLN is typically composed of many embedded > devices with limited power, memory, and processing resources > interconnected by a variety of links. There is a wide scope of > application areas for LLNs, including industrial monitoring, building > automation (e.g. Heating, Ventilating, Air Conditioning, lighting, > access control, fire), connected home, healthcare, environmental > monitoring, urban sensor networks, energy management, assets > tracking, refrigeration. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-terminology-04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-16--399128315 Content-Type: multipart/mixed; boundary=Apple-Mail-17--399128314 --Apple-Mail-17--399128314 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Just = a refresh.


Begin forwarded message:

Date: September 20, 2010 5:45:11 PM = GMT+02:00
Subject: [Roll] I-D = Action:draft-ietf-roll-terminology-04.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 =           : = Terminology in Low power And Lossy Networks
Author(s) =       : J. Vasseur
Filename =        : = draft-ietf-roll-terminology-04.txt
Pages =           : 8
Date =            : = 2010-09-20

The documents defines a terminology for discussing = routing
requirements and solutions for networks referred to as Low = power and
Lossy Networks (LLN).  A LLN is typically composed of = many embedded
devices with limited power, memory, and processing = resources
interconnected by a variety of links.  There is a wide = scope of
application areas for LLNs, including industrial monitoring, = building
automation (e.g.  Heating, Ventilating, Air = Conditioning, lighting,
access control, fire), connected home, = healthcare, environmental
monitoring, urban sensor networks, energy = management, assets
tracking, refrigeration.

A URL for this = Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-terminology-04.t= xt

Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data = which will enable a MIME compliant mail reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-17--399128314 Content-Disposition: attachment; filename="Mail Attachment" Content-Type: message/external-body; name="Mail Attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2010-09-20083603.I-D@ietf.org>

--Apple-Mail-17--399128314 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

--Apple-Mail-17--399128314-- --Apple-Mail-16--399128315-- From yoav@yitran.com Mon Sep 20 10:10:36 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C04B3A69F1 for ; Mon, 20 Sep 2010 10:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cR6NBPQcvzac for ; Mon, 20 Sep 2010 10:10:29 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) by core3.amsl.com (Postfix) with SMTP id 001E33A6AB6 for ; Mon, 20 Sep 2010 10:10:27 -0700 (PDT) Received: from source ([209.85.214.45]) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKTJeVk6wS4AAzF6N+RXcv2ZW5GvHhB2EU@postini.com; Mon, 20 Sep 2010 10:10:52 PDT Received: by mail-bw0-f45.google.com with SMTP id 4so4763050bwz.32 for ; Mon, 20 Sep 2010 10:10:43 -0700 (PDT) Received: by 10.204.61.133 with SMTP id t5mr7160458bkh.4.1285002643359; Mon, 20 Sep 2010 10:10:43 -0700 (PDT) From: Yoav Ben-Yehezkel References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu><006501cb5758$27f3aa90$77daffb0$@com> <4C9501C7.2060400@gmail.com><006b01cb577b$6c2f1550$448d3ff0$@com> <4C966485.3070206@gmail.com> <65A138E36AEC4C33A84FB9AE922D58D6@PCdePoste9> <5B535024-4A56-44AD-AC91-62B0984A8F38@cisco.com> In-Reply-To: <5B535024-4A56-44AD-AC91-62B0984A8F38@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActY1UISO6xKJ0N9T1ujj6b6aKydUgAEV7eQ Date: Mon, 20 Sep 2010 19:10:41 +0200 Message-ID: To: JP Vasseur , Cedric Chauvenet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 20 Sep 2010 17:10:36 -0000 JP, Have a look at the earlier email from Colin, he's raising an interesting point. It's not about PHY diversity, it's about energy metrics in the cases of multiple media. Thanks, Yoav -----Original Message----- From: JP Vasseur [mailto:jpv@cisco.com] Sent: Monday, September 20, 2010 5:05 PM To: Cedric Chauvenet Cc: Yoav Ben-Yehezkel; Alexandru Petrescu; Colin O'Flynn; roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt Yes I do not even know why the topic was brought up. RPL is a L3 protocol. JP. On Sep 20, 2010, at 12:16 PM, Cedric Chauvenet wrote: > Hi all, > > I fully support PHY diversity in RPL networks. > I also think it is pretty clear in WG drafts that we are not relying on particular PHY/MAC, so this diversity has been apporved by ROLL. > > Yoav pointed out very concrete usecases where Media diversity is needed. > We can also think about Wireless nodes that would rely on a PLC backbone in a smart Home Context, to minimize Wireless hops and indeed the global energy consumption. > PLC could also provide a suitable solution to cross Wireless barriers suh as metal. > > RPL PHY diversity has already been demonstrated during the first IPSO interop in march 2010, where a RPL network has been builded over 3 different media (802.15.4 RF, Ethernet and Low Power PLC). > > Regards, > C=E9dric > > ----- Original Message ----- From: "Yoav Ben-Yehezkel" > To: "Alexandru Petrescu" ; "Colin O'Flynn" > Cc: > Sent: Sunday, September 19, 2010 10:11 PM > Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt > > > Thanks Alex/Colin for bringing this up for discussion. > > My two cents: > > I always saw the ability to operate at multiple media as one of the > strongest points in favor of RPL (and L3 routing protocols) over specific > L1/2 bridging techniques. > > The smart grid will most probably need to operate using both PLC or > wireless media for the same utility owned networks in some cases. > > Consider the typical Multiple Dwelling Unit (MDU) use case where wireless > meters reside outside apartments in sealed cabinets, and in-home displays > are installed inside the apartments. RF cannot pass thick walls, so a > selection of an L3 router via a PLC node is a natural (from the cabinet to > the home). > > Another use case is of course to connect a wireless battery operated > sensor (say on the ceiling) with a PLC device that needs the sensor inputs > (such as PCTs). > > These smart-grid devices "belong" to the same utility network or > sub-network (though using different medias sometimes)... > > RPL (or any L3 routing protocol as I understand it) supported by multiple > PHY layers seems to me like an excellent choice for covering these use > cases while inherently taking the routing metric into consideration when > choosing which media is the most suitable for the next transmission to the > final destination. > > I am seeking for WG confirmation that these use cases are covered well by > RPL (as a route over media and link layer agnostic protocol). Otherwise, I > think this is a significant short-coming of the protocol. > > The WG thoughts are very much appreciated. > > Best regards, > Yoav > > > > > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: Sunday, September 19, 2010 9:29 PM > To: Colin O'Flynn > Cc: roll@ietf.org > Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt > > [my summary: it is worth clarifying (1) whether RPL runs in a single > PHY or multiple PHY network, and (2) whether metrics for RPL should be > understood in RPL network only or more universal like across the > Internet. There are also points about whether Rx link energy is as > important as Tx link energy and its usability overall.] > > Hi Colin, > > It does make sense to clarify the usage model first, especially the > assumptions of whether or not RPL runs exclusively on networks made of > single PHY, or multiple PHYs. > > I consider IP kind of work (do we say IPv6? 'router'?) is needed only if > we consider multiple kinds of PHYs in the same network. Otherwise > bridges, range extenders and other L2 tools are better appropriate than > IP routers. > > During RPL comments we commented whether RPL draft text should say > _only_ 802.15.4 or would it include PLC too. I think RPL draft text > saying _only_ 802.15.4 would make subsequent metrics and security text > much easier. However, it was insisted PLC should be there in the draft. > So I am in that perspective now. > > But does that mean that RPL runs only on a network consisting of PLC > devices, and on another network of 15.4 devices (separated by an Edge > Router)? Or does it mean RPL runs in a network mixing 15.4 devices > with PLC devices each being an RPL router? > > This was never clear. > > Le 18/09/2010 23:49, Colin O'Flynn a =E9crit : >> Hi Alex, >> >> I think we have some different assumptions about the usage model. It >> would be useful to clarify some of that first. I'm not claiming my >> assumptions are correct or consistent with the ROLL/RPL basis, these >> are simply my view of how I imagined it would all fit together: >> >> 1) A single RPL network itself does not cross multiple PHY layers. >> Crossing PHY layers would complicate the decision on "best routes" >> partially for the reasons you mention. My comments before showing TX >> power vs current was showing that for the same PHY layer you can >> have a huge swing of TX power yet minimal impact on energy required >> to transmit a packet (100x change in RF energy =3D less than 2x change >> in total energy). > > (The energy used for transmission is the one measured by setting a > highres ampermeter serially with the transmitting device, its battery > and a shunt, make it send an IPv6 packet (type ping). That shows the > energy used for transmission. This is just a rough view, but basically > that is. There are related measurement tools like antena placed near > emitter (the ones used to measure the DAS of mobile phones W/Kg).) > >> 2) Routing metrics are not universal, but will somewhat be >> application-dependant. Thus you can change the metrics for different >> nodes as required, and metrics might not make sense between >> different RPL networks (this fits in with assumption #1). >> >> Thus my view was the metrics should be simple, as you hide any >> required customization. If you want to select the outgoing interface >> you have some artificial change in the metric, where the >> administrator has basically forced the device to prefer interface 1 >> over interface 2. > > Yes, the metric should be simple. The simplest relates much to what > exists in terms of how IP routers select their output interface without > artificial human intervention. > >> In your given example of an automotive system where they all work on >> a common power source, the nodes have a specific routing metric >> where a certain "fudge factor" has been worked into the different >> nodes. Thus all other things being equal, the advertised metric of a >> node which takes a lot of energy to transmit is made such that it is >> less preferred over another node. >> >> I think you are assuming that (1) you can have different PHYs within >> the RPL network, and (2) the routing metrics are more universal, so >> you can compare two different RPL networks. Is this correct? > > Yes, right, that is my assumption: different PHYs within an RPL network > and routing metrics more universal - they'd work within the RPL network > and across the Internet (like the simple hopcount metric), and one could > also compare different RPL networks. > > Do we want metrics that work _only_ within an RPL network? Or more > universal like across the Internet? Or both? This is also a > requirement discussion which is worth clarifying. > >> I've included some clarifications below as well (see ), >> but I think the above two points are most important to understanding >> why we may see such a wide difference of opinion. > > YEs, the above points about RPL running in a single PHY or multiple PHY > network, and metric only worth in RPL or across the Internet, are > important to clarify. > >> Regards, >> >> -Colin >> >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: September 18, 2010 7:16 >> PM To: Colin O'Flynn Cc: 'Philip Levis'; roll@ietf.org Subject: Re: >> [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt >> >> Le 18/09/2010 19:37, Colin O'Flynn a =E9crit : >>> Caveat emptor: I have not read the entire metrics-09 at this >>> point, but wanted to comment anyway. >>> >>> I think the idea of "link energy" would be without much merit, of >>> course >> I'm >>> open to being wrong. My reasoning is as follows: >>> >>> 1) There will not be much difference between the energy it takes >>> to >> transmit >>> a packet within a RPL network. They will all be using similar link >>> layers, >> >> Take a car: all devices are on a single unique battery, yet many >> different copper, light and ether links in terms of energy needed. >> >> (in a car - how would a "battery" value of the metric which assumes >> each IP addressable device has its own "battery" work with RPL? All >> devices in the car are on the same unique battery, and sometimes on >> car engine electricity generator. Add to this the Electric Vehicle >> and you see.) >> >>> and much of the power of actually transmitting a packet is not >>> related to >> TX >>> power but getting everything else up (such as CPU running& >>> processing, >> PLL >>> being active and locked, CSMA being performed). >> >> That is right. Each transmitting device has CPU chipset to compute >> wireless coding and that takes energy. That energy is in higher >> orders of magnitude than actually transmitting. >> >> However the energy used to actual Tx (and Rx as in GPS devices) can >> be clearly distinguished. >> >> I meant that you would then require information on both TX& RX >> power if you wanted to be accurate. So you'd have to add more >> metrics there, and add two values for every hop. > > Hmmm... that sounds right. To be better accurate about link energy > metrics one would have to do both Tx metric and Rx metric. This could > be done. I was thinking that presenting first the Tx link energy metric > it would be easier to understand and then add the Rx metric too, > naturally. > >>> As an example for one specific radio, the ATMega128RFA1, the >>> values of current vs power output (from datasheet @ 3.0V): RX PWR >>> | Supply 3dBm | 14.5mA 1dBm | 10mA -3dBm | 9mA -17dBm | 8mA >>> >>> Converting both to mW (=3D mJ/s) RX PWR | Supply 2.00 | 43.5 1.26 | >>> 30 0.50 | 27 0.02 | 24 >>> >>> This is just current during active TX. >> >> That sounds exellent startpoint for design a link energy metric! To >> eliminate the time paramter (mJ/s) to get to the J only we could >> decide that we need to transmit 1280bytes of data - the IPv6 minimal >> MTU. >> >>> There are some additional things that are TX power independent, >>> but I think for any reasonable length 6LoWPAN packet they are much >>> smaller than the values I have here. >> >> Are we IPv6 perspective or not. If yes IPv6 stack needs to know how >> much energy is needed 1280bytes of data, a minimally sized IPv6 >> packet. The stack reasons in terms of packets of that or larger >> size. >> >> My example is 802.15.4/6LoWPAN specific, as that was just >> 802.15.4 packets. I just meant for any reasonable size 802.15.4 >> packet seen on a 6lowpan/IPv6 network you don't need to worry about >> CSMA time for example, as it's fairly minimal by comparison. > > Well, IPv6 for 802.15.4 RFC says clearly this is minimal IPv6 MTU > 1280bytes. I am not sure I understand why should IPv6 stack worry about > smaller data-link packets but I have to dig this, e.g. see whether the > linux stack does consider smaller than 1280bytes or not. > >>> 2) Receiving takes around the same amount of power as transmitting >>> for >> most >>> 802.15.4 nodes. For the previously used example that is around >>> 12mA in >> fact. >>> Thus the problem is not only TX power, but RX power. >> >> With GPS devices it is even truer, because they only receive. >> >>> How do you encapsulate that in "link energy" accurately? >> >> Well I proposed a metric bit encoding for it - should I send again? >> >> I looked back to I think may 2009 when I saw a discussion about >> it, if it was before that I probably missed it. > > Ok, I will resend tomorrow an an example of encoding energy link metric > for RA (it's on my office desktop). > >>> If you do it in simple ways with "fudge factors" you've probably >>> lost enough accuracy to bother doing it at all. >> >> I don't propose fudge factors. >> >>> 3) Link energy on its own would result in selecting lowest energy >>> paths I assume. Low power nodes which advertise smaller link >>> energies have >> probably >>> gone to great lengths to get low link energies, since they have low >>> available power. The nodes which are wall-powered won't try to get >>> link energy as low since they are free to transmit at highest >>> energy and not worry too much about power saving tricks. This >>> would be the opposite of >> what >>> you want, so obviously you combine link energy with available >>> energy. >> >> I would not combine. >> >> Combine was a poor choice of words on my part. I meant it >> uses both the link energy& node energy, and "combines" them to >> create a routing solution. So if you had separate link energy& node >> energy, figuring out how to use both of them would be a complex >> problem. > > I agree using both node and link energy in a single metric would make it > more complex. > >>> Combining link energy with available energy would be incredibly >>> complex to get perfect. Worse if you do it wrong you end up with >>> the exact opposite >> of >>> what you want since low-power paths are used at the expense of >>> battery >> life. >> >> What is battery life when birth and death is turning an engine >> on/off? Or when plugging the device on a docking. Or when plugging >> a vehicle on an outlet. >> >>> At least there is some obvious connection between a simple >>> "available energy" value and "am I likely to be used to route a >>> packet". >> >> Node energy helps it that way, yes. >> >>> 4) Transmit energy also depends on link reliability for most >>> wireless networks, since they have an acknowledgment system. >> >> Yes, retransmissions at link layer are a link layer problem, dealt >> with by power management of the link layer. IP stack cares about TCP >> retransmissions or above. >> >>> Thus an unreliable link may actually take much more than the >>> expected power to transmit every >> frame, >>> since it's often doing retries. I would expect a few >>> retransmissions to basically nullify a lot of work selecting the >>> "most optimum" routes from >> an >>> energy perspective. >> >> Hmmm... retransmissions may happen too for a node energy metric and >> that may nullify its effect too. >> >> I don't mean retransmission of the metric, I just meant >> retransmissions in general. It's a question of all this overhead >> exchanging metrics to maintain a perfect route, when in the end you >> spent more time maintain your route than routing data! So I think >> for link energy to be 'accurate', you'd also need to keep the ETX >> object updated for example. > > ETX has been so largely published and apparently implemented that I > can't disagree with it. However, I see it as a different metric than > the link energy metric. I guess one could use it differently than using > an IP link energy metric. > > I think ETX is good when considering particular wireless MAC layer, but > wouldn't be useful to qualify other links in the Internet like fiber, > for example. It is very relevant for the MACs considered by LLNs, I > think. > > Alex > > >> >>> 6) My conclusion from the above points is that the entire question >>> of >> RX/TX >>> power is too complex to bother doing perfectly in these networks. A >>> simplification that can at least be easily understood and specified >>> would >> be >>> more useful to everyone in the end than something that is more >>> complex and might not even work. >> >> If we wish we could discuss separately the actual use of the existing >> node energy metric and I think it's not that simple either. >> >>> Using such a metric DOES require external documents to specify how >>> the metric is used. But requiring external specification to work >>> out details seems inline with the rest of RPL so shouldn't be a >>> problem. >>> >>> And if in the future I'm completely wrong and someone needs link >>> energy, I don't see a problem of fitting the link energy into a >>> TLV in the "node energy object". >> >> I am happy to see openness to include link energy metric and I take >> note for future discussion. >> >> But link energy is link energy not node energy. We saw it in the >> above mAmpere discussion where you eliminated the computing power to >> which I agreed; yet it doesn't make sense conceptually to put link >> energy into a node energy container. Link energy values are >> distinct from node energy values. >> >> Alex >> >>> >>> Warm Regards, >>> >>> -Colin O'Flynn >>> >>> >>> -----Original Message----- From: roll-bounces@ietf.org >>> [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: >>> September 18, 2010 5:11 PM To: Alexandru Petrescu Cc: roll@ietf.org >>> Subject: Re: [Roll] WG Last Call on >>> draft-ietf-roll-routing-metrics-09.txt >>> >>> >>> On Sep 17, 2010, at 3:12 PM, Alexandru Petrescu wrote: >>> >>>> David, >>>> >>>> Thanks for this Last Call on the RoLL routing metrics draft. >>>> >>>> I reply now just to make sure I replied before the September >>>> 30th, 2010, the deadline Chair set and that I consider. >>>> >>>> I have proposed last year to have energy link metrics: how much >>>> energy in Joules is required on a particular link to send >>>> 1280bytes as an IPv6 packet. >>>> >>>> I have proposed this link metric also as an extension to the >>>> ripless draft-mulligan-roll-ripless-01. >>>> >>>> In draft-ietf-roll-routing-metrics energy _is_ used as a metric >>>> but as node energy only, not link energy. >>>> >>>> Link metrics _are_ considered in draft-ietf-roll-routing-metrics >>>> but not as energy. >>>> >>>> Private discussion pointed me unilaterally I may be wrong but I >>>> think publicly I may be right. >>>> >>>> I will send more comments later. >>> >>> Alex, >>> >>> Can you point me to an application requirements doc, or a concrete >>> application someone is building today, where link energy is >>> needed? Given the tremendous size and diversity of the industries >>> around LLNs, as well >> as >>> the application experience, I think our goal is to standardize >>> current practice rather than invent new mechanisms. >>> >>> Phil _______________________________________________ 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 > _______________________________________________ > 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 alexandru.petrescu@gmail.com Mon Sep 20 12:30:00 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10E573A68AF for ; Mon, 20 Sep 2010 12:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.708 X-Spam-Level: X-Spam-Status: No, score=-1.708 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0s52IQBloNdI for ; Mon, 20 Sep 2010 12:29:58 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 8407A3A6841 for ; Mon, 20 Sep 2010 12:29:55 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id D7105940124; Mon, 20 Sep 2010 21:30:07 +0200 (CEST) Message-ID: <4C97B63A.70808@gmail.com> Date: Mon, 20 Sep 2010 21:30:02 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: JP Vasseur References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> <006501cb5758$27f3aa90$77daffb0$@com> <4C9501C7.2060400@gmail.com> <006b01cb577b$6c2f1550$448d3ff0$@com> <4C966485.3070206@gmail.com> <9FB3AA8F-037A-4399-BEF9-38749BB38122@cisco.com> In-Reply-To: <9FB3AA8F-037A-4399-BEF9-38749BB38122@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100920-0, 20/09/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] ** Multiple PHY/MAC ** Re: WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 20 Sep 2010 19:30:00 -0000 Le 20/09/2010 09:21, JP Vasseur a écrit : > Hold-on ... RPL is a L3 routing protocol, which by itself answers > (hopefully) your first question. Further, this is clearly stated in > the charter. JP - I agree with this point: L3, multiple PHY/MAC, Charter. It reads good. However, let me summarize a few points questioning this multiple PHY/MAC assumption in RPL draft and metrics draft: - every RPL Control Message (pretty much everything in RPL) has src and dst scoped link-locally: src is a link-local unicast address and dst is a link-local scope multicast address... so all RPL messages are sent on a single link - but it's impossible to have several PHY/MACs on a single link. So, in order to have several PHY/MACs we need several links: does RPL router forward link-locally addressed messages? does it change src address with that of another interface when forwarding over it? ("link" is from rfc4861, which says nodes communicate on a link at the link-layer - two different link-layers are two different links). - the pictures in RPL draft show nodes like this: / (C) / Does it mean (C) has two interfaces (on two links)? I don't think so, because all such "/" links in all pictures link actually _only_ two nodes. It would make no sense at all to run multicast on every one of those node-to-node links, or use link-local multicast addresses. That makes me think there's actually one single link (one PHY/MAC) linking the nodes together. There are more things in the draft making think there's only one link: the absence of specification of which interface belongs a link-local address when that address is used, for example. - some link metrics in the metrics draft (ETX, LQL) seem particular to one PHY/MAC which is WiFi, by their historical references. Are these comparable to other MAC/PHYs? For example, is ETX 2 on WiFi bigger than ETX 1 on ANT+? Is each metric individually sufficient to cover several PHY/MACs such that to, for example, use the least possible transmitting power? I don't think so. Just three cents worth, Alex > With regards to your second question, these metrics are RPL metrics. > > On Sep 19, 2010, at 9:29 PM, Alexandru Petrescu wrote: > >> [my summary: it is worth clarifying (1) whether RPL runs in a >> single PHY or multiple PHY network, and (2) whether metrics for RPL >> should be understood in RPL network only or more universal like >> across the Internet. There are also points about whether Rx link >> energy is as important as Tx link energy and its usability >> overall.] >> >> Hi Colin, >> >> It does make sense to clarify the usage model first, especially >> the assumptions of whether or not RPL runs exclusively on networks >> made of single PHY, or multiple PHYs. >> >> I consider IP kind of work (do we say IPv6? 'router'?) is needed >> only if we consider multiple kinds of PHYs in the same network. >> Otherwise bridges, range extenders and other L2 tools are better >> appropriate than IP routers. >> >> During RPL comments we commented whether RPL draft text should say >> _only_ 802.15.4 or would it include PLC too. I think RPL draft >> text saying _only_ 802.15.4 would make subsequent metrics and >> security text much easier. However, it was insisted PLC should be >> there in the draft. So I am in that perspective now. >> >> But does that mean that RPL runs only on a network consisting of >> PLC devices, and on another network of 15.4 devices (separated by >> an Edge Router)? Or does it mean RPL runs in a network mixing 15.4 >> devices with PLC devices each being an RPL router? >> >> This was never clear. >> >> Le 18/09/2010 23:49, Colin O'Flynn a écrit : >>> Hi Alex, >>> >>> I think we have some different assumptions about the usage model. >>> It would be useful to clarify some of that first. I'm not >>> claiming my assumptions are correct or consistent with the >>> ROLL/RPL basis, these are simply my view of how I imagined it >>> would all fit together: >>> >>> 1) A single RPL network itself does not cross multiple PHY >>> layers. Crossing PHY layers would complicate the decision on >>> "best routes" partially for the reasons you mention. My comments >>> before showing TX power vs current was showing that for the same >>> PHY layer you can have a huge swing of TX power yet minimal >>> impact on energy required to transmit a packet (100x change in RF >>> energy = less than 2x change in total energy). >> >> (The energy used for transmission is the one measured by setting a >> highres ampermeter serially with the transmitting device, its >> battery and a shunt, make it send an IPv6 packet (type ping). That >> shows the energy used for transmission. This is just a rough >> view, but basically that is. There are related measurement tools >> like antena placed near emitter (the ones used to measure the DAS >> of mobile phones W/Kg).) >> >>> 2) Routing metrics are not universal, but will somewhat be >>> application-dependant. Thus you can change the metrics for >>> different nodes as required, and metrics might not make sense >>> between different RPL networks (this fits in with assumption >>> #1). >>> >>> Thus my view was the metrics should be simple, as you hide any >>> required customization. If you want to select the outgoing >>> interface you have some artificial change in the metric, where >>> the administrator has basically forced the device to prefer >>> interface 1 over interface 2. >> >> Yes, the metric should be simple. The simplest relates much to >> what exists in terms of how IP routers select their output >> interface without artificial human intervention. >> >>> In your given example of an automotive system where they all work >>> on a common power source, the nodes have a specific routing >>> metric where a certain "fudge factor" has been worked into the >>> different nodes. Thus all other things being equal, the >>> advertised metric of a node which takes a lot of energy to >>> transmit is made such that it is less preferred over another >>> node. >>> >>> I think you are assuming that (1) you can have different PHYs >>> within the RPL network, and (2) the routing metrics are more >>> universal, so you can compare two different RPL networks. Is this >>> correct? >> >> Yes, right, that is my assumption: different PHYs within an RPL >> network and routing metrics more universal - they'd work within the >> RPL network and across the Internet (like the simple hopcount >> metric), and one could also compare different RPL networks. >> >> Do we want metrics that work _only_ within an RPL network? Or more >> universal like across the Internet? Or both? This is also a >> requirement discussion which is worth clarifying. >> >>> I've included some clarifications below as well (see >>> ), but I think the above two points are most important to >>> understanding why we may see such a wide difference of opinion. >> >> YEs, the above points about RPL running in a single PHY or multiple >> PHY network, and metric only worth in RPL or across the Internet, >> are important to clarify. >> >>> Regards, >>> >>> -Colin >>> >>> -----Original Message----- From: Alexandru Petrescu >>> [mailto:alexandru.petrescu@gmail.com] Sent: September 18, 2010 >>> 7:16 PM To: Colin O'Flynn Cc: 'Philip Levis'; roll@ietf.org >>> Subject: Re: [Roll] WG Last Call on >>> draft-ietf-roll-routing-metrics-09.txt >>> >>> Le 18/09/2010 19:37, Colin O'Flynn a écrit : >>>> Caveat emptor: I have not read the entire metrics-09 at this >>>> point, but wanted to comment anyway. >>>> >>>> I think the idea of "link energy" would be without much merit, >>>> of course >>> I'm >>>> open to being wrong. My reasoning is as follows: >>>> >>>> 1) There will not be much difference between the energy it >>>> takes to >>> transmit >>>> a packet within a RPL network. They will all be using similar >>>> link layers, >>> >>> Take a car: all devices are on a single unique battery, yet many >>> different copper, light and ether links in terms of energy >>> needed. >>> >>> (in a car - how would a "battery" value of the metric which >>> assumes each IP addressable device has its own "battery" work >>> with RPL? All devices in the car are on the same unique battery, >>> and sometimes on car engine electricity generator. Add to this >>> the Electric Vehicle and you see.) >>> >>>> and much of the power of actually transmitting a packet is not >>>> related to >>> TX >>>> power but getting everything else up (such as CPU running& >>>> processing, >>> PLL >>>> being active and locked, CSMA being performed). >>> >>> That is right. Each transmitting device has CPU chipset to >>> compute wireless coding and that takes energy. That energy is in >>> higher orders of magnitude than actually transmitting. >>> >>> However the energy used to actual Tx (and Rx as in GPS devices) >>> can be clearly distinguished. >>> >>> I meant that you would then require information on both TX& >>> RX power if you wanted to be accurate. So you'd have to add >>> more metrics there, and add two values for every hop. >> >> Hmmm... that sounds right. To be better accurate about link >> energy metrics one would have to do both Tx metric and Rx metric. >> This could be done. I was thinking that presenting first the Tx >> link energy metric it would be easier to understand and then add >> the Rx metric too, naturally. >> >>>> As an example for one specific radio, the ATMega128RFA1, the >>>> values of current vs power output (from datasheet @ 3.0V): RX >>>> PWR | Supply 3dBm | 14.5mA 1dBm | 10mA -3dBm | 9mA -17dBm | >>>> 8mA >>>> >>>> Converting both to mW (= mJ/s) RX PWR | Supply 2.00 | 43.5 >>>> 1.26 | 30 0.50 | 27 0.02 | 24 >>>> >>>> This is just current during active TX. >>> >>> That sounds exellent startpoint for design a link energy metric! >>> To eliminate the time paramter (mJ/s) to get to the J only we >>> could decide that we need to transmit 1280bytes of data - the >>> IPv6 minimal MTU. >>> >>>> There are some additional things that are TX power >>>> independent, but I think for any reasonable length 6LoWPAN >>>> packet they are much smaller than the values I have here. >>> >>> Are we IPv6 perspective or not. If yes IPv6 stack needs to know >>> how much energy is needed 1280bytes of data, a minimally sized >>> IPv6 packet. The stack reasons in terms of packets of that or >>> larger size. >>> >>> My example is 802.15.4/6LoWPAN specific, as that was just >>> 802.15.4 packets. I just meant for any reasonable size 802.15.4 >>> packet seen on a 6lowpan/IPv6 network you don't need to worry >>> about CSMA time for example, as it's fairly minimal by >>> comparison. >> >> Well, IPv6 for 802.15.4 RFC says clearly this is minimal IPv6 MTU >> 1280bytes. I am not sure I understand why should IPv6 stack worry >> about smaller data-link packets but I have to dig this, e.g. see >> whether the linux stack does consider smaller than 1280bytes or >> not. >> >>>> 2) Receiving takes around the same amount of power as >>>> transmitting for >>> most >>>> 802.15.4 nodes. For the previously used example that is around >>>> 12mA in >>> fact. >>>> Thus the problem is not only TX power, but RX power. >>> >>> With GPS devices it is even truer, because they only receive. >>> >>>> How do you encapsulate that in "link energy" accurately? >>> >>> Well I proposed a metric bit encoding for it - should I send >>> again? >>> >>> I looked back to I think may 2009 when I saw a discussion >>> about it, if it was before that I probably missed it. >> >> Ok, I will resend tomorrow an an example of encoding energy link >> metric for RA (it's on my office desktop). >> >>>> If you do it in simple ways with "fudge factors" you've >>>> probably lost enough accuracy to bother doing it at all. >>> >>> I don't propose fudge factors. >>> >>>> 3) Link energy on its own would result in selecting lowest >>>> energy paths I assume. Low power nodes which advertise smaller >>>> link energies have >>> probably >>>> gone to great lengths to get low link energies, since they have >>>> low available power. The nodes which are wall-powered won't try >>>> to get link energy as low since they are free to transmit at >>>> highest energy and not worry too much about power saving >>>> tricks. This would be the opposite of >>> what >>>> you want, so obviously you combine link energy with available >>>> energy. >>> >>> I would not combine. >>> >>> Combine was a poor choice of words on my part. I meant >>> it uses both the link energy& node energy, and "combines" them >>> to create a routing solution. So if you had separate link energy& >>> node energy, figuring out how to use both of them would be a >>> complex problem. >> >> I agree using both node and link energy in a single metric would >> make it more complex. >> >>>> Combining link energy with available energy would be >>>> incredibly complex to get perfect. Worse if you do it wrong you >>>> end up with the exact opposite >>> of >>>> what you want since low-power paths are used at the expense of >>>> battery >>> life. >>> >>> What is battery life when birth and death is turning an engine >>> on/off? Or when plugging the device on a docking. Or when >>> plugging a vehicle on an outlet. >>> >>>> At least there is some obvious connection between a simple >>>> "available energy" value and "am I likely to be used to route >>>> a packet". >>> >>> Node energy helps it that way, yes. >>> >>>> 4) Transmit energy also depends on link reliability for most >>>> wireless networks, since they have an acknowledgment system. >>> >>> Yes, retransmissions at link layer are a link layer problem, >>> dealt with by power management of the link layer. IP stack cares >>> about TCP retransmissions or above. >>> >>>> Thus an unreliable link may actually take much more than the >>>> expected power to transmit every >>> frame, >>>> since it's often doing retries. I would expect a few >>>> retransmissions to basically nullify a lot of work selecting >>>> the "most optimum" routes from >>> an >>>> energy perspective. >>> >>> Hmmm... retransmissions may happen too for a node energy metric >>> and that may nullify its effect too. >>> >>> I don't mean retransmission of the metric, I just meant >>> retransmissions in general. It's a question of all this overhead >>> exchanging metrics to maintain a perfect route, when in the end >>> you spent more time maintain your route than routing data! So I >>> think for link energy to be 'accurate', you'd also need to keep >>> the ETX object updated for example. >> >> ETX has been so largely published and apparently implemented that >> I can't disagree with it. However, I see it as a different metric >> than the link energy metric. I guess one could use it differently >> than using an IP link energy metric. >> >> I think ETX is good when considering particular wireless MAC layer, >> but wouldn't be useful to qualify other links in the Internet like >> fiber, for example. It is very relevant for the MACs considered by >> LLNs, I think. >> >> Alex >> >> >>> >>>> 6) My conclusion from the above points is that the entire >>>> question of >>> RX/TX >>>> power is too complex to bother doing perfectly in these >>>> networks. A simplification that can at least be easily >>>> understood and specified would >>> be >>>> more useful to everyone in the end than something that is more >>>> complex and might not even work. >>> >>> If we wish we could discuss separately the actual use of the >>> existing node energy metric and I think it's not that simple >>> either. >>> >>>> Using such a metric DOES require external documents to specify >>>> how the metric is used. But requiring external specification >>>> to work out details seems inline with the rest of RPL so >>>> shouldn't be a problem. >>>> >>>> And if in the future I'm completely wrong and someone needs >>>> link energy, I don't see a problem of fitting the link energy >>>> into a TLV in the "node energy object". >>> >>> I am happy to see openness to include link energy metric and I >>> take note for future discussion. >>> >>> But link energy is link energy not node energy. We saw it in >>> the above mAmpere discussion where you eliminated the computing >>> power to which I agreed; yet it doesn't make sense conceptually >>> to put link energy into a node energy container. Link energy >>> values are distinct from node energy values. >>> >>> Alex >>> >>>> >>>> Warm Regards, >>>> >>>> -Colin O'Flynn >>>> >>>> >>>> -----Original Message----- From: roll-bounces@ietf.org >>>> [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: >>>> September 18, 2010 5:11 PM To: Alexandru Petrescu Cc: >>>> roll@ietf.org Subject: Re: [Roll] WG Last Call on >>>> draft-ietf-roll-routing-metrics-09.txt >>>> >>>> >>>> On Sep 17, 2010, at 3:12 PM, Alexandru Petrescu wrote: >>>> >>>>> David, >>>>> >>>>> Thanks for this Last Call on the RoLL routing metrics draft. >>>>> >>>>> I reply now just to make sure I replied before the September >>>>> 30th, 2010, the deadline Chair set and that I consider. >>>>> >>>>> I have proposed last year to have energy link metrics: how >>>>> much energy in Joules is required on a particular link to >>>>> send 1280bytes as an IPv6 packet. >>>>> >>>>> I have proposed this link metric also as an extension to the >>>>> ripless draft-mulligan-roll-ripless-01. >>>>> >>>>> In draft-ietf-roll-routing-metrics energy _is_ used as a >>>>> metric but as node energy only, not link energy. >>>>> >>>>> Link metrics _are_ considered in >>>>> draft-ietf-roll-routing-metrics but not as energy. >>>>> >>>>> Private discussion pointed me unilaterally I may be wrong but >>>>> I think publicly I may be right. >>>>> >>>>> I will send more comments later. >>>> >>>> Alex, >>>> >>>> Can you point me to an application requirements doc, or a >>>> concrete application someone is building today, where link >>>> energy is needed? Given the tremendous size and diversity of >>>> the industries around LLNs, as well >>> as >>>> the application experience, I think our goal is to standardize >>>> current practice rather than invent new mechanisms. >>>> >>>> Phil _______________________________________________ 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 jpv@cisco.com Mon Sep 20 18:51:47 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53E773A68DF for ; Mon, 20 Sep 2010 18:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.415 X-Spam-Level: X-Spam-Status: No, score=-110.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xUORMQf7GGi for ; Mon, 20 Sep 2010 18:51:44 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C02DF3A68DB for ; Mon, 20 Sep 2010 18:51:44 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANqsl0xAaMHG/2dsb2JhbACbXoZDcaownFGCc4JOBIo4gwSCXA X-IronPort-AV: E=Sophos;i="4.56,396,1280707200"; d="scan'208";a="258112005" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 21 Sep 2010 01:52:07 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o8L1q3Ow025003; Tue, 21 Sep 2010 01:52:05 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Sep 2010 03:51:48 +0200 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Sep 2010 03:51:47 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: JP Vasseur In-Reply-To: <4C97B63A.70808@gmail.com> Date: Tue, 21 Sep 2010 03:51:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> <006501cb5758$27f3aa90$77daffb0$@com> <4C9501C7.2060400@gmail.com> <006b01cb577b$6c2f1550$448d3ff0$@com> <4C966485.3070206@gmail.com> <9FB3AA8F-037A-4399-BEF9-38749BB38122@cisco.com> <4C97B63A.70808@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 21 Sep 2010 01:51:47.0539 (UTC) FILETIME=[8D137A30:01CB592F] Cc: roll@ietf.org Subject: Re: [Roll] ** Multiple PHY/MAC ** Re: WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Sep 2010 01:51:47 -0000 Simple answer. How different is it from other L3 routing protocol such = as OSPF with regards to the routing metrics in a routing domain that comprises = different PHY/MAC. It is not. Consider an ISIS L2 for example. As you probably = know,=20 you have routing metrics and in most cases a number of PHY/MAC (SDH, = optical, Ethernet, ATM, ...). You still use a metric for ISIS that reflects a = link characteristic. Hope that helps. JP. On Sep 20, 2010, at 9:30 PM, Alexandru Petrescu wrote: > Le 20/09/2010 09:21, JP Vasseur a =E9crit : >> Hold-on ... RPL is a L3 routing protocol, which by itself answers >> (hopefully) your first question. Further, this is clearly stated in >> the charter. >=20 > JP - I agree with this point: L3, multiple PHY/MAC, Charter. It reads > good. However, let me summarize a few points questioning this > multiple PHY/MAC assumption in RPL draft and metrics draft: >=20 > - every RPL Control Message (pretty much everything in RPL) has src = and > dst scoped link-locally: src is a link-local unicast address and dst > is a link-local scope multicast address... so all RPL messages are > sent on a single link - but it's impossible to have several PHY/MACs > on a single link. >=20 > So, in order to have several PHY/MACs we need several links: does RPL > router forward link-locally addressed messages? does it change src > address with that of another interface when forwarding over it? >=20 > ("link" is from rfc4861, which says nodes communicate on a link at > the link-layer - two different link-layers are two different links). >=20 > - the pictures in RPL draft show nodes like this: >=20 > / > (C) > / >=20 > Does it mean (C) has two interfaces (on two links)? I don't think > so, because all such "/" links in all pictures link actually _only_ > two nodes. It would make no sense at all to run multicast on every > one of those node-to-node links, or use link-local multicast > addresses. That makes me think there's actually one single link (one > PHY/MAC) linking the nodes together. >=20 > There are more things in the draft making think there's only one > link: the absence of specification of which interface belongs a > link-local address when that address is used, for example. >=20 > - some link metrics in the metrics draft (ETX, LQL) seem particular to > one PHY/MAC which is WiFi, by their historical references. Are these > comparable to other MAC/PHYs? For example, is ETX 2 on WiFi bigger > than ETX 1 on ANT+? Is each metric individually sufficient to cover > several PHY/MACs such that to, for example, use the least possible > transmitting power? I don't think so. >=20 > Just three cents worth, >=20 > Alex >=20 >> With regards to your second question, these metrics are RPL metrics. >>=20 >> On Sep 19, 2010, at 9:29 PM, Alexandru Petrescu wrote: >>=20 >>> [my summary: it is worth clarifying (1) whether RPL runs in a >>> single PHY or multiple PHY network, and (2) whether metrics for RPL >>> should be understood in RPL network only or more universal like >>> across the Internet. There are also points about whether Rx link >>> energy is as important as Tx link energy and its usability >>> overall.] >>>=20 >>> Hi Colin, >>>=20 >>> It does make sense to clarify the usage model first, especially >>> the assumptions of whether or not RPL runs exclusively on networks >>> made of single PHY, or multiple PHYs. >>>=20 >>> I consider IP kind of work (do we say IPv6? 'router'?) is needed >>> only if we consider multiple kinds of PHYs in the same network. >>> Otherwise bridges, range extenders and other L2 tools are better >>> appropriate than IP routers. >>>=20 >>> During RPL comments we commented whether RPL draft text should say >>> _only_ 802.15.4 or would it include PLC too. I think RPL draft >>> text saying _only_ 802.15.4 would make subsequent metrics and >>> security text much easier. However, it was insisted PLC should be >>> there in the draft. So I am in that perspective now. >>>=20 >>> But does that mean that RPL runs only on a network consisting of >>> PLC devices, and on another network of 15.4 devices (separated by >>> an Edge Router)? Or does it mean RPL runs in a network mixing 15.4 >>> devices with PLC devices each being an RPL router? >>>=20 >>> This was never clear. >>>=20 >>> Le 18/09/2010 23:49, Colin O'Flynn a =E9crit : >>>> Hi Alex, >>>>=20 >>>> I think we have some different assumptions about the usage model. >>>> It would be useful to clarify some of that first. I'm not >>>> claiming my assumptions are correct or consistent with the >>>> ROLL/RPL basis, these are simply my view of how I imagined it >>>> would all fit together: >>>>=20 >>>> 1) A single RPL network itself does not cross multiple PHY >>>> layers. Crossing PHY layers would complicate the decision on >>>> "best routes" partially for the reasons you mention. My comments >>>> before showing TX power vs current was showing that for the same >>>> PHY layer you can have a huge swing of TX power yet minimal >>>> impact on energy required to transmit a packet (100x change in RF >>>> energy =3D less than 2x change in total energy). >>>=20 >>> (The energy used for transmission is the one measured by setting a >>> highres ampermeter serially with the transmitting device, its >>> battery and a shunt, make it send an IPv6 packet (type ping). That >>> shows the energy used for transmission. This is just a rough >>> view, but basically that is. There are related measurement tools >>> like antena placed near emitter (the ones used to measure the DAS >>> of mobile phones W/Kg).) >>>=20 >>>> 2) Routing metrics are not universal, but will somewhat be >>>> application-dependant. Thus you can change the metrics for >>>> different nodes as required, and metrics might not make sense >>>> between different RPL networks (this fits in with assumption >>>> #1). >>>>=20 >>>> Thus my view was the metrics should be simple, as you hide any >>>> required customization. If you want to select the outgoing >>>> interface you have some artificial change in the metric, where >>>> the administrator has basically forced the device to prefer >>>> interface 1 over interface 2. >>>=20 >>> Yes, the metric should be simple. The simplest relates much to >>> what exists in terms of how IP routers select their output >>> interface without artificial human intervention. >>>=20 >>>> In your given example of an automotive system where they all work >>>> on a common power source, the nodes have a specific routing >>>> metric where a certain "fudge factor" has been worked into the >>>> different nodes. Thus all other things being equal, the >>>> advertised metric of a node which takes a lot of energy to >>>> transmit is made such that it is less preferred over another >>>> node. >>>>=20 >>>> I think you are assuming that (1) you can have different PHYs >>>> within the RPL network, and (2) the routing metrics are more >>>> universal, so you can compare two different RPL networks. Is this >>>> correct? >>>=20 >>> Yes, right, that is my assumption: different PHYs within an RPL >>> network and routing metrics more universal - they'd work within the >>> RPL network and across the Internet (like the simple hopcount >>> metric), and one could also compare different RPL networks. >>>=20 >>> Do we want metrics that work _only_ within an RPL network? Or more >>> universal like across the Internet? Or both? This is also a >>> requirement discussion which is worth clarifying. >>>=20 >>>> I've included some clarifications below as well (see >>>> ), but I think the above two points are most important to >>>> understanding why we may see such a wide difference of opinion. >>>=20 >>> YEs, the above points about RPL running in a single PHY or multiple >>> PHY network, and metric only worth in RPL or across the Internet, >>> are important to clarify. >>>=20 >>>> Regards, >>>>=20 >>>> -Colin >>>>=20 >>>> -----Original Message----- From: Alexandru Petrescu >>>> [mailto:alexandru.petrescu@gmail.com] Sent: September 18, 2010 >>>> 7:16 PM To: Colin O'Flynn Cc: 'Philip Levis'; roll@ietf.org >>>> Subject: Re: [Roll] WG Last Call on >>>> draft-ietf-roll-routing-metrics-09.txt >>>>=20 >>>> Le 18/09/2010 19:37, Colin O'Flynn a =E9crit : >>>>> Caveat emptor: I have not read the entire metrics-09 at this >>>>> point, but wanted to comment anyway. >>>>>=20 >>>>> I think the idea of "link energy" would be without much merit, >>>>> of course >>>> I'm >>>>> open to being wrong. My reasoning is as follows: >>>>>=20 >>>>> 1) There will not be much difference between the energy it >>>>> takes to >>>> transmit >>>>> a packet within a RPL network. They will all be using similar >>>>> link layers, >>>>=20 >>>> Take a car: all devices are on a single unique battery, yet many >>>> different copper, light and ether links in terms of energy >>>> needed. >>>>=20 >>>> (in a car - how would a "battery" value of the metric which >>>> assumes each IP addressable device has its own "battery" work >>>> with RPL? All devices in the car are on the same unique battery, >>>> and sometimes on car engine electricity generator. Add to this >>>> the Electric Vehicle and you see.) >>>>=20 >>>>> and much of the power of actually transmitting a packet is not >>>>> related to >>>> TX >>>>> power but getting everything else up (such as CPU running& >>>>> processing, >>>> PLL >>>>> being active and locked, CSMA being performed). >>>>=20 >>>> That is right. Each transmitting device has CPU chipset to >>>> compute wireless coding and that takes energy. That energy is in >>>> higher orders of magnitude than actually transmitting. >>>>=20 >>>> However the energy used to actual Tx (and Rx as in GPS devices) >>>> can be clearly distinguished. >>>>=20 >>>> I meant that you would then require information on both TX& >>>> RX power if you wanted to be accurate. So you'd have to add >>>> more metrics there, and add two values for every hop. >>>=20 >>> Hmmm... that sounds right. To be better accurate about link >>> energy metrics one would have to do both Tx metric and Rx metric. >>> This could be done. I was thinking that presenting first the Tx >>> link energy metric it would be easier to understand and then add >>> the Rx metric too, naturally. >>>=20 >>>>> As an example for one specific radio, the ATMega128RFA1, the >>>>> values of current vs power output (from datasheet @ 3.0V): RX >>>>> PWR | Supply 3dBm | 14.5mA 1dBm | 10mA -3dBm | 9mA -17dBm | >>>>> 8mA >>>>>=20 >>>>> Converting both to mW (=3D mJ/s) RX PWR | Supply 2.00 | 43.5 >>>>> 1.26 | 30 0.50 | 27 0.02 | 24 >>>>>=20 >>>>> This is just current during active TX. >>>>=20 >>>> That sounds exellent startpoint for design a link energy metric! >>>> To eliminate the time paramter (mJ/s) to get to the J only we >>>> could decide that we need to transmit 1280bytes of data - the >>>> IPv6 minimal MTU. >>>>=20 >>>>> There are some additional things that are TX power >>>>> independent, but I think for any reasonable length 6LoWPAN >>>>> packet they are much smaller than the values I have here. >>>>=20 >>>> Are we IPv6 perspective or not. If yes IPv6 stack needs to know >>>> how much energy is needed 1280bytes of data, a minimally sized >>>> IPv6 packet. The stack reasons in terms of packets of that or >>>> larger size. >>>>=20 >>>> My example is 802.15.4/6LoWPAN specific, as that was just >>>> 802.15.4 packets. I just meant for any reasonable size 802.15.4 >>>> packet seen on a 6lowpan/IPv6 network you don't need to worry >>>> about CSMA time for example, as it's fairly minimal by >>>> comparison. >>>=20 >>> Well, IPv6 for 802.15.4 RFC says clearly this is minimal IPv6 MTU >>> 1280bytes. I am not sure I understand why should IPv6 stack worry >>> about smaller data-link packets but I have to dig this, e.g. see >>> whether the linux stack does consider smaller than 1280bytes or >>> not. >>>=20 >>>>> 2) Receiving takes around the same amount of power as >>>>> transmitting for >>>> most >>>>> 802.15.4 nodes. For the previously used example that is around >>>>> 12mA in >>>> fact. >>>>> Thus the problem is not only TX power, but RX power. >>>>=20 >>>> With GPS devices it is even truer, because they only receive. >>>>=20 >>>>> How do you encapsulate that in "link energy" accurately? >>>>=20 >>>> Well I proposed a metric bit encoding for it - should I send >>>> again? >>>>=20 >>>> I looked back to I think may 2009 when I saw a discussion >>>> about it, if it was before that I probably missed it. >>>=20 >>> Ok, I will resend tomorrow an an example of encoding energy link >>> metric for RA (it's on my office desktop). >>>=20 >>>>> If you do it in simple ways with "fudge factors" you've >>>>> probably lost enough accuracy to bother doing it at all. >>>>=20 >>>> I don't propose fudge factors. >>>>=20 >>>>> 3) Link energy on its own would result in selecting lowest >>>>> energy paths I assume. Low power nodes which advertise smaller >>>>> link energies have >>>> probably >>>>> gone to great lengths to get low link energies, since they have >>>>> low available power. The nodes which are wall-powered won't try >>>>> to get link energy as low since they are free to transmit at >>>>> highest energy and not worry too much about power saving >>>>> tricks. This would be the opposite of >>>> what >>>>> you want, so obviously you combine link energy with available >>>>> energy. >>>>=20 >>>> I would not combine. >>>>=20 >>>> Combine was a poor choice of words on my part. I meant >>>> it uses both the link energy& node energy, and "combines" them >>>> to create a routing solution. So if you had separate link energy& >>>> node energy, figuring out how to use both of them would be a >>>> complex problem. >>>=20 >>> I agree using both node and link energy in a single metric would >>> make it more complex. >>>=20 >>>>> Combining link energy with available energy would be >>>>> incredibly complex to get perfect. Worse if you do it wrong you >>>>> end up with the exact opposite >>>> of >>>>> what you want since low-power paths are used at the expense of >>>>> battery >>>> life. >>>>=20 >>>> What is battery life when birth and death is turning an engine >>>> on/off? Or when plugging the device on a docking. Or when >>>> plugging a vehicle on an outlet. >>>>=20 >>>>> At least there is some obvious connection between a simple >>>>> "available energy" value and "am I likely to be used to route >>>>> a packet". >>>>=20 >>>> Node energy helps it that way, yes. >>>>=20 >>>>> 4) Transmit energy also depends on link reliability for most >>>>> wireless networks, since they have an acknowledgment system. >>>>=20 >>>> Yes, retransmissions at link layer are a link layer problem, >>>> dealt with by power management of the link layer. IP stack cares >>>> about TCP retransmissions or above. >>>>=20 >>>>> Thus an unreliable link may actually take much more than the >>>>> expected power to transmit every >>>> frame, >>>>> since it's often doing retries. I would expect a few >>>>> retransmissions to basically nullify a lot of work selecting >>>>> the "most optimum" routes from >>>> an >>>>> energy perspective. >>>>=20 >>>> Hmmm... retransmissions may happen too for a node energy metric >>>> and that may nullify its effect too. >>>>=20 >>>> I don't mean retransmission of the metric, I just meant >>>> retransmissions in general. It's a question of all this overhead >>>> exchanging metrics to maintain a perfect route, when in the end >>>> you spent more time maintain your route than routing data! So I >>>> think for link energy to be 'accurate', you'd also need to keep >>>> the ETX object updated for example. >>>=20 >>> ETX has been so largely published and apparently implemented that >>> I can't disagree with it. However, I see it as a different metric >>> than the link energy metric. I guess one could use it differently >>> than using an IP link energy metric. >>>=20 >>> I think ETX is good when considering particular wireless MAC layer, >>> but wouldn't be useful to qualify other links in the Internet like >>> fiber, for example. It is very relevant for the MACs considered by >>> LLNs, I think. >>>=20 >>> Alex >>>=20 >>>=20 >>>>=20 >>>>> 6) My conclusion from the above points is that the entire >>>>> question of >>>> RX/TX >>>>> power is too complex to bother doing perfectly in these >>>>> networks. A simplification that can at least be easily >>>>> understood and specified would >>>> be >>>>> more useful to everyone in the end than something that is more >>>>> complex and might not even work. >>>>=20 >>>> If we wish we could discuss separately the actual use of the >>>> existing node energy metric and I think it's not that simple >>>> either. >>>>=20 >>>>> Using such a metric DOES require external documents to specify >>>>> how the metric is used. But requiring external specification >>>>> to work out details seems inline with the rest of RPL so >>>>> shouldn't be a problem. >>>>>=20 >>>>> And if in the future I'm completely wrong and someone needs >>>>> link energy, I don't see a problem of fitting the link energy >>>>> into a TLV in the "node energy object". >>>>=20 >>>> I am happy to see openness to include link energy metric and I >>>> take note for future discussion. >>>>=20 >>>> But link energy is link energy not node energy. We saw it in >>>> the above mAmpere discussion where you eliminated the computing >>>> power to which I agreed; yet it doesn't make sense conceptually >>>> to put link energy into a node energy container. Link energy >>>> values are distinct from node energy values. >>>>=20 >>>> Alex >>>>=20 >>>>>=20 >>>>> Warm Regards, >>>>>=20 >>>>> -Colin O'Flynn >>>>>=20 >>>>>=20 >>>>> -----Original Message----- From: roll-bounces@ietf.org >>>>> [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: >>>>> September 18, 2010 5:11 PM To: Alexandru Petrescu Cc: >>>>> roll@ietf.org Subject: Re: [Roll] WG Last Call on >>>>> draft-ietf-roll-routing-metrics-09.txt >>>>>=20 >>>>>=20 >>>>> On Sep 17, 2010, at 3:12 PM, Alexandru Petrescu wrote: >>>>>=20 >>>>>> David, >>>>>>=20 >>>>>> Thanks for this Last Call on the RoLL routing metrics draft. >>>>>>=20 >>>>>> I reply now just to make sure I replied before the September >>>>>> 30th, 2010, the deadline Chair set and that I consider. >>>>>>=20 >>>>>> I have proposed last year to have energy link metrics: how >>>>>> much energy in Joules is required on a particular link to >>>>>> send 1280bytes as an IPv6 packet. >>>>>>=20 >>>>>> I have proposed this link metric also as an extension to the >>>>>> ripless draft-mulligan-roll-ripless-01. >>>>>>=20 >>>>>> In draft-ietf-roll-routing-metrics energy _is_ used as a >>>>>> metric but as node energy only, not link energy. >>>>>>=20 >>>>>> Link metrics _are_ considered in >>>>>> draft-ietf-roll-routing-metrics but not as energy. >>>>>>=20 >>>>>> Private discussion pointed me unilaterally I may be wrong but >>>>>> I think publicly I may be right. >>>>>>=20 >>>>>> I will send more comments later. >>>>>=20 >>>>> Alex, >>>>>=20 >>>>> Can you point me to an application requirements doc, or a >>>>> concrete application someone is building today, where link >>>>> energy is needed? Given the tremendous size and diversity of >>>>> the industries around LLNs, as well >>>> as >>>>> the application experience, I think our goal is to standardize >>>>> current practice rather than invent new mechanisms. >>>>>=20 >>>>> Phil _______________________________________________ Roll >>>>> mailing list Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>=20 >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Mon Sep 20 19:12:51 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 349F93A68E6 for ; Mon, 20 Sep 2010 19:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.416 X-Spam-Level: X-Spam-Status: No, score=-110.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSoVoVO2sUgz for ; Mon, 20 Sep 2010 19:12:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6EF5D3A68D3 for ; Mon, 20 Sep 2010 19:12:47 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE+xl0yQ/khL/2dsb2JhbACiIXGqPJxTgwMIgjYEijiDBA X-IronPort-AV: E=Sophos;i="4.56,396,1280707200"; d="scan'208";a="64786326" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 21 Sep 2010 02:13:10 +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 o8L2DAu4018674; Tue, 21 Sep 2010 02:13:10 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Sep 2010 04:13:10 +0200 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Sep 2010 04:13:09 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: JP Vasseur In-Reply-To: <4C93E7D7.3000603@gmail.com> Date: Tue, 21 Sep 2010 04:13:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <293E4334-92BD-460E-AE1D-4F34CD84A665@cisco.com> References: <4C93E7D7.3000603@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 21 Sep 2010 02:13:09.0759 (UTC) FILETIME=[8956B8F0:01CB5932] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-17656.003 X-TM-AS-Result: No--22.361900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Sep 2010 02:12:51 -0000 Hi, * co-chair hat off * On Sep 18, 2010, at 12:12 AM, Alexandru Petrescu wrote: > David, >=20 > Thanks for this Last Call on the RoLL routing metrics draft. >=20 > I reply now just to make sure I replied before the September 30th, = 2010, > the deadline Chair set and that I consider. >=20 > I have proposed last year to have energy link metrics: how much energy > in Joules is required on a particular link to send 1280bytes as an = IPv6 > packet. >=20 First of all, this document specifies a set of link/node routing = metrics/constraint along with various mechanisms to manipulate these metrics and constraint = and needless to say that additional metrics could be defined in the future. I do remember that discussion indeed. The reason for taking into account=20= the node energy as a metric and/or constraint is obvious. Now the = question that I asked you was: "why would you want to optimize path against link=20= energy ?". Trying to avoid nodes that are running out of energy or = compute paths so that energy consumption is even distributed thanks to load = balancing is well understood. But I fail to see how link energy metrics should be = used ? Say that you have n paths and their path cost reflects the amount of = energy required along each of them. Would you choose the least cost path ? If = so, what if you choose a path traversing a set of battery operated nodes, = instead of a path that may consume more energy but would traverse nodes for = which energy is not a limited factor ? Could you describe a use case of link = energy metric ? > I have proposed this link metric also as an extension to the ripless > draft-mulligan-roll-ripless-01. >=20 This document defines routing metrics for RPL. > In draft-ietf-roll-routing-metrics energy _is_ used as a metric but as > node energy only, not link energy. >=20 > Link metrics _are_ considered in draft-ietf-roll-routing-metrics but > not as energy. >=20 > Private discussion pointed me unilaterally I may be wrong but I think > publicly I may be right. Not sure what you meant here. JP. >=20 > I will send more comments later. >=20 > Alex >=20 > Le 16/09/2010 15:56, David Culler a =E9crit : >> The routing metrics draft has now gone through 9 revisions over the >> past 16 months, the diffs have narrowed to essentially wording and >> editorial changes, and the comments are few and non-controversial. >> Thus, it appears that consensus has emerged and we can LC this I-D. >>=20 >> This email is to announce Working Group Last Call on >> draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST, >> Sept. 30 2010. Please read it thoroughly and forward all final >> comments to the authors and the WG mailing list. >>=20 >> Thanks all for your good work. We're on a ROLL. >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Mon Sep 20 19:14:17 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BED23A68E4 for ; Mon, 20 Sep 2010 19:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.417 X-Spam-Level: X-Spam-Status: No, score=-106.417 tagged_above=-999 required=5 tests=[AWL=-3.818, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2P3bamJ-o0Dt for ; Mon, 20 Sep 2010 19:14:15 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 5496E3A68D3 for ; Mon, 20 Sep 2010 19:14:15 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMixl0yQ/khL/2dsb2JhbACiIXGqN5xUhUEEijiDBA X-IronPort-AV: E=Sophos;i="4.56,396,1280707200"; d="scan'208";a="9789791" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 21 Sep 2010 02:14:38 +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 o8L2Ec4H018914 for ; Tue, 21 Sep 2010 02:14:38 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Sep 2010 04:14:37 +0200 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Sep 2010 04:14:37 +0200 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Sep 2010 04:14:37 +0200 Message-Id: <6050073F-7A3B-4F4B-97BA-AD640B465F7F@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 21 Sep 2010 02:14:37.0771 (UTC) FILETIME=[BDCC49B0:01CB5932] Subject: [Roll] Just a clarification on the routing metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Sep 2010 02:14:17 -0000 Hi, Just a quick clarification. The routing ID draft specifies a set of = routing links/constraints. Of course, it does not mandate for each node to support all of them (stating the obvious) and = additional metrics may be specified in other documents. Thanks. JP.= From alexandru.petrescu@gmail.com Mon Sep 20 23:34:46 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F5923A6955 for ; Mon, 20 Sep 2010 23:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qknu-PvaI4gG for ; Mon, 20 Sep 2010 23:34:44 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id C19BD3A694D for ; Mon, 20 Sep 2010 23:34:43 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o8L6Z4Fj002162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Sep 2010 08:35:04 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o8L6Z3DC026965; Tue, 21 Sep 2010 08:35:04 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o8L6Z2cf030893; Tue, 21 Sep 2010 08:35:03 +0200 Message-ID: <4C985216.6080404@gmail.com> Date: Tue, 21 Sep 2010 08:35:02 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: JP Vasseur References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> <006501cb5758$27f3aa90$77daffb0$@com> <4C9501C7.2060400@gmail.com> <006b01cb577b$6c2f1550$448d3ff0$@com> <4C966485.3070206@gmail.com> <9FB3AA8F-037A-4399-BEF9-38749BB38122@cisco.com> <4C97B63A.70808@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] ** Multiple PHY/MAC ** Re: WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Sep 2010 06:34:46 -0000 Le 21/09/2010 03:51, JP Vasseur a écrit : > Simple answer. How different is it from other L3 routing protocol > such as OSPF with regards to the routing metrics in a routing domain > that comprises different PHY/MAC. It is not. Consider an ISIS L2 for > example. As you probably know, you have routing metrics and in most > cases a number of PHY/MAC (SDH, optical, Ethernet, ATM, ...). You > still use a metric for ISIS that reflects a link characteristic. > > Hope that helps. Ok, that about metrics in OSPF. I have to go look for a link characteristics metric for OSPF (not ISIS) and see whether it covers several PHY/MACs, see whether they're used simultaneously. But how about RPL being a single link? RPL document says it runs a single link (src, dst are link-local). One couldn't fit several PHY/MACs on a single link. Alex > > JP. > > On Sep 20, 2010, at 9:30 PM, Alexandru Petrescu wrote: > >> Le 20/09/2010 09:21, JP Vasseur a écrit : >>> Hold-on ... RPL is a L3 routing protocol, which by itself answers >>> (hopefully) your first question. Further, this is clearly stated >>> in the charter. >> >> JP - I agree with this point: L3, multiple PHY/MAC, Charter. It >> reads good. However, let me summarize a few points questioning >> this multiple PHY/MAC assumption in RPL draft and metrics draft: >> >> - every RPL Control Message (pretty much everything in RPL) has >> src and dst scoped link-locally: src is a link-local unicast >> address and dst is a link-local scope multicast address... so all >> RPL messages are sent on a single link - but it's impossible to >> have several PHY/MACs on a single link. >> >> So, in order to have several PHY/MACs we need several links: does >> RPL router forward link-locally addressed messages? does it >> change src address with that of another interface when forwarding >> over it? >> >> ("link" is from rfc4861, which says nodes communicate on a link at >> the link-layer - two different link-layers are two different >> links). >> >> - the pictures in RPL draft show nodes like this: >> >> / (C) / >> >> Does it mean (C) has two interfaces (on two links)? I don't think >> so, because all such "/" links in all pictures link actually >> _only_ two nodes. It would make no sense at all to run multicast >> on every one of those node-to-node links, or use link-local >> multicast addresses. That makes me think there's actually one >> single link (one PHY/MAC) linking the nodes together. >> >> There are more things in the draft making think there's only one >> link: the absence of specification of which interface belongs a >> link-local address when that address is used, for example. >> >> - some link metrics in the metrics draft (ETX, LQL) seem >> particular to one PHY/MAC which is WiFi, by their historical >> references. Are these comparable to other MAC/PHYs? For example, >> is ETX 2 on WiFi bigger than ETX 1 on ANT+? Is each metric >> individually sufficient to cover several PHY/MACs such that to, for >> example, use the least possible transmitting power? I don't think >> so. >> >> Just three cents worth, >> >> Alex >> >>> With regards to your second question, these metrics are RPL >>> metrics. >>> >>> On Sep 19, 2010, at 9:29 PM, Alexandru Petrescu wrote: >>> >>>> [my summary: it is worth clarifying (1) whether RPL runs in a >>>> single PHY or multiple PHY network, and (2) whether metrics >>>> for RPL should be understood in RPL network only or more >>>> universal like across the Internet. There are also points >>>> about whether Rx link energy is as important as Tx link energy >>>> and its usability overall.] >>>> >>>> Hi Colin, >>>> >>>> It does make sense to clarify the usage model first, especially >>>> the assumptions of whether or not RPL runs exclusively on >>>> networks made of single PHY, or multiple PHYs. >>>> >>>> I consider IP kind of work (do we say IPv6? 'router'?) is >>>> needed only if we consider multiple kinds of PHYs in the same >>>> network. Otherwise bridges, range extenders and other L2 tools >>>> are better appropriate than IP routers. >>>> >>>> During RPL comments we commented whether RPL draft text should >>>> say _only_ 802.15.4 or would it include PLC too. I think RPL >>>> draft text saying _only_ 802.15.4 would make subsequent >>>> metrics and security text much easier. However, it was >>>> insisted PLC should be there in the draft. So I am in that >>>> perspective now. >>>> >>>> But does that mean that RPL runs only on a network consisting >>>> of PLC devices, and on another network of 15.4 devices >>>> (separated by an Edge Router)? Or does it mean RPL runs in a >>>> network mixing 15.4 devices with PLC devices each being an RPL >>>> router? >>>> >>>> This was never clear. >>>> >>>> Le 18/09/2010 23:49, Colin O'Flynn a écrit : >>>>> Hi Alex, >>>>> >>>>> I think we have some different assumptions about the usage >>>>> model. It would be useful to clarify some of that first. I'm >>>>> not claiming my assumptions are correct or consistent with >>>>> the ROLL/RPL basis, these are simply my view of how I >>>>> imagined it would all fit together: >>>>> >>>>> 1) A single RPL network itself does not cross multiple PHY >>>>> layers. Crossing PHY layers would complicate the decision on >>>>> "best routes" partially for the reasons you mention. My >>>>> comments before showing TX power vs current was showing that >>>>> for the same PHY layer you can have a huge swing of TX power >>>>> yet minimal impact on energy required to transmit a packet >>>>> (100x change in RF energy = less than 2x change in total >>>>> energy). >>>> >>>> (The energy used for transmission is the one measured by >>>> setting a highres ampermeter serially with the transmitting >>>> device, its battery and a shunt, make it send an IPv6 packet >>>> (type ping). That shows the energy used for transmission. >>>> This is just a rough view, but basically that is. There are >>>> related measurement tools like antena placed near emitter (the >>>> ones used to measure the DAS of mobile phones W/Kg).) >>>> >>>>> 2) Routing metrics are not universal, but will somewhat be >>>>> application-dependant. Thus you can change the metrics for >>>>> different nodes as required, and metrics might not make sense >>>>> between different RPL networks (this fits in with assumption >>>>> #1). >>>>> >>>>> Thus my view was the metrics should be simple, as you hide >>>>> any required customization. If you want to select the >>>>> outgoing interface you have some artificial change in the >>>>> metric, where the administrator has basically forced the >>>>> device to prefer interface 1 over interface 2. >>>> >>>> Yes, the metric should be simple. The simplest relates much to >>>> what exists in terms of how IP routers select their output >>>> interface without artificial human intervention. >>>> >>>>> In your given example of an automotive system where they all >>>>> work on a common power source, the nodes have a specific >>>>> routing metric where a certain "fudge factor" has been >>>>> worked into the different nodes. Thus all other things being >>>>> equal, the advertised metric of a node which takes a lot of >>>>> energy to transmit is made such that it is less preferred >>>>> over another node. >>>>> >>>>> I think you are assuming that (1) you can have different PHYs >>>>> within the RPL network, and (2) the routing metrics are more >>>>> universal, so you can compare two different RPL networks. Is >>>>> this correct? >>>> >>>> Yes, right, that is my assumption: different PHYs within an RPL >>>> network and routing metrics more universal - they'd work within >>>> the RPL network and across the Internet (like the simple >>>> hopcount metric), and one could also compare different RPL >>>> networks. >>>> >>>> Do we want metrics that work _only_ within an RPL network? Or >>>> more universal like across the Internet? Or both? This is >>>> also a requirement discussion which is worth clarifying. >>>> >>>>> I've included some clarifications below as well (see >>>>> ), but I think the above two points are most important >>>>> to understanding why we may see such a wide difference of >>>>> opinion. >>>> >>>> YEs, the above points about RPL running in a single PHY or >>>> multiple PHY network, and metric only worth in RPL or across >>>> the Internet, are important to clarify. >>>> >>>>> Regards, >>>>> >>>>> -Colin >>>>> >>>>> -----Original Message----- From: Alexandru Petrescu >>>>> [mailto:alexandru.petrescu@gmail.com] Sent: September 18, >>>>> 2010 7:16 PM To: Colin O'Flynn Cc: 'Philip Levis'; >>>>> roll@ietf.org Subject: Re: [Roll] WG Last Call on >>>>> draft-ietf-roll-routing-metrics-09.txt >>>>> >>>>> Le 18/09/2010 19:37, Colin O'Flynn a écrit : >>>>>> Caveat emptor: I have not read the entire metrics-09 at >>>>>> this point, but wanted to comment anyway. >>>>>> >>>>>> I think the idea of "link energy" would be without much >>>>>> merit, of course >>>>> I'm >>>>>> open to being wrong. My reasoning is as follows: >>>>>> >>>>>> 1) There will not be much difference between the energy it >>>>>> takes to >>>>> transmit >>>>>> a packet within a RPL network. They will all be using >>>>>> similar link layers, >>>>> >>>>> Take a car: all devices are on a single unique battery, yet >>>>> many different copper, light and ether links in terms of >>>>> energy needed. >>>>> >>>>> (in a car - how would a "battery" value of the metric which >>>>> assumes each IP addressable device has its own "battery" work >>>>> with RPL? All devices in the car are on the same unique >>>>> battery, and sometimes on car engine electricity generator. >>>>> Add to this the Electric Vehicle and you see.) >>>>> >>>>>> and much of the power of actually transmitting a packet is >>>>>> not related to >>>>> TX >>>>>> power but getting everything else up (such as CPU running& >>>>>> processing, >>>>> PLL >>>>>> being active and locked, CSMA being performed). >>>>> >>>>> That is right. Each transmitting device has CPU chipset to >>>>> compute wireless coding and that takes energy. That energy >>>>> is in higher orders of magnitude than actually transmitting. >>>>> >>>>> However the energy used to actual Tx (and Rx as in GPS >>>>> devices) can be clearly distinguished. >>>>> >>>>> I meant that you would then require information on both >>>>> TX& RX power if you wanted to be accurate. So you'd have to >>>>> add more metrics there, and add two values for every >>>>> hop. >>>> >>>> Hmmm... that sounds right. To be better accurate about link >>>> energy metrics one would have to do both Tx metric and Rx >>>> metric. This could be done. I was thinking that presenting >>>> first the Tx link energy metric it would be easier to >>>> understand and then add the Rx metric too, naturally. >>>> >>>>>> As an example for one specific radio, the ATMega128RFA1, >>>>>> the values of current vs power output (from datasheet @ >>>>>> 3.0V): RX PWR | Supply 3dBm | 14.5mA 1dBm | 10mA -3dBm >>>>>> | 9mA -17dBm | 8mA >>>>>> >>>>>> Converting both to mW (= mJ/s) RX PWR | Supply 2.00 | 43.5 >>>>>> 1.26 | 30 0.50 | 27 0.02 | 24 >>>>>> >>>>>> This is just current during active TX. >>>>> >>>>> That sounds exellent startpoint for design a link energy >>>>> metric! To eliminate the time paramter (mJ/s) to get to the >>>>> J only we could decide that we need to transmit 1280bytes >>>>> of data - the IPv6 minimal MTU. >>>>> >>>>>> There are some additional things that are TX power >>>>>> independent, but I think for any reasonable length 6LoWPAN >>>>>> packet they are much smaller than the values I have here. >>>>> >>>>> Are we IPv6 perspective or not. If yes IPv6 stack needs to >>>>> know how much energy is needed 1280bytes of data, a >>>>> minimally sized IPv6 packet. The stack reasons in terms of >>>>> packets of that or larger size. >>>>> >>>>> My example is 802.15.4/6LoWPAN specific, as that was >>>>> just 802.15.4 packets. I just meant for any reasonable size >>>>> 802.15.4 packet seen on a 6lowpan/IPv6 network you don't >>>>> need to worry about CSMA time for example, as it's fairly >>>>> minimal by comparison. >>>> >>>> Well, IPv6 for 802.15.4 RFC says clearly this is minimal IPv6 >>>> MTU 1280bytes. I am not sure I understand why should IPv6 >>>> stack worry about smaller data-link packets but I have to dig >>>> this, e.g. see whether the linux stack does consider smaller >>>> than 1280bytes or not. >>>> >>>>>> 2) Receiving takes around the same amount of power as >>>>>> transmitting for >>>>> most >>>>>> 802.15.4 nodes. For the previously used example that is >>>>>> around 12mA in >>>>> fact. >>>>>> Thus the problem is not only TX power, but RX power. >>>>> >>>>> With GPS devices it is even truer, because they only >>>>> receive. >>>>> >>>>>> How do you encapsulate that in "link energy" accurately? >>>>> >>>>> Well I proposed a metric bit encoding for it - should I send >>>>> again? >>>>> >>>>> I looked back to I think may 2009 when I saw a >>>>> discussion about it, if it was before that I probably missed >>>>> it. >>>> >>>> Ok, I will resend tomorrow an an example of encoding energy >>>> link metric for RA (it's on my office desktop). >>>> >>>>>> If you do it in simple ways with "fudge factors" you've >>>>>> probably lost enough accuracy to bother doing it at all. >>>>> >>>>> I don't propose fudge factors. >>>>> >>>>>> 3) Link energy on its own would result in selecting lowest >>>>>> energy paths I assume. Low power nodes which advertise >>>>>> smaller link energies have >>>>> probably >>>>>> gone to great lengths to get low link energies, since they >>>>>> have low available power. The nodes which are wall-powered >>>>>> won't try to get link energy as low since they are free to >>>>>> transmit at highest energy and not worry too much about >>>>>> power saving tricks. This would be the opposite of >>>>> what >>>>>> you want, so obviously you combine link energy with >>>>>> available energy. >>>>> >>>>> I would not combine. >>>>> >>>>> Combine was a poor choice of words on my part. I >>>>> meant it uses both the link energy& node energy, and >>>>> "combines" them to create a routing solution. So if you had >>>>> separate link energy& node energy, figuring out how to use >>>>> both of them would be a complex problem. >>>> >>>> I agree using both node and link energy in a single metric >>>> would make it more complex. >>>> >>>>>> Combining link energy with available energy would be >>>>>> incredibly complex to get perfect. Worse if you do it >>>>>> wrong you end up with the exact opposite >>>>> of >>>>>> what you want since low-power paths are used at the >>>>>> expense of battery >>>>> life. >>>>> >>>>> What is battery life when birth and death is turning an >>>>> engine on/off? Or when plugging the device on a docking. Or >>>>> when plugging a vehicle on an outlet. >>>>> >>>>>> At least there is some obvious connection between a simple >>>>>> "available energy" value and "am I likely to be used to >>>>>> route a packet". >>>>> >>>>> Node energy helps it that way, yes. >>>>> >>>>>> 4) Transmit energy also depends on link reliability for >>>>>> most wireless networks, since they have an acknowledgment >>>>>> system. >>>>> >>>>> Yes, retransmissions at link layer are a link layer problem, >>>>> dealt with by power management of the link layer. IP stack >>>>> cares about TCP retransmissions or above. >>>>> >>>>>> Thus an unreliable link may actually take much more than >>>>>> the expected power to transmit every >>>>> frame, >>>>>> since it's often doing retries. I would expect a few >>>>>> retransmissions to basically nullify a lot of work >>>>>> selecting the "most optimum" routes from >>>>> an >>>>>> energy perspective. >>>>> >>>>> Hmmm... retransmissions may happen too for a node energy >>>>> metric and that may nullify its effect too. >>>>> >>>>> I don't mean retransmission of the metric, I just meant >>>>> retransmissions in general. It's a question of all this >>>>> overhead exchanging metrics to maintain a perfect route, >>>>> when in the end you spent more time maintain your route than >>>>> routing data! So I think for link energy to be 'accurate', >>>>> you'd also need to keep the ETX object updated for >>>>> example. >>>> >>>> ETX has been so largely published and apparently implemented >>>> that I can't disagree with it. However, I see it as a >>>> different metric than the link energy metric. I guess one >>>> could use it differently than using an IP link energy metric. >>>> >>>> I think ETX is good when considering particular wireless MAC >>>> layer, but wouldn't be useful to qualify other links in the >>>> Internet like fiber, for example. It is very relevant for the >>>> MACs considered by LLNs, I think. >>>> >>>> Alex >>>> >>>> >>>>> >>>>>> 6) My conclusion from the above points is that the entire >>>>>> question of >>>>> RX/TX >>>>>> power is too complex to bother doing perfectly in these >>>>>> networks. A simplification that can at least be easily >>>>>> understood and specified would >>>>> be >>>>>> more useful to everyone in the end than something that is >>>>>> more complex and might not even work. >>>>> >>>>> If we wish we could discuss separately the actual use of the >>>>> existing node energy metric and I think it's not that simple >>>>> either. >>>>> >>>>>> Using such a metric DOES require external documents to >>>>>> specify how the metric is used. But requiring external >>>>>> specification to work out details seems inline with the >>>>>> rest of RPL so shouldn't be a problem. >>>>>> >>>>>> And if in the future I'm completely wrong and someone needs >>>>>> link energy, I don't see a problem of fitting the link >>>>>> energy into a TLV in the "node energy object". >>>>> >>>>> I am happy to see openness to include link energy metric and >>>>> I take note for future discussion. >>>>> >>>>> But link energy is link energy not node energy. We saw it in >>>>> the above mAmpere discussion where you eliminated the >>>>> computing power to which I agreed; yet it doesn't make sense >>>>> conceptually to put link energy into a node energy >>>>> container. Link energy values are distinct from node energy >>>>> values. >>>>> >>>>> Alex >>>>> >>>>>> >>>>>> Warm Regards, >>>>>> >>>>>> -Colin O'Flynn >>>>>> >>>>>> >>>>>> -----Original Message----- From: roll-bounces@ietf.org >>>>>> [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis >>>>>> Sent: September 18, 2010 5:11 PM To: Alexandru Petrescu Cc: >>>>>> roll@ietf.org Subject: Re: [Roll] WG Last Call on >>>>>> draft-ietf-roll-routing-metrics-09.txt >>>>>> >>>>>> >>>>>> On Sep 17, 2010, at 3:12 PM, Alexandru Petrescu wrote: >>>>>> >>>>>>> David, >>>>>>> >>>>>>> Thanks for this Last Call on the RoLL routing metrics >>>>>>> draft. >>>>>>> >>>>>>> I reply now just to make sure I replied before the >>>>>>> September 30th, 2010, the deadline Chair set and that I >>>>>>> consider. >>>>>>> >>>>>>> I have proposed last year to have energy link metrics: >>>>>>> how much energy in Joules is required on a particular >>>>>>> link to send 1280bytes as an IPv6 packet. >>>>>>> >>>>>>> I have proposed this link metric also as an extension to >>>>>>> the ripless draft-mulligan-roll-ripless-01. >>>>>>> >>>>>>> In draft-ietf-roll-routing-metrics energy _is_ used as a >>>>>>> metric but as node energy only, not link energy. >>>>>>> >>>>>>> Link metrics _are_ considered in >>>>>>> draft-ietf-roll-routing-metrics but not as energy. >>>>>>> >>>>>>> Private discussion pointed me unilaterally I may be >>>>>>> wrong but I think publicly I may be right. >>>>>>> >>>>>>> I will send more comments later. >>>>>> >>>>>> Alex, >>>>>> >>>>>> Can you point me to an application requirements doc, or a >>>>>> concrete application someone is building today, where link >>>>>> energy is needed? Given the tremendous size and diversity >>>>>> of the industries around LLNs, as well >>>>> as >>>>>> the application experience, I think our goal is to >>>>>> standardize current practice rather than invent new >>>>>> mechanisms. >>>>>> >>>>>> Phil _______________________________________________ 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 >>> >>> >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > From alexandru.petrescu@gmail.com Mon Sep 20 23:47:51 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E63A03A6959 for ; Mon, 20 Sep 2010 23:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZZzbdE10BEV for ; Mon, 20 Sep 2010 23:47:51 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id B40053A6951 for ; Mon, 20 Sep 2010 23:47:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o8L6mBAL027487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Sep 2010 08:48:11 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o8L6mBCl030163; Tue, 21 Sep 2010 08:48:11 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o8L6mAxY001616; Tue, 21 Sep 2010 08:48:11 +0200 Message-ID: <4C98552A.8010908@gmail.com> Date: Tue, 21 Sep 2010 08:48:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: JP Vasseur References: <4C93E7D7.3000603@gmail.com> <293E4334-92BD-460E-AE1D-4F34CD84A665@cisco.com> In-Reply-To: <293E4334-92BD-460E-AE1D-4F34CD84A665@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Sep 2010 06:47:52 -0000 Le 21/09/2010 04:13, JP Vasseur a écrit : > Hi, > > * co-chair hat off * > > On Sep 18, 2010, at 12:12 AM, Alexandru Petrescu wrote: > >> David, >> >> Thanks for this Last Call on the RoLL routing metrics draft. >> >> I reply now just to make sure I replied before the September 30th, >> 2010, the deadline Chair set and that I consider. >> >> I have proposed last year to have energy link metrics: how much >> energy in Joules is required on a particular link to send >> 1280bytes as an IPv6 packet. >> > > First of all, this document specifies a set of link/node routing > metrics/constraint along with various mechanisms to manipulate these > metrics and constraint and needless to say that additional metrics > could be defined in the future. > > I do remember that discussion indeed. The reason for taking into > account the node energy as a metric and/or constraint is obvious. > Now the question that I asked you was: "why would you want to > optimize path against link energy ?". Trying to avoid nodes that are > running out of energy or compute paths so that energy consumption is > even distributed thanks to load balancing is well understood. But I > fail to see how link energy metrics should be used ? Say that you > have n paths and their path cost reflects the amount of energy > required along each of them. Would you choose the least cost path ? YEs. > If so, what if you choose a path traversing a set of battery operated > nodes, instead of a path that may consume more energy but would > traverse nodes for which energy is not a limited factor ? Well, I'd say that if one needs to build a path both low energy emission _and_ consuming least energy on nodes then one would need to use both metrics: link energy and node energy, which could indeed be complex. > Could you describe a use case of link energy metric ? YEs, here's a very simple pictorial: Topology Routing Table of R1 ---- A1---- ---- P3 Dst | Next Hop |Hops | Energy | R1 |-------| R2 |---------| R3 |-- ----------------------------- ---- E1 ---- E2 ---- P3 | A1 | 2 | E1+E2 Legend R1: Router1 E1: Energy value for this link A1: Address of one of R2's interfaces P3: prefix valid on interface In this picture R1 knows not only it takes 2 hops to reach R3 but also it takes energy E1+E2. I hope it is illustrative. Other examples available upon request. >> I have proposed this link metric also as an extension to the >> ripless draft-mulligan-roll-ripless-01. >> > > This document defines routing metrics for RPL. Well, sometimes it is hard to decide in certain contexts whether RPL, RA, RIP or OSPF is more appropriate. But a good metric should work with all of them. It would also be good to exercise the RPL metrics with other routing protocols like RIP, or simple RA of ND. >> In draft-ietf-roll-routing-metrics energy _is_ used as a metric >> but as node energy only, not link energy. >> >> Link metrics _are_ considered in draft-ietf-roll-routing-metrics >> but not as energy. >> >> Private discussion pointed me unilaterally I may be wrong but I >> think publicly I may be right. > > Not sure what you meant here. That is private :-) I meant to say that I was let understand, in private, this link energy metric may not be appropriate for the RPL metrics draft. Alex > > JP. > >> >> I will send more comments later. >> >> Alex >> >> Le 16/09/2010 15:56, David Culler a écrit : >>> The routing metrics draft has now gone through 9 revisions over >>> the past 16 months, the diffs have narrowed to essentially >>> wording and editorial changes, and the comments are few and >>> non-controversial. Thus, it appears that consensus has emerged >>> and we can LC this I-D. >>> >>> This email is to announce Working Group Last Call on >>> draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon >>> PST, Sept. 30 2010. Please read it thoroughly and forward all >>> final comments to the authors and the WG mailing list. >>> >>> Thanks all for your good work. We're on a ROLL. >>> _______________________________________________ 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 jpv@cisco.com Tue Sep 21 00:53:54 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86D173A692A for ; Tue, 21 Sep 2010 00:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.266 X-Spam-Level: X-Spam-Status: No, score=-111.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8ZQiLWx6RQt for ; Tue, 21 Sep 2010 00:53:52 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5781F3A67FA for ; Tue, 21 Sep 2010 00:53:52 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADsBmEyrRN+K/2dsb2JhbACbYYZDcaY9nEqCc4JOBIo4gn4Gglw X-IronPort-AV: E=Sophos;i="4.56,398,1280707200"; d="scan'208";a="592423551" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 21 Sep 2010 07:54:16 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o8L7sGGY003593; Tue, 21 Sep 2010 07:54:16 GMT Received: from xfe-sjc-232.amer.cisco.com ([128.107.191.79]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Sep 2010 00:54:16 -0700 Received: from [10.1.3.251] ([10.61.68.32]) by xfe-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Sep 2010 00:54:15 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: JP Vasseur In-Reply-To: <000001cb58a7$bc501a20$34f04e60$@com> Date: Tue, 21 Sep 2010 08:30:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> <006501cb5758$27f3aa90$77daffb0$@com> <4C9501C7.2060400@gmail.com> <006b01cb577b$6c2f1550$448d3ff0$@com> <4C966485.3070206@gmail.com> <9FB3AA8F-037A-4399-BEF9-38749BB38122@cisco.com> <000001cb58a7$bc501a20$34f04e60$@com> To: "Colin O'Flynn" X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 21 Sep 2010 07:54:15.0648 (UTC) FILETIME=[2FF58E00:01CB5962] Cc: roll@ietf.org Subject: Re: [Roll] ** Multiple PHY/MAC ** Re: WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Sep 2010 07:53:54 -0000 Hi, On Sep 20, 2010, at 11:37 AM, Colin O'Flynn wrote: > Hi JP, >=20 > I think the problem was around the routing metrics themselves somehow = being > L2 dependant. Let me see if I can summarize: >=20 > Thus while there is nothing to stop RPL working between multiple PHY = layers, > as any L3 routing protocol would, there is a question around how the = metrics > reflect different L2 hops.=20 >=20 > Say you had a network with WiFi, 802.15.4, and PLC nodes, with some of = the > nodes having one interface, some having two or more. Does RPL run a = *single* > RPLInstance across the entire network? Colin, do you agree that this is no different than any other routing = protocol. Take the example of OSPF and a set of links: Ethernet, SDH, Optical, ATM. >=20 > Alex's concern is that the routing metric only tells you information = about > how much energy a node has available, not the cost of routing on that = link > when you have vastly different L2 technologies. I understand the point and actually (as seconded by Phil) I still do not = see the=20 application ? >=20 > Thus for example a battery powered 802.15.4 node and a battery powered > cellular node are both reachable and possible paths to a destination. = The > 802.15.4 node may advertise itself as having a certain amount of = energy to > spare, and a cellular node may advertise itself as having less energy = to > spare (smaller E-E value). However this does not reflect the fact the > 802.15.4 node is currently handling no routes, and the cellular node = is > handling ten. The incremental cost of adding a single route to the = 802.15.4 > is higher than for cellular. In this case you need to somehow = advertise not > only how much energy you have or are using, but how much energy you = would > have after carrying a packet. In my example you may end up = oscillating, as > once the 802.15.4 node starts carrying traffic it advertises itself as > having much less available energy and tries to dump the route. Have I > summarized this correctly Alex? But in you case, that would not help. Indeed, even if you knew about of = your energy is needed to send 1bit across a link L, that would not tell you which = path is preferable. Indeed, you may choose a "green" path but going through node with little = energy as battery operated. Thus you would need two values: before and after = routing the packet that the sending node would need to compute by the way, which makes data = processing practically not implementable (or at what cost ???). One could come up = with an algorithm for average # of packets, ... etc but this would be quite complicated = and you may end up consuming more energy that you might saved. >=20 > Perhaps it does make sense to adjust the 'node energy' metric to = advertise > not the currently available power/lifetime as is worded in the draft, = but > somehow work in the power it would take to carry a route/packet = relative to > your available power. Packet of which size ? See previous comment. > So the estimate in E-E is not the current value, but > the expected value after sending some defined number of packets. This = would > at least let you know if you have a node with a tiny battery that just > happens to have no other draw, or a node connected to a car battery = that can > handle your extra packets. This is why we used the estimated % of remaining energy in order to load = balance the=20 traffic in an attempt to prolong the network life duration. Thanks. JP. >=20 > Regards, >=20 > -Colin >=20 > -----Original Message----- > From: JP Vasseur [mailto:jpv@cisco.com]=20 > Sent: September 20, 2010 8:22 AM > To: Alexandru Petrescu > Cc: Colin O'Flynn; roll@ietf.org > Subject: ** Multiple PHY/MAC ** Re: [Roll] WG Last Call on > draft-ietf-roll-routing-metrics-09.txt >=20 > Hold-on ... RPL is a L3 routing protocol, which by itself answers > (hopefully) your > first question. Further, this is clearly stated in the charter. With = regards > to your=20 > second question, these metrics are RPL metrics. >=20 > On Sep 19, 2010, at 9:29 PM, Alexandru Petrescu wrote: >=20 >> [my summary: it is worth clarifying (1) whether RPL runs in a single >> PHY or multiple PHY network, and (2) whether metrics for RPL should = be >> understood in RPL network only or more universal like across the >> Internet. There are also points about whether Rx link energy is as >> important as Tx link energy and its usability overall.] >>=20 >> Hi Colin, >>=20 >> It does make sense to clarify the usage model first, especially the >> assumptions of whether or not RPL runs exclusively on networks made = of >> single PHY, or multiple PHYs. >>=20 >> I consider IP kind of work (do we say IPv6? 'router'?) is needed only = if >> we consider multiple kinds of PHYs in the same network. Otherwise >> bridges, range extenders and other L2 tools are better appropriate = than >> IP routers. >>=20 >> During RPL comments we commented whether RPL draft text should say >> _only_ 802.15.4 or would it include PLC too. I think RPL draft text >> saying _only_ 802.15.4 would make subsequent metrics and security = text >> much easier. However, it was insisted PLC should be there in the = draft. >> So I am in that perspective now. >>=20 >> But does that mean that RPL runs only on a network consisting of PLC >> devices, and on another network of 15.4 devices (separated by an Edge >> Router)? Or does it mean RPL runs in a network mixing 15.4 devices >> with PLC devices each being an RPL router? >>=20 >> This was never clear. >>=20 >> Le 18/09/2010 23:49, Colin O'Flynn a =E9crit : >>> Hi Alex, >>>=20 >>> I think we have some different assumptions about the usage model. It >>> would be useful to clarify some of that first. I'm not claiming my >>> assumptions are correct or consistent with the ROLL/RPL basis, these >>> are simply my view of how I imagined it would all fit together: >>>=20 >>> 1) A single RPL network itself does not cross multiple PHY layers. >>> Crossing PHY layers would complicate the decision on "best routes" >>> partially for the reasons you mention. My comments before showing TX >>> power vs current was showing that for the same PHY layer you can >>> have a huge swing of TX power yet minimal impact on energy required >>> to transmit a packet (100x change in RF energy =3D less than 2x = change >>> in total energy). >>=20 >> (The energy used for transmission is the one measured by setting a = highres > ampermeter serially with the transmitting device, its battery and a = shunt, > make it send an IPv6 packet (type ping). That shows the energy used = for > transmission. This is just a rough view, but basically that is. = There are > related measurement tools like antena placed near emitter (the ones = used to > measure the DAS of mobile phones W/Kg).) >>=20 >>> 2) Routing metrics are not universal, but will somewhat be >>> application-dependant. Thus you can change the metrics for different >>> nodes as required, and metrics might not make sense between >>> different RPL networks (this fits in with assumption #1). >>>=20 >>> Thus my view was the metrics should be simple, as you hide any >>> required customization. If you want to select the outgoing interface >>> you have some artificial change in the metric, where the >>> administrator has basically forced the device to prefer interface 1 >>> over interface 2. >>=20 >> Yes, the metric should be simple. The simplest relates much to what > exists in terms of how IP routers select their output interface = without > artificial human intervention. >>=20 >>> In your given example of an automotive system where they all work on >>> a common power source, the nodes have a specific routing metric >>> where a certain "fudge factor" has been worked into the different >>> nodes. Thus all other things being equal, the advertised metric of a >>> node which takes a lot of energy to transmit is made such that it is >>> less preferred over another node. >>>=20 >>> I think you are assuming that (1) you can have different PHYs within >>> the RPL network, and (2) the routing metrics are more universal, so >>> you can compare two different RPL networks. Is this correct? >>=20 >> Yes, right, that is my assumption: different PHYs within an RPL = network >> and routing metrics more universal - they'd work within the RPL = network >> and across the Internet (like the simple hopcount metric), and one = could >> also compare different RPL networks. >>=20 >> Do we want metrics that work _only_ within an RPL network? Or more > universal like across the Internet? Or both? This is also a = requirement > discussion which is worth clarifying. >>=20 >>> I've included some clarifications below as well (see ), >>> but I think the above two points are most important to understanding >>> why we may see such a wide difference of opinion. >>=20 >> YEs, the above points about RPL running in a single PHY or multiple = PHY > network, and metric only worth in RPL or across the Internet, are = important > to clarify. >>=20 >>> Regards, >>>=20 >>> -Colin >>>=20 >>> -----Original Message----- From: Alexandru Petrescu >>> [mailto:alexandru.petrescu@gmail.com] Sent: September 18, 2010 7:16 >>> PM To: Colin O'Flynn Cc: 'Philip Levis'; roll@ietf.org Subject: Re: >>> [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt >>>=20 >>> Le 18/09/2010 19:37, Colin O'Flynn a =E9crit : >>>> Caveat emptor: I have not read the entire metrics-09 at this >>>> point, but wanted to comment anyway. >>>>=20 >>>> I think the idea of "link energy" would be without much merit, of >>>> course >>> I'm >>>> open to being wrong. My reasoning is as follows: >>>>=20 >>>> 1) There will not be much difference between the energy it takes >>>> to >>> transmit >>>> a packet within a RPL network. They will all be using similar link >>>> layers, >>>=20 >>> Take a car: all devices are on a single unique battery, yet many >>> different copper, light and ether links in terms of energy needed. >>>=20 >>> (in a car - how would a "battery" value of the metric which assumes >>> each IP addressable device has its own "battery" work with RPL? All >>> devices in the car are on the same unique battery, and sometimes on >>> car engine electricity generator. Add to this the Electric Vehicle >>> and you see.) >>>=20 >>>> and much of the power of actually transmitting a packet is not >>>> related to >>> TX >>>> power but getting everything else up (such as CPU running& >>>> processing, >>> PLL >>>> being active and locked, CSMA being performed). >>>=20 >>> That is right. Each transmitting device has CPU chipset to compute >>> wireless coding and that takes energy. That energy is in higher >>> orders of magnitude than actually transmitting. >>>=20 >>> However the energy used to actual Tx (and Rx as in GPS devices) can >>> be clearly distinguished. >>>=20 >>> I meant that you would then require information on both TX& RX >>> power if you wanted to be accurate. So you'd have to add more >>> metrics there, and add two values for every hop. >>=20 >> Hmmm... that sounds right. To be better accurate about link energy >> metrics one would have to do both Tx metric and Rx metric. This = could >> be done. I was thinking that presenting first the Tx link energy = metric >> it would be easier to understand and then add the Rx metric too, > naturally. >>=20 >>>> As an example for one specific radio, the ATMega128RFA1, the >>>> values of current vs power output (from datasheet @ 3.0V): RX PWR >>>> | Supply 3dBm | 14.5mA 1dBm | 10mA -3dBm | 9mA -17dBm | 8mA >>>>=20 >>>> Converting both to mW (=3D mJ/s) RX PWR | Supply 2.00 | 43.5 1.26 = | >>>> 30 0.50 | 27 0.02 | 24 >>>>=20 >>>> This is just current during active TX. >>>=20 >>> That sounds exellent startpoint for design a link energy metric! To >>> eliminate the time paramter (mJ/s) to get to the J only we could >>> decide that we need to transmit 1280bytes of data - the IPv6 minimal >>> MTU. >>>=20 >>>> There are some additional things that are TX power independent, >>>> but I think for any reasonable length 6LoWPAN packet they are much >>>> smaller than the values I have here. >>>=20 >>> Are we IPv6 perspective or not. If yes IPv6 stack needs to know how >>> much energy is needed 1280bytes of data, a minimally sized IPv6 >>> packet. The stack reasons in terms of packets of that or larger >>> size. >>>=20 >>> My example is 802.15.4/6LoWPAN specific, as that was just >>> 802.15.4 packets. I just meant for any reasonable size 802.15.4 >>> packet seen on a 6lowpan/IPv6 network you don't need to worry about >>> CSMA time for example, as it's fairly minimal by comparison. >>=20 >> Well, IPv6 for 802.15.4 RFC says clearly this is minimal IPv6 MTU >> 1280bytes. I am not sure I understand why should IPv6 stack worry = about >> smaller data-link packets but I have to dig this, e.g. see whether = the >> linux stack does consider smaller than 1280bytes or not. >>=20 >>>> 2) Receiving takes around the same amount of power as transmitting >>>> for >>> most >>>> 802.15.4 nodes. For the previously used example that is around >>>> 12mA in >>> fact. >>>> Thus the problem is not only TX power, but RX power. >>>=20 >>> With GPS devices it is even truer, because they only receive. >>>=20 >>>> How do you encapsulate that in "link energy" accurately? >>>=20 >>> Well I proposed a metric bit encoding for it - should I send again? >>>=20 >>> I looked back to I think may 2009 when I saw a discussion about >>> it, if it was before that I probably missed it. >>=20 >> Ok, I will resend tomorrow an an example of encoding energy link = metric >> for RA (it's on my office desktop). >>=20 >>>> If you do it in simple ways with "fudge factors" you've probably >>>> lost enough accuracy to bother doing it at all. >>>=20 >>> I don't propose fudge factors. >>>=20 >>>> 3) Link energy on its own would result in selecting lowest energy >>>> paths I assume. Low power nodes which advertise smaller link >>>> energies have >>> probably >>>> gone to great lengths to get low link energies, since they have low >>>> available power. The nodes which are wall-powered won't try to get >>>> link energy as low since they are free to transmit at highest >>>> energy and not worry too much about power saving tricks. This >>>> would be the opposite of >>> what >>>> you want, so obviously you combine link energy with available >>>> energy. >>>=20 >>> I would not combine. >>>=20 >>> Combine was a poor choice of words on my part. I meant it >>> uses both the link energy& node energy, and "combines" them to >>> create a routing solution. So if you had separate link energy& node >>> energy, figuring out how to use both of them would be a complex >>> problem. >>=20 >> I agree using both node and link energy in a single metric would make = it >> more complex. >>=20 >>>> Combining link energy with available energy would be incredibly >>>> complex to get perfect. Worse if you do it wrong you end up with >>>> the exact opposite >>> of >>>> what you want since low-power paths are used at the expense of >>>> battery >>> life. >>>=20 >>> What is battery life when birth and death is turning an engine >>> on/off? Or when plugging the device on a docking. Or when plugging >>> a vehicle on an outlet. >>>=20 >>>> At least there is some obvious connection between a simple >>>> "available energy" value and "am I likely to be used to route a >>>> packet". >>>=20 >>> Node energy helps it that way, yes. >>>=20 >>>> 4) Transmit energy also depends on link reliability for most >>>> wireless networks, since they have an acknowledgment system. >>>=20 >>> Yes, retransmissions at link layer are a link layer problem, dealt >>> with by power management of the link layer. IP stack cares about = TCP >>> retransmissions or above. >>>=20 >>>> Thus an unreliable link may actually take much more than the >>>> expected power to transmit every >>> frame, >>>> since it's often doing retries. I would expect a few >>>> retransmissions to basically nullify a lot of work selecting the >>>> "most optimum" routes from >>> an >>>> energy perspective. >>>=20 >>> Hmmm... retransmissions may happen too for a node energy metric and >>> that may nullify its effect too. >>>=20 >>> I don't mean retransmission of the metric, I just meant >>> retransmissions in general. It's a question of all this overhead >>> exchanging metrics to maintain a perfect route, when in the end you >>> spent more time maintain your route than routing data! So I think >>> for link energy to be 'accurate', you'd also need to keep the ETX >>> object updated for example. >>=20 >> ETX has been so largely published and apparently implemented that I >> can't disagree with it. However, I see it as a different metric than >> the link energy metric. I guess one could use it differently than = using >> an IP link energy metric. >>=20 >> I think ETX is good when considering particular wireless MAC layer, = but >> wouldn't be useful to qualify other links in the Internet like fiber, >> for example. It is very relevant for the MACs considered by LLNs, I > think. >>=20 >> Alex >>=20 >>=20 >>>=20 >>>> 6) My conclusion from the above points is that the entire question >>>> of >>> RX/TX >>>> power is too complex to bother doing perfectly in these networks. A >>>> simplification that can at least be easily understood and specified >>>> would >>> be >>>> more useful to everyone in the end than something that is more >>>> complex and might not even work. >>>=20 >>> If we wish we could discuss separately the actual use of the = existing >>> node energy metric and I think it's not that simple either. >>>=20 >>>> Using such a metric DOES require external documents to specify how >>>> the metric is used. But requiring external specification to work >>>> out details seems inline with the rest of RPL so shouldn't be a >>>> problem. >>>>=20 >>>> And if in the future I'm completely wrong and someone needs link >>>> energy, I don't see a problem of fitting the link energy into a >>>> TLV in the "node energy object". >>>=20 >>> I am happy to see openness to include link energy metric and I take >>> note for future discussion. >>>=20 >>> But link energy is link energy not node energy. We saw it in the >>> above mAmpere discussion where you eliminated the computing power to >>> which I agreed; yet it doesn't make sense conceptually to put link >>> energy into a node energy container. Link energy values are >>> distinct from node energy values. >>>=20 >>> Alex >>>=20 >>>>=20 >>>> Warm Regards, >>>>=20 >>>> -Colin O'Flynn >>>>=20 >>>>=20 >>>> -----Original Message----- From: roll-bounces@ietf.org >>>> [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: >>>> September 18, 2010 5:11 PM To: Alexandru Petrescu Cc: roll@ietf.org >>>> Subject: Re: [Roll] WG Last Call on >>>> draft-ietf-roll-routing-metrics-09.txt >>>>=20 >>>>=20 >>>> On Sep 17, 2010, at 3:12 PM, Alexandru Petrescu wrote: >>>>=20 >>>>> David, >>>>>=20 >>>>> Thanks for this Last Call on the RoLL routing metrics draft. >>>>>=20 >>>>> I reply now just to make sure I replied before the September >>>>> 30th, 2010, the deadline Chair set and that I consider. >>>>>=20 >>>>> I have proposed last year to have energy link metrics: how much >>>>> energy in Joules is required on a particular link to send >>>>> 1280bytes as an IPv6 packet. >>>>>=20 >>>>> I have proposed this link metric also as an extension to the >>>>> ripless draft-mulligan-roll-ripless-01. >>>>>=20 >>>>> In draft-ietf-roll-routing-metrics energy _is_ used as a metric >>>>> but as node energy only, not link energy. >>>>>=20 >>>>> Link metrics _are_ considered in draft-ietf-roll-routing-metrics >>>>> but not as energy. >>>>>=20 >>>>> Private discussion pointed me unilaterally I may be wrong but I >>>>> think publicly I may be right. >>>>>=20 >>>>> I will send more comments later. >>>>=20 >>>> Alex, >>>>=20 >>>> Can you point me to an application requirements doc, or a concrete >>>> application someone is building today, where link energy is >>>> needed? Given the tremendous size and diversity of the industries >>>> around LLNs, as well >>> as >>>> the application experience, I think our goal is to standardize >>>> current practice rather than invent new mechanisms. >>>>=20 >>>> Phil _______________________________________________ Roll mailing >>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 >=20 From dominique.barthel@orange-ftgroup.com Tue Sep 21 02:37:56 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CF983A695B for ; Tue, 21 Sep 2010 02:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.702, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyggAvGDy751 for ; Tue, 21 Sep 2010 02:37:54 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id EBC3A3A68B1 for ; Tue, 21 Sep 2010 02:37:53 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CA05E7D8003; Tue, 21 Sep 2010 11:41:37 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id B8D8E7D8007; Tue, 21 Sep 2010 11:41:37 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Sep 2010 11:37:06 +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: Tue, 21 Sep 2010 11:36:34 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF019B99DE@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4C98552A.8010908@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt Thread-Index: ActZWSDJgxu0J/B2QwiO2VyxTFRkqQAEX4Ug References: <4C93E7D7.3000603@gmail.com><293E4334-92BD-460E-AE1D-4F34CD84A665@cisco.com> <4C98552A.8010908@gmail.com> From: To: , X-OriginalArrivalTime: 21 Sep 2010 09:37:06.0173 (UTC) FILETIME=[8DE0F2D0:01CB5970] Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Sep 2010 09:37:56 -0000 Hello all, As part of our research activity, we published "academic" papers about = protocols that minimize the total path energy expenditure (sum of link = energies), in a grand vision of saving Energy and our Planet. Many = others did, I can point at publications over 10 years ago, long before = ours. As a co-author of this draft, I pondered on introducing the link energy = metric. As part of an industrial ecosystem, I must say no LLN equipment vendor = today said it needs/wants link energy metric. If there's any such vendor = on this list, please speak up now and state your market/application = characteristics. Now getting technical: Routing purely along minimal energy pathes is nice and saves the Planet, = but it introduces the risk of over-using the same lower energy links, = therefore the same few nodes, which can be energy limited, leading to = shorter node lifetimes. Some nodes die early. Another interesting metric is Max(Min(Remaining_Energy), which routes = around energy-depleted nodes. However, it may use more energy for the = overall path than the above, so all nodes die at the same time but maybe = a little earlier than necessary. In research papers by others and also by my team, hybrid metrics have = been proposed that combine the above two. When nodes have plenty of = energy (eg brand new battery-powered nodes), the network routes along = minimal energy pathes, while when nodes start aging and becoming = energy-depleted, the Max(Min(Remaining_Energy) gradually kicks in to = take the forwarding burden off of the energy-depleted nodes and save = their energy for sensing. I would have loved introducing this hybrid metrics into RPL, but I = resisted for lack of a clearly identified industrial need. I made sure there is nothing that prevents them from being introduced = later, should the need arise. Finally: A major difficulty with link energy in wireless is its inaccuracy. Even = though you can quote joules for your own transmission and for your own = reception, and although you can probably also account for the number of = expected retransmissions, overhearing is a big problem. If you have 100 = nodes in your radio vicinity, the energy cost you should account for for = transmitting on this "link" (from this node) is 100 times higher than = what you thought (assuming L2 broadcast or even L2 unicast and = not-so-smart receivers). My 3.5 c Dominique =20 -----Message d'origine----- De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de = Alexandru Petrescu Envoy=E9 : mardi 21 septembre 2010 08:48 =C0 : JP Vasseur Cc : roll@ietf.org Objet : Re: [Roll] WG Last Call on = draft-ietf-roll-routing-metrics-09.txt Le 21/09/2010 04:13, JP Vasseur a =E9crit : > Hi, > > * co-chair hat off * > > On Sep 18, 2010, at 12:12 AM, Alexandru Petrescu wrote: > >> David, >> >> Thanks for this Last Call on the RoLL routing metrics draft. >> >> I reply now just to make sure I replied before the September 30th,=20 >> 2010, the deadline Chair set and that I consider. >> >> I have proposed last year to have energy link metrics: how much=20 >> energy in Joules is required on a particular link to send 1280bytes=20 >> as an IPv6 packet. >> > > First of all, this document specifies a set of link/node routing=20 > metrics/constraint along with various mechanisms to manipulate these=20 > metrics and constraint and needless to say that additional metrics=20 > could be defined in the future. > > I do remember that discussion indeed. The reason for taking into=20 > account the node energy as a metric and/or constraint is obvious. > Now the question that I asked you was: "why would you want to optimize = > path against link energy ?". Trying to avoid nodes that are running=20 > out of energy or compute paths so that energy consumption is even=20 > distributed thanks to load balancing is well understood. But I fail to = > see how link energy metrics should be used ? Say that you have n paths = > and their path cost reflects the amount of energy required along each=20 > of them. Would you choose the least cost path ? YEs. > If so, what if you choose a path traversing a set of battery operated=20 > nodes, instead of a path that may consume more energy but would=20 > traverse nodes for which energy is not a limited factor ? Well, I'd say that if one needs to build a path both low energy emission = _and_ consuming least energy on nodes then one would need to use both metrics: link energy and node energy, which could indeed be complex. > Could you describe a use case of link energy metric ? YEs, here's a very simple pictorial: Topology Routing Table of R1 ---- A1---- ---- P3 Dst | Next Hop |Hops | = Energy | R1 |-------| R2 |---------| R3 |-- = ----------------------------- ---- E1 ---- E2 ---- P3 | A1 | 2 | E1+E2 Legend R1: Router1 E1: Energy value for this link A1: Address of one of R2's interfaces P3: prefix valid on interface In this picture R1 knows not only it takes 2 hops to reach R3 but also = it takes energy E1+E2. I hope it is illustrative. Other examples = available upon request. >> I have proposed this link metric also as an extension to the ripless=20 >> draft-mulligan-roll-ripless-01. >> > > This document defines routing metrics for RPL. Well, sometimes it is hard to decide in certain contexts whether RPL, = RA, RIP or OSPF is more appropriate. But a good metric should work with = all of them. It would also be good to exercise the RPL metrics with = other routing protocols like RIP, or simple RA of ND. >> In draft-ietf-roll-routing-metrics energy _is_ used as a metric but=20 >> as node energy only, not link energy. >> >> Link metrics _are_ considered in draft-ietf-roll-routing-metrics but=20 >> not as energy. >> >> Private discussion pointed me unilaterally I may be wrong but I think = >> publicly I may be right. > > Not sure what you meant here. That is private :-) I meant to say that I was let understand, in = private, this link energy metric may not be appropriate for the RPL = metrics draft. Alex > > JP. > >> >> I will send more comments later. >> >> Alex >> >> Le 16/09/2010 15:56, David Culler a =E9crit : >>> The routing metrics draft has now gone through 9 revisions over the=20 >>> past 16 months, the diffs have narrowed to essentially wording and=20 >>> editorial changes, and the comments are few and non-controversial.=20 >>> Thus, it appears that consensus has emerged and we can LC this I-D. >>> >>> This email is to announce Working Group Last Call on=20 >>> draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST,=20 >>> Sept. 30 2010. Please read it thoroughly and forward all final=20 >>> comments to the authors and the WG mailing list. >>> >>> Thanks all for your good work. We're on a ROLL. >>> _______________________________________________ Roll mailing list=20 >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> >> >> _______________________________________________ Roll mailing list=20 >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Tue Sep 21 05:07:59 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 245273A69DA; Tue, 21 Sep 2010 05:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.326 X-Spam-Level: X-Spam-Status: No, score=-10.326 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEduCirYe0eM; Tue, 21 Sep 2010 05:07:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5D9883A69D2; Tue, 21 Sep 2010 05:07:55 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,399,1280707200"; d="scan'208";a="64826286" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 21 Sep 2010 12:08:19 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o8LC8JqG014102; Tue, 21 Sep 2010 12:08:19 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Sep 2010 14:08:19 +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: Tue, 21 Sep 2010 14:08:14 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02CE7AE9@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Flow Label: 12 bits mutable and 8 bits immutable Thread-Index: ActY1WiiZ5rtb0cgRXKI4a5iP8/LxAAroI0A References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com><4C9030FF.6060302@oracle.com> From: "Pascal Thubert (pthubert)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "JP Vasseur" X-OriginalArrivalTime: 21 Sep 2010 12:08:19.0283 (UTC) FILETIME=[ADDFAA30:01CB5985] Cc: ROLL WG , IPv6 WG Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Sep 2010 12:07:59 -0000 Hi R=E9mi: It would not.=20 We'll be very glad that 6LoWPAN compresses RPL optimally. But RPL being = layer 2 agnostic cannot depend on 6LoWPAN.=20 Header and IP in IP insertion is problematic on any network, be it for = the MTU issues only. The FL for RPL discussion illustrates that there can be multiple = valuable usages of the field by the network.=20 It mostly shows that tying the usage to local balancing only is probably = short sighted. Cheers, Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of R=E9mi > Despr=E9s > Sent: Saturday, September 18, 2010 4:53 PM > To: JP Vasseur > Cc: IPv6 WG; ROLL WG > Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable >=20 >=20 > Le 18 sept. 2010 =E0 02:22, JP Vasseur a =E9crit : > > On Sep 15, 2010, at 8:51 AM, Carsten Bormann wrote: > > ... > >> > >> However, it would be pretty easy to put something in 6lowpan to = carry those > 3 bytes. > >> (Consider it an advanced form of header compression for the 48-byte > >> IP-in-IP thing, if you don't like the sub-IP thinking.) Consult > http://tools.ietf.org/html/draft-bormann-6lowpan-ext-hdr-00 for a = sample base > design. > >> Such a simple extension may actually be a preferable way to carry = ROLL in > 6lowpan. > > > > "preferable" in which sense ? >=20 > At least, IMHO, in that it eliminates the motivation to interfere with = the current > discussion on improving flow-label utilization. >=20 > Regards, > RD >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Tue Sep 21 06:48:21 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9362B3A6900; Tue, 21 Sep 2010 06:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_20=-0.74, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbCJPUY+lwLG; Tue, 21 Sep 2010 06:48:17 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 6FB5B28C0FD; Tue, 21 Sep 2010 06:48:17 -0700 (PDT) Received: from marajade.sandelman.ca (wlan202.sandelman.ca [209.87.252.202]) by relay.sandelman.ca (Postfix) with ESMTPS id 7BA073446B; Tue, 21 Sep 2010 09:49:28 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id B059D98AA6; Tue, 21 Sep 2010 09:48:39 -0400 (EDT) From: Michael Richardson To: "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02CE7AE9@XMB-AMS-107.cisco.com> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com><4C9030FF.6060302@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02CE7AE9@XMB-AMS-107.cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Sep 2010 09:48:39 -0400 Message-ID: <17405.1285076919@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: =?us-ascii?Q?=3D=3Fiso-8859-1=3FQ=3FR=3DE9mi=5FDespr=3DE9s=3F=3D?= , ROLL WG , IPv6 WG Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Sep 2010 13:48:21 -0000 >>>>> "Pascal" =3D=3D Pascal Thubert <(pthubert)" > wri= tes: Pascal> Hi R=E9mi: Pascal> We'll be very glad that 6LoWPAN compresses RPL Pascal> optimally. But RPL being layer 2 agnostic cannot depend on Only when the security is provide by the layer 2 can the layer 2 do any compression. Otherwise, the encryption of the RPL messages renders the compression useless.=20 Saying that RPL is layer-2 agnostic doesn't mean that it will perform well on all layer-2s. the interface between layer 2 and layer 3 needs to be carefully managed. If you want layer-2 agnostic compression, it has to be done before the encryption, and that means at layer-3. --=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 From pthubert@cisco.com Tue Sep 21 07:49:18 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F68A3A69C1; Tue, 21 Sep 2010 07:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.326 X-Spam-Level: X-Spam-Status: No, score=-10.326 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpWLMTbrWySH; Tue, 21 Sep 2010 07:49:17 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8797B3A6A5C; Tue, 21 Sep 2010 07:49:16 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,400,1280707200"; d="scan'208";a="64840644" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 21 Sep 2010 14:49:40 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o8LEne6F026801; Tue, 21 Sep 2010 14:49:40 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Sep 2010 16:49:40 +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: Tue, 21 Sep 2010 16:49:38 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02CE7C07@XMB-AMS-107.cisco.com> In-Reply-To: <6A525E5A-294B-4E91-ACCA-632A0DCF7C19@free.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Flow Label: 12 bits mutable and 8 bits immutable Thread-Index: ActZiGAKpbNumQn2Q9C/gXwZvDTP0AAEzs1w References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com><4C9030FF.6060302@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02CE7AE9@XMB-AMS-107.cisco.com> <6A525E5A-294B-4E91-ACCA-632A0DCF7C19@free.fr> From: "Pascal Thubert (pthubert)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-OriginalArrivalTime: 21 Sep 2010 14:49:40.0720 (UTC) FILETIME=[3875B700:01CB599C] Cc: ROLL WG , IPv6 WG Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Sep 2010 14:49:18 -0000 It is.=20 But the real world tells us that various MTUs over various paths is = problematic. In particular it creates states in the hosts which can be = subject to attacks. Middle box happen to defeat PMTUD. Encapsulation for = insertion will probably hit the router performance unless there's = special silicon for that operation, which current routers obviously do = not have. Etc... Pascal > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > Sent: Tuesday, September 21, 2010 2:28 PM > To: Pascal Thubert (pthubert) > Cc: JP Vasseur; IPv6 WG; ROLL WG > Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable >=20 >=20 > Le 21 sept. 2010 =E0 14:08, Pascal Thubert (pthubert) a =E9crit : >=20 > > Hi R=E9mi: > > > > It would not. > > > > We'll be very glad that 6LoWPAN compresses RPL optimally. But RPL = being > layer 2 agnostic cannot depend on 6LoWPAN. > > Header and IP in IP insertion is problematic on any network, >=20 > Couldn't the additional header start with e.g. a 0xF so that it can be > distinguished from an IPvX header. > (These 4 bits, plus the 20 that would be sufficient if FLs were to be = used, would > make a nice 3 octets.) It would then be layer-2 agnostic. >=20 > > be it for the MTU issues only. >=20 > Why? > Isn't each traversed link authorized to have its link MTU? >=20 > Cheers, > RD > > > > The FL for RPL discussion illustrates that there can be multiple = valuable > usages of the field by the network. > > It mostly shows that tying the usage to local balancing only is = probably short > sighted. > > > > Cheers, > > > > Pascal > > > >> -----Original Message----- > >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On = Behalf > >> Of R=E9mi Despr=E9s > >> Sent: Saturday, September 18, 2010 4:53 PM > >> To: JP Vasseur > >> Cc: IPv6 WG; ROLL WG > >> Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits = immutable > >> > >> > >> Le 18 sept. 2010 =E0 02:22, JP Vasseur a =E9crit : > >>> On Sep 15, 2010, at 8:51 AM, Carsten Bormann wrote: > >>> ... > >>>> > >>>> However, it would be pretty easy to put something in 6lowpan to > >>>> carry those > >> 3 bytes. > >>>> (Consider it an advanced form of header compression for the = 48-byte > >>>> IP-in-IP thing, if you don't like the sub-IP thinking.) Consult > >> http://tools.ietf.org/html/draft-bormann-6lowpan-ext-hdr-00 for a > >> sample base design. > >>>> Such a simple extension may actually be a preferable way to carry > >>>> ROLL in > >> 6lowpan. > >>> > >>> "preferable" in which sense ? > >> > >> At least, IMHO, in that it eliminates the motivation to interfere > >> with the current discussion on improving flow-label utilization. > >> > >> Regards, > >> RD > >> > >> > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll >=20 From pthubert@cisco.com Tue Sep 21 08:04:44 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59B2B3A692E; Tue, 21 Sep 2010 08:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.475 X-Spam-Level: X-Spam-Status: No, score=-10.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-8yr9+jdGDI; Tue, 21 Sep 2010 08:04:43 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 777AE3A6958; Tue, 21 Sep 2010 08:04:43 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALZmmEyrR7Hu/2dsb2JhbACiKXGnFZw/hUEEjTw X-IronPort-AV: E=Sophos;i="4.56,400,1280707200"; d="scan'208";a="189688723" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 21 Sep 2010 15:05:08 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o8LF4l5C006739; Tue, 21 Sep 2010 15:05:08 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Sep 2010 17:05:06 +0200 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: Tue, 21 Sep 2010 17:05:04 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02CE7C34@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Flow Label: 12 bits mutable and 8 bits immutable Thread-Index: ActZl/m2V2lfT6p5SaGPt/gPUTEeCwAAvgLA References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com><4C9030FF.6060302@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02CE7AE9@XMB-AMS-107.cisco.com> <17405.1285076919@marajade.sandelman.ca> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" , "Michael Richardson" X-OriginalArrivalTime: 21 Sep 2010 15:05:06.0242 (UTC) FILETIME=[601D2A20:01CB599E] Cc: ROLL WG , IPv6 WG Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Sep 2010 15:04:44 -0000 You are correct, Carsten: This also relates to the concept that was evoked earlier in the thread to allow an implicit format on a RPL link. There's no such thing as a RPL link. As you say, RPL control itself does not exhibit the HbH header since most of it is 1 hop - link local. And then a link upon which RPL is active can be shared with other activities that are not RPL related at all. If the HbH is present, then the route lookup will be done along a VRF that is indexed by the instanceID. Other tagging might come in the future. And then there's the default RIB when the router has no better indication in the packet. I like your vlan analogy. It is quite usual in practice to map vlans onto vrfs. Since we are doing route over, we are quite naturally integrating the concepts. For the time being and considering the constraints that apply to RPL, we found that one octet was the right trade off to represent an instance. We'll probably see a day, though, where the concept generalizes, and at that time we'll probably need 4 octets at least. In particular, RPL or something very much like RPL would probably be very interesting in hierarchical access domains like DSL where 1:1 vlans apply today. Take care, Pascal > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Tuesday, September 21, 2010 4:18 PM > To: Michael Richardson > Cc: Pascal Thubert (pthubert); ROLL WG; IPv6 WG > Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable >=20 > On Sep 21, 2010, at 15:48, Michael Richardson wrote: >=20 > > Pascal> We'll be very glad that 6LoWPAN compresses RPL > > Pascal> optimally. But RPL being layer 2 agnostic cannot depend on > > > > Only when the security is provide by the layer 2 can the layer 2 do any > > compression. Otherwise, the encryption of the RPL messages renders the > > compression useless. >=20 > I think Pascal was talking about the encapsulation RPL provides for data packets > (RPL option, draft-ietf-6man-rpl-option-00.txt), not about actual RPL messages. > Do you think the encapsulation information will be encrypted? >=20 > Gruesse, Carsten From pal@cs.stanford.edu Tue Sep 21 09:19:39 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CFDD3A6958 for ; Tue, 21 Sep 2010 09:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.417 X-Spam-Level: X-Spam-Status: No, score=-6.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaK5P78mwpQQ for ; Tue, 21 Sep 2010 09:19:38 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 341C63A6A4F for ; Tue, 21 Sep 2010 09:19:38 -0700 (PDT) Received: from dn0a21034e.sunet ([10.33.3.78]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Oy5Za-00059o-J4; Tue, 21 Sep 2010 09:20:02 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF019B99DE@ftrdmel0.rd.francetelecom.fr> Date: Tue, 21 Sep 2010 09:20:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <510DF90A-F9AF-44B1-AF87-80911A30E34F@cs.stanford.edu> References: <4C93E7D7.3000603@gmail.com><293E4334-92BD-460E-AE1D-4F34CD84A665@cisco.com> <4C98552A.8010908@gmail.com> <8E09C72DBC577D489F13A71228C0B7BF019B99DE@ftrdmel0.rd.francetelecom.fr> To: X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 4c7a780eb20f40a19c8376fd8d8b00d5 Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Sep 2010 16:19:39 -0000 On Sep 21, 2010, at 2:36 AM, = wrote: >=20 > As part of an industrial ecosystem, I must say no LLN equipment vendor = today said it needs/wants link energy metric. If there's any such vendor = on this list, please speak up now and state your market/application = characteristics. Agreed -- does a single one of the huge number of real applications out = there need it? Phil= From gnawali@cs.stanford.edu Tue Sep 21 12:20:06 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C283A6A90 for ; Tue, 21 Sep 2010 12:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.579 X-Spam-Level: X-Spam-Status: No, score=-5.579 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlIhMWuIxnrQ for ; Tue, 21 Sep 2010 12:20:05 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 5CDE13A69A8 for ; Tue, 21 Sep 2010 12:20:05 -0700 (PDT) Received: from mail-iw0-f174.google.com ([209.85.214.174]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1Oy8OE-0004Qu-Ac for roll@ietf.org; Tue, 21 Sep 2010 12:20:30 -0700 Received: by iwn5 with SMTP id 5so5341695iwn.19 for ; Tue, 21 Sep 2010 12:20:29 -0700 (PDT) Received: by 10.231.161.73 with SMTP id q9mr12483772ibx.70.1285096753320; Tue, 21 Sep 2010 12:19:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.145.20 with HTTP; Tue, 21 Sep 2010 12:18:53 -0700 (PDT) In-Reply-To: <20100921191745.2814628C106@core3.amsl.com> References: <20100921191745.2814628C106@core3.amsl.com> From: Omprakash Gnawali Date: Tue, 21 Sep 2010 14:18:53 -0500 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: d3e02c565cd5ac634b2ff74b6ba3e13d Subject: [Roll] Fwd: New Version Notification for draft-gnawali-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Sep 2010 19:20:06 -0000 Dear WG, I just updated the draft to address JP's comment on allowing for leaf nodes= . - om_p ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Tue, Sep 21, 2010 at 2:17 PM Subject: New Version Notification for draft-gnawali-roll-minrank-hysteresis-of-02 To: gnawali@cs.stanford.edu Cc: pal@cs.stanford.edu A new version of I-D, draft-gnawali-roll-minrank-hysteresis-of-02.txt has been successfully submitted by Omprakash Gnawali and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-gnawali-roll-minrank-hysteresis-of Revision: =A0 =A0 =A0 =A002 Title: =A0 =A0 =A0 =A0 =A0 The Minimum Rank Objective Function with Hystere= sis Creation_date: =A0 2010-09-21 WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission Number_of_pages: 8 Abstract: Hysteresis delays the effect of changes in link metric on parent selection. =A0Such delay makes the topology stable despite jitters in link metrics. =A0The Routing Protocol for Low Power and Lossy Networks (RPL) allows the use of objective functions to construct routes that optimize or constrain a routing metric on the paths. =A0This specification describes the Minimum Rank Objective Function with Hysteresis (MRHOF), an objective function that minimizes the node rank in terms of a given metric, while using hysteresis to prevent excessive rank churn. =A0The use of MRHOF with RPL results in nodes selecting stable paths that minimize the given routing metric to the roots of a Directed Acyclic Graph (DAG). The IETF Secretariat. From Jerald.P.Martocci@jci.com Tue Sep 21 12:23:16 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5667A28C126; Tue, 21 Sep 2010 12:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.683 X-Spam-Level: X-Spam-Status: No, score=-2.683 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcBoE6qrRH11; Tue, 21 Sep 2010 12:23:15 -0700 (PDT) Received: from exprod8og119.obsmtp.com (exprod8og119.obsmtp.com [64.18.3.38]) by core3.amsl.com (Postfix) with ESMTP id E4FEF28C119; Tue, 21 Sep 2010 12:23:13 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob119.postini.com ([64.18.7.12]) with SMTP ID DSNKTJkGNXeDI8Pb9yiWaUwi0WNRc2xBeSiy@postini.com; Tue, 21 Sep 2010 12:23:40 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010092114233090-488499 ; Tue, 21 Sep 2010 14:23:30 -0500 In-Reply-To: <510DF90A-F9AF-44B1-AF87-80911A30E34F@cs.stanford.edu> References: <4C93E7D7.3000603@gmail.com><293E4334-92BD-460E-AE1D-4F34CD84A665@cisco.com> <4C98552A.8010908@gmail.com> <8E09C72DBC577D489F13A71228C0B7BF019B99DE@ftrdmel0.rd.francetelecom.fr> <510DF90A-F9AF-44B1-AF87-80911A30E34F@cs.stanford.edu> To: Philip Levis MIME-Version: 1.0 X-KeepSent: 6F97718A:7E0BC855-862577A5:006A1B97; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 FP4 December 11, 2009 From: Jerald.P.Martocci@jci.com Message-ID: Date: Tue, 21 Sep 2010 14:23:29 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 09/21/2010 02:23:31 PM, Serialize complete at 09/21/2010 02:23:31 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 09/21/2010 02:23:30 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 09/21/2010 02:23:39 PM, Serialize complete at 09/21/2010 02:23:39 PM Content-Type: text/html; charset="US-ASCII" Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Sep 2010 19:23:16 -0000
Don't see a need in the commercial building market.  We have battery powered hosts (e.g. temperature sensors), but all our routing devices are powered.


From: Philip Levis <pal@cs.stanford.edu>
To: <dominique.barthel@orange-ftgroup.com>        <dominique.barthel@orange-ftgroup.com>
Cc: roll@ietf.org
Date: 09/21/2010 11:21 AM
Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt





On Sep 21, 2010, at 2:36 AM, <dominique.barthel@orange-ftgroup.com> <dominique.barthel@orange-ftgroup.com> wrote:

>
> As part of an industrial ecosystem, I must say no LLN equipment vendor today said it needs/wants link energy metric. If there's any such vendor on this list, please speak up now and state your market/application characteristics.

Agreed -- does a single one of the huge number of real applications out there need it?

Phil
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

From cabo@tzi.org Tue Sep 21 13:59:30 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB0D3A67C2; Tue, 21 Sep 2010 13:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.162 X-Spam-Level: X-Spam-Status: No, score=-106.162 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HKs0gPdPNsW; Tue, 21 Sep 2010 13:59:29 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 5FBA43A67A3; Tue, 21 Sep 2010 13:59:24 -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 o8LEINxD024251; Tue, 21 Sep 2010 16:18:23 +0200 (CEST) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 93E624F2; Tue, 21 Sep 2010 16:18:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <17405.1285076919@marajade.sandelman.ca> Date: Tue, 21 Sep 2010 16:18:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com><4C9030FF.6060302@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02CE7AE9@XMB-AMS-107.cisco.com> <17405.1285076919@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1081) Cc: IPv6 WG , ROLL WG Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Sep 2010 20:59:30 -0000 On Sep 21, 2010, at 15:48, Michael Richardson wrote: > Pascal> We'll be very glad that 6LoWPAN compresses RPL > Pascal> optimally. But RPL being layer 2 agnostic cannot depend on >=20 > Only when the security is provide by the layer 2 can the layer 2 do = any > compression. Otherwise, the encryption of the RPL messages renders = the > compression useless. I think Pascal was talking about the encapsulation RPL provides for data = packets (RPL option, draft-ietf-6man-rpl-option-00.txt), not about = actual RPL messages. Do you think the encapsulation information will be = encrypted? Gruesse, Carsten From pal@cs.stanford.edu Tue Sep 21 14:07:30 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E879B3A67F8 for ; Tue, 21 Sep 2010 14:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.422 X-Spam-Level: X-Spam-Status: No, score=-6.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rptWos7-OFPG for ; Tue, 21 Sep 2010 14:07:29 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id E5ADA3A676A for ; Tue, 21 Sep 2010 14:07:29 -0700 (PDT) Received: from dn0a21034e.sunet ([10.33.3.78]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OyA4B-0004lZ-4N for roll@ietf.org; Tue, 21 Sep 2010 14:07:55 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Philip Levis In-Reply-To: Date: Tue, 21 Sep 2010 14:07:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8C3431B7-9354-4471-960A-973906A77606@cs.stanford.edu> References: <20100921191745.2814628C106@core3.amsl.com> To: ROLL WG X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 6bee508a35d8245455fa42c2dd36c733 Subject: [Roll] Poll for WG adoption of mrhof X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Sep 2010 21:07:31 -0000 I'd like to poll the WG as to whether we should make MRHOF (minimum rank = hysteresis objective function) a WG document. Om has just published a = new version of the draft (-02) that incorporates comments from JP and = others. The motivation is that, going forward, we as a WG should have an OF that = describes and standardizes current practice. A few reviewers have = pointed out that, to be a full implementable, inter-operable standard, = RPL needs a good objective function. MRHOF essentially just describes = what most networks do today: minimizing rank based on a metric, with a = bit of hysteresis to increase stability at a slight loss of efficiency. = The hysteresis usually actually improves efficiency, as instabilities = can themselves harm performance, for example due to Trickle resets. Comments and feedback are welcome. Here's the URL: http://www.ietf.org/id/draft-gnawali-roll-minrank-hysteresis-of-02.txt Phil= From jpv@cisco.com Wed Sep 22 02:15:46 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1C33A6953 for ; Wed, 22 Sep 2010 02:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.391 X-Spam-Level: X-Spam-Status: No, score=-110.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZP0UI2UWYjX for ; Wed, 22 Sep 2010 02:15:44 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6F83B3A693C for ; Wed, 22 Sep 2010 02:15:44 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKdmmUyrRN+K/2dsb2JhbACiLHGmapwIhUEEijiCfgaHeRQ X-IronPort-AV: E=Sophos;i="4.56,405,1280707200"; d="scan'208";a="593000215" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 22 Sep 2010 09:16:11 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o8M9FuB9010480; Wed, 22 Sep 2010 09:16:10 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Sep 2010 11:16:10 +0200 Received: from [10.1.3.17] ([10.61.102.14]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Sep 2010 11:16:09 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <8C3431B7-9354-4471-960A-973906A77606@cs.stanford.edu> Date: Wed, 22 Sep 2010 11:15:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <090F3E87-FCC6-47F7-86E2-F4A47F48D542@cisco.com> References: <20100921191745.2814628C106@core3.amsl.com> <8C3431B7-9354-4471-960A-973906A77606@cs.stanford.edu> To: Philip Levis X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 22 Sep 2010 09:16:09.0339 (UTC) FILETIME=[CB290CB0:01CB5A36] Cc: ROLL WG , David Culler Subject: Re: [Roll] Poll for WG adoption of mrhof X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 22 Sep 2010 09:15:46 -0000 Hi Phil, If you do not mind, chairs poll for WG adoption.=20 I gave private comments since I had issues with the previous version of = the document (wrt to IETF specification rules, ROLL charter, ...). I did = not get a chance to read the new revision. Thanks for your understanding. JP. On Sep 21, 2010, at 11:07 PM, Philip Levis wrote: > I'd like to poll the WG as to whether we should make MRHOF (minimum = rank hysteresis objective function) a WG document. Om has just published = a new version of the draft (-02) that incorporates comments from JP and = others. >=20 > The motivation is that, going forward, we as a WG should have an OF = that describes and standardizes current practice. A few reviewers have = pointed out that, to be a full implementable, inter-operable standard, = RPL needs a good objective function. MRHOF essentially just describes = what most networks do today: minimizing rank based on a metric, with a = bit of hysteresis to increase stability at a slight loss of efficiency. = The hysteresis usually actually improves efficiency, as instabilities = can themselves harm performance, for example due to Trickle resets. >=20 > Comments and feedback are welcome. Here's the URL: >=20 > http://www.ietf.org/id/draft-gnawali-roll-minrank-hysteresis-of-02.txt >=20 > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From coflynn@newae.com Wed Sep 22 04:34:52 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CE7E3A69BA for ; Wed, 22 Sep 2010 04:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpT2Qd0L4hLk for ; Wed, 22 Sep 2010 04:34:50 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 9916D3A6955 for ; Wed, 22 Sep 2010 04:34:49 -0700 (PDT) Received: from 95-178-201-83.dsl.optinet.hr ([95.178.201.83] helo=COLINNETBOOK) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1OyNbV-0004lQ-S4; Wed, 22 Sep 2010 07:35:15 -0400 From: "Colin O'Flynn" To: "'JP Vasseur'" References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> <006501cb5758$27f3aa90$77daffb0$@com> <4C9501C7.2060400@gmail.com> <006b01cb577b$6c2f1550$448d3ff0$@com> <4C966485.3070206@gmail.com> <9FB3AA8F-037A-4399-BEF9-38749BB38122@cisco.com> <000001cb58a7$bc501a20$34f04e60$@com> In-Reply-To: Date: Wed, 22 Sep 2010 13:35:14 +0200 Message-ID: <004f01cb5a4a$3a6b2050$af4160f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActZYjO+Apg0NcG1QQSEyJV55X5M1QA50OzQ Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: roll@ietf.org Subject: Re: [Roll] ** Multiple PHY/MAC ** Re: WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 22 Sep 2010 11:34:52 -0000 > This is why we used the estimated % of remaining energy in order to = load balance the=20 > traffic in an attempt to prolong the network life duration. Yes but it's pointless as I've said. You could have 80% of a car battery left, or 100% of a button-cell coin battery. By those metrics the button-cell battery will then carry the traffic until it has 80% left at which point it's optimal to switch. The actual metrics at least used desired lifetime, which will result in = this scenario working itself out quicker. But you still waste the energy of discovering that the coin cell battery doesn't like carrying traffic, because once it starts carrying traffic it starts bitching. You should be advertising how much carrying a generic route will affect = the power source. It won't be perfect but it's better IMO.=20 Regards, -Colin -----Original Message----- From: JP Vasseur [mailto:jpv@cisco.com]=20 Sent: September 21, 2010 8:30 AM To: Colin O'Flynn Cc: roll@ietf.org; 'Alexandru Petrescu' Subject: Re: ** Multiple PHY/MAC ** Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt Hi, On Sep 20, 2010, at 11:37 AM, Colin O'Flynn wrote: > Hi JP, >=20 > I think the problem was around the routing metrics themselves somehow being > L2 dependant. Let me see if I can summarize: >=20 > Thus while there is nothing to stop RPL working between multiple PHY layers, > as any L3 routing protocol would, there is a question around how the metrics > reflect different L2 hops.=20 >=20 > Say you had a network with WiFi, 802.15.4, and PLC nodes, with some of = the > nodes having one interface, some having two or more. Does RPL run a *single* > RPLInstance across the entire network? Colin, do you agree that this is no different than any other routing protocol. Take the example of OSPF and a set of links: Ethernet, SDH, Optical, ATM. >=20 > Alex's concern is that the routing metric only tells you information = about > how much energy a node has available, not the cost of routing on that = link > when you have vastly different L2 technologies. I understand the point and actually (as seconded by Phil) I still do not = see the=20 application ? >=20 > Thus for example a battery powered 802.15.4 node and a battery powered > cellular node are both reachable and possible paths to a destination. = The > 802.15.4 node may advertise itself as having a certain amount of = energy to > spare, and a cellular node may advertise itself as having less energy = to > spare (smaller E-E value). However this does not reflect the fact the > 802.15.4 node is currently handling no routes, and the cellular node = is > handling ten. The incremental cost of adding a single route to the 802.15.4 > is higher than for cellular. In this case you need to somehow = advertise not > only how much energy you have or are using, but how much energy you = would > have after carrying a packet. In my example you may end up = oscillating, as > once the 802.15.4 node starts carrying traffic it advertises itself as > having much less available energy and tries to dump the route. Have I > summarized this correctly Alex? But in you case, that would not help. Indeed, even if you knew about of = your energy is needed to send 1bit across a link L, that would not tell you which = path is preferable. Indeed, you may choose a "green" path but going through node with little energy as battery operated. Thus you would need two values: before and after = routing the packet that the sending node would need to compute by the way, which makes data processing practically not implementable (or at what cost ???). One could come up = with an algorithm for average # of packets, ... etc but this would be quite complicated = and you may end up consuming more energy that you might saved. >=20 > Perhaps it does make sense to adjust the 'node energy' metric to = advertise > not the currently available power/lifetime as is worded in the draft, = but > somehow work in the power it would take to carry a route/packet = relative to > your available power. Packet of which size ? See previous comment. > So the estimate in E-E is not the current value, but > the expected value after sending some defined number of packets. This would > at least let you know if you have a node with a tiny battery that just > happens to have no other draw, or a node connected to a car battery = that can > handle your extra packets. This is why we used the estimated % of remaining energy in order to load balance the=20 traffic in an attempt to prolong the network life duration. Thanks. JP. >=20 > Regards, >=20 > -Colin >=20 > -----Original Message----- > From: JP Vasseur [mailto:jpv@cisco.com]=20 > Sent: September 20, 2010 8:22 AM > To: Alexandru Petrescu > Cc: Colin O'Flynn; roll@ietf.org > Subject: ** Multiple PHY/MAC ** Re: [Roll] WG Last Call on > draft-ietf-roll-routing-metrics-09.txt >=20 > Hold-on ... RPL is a L3 routing protocol, which by itself answers > (hopefully) your > first question. Further, this is clearly stated in the charter. With regards > to your=20 > second question, these metrics are RPL metrics. >=20 > On Sep 19, 2010, at 9:29 PM, Alexandru Petrescu wrote: >=20 >> [my summary: it is worth clarifying (1) whether RPL runs in a single >> PHY or multiple PHY network, and (2) whether metrics for RPL should = be >> understood in RPL network only or more universal like across the >> Internet. There are also points about whether Rx link energy is as >> important as Tx link energy and its usability overall.] >>=20 >> Hi Colin, >>=20 >> It does make sense to clarify the usage model first, especially the >> assumptions of whether or not RPL runs exclusively on networks made = of >> single PHY, or multiple PHYs. >>=20 >> I consider IP kind of work (do we say IPv6? 'router'?) is needed only = if >> we consider multiple kinds of PHYs in the same network. Otherwise >> bridges, range extenders and other L2 tools are better appropriate = than >> IP routers. >>=20 >> During RPL comments we commented whether RPL draft text should say >> _only_ 802.15.4 or would it include PLC too. I think RPL draft text >> saying _only_ 802.15.4 would make subsequent metrics and security = text >> much easier. However, it was insisted PLC should be there in the = draft. >> So I am in that perspective now. >>=20 >> But does that mean that RPL runs only on a network consisting of PLC >> devices, and on another network of 15.4 devices (separated by an Edge >> Router)? Or does it mean RPL runs in a network mixing 15.4 devices >> with PLC devices each being an RPL router? >>=20 >> This was never clear. >>=20 >> Le 18/09/2010 23:49, Colin O'Flynn a =E9crit : >>> Hi Alex, >>>=20 >>> I think we have some different assumptions about the usage model. It >>> would be useful to clarify some of that first. I'm not claiming my >>> assumptions are correct or consistent with the ROLL/RPL basis, these >>> are simply my view of how I imagined it would all fit together: >>>=20 >>> 1) A single RPL network itself does not cross multiple PHY layers. >>> Crossing PHY layers would complicate the decision on "best routes" >>> partially for the reasons you mention. My comments before showing TX >>> power vs current was showing that for the same PHY layer you can >>> have a huge swing of TX power yet minimal impact on energy required >>> to transmit a packet (100x change in RF energy =3D less than 2x = change >>> in total energy). >>=20 >> (The energy used for transmission is the one measured by setting a highres > ampermeter serially with the transmitting device, its battery and a = shunt, > make it send an IPv6 packet (type ping). That shows the energy used = for > transmission. This is just a rough view, but basically that is. = There are > related measurement tools like antena placed near emitter (the ones = used to > measure the DAS of mobile phones W/Kg).) >>=20 >>> 2) Routing metrics are not universal, but will somewhat be >>> application-dependant. Thus you can change the metrics for different >>> nodes as required, and metrics might not make sense between >>> different RPL networks (this fits in with assumption #1). >>>=20 >>> Thus my view was the metrics should be simple, as you hide any >>> required customization. If you want to select the outgoing interface >>> you have some artificial change in the metric, where the >>> administrator has basically forced the device to prefer interface 1 >>> over interface 2. >>=20 >> Yes, the metric should be simple. The simplest relates much to what > exists in terms of how IP routers select their output interface = without > artificial human intervention. >>=20 >>> In your given example of an automotive system where they all work on >>> a common power source, the nodes have a specific routing metric >>> where a certain "fudge factor" has been worked into the different >>> nodes. Thus all other things being equal, the advertised metric of a >>> node which takes a lot of energy to transmit is made such that it is >>> less preferred over another node. >>>=20 >>> I think you are assuming that (1) you can have different PHYs within >>> the RPL network, and (2) the routing metrics are more universal, so >>> you can compare two different RPL networks. Is this correct? >>=20 >> Yes, right, that is my assumption: different PHYs within an RPL = network >> and routing metrics more universal - they'd work within the RPL = network >> and across the Internet (like the simple hopcount metric), and one = could >> also compare different RPL networks. >>=20 >> Do we want metrics that work _only_ within an RPL network? Or more > universal like across the Internet? Or both? This is also a = requirement > discussion which is worth clarifying. >>=20 >>> I've included some clarifications below as well (see ), >>> but I think the above two points are most important to understanding >>> why we may see such a wide difference of opinion. >>=20 >> YEs, the above points about RPL running in a single PHY or multiple = PHY > network, and metric only worth in RPL or across the Internet, are important > to clarify. >>=20 >>> Regards, >>>=20 >>> -Colin >>>=20 >>> -----Original Message----- From: Alexandru Petrescu >>> [mailto:alexandru.petrescu@gmail.com] Sent: September 18, 2010 7:16 >>> PM To: Colin O'Flynn Cc: 'Philip Levis'; roll@ietf.org Subject: Re: >>> [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt >>>=20 >>> Le 18/09/2010 19:37, Colin O'Flynn a =E9crit : >>>> Caveat emptor: I have not read the entire metrics-09 at this >>>> point, but wanted to comment anyway. >>>>=20 >>>> I think the idea of "link energy" would be without much merit, of >>>> course >>> I'm >>>> open to being wrong. My reasoning is as follows: >>>>=20 >>>> 1) There will not be much difference between the energy it takes >>>> to >>> transmit >>>> a packet within a RPL network. They will all be using similar link >>>> layers, >>>=20 >>> Take a car: all devices are on a single unique battery, yet many >>> different copper, light and ether links in terms of energy needed. >>>=20 >>> (in a car - how would a "battery" value of the metric which assumes >>> each IP addressable device has its own "battery" work with RPL? All >>> devices in the car are on the same unique battery, and sometimes on >>> car engine electricity generator. Add to this the Electric Vehicle >>> and you see.) >>>=20 >>>> and much of the power of actually transmitting a packet is not >>>> related to >>> TX >>>> power but getting everything else up (such as CPU running& >>>> processing, >>> PLL >>>> being active and locked, CSMA being performed). >>>=20 >>> That is right. Each transmitting device has CPU chipset to compute >>> wireless coding and that takes energy. That energy is in higher >>> orders of magnitude than actually transmitting. >>>=20 >>> However the energy used to actual Tx (and Rx as in GPS devices) can >>> be clearly distinguished. >>>=20 >>> I meant that you would then require information on both TX& RX >>> power if you wanted to be accurate. So you'd have to add more >>> metrics there, and add two values for every hop. >>=20 >> Hmmm... that sounds right. To be better accurate about link energy >> metrics one would have to do both Tx metric and Rx metric. This = could >> be done. I was thinking that presenting first the Tx link energy = metric >> it would be easier to understand and then add the Rx metric too, > naturally. >>=20 >>>> As an example for one specific radio, the ATMega128RFA1, the >>>> values of current vs power output (from datasheet @ 3.0V): RX PWR >>>> | Supply 3dBm | 14.5mA 1dBm | 10mA -3dBm | 9mA -17dBm | 8mA >>>>=20 >>>> Converting both to mW (=3D mJ/s) RX PWR | Supply 2.00 | 43.5 1.26 = | >>>> 30 0.50 | 27 0.02 | 24 >>>>=20 >>>> This is just current during active TX. >>>=20 >>> That sounds exellent startpoint for design a link energy metric! To >>> eliminate the time paramter (mJ/s) to get to the J only we could >>> decide that we need to transmit 1280bytes of data - the IPv6 minimal >>> MTU. >>>=20 >>>> There are some additional things that are TX power independent, >>>> but I think for any reasonable length 6LoWPAN packet they are much >>>> smaller than the values I have here. >>>=20 >>> Are we IPv6 perspective or not. If yes IPv6 stack needs to know how >>> much energy is needed 1280bytes of data, a minimally sized IPv6 >>> packet. The stack reasons in terms of packets of that or larger >>> size. >>>=20 >>> My example is 802.15.4/6LoWPAN specific, as that was just >>> 802.15.4 packets. I just meant for any reasonable size 802.15.4 >>> packet seen on a 6lowpan/IPv6 network you don't need to worry about >>> CSMA time for example, as it's fairly minimal by comparison. >>=20 >> Well, IPv6 for 802.15.4 RFC says clearly this is minimal IPv6 MTU >> 1280bytes. I am not sure I understand why should IPv6 stack worry = about >> smaller data-link packets but I have to dig this, e.g. see whether = the >> linux stack does consider smaller than 1280bytes or not. >>=20 >>>> 2) Receiving takes around the same amount of power as transmitting >>>> for >>> most >>>> 802.15.4 nodes. For the previously used example that is around >>>> 12mA in >>> fact. >>>> Thus the problem is not only TX power, but RX power. >>>=20 >>> With GPS devices it is even truer, because they only receive. >>>=20 >>>> How do you encapsulate that in "link energy" accurately? >>>=20 >>> Well I proposed a metric bit encoding for it - should I send again? >>>=20 >>> I looked back to I think may 2009 when I saw a discussion about >>> it, if it was before that I probably missed it. >>=20 >> Ok, I will resend tomorrow an an example of encoding energy link = metric >> for RA (it's on my office desktop). >>=20 >>>> If you do it in simple ways with "fudge factors" you've probably >>>> lost enough accuracy to bother doing it at all. >>>=20 >>> I don't propose fudge factors. >>>=20 >>>> 3) Link energy on its own would result in selecting lowest energy >>>> paths I assume. Low power nodes which advertise smaller link >>>> energies have >>> probably >>>> gone to great lengths to get low link energies, since they have low >>>> available power. The nodes which are wall-powered won't try to get >>>> link energy as low since they are free to transmit at highest >>>> energy and not worry too much about power saving tricks. This >>>> would be the opposite of >>> what >>>> you want, so obviously you combine link energy with available >>>> energy. >>>=20 >>> I would not combine. >>>=20 >>> Combine was a poor choice of words on my part. I meant it >>> uses both the link energy& node energy, and "combines" them to >>> create a routing solution. So if you had separate link energy& node >>> energy, figuring out how to use both of them would be a complex >>> problem. >>=20 >> I agree using both node and link energy in a single metric would make = it >> more complex. >>=20 >>>> Combining link energy with available energy would be incredibly >>>> complex to get perfect. Worse if you do it wrong you end up with >>>> the exact opposite >>> of >>>> what you want since low-power paths are used at the expense of >>>> battery >>> life. >>>=20 >>> What is battery life when birth and death is turning an engine >>> on/off? Or when plugging the device on a docking. Or when plugging >>> a vehicle on an outlet. >>>=20 >>>> At least there is some obvious connection between a simple >>>> "available energy" value and "am I likely to be used to route a >>>> packet". >>>=20 >>> Node energy helps it that way, yes. >>>=20 >>>> 4) Transmit energy also depends on link reliability for most >>>> wireless networks, since they have an acknowledgment system. >>>=20 >>> Yes, retransmissions at link layer are a link layer problem, dealt >>> with by power management of the link layer. IP stack cares about = TCP >>> retransmissions or above. >>>=20 >>>> Thus an unreliable link may actually take much more than the >>>> expected power to transmit every >>> frame, >>>> since it's often doing retries. I would expect a few >>>> retransmissions to basically nullify a lot of work selecting the >>>> "most optimum" routes from >>> an >>>> energy perspective. >>>=20 >>> Hmmm... retransmissions may happen too for a node energy metric and >>> that may nullify its effect too. >>>=20 >>> I don't mean retransmission of the metric, I just meant >>> retransmissions in general. It's a question of all this overhead >>> exchanging metrics to maintain a perfect route, when in the end you >>> spent more time maintain your route than routing data! So I think >>> for link energy to be 'accurate', you'd also need to keep the ETX >>> object updated for example. >>=20 >> ETX has been so largely published and apparently implemented that I >> can't disagree with it. However, I see it as a different metric than >> the link energy metric. I guess one could use it differently than = using >> an IP link energy metric. >>=20 >> I think ETX is good when considering particular wireless MAC layer, = but >> wouldn't be useful to qualify other links in the Internet like fiber, >> for example. It is very relevant for the MACs considered by LLNs, I > think. >>=20 >> Alex >>=20 >>=20 >>>=20 >>>> 6) My conclusion from the above points is that the entire question >>>> of >>> RX/TX >>>> power is too complex to bother doing perfectly in these networks. A >>>> simplification that can at least be easily understood and specified >>>> would >>> be >>>> more useful to everyone in the end than something that is more >>>> complex and might not even work. >>>=20 >>> If we wish we could discuss separately the actual use of the = existing >>> node energy metric and I think it's not that simple either. >>>=20 >>>> Using such a metric DOES require external documents to specify how >>>> the metric is used. But requiring external specification to work >>>> out details seems inline with the rest of RPL so shouldn't be a >>>> problem. >>>>=20 >>>> And if in the future I'm completely wrong and someone needs link >>>> energy, I don't see a problem of fitting the link energy into a >>>> TLV in the "node energy object". >>>=20 >>> I am happy to see openness to include link energy metric and I take >>> note for future discussion. >>>=20 >>> But link energy is link energy not node energy. We saw it in the >>> above mAmpere discussion where you eliminated the computing power to >>> which I agreed; yet it doesn't make sense conceptually to put link >>> energy into a node energy container. Link energy values are >>> distinct from node energy values. >>>=20 >>> Alex >>>=20 >>>>=20 >>>> Warm Regards, >>>>=20 >>>> -Colin O'Flynn >>>>=20 >>>>=20 >>>> -----Original Message----- From: roll-bounces@ietf.org >>>> [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: >>>> September 18, 2010 5:11 PM To: Alexandru Petrescu Cc: roll@ietf.org >>>> Subject: Re: [Roll] WG Last Call on >>>> draft-ietf-roll-routing-metrics-09.txt >>>>=20 >>>>=20 >>>> On Sep 17, 2010, at 3:12 PM, Alexandru Petrescu wrote: >>>>=20 >>>>> David, >>>>>=20 >>>>> Thanks for this Last Call on the RoLL routing metrics draft. >>>>>=20 >>>>> I reply now just to make sure I replied before the September >>>>> 30th, 2010, the deadline Chair set and that I consider. >>>>>=20 >>>>> I have proposed last year to have energy link metrics: how much >>>>> energy in Joules is required on a particular link to send >>>>> 1280bytes as an IPv6 packet. >>>>>=20 >>>>> I have proposed this link metric also as an extension to the >>>>> ripless draft-mulligan-roll-ripless-01. >>>>>=20 >>>>> In draft-ietf-roll-routing-metrics energy _is_ used as a metric >>>>> but as node energy only, not link energy. >>>>>=20 >>>>> Link metrics _are_ considered in draft-ietf-roll-routing-metrics >>>>> but not as energy. >>>>>=20 >>>>> Private discussion pointed me unilaterally I may be wrong but I >>>>> think publicly I may be right. >>>>>=20 >>>>> I will send more comments later. >>>>=20 >>>> Alex, >>>>=20 >>>> Can you point me to an application requirements doc, or a concrete >>>> application someone is building today, where link energy is >>>> needed? Given the tremendous size and diversity of the industries >>>> around LLNs, as well >>> as >>>> the application experience, I think our goal is to standardize >>>> current practice rather than invent new mechanisms. >>>>=20 >>>> Phil _______________________________________________ Roll mailing >>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 >=20 From jpv@cisco.com Wed Sep 22 04:58:01 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C8653A6978 for ; Wed, 22 Sep 2010 04:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.392 X-Spam-Level: X-Spam-Status: No, score=-110.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ul7Dvro+GYc for ; Wed, 22 Sep 2010 04:57:58 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id C4B733A69AA for ; Wed, 22 Sep 2010 04:57:58 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAK6LmUyrR7H+/2dsb2JhbACbaoZEcaYEnBSCc4JOBIo4gn4Gglw X-IronPort-AV: E=Sophos;i="4.56,406,1280707200"; d="scan'208";a="190314501" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 22 Sep 2010 11:58:25 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o8MBw3xe015598; Wed, 22 Sep 2010 11:58:25 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Sep 2010 13:58:12 +0200 Received: from [10.1.3.148] ([10.61.99.175]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Sep 2010 13:58:10 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: JP Vasseur In-Reply-To: <004f01cb5a4a$3a6b2050$af4160f0$@com> Date: Wed, 22 Sep 2010 13:58:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C93E7D7.3000603@gmail.com> <168DE889-5D19-4F6A-82C1-2482B97D2F94@cs.stanford.edu> <006501cb5758$27f3aa90$77daffb0$@com> <4C9501C7.2060400@gmail.com> <006b01cb577b$6c2f1550$448d3ff0$@com> <4C966485.3070206@gmail.com> <9FB3AA8F-037A-4399-BEF9-38749BB38122@cisco.com> <000001cb58a7$bc501a20$34f04e60$@com> <004f01cb5a4a$3a6b2050$af4160f0$@com> To: "Colin O'Flynn" X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 22 Sep 2010 11:58:10.0666 (UTC) FILETIME=[6D85D4A0:01CB5A4D] Cc: roll@ietf.org Subject: Re: [Roll] ** Multiple PHY/MAC ** Re: WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 22 Sep 2010 11:58:01 -0000 On Sep 22, 2010, at 1:35 PM, Colin O'Flynn wrote: >> This is why we used the estimated % of remaining energy in order to = load > balance the=20 >> traffic in an attempt to prolong the network life duration. >=20 > Yes but it's pointless as I've said. You could have 80% of a car = battery > left, or 100% of a button-cell coin battery. By those metrics the > button-cell battery will then carry the traffic until it has 80% left = at > which point it's optimal to switch. >=20 > The actual metrics at least used desired lifetime, which will result = in this > scenario working itself out quicker. But you still waste the energy of > discovering that the coin cell battery doesn't like carrying traffic, > because once it starts carrying traffic it starts bitching. >=20 > You should be advertising how much carrying a generic route will = affect the > power source. It won't be perfect but it's better IMO.=20 Just turned out to be impractical. Look at the other email. >=20 > Regards, >=20 > -Colin >=20 > -----Original Message----- > From: JP Vasseur [mailto:jpv@cisco.com]=20 > Sent: September 21, 2010 8:30 AM > To: Colin O'Flynn > Cc: roll@ietf.org; 'Alexandru Petrescu' > Subject: Re: ** Multiple PHY/MAC ** Re: [Roll] WG Last Call on > draft-ietf-roll-routing-metrics-09.txt >=20 > Hi, >=20 > On Sep 20, 2010, at 11:37 AM, Colin O'Flynn wrote: >=20 >> Hi JP, >>=20 >> I think the problem was around the routing metrics themselves somehow > being >> L2 dependant. Let me see if I can summarize: >>=20 >> Thus while there is nothing to stop RPL working between multiple PHY > layers, >> as any L3 routing protocol would, there is a question around how the > metrics >> reflect different L2 hops.=20 >>=20 >> Say you had a network with WiFi, 802.15.4, and PLC nodes, with some = of the >> nodes having one interface, some having two or more. Does RPL run a > *single* >> RPLInstance across the entire network? >=20 > Colin, do you agree that this is no different than any other routing > protocol. Take the > example of OSPF and a set of links: Ethernet, SDH, Optical, ATM. >=20 >>=20 >> Alex's concern is that the routing metric only tells you information = about >> how much energy a node has available, not the cost of routing on that = link >> when you have vastly different L2 technologies. >=20 > I understand the point and actually (as seconded by Phil) I still do = not see > the=20 > application ? >=20 >>=20 >> Thus for example a battery powered 802.15.4 node and a battery = powered >> cellular node are both reachable and possible paths to a destination. = The >> 802.15.4 node may advertise itself as having a certain amount of = energy to >> spare, and a cellular node may advertise itself as having less energy = to >> spare (smaller E-E value). However this does not reflect the fact the >> 802.15.4 node is currently handling no routes, and the cellular node = is >> handling ten. The incremental cost of adding a single route to the > 802.15.4 >> is higher than for cellular. In this case you need to somehow = advertise > not >> only how much energy you have or are using, but how much energy you = would >> have after carrying a packet. In my example you may end up = oscillating, as >> once the 802.15.4 node starts carrying traffic it advertises itself = as >> having much less available energy and tries to dump the route. Have I >> summarized this correctly Alex? >=20 > But in you case, that would not help. Indeed, even if you knew about = of your > energy > is needed to send 1bit across a link L, that would not tell you which = path > is preferable. > Indeed, you may choose a "green" path but going through node with = little > energy as > battery operated. Thus you would need two values: before and after = routing > the packet > that the sending node would need to compute by the way, which makes = data > processing > practically not implementable (or at what cost ???). One could come up = with > an algorithm > for average # of packets, ... etc but this would be quite complicated = and > you may end up > consuming more energy that you might saved. >=20 >>=20 >> Perhaps it does make sense to adjust the 'node energy' metric to = advertise >> not the currently available power/lifetime as is worded in the draft, = but >> somehow work in the power it would take to carry a route/packet = relative > to >> your available power. >=20 > Packet of which size ? See previous comment. >=20 >> So the estimate in E-E is not the current value, but >> the expected value after sending some defined number of packets. This > would >> at least let you know if you have a node with a tiny battery that = just >> happens to have no other draw, or a node connected to a car battery = that > can >> handle your extra packets. >=20 > This is why we used the estimated % of remaining energy in order to = load > balance the=20 > traffic in an attempt to prolong the network life duration. >=20 > Thanks. >=20 > JP. >=20 >>=20 >> Regards, >>=20 >> -Colin >>=20 >> -----Original Message----- >> From: JP Vasseur [mailto:jpv@cisco.com]=20 >> Sent: September 20, 2010 8:22 AM >> To: Alexandru Petrescu >> Cc: Colin O'Flynn; roll@ietf.org >> Subject: ** Multiple PHY/MAC ** Re: [Roll] WG Last Call on >> draft-ietf-roll-routing-metrics-09.txt >>=20 >> Hold-on ... RPL is a L3 routing protocol, which by itself answers >> (hopefully) your >> first question. Further, this is clearly stated in the charter. With > regards >> to your=20 >> second question, these metrics are RPL metrics. >>=20 >> On Sep 19, 2010, at 9:29 PM, Alexandru Petrescu wrote: >>=20 >>> [my summary: it is worth clarifying (1) whether RPL runs in a single >>> PHY or multiple PHY network, and (2) whether metrics for RPL should = be >>> understood in RPL network only or more universal like across the >>> Internet. There are also points about whether Rx link energy is as >>> important as Tx link energy and its usability overall.] >>>=20 >>> Hi Colin, >>>=20 >>> It does make sense to clarify the usage model first, especially the >>> assumptions of whether or not RPL runs exclusively on networks made = of >>> single PHY, or multiple PHYs. >>>=20 >>> I consider IP kind of work (do we say IPv6? 'router'?) is needed = only if >>> we consider multiple kinds of PHYs in the same network. Otherwise >>> bridges, range extenders and other L2 tools are better appropriate = than >>> IP routers. >>>=20 >>> During RPL comments we commented whether RPL draft text should say >>> _only_ 802.15.4 or would it include PLC too. I think RPL draft text >>> saying _only_ 802.15.4 would make subsequent metrics and security = text >>> much easier. However, it was insisted PLC should be there in the = draft. >>> So I am in that perspective now. >>>=20 >>> But does that mean that RPL runs only on a network consisting of PLC >>> devices, and on another network of 15.4 devices (separated by an = Edge >>> Router)? Or does it mean RPL runs in a network mixing 15.4 devices >>> with PLC devices each being an RPL router? >>>=20 >>> This was never clear. >>>=20 >>> Le 18/09/2010 23:49, Colin O'Flynn a =E9crit : >>>> Hi Alex, >>>>=20 >>>> I think we have some different assumptions about the usage model. = It >>>> would be useful to clarify some of that first. I'm not claiming my >>>> assumptions are correct or consistent with the ROLL/RPL basis, = these >>>> are simply my view of how I imagined it would all fit together: >>>>=20 >>>> 1) A single RPL network itself does not cross multiple PHY layers. >>>> Crossing PHY layers would complicate the decision on "best routes" >>>> partially for the reasons you mention. My comments before showing = TX >>>> power vs current was showing that for the same PHY layer you can >>>> have a huge swing of TX power yet minimal impact on energy required >>>> to transmit a packet (100x change in RF energy =3D less than 2x = change >>>> in total energy). >>>=20 >>> (The energy used for transmission is the one measured by setting a > highres >> ampermeter serially with the transmitting device, its battery and a = shunt, >> make it send an IPv6 packet (type ping). That shows the energy used = for >> transmission. This is just a rough view, but basically that is. = There > are >> related measurement tools like antena placed near emitter (the ones = used > to >> measure the DAS of mobile phones W/Kg).) >>>=20 >>>> 2) Routing metrics are not universal, but will somewhat be >>>> application-dependant. Thus you can change the metrics for = different >>>> nodes as required, and metrics might not make sense between >>>> different RPL networks (this fits in with assumption #1). >>>>=20 >>>> Thus my view was the metrics should be simple, as you hide any >>>> required customization. If you want to select the outgoing = interface >>>> you have some artificial change in the metric, where the >>>> administrator has basically forced the device to prefer interface 1 >>>> over interface 2. >>>=20 >>> Yes, the metric should be simple. The simplest relates much to what >> exists in terms of how IP routers select their output interface = without >> artificial human intervention. >>>=20 >>>> In your given example of an automotive system where they all work = on >>>> a common power source, the nodes have a specific routing metric >>>> where a certain "fudge factor" has been worked into the different >>>> nodes. Thus all other things being equal, the advertised metric of = a >>>> node which takes a lot of energy to transmit is made such that it = is >>>> less preferred over another node. >>>>=20 >>>> I think you are assuming that (1) you can have different PHYs = within >>>> the RPL network, and (2) the routing metrics are more universal, so >>>> you can compare two different RPL networks. Is this correct? >>>=20 >>> Yes, right, that is my assumption: different PHYs within an RPL = network >>> and routing metrics more universal - they'd work within the RPL = network >>> and across the Internet (like the simple hopcount metric), and one = could >>> also compare different RPL networks. >>>=20 >>> Do we want metrics that work _only_ within an RPL network? Or more >> universal like across the Internet? Or both? This is also a = requirement >> discussion which is worth clarifying. >>>=20 >>>> I've included some clarifications below as well (see ), >>>> but I think the above two points are most important to = understanding >>>> why we may see such a wide difference of opinion. >>>=20 >>> YEs, the above points about RPL running in a single PHY or multiple = PHY >> network, and metric only worth in RPL or across the Internet, are > important >> to clarify. >>>=20 >>>> Regards, >>>>=20 >>>> -Colin >>>>=20 >>>> -----Original Message----- From: Alexandru Petrescu >>>> [mailto:alexandru.petrescu@gmail.com] Sent: September 18, 2010 7:16 >>>> PM To: Colin O'Flynn Cc: 'Philip Levis'; roll@ietf.org Subject: Re: >>>> [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt >>>>=20 >>>> Le 18/09/2010 19:37, Colin O'Flynn a =E9crit : >>>>> Caveat emptor: I have not read the entire metrics-09 at this >>>>> point, but wanted to comment anyway. >>>>>=20 >>>>> I think the idea of "link energy" would be without much merit, of >>>>> course >>>> I'm >>>>> open to being wrong. My reasoning is as follows: >>>>>=20 >>>>> 1) There will not be much difference between the energy it takes >>>>> to >>>> transmit >>>>> a packet within a RPL network. They will all be using similar link >>>>> layers, >>>>=20 >>>> Take a car: all devices are on a single unique battery, yet many >>>> different copper, light and ether links in terms of energy needed. >>>>=20 >>>> (in a car - how would a "battery" value of the metric which assumes >>>> each IP addressable device has its own "battery" work with RPL? = All >>>> devices in the car are on the same unique battery, and sometimes on >>>> car engine electricity generator. Add to this the Electric Vehicle >>>> and you see.) >>>>=20 >>>>> and much of the power of actually transmitting a packet is not >>>>> related to >>>> TX >>>>> power but getting everything else up (such as CPU running& >>>>> processing, >>>> PLL >>>>> being active and locked, CSMA being performed). >>>>=20 >>>> That is right. Each transmitting device has CPU chipset to compute >>>> wireless coding and that takes energy. That energy is in higher >>>> orders of magnitude than actually transmitting. >>>>=20 >>>> However the energy used to actual Tx (and Rx as in GPS devices) can >>>> be clearly distinguished. >>>>=20 >>>> I meant that you would then require information on both TX& = RX >>>> power if you wanted to be accurate. So you'd have to add more >>>> metrics there, and add two values for every hop. >>>=20 >>> Hmmm... that sounds right. To be better accurate about link energy >>> metrics one would have to do both Tx metric and Rx metric. This = could >>> be done. I was thinking that presenting first the Tx link energy = metric >>> it would be easier to understand and then add the Rx metric too, >> naturally. >>>=20 >>>>> As an example for one specific radio, the ATMega128RFA1, the >>>>> values of current vs power output (from datasheet @ 3.0V): RX PWR >>>>> | Supply 3dBm | 14.5mA 1dBm | 10mA -3dBm | 9mA -17dBm | 8mA >>>>>=20 >>>>> Converting both to mW (=3D mJ/s) RX PWR | Supply 2.00 | 43.5 = 1.26 | >>>>> 30 0.50 | 27 0.02 | 24 >>>>>=20 >>>>> This is just current during active TX. >>>>=20 >>>> That sounds exellent startpoint for design a link energy metric! = To >>>> eliminate the time paramter (mJ/s) to get to the J only we could >>>> decide that we need to transmit 1280bytes of data - the IPv6 = minimal >>>> MTU. >>>>=20 >>>>> There are some additional things that are TX power independent, >>>>> but I think for any reasonable length 6LoWPAN packet they are much >>>>> smaller than the values I have here. >>>>=20 >>>> Are we IPv6 perspective or not. If yes IPv6 stack needs to know = how >>>> much energy is needed 1280bytes of data, a minimally sized IPv6 >>>> packet. The stack reasons in terms of packets of that or larger >>>> size. >>>>=20 >>>> My example is 802.15.4/6LoWPAN specific, as that was just >>>> 802.15.4 packets. I just meant for any reasonable size 802.15.4 >>>> packet seen on a 6lowpan/IPv6 network you don't need to worry about >>>> CSMA time for example, as it's fairly minimal by comparison. >>>=20 >>> Well, IPv6 for 802.15.4 RFC says clearly this is minimal IPv6 MTU >>> 1280bytes. I am not sure I understand why should IPv6 stack worry = about >>> smaller data-link packets but I have to dig this, e.g. see whether = the >>> linux stack does consider smaller than 1280bytes or not. >>>=20 >>>>> 2) Receiving takes around the same amount of power as transmitting >>>>> for >>>> most >>>>> 802.15.4 nodes. For the previously used example that is around >>>>> 12mA in >>>> fact. >>>>> Thus the problem is not only TX power, but RX power. >>>>=20 >>>> With GPS devices it is even truer, because they only receive. >>>>=20 >>>>> How do you encapsulate that in "link energy" accurately? >>>>=20 >>>> Well I proposed a metric bit encoding for it - should I send again? >>>>=20 >>>> I looked back to I think may 2009 when I saw a discussion = about >>>> it, if it was before that I probably missed it. >>>=20 >>> Ok, I will resend tomorrow an an example of encoding energy link = metric >>> for RA (it's on my office desktop). >>>=20 >>>>> If you do it in simple ways with "fudge factors" you've probably >>>>> lost enough accuracy to bother doing it at all. >>>>=20 >>>> I don't propose fudge factors. >>>>=20 >>>>> 3) Link energy on its own would result in selecting lowest energy >>>>> paths I assume. Low power nodes which advertise smaller link >>>>> energies have >>>> probably >>>>> gone to great lengths to get low link energies, since they have = low >>>>> available power. The nodes which are wall-powered won't try to get >>>>> link energy as low since they are free to transmit at highest >>>>> energy and not worry too much about power saving tricks. This >>>>> would be the opposite of >>>> what >>>>> you want, so obviously you combine link energy with available >>>>> energy. >>>>=20 >>>> I would not combine. >>>>=20 >>>> Combine was a poor choice of words on my part. I meant it >>>> uses both the link energy& node energy, and "combines" them to >>>> create a routing solution. So if you had separate link energy& = node >>>> energy, figuring out how to use both of them would be a complex >>>> problem. >>>=20 >>> I agree using both node and link energy in a single metric would = make it >>> more complex. >>>=20 >>>>> Combining link energy with available energy would be incredibly >>>>> complex to get perfect. Worse if you do it wrong you end up with >>>>> the exact opposite >>>> of >>>>> what you want since low-power paths are used at the expense of >>>>> battery >>>> life. >>>>=20 >>>> What is battery life when birth and death is turning an engine >>>> on/off? Or when plugging the device on a docking. Or when plugging >>>> a vehicle on an outlet. >>>>=20 >>>>> At least there is some obvious connection between a simple >>>>> "available energy" value and "am I likely to be used to route a >>>>> packet". >>>>=20 >>>> Node energy helps it that way, yes. >>>>=20 >>>>> 4) Transmit energy also depends on link reliability for most >>>>> wireless networks, since they have an acknowledgment system. >>>>=20 >>>> Yes, retransmissions at link layer are a link layer problem, dealt >>>> with by power management of the link layer. IP stack cares about = TCP >>>> retransmissions or above. >>>>=20 >>>>> Thus an unreliable link may actually take much more than the >>>>> expected power to transmit every >>>> frame, >>>>> since it's often doing retries. I would expect a few >>>>> retransmissions to basically nullify a lot of work selecting the >>>>> "most optimum" routes from >>>> an >>>>> energy perspective. >>>>=20 >>>> Hmmm... retransmissions may happen too for a node energy metric and >>>> that may nullify its effect too. >>>>=20 >>>> I don't mean retransmission of the metric, I just meant >>>> retransmissions in general. It's a question of all this overhead >>>> exchanging metrics to maintain a perfect route, when in the end you >>>> spent more time maintain your route than routing data! So I think >>>> for link energy to be 'accurate', you'd also need to keep the ETX >>>> object updated for example. >>>=20 >>> ETX has been so largely published and apparently implemented that I >>> can't disagree with it. However, I see it as a different metric = than >>> the link energy metric. I guess one could use it differently than = using >>> an IP link energy metric. >>>=20 >>> I think ETX is good when considering particular wireless MAC layer, = but >>> wouldn't be useful to qualify other links in the Internet like = fiber, >>> for example. It is very relevant for the MACs considered by LLNs, I >> think. >>>=20 >>> Alex >>>=20 >>>=20 >>>>=20 >>>>> 6) My conclusion from the above points is that the entire question >>>>> of >>>> RX/TX >>>>> power is too complex to bother doing perfectly in these networks. = A >>>>> simplification that can at least be easily understood and = specified >>>>> would >>>> be >>>>> more useful to everyone in the end than something that is more >>>>> complex and might not even work. >>>>=20 >>>> If we wish we could discuss separately the actual use of the = existing >>>> node energy metric and I think it's not that simple either. >>>>=20 >>>>> Using such a metric DOES require external documents to specify how >>>>> the metric is used. But requiring external specification to work >>>>> out details seems inline with the rest of RPL so shouldn't be a >>>>> problem. >>>>>=20 >>>>> And if in the future I'm completely wrong and someone needs link >>>>> energy, I don't see a problem of fitting the link energy into a >>>>> TLV in the "node energy object". >>>>=20 >>>> I am happy to see openness to include link energy metric and I take >>>> note for future discussion. >>>>=20 >>>> But link energy is link energy not node energy. We saw it in the >>>> above mAmpere discussion where you eliminated the computing power = to >>>> which I agreed; yet it doesn't make sense conceptually to put link >>>> energy into a node energy container. Link energy values are >>>> distinct from node energy values. >>>>=20 >>>> Alex >>>>=20 >>>>>=20 >>>>> Warm Regards, >>>>>=20 >>>>> -Colin O'Flynn >>>>>=20 >>>>>=20 >>>>> -----Original Message----- From: roll-bounces@ietf.org >>>>> [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: >>>>> September 18, 2010 5:11 PM To: Alexandru Petrescu Cc: = roll@ietf.org >>>>> Subject: Re: [Roll] WG Last Call on >>>>> draft-ietf-roll-routing-metrics-09.txt >>>>>=20 >>>>>=20 >>>>> On Sep 17, 2010, at 3:12 PM, Alexandru Petrescu wrote: >>>>>=20 >>>>>> David, >>>>>>=20 >>>>>> Thanks for this Last Call on the RoLL routing metrics draft. >>>>>>=20 >>>>>> I reply now just to make sure I replied before the September >>>>>> 30th, 2010, the deadline Chair set and that I consider. >>>>>>=20 >>>>>> I have proposed last year to have energy link metrics: how much >>>>>> energy in Joules is required on a particular link to send >>>>>> 1280bytes as an IPv6 packet. >>>>>>=20 >>>>>> I have proposed this link metric also as an extension to the >>>>>> ripless draft-mulligan-roll-ripless-01. >>>>>>=20 >>>>>> In draft-ietf-roll-routing-metrics energy _is_ used as a metric >>>>>> but as node energy only, not link energy. >>>>>>=20 >>>>>> Link metrics _are_ considered in draft-ietf-roll-routing-metrics >>>>>> but not as energy. >>>>>>=20 >>>>>> Private discussion pointed me unilaterally I may be wrong but I >>>>>> think publicly I may be right. >>>>>>=20 >>>>>> I will send more comments later. >>>>>=20 >>>>> Alex, >>>>>=20 >>>>> Can you point me to an application requirements doc, or a concrete >>>>> application someone is building today, where link energy is >>>>> needed? Given the tremendous size and diversity of the industries >>>>> around LLNs, as well >>>> as >>>>> the application experience, I think our goal is to standardize >>>>> current practice rather than invent new mechanisms. >>>>>=20 >>>>> Phil _______________________________________________ Roll mailing >>>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >>=20 >=20 >=20 From pal@cs.stanford.edu Wed Sep 22 07:01:30 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4303E3A6B0E for ; Wed, 22 Sep 2010 07:01:30 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9qBTwlT6WKN for ; Wed, 22 Sep 2010 07:01:29 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 469E03A69F4 for ; Wed, 22 Sep 2010 07:01:29 -0700 (PDT) Received: from [12.178.149.162] by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OyPtU-0001Fx-8i; Wed, 22 Sep 2010 07:01:56 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <090F3E87-FCC6-47F7-86E2-F4A47F48D542@cisco.com> Date: Wed, 22 Sep 2010 09:01:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100921191745.2814628C106@core3.amsl.com> <8C3431B7-9354-4471-960A-973906A77606@cs.stanford.edu> <090F3E87-FCC6-47F7-86E2-F4A47F48D542@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1081) X-Scan-Signature: ff384b2b9a2989b26e23b1d864f6aba2 Cc: ROLL WG , David Culler Subject: Re: [Roll] Poll for WG adoption of mrhof X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 22 Sep 2010 14:01:30 -0000 On Sep 22, 2010, at 4:15 AM, JP Vasseur wrote: > Hi Phil, >=20 > If you do not mind, chairs poll for WG adoption.=20 > I gave private comments since I had issues with the previous version = of the document (wrt to IETF specification rules, ROLL charter, ...). I = did not get a chance to read the new revision. >=20 > Thanks for your understanding. Sure, sorry about that. I saw Mukul poll for the p2p draft so thought I = would do so as well. For future reference, is this an official part of = IETF process or just something you'd prefer (happy to go along)? Phil= From prvs=8748beeb6=mukul@uwm.edu Wed Sep 22 07:22:14 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC493A6AD4 for ; Wed, 22 Sep 2010 07:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GR-wwPuj6KaU for ; Wed, 22 Sep 2010 07:22:12 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 8C5FF3A6A87 for ; Wed, 22 Sep 2010 07:22:12 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.134]) by ip2mta.uwm.edu with ESMTP; 22 Sep 2010 09:22:39 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 5F9DF1FD05E; Wed, 22 Sep 2010 09:22:39 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMWNRhXUUZOS; Wed, 22 Sep 2010 09:22:38 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id D8C101FD093; Wed, 22 Sep 2010 09:22:38 -0500 (CDT) Date: Wed, 22 Sep 2010 09:22:38 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <1449628946.109107.1285165358794.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.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.7_GA_2473.RHEL5_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL5_64) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] Poll for WG adoption of mrhof X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 22 Sep 2010 14:22:14 -0000 Hi Phil, >Sure, sorry about that. I saw Mukul poll for the p2p draft so thought I would do so as well. For future reference, is this an official part of IETF process or just something you'd prefer (happy to go along)? Here are the emails regarding my request for WG status for p2p draft and the actual poll that JP initiated. Looking at the emails, one can argue both ways whether I initiated the poll or JP did. But the truth is that people responded only to JP's message. My message received a grand total of zero responses. :) Mukul ----- Forwarded Message ----- From: "Mukul Goyal" To: "roll" Sent: Sunday, August 8, 2010 9:32:57 PM Subject: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-02 Hi all, Here is the new version of the P2P draft. It takes in account all the comments received so far. I would like to request WG status for the draft. Comments welcome. Regards Mukul ----- Forwarded Message ----- From: "JP Vasseur" To: "ROLL WG" Sent: Wednesday, August 18, 2010 2:30:09 PM Subject: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group document ? Dear all, draft-dt-roll-p2p-rpl-02.txt has been presented several times and discussed on the mailing list. Could you let us know whether or not you think that draft-dt-roll-p2p-rpl-02.txt should be adopted as a ROLL Working Group document (feel free to justify) ? Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Wed Sep 22 07:36:00 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC8D63A6B01 for ; Wed, 22 Sep 2010 07:36:00 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lfe-V37omea2 for ; Wed, 22 Sep 2010 07:35:56 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 3191E3A6A94 for ; Wed, 22 Sep 2010 07:35:55 -0700 (PDT) Received: from mobile-166-137-142-024.mycingular.net ([166.137.142.24] helo=[10.7.206.2]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OyQQm-00035P-2a; Wed, 22 Sep 2010 07:36:22 -0700 References: <1449628946.109107.1285165358794.JavaMail.root@mail02.pantherlink.uwm.edu> Message-Id: <1505D652-1EBE-4325-B76F-4730F25DB6AB@cs.stanford.edu> From: Philip Levis To: Mukul Goyal In-Reply-To: <1449628946.109107.1285165358794.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Wed, 22 Sep 2010 09:36:10 -0500 X-Scan-Signature: 323acaff36744e8473855e70acc36bcb Cc: roll Subject: Re: [Roll] Poll for WG adoption of mrhof X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 22 Sep 2010 14:36:00 -0000 Ah, ok. Clearly my memory is faulty! Thanks for the clarification. Phil (sent from a phone) On Sep 22, 2010, at 9:22 AM, Mukul Goyal wrote: > Hi Phil, > >> Sure, sorry about that. I saw Mukul poll for the p2p draft so >> thought I would do so as well. For future reference, is this an >> official part of IETF process or just something you'd prefer (happy >> to go along)? > > Here are the emails regarding my request for WG status for p2p draft > and the actual poll that JP initiated. Looking at the emails, one > can argue both ways whether I initiated the poll or JP did. But the > truth is that people responded only to JP's message. My message > received a grand total of zero responses. > > :) > > Mukul > > ----- Forwarded Message ----- > From: "Mukul Goyal" > To: "roll" > Sent: Sunday, August 8, 2010 9:32:57 PM > Subject: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p- > rpl-02 > > Hi all, > > Here is the new version of the P2P draft. It takes in account all > the comments received so far. > > I would like to request WG status for the draft. > > Comments welcome. > > Regards > Mukul > > > ----- Forwarded Message ----- > From: "JP Vasseur" > To: "ROLL WG" > Sent: Wednesday, August 18, 2010 2:30:09 PM > Subject: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working > Group document ? > > Dear all, > > draft-dt-roll-p2p-rpl-02.txt has been presented several times and > discussed on the mailing list. Could you let us know whether or not > you think that draft-dt-roll-p2p-rpl-02.txt should be adopted as a > ROLL Working Group document (feel free to justify) ? > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jeonggil.ko@gmail.com Wed Sep 22 12:01:47 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3F243A6B51 for ; Wed, 22 Sep 2010 12:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySR8VOn2DK-j for ; Wed, 22 Sep 2010 12:01:45 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 9BFFF3A6B40 for ; Wed, 22 Sep 2010 12:00:56 -0700 (PDT) Received: by qwc9 with SMTP id 9so717709qwc.31 for ; Wed, 22 Sep 2010 12:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=odRIJ4raksdga+mAK7jucTLR8ssODxn8H2DrusjdE+U=; b=joOdb/brTKyU3NwtUhFZYJAGLLfrnHsR7FPQV2xwZRS/87OExjV1HlWnusdQyjoMKR 5XpAUDzfcPIzTci7kyQc4WBiv22+uM83/u+cXajeo84A9lZuwaSqTlacup9Wdw8pKqXN xGFEDF7XTFdjRLKM3jPTUpv0TPqfI/tKD3U04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; b=tN3eeh+Q47DJJAWBbBhydDXlx/nq5cOvP+N6RKVOKG+nMu+ZX4C0hWJEqvLsTrmucF QFQ5aH9TdtbbObtfwCoDFqFYteZV8aSiLabJ4XMh5tolEEvYSO4iwjIDPsbghIh8kZoQ F3iZP50P7MuyRN8z0jgMGe4HvHTVqhvD5zesE= Received: by 10.224.65.138 with SMTP id j10mr440536qai.147.1285182083950; Wed, 22 Sep 2010 12:01:23 -0700 (PDT) Received: from jgko.cs.jhu.edu (jgko.cs.jhu.edu [128.220.71.105]) by mx.google.com with ESMTPS id t1sm10603293qcs.45.2010.09.22.12.01.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Sep 2010 12:01:22 -0700 (PDT) Sender: "JeongGil (John) Ko" From: "JeongGil Ko (John)" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Sep 2010 15:01:21 -0400 Message-Id: <2A1BC21C-977E-43D8-BDA2-2CA74D56C8F7@cs.jhu.edu> To: roll WG Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [Roll] Parent selection for leaf nodes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 22 Sep 2010 19:01:47 -0000 Hi. Let's say we have a case where a node 'wants' to join the network as a = leaf node (for various reasons). In this case, I guess the assumption = behind this happening would be that this node cannot (or will not) = understand the OFs in the DODAG. Then among the multiple DIOs it hears = from multiple routers how should the leaf node determine the most = preferred parent node? Since it does not understand the OFs in the DIOs, = it would not be able to compute 'its' rank and thus, will just go for = the node in its reach with the lowest rank (despite that the one hop = link quality to this node can be bad)?=20 Thanks. -John ------ JeongGil Ko (John) Ph.D. Student Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko From mcr@sandelman.ca Wed Sep 22 19:19:41 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B0D3A6956 for ; Wed, 22 Sep 2010 19:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGnC58YgV+Mh for ; Wed, 22 Sep 2010 19:19:40 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id E30D93A68AD for ; Wed, 22 Sep 2010 19:19:39 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 3D7483446F; Wed, 22 Sep 2010 22:21:01 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 5E94698AAA; Wed, 22 Sep 2010 22:20:06 -0400 (EDT) From: Michael Richardson To: "JeongGil Ko (John)" In-Reply-To: <2A1BC21C-977E-43D8-BDA2-2CA74D56C8F7@cs.jhu.edu> References: <2A1BC21C-977E-43D8-BDA2-2CA74D56C8F7@cs.jhu.edu> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Wed, 22 Sep 2010 22:20:06 -0400 Message-ID: <10543.1285208406@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll WG Subject: Re: [Roll] Parent selection for leaf nodes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 23 Sep 2010 02:19:41 -0000 >>>>> "JeongGil" == JeongGil Ko <(John)" > writes: JeongGil> Let's say we have a case where a node 'wants' to join the JeongGil> network as a leaf node (for various reasons). In this JeongGil> case, I guess the assumption behind this happening would JeongGil> be that this node cannot (or will not) understand the OFs JeongGil> in the DODAG. Then among the multiple DIOs it hears from Not understanding the OFs forces a node to join as a leaf. It is not necessarily a "want". There are other reasons to join as a leaf. JeongGil> multiple routers how should the leaf node determine the JeongGil> most preferred parent node? Since it does not understand JeongGil> the OFs in the DIOs, it would not be able to compute 'its' JeongGil> rank and thus, will just go for the node in its reach with JeongGil> the lowest rank (despite that the one hop link quality to JeongGil> this node can be bad)? I think so. If it can locally compute single hop qualities, then it can make a more informed decision, even if it does not understand the OFs to be able to pass that information on. -- ] 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 phoebus@ieee.org Thu Sep 23 00:44:29 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA9E33A6AD4 for ; Thu, 23 Sep 2010 00:44:29 -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_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdWuZ5Zdyhjb for ; Thu, 23 Sep 2010 00:44:28 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id BD1253A6A7A for ; Thu, 23 Sep 2010 00:44:27 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 999E7156F85 for ; Thu, 23 Sep 2010 09:44:25 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id 0FxbtIPLzuPa for ; Thu, 23 Sep 2010 09:44:22 +0200 (CEST) X-KTH-Auth: phoebus [130.237.43.217] X-KTH-mail-from: phoebus@ieee.org X-KTH-rcpt-to: roll@ietf.org Received: from dhcp-43-217.s3.kth.se (dhcp-43-217.s3.kth.se [130.237.43.217]) by smtp-1.sys.kth.se (Postfix) with ESMTP id CC54F156FAF for ; Thu, 23 Sep 2010 09:44:22 +0200 (CEST) Message-ID: <4C9B0556.9090305@ieee.org> Date: Thu, 23 Sep 2010 09:44:22 +0200 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "roll@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine metrics in the A field X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: phoebus@ieee.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 07:44:29 -0000 I'm in the midst of making a pass through routing-metrics-09, and a question I (and others) asked earlier keeps coming up back in my head: Why are we specifying how to combine the metrics in the DAG metric container? Can't it be specified in the OF? Here was the old thread (way back in April): http://www.ietf.org/mail-archive/web/roll/current/msg03815.html JP's response: http://www.ietf.org/mail-archive/web/roll/current/msg03768.html The argument was to not have a flood of new RFCs specifying OFs for each possible new way of combining metrics. OK. But say that we do want to use a combination of add, max, min, multiplication, or some other operator to combine some of these metrics. What do we set in the "A" field of the Routing Metric/Constraint object depicted in Figure 2? I would prefer to replace "A=0x03: The routing metric is multiplicative" with "A=0x03: The routing metric is aggregated in some other fashion specified by the objective function." Or, there should be a sentence in the specification saying that the objective function can "override" and ignore this field (and MUST set A=0x00 if the OF plans for the A field to be ignored). I noticed that the text in Section 8 of routing-metrics-08 : "The use of compound metrics, such as a polynomial function of individual metric values, will be described in a future revision of this document." has been removed in routing-metrics-09. Given the rigidity of the A field, I'm not sure that we can specify compound metrics in future OFs. I'll send more comments about the rest of the document soon. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 9/16/10 3:56 PM, David Culler wrote: > The routing metrics draft has now gone through 9 revisions over the > past 16 months, the diffs have narrowed to essentially wording and > editorial changes, and the comments are few and non-controversial. > Thus, it appears that consensus has emerged and we can LC this I-D. > > This email is to announce Working Group Last Call on > draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST, > Sept. 30 2010. Please read it thoroughly and forward all final > comments to the authors and the WG mailing list. > > Thanks all for your good work. We're on a ROLL. > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From joakime@sics.se Thu Sep 23 01:26:59 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6A423A6AC4 for ; Thu, 23 Sep 2010 01:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTu424J2GO-V for ; Thu, 23 Sep 2010 01:26:59 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id D76433A69E8 for ; Thu, 23 Sep 2010 01:26:58 -0700 (PDT) Received: from [193.10.67.77] (harr.sics.se [193.10.67.77]) by letter.sics.se (Postfix) with ESMTPS id 51C8A40115; Thu, 23 Sep 2010 10:27:27 +0200 (CEST) Message-ID: <4C9B0F77.9090008@sics.se> Date: Thu, 23 Sep 2010 10:27:35 +0200 From: Joakim Eriksson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: roll@ietf.org References: <4C9B0556.9090305@ieee.org> In-Reply-To: <4C9B0556.9090305@ieee.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine metrics in the A field X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 23 Sep 2010 08:27:00 -0000 I agree with this! It would be much easier to add some type of OF specific "metrics-container" that could carry descriptions on how to combine the metrics. If we have that any future OF could use that OF-configuration container and use the information in that container (in whatever format that specific OF defines). Then we could define OF-Generic1 that handles additive and multiplicative metrics, and that has some very simple configuration container that describe how to handle the metrics. Later we can add the OF-Generic2 that handles constraints, and more advanced combinations of metrics - this without forcing all other OFs to be almost-generic. Best regards, -- Joakim Eriksson, SICS Phoebus Chen skrev 2010-09-23 09:44: > I'm in the midst of making a pass through routing-metrics-09, and a > question I (and others) asked earlier keeps coming up back in my head: > > Why are we specifying how to combine the metrics in the DAG metric > container? Can't it be specified in the OF? > > Here was the old thread (way back in April): > http://www.ietf.org/mail-archive/web/roll/current/msg03815.html > JP's response: > http://www.ietf.org/mail-archive/web/roll/current/msg03768.html > > The argument was to not have a flood of new RFCs specifying OFs for each > possible new way of combining metrics. OK. > > But say that we do want to use a combination of add, max, min, > multiplication, or some other operator to combine some of these metrics. > What do we set in the "A" field of the Routing Metric/Constraint object > depicted in Figure 2? I would prefer to replace "A=0x03: The routing > metric is multiplicative" with "A=0x03: The routing metric is aggregated > in some other fashion specified by the objective function." Or, there > should be a sentence in the specification saying that the objective > function can "override" and ignore this field (and MUST set A=0x00 if > the OF plans for the A field to be ignored). > > I noticed that the text in Section 8 of routing-metrics-08 : > "The use of compound metrics, such as a polynomial function of > individual metric values, will be described in a future revision of this > document." > has been removed in routing-metrics-09. Given the rigidity of the A > field, I'm not sure that we can specify compound metrics in future OFs. > > > I'll send more comments about the rest of the document soon. > -- -- Joakim From alexandru.petrescu@gmail.com Thu Sep 23 01:30:49 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A94E13A6AE9 for ; Thu, 23 Sep 2010 01:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRJZ5YrCcdkh for ; Thu, 23 Sep 2010 01:30:48 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 0D15D3A6B60 for ; Thu, 23 Sep 2010 01:30:45 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o8N8VDsZ030205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 23 Sep 2010 10:31:13 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o8N8VDj5029613 for ; Thu, 23 Sep 2010 10:31:13 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o8N8VCMF007782 for ; Thu, 23 Sep 2010 10:31:13 +0200 Message-ID: <4C9B1050.3050003@gmail.com> Date: Thu, 23 Sep 2010 10:31:12 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: roll@ietf.org References: <4C9B0556.9090305@ieee.org> <4C9B0F77.9090008@sics.se> In-Reply-To: <4C9B0F77.9090008@sics.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine metrics in the A field X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 23 Sep 2010 08:30:49 -0000 Le 23/09/2010 10:27, Joakim Eriksson a écrit : > I agree with this! > > It would be much easier to add some type of OF specific > "metrics-container" that could carry descriptions on how to combine > the metrics. I agree with an idea of "metrics container". One would try metrics in practice first with another routing protocol than RPL, to make sure the metrics themselves are ok. Independent testing of metrics (independend of RPL) reassures the metrics themselves are fine. It would be good to suggest metric encodings (containers) working with the widely available RA, RIP and OSPF and then to RPL which is under development. Alex > > If we have that any future OF could use that OF-configuration > container and use the information in that container (in whatever > format that specific OF defines). Then we could define OF-Generic1 > that handles additive and multiplicative metrics, and that has some > very simple configuration container that describe how to handle the > metrics. Later we can add the OF-Generic2 that handles constraints, > and more advanced combinations of metrics - this without forcing all > other OFs to be almost-generic. > > > > Best regards, -- Joakim Eriksson, SICS > > > Phoebus Chen skrev 2010-09-23 09:44: >> I'm in the midst of making a pass through routing-metrics-09, and >> a question I (and others) asked earlier keeps coming up back in my >> head: >> >> Why are we specifying how to combine the metrics in the DAG metric >> container? Can't it be specified in the OF? >> >> Here was the old thread (way back in April): >> http://www.ietf.org/mail-archive/web/roll/current/msg03815.html >> JP's response: >> http://www.ietf.org/mail-archive/web/roll/current/msg03768.html >> >> The argument was to not have a flood of new RFCs specifying OFs for >> each possible new way of combining metrics. OK. >> >> But say that we do want to use a combination of add, max, min, >> multiplication, or some other operator to combine some of these >> metrics. What do we set in the "A" field of the Routing >> Metric/Constraint object depicted in Figure 2? I would prefer to >> replace "A=0x03: The routing metric is multiplicative" with >> "A=0x03: The routing metric is aggregated in some other fashion >> specified by the objective function." Or, there should be a >> sentence in the specification saying that the objective function >> can "override" and ignore this field (and MUST set A=0x00 if the OF >> plans for the A field to be ignored). >> >> I noticed that the text in Section 8 of routing-metrics-08 : "The >> use of compound metrics, such as a polynomial function of >> individual metric values, will be described in a future revision of >> this document." has been removed in routing-metrics-09. Given the >> rigidity of the A field, I'm not sure that we can specify compound >> metrics in future OFs. >> >> >> I'll send more comments about the rest of the document soon. >> > > From alexandru.petrescu@gmail.com Thu Sep 23 01:46:56 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0151E3A6AAD for ; Thu, 23 Sep 2010 01:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYfxnEad0ztt for ; Thu, 23 Sep 2010 01:46:51 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id AB02C28C0EC for ; Thu, 23 Sep 2010 01:46:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o8N8lBif008427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Sep 2010 10:47:11 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o8N8lBa6003405; Thu, 23 Sep 2010 10:47:11 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o8N8lAXE016321; Thu, 23 Sep 2010 10:47:10 +0200 Message-ID: <4C9B140E.7050305@gmail.com> Date: Thu, 23 Sep 2010 10:47:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Philip Levis References: <4C93E7D7.3000603@gmail.com><293E4334-92BD-460E-AE1D-4F34CD84A665@cisco.com> <4C98552A.8010908@gmail.com> <8E09C72DBC577D489F13A71228C0B7BF019B99DE@ftrdmel0.rd.francetelecom.fr> <510DF90A-F9AF-44B1-AF87-80911A30E34F@cs.stanford.edu> In-Reply-To: <510DF90A-F9AF-44B1-AF87-80911A30E34F@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 23 Sep 2010 08:46:56 -0000 Le 21/09/2010 18:20, Philip Levis a écrit : > > On Sep 21, 2010, at 2:36 AM, > wrote: > >> >> As part of an industrial ecosystem, I must say no LLN equipment >> vendor today said it needs/wants link energy metric. If there's >> any such vendor on this list, please speak up now and state your >> market/application characteristics. > > Agreed -- does a single one of the huge number of real applications > out there need it? I wanted to leave a silence space and answer now. The real applications in this space are so numerous that it looks hard to avoid some of them actually using link energy metrics. Independently of node vs link we're clear energy metrics are required. The metrics draft offers a node energy metric as 3 distinctive values: "powered", "battery", "scavenger". I am not sure how to fit this metric in a vehicle where all devices are on the same battery - (1) they all should use the same value hence can't make any distinction powered-battery-scavenger, (2) is that value "powered" or "battery"? For that vehicular and other reasons I believe node energy metrics are not sufficient and link metrics are necessary: in a vehicle where each link has a distinctive link energy metric we can have a routing protocol make decisions based on link energy metrics (rather than the unique battery value). As for the vendor question: which LLN equipment vendor needs this? This is something which may be exhibited here or not, now or later. For now I think of link energy metrics as a technical issue worth taking into account. If technically it makes sense then a richer menu of options may tempt vendors more to choose among ways to make money out of it. Alex From coflynn@newae.com Thu Sep 23 02:01:19 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF163A6B41 for ; Thu, 23 Sep 2010 02:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CW0hNFg4sjYd for ; Thu, 23 Sep 2010 02:01:14 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id A760A3A6B24 for ; Thu, 23 Sep 2010 02:01:14 -0700 (PDT) Received: from 78-3-84-45.adsl.net.t-com.hr ([78.3.84.45] helo=COLINNETBOOK) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1OyhgU-0008If-Nc for roll@ietf.org; Thu, 23 Sep 2010 05:01:43 -0400 From: "Colin O'Flynn" To: Date: Thu, 23 Sep 2010 11:00:50 +0200 Message-ID: <001201cb5afd$f0e7f430$d2b7dc90$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01CB5B0E.B470C430" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acta/dDBadKuY0P8SjadVirFMaiuWg== Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: [Roll] Node Energy Measuring Stick X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 23 Sep 2010 09:01:19 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0013_01CB5B0E.B470C430 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, As the previous thread on link energy somewhat split into multiple discussions, I'd like to bring what I think is an important point to a separate thread. So far only JP has chimed in on this discussion but if I'm wrong I'd at least like to hear it from more than one person ;-) The proposed energy metrics in the metrics-09 measures battery power as a relative scale of "desired lifetime" to "current estimated lifetime". This is good since it allows you to specify a non-replaceable node has e.g. a 10 year desired lifetime. What this misses is some way to advertise the capacity of the battery. This is important as it is impossible to know with the current metric until after you start using the node if it is a car battery or a button coin cell. I would propose the node energy takes into account the cost of carrying some arbitrarily defined route. For example use the same metric (estimated lifetime/desired lifetime) but have the estimated lifetime include "estimated lifetime while carrying route". The arbitrary route will need to be defined. Ideally it would somehow reflect the actual usage, but in reality it might need to just be something like "sending a RPL DIO every hour". If this needs to be studied more it could simply be left to another/outside document to define how this "example usage" is used. I think even having a very simple estimated usage would be a huge improvement though as I there is no way to know what the incremental cost of adding a route to the node will be until you actually add it with the current proposal. Regards, -Colin O'Flynn ------=_NextPart_000_0013_01CB5B0E.B470C430 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

As the previous thread on link energy somewhat = split into multiple discussions, I’d like to bring what I think is an = important point to a separate thread. So far only JP has chimed in on this = discussion but if I’m wrong I’d at least like to hear it from more than one = person ;-)

 

The proposed energy metrics in the metrics-09 = measures battery power as a relative scale of “desired lifetime” to = “current estimated lifetime”. This is good since it allows you to specify a = non-replaceable node has e.g. a 10 year desired lifetime.

 

What this misses is some way to advertise the = capacity of the battery. This is important as it is impossible to know with the = current metric until after you start using the node if it is a car battery or a = button coin cell.

 

I would propose the node energy takes into account = the cost of carrying some arbitrarily defined route. For example use the same = metric (estimated lifetime/desired lifetime) but have the estimated lifetime = include “estimated lifetime while carrying route”. The arbitrary route will need to = be defined. Ideally it would somehow reflect the actual usage, but in = reality it might need to just be something like “sending a RPL DIO every = hour”.

 

If this needs to be studied more it could simply be = left to another/outside document to define how this “example usage” = is used. I think even having a very simple estimated usage would be a huge = improvement though as I there is no way to know what the incremental cost of adding = a route to the node will be until you actually add it with the current proposal. =

 

Regards,

 

    -Colin = O’Flynn

------=_NextPart_000_0013_01CB5B0E.B470C430-- From alexandru.petrescu@gmail.com Thu Sep 23 02:13:48 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D2683A6B24 for ; Thu, 23 Sep 2010 02:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghiD+XSIFt0p for ; Thu, 23 Sep 2010 02:13:46 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 590703A69C2 for ; Thu, 23 Sep 2010 02:13:46 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o8N9EBjo026625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Sep 2010 11:14:11 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o8N9EBoK014327; Thu, 23 Sep 2010 11:14:11 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o8N9EAt5030094; Thu, 23 Sep 2010 11:14:11 +0200 Message-ID: <4C9B1A62.3040709@gmail.com> Date: Thu, 23 Sep 2010 11:14:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: dominique.barthel@orange-ftgroup.com References: <4C93E7D7.3000603@gmail.com><293E4334-92BD-460E-AE1D-4F34CD84A665@cisco.com> <4C98552A.8010908@gmail.com> <8E09C72DBC577D489F13A71228C0B7BF019B99DE@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF019B99DE@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 23 Sep 2010 09:13:48 -0000 Le 21/09/2010 11:36, dominique.barthel@orange-ftgroup.com a écrit : > Hello all, > > As part of our research activity, we published "academic" papers > about protocols that minimize the total path energy expenditure (sum > of link energies), in a grand vision of saving Energy and our > Planet. Many others did, I can point at publications over 10 years > ago, long before ours. As a co-author of this draft, I pondered on > introducing the link energy metric. As part of an industrial > ecosystem, I must say no LLN equipment vendor today said it > needs/wants link energy metric. Well depends who one talks to. I think any base station manufacturer facing court against "robin des toits" has given much thought about how much energy their links put in the air. > If there's any such vendor on this list, please speak up now and > state your market/application characteristics. > > Now getting technical: Routing purely along minimal energy pathes is > nice and saves the Planet, but it introduces the risk of over-using > the same lower energy links, therefore the same few nodes, which can > be energy limited, leading to shorter node lifetimes. Some nodes die > early. Hmm... it depends. I agree with you that in some networks if node local energy is not considered then routing according only to link energy metrics may overlook some nodes dying loosing their energy. > Another interesting metric is Max(Min(Remaining_Energy), which > routes around energy-depleted nodes. Interesting, yes. > However, it may use more energy for the overall path than the above, > so all nodes die at the same time but maybe a little earlier than > necessary. Interesting. > In research papers by others and also by my team, hybrid metrics Research papers: yes there are several such papers talking link energy metrics, "energy consumed per packet transferred", "power required to transmit a signal", "energy-based link costs". I will have to go look the research papers you mention about hybrid metrics too. > have been proposed that combine the above two. When nodes have plenty > of energy (eg brand new battery-powered nodes), the network routes > along minimal energy pathes, while when nodes start aging and > becoming energy-depleted, the Max(Min(Remaining_Energy) gradually > kicks in to take the forwarding burden off of the energy-depleted > nodes and save their energy for sensing. I would have loved > introducing this hybrid metrics into RPL, but I resisted for lack of > a clearly identified industrial need. I made sure there is nothing > that prevents them from being introduced later, should the need > arise. Well, would the hybrid concept be able to hybridize node and link energy metrics? If yes then I am interested. > Finally: A major difficulty with link energy in wireless is its > inaccuracy. Even though you can quote joules for your own > transmission and for your own reception, and although you can > probably also account for the number of expected retransmissions, > overhearing is a big problem. Yes, overhearing and interference and fading are big problems. They all affect the way current metrics are designed anyways, in unexpected manners. > If you have 100 nodes in your radio vicinity, the energy cost you > should account for for transmitting on this "link" (from this node) > is 100 times higher than what you thought (assuming L2 broadcast or > even L2 unicast and not-so-smart receivers). Well yes, your phrase sounds ok to me, provided we talk PHY level. Maybe at IP level we don't worry less about overhearing, interference and fading. In comparison: I don't see how node energy metrics are not affected by same uncertainty factors too: "battery" working is often influenced by ambiant temperature, age. Alex > > My 3.5 c > > Dominique > > > -----Message d'origine----- De : roll-bounces@ietf.org > [mailto:roll-bounces@ietf.org] De la part de Alexandru Petrescu > Envoyé : mardi 21 septembre 2010 08:48 À : JP Vasseur Cc : > roll@ietf.org Objet : Re: [Roll] WG Last Call on > draft-ietf-roll-routing-metrics-09.txt > > Le 21/09/2010 04:13, JP Vasseur a écrit : >> Hi, >> >> * co-chair hat off * >> >> On Sep 18, 2010, at 12:12 AM, Alexandru Petrescu wrote: >> >>> David, >>> >>> Thanks for this Last Call on the RoLL routing metrics draft. >>> >>> I reply now just to make sure I replied before the September >>> 30th, 2010, the deadline Chair set and that I consider. >>> >>> I have proposed last year to have energy link metrics: how much >>> energy in Joules is required on a particular link to send >>> 1280bytes as an IPv6 packet. >>> >> >> First of all, this document specifies a set of link/node routing >> metrics/constraint along with various mechanisms to manipulate >> these metrics and constraint and needless to say that additional >> metrics could be defined in the future. >> >> I do remember that discussion indeed. The reason for taking into >> account the node energy as a metric and/or constraint is obvious. >> Now the question that I asked you was: "why would you want to >> optimize path against link energy ?". Trying to avoid nodes that >> are running out of energy or compute paths so that energy >> consumption is even distributed thanks to load balancing is well >> understood. But I fail to see how link energy metrics should be >> used ? Say that you have n paths and their path cost reflects the >> amount of energy required along each of them. Would you choose the >> least cost path ? > > YEs. > >> If so, what if you choose a path traversing a set of battery >> operated nodes, instead of a path that may consume more energy but >> would traverse nodes for which energy is not a limited factor ? > > Well, I'd say that if one needs to build a path both low energy > emission _and_ consuming least energy on nodes then one would need to > use both metrics: link energy and node energy, which could indeed be > complex. > >> Could you describe a use case of link energy metric ? > > YEs, here's a very simple pictorial: > > Topology Routing Table of R1 > > ---- A1---- ---- P3 Dst | Next Hop |Hops | Energy | > R1 |-------| R2 |---------| R3 |-- ----------------------------- > ---- E1 ---- E2 ---- P3 | A1 | 2 | E1+E2 > > Legend R1: Router1 E1: Energy value for this link A1: Address of one > of R2's interfaces P3: prefix valid on interface > > In this picture R1 knows not only it takes 2 hops to reach R3 but > also it takes energy E1+E2. I hope it is illustrative. Other > examples available upon request. > > >>> I have proposed this link metric also as an extension to the >>> ripless draft-mulligan-roll-ripless-01. >>> >> >> This document defines routing metrics for RPL. > > Well, sometimes it is hard to decide in certain contexts whether RPL, > RA, RIP or OSPF is more appropriate. But a good metric should work > with all of them. It would also be good to exercise the RPL metrics > with other routing protocols like RIP, or simple RA of ND. > >>> In draft-ietf-roll-routing-metrics energy _is_ used as a metric >>> but as node energy only, not link energy. >>> >>> Link metrics _are_ considered in draft-ietf-roll-routing-metrics >>> but not as energy. >>> >>> Private discussion pointed me unilaterally I may be wrong but I >>> think publicly I may be right. >> >> Not sure what you meant here. > > That is private :-) I meant to say that I was let understand, in > private, this link energy metric may not be appropriate for the RPL > metrics draft. > > Alex > >> >> JP. >> >>> >>> I will send more comments later. >>> >>> Alex >>> >>> Le 16/09/2010 15:56, David Culler a écrit : >>>> The routing metrics draft has now gone through 9 revisions over >>>> the past 16 months, the diffs have narrowed to essentially >>>> wording and editorial changes, and the comments are few and >>>> non-controversial. Thus, it appears that consensus has emerged >>>> and we can LC this I-D. >>>> >>>> This email is to announce Working Group Last Call on >>>> draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon >>>> PST, Sept. 30 2010. Please read it thoroughly and forward all >>>> final comments to the authors and the WG mailing list. >>>> >>>> Thanks all for your good work. We're on a ROLL. >>>> _______________________________________________ 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 >> >> > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From phoebus@ieee.org Thu Sep 23 03:47:26 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDFE03A6929 for ; Thu, 23 Sep 2010 03:47:26 -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_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgiL0irID-Kg for ; Thu, 23 Sep 2010 03:47:25 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 5B6393A68FD for ; Thu, 23 Sep 2010 03:47:25 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 68690156FEF for ; Thu, 23 Sep 2010 12:47:23 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id X0wTwjRMQmzL for ; Thu, 23 Sep 2010 12:47:20 +0200 (CEST) X-KTH-Auth: phoebus [130.237.43.217] X-KTH-mail-from: phoebus@ieee.org X-KTH-rcpt-to: roll@ietf.org Received: from dhcp-43-217.s3.kth.se (dhcp-43-217.s3.kth.se [130.237.43.217]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 9738A156FAF for ; Thu, 23 Sep 2010 12:47:19 +0200 (CEST) Message-ID: <4C9B3037.4090209@ieee.org> Date: Thu, 23 Sep 2010 12:47:19 +0200 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "roll@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Clarification on Node Fanout Ratio Object X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: phoebus@ieee.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 10:47:26 -0000 I'm a little confused about the Node Fanout Ratio (NFR) Object in Section 3.4 . Does fanout refer to outgoing links (upward, to a parents), or incoming links (downward, from children) of a node? The text says: "The Node Fanout Ratio (NFR) object is used to provide information on the nodes current forwarding load." From this, I would read fanout to mean the number of incoming links, if you are concerned with upward routing. The amount of traffic you have to forward depends on the amount of traffic coming in, which might be roughly related to the number of children. But as far as I know, RPL nodes only keep track of parents, not of children, so it cannot keep track of the number of incoming links. Or is the NFR object is used for optimizing the topology for downward routing (related to DAO fanout), to get path diversity / reliability? If this is the case, perhaps this should be explained in the metrics document. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 9/16/10 3:56 PM, David Culler wrote: > The routing metrics draft has now gone through 9 revisions over the > past 16 months, the diffs have narrowed to essentially wording and > editorial changes, and the comments are few and non-controversial. > Thus, it appears that consensus has emerged and we can LC this I-D. > > This email is to announce Working Group Last Call on > draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST, > Sept. 30 2010. Please read it thoroughly and forward all final > comments to the authors and the WG mailing list. > > Thanks all for your good work. We're on a ROLL. > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From phoebus@ieee.org Thu Sep 23 06:38:04 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCE4F3A6AD5 for ; Thu, 23 Sep 2010 06:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.749 X-Spam-Level: X-Spam-Status: No, score=-103.749 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va2SALK4Kxuq for ; Thu, 23 Sep 2010 06:37:58 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id 8CA623A6968 for ; Thu, 23 Sep 2010 06:37:57 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id D77B914F12B for ; Thu, 23 Sep 2010 15:37:55 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id fT87lWJpx3Qf for ; Thu, 23 Sep 2010 15:37:52 +0200 (CEST) X-KTH-Auth: phoebus [130.237.43.217] X-KTH-mail-from: phoebus@ieee.org X-KTH-rcpt-to: roll@ietf.org Received: from dhcp-43-217.s3.kth.se (dhcp-43-217.s3.kth.se [130.237.43.217]) by smtp-2.sys.kth.se (Postfix) with ESMTP id E974714D7D5 for ; Thu, 23 Sep 2010 15:37:51 +0200 (CEST) Message-ID: <4C9B582F.1060108@ieee.org> Date: Thu, 23 Sep 2010 15:37:51 +0200 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "roll@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Editorial Comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: phoebus@ieee.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 13:38:04 -0000 General Editorial Comments for the authors: 1) I suggest moving Section 6 on "Use of multiple DAG Metric Container" into Section 2 "Object formats." It's near the end of the document, yet it says "In the rest of this document, this use of multiple DAG Metric Containers will be considered as if they were actually just one long DAG Metric Container." 2) I suggest moving Section 7 "Metric consistency" into Section 1 "Introduction". (Also, maybe the point being made in this section is obvious?) 3) I suggest moving Section 8 "Metric Usage" into a subsection of Section 2, or somewhere earlier in the document. It will shed more light when the precedence field is first discussed. Of course, the text will need to mention that the metrics mentioned in the examples will be defined in more detail in Sections 3 and 4. 4) Section 8 gives an example of how to break ties in metrics. What happens when there is a tie in the precedence field between two metrics? Is this not allowed? Is it broken in the order of the objects in the metric container (as it was before in version 8 of the document)? Or is the behavior in this case "beyond the scope of this document," and must be resolved by the Objective Function? 5) Section 9 is still incomplete... is this OK for last call? Only the NSA and Hop-count objects are described in 9.3 and 9.4 respectively. 6) Section 1 "Introduction" has a long discussion on Dynamic vs. Static Metrics, after classifying the links according to characteristics (paragraphs 1, 3-5 after the list on pg. 5). I suggest a shorter description and deferring / moving the bulk of the discussion to Section 5 "Computation of dynamic metrics and attributes." Or at least, present this discussion after the discussion on the other classifications (which turns out to just be one sentence on link and node metrics not being exclusive), following the order of the list. 7) In many of the object formats, several of the descriptions of the flags/fields do not follow the order of the flags/fields in the object. See Figure 2 and the following description, Figure 3 and the following description, and Figure 5 and the following description. It would be a little easier to read if the orders matched. 8) In several figures, the last Byte indices above the objects are partially missing. Not a big deal, but it looks a little sloppy leaving them off. 9) There are misspelled words throughout the document... please run it through a spell checker after making the final edits. Nits below. Search for comments preceded by PC>. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus Networking Working Group JP. Vasseur, Ed. Internet-Draft Cisco Systems, Inc Intended status: Standards Track M. Kim, Ed. Expires: March 9, 2011 Corporate Technology Group, KT K. Pister Dust Networks N. Dejean Coronis SAS D. Barthel France Telecom Orange September 5, 2010 Routing Metrics used for Path Calculation in Low Power and Lossy Networks draft-ietf-roll-routing-metrics-09 Abstract Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks that require the specification of new routing metrics and constraints. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing for Low Power and lossy networks (RPL) routing protocol. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Vasseur, et al. Expires March 9, 2011 [Page 1] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 This Internet-Draft will expire on March 9, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Vasseur, et al. Expires March 9, 2011 [Page 2] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Object formats . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Node Metric/Constraint objects . . . . . . . . . . . . . . . . 9 3.1. Node State and Attributes object . . . . . . . . . . . . . 10 3.2. Node Energy object . . . . . . . . . . . . . . . . . . . . 11 3.3. Hop-Count object . . . . . . . . . . . . . . . . . . . . . 14 3.4. Node Fanout Ratio object . . . . . . . . . . . . . . . . . 15 4. Link Metric/Constraint objects . . . . . . . . . . . . . . . . 16 4.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3. Link reliability . . . . . . . . . . . . . . . . . . . . . 18 4.3.1. The Link Quality Level reliability metric . . . . . . 19 4.3.2. The Expected Transmission Count (ETX) reliability object . . . . . . . . . . . . . . . . . . . . . . . . 21 4.4. Link Color object . . . . . . . . . . . . . . . . . . . . 22 4.4.1. Link Color object description . . . . . . . . . . . . 22 4.4.2. Mode of operation . . . . . . . . . . . . . . . . . . 24 5. Computation of dynamic metrics and attributes . . . . . . . . 24 6. Use of multiple DAG Metric Container . . . . . . . . . . . . . 25 7. Metric consistency . . . . . . . . . . . . . . . . . . . . . . 25 8. Metric usage . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 9.1. Routing Metric/Constraint type . . . . . . . . . . . . . . 26 9.2. Routing Metric/Constraint common header . . . . . . . . . 27 9.3. NSA object . . . . . . . . . . . . . . . . . . . . . . . . 27 9.4. Hop-Count object . . . . . . . . . . . . . . . . . . . . . 28 10. Security considerations . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 12.1. Normative references . . . . . . . . . . . . . . . . . . . 29 12.2. Informative references . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Vasseur, et al. Expires March 9, 2011 [Page 3] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 1. Introduction This document makes use of the terminology defined in [I-D.ietf-roll-terminology]. Low power and Lossy Networks (LLNs) have specific routing characteristics compared with traditional wired or ad-hoc networks that have been spelled out in [RFC5548], [RFC5673], [RFC5826] and [RFC5867]. Historically, IGP such as OSPF ([RFC2328]) and IS-IS ([RFC1195]) have used quantitative static link metrics. Other mechanisms such as Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) (see [RFC2702] and [RFC3209]) make use of other link attributes such as the available reserved bandwidth (dynamic) or link affinities (most of the time static) to compute constrained shortest paths for Traffic Engineering Label Switched Paths (TE LSPs). This document specifies routing metrics and constraints to be used in path calculation by the Routing Protocol for Low Power and Lossy Networks (RPL) specified in [I-D.ietf-roll-rpl]. One of the prime objectives of this document is to propose a flexible mechanism for the advertisement of routing metrics and constraints used by RPL. Some RPL implementations may elect to adopt an extremely simple approach based on the use of a single metric with no constraint whereas other implementations may use a larger set of link and node routing metrics and constraints. This specification provides a high degree of flexibility and a set of routing metrics and constraints. New routing metrics and constraints could be defined in the future, as needed. RPL is a distance vector routing protocol that builds Directed Acyclic Graphs (DAGs) based on routing metrics and constraints. DAG formation rules are defined in [I-D.ietf-roll-rpl]: o The DAG root may advertise a routing constraint used as a "filter" to prune links and nodes that do not satisfy specific properties. For example, it may be required for the path to only traverse nodes that are mains powered or links that have at least a minimum reliability or a specific "color" reflecting a user defined link characteristic (e.g the link layer supports encryption). o A routing metric is a quantitative value that is used to evaluate the path cost. Link and nodes metrics are usually (but not always) additive. The best path is the path with the lowest cost with respect to some Vasseur, et al. Expires March 9, 2011 [Page 4] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 metrics that satisfies all constraints (if any) and is also called the shortest constrained path (in the presence of constraints). Routing metrics can be classified according to the following set of characteristics: o Link versus Node metrics o Qualitative versus quantitative o Dynamic versus static It must be noted that the use of dynamic metrics is not new and has been experimented in ARPANET 2 [Khanna1989], with moderate success. The use of dynamic metrics is not trivial and great care must be given to the use of dynamic metrics since it may lead to potential routing instabilities. it must be noted that the use of dynamic metrics has been largely experimented and deployed in a number of (non IP) networks in the past decade. As pointed out in various routing requirements documents (see [RFC5673], [RFC5826] [RFC5548] and [RFC5867]), it must be possible to take into account a variety of node constraints/metrics during path computation. It is also worth mentioning that it is fairly common for links in LLNs to have fast changing node and link characteristics, which must be taken into account when specifying routing metrics. For instance, in addition to the dynamic nature of some links (e.g. wireless but also Poweline Communication (PLC) links, nodes' resources such as residual energy and other link's charatacteristics such as the throughput are changing continuously and may have to be taken into account during the path computation. Similarly, link attributes including throughput and reliability may drastically change over time due to multi-path interference. Very careful attention must be given when using dynamic metrics and attributes that affect routing decisions in order to preserve routing stability. Routing metrics and constraints may either be static or dynamic. When dynamic, a RPL implementation SHOULD make use of a multi-threshold scheme rather than fine granular metric updates so as to avoid constant routing changes. Furthermore, it is a time and energy consuming process to update dynamic metrics and recompute the routing tables on a frequent basis. Therefore, it may be desirable to use a set of discrete values to reduce computational overhead and bandwidth utilization. Of course, this comes with a cost, namely, reduced metric accuracy. In other Vasseur, et al. Expires March 9, 2011 [Page 5] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 cases, a set of flags may be defined to reflect a node state without having to define discrete values. Some link or node characteristics (e.g. link reliability flag, remaining energy on the node) may either be used by RPL as routing constraints or metric. For example, the path may be computed to PC> s/metric/metrics/ avoid links that do not provide a sufficient level of reliability (use as a constraint) or as the path offering the maximum number of links with a specified reliability level (use as a metric). The PC> path offering the maximum fraction / proportion of links with a specified reliability level? Paths with more good links might be longer. document provides the flexibility to use link and node charaterisics either as constraints and/or metrics. The set of routing metrics and constraints used by an RPL implementation is signalled along the Directed Acyclic Graph (DAG) that is built according to the Objective Function (rules governing how to build a DAG) and the routing metrics and constraints are advertised in the DAG Information Option (DIO) message specified in [I-D.ietf-roll-rpl]. RPL may be used to build DAGs with different characteristics. For example, it may be desirable to build a DAG with the goal to maximize reliability by using the link reliability metric to compute the "best" path. Another example might be to use the energy node characteristic (e.g. mains powered versus battery operated) as a node constraint when building the DAG so as to avoid battery powered nodes in the DAG while optimizing the link throughput. Links and nodes routing metrics and constraints are not exclusive. PC> s/Links and nodes/ Link and node/ Since they are being used as adjectives here. The requirements on reporting frequency may differ among metrics, thus different reporting rates may be used for each category and are consequently implementatin-specific. The specification of objective functions used to compute the DAG built by RPL is out of the scope of this document. Routing metrics and constraints are decoupled from the objective function. So a generic objective function could for example specify the rules to select the best parents in the DAG, the number of backup parents, etc. Such objective function can be used with any routing metrics and/or contraints such as the ones specified in this document. Some metrics are either aggregated or recorded. In the former case, the metric is adjusted as the DIO message travels along the DAG. For example, if the metric is the link latency, each node updates the latency metric along the DAG. By contrast, a metric may be recorded in which case each node adds a sub-object reflecting the local metric. For example, it might be desirable to record the link quality level along the path. In this case, each visited node adds a sub-object reporting the local link quality level. In order to limit Vasseur, et al. Expires March 9, 2011 [Page 6] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 the number of sub-objects, the use of a counter may be desirable (e.g. record the number of links with a certain link quality level), thus compressing the information to reduce the message lenght. Upon receiving the DIO message from a set of parents, a node can decide accoding to the OF and local policy which node to choose as a parent based on the maximum number of links with a specific link reliability level for example. PC> level, for example. Note that the routing metrics are constrained specified in this PC> s/are constrained/and constraints/ document are not specific to any link layer. Internal API between PC> An internal API... the MAC layer and RPL may advantageously be used to accurately PC> remove "advantageously" reflect the metrics values of the link (wireless, wired, PLC). 2. Object formats Routing metrics and constraints are carried within the DAG Metric Container object defined in [I-D.ietf-roll-rpl]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Type=2 | Option Len | Routing Metric/Constraint objects +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 1: DAG Metric Container format The Routing Metric/Contraints objects have a common format consisting PC> s/Contraints/Constraint/ of one or more 8-bit words with a common header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Routing-MC-Type| Flags |P|C|0|R| A | Prec | Length (bytes)| PC> |Routing-MC-Type| Res |P|C|O|R| A | Prec | Length (bytes)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (object body) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Routing Metric/Constraint object generic format The object body carries one or more sub-objects. Note that the Routing Metric/Constraint objects defined in this document can appear in any order in the DAG Metric Container. Vasseur, et al. Expires March 9, 2011 [Page 7] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 Routing-MC-Type (Routing Metric/Contraint Type - 8 bits): the Routing Metric/Constraint Type field uniquely identifies each Routing Metric/ Constraint object and is managed by IANA. Length: this field defines the length of the object body, in bytes. The Flag field of the Routing Metric/Constraint object is managed by IANA. Unassigned bits are considered as reserved. They MUST be set to zero on transmission and MUST be ignored on receipt. o C Flag. When set, this indicates that the Routing Metric/ Constraint object refers to a routing constraint. When cleared, the routing object refers to a routing metric. o O Flag: The O flag is used exclusively for routing constraints (C flag is set). When set, this indicates that the constraint is optional. When cleared, the constraint is mandatory. If the C flag is zero, the O flag MUST be set to zero on transmission and ignored on reception. o R Flag: The R Flag is only relevant for routing metric (C=0) and MUST be cleared for C=1. When set, this indicates that the routing metric is recorded along the path. Conversely, when cleared, the routing metric is aggregated. o A Field: The A field is used to indicate whether an aggregated routing metric is additive, multiplicative, reports a maximum or a minimum. * A=0x00: The routing metric is additive * A=0x01: The routing metric reports a maximum * A=0x02: The routing metric reports a minimum * A=0x03: The routing metric is multiplicative The A field has no meaning when the C Flag is set (i.e. when the Routing Metric/Constraint object refers to a routing constraint) and MUST be written to 0x00. o Prec field: The P field indicates the precedence of this Routing Metric/Constraint object. This is useful when a DAG Metric Container contains several Routing Metric objects. The value 0 means the highest precedence. The precedence field can be used as a tie-breaker in the presence of the multiple metrics advertising the same value. Vasseur, et al. Expires March 9, 2011 [Page 8] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 o P field: the P field is only used for recorded metric. When PC> s/metric/metrics/ cleared, all nodes along the path managed to recorded the PC> s/recorded/record/ corresponding link metric. When set, this indicates than one of PC> remove "link"; s/of/or/ more nodes along the path could not record the metric of interest (either because of lack of knowledge or because this was prevented by policy). Example 1: A DAG formed by RPL where all nodes must be main-powered PC> mains-powered and the best path is the one with lower aggregated ETX. In this case the DAG Metric container carries two Routing Metric/Constraint objects: one is an ETX metric object with header (C=0, O=0, A=00, R=0) and the second one is a Node Energy constraint with header (C=1, PC> s/constraint/constraint object/ O=0, A=00, R=0). Note that a RPL instance may use the metric object to report a maximum (A=0x01) or a minimum (A=0x02). If the best path is characterized by the path avoiding low quality links for example, PC> Replace with "If, for example, the best path is characterized by the path avoiding low quality links," then the path metric reports a maximum (A=0x01) (note that higher values mean lower link quality): when the link quality metric (ETX) is processed along a path, each node updates its value if the current PC> s/current/node's current/; There is some implicit assumption that the reader understands that "its value" refers to the node's ETX, which corresponds to the ETX of the best path to the root it knows thus far. And that the "node's current link ETX" is for the link to its parent. Not sure how to easily fix the sentence so it's clearer. link ETX value is higher than the value carried by the metric object. Example 2: A DAG formed by RPL where the link metric is the link quality level and link quality levels must be recorded along the path. In this case, the DAG Metric Container carries a Routing Metric/Constraint object: link quality level metric (C=0, O=0, A=00, R=1) containing multiple sub-objects. A Routing Metric/Constraint object may also include one or more type- length-value (TLV) encoded data sets. Each Routing Metric/Constraint TLV has the same structure: Type: 1 byte Length: 1 byte Value: variable A Routing Metric/Constraint TLV is comprised of 1 byte for the type, 1 byte specifying the TLV length, and a value field. The TLV length field defines the length of the value field in bytes. Unrecognized TLVs MUST be ignored. IANA management of the Routing Metric/Constraint objects identifier codespace is described in Section 9. 3. Node Metric/Constraint objects It is fairly common for LLNs to be made of nodes with heterogeneous attributes and capabilities (e.g. nodes being battery operated or Vasseur, et al. Expires March 9, 2011 [Page 9] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 not, amount of memory, etc). More capable and stable nodes may assist the most constrained ones for routing packets, which results in extension of network lifetime and efficient network operations. This is a typical (but non exclusive) use of constraint-based routing PC> s/non exclusive/non-exclusive/; s/routing/routing,/ where the computed path may not be the shortest path according to some specified metrics. Another use is to find the shortest path according to a pre-defined metric while avoiding link with a specific PC> s/link/links/ color (for example "non secured link"). PC> s/non secured/non-secured/ 3.1. Node State and Attributes object The Node State and Attribute (NSA) object is used to provide information on the nodes characteristics. The NSA object MAY be present in the DAG Metric Container. There MUST be no more than one NSA object as a constraint per DAG Metric Container, and no more than one NSA object as a metric per DAG Metric Container. The NSA object may also contain a set of TLVs used to convey various node characteristics. No TLV is currently defined. The NSA Routing Metric/Constraint Type is to be assigned by IANA (recommended value=1). The format of the NSA object body is as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Res | Flags |A|O| Optional TLVs +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 3: NSA object format Node workload may be hard to determine and expressed in some scalar form. However, node workload could be a useful metric to consider during path calculation, in particular when queuing delays must be minimized for highly sensitive traffic considering Medium Access Control (MAC) layer delay. Node workload MAY be set upon CPU overload, lack of memory or any other node related conditions. Using a simple 1-bit flag to characterize the node workload provides a sufficient level of granularity, similarly to the "overload" bit used in routing protocols such as IS-IS. Algorithms used to set the overload bit and to compute path to potentially avoid node with their PC> s/path/paths/; s/node/nodes/ overload bit set are outside the scope of this document but it is PC> s/document/document,/ RECOMMENDED to avoid too frequent changes of that bit to avoid PC> remove "too", s/that/this/ routing oscillations. Vasseur, et al. Expires March 9, 2011 [Page 10] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 Data Aggregation Attribute: data fusion involves more complicated processing to improve accuracy of the output data while data PC> processing to improve the accuracy of the output data, while data aggregation mostly aims at reducing the amount of data. This is listed as a requirement in Section 6.2 of [RFC5548]. Some applications may make use of the aggregation node attribute in their routing decision so as to minimize the amount of traffic on the network, thus potentially increasing its life time in battery PC> s/life time/lifetime/ operated environments. Applications where high directional data flow PC> s/high/highly/ is expected on a regular basis may take advantage of data aggregation supported routing. The following two bits of the NSA object are currently defined: o O Flag: When set, this indicates that the node is overloaded and may not be able to process traffic. o A Flag: When set, this indicates that the node can act as a traffic aggregator. An implementation MAY decide to add optional TLVs (not currently defined) to further describe the node traffic aggregator functionality. The Flag field of the NSA Routing Metric/Constraint object is managed by IANA. Unassigned bits are considered as reserved. They MUST be set to zero on transmission and MUST be ignored on receipt. 3.2. Node Energy object Whenever possible, a node with low residual energy should not be selected as a router, thus the support for constraint-based routing is needed. In such cases, the routing protocol engine may compute a longer path (constraint based) for some traffic in order to increase the network life duration. The routing engine may prefer a "longer" path that traverses mains- powered nodes in particular for low-critical traffic or nodes equipped with energy scavenging, rather than a "shorter" path through PC> "powered nodes, in particular for less critical traffic, rather than" Remove the phrase on energy scavenging since it didn't make sense in the sentence. battery operated nodes. Power and energy are clearly critical resources in most LLNs. As yet there is no simple abstraction which adequately covers the broad range of power sources and energy storage devices used in existing LLN nodes. These include main-powered, primary batteries, energy- PC> s/main-powered/mains-powered/; s/energy-/energy/ scavengers, and a variety of secondary storage mechanisms. Scavengers may provide a reliable low level of power, such as might be available from a 4-20mA loop; a reliable but periodic stream of power, such as provided by a well-positioned solar cell; or unpredictable power, such as might be provided by a vibrational energy scavenger on an intermittently powered pump. Routes which are Vasseur, et al. Expires March 9, 2011 [Page 11] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 viable when the sun is shining may disappear at night. A pump turning on may connect two previously disconnected sections of a network. Storage systems like rechargeable batteries often suffer substantial degradation if regularly used to full discharge, leading to different residual energy numbers for regular versus emergency operation. A route for emergency traffic may have a different optimum than one for regular reporting. Batteries used in LLNs often degrade substantially if their average current consumption exceeds a small fraction of the peak current that they can deliver. It is not uncommon for battery-operated nodes to have a combination of primary storage, energy scavenging, and secondary storage, leading to three different values for acceptable average current depending on the time frame being considered, e.g. milliseconds, seconds, and hours/years. Raw power and energy values are meaningless without knowledge of the energy cost of sending and receiving packets, and lifetime estimates have no value without some higher-level constraint on the lifetime required of a device. In some cases the path that exhausts the battery of a node on the bed table in a month may be preferable to a route that reduces the lifetime of a node in the wall to a decade. Given the complexity of trying to address such a broad collection of constraints, this document defines three levels of fidelity in the solution. The simplest solution relies on a 2-bit field encoding three types of power sources: "powered", "battery", "scavenger". This simple approach may be sufficient for many applications. The mid-complexity solution is a single parameter that can be used to encode the energetic happiness of both battery powered and scavenging nodes. For scavenging nodes, the 8 bit quantity is the power provided by the scavenger divided by the power consumed by the application, H=P_in/P_out, in units of percent. Nodes which are scavenging more power than they are consuming will register above 100. The time period for averaging power in this calculation is out of the scope of this document but something related to the discharge time of the energy storage device on the node is probably appropriate. PC> The time period for averaging power in this calculation may be related to the discharge time of the energy storage device on the node, but specifying this time period is out of the scope of this document. For battery powered devices, H is the current expected lifetime divided by the desired minimum lifetime. The estimation of remaining battery energy and actual power consumption can be difficult, and the specifics of this calculation are out of scope of this document, but two examples are presented. If the node can measure its average power consumption, then H can be calculated as Vasseur, et al. Expires March 9, 2011 [Page 12] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 the ratio of desired max power (initial energy E_0 divided by desired lifetime T) to actual power H=P_max/P_now. Alternatively, if the PC> s/power/power,/ energy in the battery E_bat can be estimated, and the total elapsed lifetime, t, is available, then H can be calculated as the total stored energy remaining versus the target energy remaining: H= E_bat / [E_0 (T-t)/T]. An example of optimized route is max(min(H)) for all battery operated nodes along the route, subject to the constraint that H>=100 for all scavengers along the route. The Node Energy (NE) object is used to provide information related to node energy and may be used as a metric or as constraint. The NE object MAY be present in the DAG Metric Container. There MUST be no more than one NE object as a constraint per DAG Metric Container, and no more than one NE object as a metric per DAG Metric Container. The NE object Type is to be assigned by IANA (recommended value=2). The format of the NE object body is as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | NE Sub-objects +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 4: NE object format The format of the NE sub-object body is as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Flags |I| T |E| E-E | Optional TLVs +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 5: NE sub-object format The NE sub-object may also contain a set of TLVs used to convey various nodes' characteristics. The following flags are currently defined: Vasseur, et al. Expires March 9, 2011 [Page 13] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 o T (node Type): 2-bit field indicating the node type. When E=0x00, the node is mains powered. When E=0x01 is battery powered. When E=0x02 the node is powered by a scavenger. PC> When E=0x01, the node is battery powered. When E=0x02, the node is powered by an energy scavenger. o I (Included): the I bit is only relevant when the node type is used as a constraint. For example, the path must only traverse mains powered node. Conversely, battery operated node must be PC> s/mains powered node/mains-powered nodes/; s/battery operated node/battery operated nodes/ excluded. The I bit is used to stipulate inclusion versus exclusion. When set, this indicates that nodes of type specified PC> s/of type/of the type/ in the node type field MUST be included. Conversely, when cleared, this indicates that nodes of type specified in the node PC> s/of type/of the type/ type field MUST be excluded. o E (Estimation): when the E bit is set for a metric, the estimated percentage of remaining energy on the node is indicated in the E-E 8-bit field. When cleared, the estimated percentage of remaining energy is not provided. When the E bit is set for a constraint, the E-E field defines a threshold for the inclusion/exclusion: if an inclusion, nodes with values higher than the threshold are to be included; if an exclusion, nodes with values lower than the threshold are to be excluded. E-E (Estimated-Energy): 8-bit unsigned integer field indicating an estimated percentage of remaining energy. The E-E field is only relevant when the E flag is set, and MUST be set to 0 when the E flag is cleared. If the NE object comprises several sub-objects when used as a constraint, each sub-object adds or subtracts node subsets as the sub-objects are parsed in order. The initial set (full or empty) is defined by the I bit of the first sub-object: full if that I bit is an exclusion, empty is that I bit is an inclusion. No TLV is currently defined. The most complex solution involves a half dozen TLV parameters representing energy storage, consumption, and generation capabilities of the node, as well as desired lifetime, and will appear in a future version of this document. PC> "and will appear in a future version of this document." should not appear in a Last Called document. 3.3. Hop-Count object The HoP-Count (HP) object is used to report the number of traversed nodes along the path. The HP object MAY be present in the DAG Metric Container. There MUST be no more than one HP object as a constraint per DAG Metric Container, and no more than one HP object as a metric per DAG Metric Vasseur, et al. Expires March 9, 2011 [Page 14] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 Container. The HP object may also contain a set of TLVs used to convey various node characteristics. No TLV is currently defined. The HP routing metric object Type is to be assigned by IANA (recommended value=3) The format of the Hop Count object body is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Res | Flags | Hop Count | Optional TLVs +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 6: Hop Count object format No Flag is currently defined. The HP object may be used as a constraint or a metric. When used as a constraint, the DAG root indicates the maximum number of hops that a path may traverse. When that number is reached, no other node can join that path. When used as a metric each visited node simply PC> s/metric/metric,/ increments the Hop Count field. 3.4. Node Fanout Ratio object The Node Fanout Ratio (NFR) object is used to provide information on the nodes current forwarding load. PC> s/nodes/node's/ The NFR object MAY be present in the DAG Metric Container. There MUST be no more than one NFR object as a constraint per DAG Metric Container, and no more than one NFR object as a metric per DAG Metric Container. The NFR object may also contain a set of TLVs used to convey various forwarding load characteristics. No TLV is currently defined. The NFR object Type is to be assigned by IANA (recommended value=9). Vasseur, et al. Expires March 9, 2011 [Page 15] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 The format of the NFR object body is as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Flags | F R | Optional TLVs PC> close gap between "F R" +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 7: NFR object format When the data traffic of the application supported by the network is known a priori, energy depletion in the network can be equalized simply by controlling the fanout ratio of router nodes. Algorithms describing how to compute the FR value and how to use it are outside the scope of this document. The following field of the NFR object is defined: o FR Field: a 4-bit unsigned integer that indicates a relative fanout of the node. A value of 15 indicates a node that is very close to, or at its maximum supported fanout capability. A value of 0 indicates a very small fanout. Unassigned bits are considered as reserved. They MUST be set to zero on transmission and MUST be ignored on receipt. 4. Link Metric/Constraint objects 4.1. Throughput Many LLNs support a wide range of throughputs. For some links, this may be due to variable coding. For the deeply duty-cycled links found in many LLNs, the variability comes as a result of trading power consumption for bit rate. There are several MAC layer protocols which allow for the effective bit rate and power consumption of a link to vary over more than three orders of magnitude, with a corresponding change in power consumption. For efficient operation, it may be desirable for nodes to report the range of throughput that their links can handle in addition to the currently available throughput. The Throughput object MAY be present in the DAG Metric Container. There MUST be no more than one Throughput object as a constraint per DAG Metric Container, and no more than one Throughput object as a metric per DAG Metric Container. Vasseur, et al. Expires March 9, 2011 [Page 16] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 The Throughput object is made of throughput sub-objects and MUST at least comprise one Throughput sub-object. The first Throughput sub- object MUST be the most recently estimated actual throughput. The actual evaluation of the throughput is outside of this document. PC> s/evaluation/estimation/; s/outside of this document/outside the scope of this document/ Each Throughput sub-object has a fixed length of 4 bytes. The Throughput object does not contain any additional TLV. The Throughput object Type is to be assigned by IANA (recommended value=4) The format of the Throughput object body is as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (sub-object) ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Throughput object body format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Throughput | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Throughput sub-object format Throughput: 32 bits. The Throughput is encoded in 32 bits in unsigned integer format, expressed in bytes per second. 4.2. Latency Similarly to throughput, the latency of many LLN MAC sub-layers can vary over many orders of magnitude, again with a corresponding change in current consumption. Some LLN MAC link layers will allow the latency to be adjusted globally on the subnet, or on a link-by-link PC> s/subnet, or on a link-by-link/subnet, on a link-by-link/ basis, or not at all. Some will insist that it be fixed for a given link, but allow it to be variable from link to link. The Latency object MAY be present in the DAG Metric Container. There MUST be no more than one Latency object as a constraint per DAG Metric Container, and no more than one Latency object as a metric per DAG Metric Container. Vasseur, et al. Expires March 9, 2011 [Page 17] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 The Latency object is made of Latency sub-objects and MUST at least comprise one Latency sub-object. Each Latency sub-object has a fixed length of 4 bytes. The Latency object does not contain any additional TLV. The Latency object Type is to be assigned by IANA (recommended value=5) The Latency object is a metric or constraint. The format of the Latency object body is as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (sub-object) ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Latency object body format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Latency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Latency sub-object format Latency: 32 bits. The Latency is encoded in 32 bits in unsigned integer format, expressed in microseconds. The Latency object may be used as a constraint or a path metric. For example, one may want the latency not to exceed some value. In this case, the Latency object common header indicates that the provided value relates to a constraint. In another example, the Latency object may be used as an aggregated additive metric where the value is updated along the path to reflect the path latency. 4.3. Link reliability In LLNs, link reliability is degraded by external interference and multi-path interference (wireless links). Multipath typically affects both directions on the link equally, whereas external interference is sometimes uni-directional. Time scales vary from milliseconds to days, and are often periodic and linked to human activity. Packet error rates can generally be measured directly, and Vasseur, et al. Expires March 9, 2011 [Page 18] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 other metrics (e.g. bit error rate, mean time between failures) are typically derived from that. Note that such variability is not specific to wireless link but also applies to PLC links. A change in link quality can affect network connectivity, thus, link quality may be taken into account as a critical routing metric. Link quality metric should be applied to each directional link unless bi- directionality is one of routing metrics. PC> The previous sentence, saying "...unless bi-directionality is one of routing metrics" is confusing because bi-directionality is never mentioned in the document as a routing metric or constraint. This might be a link state attribute to add in the future (I know there was a long discussion on link bi-directionality on the mailing list). A number of link reliability metrics could be defined reflecting several reliability aspects. Two link reliability metrics are defined in this document: the Link Quality Level (LQL) and the Expected Transmission count Metric (ETX). Note that an RPL implementation MAY either use the LQL, the ETX or both. 4.3.1. The Link Quality Level reliability metric The Link Quality Level (LQL) object is used to quantify the link reliability using a discrete value, from 0 to 7 where 0 indicates that the link quality level is unknown and 1 reports the highest link quality level. The mechanisms and algorithms used to compute the LQL is implementation specific and outside of the scope of this document. The LQL can either be used as a metric or a constraint. When used as a metric, the LQL metric can be recorded or aggregated. For example, the DAG may require to record the LQL for all traversed links. Each PC> s/DAG may require/OF may require/ (?); Also, who is recording the LQL (subject missing)? node can then use the LQL to select the parent based on user defined rules (e.g. "select the path with the maximum number of links PC> s/maximum number of links/maximum proportion of links/ (or some other better wording than this... see previous comment) reporting a LQL value of 3 or less"). By contrast the LQL link metric may be aggregated, in which case the sum of all LQLs may be reported (additive metric) or the minimum value may be reported along the path. When used as a recorded metric, a counter is used to compress the information where the number of links for each LQL is reported. PC> When used as a recorded metric, a counter records the number of links at each LQL level in order to compress the data. The LQL object MAY be present in the DAG Metric Container. There MUST be no more than one LQL object as a constraint per DAG Metric Container, and no more than one LQL object as a metric per DAG Metric Container. The LQL object MUST contain one or more sub-object used to report the number of links along with their LQL. The LQL object Type is to be assigned by IANA (recommended value=6) Vasseur, et al. Expires March 9, 2011 [Page 19] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 The format of the LQL object body is as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Res | LQL sub-object +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 12: LQL object format When the LQL metric is recorded, the LQL object body comprises one or more LQL Type 1 sub-object. The format of the LQL Type 1 sub-object is as follows 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Val | Counter | +-+-+-+-+-+-+-+-+ Figure 13: LQL Type 1 sub-object format Val: LQL value from 0 to 7 where 0 means undetermined and 1 indicates the highest link quality. Counter: number of links with that value. When the LQL metric is aggregated, the LQL object body comprises one LQL Type 2 sub-object: The format of the LQL Type 2 sub-object is as follows 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aggregated LQL Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: LQL Type 2 sub-object format Aggregated LQL Value: when used as an additive metric (A=0x00), the aggregated LQL value reports the sum of all the LQL values for all links along the path. When used to report a minimum (A=0x02), the field reports the minimum LQL value of all links along the path PC> s/path/path,/ ignoring undetermined LQLs (Aggregated LQL Value = 0). When used to PC> s/Aggregated LQL Value = 0/ LQL=0/ report a maximum (A=0x01), the field reports the maximum LQL value of all links along the path. When used to report a multiplication (A=0x03), and the LQL field of one of the links along the path is Vasseur, et al. Expires March 9, 2011 [Page 20] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 undetermined (LQL=0), the undetermined LQL will be ignored and not be aggregated (i.e. no reset to Aggregated LQL Value field). PC> s/no reset/no change/ 4.3.2. The Expected Transmission Count (ETX) reliability object The Expected Transmission Count (ETX) metric is the number of transmissions a node expects to make to a destination in order to successfully deliver a packet. For example, an implementation may use the following formula: ETX= 1 / (Df * Dr) where Df is the measured probability that a packet is received by the neighbor and Dr is the measured probability that the acknowledgment packet is successfully received. This document does not mandate the use of a specific formula to compute the ETX value. The ETX object MAY be present in the DAG Metric Container. There MUST be no more than one ETX object as a constraint per DAG Metric Container, and no more than one ETX object as a metric per DAG Metric Container. The ETX object is made of ETX sub-objects and MUST at least comprise one ETX sub-object. Each ETX sub-object has a fixed length of 8 bits. The ETX object does not contain any additional TLV. The ETX object Type is to be assigned by IANA (recommended value=7) Vasseur, et al. Expires March 9, 2011 [Page 21] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 The format of the ETX object body is as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (sub-object) ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: ETX object body format 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ETX | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: ETX sub-object format ETX: 16 bits. The ETX * 128 is encoded using 16 bits in unsigned integer format, rounded off to the nearest whole number. For example, if ETX = 3.569, the object value will be 457. If ETX > 511.9921875, the object value will be the maximum which is 65535. The ETX object may be used as a constraint or a path metric. For example, it may be required that the ETX must not exceed some specified value. In this case, the ETX object common header indicates that the value relates to a constraint . In another example, the ETX object may be used as an aggregated additive metric where the value is updated along the path to reflect to path quality. 4.4. Link Color object 4.4.1. Link Color object description The Link Color (LC) object is an administrative 10-bit link constraint (which may either be static or dynamically adjusted) used to avoid or attract specific links for specific traffic types. The LC object can either be used as a metric or as a constraint. When used as a metric, the LC metric can only be recorded. For example, the DAG may require recording the link colors for all traversed links. Each node can then use the LC to select the parent based on user defined rules (e.g. "select the path with the maximum number of links having their first bit set 1 (e.g. encrypted links)"). The LC object may also be used as a constraint. When used as a recorded metric, a counter is used to compress the Vasseur, et al. Expires March 9, 2011 [Page 22] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 information where the number of links for each Link Color is reported. The Link Color (LC) object MAY be present in the DAG Metric Container. There MUST be no more than one LC object as a constraint per DAG Metric Container, and no more than one LC object as a metric per DAG Metric Container. There MUST be a at least one LC sub-object per LC object. The LC object does not contain any additional TLV. The LC object Type is to be assigned by IANA (recommended value=8) The format of the LC object body is as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Res | LC sub-objects +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 17: LC object format When the LC object is used as a recorded metric, the LC object body comprises one or more LC Type 1 sub-objects. The format of the LC Type 1 sub-object body is as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Color | Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18: LC Type 1 sub-object format When the LC object is used as a constraint, the LC object body comprises one or more LC Type 2 sub-objects. Vasseur, et al. Expires March 9, 2011 [Page 23] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 The format of the LC Type 2 sub-object body is as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Color |I| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19: LC Type 2 sub-object format I Bit: The I bits is only relevant when the Link Color is used as a constraint. When cleared, this indicates that links with the specified color must be included. When set, this indicates that links with the specified color must be excluded. The use of the LC object is outside the scope of this document. 4.4.2. Mode of operation PC> This breaks with the format of the other metrics section. Is it necessary to have a "Mode of operation" subsection here? Can we just remove the section heading (include it in 4.4)? The link color may be used as a constraint or a metric. o When used as constraint, the LC object may be inserted in the DAG Metric Container to indicate that links with a specific color should be included or excluded from the computed path. o When used as recorded metric, each node along the path may insert a LC object in the DAG Metric Container to report the color of the local link. If there is already a LC object reported a similar PC> s/reported/reporting/ color, the node MUST NOT add another identical LC sub-object and MUST increment the counter field. 5. Computation of dynamic metrics and attributes As already pointed out, dynamically calculated metrics are of the utmost importance in many circumstances in LLNs. This is mainly because a variety of metrics change on a frequent basis, thus implying the need to adapt the routing decisions. That being said, care must be given to the pace at which changes are reported in the network. The attributes will change according to their own time scales. RPL controls the reporting rate. To minimize metric updates, multi-threshold algorithms MAY be used to determine when updates should be sent. When practical, low-pass filtering and/or hysteresis should be used to avoid rapid fluctuations of these values. Finally, although the specification of path computation algorithms using dynamic metrics are out the scope of this document, it is RECOMMENDED to carefully design the route Vasseur, et al. Expires March 9, 2011 [Page 24] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 optimization algorithm to avoid too frequent computation of new routes upon metric values changes. Controlled adaptation of the routing metrics and rate at which paths are computed are critical to avoid undesirable routing instabilities resulting in increased latencies and packet loss because of temporary micro-loops. Furthermore, excessive route changes will adversely impact the traffic and power consumption in the network, thus potentially impacting its scalability. 6. Use of multiple DAG Metric Container Since RPL options length are coded using 1 octet, their length cannot exceed 256 bytes, which also applies to the DAG Metric Container. Although in the vast majority of cases, the advertised routing metrics and constraints will not require that much space, there might be circumstances where larger space will be required, should for example a set of routing metrics be recorded along a long path. In this case, as specified in [I-D.ietf-roll-rpl], routing metrics will be carried using multiple DAG Metric Containers. In the rest of this document, this use of multiple DAG Metric Containers will be considered as if they were actually just one long DAG Metric Container. 7. Metric consistency Since a set of metrics and constraints will be used for links and nodes in LLN, it is particularly critical to ensure the use of consistent metric calculation mechanisms for all links and nodes in the network, similarly to the case of inter-domain IP routing. 8. Metric usage This section describes how metrics carried in the DAG Metric Container shall be used. When the DAG Metric Container contains a single aggregated metric (scalar value), the order relation to select the best path is implicitly derived from the metric type. For example, lower is better for Hop Count, Link Latency, ETX and Fanout Ratio. For Node Energy or Throughput, higher is better. An example of using such a single aggregated metric is optimizing routing for node energy. The Node Energy metric (E-E field) is Vasseur, et al. Expires March 9, 2011 [Page 25] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 aggregated along paths with an explicit min function (A field), and the best path is selected through an implied Max function because the metric is Energy. When the DAG Metric Container contains several aggregated metrics, they are to be used as tie-breakers according to their precedence defined by their Prec field values. An example of such use of multiple aggregated metrics is the following: Hop-Count as the primary criteria, LQL as the secondary criteria and Fanout Ratio as the ultimate tie-breaker. In such a case, the Hop-Count, LQL and Fanout Ratio metric objects' Prec fields should bear strictly increasing values such as 0, 1 and 2, respectively. 9. IANA Considerations IANA is requested to establish a new top-level registry to contain all Routing Metric/Constraint objects codepoints and sub-registries. The allocation policy for each new registry is by IETF Consensus: new values are assigned through the IETF consensus process (see [RFC5226]). Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists). 9.1. Routing Metric/Constraint type IANA is requested to create a registry for Routing Metric/Constraint objects. Each Routing Metric/Constraint object has a type value. Value Meaning Reference 1 Node State and Attribute This document 2 Node Energy This document 3 Hop Count This document 4 Link Throughput This document 5 Link Latency This document 6 Link Quality Level This document 7 Link ETX This document 8 Link Color This document 9 Node Fanout Ratio This document Vasseur, et al. Expires March 9, 2011 [Page 26] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 9.2. Routing Metric/Constraint common header IANA is requested to create a registry to manage the codespace of A PC> s/A/the A/ field of the Routing Metric/Constraint common header. Codespace of the A field (Routing Metric/Constraint common header) Value Meaning Reference 0 Routing metric is additive This document 1 Routing metric reports a maximum This document 2 Routing metric reports a minimum This document 3 Routing metric is multiplicative This document IANA is requested to create a registry to manage the Flag field of the Routing Metric/Constraint common header. New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities: o Bit number o Capability Description o Defining RFC Several bits are defined for the Routing Metric/Constraint common header in this document. The following values have been assigned: Codespace of the Flag field (Routing Metric/Constraint common header) Bit Description Reference 12-15 Precedence This document 10-11 Additive/Max/Min/Multi This document 9 Recorded/Aggregated This document 8 Optional Constraint This document 7 Constraint/metric This document PC> s/metric/Metric 6 P (Partial) This document 9.3. NSA object IANA is requested to create a registry to manage the codespace of the Flag field of the NSA object. New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities: o Bit number Vasseur, et al. Expires March 9, 2011 [Page 27] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 o Capability Description o Defining RFC Several bits are defined for the NSA object flag field in this document. The following values have been assigned: Codespace of the Flag field (NSA object) Bit Description Reference 14 Aggregator This document 15 Overloaded This document 9.4. Hop-Count object IANA is requested to create a registry to manage the codespace of the Flag field of the Hop-count object. New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities: o Bit number o Capability Description o Defining RFC No Flag is currently defined. 10. Security considerations Routing metrics should be handled in a secure and trustful manner. For instance, a malicious node can not advertise falsely that it has good metrics for routing and belong to the established path to have a chance to intercept packets. Since the routing metrics/constraints PC> For instance, RPL should not allow a malicious node to falsely advertise that it has good metrics for routing, be added as a router for other nodes' traffic, and intercept packets. are carried within RPL message, the security routing mechanisms defined in [I-D.ietf-roll-rpl] applies here. 11. Acknowledgements The authors would like to acknowledge the contributions of Young Jae Kim, Hakjin Chong, David Meyer, Mischa Dohler, Anders Brandt, Philip Levis, Pascal Thubert, Richard Kelsey, Jonathan Hui, Alexandru Petrescu, Richard Kelsey, Mathilde Durvy, Phoebus Chen, Tim Winter, Mukul Goyal, Yoav Ben-Yehezkel, Matteo Paris, Omprakash Gnawali, Mads Westergreen and Mukul Goyal for their review and valuable comments. Vasseur, et al. Expires March 9, 2011 [Page 28] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 12. References 12.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 12.2. Informative references [I-D.ietf-roll-rpl] Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-11 (work in progress), July 2010. [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-03 (work in progress), March 2010. [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009. [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009. Vasseur, et al. Expires March 9, 2011 [Page 29] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010. [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010. Authors' Addresses JP Vasseur (editor) Cisco Systems, Inc 11, Rue Camille Desmoulins Issy Les Moulineaux, 92782 France Email: jpv@cisco.com Mijeom Kim (editor) Corporate Technology Group, KT 17 Woomyeon-dong, Seocho-gu Seoul, 137-792 Korea Email: mjkim@kt.com Kris Pister Dust Networks 30695 Huntwood Ave. Hayward, CA 95544 USA Email: kpister@dustnetworks.com Nicolas Dejean Coronis SAS Espace Concorde, 120 impasse JB Say Perols, 34470 France Email: nicolas.dejean@coronis.com Vasseur, et al. Expires March 9, 2011 [Page 30] Internet-Draft draft-ietf-roll-routing-metrics-09 September 2010 Dominique Barthel France Telecom Orange 28 chemin du Vieux Chene, BP 98 Meylan, 38243 France Email: dominique.barthel@orange-ftgroup.com Vasseur, et al. Expires March 9, 2011 [Page 31] Html markup produced by rfcmarkup 1.90, available from http://tools.ietf.org/tools/rfcmarkup/ On 9/16/10 3:56 PM, David Culler wrote: > The routing metrics draft has now gone through 9 revisions over the > past 16 months, the diffs have narrowed to essentially wording and > editorial changes, and the comments are few and non-controversial. > Thus, it appears that consensus has emerged and we can LC this I-D. > > This email is to announce Working Group Last Call on > draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST, > Sept. 30 2010. Please read it thoroughly and forward all final > comments to the authors and the WG mailing list. > > Thanks all for your good work. We're on a ROLL. > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From phoebus@ieee.org Thu Sep 23 06:56:30 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CB853A69DA for ; Thu, 23 Sep 2010 06:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.416 X-Spam-Level: X-Spam-Status: No, score=-105.416 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YySkb34Fk7Bb for ; Thu, 23 Sep 2010 06:56:29 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id 0B7F23A6923 for ; Thu, 23 Sep 2010 06:56:29 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 218D114F11C for ; Thu, 23 Sep 2010 15:56:28 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id FhHJBo8wi8A9 for ; Thu, 23 Sep 2010 15:56:26 +0200 (CEST) X-KTH-Auth: phoebus [130.237.43.217] X-KTH-mail-from: phoebus@ieee.org X-KTH-rcpt-to: roll@ietf.org Received: from dhcp-43-217.s3.kth.se (dhcp-43-217.s3.kth.se [130.237.43.217]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 7F7AB14F2F0 for ; Thu, 23 Sep 2010 15:56:26 +0200 (CEST) Message-ID: <4C9B5C8A.3030604@ieee.org> Date: Thu, 23 Sep 2010 15:56:26 +0200 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: roll@ietf.org References: <4C9B0556.9090305@ieee.org> <4C9B0F77.9090008@sics.se> In-Reply-To: <4C9B0F77.9090008@sics.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine metrics in the A field X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: phoebus@ieee.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 13:56:30 -0000 I like this suggestion. Specifying how to combine metrics in a separate container allows us to also advertise it within the DODAG configuration object when a node needs to know it, not every time a DIO with a DAG Metric Container is sent. The way to combine metrics should change much more slowly (if ever) than the metrics, so there really isn't a need to send it each time. This is particularly useful if we wish to introduce "weights" (or some other constants) when we combine different metrics... these weights will probably not change unless the network operator reconfigures them. We just need to make sure the order of the metrics in the DAG Metric Container used by an Objective Function is fixed/known by all nodes joining an RPL Instance, so they can be combined correctly. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 9/23/10 10:27 AM, Joakim Eriksson wrote: > I agree with this! > > It would be much easier to add some type of OF specific > "metrics-container" that could carry descriptions on how to combine the > metrics. > > If we have that any future OF could use that OF-configuration container > and use the information in that container (in whatever format that > specific OF defines). Then we could define OF-Generic1 that handles > additive and multiplicative metrics, and that has some very simple > configuration container that describe how to handle the metrics. > Later we can add the OF-Generic2 that handles constraints, and > more advanced combinations of metrics - this without forcing all > other OFs to be almost-generic. > > > > Best regards, > -- Joakim Eriksson, SICS > > > Phoebus Chen skrev 2010-09-23 09:44: >> I'm in the midst of making a pass through routing-metrics-09, and a >> question I (and others) asked earlier keeps coming up back in my head: >> >> Why are we specifying how to combine the metrics in the DAG metric >> container? Can't it be specified in the OF? >> >> Here was the old thread (way back in April): >> http://www.ietf.org/mail-archive/web/roll/current/msg03815.html >> JP's response: >> http://www.ietf.org/mail-archive/web/roll/current/msg03768.html >> >> The argument was to not have a flood of new RFCs specifying OFs for each >> possible new way of combining metrics. OK. >> >> But say that we do want to use a combination of add, max, min, >> multiplication, or some other operator to combine some of these metrics. >> What do we set in the "A" field of the Routing Metric/Constraint object >> depicted in Figure 2? I would prefer to replace "A=0x03: The routing >> metric is multiplicative" with "A=0x03: The routing metric is aggregated >> in some other fashion specified by the objective function." Or, there >> should be a sentence in the specification saying that the objective >> function can "override" and ignore this field (and MUST set A=0x00 if >> the OF plans for the A field to be ignored). >> >> I noticed that the text in Section 8 of routing-metrics-08 : >> "The use of compound metrics, such as a polynomial function of >> individual metric values, will be described in a future revision of this >> document." >> has been removed in routing-metrics-09. Given the rigidity of the A >> field, I'm not sure that we can specify compound metrics in future OFs. >> >> >> I'll send more comments about the rest of the document soon. >> > > From richard.kelsey@ember.com Thu Sep 23 07:02:41 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E07C83A69D6 for ; Thu, 23 Sep 2010 07:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGZ8m0c3CZYk for ; Thu, 23 Sep 2010 07:02:41 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id D41003A6938 for ; Thu, 23 Sep 2010 07:02:40 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Sep 2010 10:03:09 -0400 Date: Thu, 23 Sep 2010 10:03:07 -0400 Message-Id: <87fwx04kx0.fsf@kelsey-ws.hq.ember.com> To: "Colin O'Flynn" In-reply-to: <001201cb5afd$f0e7f430$d2b7dc90$@com> (coflynn@newae.com) From: Richard Kelsey References: <001201cb5afd$f0e7f430$d2b7dc90$@com> X-OriginalArrivalTime: 23 Sep 2010 14:03:09.0497 (UTC) FILETIME=[0D966290:01CB5B28] Cc: roll@ietf.org Subject: Re: [Roll] Node Energy Measuring Stick X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 23 Sep 2010 14:02:42 -0000 > From: "Colin O'Flynn" > Date: Thu, 23 Sep 2010 11:00:50 +0200 > > The proposed energy metrics in the metrics-09 measures battery power as a > relative scale of "desired lifetime" to "current estimated lifetime". This > is good since it allows you to specify a non-replaceable node has e.g. a 10 > year desired lifetime. > > What this misses is some way to advertise the capacity of the battery. This > is important as it is impossible to know with the current metric until after > you start using the node if it is a car battery or a button coin cell. An 'available bandwidth' metric works for this. For a battery powered device you know the desired lifetime, the amount of energy in the battery, and how much of this will be consumed by the device itself. The leftover energy, divided by the desired lifetime and the cost of sending and receiving, gives the bandwidth the device can donate to the network. This works for energy scavenging devices as well, assuming that the scavenging rate is predictable. -Richard Kelsey From pthubert@cisco.com Fri Sep 24 01:46:44 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABED43A6AF6; Fri, 24 Sep 2010 01:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.327 X-Spam-Level: X-Spam-Status: No, score=-10.327 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjg1iBaahEB4; Fri, 24 Sep 2010 01:46:42 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 116EB3A6ADB; Fri, 24 Sep 2010 01:46:41 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.57,228,1283731200"; d="scan'208";a="65098567" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 24 Sep 2010 08:47:12 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o8O8lCM3008331; Fri, 24 Sep 2010 08:47:12 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Sep 2010 10:47:12 +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: Fri, 24 Sep 2010 10:47:07 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02CE8896@XMB-AMS-107.cisco.com> In-Reply-To: <7C435E06-59B9-4C16-9D4C-2DB976A1AA29@free.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Flow Label: 12 bits mutable and 8 bits immutable Thread-Index: ActZnyD3jMgXGhEKQWWl2IGwCnFQQgCIZwKA References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com><4C9030FF.6060302@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02CE7AE9@XMB-AMS-107.cisco.com> <6A525E5A-294B-4E91-ACCA-632A0DCF7C19@free.fr> <6A2A459175DABE4BB11DE2026AA50A5D02CE7C07@XMB-AMS-107.cisco.com> <7C435E06-59B9-4C16-9D4C-2DB976A1AA29@free.f r> From: "Pascal Thubert (pthubert)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-OriginalArrivalTime: 24 Sep 2010 08:47:12.0727 (UTC) FILETIME=[14E29670:01CB5BC5] Cc: ROLL WG , IPv6 WG Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 24 Sep 2010 08:46:44 -0000 Hi Remi: > It looks like you insist on destroying FL compatibility with what it = has been > specified for. What was it defined for, indeed? The story starts in the mid-90s and is contiguous with the early Ypsilon = work on flow switching. It's quite natural that at that time, the = concept of flow was integrated in the IPv6 header, in a same fashion = that byte alignment in enforced in the headers since that was also a = concern of the day. While IPv6 adopted the wait-and-see position, flow switching evolved = into tag switching and then MPLS. From an IPv6 perspective, what can we = see after all this waiting? That the real value of the tag has nothing = to do with the initial MP (IPv4 has been hegemonic ever since) or the LS = (IP routing in silicon has rendered the performance discussion obsolete = more than ten years ago). The real value that we can clearly observe today appeared with the = applications to VPN and TE. IOW, the value of the tag derives from the = capability in the router to select a path that's not the one the main = RIB would have indicated. Modern networks need VPN, TE and MTR = capabilities and MPLS bloomed in a niche that IPv4, with no mean to do = this tagging, could simply not start to address. What does that tell us? Probably that the use of the flow label as a tag = to influence the routing of the packet (eg a VRF index) is not so far = from the initial intent but simply its natural evolution. Clearly, tags = are employed in the core in such a way that a simple 20 bit field in the = header can never suffice to emulate. But OTOH, at the edge of the = network, it is still possible to place a tag in the flow label that will = be mapped into a MPLS label at the border. This is quite naturally the = route-over version of the mapping of a 1Q tag into a label that we = commonly do today. Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > Sent: Tuesday, September 21, 2010 5:10 PM > To: Pascal Thubert (pthubert) > Cc: JP Vasseur; IPv6 WG; ROLL WG > Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable >=20 >=20 > Le 21 sept. 2010 =E0 16:49, Pascal Thubert (pthubert) a =E9crit : >=20 > > It is. > > > > But the real world tells us that various MTUs over various paths is > problematic. >=20 > Isn't this independent from RPL, and from whatever MTU one applies = locally? >=20 > Actually, this is a nice feature of IPv6 that every network under an > administrative control has to make sure it supports 1280 + whatever = headers > are needed to traverse. > Hosts, except for on-link neighbors, should better send with a 1280 = MTU. > (This constraint will disappear when PMTUD becomes reliable, but it = may take > quite a while.) >=20 > > In particular it creates states in the hosts which can be subject to = attacks. > Middle box happen to defeat PMTUD. >=20 >=20 > > Encapsulation for insertion will probably hit the router performance > > unless there's special silicon for that operation, >=20 > The change of size only appears at the border between RPL and ordinary = IP, > right? >=20 > > which current routers obviously do not have. Etc... >=20 > Etc. Etc. > It looks like you insist on destroying FL compatibility with what it = has been > specified for. >=20 > IMHO, working on RPL solutions without interfering with FLs has a = better > chance to permit consensus, both for RPL and for FLs. >=20 > RD >=20 >=20 > > Pascal > > > > > >> -----Original Message----- > >> From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > >> Sent: Tuesday, September 21, 2010 2:28 PM > >> To: Pascal Thubert (pthubert) > >> Cc: JP Vasseur; IPv6 WG; ROLL WG > >> Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits = immutable > >> > >> > >> Le 21 sept. 2010 =E0 14:08, Pascal Thubert (pthubert) a =E9crit : > >> > >>> Hi R=E9mi: > >>> > >>> It would not. > >>> > >>> We'll be very glad that 6LoWPAN compresses RPL optimally. But RPL > >>> being > >> layer 2 agnostic cannot depend on 6LoWPAN. > >>> Header and IP in IP insertion is problematic on any network, > >> > >> Couldn't the additional header start with e.g. a 0xF so that it can > >> be distinguished from an IPvX header. > >> (These 4 bits, plus the 20 that would be sufficient if FLs were to = be > >> used, would make a nice 3 octets.) It would then be layer-2 = agnostic. > >> > >>> be it for the MTU issues only. > >> > >> Why? > >> Isn't each traversed link authorized to have its link MTU? > >> > >> Cheers, > >> RD > >>> > >>> The FL for RPL discussion illustrates that there can be multiple > >>> valuable > >> usages of the field by the network. > >>> It mostly shows that tying the usage to local balancing only is > >>> probably short > >> sighted. > >>> > >>> Cheers, > >>> > >>> Pascal > >>> > >>>> -----Original Message----- > >>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > >>>> Behalf Of R=E9mi Despr=E9s > >>>> Sent: Saturday, September 18, 2010 4:53 PM > >>>> To: JP Vasseur > >>>> Cc: IPv6 WG; ROLL WG > >>>> Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits > >>>> immutable > >>>> > >>>> > >>>> Le 18 sept. 2010 =E0 02:22, JP Vasseur a =E9crit : > >>>>> On Sep 15, 2010, at 8:51 AM, Carsten Bormann wrote: > >>>>> ... > >>>>>> > >>>>>> However, it would be pretty easy to put something in 6lowpan to > >>>>>> carry those > >>>> 3 bytes. > >>>>>> (Consider it an advanced form of header compression for the > >>>>>> 48-byte IP-in-IP thing, if you don't like the sub-IP thinking.) > >>>>>> Consult > >>>> http://tools.ietf.org/html/draft-bormann-6lowpan-ext-hdr-00 for a > >>>> sample base design. > >>>>>> Such a simple extension may actually be a preferable way to = carry > >>>>>> ROLL in > >>>> 6lowpan. > >>>>> > >>>>> "preferable" in which sense ? > >>>> > >>>> At least, IMHO, in that it eliminates the motivation to interfere > >>>> with the current discussion on improving flow-label utilization. > >>>> > >>>> Regards, > >>>> RD > >>>> > >>>> > >>>> _______________________________________________ > >>>> Roll mailing list > >>>> Roll@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/roll > >> > > >=20 From cabo@tzi.org Fri Sep 24 01:57:11 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7F33A6B22 for ; Fri, 24 Sep 2010 01:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.233 X-Spam-Level: X-Spam-Status: No, score=-106.233 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8+vLSsDu2tn for ; Fri, 24 Sep 2010 01:57:10 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id DE4923A6B0C for ; Fri, 24 Sep 2010 01:57:09 -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 o8O8vYCN025567; Fri, 24 Sep 2010 10:57:34 +0200 (CEST) Received: from eduroam-0016.wlan.uni-bremen.de (eduroam-0016.wlan.uni-bremen.de [134.102.16.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EBEE1F6D; Fri, 24 Sep 2010 10:57:33 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4C9B0F77.9090008@sics.se> Date: Fri, 24 Sep 2010 10:57:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C9B0556.9090305@ieee.org> <4C9B0F77.9090008@sics.se> To: Joakim Eriksson X-Mailer: Apple Mail (2.1081) Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine metrics in the A field X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 24 Sep 2010 08:57:11 -0000 On Sep 23, 2010, at 10:27, Joakim Eriksson wrote: > metrics-container ... and do something like RFC 3320 to send around the mobile code that = then combines the metrics :-) Gruesse, Carsten From joakime@sics.se Fri Sep 24 08:36:48 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108F73A6B7A for ; Fri, 24 Sep 2010 08:36:48 -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.744, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDNbx2RQyjnn for ; Fri, 24 Sep 2010 08:36:47 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 17B923A6B29 for ; Fri, 24 Sep 2010 08:36:47 -0700 (PDT) Received: from [192.168.1.5] (c-b71ae455.013-276-73746f7.cust.bredbandsbolaget.se [85.228.26.183]) (Authenticated sender: joakime@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 40AC940119; Fri, 24 Sep 2010 17:37:17 +0200 (CEST) Message-ID: <4C9CC5BB.203@sics.se> Date: Fri, 24 Sep 2010 17:37:31 +0200 From: Joakim Eriksson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Carsten Bormann References: <4C9B0556.9090305@ieee.org> <4C9B0F77.9090008@sics.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine metrics in the A field X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 24 Sep 2010 15:36:48 -0000 Yes, well. Not mainly to enable mobile code, but a variety of ways of specifying configurations. From very simplistic (just some flags or so) to very sophisticated (such as mobile code). Best regards, -- Joakim Eriksson, SICS Carsten Bormann skrev 2010-09-24 10:57: > On Sep 23, 2010, at 10:27, Joakim Eriksson wrote: > >> metrics-container > > ... and do something like RFC 3320 to send around the mobile code that then combines the metrics :-) > > Gruesse, Carsten From coflynn@newae.com Sat Sep 25 02:55:56 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 862EB3A6A3D for ; Sat, 25 Sep 2010 02:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCW8c9ZBiuDE for ; Sat, 25 Sep 2010 02:55:55 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 7BC923A6939 for ; Sat, 25 Sep 2010 02:55:55 -0700 (PDT) Received: from 78-3-79-215.adsl.net.t-com.hr ([78.3.79.215] helo=COLINNETBOOK) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1OzRUa-00064y-D1; Sat, 25 Sep 2010 05:56:28 -0400 From: "Colin O'Flynn" To: "'Richard Kelsey'" References: <001201cb5afd$f0e7f430$d2b7dc90$@com> <87fwx04kx0.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87fwx04kx0.fsf@kelsey-ws.hq.ember.com> Date: Sat, 25 Sep 2010 11:56:23 +0200 Message-ID: <00b601cb5c97$ec680c10$c5382430$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActbKA8UXV9QOmTrRZWMvA7uHAdPEwAK2c+Q Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: roll@ietf.org Subject: Re: [Roll] Node Energy Measuring Stick X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 25 Sep 2010 09:55:56 -0000 Hi Richard, This makes sense, I assume you mean to make use of the "throughput" metric/constraint? There would thus be a best practice to always use the throughput metric with the node energy metric? My understanding is thus the node energy metric provides a relative measure of current power consumption vs. available power, and cannot be used to decide the best route from an energy perspective. It can only be used as a reactive measure to change a route that is using too much power. The "throughput" metric is the metric providing information about creating a route initially. Is this the desired result? If so I think it would be important to explicitly mention this limitation to prevent possible misuse of the node energy metric. Regards, -Colin -----Original Message----- From: Richard Kelsey [mailto:richard.kelsey@ember.com] Sent: September 23, 2010 4:03 PM To: Colin O'Flynn Cc: roll@ietf.org Subject: Re: [Roll] Node Energy Measuring Stick > From: "Colin O'Flynn" > Date: Thu, 23 Sep 2010 11:00:50 +0200 > > The proposed energy metrics in the metrics-09 measures battery power as a > relative scale of "desired lifetime" to "current estimated lifetime". This > is good since it allows you to specify a non-replaceable node has e.g. a 10 > year desired lifetime. > > What this misses is some way to advertise the capacity of the battery. This > is important as it is impossible to know with the current metric until after > you start using the node if it is a car battery or a button coin cell. An 'available bandwidth' metric works for this. For a battery powered device you know the desired lifetime, the amount of energy in the battery, and how much of this will be consumed by the device itself. The leftover energy, divided by the desired lifetime and the cost of sending and receiving, gives the bandwidth the device can donate to the network. This works for energy scavenging devices as well, assuming that the scavenging rate is predictable. -Richard Kelsey From remi.despres@free.fr Tue Sep 21 05:27:10 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ED253A69E6; Tue, 21 Sep 2010 05:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.316 X-Spam-Level: X-Spam-Status: No, score=-1.316 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkmhsOmBTV3C; Tue, 21 Sep 2010 05:27:09 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by core3.amsl.com (Postfix) with ESMTP id 24DE03A69E0; Tue, 21 Sep 2010 05:27:09 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2114.sfr.fr (SMTP Server) with ESMTP id DDA8B7000090; Tue, 21 Sep 2010 14:27:32 +0200 (CEST) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2114.sfr.fr (SMTP Server) with ESMTP id 690277000092; Tue, 21 Sep 2010 14:27:32 +0200 (CEST) X-SFR-UUID: 20100921122732430.690277000092@msfrf2114.sfr.fr Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02CE7AE9@XMB-AMS-107.cisco.com> Date: Tue, 21 Sep 2010 14:27:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6A525E5A-294B-4E91-ACCA-632A0DCF7C19@free.fr> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com><4C9030FF.6060302@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02CE7AE9@XMB-AMS-107.cisco.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Sun, 26 Sep 2010 17:06:30 -0700 Cc: ROLL WG , IPv6 WG Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Sep 2010 12:27:10 -0000 Le 21 sept. 2010 =E0 14:08, Pascal Thubert (pthubert) a =E9crit : > Hi R=E9mi: >=20 > It would not.=20 >=20 > We'll be very glad that 6LoWPAN compresses RPL optimally. But RPL = being layer 2 agnostic cannot depend on 6LoWPAN.=20 > Header and IP in IP insertion is problematic on any network, Couldn't the additional header start with e.g. a 0xF so that it can be = distinguished from an IPvX header. (These 4 bits, plus the 20 that would be sufficient if FLs were to be = used, would make a nice 3 octets.) It would then be layer-2 agnostic.=20 > be it for the MTU issues only. Why? Isn't each traversed link authorized to have its link MTU? Cheers, RD >=20 > The FL for RPL discussion illustrates that there can be multiple = valuable usages of the field by the network.=20 > It mostly shows that tying the usage to local balancing only is = probably short sighted. >=20 > Cheers, >=20 > Pascal >=20 >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of R=E9mi >> Despr=E9s >> Sent: Saturday, September 18, 2010 4:53 PM >> To: JP Vasseur >> Cc: IPv6 WG; ROLL WG >> Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable >>=20 >>=20 >> Le 18 sept. 2010 =E0 02:22, JP Vasseur a =E9crit : >>> On Sep 15, 2010, at 8:51 AM, Carsten Bormann wrote: >>> ... >>>>=20 >>>> However, it would be pretty easy to put something in 6lowpan to = carry those >> 3 bytes. >>>> (Consider it an advanced form of header compression for the 48-byte >>>> IP-in-IP thing, if you don't like the sub-IP thinking.) Consult >> http://tools.ietf.org/html/draft-bormann-6lowpan-ext-hdr-00 for a = sample base >> design. >>>> Such a simple extension may actually be a preferable way to carry = ROLL in >> 6lowpan. >>>=20 >>> "preferable" in which sense ? >>=20 >> At least, IMHO, in that it eliminates the motivation to interfere = with the current >> discussion on improving flow-label utilization. >>=20 >> Regards, >> RD >>=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From remi.despres@free.fr Tue Sep 21 08:10:02 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFE523A6A41; Tue, 21 Sep 2010 08:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.341 X-Spam-Level: X-Spam-Status: No, score=-1.341 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SelSncLDqAxX; Tue, 21 Sep 2010 08:10:01 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by core3.amsl.com (Postfix) with ESMTP id 990C63A692E; Tue, 21 Sep 2010 08:10:01 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id 211B87000092; Tue, 21 Sep 2010 17:10:26 +0200 (CEST) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id BBBE27000086; Tue, 21 Sep 2010 17:10:25 +0200 (CEST) X-SFR-UUID: 20100921151025769.BBBE27000086@msfrf2206.sfr.fr Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02CE7C07@XMB-AMS-107.cisco.com> Date: Tue, 21 Sep 2010 17:10:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7C435E06-59B9-4C16-9D4C-2DB976A1AA29@free.fr> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com><4C9030FF.6060302@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02CE7AE9@XMB-AMS-107.cisco.com> <6A525E5A-294B-4E91-ACCA-632A0DCF7C19@free.fr> <6A2A459175DABE4BB11DE2026AA50A5D02CE7C07@XMB-AMS-107.cisco.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Sun, 26 Sep 2010 17:06:45 -0700 Cc: ROLL WG , IPv6 WG Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Sep 2010 15:10:02 -0000 Le 21 sept. 2010 =E0 16:49, Pascal Thubert (pthubert) a =E9crit : > It is.=20 >=20 > But the real world tells us that various MTUs over various paths is = problematic. Isn't this independent from RPL, and from whatever MTU one applies = locally? Actually, this is a nice feature of IPv6 that every network under an = administrative control has to make sure it supports 1280 + whatever = headers are needed to traverse. Hosts, except for on-link neighbors, should better send with a 1280 MTU. (This constraint will disappear when PMTUD becomes reliable, but it may = take quite a while.) > In particular it creates states in the hosts which can be subject to = attacks. Middle box happen to defeat PMTUD. > Encapsulation for insertion will probably hit the router performance = unless there's special silicon for that operation, The change of size only appears at the border between RPL and ordinary = IP, right? > which current routers obviously do not have. Etc... Etc. Etc. It looks like you insist on destroying FL compatibility with what it has = been specified for. IMHO, working on RPL solutions without interfering with FLs has a better = chance to permit consensus, both for RPL and for FLs. RD > Pascal >=20 >=20 >> -----Original Message----- >> From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] >> Sent: Tuesday, September 21, 2010 2:28 PM >> To: Pascal Thubert (pthubert) >> Cc: JP Vasseur; IPv6 WG; ROLL WG >> Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable >>=20 >>=20 >> Le 21 sept. 2010 =E0 14:08, Pascal Thubert (pthubert) a =E9crit : >>=20 >>> Hi R=E9mi: >>>=20 >>> It would not. >>>=20 >>> We'll be very glad that 6LoWPAN compresses RPL optimally. But RPL = being >> layer 2 agnostic cannot depend on 6LoWPAN. >>> Header and IP in IP insertion is problematic on any network, >>=20 >> Couldn't the additional header start with e.g. a 0xF so that it can = be >> distinguished from an IPvX header. >> (These 4 bits, plus the 20 that would be sufficient if FLs were to be = used, would >> make a nice 3 octets.) It would then be layer-2 agnostic. >>=20 >>> be it for the MTU issues only. >>=20 >> Why? >> Isn't each traversed link authorized to have its link MTU? >>=20 >> Cheers, >> RD >>>=20 >>> The FL for RPL discussion illustrates that there can be multiple = valuable >> usages of the field by the network. >>> It mostly shows that tying the usage to local balancing only is = probably short >> sighted. >>>=20 >>> Cheers, >>>=20 >>> Pascal >>>=20 >>>> -----Original Message----- >>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On = Behalf >>>> Of R=E9mi Despr=E9s >>>> Sent: Saturday, September 18, 2010 4:53 PM >>>> To: JP Vasseur >>>> Cc: IPv6 WG; ROLL WG >>>> Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits = immutable >>>>=20 >>>>=20 >>>> Le 18 sept. 2010 =E0 02:22, JP Vasseur a =E9crit : >>>>> On Sep 15, 2010, at 8:51 AM, Carsten Bormann wrote: >>>>> ... >>>>>>=20 >>>>>> However, it would be pretty easy to put something in 6lowpan to >>>>>> carry those >>>> 3 bytes. >>>>>> (Consider it an advanced form of header compression for the = 48-byte >>>>>> IP-in-IP thing, if you don't like the sub-IP thinking.) Consult >>>> http://tools.ietf.org/html/draft-bormann-6lowpan-ext-hdr-00 for a >>>> sample base design. >>>>>> Such a simple extension may actually be a preferable way to carry >>>>>> ROLL in >>>> 6lowpan. >>>>>=20 >>>>> "preferable" in which sense ? >>>>=20 >>>> At least, IMHO, in that it eliminates the motivation to interfere >>>> with the current discussion on improving flow-label utilization. >>>>=20 >>>> Regards, >>>> RD >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>=20 >=20 From remi.despres@free.fr Fri Sep 24 08:01:25 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5140E3A6A09; Fri, 24 Sep 2010 08:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.373 X-Spam-Level: X-Spam-Status: No, score=-1.373 tagged_above=-999 required=5 tests=[AWL=0.576, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sptt9dKj111j; Fri, 24 Sep 2010 08:01:23 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.82]) by core3.amsl.com (Postfix) with ESMTP id 53C9F3A69DA; Fri, 24 Sep 2010 08:01:23 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2408.sfr.fr (SMTP Server) with ESMTP id 225317000091; Fri, 24 Sep 2010 17:01:54 +0200 (CEST) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2408.sfr.fr (SMTP Server) with ESMTP id 93573700008D; Fri, 24 Sep 2010 17:01:53 +0200 (CEST) X-SFR-UUID: 20100924150153603.93573700008D@msfrf2408.sfr.fr Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02CE8896@XMB-AMS-107.cisco.com> Date: Fri, 24 Sep 2010 17:01:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <353FEAD4-DD1C-46D3-9353-926A8F1DBF4B@free.fr> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com><4C9030FF.6060302@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02CE7AE9@XMB-AMS-107.cisco.com> <6A525E5A-294B-4E91-ACCA-632A0DCF7C19@free.fr> <6A2A459175DABE4BB11DE2026AA50A5D02CE7C07@XMB-AMS-107.cisco.com> <7C435E06-59B9-4C16-9D4C-2DB976A1AA29@free.f r> <6A2A459175DABE4BB11DE2026AA50A5D02CE8896@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Sun, 26 Sep 2010 17:06:46 -0700 Cc: ROLL WG , IPv6 WG Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 24 Sep 2010 15:01:25 -0000 Thanks Pascal for the historical tutorial. Having not participated in IETF in the mid 90s, I find it interesting. =20= My FL reference to FLs is is essentially based on the "IPv6 Flow Label = Specification" of RFC 3697, in 2004. Le 24 sept. 2010 =E0 10:47, Pascal Thubert (pthubert) a =E9crit : > Hi Remi: >=20 >> It looks like you insist on destroying FL compatibility with what it = has been >> specified for. >=20 > What was it defined for, indeed? RFC 3697 says "The 20-bit Flow Label field in the IPv6 header [IPv6] is = used by a source to label packets of a flow". The RFC doesn't really say for what purpose but, in the absence of any = additional signaling that would permit more influence on routing, the = purpose seems to just be an influence on load balancing? Besides, FLs are for this an effective approach because intermediate = routing nodes that do load balancing cannot reconstruct 5-tuples for all = packets they have to forward. That's why I believe that, if RFC 3697 is revised, in particular to = clarify what intermediate nodes can do with FLs, it should only be = without destroying what they are good for. RD > The story starts in the mid-90s and is contiguous with the early = Ypsilon work on flow switching. It's quite natural that at that time, = the concept of flow was integrated in the IPv6 header, in a same fashion = that byte alignment in enforced in the headers since that was also a = concern of the day. >=20 > While IPv6 adopted the wait-and-see position, flow switching evolved = into tag switching and then MPLS. =46rom an IPv6 perspective, what can = we see after all this waiting? That the real value of the tag has = nothing to do with the initial MP (IPv4 has been hegemonic ever since) = or the LS (IP routing in silicon has rendered the performance discussion = obsolete more than ten years ago). >=20 > The real value that we can clearly observe today appeared with the = applications to VPN and TE. IOW, the value of the tag derives from the = capability in the router to select a path that's not the one the main = RIB would have indicated. Modern networks need VPN, TE and MTR = capabilities and MPLS bloomed in a niche that IPv4, with no mean to do = this tagging, could simply not start to address. >=20 > What does that tell us? Probably that the use of the flow label as a = tag to influence the routing of the packet (eg a VRF index) is not so = far from the initial intent but simply its natural evolution. Clearly, = tags are employed in the core in such a way that a simple 20 bit field = in the header can never suffice to emulate. But OTOH, at the edge of the = network, it is still possible to place a tag in the flow label that will = be mapped into a MPLS label at the border. This is quite naturally the = route-over version of the mapping of a 1Q tag into a label that we = commonly do today. >=20 > Pascal > http://www.xtranormal.com/watch/7011357/ From jpv@cisco.com Mon Sep 27 02:42:20 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C9743A6CB1 for ; Mon, 27 Sep 2010 02:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.393 X-Spam-Level: X-Spam-Status: No, score=-110.393 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qy9p+qdJX32K for ; Mon, 27 Sep 2010 02:42:15 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 42CCD3A6C9B for ; Mon, 27 Sep 2010 02:42:12 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAIcEoEyrR7Hu/2dsb2JhbACBQ6Btcak9m3eFRASKOoME X-IronPort-AV: E=Sophos;i="4.57,242,1283731200"; d="scan'208,217";a="261049821" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 27 Sep 2010 09:42:50 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o8R9gndZ018459 for ; Mon, 27 Sep 2010 09:42:50 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Sep 2010 11:41:49 +0200 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Sep 2010 11:41:49 +0200 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-321-183147305 Date: Mon, 27 Sep 2010 11:41:48 +0200 Message-Id: <49DAA66E-1195-4001-85DA-A334EB1BC562@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 27 Sep 2010 09:41:49.0514 (UTC) FILETIME=[353DDAA0:01CB5E28] Subject: [Roll] Important Dates IETF-79 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 27 Sep 2010 09:42:20 -0000 --Apple-Mail-321-183147305 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii IETF 79: November 7-12, 2010, Beijing, China =20 2010-08-9 (Week of): IETF Online Registration opens. 2010-08-9 (Monday): Working Group and BOF scheduling begins. To request = a Working Group session, use the IETF Meeting Session Request Tool. 2010-09-13 (Monday): Cutoff date for BOF proposal requests to Area = Directors at 17:00 PT (24:00 UTC). To request a BOF, please see = instructions on Requesting a BOF. 2010-09-27 (Monday): Cutoff date for requests to schedule Working Group = meetings at 17:00 PT (24:00 UTC). To request a Working Group session, = use the IETF Meeting Session Request Tool. 2010-09-27 (Monday): Cutoff date for Area Directors to approve BOFs at = 17:00 PT (24:00 UTC). 2010-10-06 (Wednesday): Preliminary agenda published for comment. 2010-10-11 (Monday): Cutoff date for requests to reschedule Working = Group and BOF meetings 17:00 PT (24:00 UTC). 2010-10-11 (Monday): Working Group Chair approval for initial document = (Version -00) submissions appreciated by 17:00 PT (24:00 UTC). 2010-10-15 (Friday): Final agenda to be published. 2010-10-18 (Monday): Internet Draft Cut-off for initial document (-00) = submission by 17:00 PT (24:00 UTC), upload using IETF ID Submission = Tool. 2010-10-25 (Monday): Internet Draft final submission cut-off by 17:00 PT = (24:00 UTC), upload using IETF ID Submission Tool. 2010-10-27 (Wednesday): Draft Working Group agendas due by 17:00 PT = (24:00 UTC), upload using IETF Meeting Materials Management Tool. 2010-10-29 (Friday): Early Bird registration and payment cut-off at = 17:00 PT (24:00 UTC). 2010-11-01 (Monday): Revised Working Group agendas due by 17:00 PT = (01:00 Tuesday, November 02 UTC), upload using IETF Meeting Materials = Management Tool. 2010-11-01 (Monday): Registration cancellation cut-off at 17:00 PT = (01:00 Tuesday, November 02 UTC). 2010-11-05 (Friday): Final Pre-Registration and Pre-Payment cut-off at = 17:00 local Beijing time. (02:00 PT, 09:00 UTC). 2010-11-07 - 2010-11-12: 79th IETF Meeting in Beijing, China. 2010-12-10 (Friday): Proceedings submission cutoff date by 17:00 PT = (01:00 Saturday, December 11 UTC), upload using IETF Meeting Materials = Management Tool. 2011-01-05 (Wednesday): Proceedings submission corrections cutoff date = by 17:00 PT (01:00 Thursday, January 6 UTC), upload using IETF Meeting = Materials Management Tool. --Apple-Mail-321-183147305 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

IETF 79: November 7-12, 2010, Beijing, China

 

  • 2010-08-9 (Week of): IETF Online Registration opens.
  • 2010-08-9 (Monday): Working Group and BOF scheduling begins. To request a Working Group session, use the IETF Meeting Session Request Tool.
  • 2010-09-13 (Monday): Cutoff date for BOF proposal requests to Area Directors at 17:00 PT (24:00 UTC). To request a BOF, please see instructions on Requesting a BOF.
  • 2010-09-27 (Monday): Cutoff date for requests to schedule Working Group meetings at 17:00 PT (24:00 UTC). To request a Working Group session, use the IETF Meeting Session Request Tool.
  • 2010-09-27 (Monday): Cutoff date for Area Directors to approve BOFs at 17:00 PT (24:00 UTC).
  • 2010-10-06 (Wednesday): Preliminary agenda published for comment.
  • 2010-10-11 (Monday): Cutoff date for requests to reschedule Working Group and BOF meetings 17:00 PT (24:00 UTC).
  • 2010-10-11 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by 17:00 PT (24:00 UTC).
  • 2010-10-15 (Friday): Final agenda to be published.
  • 2010-10-18 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (24:00 UTC), upload using IETF ID Submission Tool.
  • 2010-10-25 (Monday): Internet Draft final submission cut-off by 17:00 PT (24:00 UTC), upload using IETF ID Submission Tool.
  • 2010-10-27 (Wednesday): Draft Working Group agendas due by 17:00 PT (24:00 UTC), upload using IETF Meeting Materials Management Tool.
  • 2010-10-29 (Friday): Early Bird registration and payment cut-off at 17:00 PT (24:00 UTC).
  • 2010-11-01 (Monday): Revised Working Group agendas due by 17:00 PT (01:00 Tuesday, November 02 UTC), upload using IETF Meeting Materials Management Tool.
  • 2010-11-01 (Monday): Registration cancellation cut-off at 17:00 PT (01:00 Tuesday, November 02 UTC).
  • 2010-11-05 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:00 local Beijing time. (02:00 PT, 09:00 UTC).
  • 2010-11-07 - 2010-11-12: 79th IETF Meeting in Beijing, China.
  • 2010-12-10 (Friday): Proceedings submission cutoff date by 17:00 PT (01:00 Saturday, December 11 UTC), upload using IETF Meeting Materials Management Tool.
  • 2011-01-05 (Wednesday): Proceedings submission corrections cutoff date by 17:00 PT (01:00 Thursday, January 6 UTC), upload using IETF Meeting Materials Management Tool.

--Apple-Mail-321-183147305-- From jpv@cisco.com Thu Sep 30 13:21:04 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADAA63A6E09 for ; Thu, 30 Sep 2010 13:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.396 X-Spam-Level: X-Spam-Status: No, score=-110.396 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b64j0ZcqiaET for ; Thu, 30 Sep 2010 13:21:00 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 623FE3A69C4 for ; Thu, 30 Sep 2010 13:21:00 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM+NpEyrR7Hu/2dsb2JhbACiMXGrCJw0hUQEijyDBogU X-IronPort-AV: E=Sophos;i="4.57,261,1283731200"; d="scan'208,217";a="263005867" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 30 Sep 2010 20:21:44 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o8UKLhWT028713; Thu, 30 Sep 2010 20:21:44 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Sep 2010 22:21:42 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Sep 2010 22:21:42 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-194-475649863 From: JP Vasseur In-Reply-To: Date: Thu, 30 Sep 2010 20:56:51 +0200 Message-Id: <33C30D88-2950-4FF0-AA4E-0E2127197756@cisco.com> References: <20100921191745.2814628C106@core3.amsl.com> To: ROLL WG , Omprakash Gnawali X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 30 Sep 2010 20:21:42.0291 (UTC) FILETIME=[185BF630:01CB60DD] Cc: David Culler Subject: [Roll] Adopting draft-gnawali-roll-minrank-hysteresis-of-02 as a new ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 30 Sep 2010 20:21:04 -0000 --Apple-Mail-194-475649863 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Omprakash, Thanks for the new revision addressing my comments. All,=20 Could you please let us know if you are in favor/opposed of adopting = draft-gnawali-roll-minrank-hysteresis-of as a ROLL Working Group = document ? Thanks. JP. On Sep 21, 2010, at 9:18 PM, Omprakash Gnawali wrote: > Dear WG, >=20 > I just updated the draft to address JP's comment on allowing for leaf = nodes. >=20 > - om_p >=20 > ---------- Forwarded message ---------- > From: IETF I-D Submission Tool > Date: Tue, Sep 21, 2010 at 2:17 PM > Subject: New Version Notification for > draft-gnawali-roll-minrank-hysteresis-of-02 > To: gnawali@cs.stanford.edu > Cc: pal@cs.stanford.edu >=20 >=20 >=20 > A new version of I-D, draft-gnawali-roll-minrank-hysteresis-of-02.txt > has been successfully submitted by Omprakash Gnawali and posted to the > IETF repository. >=20 > Filename: draft-gnawali-roll-minrank-hysteresis-of > Revision: 02 > Title: The Minimum Rank Objective Function with Hysteresis > Creation_date: 2010-09-21 > WG ID: Independent Submission > Number_of_pages: 8 >=20 > Abstract: > Hysteresis delays the effect of changes in link metric on parent > selection. Such delay makes the topology stable despite jitters in > link metrics. The Routing Protocol for Low Power and Lossy Networks > (RPL) allows the use of objective functions to construct routes that > optimize or constrain a routing metric on the paths. This > specification describes the Minimum Rank Objective Function with > Hysteresis (MRHOF), an objective function that minimizes the node > rank in terms of a given metric, while using hysteresis to prevent > excessive rank churn. The use of MRHOF with RPL results in nodes > selecting stable paths that minimize the given routing metric to the > roots of a Directed Acyclic Graph (DAG). >=20 >=20 >=20 > The IETF Secretariat. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-194-475649863 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear = WG,

I just updated the draft to address JP's comment on allowing = for leaf nodes.

- om_p

---------- Forwarded message = ----------
From: IETF I-D Submission Tool <idsubmission@ietf.org>
Dat= e: Tue, Sep 21, 2010 at 2:17 PM
Subject: New Version Notification = for
draft-gnawali-roll-minrank-hysteresis-of-02
To: gnawali@cs.stanford.edu
Cc:= pal@cs.stanford.edu


A new version of I-D, = draft-gnawali-roll-minrank-hysteresis-of-02.txt
has been successfully = submitted by Omprakash Gnawali and posted to the
IETF = repository.

Filename:       =  draft-gnawali-roll-minrank-hysteresis-of
Revision:   =      02
Title:           The = Minimum Rank Objective Function with Hysteresis
Creation_date:   = 2010-09-21
WG ID:           Independent = Submission
Number_of_pages: 8

Abstract:
Hysteresis delays = the effect of changes in link metric on parent
selection.  Such = delay makes the topology stable despite jitters in
link metrics. =  The Routing Protocol for Low Power and Lossy Networks
(RPL) = allows the use of objective functions to construct routes = that
optimize or constrain a routing metric on the paths. =  This
specification describes the Minimum Rank Objective = Function with
Hysteresis (MRHOF), an objective function that = minimizes the node
rank in terms of a given metric, while using = hysteresis to prevent
excessive rank churn.  The use of MRHOF = with RPL results in nodes
selecting stable paths that minimize the = given routing metric to the
roots of a Directed Acyclic Graph = (DAG).



The IETF = Secretariat.
_______________________________________________
Roll = mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-194-475649863-- From prvs=88295d1e4=Tzeta.Tsao@cooperindustries.com Thu Sep 30 14:35:23 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFB6D3A6CF3 for ; Thu, 30 Sep 2010 14:35:19 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwEY+rfmQAgH for ; Thu, 30 Sep 2010 14:35:00 -0700 (PDT) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by core3.amsl.com (Postfix) with ESMTP id 875083A6D2C for ; Thu, 30 Sep 2010 14:35:00 -0700 (PDT) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.57,261,1283745600"; d="scan'208";a="71348602" Received: from cipt0174.nam.ci.root ([10.132.108.174]) by cooperlighting-sw.cooperlighting.com with ESMTP; 30 Sep 2010 17:35:43 -0400 Received: from EVS4.NAM.CI.ROOT ([10.132.108.172]) by cipt0174.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Sep 2010 17:35:43 -0400 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: Thu, 30 Sep 2010 17:35:32 -0400 Message-ID: <9BB070DB2D281946859EA89837931EEE2B6625@EVS4.nam.ci.root> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-roll-security-framework-01 Thread-Index: Actg5tsZartRJieeQ4i3pI5x2QlPKwAACGFQ From: "Tsao, Tzeta" To: "ROLL WG" X-OriginalArrivalTime: 30 Sep 2010 21:35:43.0705 (UTC) FILETIME=[6FA5F490:01CB60E7] Subject: [Roll] FW: New Version Notification for draft-ietf-roll-security-framework-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 30 Sep 2010 21:35:25 -0000 WG, We have posted draft-ietf-roll-security-framework-01, which should be available from the repository shortly; hopefully it addressed the two tickets raised during the LC. Thanks, Tzeta -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Thursday, September 30, 2010 5:31 PM To: Tsao, Tzeta Cc: Alexander, Roger; mischa.dohler@cttc.es; vanesa.daza@upf.edu; angel.lozano@upf.edu Subject: New Version Notification for draft-ietf-roll-security-framework-01=20 A new version of I-D, draft-ietf-roll-security-framework-01.txt has been successfully submitted by Tzeta Tsao and posted to the IETF repository. Filename: draft-ietf-roll-security-framework Revision: 01 Title: A Security Framework for Routing over Low Power and Lossy Networks Creation_date: 2010-09-30 WG ID: roll Number_of_pages: 44 Abstract: This document presents a security framework for routing over low power and lossy networks (LLN). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and evaluating the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. As an illustration, this framework is applied to IPv6 Routing Protocol for Low Power and Lossy Networks (RPL). =20 The IETF Secretariat. From root@core3.amsl.com Thu Sep 30 14:45:02 2010 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 430A23A6C7E; Thu, 30 Sep 2010 14:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100930214502.430A23A6C7E@core3.amsl.com> Date: Thu, 30 Sep 2010 14:45:02 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-security-framework-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 30 Sep 2010 21:45:02 -0000 --NextPart 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 Security Framework for Routing over Low Power and Lossy Networks Author(s) : T. Tsao, et al. Filename : draft-ietf-roll-security-framework-01.txt Pages : 44 Date : 2010-09-30 This document presents a security framework for routing over low power and lossy networks (LLN). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and evaluating the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. As an illustration, this framework is applied to IPv6 Routing Protocol for Low Power and Lossy Networks (RPL). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-security-framework-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-security-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-09-30143045.I-D@ietf.org> --NextPart--