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
--- Begin Message ---
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 protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
--- End Message ---
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
