Shoichi,
Sorry for the delay.
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.
Thanks, and highly welcome.
>> Basically, IPsec targets to general IP nodes operated over ethernet.
It seems questionable. I believe that it does not assume always using
over ethernet.
That's why I added *Basically* into the sentence. Your concern will be
clarified later if necessary of course.
>> 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.
Good suggestion if KINK is feasible for the 6lowpan security. Can you
more elaborate on that ? Especially, what gaps between IKE and KINK
and why you are thinking KINK is suitable in 6lowpan...
>> 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.
As long as we write this document, I lean to a general case. Then, we
will deeply investigate what algorithms can be used for the 6lowpan
security accordingly. But, good suggestion.
>> 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.
Agreed, as I pointed out, we will have further in-depth discussion
when working on the 6lowpan security solution later.
>> 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.
Agreed,
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.
Shoichi, your all comments are really acceptable and reasonable. Given
the WG opinion, we will work on the 6lowpan security solution as well
as analysis later.
Now, we are focusing on the basic stuff as 6lowpan format, so let me
stick to this work entirely for a while. Then I will get back to you
with more details regarding 6lowpan security stuffs. But, don't
hesitate to contact me if you have any comments on the 6lowpan
security works.
Obviously, I believe we should work on the 6lowpan security in the 2nd round.
Thanks and keep in touch.
--
Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
