Hi Jim: Please see inline:
>> 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. I was not there when that decision was made and I do not know all the details. Seems to me that we get a result that is close to D-TLS with a security sublayer sitting above UDP as opposed to a sitting at the bottom of the app layer. That much does not bother me too much because it is an end point thing above standard UDP and the end-to-end principle is respected. I need to dig but my current understanding is that the ISA approach saves bytes in the packet, which is *critical* in the sensor space; part of that saving comes from using time in the nonce but not passing (all of) it over the air because devices are somewhat synchronized. Anyway, once you have a D-TLS prime and a good L2 security, it's hard to justify you need IPSec as well. I figure that ISA100.11a falls into Tony's "specific deployment or application," because ISA defines both ends of a communication, so this does not bother me too much either. What I've been trying to do is make sure that the packets across the backbone (that interconnects LoWPANs) are standard IPv6 packets and that basic rules such as RFC 3448 are taken into consideration in the end points. None of this was a given to start with :) > >> >> 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? ISA has cleanly defined layers which pretty much echo the TCP/IP model, and has both L2 and upper L4 security, but no L3 security. What I've been trying to say here is that the crypto operation is the same at both layers so the crypto engine available for L2 in the chipsets can be reused by the transport security; thus the use of standard AES with CCM* mode. Each layer secures its own data per its own policy; for instance upper L4 will encrypt the payload and L2 will only authenticate the frame. As a result, the crypto engine present in the chipset will run twice. Once and L2 and once at L4 if you're terminating the connection; once to check and once to sign if you're only forwarding over the L2 mesh. >> 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. What we do is a DTLS prime, not an IPSec Prime. So the UDP ports are visible but still we want to prevent tempering with them. In particular for the UDP checksum, what I'm trying to do is get an IP+UDP pseudo-header included in the MIC computation but not encrypted, to emulate the UDP checksum so that the UDP checksum can be elided. With CCM, it is possible to encrypt only a part of the message, leaving - typically a header - in the clear. Obviously, we elide the pseudo-header as well for transmission. With the checksum trick, UDP is in the clear but still protected against corruption along the path. As a result, the UDP header can be compressed down to 1 byte as opposed to 3 bytes with RFC 4944. I'm planning to document that process to 6LoWPAN see if we can get a consensus betweem the 2 organizations that the whole thing is workable. I hope it is clearer now :) Pascal > >> >> 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 --------------------------------------------------------------------
