Subject: [6lowpan] IPSec header compression provision in HC-06 (draft-ietf-6lowpan-hc-06)

From: "Shahid Raza" <[email-masked]>
Date: Tue, 6 Apr 2010 14:37:20 +0200

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

---

From: Shoichi Sakane <[email-masked]>
Date: Wed, 07 Apr 2010 14:45:44 +0900

Hi Shahid,

Even if a protocol mandates a kind of security, it doesn't automatically
mean to adopt the security.  When we look at the world realistically, we
always need to consider what type of security we employ and where we will
apply it.  I don't think whole scenarios in IP-based WSN requires IP
layer's security.

When you find a certain scenario in which IPsec is the best way to provide
a kind of security, and when we get a reasonable mechanism of provisioning
the shared keys for IPsec, IPsec is useful in that context.

I support the suggestion of Pascal.  We should think it separately from 
current HC anyway.

Personally, I am interested in your work. :-)

===
Shoichi Sakane

On 04/06/2010 09:37 PM, Shahid Raza wrote:
>  
> 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.
>  
> Email: [email-masked] <mailto:[email-masked]>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan