Subject: Re: [6lowpan] Security analysis 02 version is now available

From: Shoichi Sakane <[email-masked]>
Date: Tue, 11 Mar 2008 03:40:26 +0900

Hi Daniel,

> Your comments are highly welcome...
> http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-security-analysis-02.txt

        In section 7.2:
        >>Thei fact that IPsec additionally requires another header (AH or ESP)
        >>in every packet, thus increasing per-packet header overhead, makes its
        >>use problematic in 6lowpan environments.

I agree.  Actually, ESP with AES-CCM requires additional 32 bytes.
It is considerable.  I attached my response to your analysis draft-01.
There was an analysis of the overhead.

However, the security overhead of the packet size depends on the 6lowpan
application.  It might be drastically decreased.

        In section 8.1:
        >>Such a scheme is not suitable for sensor networks because there
        >>is usually no guarantee of communicating seamlessly with a trusted
        >>server at all the times in sensor networks.

I disagree with this statement.  I don't think a trusted third party
model is not suitable to all sensor networks.  Certainly, there might
not be assurance to connect to the centralized server in several sensor
networks.  But it is true that some sensor networks are designed to
be sure to connect to the server, e.g. typical industrial wireless
networks like WiHART and ISA100.

In this section, I think that it is enough to describe benefits and
issues of each mechanism.  No need to say which mechanism is good
nor others are bad.

Security is highly considerable issue in the wireless area.
I believe that what mechanism is the best depends on application.

Regards,

-- 
Shoichi Sakane
Yokogawa Electric Corporation

Subject: [6lowpan] comment about 6lowpan-security-analysis
From: Shoichi Sakane <[email-masked]>
To: [email-masked]
Date: Wed, 08 Nov 2006 19:18:23 +0900
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>

Hi all,

# If you get double mails from me, I am sorry that it was my fault.
# I sent the first mail from my wrong address, so it stacked at the
# owner of this list.

I read draft-daniel-6lowpan-security-analysis-01.txt.  I believe that
this activity is valuable to clarify the security problem for 6LoWPAN.
I thank the authors.  I would like to cooperate with the work as much as
I can.  At first, I have some comments in the section 7.2.

>>   Basically, IPsec targets to general IP nodes operated over ethernet.

It seems questionable.  I believe that it does not assume always using
over ethernet.

>>   It means each node has some of fluent stack size, bandwidth and non-
>>   low cost limitations like 6lowpan.

IPsec basically is based on symmetric cryptography.  This sentence is
only correct for some key mangement protocols to establish the keys,
like IKE.  I believe that KINK is suitable in term of power consumption.
Bandwidth consumption was not considered in both cases.

>>   Given the IPsec background, it is at least not suitable for 6lowpan
>>   nodes.  Especially, 6lowpan node may not be able to operate all IPsec
>>   algorithms on its own capability either FFD or RFD.

It is not needed to support all of likely algorithms of IPsec.  Algorithm
to be implemented for interoperability can be reduced according to RFC4305.
And RFC4309 defines how to use AES-CCM with IPsec so that a stack size might
be reduced because IEEE 802.15.4 does include AEC-CCM.

>>   Bandwidth is very sensitive element in the 6lowpan, but IPsec
>>   generates some of redundant packets such as AH/ESP header.

RFC4301 defined that AH is no longer mandated to implement.
I believe that we use just ESP to protect from almost 6LoWPAN threats.
However it is needed to investigate each threat if we do not need AH.
If we need ESP with AES-CCM, the packet size increases 32 bytes.
        4 bytes for SPI.
        4 bytes for sequence number as no ESN.
        8 bytes for IV.
        6 bytes for padding in minimum.
        1 bytes for pad length.
        1 bytes for next header.
        8 bytes for ICV.

Multiple security association between a 6lowpan node and different end
points make packet sizes increase.  However I do not think such usage
is not suitable for a 6lowpan node.  such usage is not realistic even
for a full function devices like PC.

>>   IPsec needs shared secret key between nodes called IKE (Internet Key
>>   Exchange), and it will make the key exchange in secrecy possible.  It
>>   can, however cause some of redundant packets over the 6lowpan
>>   networks.

Need a minor fix.  IKE is a protocol to establish such keys securely,
not secret keys.

And packets for key exchange is not redundant.  They are obviously necessary
to establish keys even if any method except manual keying are applied.
However, for low computaional power devices, IKE requires much power to
process asymmetric cryptography.  Indeed, a certain algorithm like ECC or
XTR can save power.  But it might not be still suitable for a 6lowpan devices.

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: "Daniel Park" <[email-masked]>
Date: Tue, 11 Mar 2008 05:07:21 +0900

Thanks your comments,

> I believe that what mechanism is the best depends on application.

That's why we are now focusing on security analysis not proposing
solution itself. Can you elaborate on any examples of 6lowpan security
applications ?

> ---------- Forwarded message ----------

---

From: Shoichi Sakane <[email-masked]>
Date: Tue, 11 Mar 2008 23:48:01 +0900

Hi, 

I probably misread.  If the goal of the document is to describe that the
current upper layer security mechanism is too heavy to realize the 6lowpan
security network, that is O.K. to me.

my concern at the meeting is that which mechanism we can use to realize the
6lowpan security when an application needs certain security.  and the application
needs inter-communication with the Internet.  we have to consider any security
mechanism in the upper layer of the 6lowpan.

again, if the devices in the 6lowpan network need to securely communicate with
the devices at the Internet, a secure layer is required upon the 6lowpan
layer.  ipsec could be the layer.  but ipsec is not always required because
there is other security layer like TLS which is most useful currently.
but overhead of TLS is much bigger than ipsec.

>> application.  It might be drastically decreased.

we could define a transform which is less packet size than the transforms
which had been standardized already so that the overhead of the packet
could be half.  but it maybe still considerable size.

> solution itself. Can you elaborate on any examples of 6lowpan security

well, SP100 could be one of the application.  but the specification assumed
presence of the key management under the 6lowpan.

regards,