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&CommitteeID=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 --------------------------------------------------------------------
