Subject: Re: [Roll] Comments on draft-qiu-6lowpan-secure-router-01

From: "QIU Ying" <[email-masked]>
Date: Tue, 14 Dec 2010 19:54:56 +0800

Hi, Greg

Thank Greg for review and comment this draft.

Please see my response inline.

>Author: Greg Zaverucha ([email-masked])
>Date: 2010-11-26
>-----------------------------------------------------------------------
>Summary of the draft
>  The Qiu et al. draft gives a protocol for sensor nodes to authenticate
and
>establish a shared key.  The network topology is a mesh, allowing
>node-to-node communication.  In addition to sensor nodes there are routers
and
>base stations. Sensors have a pre-shared key with each base-station and
routers
>share a key with the base-station as well.  Routers and base stations
assist
>nodes to establish a shared key and authenticate.  The sensor nodes contact
the
>base station (which acts like a CA) to request a shared key with a router
or
>other node. The response from the base station is sent via a router who

Please note where the said via ROUTER is the new router that the sensor node
wants to attach.  

>processes the reponse before sending it to the node.  After the base
station
>response is sent to the sensor node, both the node and router have a shared
key
> (which is also known by the base station).

>-----------------------------------------------------------------------
>General comments
>
>- Section two should be expanded: describe what types of devices are in the
>  network (sensors, routers, basesstations), what their capabilities are in
>terms of communication and computation, if they are mobile, etc..  Adding
some
>details from RFC 4919 might be appropriate. 

OK. Will be maturated in new version.

>- In the introduction or Section 2 it might help to describe some typical
>  attacks that this proposal is trying to prevent, and maybe describe some
of
>the adversary's capabilites.

OK.

>- Two nodes must be in range of router or basestation to establish a key.
  Using public key-techniques this limitation is not present. 

I am not sure whether we need to consider this scenario in sensor
networking. IMHO, the job of a sensor is to collect the information and send
to base station to analysis and process, or performs the commands from the
base station. The capability of communicating directly between any two nodes
(neighbour or long distance) should be the scope of mobile networks. Any
comments?

>- On management of the table of shared keys: the Qiu et al. draft suggests
that
>  the oldest key in the table should be expunged if additional space is
>required. This is undesirable: instead an LRU (least recently used) type of
>algorithm should be used (or other page replacement algorithm which gives
>better performance given the access patterns of this application). Such an
>algorithm will require a small amount of overhead, but this cost will be
offset
>by a reduced number of key agreements.  

Good comments. Will be revised in new version.
 
>- In the notice message, is it really necessary for R0 to be sent back to
the node?
>The node already knows this value, and it must be used to check the MAC. 

Yes, the R0 cannot be ignored because the sensor node might send out many
request messages with various R0 if it cannot receive the notice message in
time. Hence, the sensor node must know which R0 is used in the notice
message. 

>- You should give some possible choices for the encryption and MAC
algorithms
>  used in the protocol, and what properties they should have.  For example,
in
>the appv message encryption is used, but I think it should be
>authenticated encryption.  The primitives in Suite E
>(http://tools.ietf.org/html/draft-campagna-suitee-00) would probably be
>suitable.

OK.

>- No guidance is given on key management issues.  How do new sensors
establish
>  shared keys with all routers and base stations?  What about adding new
>routers, how do all existing sensors get re-keyed?
>- The document gives no recommendations for parameter sizes

More details will appear in new version.

Regards and Thanks
Qiu Ying

Institute for Infocomm Research disclaimer:  "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you."