Hi all, I'm not a security expert, so I'm not eligible to make detail technical discussion on it. But I have the same concern with Pascal and Jonathan. As Jonathan and Pascal already explained the concerns on IPsec in sensor nodes' view, I won't repeat it. I just want to ask the experts on this area to consider the reality that many 6LoWPAN implementors feel hard to squeeze IPsec into the small sensor nodes. I hope that this discussion trigger either the study of IPSec if it can be enough lightweight to be applicable on 6LoWPAN nodes, or practical solutions on sensor network security.
Thanks, -eunah (PS) ISA's choice sounds very interesting for me, although I need to check the details. Thanks Pascal for the information. On 2/28/08, Jonathan Hui <[EMAIL PROTECTED]> wrote: > > Right. We've already seen AES + CCM implemented in hardware with > 802.15.4 radios. While some of those implementations are currently 15.4 > specific, the fact that it is not more general could be considered an > 'implementation flaw'. > > The biggest concern to those of us trying to deal with IEEE 802.15.4 is > really the header overhead. For this reason, the security protocol for > IEEE 802.15.4 allows for variable size IV and ICV, giving the ability to > make the tradeoffs we need. The basic functions of RFC4309 seem > particularly applicable for IPsec over 802.15.4 links, but the header > size is of concern. The IV carried in each packet is required to be 8 > bytes and the ICV is required to be between 8 and 16 bytes. 802.15.4, on > the other hand, allows smaller fields for both the IV and ICV and gives > the flexibility to make tradeoffs. When you're working with nodes that > send very small messages and maximum frame sizes of 128 bytes (including > link headers), every byte counts. > > I'm also concerned on the requirement for automated key distribution. Is > it possible to claim that you support IPsec without supporting automated > key management like IKEv2 or something similar? > > I'm interested in working through this more in detail to do the study of > whether IPsec is a viable option and would like to solicit help from > those that have more expertise in this space. If anyone is interested, > let me know. > > -- > Jonathan Hui > > > Bound, Jim wrote: > > It all comes down to is IPsec capable for the nodes within the discussion > > below and I point to Tony Hain's mail that IPsec is far better than 47 > > security protocol options from an IETF doing our job here. Batteries are > > energy cost impacting other work in the IETF too it is a reality we need to > > be aware of for sure. > > > > thanks > > /jim > > > >> -----Original Message----- > >> From: Jonathan Hui [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, February 27, 2008 3:04 AM > >> To: Pascal Thubert (pthubert) > >> Cc: Bound, Jim; ipv6@ietf.org > >> Subject: Re: IPsec and 6LoWPAN (was: Re: Making IPsec *not* > >> mandatory inNode Requirement) > >> > >> > >> To answer Jim's question following on Pascal's point, I don't > >> believe that only link-layer security is enough because it > >> lacks any end-to-end properties. It wasn't clear in my > >> previous email, but multihop topologies are the norm in > >> low-power wireless with IEEE 802.15.4. > >> > >> The ISA100.11a approach which sits above UDP or a lightweight > >> version of IPsec which sits a bit lower in the layering are > >> both much more attractive approaches to me than requiring > >> IPsec, as we know it today, on sensor nodes. Of course, we > >> won't get all of the features of a full-blown IPsec > >> implementation, but we've got to trade something to live in > >> this constrained world. I'm willing to live with that and I'm > >> wondering what others on this list think about that. > >> Specifically, is there a place for the IETF to specify a > >> lightweight end-to-end security scheme in place of IPsec? > >> > >> The question of IPsec vs. engineering cost is in some sense > >> true, but it doesn't capture the entire story. IPsec has > >> significant header requirements, compared to the link MTU of > >> IEEE 802.15.4. This translates directly to extra buffering > >> requirements, channel utilization, and energy cost. You could > >> argue to use bigger batteries, but some environments with > >> physical and environmental constraints can't afford to do so. > >> > >> -- > >> Jonathan Hui > >> > >> > >> Pascal Thubert (pthubert) wrote: > >>> Hi Jim: > >>> > >>> All I can say is that at least one Wireless Sensor Network > >> standard under development will not use IPSec. ISA100.11a > >> (http://www.isa.org/MSTemplate.cfm?MicrositeID=1134&CommitteeI > >> D=6891) has decided to endorse - and extend when necessary - > >> the work done at 802.15.4 and 6LoWPAN, which means that we > >> will have IPv6-based sensors in the industrial WSN space. I > >> say it's great news and we-IETF should continue in our effort > >> to support the ISA there. > >>> ISA100.11a is defining a simple transport level security > >> above UDP that is based on the AES encryption engine in the > >> CCM mode (in reality CCM* as defined by 802.15.4, annex B, > >> which refers to CCM as defined by ANSI X9.63-2001 as well as > >> NIST Pub 800-38C and RFC 3610, that's a quote for the purists). > >>> The ISA100.11a Transport level security replicates end to > >> end what is done at the Data Link Layer in order to benefit > >> from the chipset built-in features. No IKE, No IPSec at least > >> for the current spec. A side effect of that design is that > >> we'll be able to elide the UDP checksum in the 6LoWPAN > >> compression by including the IPv6 pseudo header and the UDP > >> ports in the Message Integrity Check computation, pushing the > >> whole computation up a sublayer. > >>> I've come to expect that the encryption will be done end to > >> end at the transport level whereas the integrity and > >> authentication will be played hop by hop over the DLL mesh, > >> but that's a deployment decision. > >>> Pascal > >>> > >>> > >>>> -----Original Message----- > >>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >> On Behalf > >>>> Of Bound, Jim > >>>> Sent: mercredi 27 février 2008 05:46 > >>>> To: Jonathan Hui; ipv6@ietf.org > >>>> Subject: RE: IPsec and 6LoWPAN (was: Re: Making IPsec > >> *not* mandatory > >>>> inNode Requirement) > >>>> > >>>> Good point and Gordon Bell has almost always been right > >> for me so I > >>>> know I listen to him. The key is do these low power and > >> restricted > >>>> sensor components require security at the IP layer? > >>>> If IEEE xxx is secure can we conclude the IP layer is not relevant > >>>> for sensors, but I would suggest they are for any sensor gateway > >>>> nodes. Or can we develop in industry a micro-kernel IPsec > >>>> implementation in hardware that can be cost effectively added to a > >>>> sensor or set of sensor unions for a network? Clearly we > >> are seeing > >>>> this type of hardware development on microprocessors with the > >>>> exponential appearance of deep packet inspection providers > >> into the > >>>> market that are not router/switch vendors. But is IPsec the right > >>>> answer is the right question for lowpan for engineering > >> cost reasons > >>>> as opposed to is it possible? > >>>> > >>>> /jim > >>>> > >>>>> -----Original Message----- > >>>>> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf > >>>>> Of Jonathan Hui > >>>>> Sent: Tuesday, February 26, 2008 6:57 PM > >>>>> To: ipv6@ietf.org > >>>>> Subject: IPsec and 6LoWPAN (was: Re: Making IPsec *not* > >> mandatory in > >>>>> Node Requirement) > >>>>> > >>>>> > >>>>> I won't argue against the fact that security is an important > >>>> part of a > >>>>> complete solution. The question for me is whether IPsec > >> is the most > >>>>> appropriate solution for highly constrained embedded devices > >>>>> (constrained in energy, memory, compute, and link > >>>> capabilities). From > >>>>> the few implementation numbers thrown around this thread, > >> it sounds > >>>>> like IPsec is not an option for low-power wireless nodes > >>>> with 8K RAM, > >>>>> 48K ROM, 128B link MTU, and not to mention that any > >> implementation > >>>>> should leave enough space for an interesting application > >> and should > >>>>> operate for multiple years on modest batteries. > >>>>> > >>>>> One nice thing is that, given some application scenarios, > >> there are > >>>>> other ways to incorporate sufficient security without the > >> need for > >>>>> IPsec. For example, link-layer security may be sufficient > >>>> for private > >>>>> networks. Link-layer security may also be sufficient if border > >>>>> routers/gateways attach to other traditional IP networks via > >>>> encrypted > >>>>> tunnels. > >>>>> > >>>>> I'm not a security expert, nor do I know the complete workings of > >>>>> IPsec. > >>>>> But I'd be curious if people strongly believe or have ideas > >>>> on ways to > >>>>> squeeze IPsec into devices that I'm interested in. > >>>>> If not, is it at all possible to consider developing an > >> alternative > >>>>> end-to-end security mechanism that is lightweight. I'm > >> not arguing > >>>>> that this should be used between two traditional IP hosts, > >>>> but that it > >>>>> can be used between a traditional IP host communicating with a > >>>>> low-power, wireless device or two low-power wireless devices > >>>>> communicating directly. > >>>>> > >>>>> Gordon Bell observed that we've seen a new class of > >> computing form > >>>>> about every decade. IP has so far been able to follow > >> these trends, > >>>>> including hand held devices. Now we are at the beginning of yet > >>>>> another class with low-power wireless devices based on IEEE > >>>> 802.15.4, > >>>>> and the 6lowpan effort within the IETF has set out to > >> bring IPv6 to > >>>>> this new class. I'd be disappointed if we couldn't come to an > >>>>> agreement on how we can appropriately bring this new class > >>>> into the IP > >>>>> framework. > >>>>> > >>>>> -- > >>>>> Jonathan Hui > >>>>> > >> -------------------------------------------------------------------- > >>>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>>>> Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >>>>> > >> -------------------------------------------------------------------- > >> -------------------------------------------------------------------- > >>>> IETF IPv6 working group mailing list > >>>> ipv6@ietf.org > >>>> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >>>> > >> -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
