Hi Shahid:
The mandatory support for IPsec has a long experience of not being implemented where it was not deemed useful. We live in a world where the practical aspects tend to dominate after all, and for all I know that's rather good news. In this case, I know number of successful WSN standards and products that use IPv6 and yet do not have IPSec. It appears that more often than not, and for a number of practical reasons, those standards have favored L2 and L4 security to IPSec. Second, the "cost" associated to IPSec is often not really IPSec itself but rather IKE and family. Not saying that we should not work on IPSec either. But I see no point in delaying HC to include it. IMHO, we'd better create a new draft that would also look at other 6LoWPAN security aspects, for instance the use or the adaptation of PANA and IKEv2 in a LoWPAN. Cheers, Pascal From: Shahid Raza [mailto:[email protected]] Sent: Tuesday, April 06, 2010 2:25 PM To: [email protected] Cc: [email protected]; Pascal Thubert (pthubert); Joakim Eriksson Subject: IPSec header compression provision in HC-06 (draft-ietf-6lowpan-hc-06) IPSec is mandatory for IPv6 which means that each IPV6 enabled device must be able to handle IPSec. However, 6LowPAN in its current form does not address IPSec processing. Thus, strictly speaking, 6LowPAN is an incomplete IPv6 implementation and there is reason to investigate if at least basic IPSec support can be added. I guess the whole point of assigning IP to a sensor node is to make it autonomous in all possible ways including security. The IP based sensor node should be able to establish secure sessions with the destination device (inside and outside PANs) without the intervention (or without trusting) any intermediate device such as 6LowPAN gateway etc.. To do so the obvious choice is IPSec as the traditional internet is already equipped with it; also, any available upper layer (Transport to Application) protocol with incur the same overhead as the IPSec does. There are discussions that IPSec is just too heavy for sensor network. This is not all true now as the ECC implementations for embedded device are available and AES CCM is already in use in sensor domain. Also, if we have IPSec the link layer security can be skipped and we can save maximum of 21 bytes there. These 21 bytes can be used to implement Authentication Header (AH) at IP layer. Hence the upcoming RFC for 6LowPAN (that will use LOWPAN_IPHC and LOWPAN_NHC) should at least provide a provision for IPSec. We are currently working on it and we claim the two reserved values (5, 6) of EID in the IPv6 Extension Header Encoding (http://tools.ietf.org/html/draft-ietf-6lowpan-hc-06). The EID values 101 and 110 will be used for IPSec's AH and ESP respectively. These provisions will help to implement compressed version of IPSec for 6LowPAN. Anticipating for this provision and your suggestions. Regards Shahid Raza Swedish Institute of Computer Science (SICS), Sweden Cell: +46 768831797 Email: [email protected]
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
