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 --------------------------------------------------------------------
