Subject: [6lowpan] review of the draft of 6lowpan security analysis

From: Shoichi Sakane <[email-masked]>
Date: Wed, 20 Aug 2008 14:57:26 +0900

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-masked]
https://www.ietf.org/mailman/listinfo/6lowpan