Hi,
I have read draft-daniel-6lowpan-security-analysis-02.txt carefully.
IMHO, the assumptions should be improved, and the goal of this document
should be described explicitly at least. After that, we have to list
up the items to be analyzed. And, then a few inaccurate descriptions
should be corrected.
I attached details below.
Regards,
Shoichi Sakane
====
o the goal of this draft.
I haven't understood the goal of this document after I read this
draft. It is just analysis of 6lowpan, listing problems,
or suggesting a base model to solve 6lowpan security problems,
or proposing solutions for specific problem.
I felt that any things were included when I read this draft.
For example, the description of ND in section 7.2 is a solution.
SEND is needed to the wired network similarly, not unique solution
for 6lowpan. Here should be described what problem is and what
will happen in 6lowpan specific instead of solution.
In my personal opinion, this document should just describe the
analysis in perspective of 6lowpan. It is better to keep it by
describing problem statement even if it is described more.
If you want to describe a basic security model or solutions,
you need to define the security requirement for 6lowpan.
Defining requirements will raise up issues and problems to be
defined consequently, otherwise it is not meaning.
Aside from volume of the analysis description and accuracy, this
draft should cover whole part where a problem may happen as
possible. Currently, Gateway/BBR issue is not included.
ND issue, there is a description actually, should be into a
sole section and should be discussed separately.
o the assumptions of this document.
The assumptions should be located to the former part of the
document in order to clear the scope of this draft.
The relationship with the section of the security considerations
of the other documents should be described explicitly.
I think that the analysis depends on the assumption.
For example, the following is related to the result of analysis.
- availability of the 802.15.4-2003, or the 802.15.4-2006.
- unmanaged network or well-managed network,
- the communication range is either within a LoWPAN or
interconnection with other networks.
- symmetric cryptography, or ECC, or RSA as the constraint of
the 6lowpan device.
The assumption should be described these condition clearly.
Or, the document should analyze 6lowpan according to each condition.
o Security Threats
I think that this threat description needs improvement.
Generic threats of the wireless networks should be removed,
leaving some examples, and be referred to some appropriate
documents. For example, the following paper describes well.
"Secure Routing in Wireless Sensor Networks: Attacks and
Countermeasures", C.Karlof and D.Wagner, Sep, 2003.
There is a summary of this paper at
http://www.tcs.hut.fi/Studies/T-79.194/papers/hietalahti_050427.pdf
Here, it is important to describe 6lowpan specific threat.
o 6lowpan security analysis
I feel that IPsec is inappropriate for 6lowpan after I read
the section "IP Security analysis". I never advocate using IPsec.
But, the description should be accurate and fair.
Asymmetric cryptography is not used in both ESP and AH themselves.
So the impact to processing power is not so big. The impact by SSL
is similar to IPsec processing after the session key negotiation
of SSL.
The essence problem is within the key management protocol (KMP).
Typical KMP for IPsec is IKE. It is required to use asymmetric
cryptography. But, the impact to processing power is also similar
to SSL. When ECC is accepted, the impact is not so problem.
Furthermore, the impact is mitigated when symmetric cryptography
based KMPs like KINK or MIKEY-PSK is used. (Total message size of
KINK is typically bigger than IKE's though.)
In fact, my team had an experience to implement IPsec with KINK
into a embedded device which is on H8/3029 though the device did
not support 6lowpan.
The most severe issue is to influence into the bandwidth of 6lowpan.
Total message size of both IKE and SSL is not so different. Note
that the number of exchanging messages of SSL is more than IKE.
This draft recommends to use "cluster based dynamic key management
scheme". I think that this topic should be separated into another
document like key management protocol for 6lowpan. However, the
ability to exchange messages between a 6lowpan device and a device
of the outside of LoWPAN is probably required in some scenario.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
