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

From: <[email-masked]>
Date: Tue, 6 Apr 2010 18:10:54 +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.

IPsec is useful in many scenarios. But it is not an essential
requirement for IPv6 per se. Node requirements (RFC4294) mandates
IPsec on all types of nodes. However in the context of sensors, IPsec
requirement at best is a MAY (definitely not a MUST).

>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. 

IPsec is not necessarily the obvious choice. The choice of IPsec as
the security protocol for Mobile IPv6 (RFC3775) for example has
created far more complexity than being useful.  Security can be
accomplished without IPsec. Please do not fall into the trap that IPv6
nodes by default have an IPsec stack and hence all security
requirements can be met by IPsec. Alternatives should be evaluated.

-Raj

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 6 Apr 2010 19:35:41 +0200

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-masked]] 
Sent: Tuesday, April 06, 2010 2:25 PM
To: [email-masked]
Cc: [email-masked]; 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-masked]