Hi Pascal, Responses in line.
> 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. Agree this is a very good endorsement from ISA. > > 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). Uggh. As purist I do not trust UDP in the first place :--). If one can build a stack supporting UPD and all that is required for AES then hearing that IPsec is to heavy for a sensor makes zero sense to me. > > 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. Can you say more because moving link layer control up to a transport in my view not only breaks the Internet Protocol Reference Model but the IEEE layer 1 and 2 models? Also IEEE does a fairly good job for most media to secure the link at that end? > 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. Ouch I don't even believe you should see any ports until after a decrypt from my security purist view. > > 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. Well for mission critical nets this is clearly not supportive of defense in depth at all. But I can see it as we are talking for some deployments that do not need defense in depth. Thanks /jim > > 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 --------------------------------------------------------------------
