Subject: [6lowapp] Proposed Charter Changes

From: "Oflynn, Colin" <[email-masked]>
Date: Sat, 16 Jan 2010 02:36:52 -0700

Hello,

Zach and I have been working on charter updates, to support a new I-Draft we have coming (next week hopefully). Essentially it is designed to make the charter more flexible with respect to methods of configuring the initial network.

Also note we use the term 'security bootstrapping' as in draft-struik-6lowapp-security-considerations. It was felt that 'bootstrapping' is more in-line with the operating we are performing, since it requires setting up a network without any prior communication between nodes. 

Suggest changes are removal of lines:

-This WG will support three commissioning methodologies:
... Inclusive to ...
-Modes 1 and 2 are mandatory to implement but mode 3 is optional.
-In all modes, once Device A and Device B have formed a secure connection 
-with Device C, Device C can be used to transitively introduce A and B so now 
-A and B have a secure connection with C. This transitive trust introduction 
-can be used during commissioning even if A and B do not yet have network 
-connectivity to each other. 

And addition of lines

+ The WG will work to support methods of security bootstrapping which are 
+ realistic given the constraints and requirements of the network. These 
+ methods are not specific to any communication layer. Instead the methods 
+ could run across any layer, including IP. Requirements considered include:
+ 
+ 1) Suitable for use on resource constrained nodes. This includes power, 
+ cost, size, and computational constraints.
+ 
+ 2) Capable of possessing sufficient security for the application space.
+ 
+ 3) Realistically guarantee any two nodes can join together. This includes 
+ nodes which are already on separate networks, but a user wishes to have those
+ two networks merge together.
+ 
+ 4) Additional requirements for each application space, such as urban or 
+ commercial environments which deploy large networks compared to residential
+ environments.
+
+ To ensure that any two nodes can join together, all nodes must implement at
+ least one universal method. In additional several other methods will be
+ specified which take advantage of the application space. In commercial
+ applications for instance bootstrapping can take advantage of the fact
+ that networks are typically managed from a central authority, and a method
+ optimized for residential usage might take advantage of the fact that nodes
+ are in close proximity.
+
+ Methods which will be considered include:
+
+ 1) Out of Band Key or Certificate. In this mode a key (either symmetric or
+ asymmetric) is distributed with the product, such as a 2D barcode printed on
+ the node. The user can scan this key with a computer and give access to this
+ node. Typically might be found in industrial, commercial, or urban environments
+ with a central authority.
+
+ 2) Push Button Protocol. In this mode two nodes only require pushbuttons and LEDs,
+ and the user simply pushes the button on each node. Due to the simplicity this
+ might be found in home installations.
+
+ 3) Out of Band Wireless Communication Link. This could include IrDA or NFC
+ (Near Field Communication) type technologies. Due to the extra hardware requirements
+ this may be found on higher performance nodes. However medical applications may
+ make use of optical communication techniques due to other requirements.
+
+ 4) Out of Band Physical Communication Link. The simplest example of this is the
+ programming interface which a node uses to download firmware. As all nodes already
+ have this hardware present, this may be the simplest interface to implement.
+
+ This list should not be considered exhaustive, and methods may be removed or added
+ as additional application spaces and requirements are found. The list gives examples
+ of the types of methods to be investigated. 

Any comments, suggestions, or questions would be appreciated.

Regards,

  -Colin O'Flynn

---

From: JP Vasseur <[email-masked]>
Date: Sun, 17 Jan 2010 10:25:48 +0100

Hi Colin,

One quick general comment is that I would propose not to specify any  
specific media (no reference to wireless, all mechanisms should also  
apply to different PHY/MAC such as PLC).
I do not think that you need in the charter to already specify  
methods, but just working group items.

Thanks.

JP.

On Jan 16, 2010, at 10:36 AM, Oflynn, Colin wrote:

> Hello,
>
> Zach and I have been working on charter updates, to support a new I- 
> Draft we have coming (next week hopefully). Essentially it is  
> designed to make the charter more flexible with respect to methods  
> of configuring the initial network.
>
> Also note we use the term 'security bootstrapping' as in draft- 
> struik-6lowapp-security-considerations. It was felt that  
> 'bootstrapping' is more in-line with the operating we are  
> performing, since it requires setting up a network without any prior  
> communication between nodes.
>
> _______________________________________________
> 6lowapp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowapp

---

From: Zach Shelby <[email-masked]>
Date: Tue, 19 Jan 2010 14:36:51 +0200

On Jan 17, 2010, at 11:25 , JP Vasseur wrote:

> Hi Colin,
> 
> One quick general comment is that I would propose not to specify any specific media (no reference to wireless, all mechanisms should also apply to different PHY/MAC such as PLC).

Good point. 

> I do not think that you need in the charter to already specify methods, but just working group items.

Right, Cullen included a list of possible methods in the http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp charter proposal. The idea here was to make them more generic so that the work can be done in the WG. You are suggesting that we leave the "Methods which will be considered include:" text away, I would be OK with that.

Regarding the work item, the message from Hiroshima was that we need to reduce the number of work items as much as possible, possibly even just a single work item (CoAP). However considering that this security bootstrapping work will have wider application in these environments I suggest that it should be a separate work item. Currently in http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp there are 4 work items. I suggest that we reduce that to 2:

1. CoAP including discovery and HTTP mapping. PS

2. Security bootstrapping. PS

Regards,
Zach

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.

---

From: Jorge Amodio <[email-masked]>
Date: Tue, 19 Jan 2010 09:00:12 -0600

> specific media (no reference to wireless, all mechanisms should also apply
> to different PHY/MAC such as PLC).

+1

Regads
Jorge