Thanks your comments, On Tue, Mar 11, 2008 at 3:40 AM, Shoichi Sakane <[EMAIL PROTECTED]> wrote: > 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.
That's why we are now focusing on security analysis not proposing solution itself. Can you elaborate on any examples of 6lowpan security applications ? > -- > Shoichi Sakane > Yokogawa Electric Corporation > > > ---------- Forwarded message ---------- > From: Shoichi Sakane <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Date: Wed, 08 Nov 2006 19:18:23 +0900 > Subject: [6lowpan] comment about 6lowpan-security-analysis > 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 > > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
