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
