Subject: [6tisch] CoAP resource management - draft-ietf-6tisch-coap-02

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Tue, 11 Nov 2014 15:36:51 +0000

All,

The chairs and the authors discussed the CoAP draft recently. We agreed that we need to push the CoAP draft since CoMAN may take a long time to converge and become usable. We also agreed that some changes were required to the CoAP draft to make any future transition to CoMAN easy. The changes discussed are as follows -

  1.  Add versioning info – This will allow heterogenous 6top nodes to communicate in the same network and PCE (or peer nodes) to take advantages of resources available in future versions. Also allows easier transition to CoMAN.
     *   Added text to RFC. attached changes in versioning.txt (this is a git diff for easy review)
  2.  Shorten resource names – to reduce overhead
     *   Added text to RFC. Attached changes in changetouri.txt

The third and most important discussion was -
3. How do nodes exchange the version data (with PCE and other nodes) of nodes so a network of heterogenous nodes (w.r.t version) can interoperate.
1. Proposal - use the joining flows defined in draft-richardson-6tisch--security-6top-03

Comments and suggestions on this proposal are requested.

The updated draft is available on bitbucket - https://bitbucket.org/6tisch/draft-ietf-6tisch-coap/overview

-raghuram
diff --git a/draft-ietf-6tisch-coap-02.xml b/draft-ietf-6tisch-coap-02.xml
index 57d86a6..f8fde84 100644
--- a/draft-ietf-6tisch-coap-02.xml
+++ b/draft-ietf-6tisch-coap-02.xml
@@ -177,28 +177,28 @@
 | Name        | Accessibility   | URI path      |
 |             | 6top Commands   |               |
 +-------------+-----------------+---------------+
-| Neighbor    | CREATE/READ/    | 6t/Neighbor   |
+| Neighbor    | CREATE/READ/    | 6t/nb         |
 | List        | DELETE/UPDATE   |               |
 +-------------+-----------------+---------------+
-| slotframe   | CREATE/READ/    | 6t/slotframe  |
+| slotframe   | CREATE/READ/    | 6t/sf         |
 | List        | DELETE/UPDATE   |               |
 +-------------+-----------------+---------------+
-| Cell        | CREATE/READ/    | 6t/Cell       |
+| Cell        | CREATE/READ/    | 6t/cl         |
 | List        | DELETE/UPDATE   |               |
 +-------------+-----------------+---------------+
-| Time        | CREATE/READ/    | 6t/TimeSource |
+| Time        | CREATE/READ/    | 6t/ts         |
 | Source      | DELETE/UPDATE   |               |
 +-------------+-----------------+---------------+
-| LabelSwitch | CREATE/READ/    | 6t/LblSwitch  |
+| LabelSwitch | CREATE/READ/    | 6t/ls         |
 | List        | DELETE/UPDATE   |               |
 +-------------+-----------------+---------------+
-| Track       | CREATE/READ/    | 6t/Track      |
+| Track       | CREATE/READ/    | 6t/tr         |
 | List        | DELETE/UPDATE   |               |
 +-------------+-----------------+---------------+
-| EB          | CREATE/READ/    | 6t/EB         |
+| EB          | CREATE/READ/    | 6t/eb         |
 | List        | DELETE/UPDATE   |               |
 +-------------+-----------------+---------------+
-| Chunk       | CREATE/READ/    | 6t/Chunk      |
+| Chunk       | CREATE/READ/    | 6t/ch         |
 | List        | DELETE/UPDATE   |               |
 +-------------+-----------------+---------------+
 ]]></artwork>
@@ -211,14 +211,14 @@
 +-------------+---------------------------+
 | Field name  | URI path                  |
 +-------------+---------------------------+
-| Neighbor    | 6t/Neighbor/TargetNodeAddr|
+| Neighbor    | 6t/nb/tna 		 		  |
 | Addr        |                           |
 +-------------+---------------------------+
-| ASN         | 6t/Neighbor/ASN           |
+| ASN         | 6t/nb/asn           	  |
 +-------------+---------------------------+
-| RSSI        | 6t/Neighbor/RSSI          |
+| RSSI        | 6t/nb/rssi          	  |
 +-------------+---------------------------+
-| LinkQuality | 6t/Neighbor/LinkQuality   |
+| LinkQuality | 6t/nb/lq 		 		  |
 +-------------+---------------------------+
 ]]></artwork>
                </figure>        
@@ -233,12 +233,12 @@
 | Name        | Accessibility   |    URI path           |
 |             | 6top Commands   |                       |
 +-------------+-----------------+-----------------------+
-| Queue       | READ/CONFIGURE  | 6t/Queue              |
+| Queue       | READ/CONFIGURE  | 6t/qu 				|
 +-------------+-----------------+-----------------------+
-| Monitoring  | READ/CONFIGURE  | 6t/MonitoringStatus   |
+| Monitoring  | READ/CONFIGURE  | 6t/ms 				|
 | status      |                 |                       |
 +-------------+-----------------+-----------------------+
-| Statistics  | READ/CONFIGURE  | 6t/StatisticsMetrics  |
+| Statistics  | READ/CONFIGURE  | 6t/sm 				|
 | metrics     |                 |                       |
 +-------------+-----------------+-----------------------+
 ]]></artwork>
@@ -254,7 +254,7 @@
         +------------------------------------------+
 Header  | GET                                      |
         +------------------------------------------+
-Uri-Path| /6t/Neighbor                             |
+Uri-Path| /6t/nb 				   				   |
         +------------------------------------------+
 Options | Accept: application/cbor                 |
         | Uri-Query: ABNF(TargetNodeAddr==0x1234)  |
@@ -265,7 +265,7 @@ Options | Accept: application/cbor                 |
                   Since this resources points to the entire neighbor list, the response returns all the entries (the list of neighbors of that node) and all fields in each entry (i.e. entry for a neighbor) of the list in CBOR format. A request with a Uri-Query option may be used to retrieve only specific entries in the list. The value of Uri-Query MUST be in the ABNF format as described in <xref target ="RFC5234"/>.
                </t>
                <t>
-                  Resources that point to collection within a list, such as '/6t/Neighbor/TargetNodeAddr',
+                  Resources that point to collection within a list, such as '/6t/nb/tna',
                   returns only the values in the TargetNodeAddr entry of the Neighbor list. The usage
                   of the Uri-Query option has the same effect of filtering on the result.
                </t>
@@ -282,14 +282,14 @@ Options | Accept: application/cbor                 |
         +-------------------------------------+
 Header  | POST                                |
         +-------------------------------------+
-Uri-Path| /6t/Neighbor                        |
+Uri-Path| /6t/nb 			      			  |
         +-------------------------------------+
 Payload | CBOR( {TargetNodeAddr: 0x1234} )    |
         +-------------------------------------+
 ]]></artwork>
                </figure>
                <t>
-                  The POST method may not be used on resources that are collection within a list, such as '/6t/Neighbor/TargetNodeAddr'.
+                  The POST method may not be used on resources that are collection within a list, such as '/6t/nb/tna'.
                </t>
                <t>
                   To delete a Neighbor, the CoAP client MUST send a DELETE message as shown in <xref target="fig:delmsg"/>.
@@ -299,7 +299,7 @@ Payload | CBOR( {TargetNodeAddr: 0x1234} )    |
         +-------------------------------------+
 Header  | DELETE                              |
         +-------------------------------------+
-Uri-Path| /6t/Neighbor                        |
+Uri-Path| /6t/nb 			      			  |
         +-------------------------------------+
 Options | Uri-Query: ABNF(TargetNodeAddr      |
         |                      == 0x1234)     |
@@ -307,7 +307,7 @@ Options | Uri-Query: ABNF(TargetNodeAddr      |
 ]]></artwork>
                </figure>
                <t>
-                  A DELETE message SHOULD always contain a Uri-Query option in order to clearly specify which entry(s) within the list must be deleted. Ideally, the CoAP client SHOULD make one call per entry that must be deleted. An implementation may decide whether or not a DELETE method on '/6t/Neighbor' may be allowed.
+                  A DELETE message SHOULD always contain a Uri-Query option in order to clearly specify which entry(s) within the list must be deleted. Ideally, the CoAP client SHOULD make one call per entry that must be deleted. An implementation may decide whether or not a DELETE method on '/6t/nb' may be allowed.
                </t>
                <t>
                   The endpoint MUST appropriately respond with a 2.02 (Deleted) message.
@@ -320,26 +320,26 @@ Options | Uri-Query: ABNF(TargetNodeAddr      |
 +--------------------+----------------+---------------+-------------+
 |   CoAP method      |  6top command  |6top behaviour |CoAP Response|
 +--------------------+----------------+---------------+-------------+
-| POST /6t/Neighbor  | Create.neighbor| Adds a        | 2.01 Created|
+| POST /6t/nb 	     | Create.neighbor| Adds a        | 2.01 Created|
 | CBOR(              |                | neighbor      |             |
 | {TargetNodeAddr:   | (address,stats)|               |             |
 |             1234}) |                |               |             |
 +--------------------+----------------+---------------+-------------+
-| GET /6t/Neighbor   | Read.all.      | Reads         | 2.05 Content|
+| GET /6t/nb         | Read.all.      | Reads         | 2.05 Content|
 |                    | neighbor()     | all           | CBOR(Neigh- |
 |                    |                | neighbors     | bor List)   |
 +--------------------+----------------+---------------+-------------+
-| GET /6t/Neighbor   | Read.neighbor  | Reads neighbor| 2.05 Content|
+| GET /6t/nb         | Read.neighbor  | Reads neighbor| 2.05 Content|
 | Uri-Query -        |  (address)     | information   | CBOR(Neigh- |
 | TargetNodeAddr:    |                |               | bor List)   |
 |             1234}) |                |               |             |
 +--------------------+----------------+---------------+-------------+
-| POST /6t/Neighbor  | Update.neighbor| Updates an    | 2.04 Changed|
+| POST /6t/nb        | Update.neighbor| Updates an    | 2.04 Changed|
 | CBOR(              | (address,stats)| entry         |             |
 | {TargetNodeAddr:   |                |               |             |
 |             1234}) |                |               |             |
 +--------------------+----------------+---------------+-------------+
-| DELETE /6t/Neighbor|Delete.neighbor | Removes       | 2.02 Deleted| 
+| DELETE /6t/nb      |Delete.neighbor | Removes       | 2.02 Deleted| 
 | Uri-Query -        | (address)      | the neighbor  |             |
 | TargetNodeAddr     |                |               |             |
 |          == 1234}) |                |               |             |
@@ -388,10 +388,10 @@ CoAP Client                Node A                   Node A
                       (CoAP-endpoint)         (6top sublayer)
     |     CoAP Request       |                        |
     |- - - - - - - - - - - ->| 6top Request           |
-    | POST /6t/Neighbor      |----------------------->|
+    | POST /6t/nb            |----------------------->|
     | payload:               | Create.neighbor        | Adds a
     | CBOR({TargertNodeAddr: | (address,stats)        | neighbor
-	|             1234})     |                        | with address
+    |             1234})     |                        | with address
     |                        |                        | 1234
     |                        | 6top Confirm           |
     |   CoAP Response        |<-----------------------|
@@ -409,7 +409,7 @@ CoAP Client                Node A                   Node A
                       (CoAP-endpoint)          (6top sublayer)
     |     CoAP Request       |                        |
     |- - - - - - - - - - - ->| 6top Request           |
-    | GET /6t/Neighbor       |----------------------->|
+    | GET /6t/nb             |----------------------->|
     | Uri-Query -            | Read.neighbor(address) |Reads neighbor
     | TargetNodeAddr         |                        |information
     |       == 0x1234        |                        |
@@ -432,7 +432,7 @@ CoAP Client                 Node A                   Node A
                        (CoAP-endpoint)          (6top sublayer)
     |     CoAP Register       |                        |
     |- - - - - - - - - - - - >| 6top Request           |
-    | GET /6t/MonitoringStatus|----------------------->|
+    | GET /6t/ms 	      	  |----------------------->|
     |                         | Read.Monitoring.Status |Reads
     |                         |                        |the current
     |                         |                        |Monitoring 
diff --git a/draft-ietf-6tisch-coap-02.xml b/draft-ietf-6tisch-coap-02.xml
index f8fde84..ecd30b6 100644
--- a/draft-ietf-6tisch-coap-02.xml
+++ b/draft-ietf-6tisch-coap-02.xml
@@ -161,12 +161,25 @@
             </t>
          </section>
          <section title="6TiSCH Resources ">
+				 <t>
+						 The 6TiSCH resources presented in this memo offer a comprehensive way to manage 6top nodes based on the requirement known to us as of this writing. These resources are bound to evolve and will be identified by appropriate version numbers that will be tied to revisions of this RFC.
+				 </t>
             <t>
                Management resources are classified as resources to which a higher layer entity may create, update or delete. They are typically used to create schedules, identify time sources that TSCH needs. They are the means to close the control loop between TSCH and higher layers.
             </t>
             <t>
                Informational resources are classified as resources to which a higher layer entity typically has only READ access. They are typically used to monitor operational parameters of TSCH and the values used as input to routing algorithms and other mechanisms.
             </t>
+			   <section title="Versioning">
+					   <t>
+					   The version number describes the set of resources that can be accessed on a node that implements the recommendations in this RFC. The version number consists of an ascii formatted string consiting of major version number and minor version number separated by a period (e.g. 'major'.'minor'). The major and minor version numbers run from 1 through 255 (both inclusive). 
+			   </t>
+			   <t> Each revision of this RFC will define a version number which will uniquely identify the set of resources defined in that particular revision of the RFC. Note that version number may or may not change between revisions of this RFC. A change indicates that the resources or their message format have changed.
+			   </t>
+				 <t>
+						 The 6TiSCH resource version information is available through two sources. The first is by executing a GET method on the resource '/6t/ve' of a 6top node. This method, however, causes a significant increase in control traffic due to unicast nature of the request. The second method, is by accessing the 6top IE's. <xref target="I-D.ietf-6tisch-6top-interface"/> describes the YANG model for the version number. A 6top node MUST respond with the same version number irrespective of the method used.
+				 </t>
+			   </section>
             <section title="Management Resources">
                <t>
                   All the attributes in the management resources have the Read/Write accessibility. The following table lists the 6top management resources and the related URI paths.
@@ -233,6 +246,8 @@
 | Name        | Accessibility   |    URI path           |
 |             | 6top Commands   |                       |
 +-------------+-----------------+-----------------------+
+| Version 	  | READ  			| 6t/ve 				|
++-------------+-----------------+-----------------------+
 | Queue       | READ/CONFIGURE  | 6t/qu 				|
 +-------------+-----------------+-----------------------+
 | Monitoring  | READ/CONFIGURE  | 6t/ms 				|
@@ -243,6 +258,16 @@
 +-------------+-----------------+-----------------------+
 ]]></artwork>
                </figure>
+			   <section title="Version">
+								 <t>
+					   The version resource is a read-only resource that provides information on the methods, resources, message formats that is supported by the node.
+					   The version resource does not directly map to a 6top resource defined in <xref target="I-D.ietf-6tisch-6top-interface"/>.
+					   Upon executing a GET on the '/6t/ve' resource, the node responds with a version number that is described by a major and minor number expressed as an ascii string in the following format - 'major.minor'. The major and minor versions are numbers running from 1 through 255 (both inclusive).
+						 </t>
+						 <t>
+ A 6top node implmenting the recommendations in this RFC will respond with a version number of '1.0' (major version = 1, minor version = 0). 
+ 					</t>
+			   </section>
             </section>
             <section title="Message Formats">
                <t>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Nov 2014 15:31:08 -0500

Raghuram Sudhaakar (rsudhaak) <[email-masked]> wrote:
    > The third and most important discussion was - 3. How do nodes exchange
    > the version data (with PCE and other nodes) of nodes so a network of
    > heterogenous nodes (w.r.t version) can interoperate.  1. Proposal - use
    > the joining flows defined in draft-richardson-6tisch--security-6top-03

    > Comments and suggestions on this proposal are requested.

I don't understand why you talk about "version data"?
How are the nodes heterogenous?  I suspect that I might be suffering from
unshared terminology here.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Tue, 11 Nov 2014 21:03:23 +0000

Michael
I believe ³version data² may be a misleading word I used in the previous
email. What I meant is the version number.

The version number uniquely identifies the set of 6top resources that can
be accessed on a node. Version number is bumped up when a resource is
added, renamed or deleted.

Heterogenity may arise when new nodes (running an updated implementation
which may have added a new resources) are added to existing deployments.
Heterogenity is entirely w.r.t the version number (and consequently the
set of 6top resources that can be accessed on the nodes).

This is important for both the PCE as well as peer nodes to identify what
information they access on a 6top node.

-raghuram

On 11/11/14, 12:31 PM, "Michael Richardson" <[email-masked]> wrote:

>    > the joining flows defined in
>draft-richardson-6tisch--security-6top-03
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 11 Nov 2014 11:14:26 -1000

Version numbers often don’t work very well.
They may look like cheap insurance, but in the end they don’t buy much.
E.g. simply incrementing them suddenly makes you incommunicado with older devices.

Not having looked at the details, I cannot recommend something specific, but maybe e.g. look at the capability indication in draft-ietf-6lo-ghc as a very soft alternative to version numbers.

Grüße, Carsten

> On 11 Nov 2014, at 11:03, Raghuram Sudhaakar (rsudhaak) <[email-masked]> wrote:
> 
> Michael
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Nov 2014 16:20:21 -0500

Raghuram Sudhaakar (rsudhaak) <[email-masked]> wrote:
    > Michael I believe ³version data² may be a misleading word I used in the
    > previous email. What I meant is the version number.

    > The version number uniquely identifies the set of 6top resources that
    > can be accessed on a node. Version number is bumped up when a resource
    > is added, renamed or deleted.

okay, you mean the version of the 6top API; versions are created by standards
action...

    > Heterogenity may arise when new nodes (running an updated
    > implementation which may have added a new resources) are added to
    > existing deployments.  Heterogenity is entirely w.r.t the version
    > number (and consequently the set of 6top resources that can be accessed
    > on the nodes).

Yes, I agree this is an interesting issue.
The problem is what do you do when a v2 node tries to talk to a v1 node... we
need to think about this now, I agree.  I think this is most acute in the
minimal case, as otherwise the PCE can have a notion about what the range of
versions available are, and can cope...  The PCE can speak all versions, so
this means that the nodes do not have to support more than one version.
But, in the minimal case, they have to talk to each other, so there has to be
a discovery process and some adaptation.

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 11 Nov 2014 14:22:48 -1000

Michael,

Your description captures what I had in mind. In the centralized case, as
part of the joining process (e.g. defined
in draft-richardson-6tisch--security-6top-03), the PCE GETs the CoAP API
version implemented by the newly joining node. The PCE speaks all versions,
and chooses the commands it sends to the node depending on the set of
commands the node understands. Similarly, in a purely distributed cases, a
node GETs the version of the CoAP interface of its neighbor.

In my mind, the version is just a mechanism the CoAP interface offers, and
is generally a "healthy" feature to have, especially if the version of the
interface can change. The initial idea for this discussion is also to be
able to possibly switch to a more generic solution (COMAN? COMI?).

Another versioning option would be to:
- associate a version number to the YANG data model
- have all associated CoAP URIs be prefixed with that version, e.g. /6t/1,
/6t/2, etc.

This is the approach used by Google (
https://developers.google.com/gmail/api/v1/reference/) and Xively (
https://xively.com/dev/docs/api/data/read/single_feed/). It allows for
multiple a node to implement multiple versions, at the cost of an extra
Uri-Path.

Thoughts?

Thomas

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 12 Nov 2014 07:55:36 +0000

> need to think about this now, I agree.  I think this is most acute in the minimal
> case, as otherwise the PCE can have a notion about what the range of versions
> available are, and can cope...  The PCE can speak all versions, so this means that
> the nodes do not have to support more than one version.
> But, in the minimal case, they have to talk to each other, so there has to be a
> discovery process and some adaptation.
> 
[PT] 
Exactly

[PT] Pascal

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Nov 2014 14:42:29 -0500

These are the things that we need to have for the 6top interface for joining.
While some craters have shown up in the architecture, some of the details are
still very solid. I am interested in making the terminology clearer and I
imagine that we have to have some IANA Considerations.
I hope to learn to write these things down in YANG.

joining node interface:
1) an enum (registry) saying what kind of network security is to be used.
   a) NO_SECURITY = 0 
   b) network-wide MIC/key, to be used directly.
   c) a network-wide "PSK", to be used with 802.15.9 mode DTLS (DHE_PSK),
      unclear to me how broadcast/multicasts are keyed,I hope to read
      the 15.9 documents.
   d) a network-wide "PSK", to be used with 802.15.9 mode IKEv2
       (Shared key message integrity code. ditto about broadcast)
   f) a PK method: to be used with 802.15.9 mode DTLS (ECDSA),
   g) a PK method: to be used with 802.15.9 mode IKEv2 (ECDSA)
      I thought that 7296 would have rolled in the signature-auth work.
      I want to specify the ECDSA authentication methods.
   h) ditto above, s/IKEv2/HIP/
   i) perhaps a code for using draft-piro-6tisch-security-issues-02 
   -- I'm unclear how MLE works at this point.

2) a space for an ECDSA PKIX certificate.  from 6top's point of view, this is
   around 300 opaque bytes.  We should be transfering DER, not base64 encoded
   certificates!
3) a way to indicate if (2) replaces the devices' IDevID, or if it is in fact
   the LDevID.   From a RESTful point of view, it would be best if a POST
   to (2) returned the URI of the new certificate. It could be a FIFO
   (so the oldest certificate gets silently dropped), or it could be an error
   if the device is full.
   That same RESTful view would then want to get a list of certificates, 
   with the IDevID one being listed, and one could delete it explicitely.

4) for the PSK methods, a place to put the PSK. An opaque space of around 
   128 ytes. Again, we should return a URI, and be able to list them.
   we might not want to support GET on this resource.

5) the PANID of the production network
6) "GO" flag.
   A way to tell the device that provisioning is over, and it should 
   probably restart and join the real network with the real credentials.
   
======= Join Assistant

7) a toggle which enables a node to become a join assistant.
   This might return an error if the node is incapable or unwilling to do
   that.

8) a ULA to use to announce in the RA for joining nodes.  So
   128bits+prefixlen.  A device with multiple interfaces should configure
   different 64-bit prefixes.  

9) some details about the enhanced beacon the join ssistant should transmit, 
   which I am not qualified to specify.
10) the well-known beacon key to use for the join network. (Defaulting to
   "6TISCHJOIN") 
11) the address of the JCE, for the ACL about who can contact joining nodes.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 18 Nov 2014 05:42:52 +0100

Hi Michael,

I think part of these should go to the 6top interface expressed in YANG
model. Here some comments inline.

thanks!
X

joining node interface:

That's easy, a placeholder for that option can be added to the YANG model.
Is this an option that can be set and read right?

2) a space for an ECDSA PKIX certificate.  from 6top's point of view, this
is
   around 300 opaque bytes.  We should be transfering DER, not base64
encoded
   certificates!

Is this read only or read/write, write-once? .. Should be exposed so it is
queried/modified or is something static that will never change (except for
the first time)?

3) a way to indicate if (2) replaces the devices' IDevID, or if it is in
fact
   the LDevID.   From a RESTful point of view, it would be best if a POST
   to (2) returned the URI of the new certificate. It could be a FIFO
   (so the oldest certificate gets silently dropped), or it could be an
error
   if the device is full.
   That same RESTful view would then want to get a list of certificates,
   with the IDevID one being listed, and one could delete it explicitely.

ok this can be done too.

idem as before. in YANG we define the placeholder and the access method.

the PANID is part of the 15.4 PIB. It should be exposed by 6top.

6) "GO" flag.

This is the joining/security state. We may think on a state machine (only
Go and Configuring options?)

======= Join Assistant

Ok, this seems a capability indicator. Could this be a bitmap so we can
flag multiple capabilites?

How this ULA is build? could it be build/defined using 6top information? or
it is a completely new element?

Ok this requires space in the yang model to store the well-known key.

Ok this is a L3 "important" address dictionary that a node should keep. Is
this the only address we need to know? PCE? other services in the network?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Nov 2014 03:00:24 -0500

> model. Here some comments inline.

Yes, that was my intention.

  mcr> joining node interface:
  mcr> 1) an enum (registry) saying what kind of network security is to be used.
  mcr> a) NO_SECURITY = 0
  mcr> b) network-wide MIC/key, to be used directly.
  mcr> c) a network-wide "PSK", to be used with 802.15.9 mode DTLS (DHE_PSK),
  mcr> unclear to me how broadcast/multicasts are keyed,I hope to read
  mcr> the 15.9 documents.
  mcr> d) a network-wide "PSK", to be used with 802.15.9 mode IKEv2
  mcr> (Shared key message integrity code. ditto about broadcast)
  mcr> f) a PK method: to be used with 802.15.9 mode DTLS (ECDSA),
  mcr> g) a PK method: to be used with 802.15.9 mode IKEv2 (ECDSA)
  mcr> I thought that 7296 would have rolled in the signature-auth work.
  mcr> I want to specify the ECDSA authentication methods.
  mcr> h) ditto above, s/IKEv2/HIP/
  mcr> i) perhaps a code for using draft-piro-6tisch-security-issues-02
  mcr> -- I'm unclear how MLE works at this point.

    > Is this an option that can be set and read right?

Yes, R/W.

  mcr> 2) a space for an ECDSA PKIX certificate.  from 6top's point of view, this
  mcr> is
  mcr> around 300 opaque bytes.  We should be transfering DER, not base64
  mcr> encoded
  mcr> certificates!

    > queried/modified or is something static that will never change (except for

It could be read for diagnostics and management, but it's mostly write.  

  mcr> 3) a way to indicate if (2) replaces the devices' IDevID, or if it is in
  mcr> fact
  mcr> the LDevID.   From a RESTful point of view, it would be best if a POST
  mcr> to (2) returned the URI of the new certificate. It could be a FIFO
  mcr> (so the oldest certificate gets silently dropped), or it could be an
  mcr> error
  mcr> if the device is full.
  mcr> That same RESTful view would then want to get a list of certificates,
  mcr> with the IDevID one being listed, and one could delete it explicitely.

    > ok this can be done too.

Good.

  mcr> 4) for the PSK methods, a place to put the PSK. An opaque space of around
  mcr> 128 ytes. Again, we should return a URI, and be able to list them.
  mcr> we might not want to support GET on this resource.

    > idem as before. in YANG we define the placeholder and the access

  mcr> 5) the PANID of the production network

    > the PANID is part of the 15.4 PIB. It should be exposed by 6top.

Good, no need to duplicate.

  mcr> 6) "GO" flag.
  mcr> A way to tell the device that provisioning is over, and it should
  mcr> probably restart and join the real network with the real credentials.

    > Go and Configuring options?)

Yes, we likely need to define a state machine; I'm suggesting that this is
just an input to that.

  mcr> ======= Join Assistant

  mcr> 7) a toggle which enables a node to become a join assistant.
  mcr> This might return an error if the node is incapable or unwilling to do
  mcr> that.

    > flag multiple capabilites?

Are you suggesting that the ability to be a Join Assistant is in a separate
capabilities resource?

  mcr> 8) a ULA to use to announce in the RA for joining nodes.  So
  mcr> 128bits+prefixlen.  A device with multiple interfaces should configure
  mcr> different 64-bit prefixes.

    > it is a completely new element?

I think that the JCE determines it.  Pascal has the notion that it needs to
be unique per Join Assistant, I'm not yet convinced one way or another, but I
suggest that the JCE assign it.

  mcr> 9) some details about the enhanced beacon the join ssistant should transmit,
  mcr> which I am not qualified to specify.
  mcr> 10) the well-known beacon key to use for the join network. (Defaulting to
  mcr> "6TISCHJOIN")

    > Ok this requires space in the yang model to store the well-known key.

Yes.

  mcr> 11) the address of the JCE, for the ACL about who can contact joining nodes.

    > this the only address we need to know? PCE? other services in the network?

It's all that is necessary as part of becoming a Join Assistant.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 24 Nov 2014 15:25:01 +0200

>    b) network-wide MIC/key, to be used directly.

As the key is AES-CCM key that means that every single device needs to
store their frame counters to stable storage. This sets quite high
requirements for the devices. In theory they should also store the
frame counters for all the peers they are talking to, but I don't know
if any device does that. Usually they only store their own frame
counter to flash every now and then, and then on the restart they load
it from the flash, and add big enough counter to it to make sure that
it is unique. 

>       unclear to me how broadcast/multicasts are keyed,I hope to read

There is no TLS/DTLS key management defined in the 15.9. Nobody has
bothered to invest time or energy to add that, so thats why it is not
there.

>        (Shared key message integrity code. ditto about broadcast)

How the broadcast/multicast keys are keyed is not really defined in
the 15.9, but it is left for the upper layer. I.e. 15.4 the keys are
identified with the two attributes, Key Source and Key Index. The
format of the Key Source depends on the Key Identifier Mode value.
There are 4 different values for the Key Identifier Mode:

0x00	Key is determined implictly from the originator and
	recipient(s) of the frame. I.e there is no  Key Source or Key
	Index, and pairwise keys between peers are used. Note, that
	there is no Key Index, thus there is only one such key at
	given time. 

0x01	Key is determined from the Key Index field in conjuction with
	macDefaultKeySource. I.e. each device can have one default
	sender, which allows compression of the security header, as
	this default key source can be left out from the header. I
	would expect that this macDefaultKeySource would be the PAN
	coordinator or similar. As the macDefaultKeySource needs to be
	global to the PAN, there can really be only one owner for the
	key. 

0x02	Key is determined explictly from the 4-octet Key Source field,
	and the Key Index field. The 4-octet Key Source consists of
	PAN Id and the short address. I.e there can be 255 keys from
	the same sender. 

0x03	Key is determined explictly from the 8-octet key source field,
	and the key index field. I.e. this gives the extended address
	of the sender and identifies which of the 255 keys from that
	sender is used.

The 15.9 allows creating those keys KMP-CREATE.request is given the
NewKeyIdMode, NewKeySource and NewKeyIndex which key management then
negotiates.

If the NewKeyIdMode is 0x00, then pairwise keys are negotiated, and
there can only be one key between the peers, so the Key Source and Key
Index are ignored.

The key identifier mode 0x01 can be used for the broadcast key for the
traffic originating from the pan coordinator. I.e. instead of storing
the pan coordinator address in the header, it can be left out, but as
one common frame counter is used for all traffic, only the pan
coordinator (or actually the macDefaultKeySource, i.e. the owner of
the key) can send data out using this key.

The key identifier modes 0x02 and 0x03 can be used for the broadcast
or multicast traffic from any peer to any peer. Each originator has
its own frame counters and each recipient stores last frame counter
seen from the other enad compares that there is no replay.

All of those keys can be negotiated by the upper layer, by calling the
KMP-CREATE.request with suitable paramaters. How the actual key
management protocol then maps those calls to actual operations on the
key management is left outside the 15.9. I.e. we most likely need IETF
draft explaining how to map the KeyIdMode, KeySource and KeyIndex to
actual IKEv2/HIP etc payloads.

For pairwise keys this is usually quite easy, i.e. we just derive
those keys from the KEYMAT. This is actually defined in the 15.9. For
the broadcast / multicast key destribition it says that such features
needs to be added to the IKEv2, i.e. sending key material over IKEv2
channel using Notify payloads inside INFORMATIONAL exchanges.

I.e. we need to write draft saying that 15.9 broadcast/multicast key
distribution is done by sending Notify Payload with notify message
status type of xxx, and having content of:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |KIM|  RESERVED |            Key Source (0/4/8 octets)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               | Key Index     | Key Material (16 octets)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where the KIM is the Key Id Mode, and the Key Source is either 0, 4,
or 8 octects depeding on the KIM value (0x01 = 0, 0x02 = 4, 0x03 = 8
octets). The Key Index is always 1 octet. This is never used if the
Key Id Mode is 0, as then pairwise keys are used. The Key material
used for the key is the last 16 octets of the notify payload. 

This specification is not yet written.

Or instead of that we can use the GDOI IKEv2 specification to
distribute the keying material. 

>    f) a PK method: to be used with 802.15.9 mode DTLS (ECDSA),

As I said no DTLS/TLS key management method in 15.9. If that is
needed, then someone needs to start working on it, i.e. write the
appendix for it.

>       I want to specify the ECDSA authentication methods.

The 7296 didn't include signature auth method draft, as there was not
yet proven interoperability with it. There are not even
implementations out there using it yet, so to make that full internet
standard in the first step would have been bit premature. It should
come out as RFC soon. 

>    around 300 opaque bytes.  We should be transfering DER, not base64 encoded

802.15.9 allows transmitting 9 kB payloads inside the 15.4, so 300
bytes should not be problem. Also 15.9 defines multipurpose layer,
which can be used by others than KMP, i.e. 6tisch can use it do its
own protocols if needed. 

> 10) the well-known beacon key to use for the join network. (Defaulting to

Why is this? What key Source it would use? What Key Id Mode? In 15.9
we specify that the key management packets are sent with security
level of 0, and I did hear someone complaining that you cannot mix
security level 0 and other security level frames in the 15.4, but that
is wrong. The 15.4 do allow receiving packets with any security level,
and upper layer is told about the security level of the received frame
in the DATA.indication call.

Using well-known keys makes it bit harder for the upper layer to know
whether the frame actually has some protection or not. I.e. instead of
checking whether the security level is 0, it needs to check the
KeyIdMode, KeySource and KeyIndex to know if this key was one of the
well know keys, which would indicate there is no protection for the
frames.

If there is no protection for the frames, it is better to indicate it
using security level 0, and not hide that fact to some well know key.
Also if you define such key you also need to defined the KeyIdMode,
KeyIndex and KeySource for it. 
-- 
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 24 Nov 2014 16:43:28 +0000

Hello Tero,

> Why is this? What key Source it would use? What Key Id Mode? In 15.9 we
> specify that the key management packets are sent with security level of 0, and I
> did hear someone complaining that you cannot mix security level 0 and other
> security level frames in the 15.4, but that is wrong. The 15.4 do allow receiving
> packets with any security level, and upper layer is told about the security level of
> the received frame in the DATA.indication call.
> 
> Using well-known keys makes it bit harder for the upper layer to know whether
> the frame actually has some protection or not. I.e. instead of checking whether
> the security level is 0, it needs to check the KeyIdMode, KeySource and KeyIndex
> to know if this key was one of the well know keys, which would indicate there is
> no protection for the frames.
> 
> If there is no protection for the frames, it is better to indicate it using security
> level 0, and not hide that fact to some well know key.
> Also if you define such key you also need to defined the KeyIdMode, KeyIndex
> and KeySource for it.

[PT] The use of a well-known beacon key (Defaulting to"6TISCHJOIN") has been debated for a while. The lack of an ethertype has already lead in the field to frame from protocol A being understood -wrong- by protocol B.
Even if that looks anecdotic, we are now facing the need to reuse some messaging footprint in 6LoWPAN, and if that happens, we need to make sure that the overlapping protocol elements never mix in a same network.
So, agreeably, the beacon key does not provide protection against rogues, but it does provide protection against unexpected impact of coexisting but incompatible protocols.
IOW, the beacon key can be seen as an SSID that will isolate networks that are incompatible or should not be mixing for some policy reasons.

The KIM would probably be 0 (correct?) and some meta would indicate the bundle that is used to join (a bundle reserved for that purpose actually), and on that bundle, no actual security can be expected, so all sort of preventive actions, such as defense against DoS, will be activated.

Cheers,

Pascal

---

From: Rene Struik <[email-masked]>
Date: Mon, 24 Nov 2014 11:58:49 -0500

Hi Pascal:

Once again, the use of "well-known" keys is a bad idea, as a simple read 
of 802.15.4-2011 and 802.15.4e-2012 will confirm.

See also my message to the 6TiSCH list during the IETF-91 meeting below.

Best regards, Rene

[excerpt from my email of Wed November 12, 2014, 
http://www.ietf.org/mail-archive/web/6tisch/current/msg02694.html]

Correction: I don't think I ever suggested the use of well-known keys(as 
you seemed to suggest below): (ab)using crypto with a well-knownkeys is 
a way (promoted by some, not by me) to make the mechanics of aprotocol 
work (in terms of I/O parameters), but does not accomplish anyof the 
semantics (in terms of delivered security properties:confidentiality, 
authenticity, and so on). In fact, it may cause lots ofsecurity 
problems, e.g., in the context of 802.15.4e, since it wouldallow 
poisoning frame counters (the ASN entry in the MAC PIB table).

Rene

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 24 Nov 2014 17:09:46 +0000

Yes, you made it clear that you do not like it, René. 

And certainly this is a clear indication that we should not generalize the mechanism beyond the proposal for the join process.

But we need 1) a plan B since the problem below is real and 2) convincing arguments against the particular use in the join process design.

In this particular use, the key (and the time slots) would be reserved for join only. There is no confidentiality there, and  whatever security properties will have to come from upper layer between the JN and the JCE.

There may be added work at upper layer to figure that an exchange happened on a join bundle (literally a different link from ULP perspective) and is thus not trusted, but I fail to see an opening that messages fully in the clear do not have already.

Cheers,

Pascal

> -----Original Message-----
> From: Rene Struik [mailto:[email-masked]]
> Sent: lundi 24 novembre 2014 17:59
> To: Pascal Thubert (pthubert); Tero Kivinen; Michael Richardson
> Cc: Raghuram Sudhaakar (rsudhaak); [email-masked]; Robert Moskowitz
> Subject: on the fallacy of default keys (was: Re: [6tisch] 6tisch join requirements
> for 6top)
> 
> Hi Pascal:
> 
> Once again, the use of "well-known" keys is a bad idea, as a simple read of
> 802.15.4-2011 and 802.15.4e-2012 will confirm.
> 
> [excerpt from my email of Wed November 12, 2014, http://www.ietf.org/mail-
> archive/web/6tisch/current/msg02694.html]
> 
> Correction: I don't think I ever suggested the use of well-known keys(as you
> seemed to suggest below): (ab)using crypto with a well-knownkeys is a way
> (promoted by some, not by me) to make the mechanics of aprotocol work (in
> terms of I/O parameters), but does not accomplish anyof the semantics (in
> terms of delivered security properties:confidentiality, authenticity, and so on). In
> fact, it may cause lots ofsecurity problems, e.g., in the context of 802.15.4e,
> since it wouldallow poisoning frame counters (the ASN entry in the MAC PIB
> table).
> 
> Rene
> 
> >> security level 0 and other security level frames in the 15.4, but
> >> that is wrong. The 15.4 do allow receiving packets with any security
> >> level, and upper layer is told about the security level of the received frame in
> the DATA.indication call.
> >>
> >> whether the frame actually has some protection or not. I.e. instead
> >> of checking whether the security level is 0, it needs to check the
> >> well know keys, which would indicate there is no protection for the frames.
> >>
> > [PT] The use of a well-known beacon key (Defaulting to"6TISCHJOIN") has
> been debated for a while. The lack of an ethertype has already lead in the field
> to frame from protocol A being understood -wrong- by protocol B.
> > Even if that looks anecdotic, we are now facing the need to reuse some
> messaging footprint in 6LoWPAN, and if that happens, we need to make sure
> that the overlapping protocol elements never mix in a same network.
> > So, agreeably, the beacon key does not provide protection against rogues, but
> it does provide protection against unexpected impact of coexisting but
> incompatible protocols.
> > IOW, the beacon key can be seen as an SSID that will isolate networks that are
> incompatible or should not be mixing for some policy reasons.
> >
> > The KIM would probably be 0 (correct?) and some meta would indicate the
> bundle that is used to join (a bundle reserved for that purpose actually), and on
> that bundle, no actual security can be expected, so all sort of preventive actions,
> such as defense against DoS, will be activated.
> >
> >
> > Cheers,
> >
> > Pascal
> >

---

From: Rene Struik <[email-masked]>
Date: Mon, 24 Nov 2014 12:28:18 -0500

Hi Pascal:

I fail to see how this would work with the existing 802.15.4-2011 and 
802.15.4e-2012 specifications, but would be happy to be educated here.

Rene

---

From: Pat Kinney <[email-masked]>
Date: Mon, 24 Nov 2014 11:32:15 -0600

I find that I must disagree with Tero on his point 10 the well-known beacon key to use for the join network. (Defaulting to "6TISCHJOIN). This behavior is used in WirelessHART networks for a very practical reason.

Keys are not always used for security purposes, often they are used to prevent unintended occurrences, like using a lock and key to prevent a door from accidentally opening.  It is for this reasoning that WirelessHART used a "well-known" key (772E 6861 7274 636F 6D6D 2E6F 7267: ASCII value sequence of the 16 character string of the HART Foundation's web address: www.hartcomm.org) for nodes joining a network or broadcasting a network advertisement.  This mechanism allows for the 802.15.4 MAC to perform additional filtering on received packets.  It was noted in large conventions that using only the 2-octet FCS filter was not sufficient to prevent all undesired messages.  Using the well-known key allowed an additional filter of the 4-octet MIC.

In conclusion, I support the use of the well-known key and I further disagree with the comment that "Using well-known keys makes it bit harder for the upper layer to know whether the frame actually has some protection or not", if an upper layer finds this practice confusing then it shouldn't be an upper layer, perhaps it should try out as a PHY.

Pat

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email-masked]

On 24, Nov2014, at 7:25, Tero Kivinen <[email-masked]> wrote:

                       1                   2                   3

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 25 Nov 2014 13:17:26 +0200

Pascal Thubert (pthubert) writes:
> [PT] The use of a well-known beacon key (Defaulting to"6TISCHJOIN")
> has been debated for a while. The lack of an ethertype has already
> lead in the field to frame from protocol A being understood -wrong-
> by protocol B. 

So when someone is running the protocol A and B both over the same
default well-known key then you still have the problem...

You could add new header information element to the beacon specifying
the "service name" and then use that to separate the network where you
want to join. That would be clearer, and better way of doing that. 

> Even if that looks anecdotic, we are now facing the need to reuse
> some messaging footprint in 6LoWPAN, and if that happens, we need to
> make sure that the overlapping protocol elements never mix in a same
> network. 

Didn't 6LoWPAN add some multiplexer in the beginning of data, or do I
remember wrong? 

> So, agreeably, the beacon key does not provide protection against
> rogues, but it does provide protection against unexpected impact of
> coexisting but incompatible protocols. 

Only if they are not using the same well known keys. I.e. if you
cannot coordinate protocol A and B running on the same are not to mess
up each other, there is nothing saying you cannot have same mixup
happening over the same well-known keys.

Anyways even if the device gets garbage in, that should not cause
any catastrophic problems, it might just cause some upper layer
processes to start up and see garbage and then throw things out. The
system should be robust against such attacks, regardless whether they
are from the real attackers or from someone just happening to using
same band for some other traffic. 

> IOW, the beacon key can be seen as an SSID that will isolate
> networks that are incompatible or should not be mixing for some
> policy reasons. 

Adding SSID Header IE would most likely be better solution. 

> The KIM would probably be 0 (correct?) and some meta would indicate
> the bundle that is used to join (a bundle reserved for that purpose
> actually), and on that bundle, no actual security can be expected,
> so all sort of preventive actions, such as defense against DoS, will
> be activated. 

Key Identifier Mode 0, cannot be used, as it is peer to peer keys, and
there is only one of those keys between the peers, i.e. if you use Key
Identifier Mode 0, then this is the ONLY key that can be used between
the coordinator and peer.

Also as the new device joining the network do not know who is going to
send beacons, it cannot create the KeyDescriptor entries for it, i.e.
all devices in the network needs to be configure with macPANId and
macCoordExtendedAddress, i.e the device needs to know the extended
address of the coordinator sending the beacon beforehand. This is bit
hard to set up...

For the same reason you cannot use Key Identifier Mode 1, as that
would require configuring the extended address of the coordinator in
the macDefaultKeySource PIB entry.

Hmmm..actually even Key Identifier Modes 2 or 3 cannot be used, as
they also require the MAC to fill the KeyDescriptor beforehand, and
there they will need to now the extended address of the coordinator.

Of course the 15.4 does not tell how the KeyDescritors are created, I
have always assumed that upper layer creates them when the inbound
security processing fails with UNAVAILABLE_KEY. I.e. this error would
somehow be passed to the upper layer along with the KeyIdMode,
KeySource, KeyIndex, device addressing mode, device PANID and device
address. The upper layer would then see if it can create KeyDescriptor
entry for the key and if so, it would do so and for the next packet
from the same peer the entry would be there. All of this is of course
NOT specified in the 15.4, so there is no way to say what
implementations do.

So if this kind of joining key for beacon is wanted, I think the best
way would be to use Key Identifier Mode 3, as then the beacon actually
has all the information needed to create the KeyDescriptor. This will
then mean that beacons will have 14 bytes of auxiliary security
header, and 4 to 16 bytes of MIC. Adding for example 10-byte SSID
Header IE would make packets smaller...

Note, that receiving peer needs to know the extended address of the
sender in the 15.4 to be able to decrypt the packet, as the nonce
generation depends on that. There is no way around that. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 25 Nov 2014 13:25:48 +0200

Pat Kinney writes:
> Keys are not always used for security purposes, often they are used
> to prevent unintended occurrences, like using a lock and key to
> prevent a door from accidentally opening.  It is for this reasoning
> that WirelessHART used a "well-known" key (772E 6861 7274 636F 6D6D
> 2E6F 7267: ASCII value sequence of the 16 character string of the
> HART Foundation's web address: www.hartcomm.org) for nodes joining a
> network or broadcasting a network advertisement.  This mechanism

Which Key Identifier Mode, Key Source and Key Index is used for that
key? How is the KeyDescriptor created for it?
-- 
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 25 Nov 2014 13:14:52 +0000

> > lead in the field to frame from protocol A being understood -wrong- by
> > protocol B.
> 
> So when someone is running the protocol A and B both over the same default
> well-known key then you still have the problem...
> 
> You could add new header information element to the beacon specifying the
> "service name" and then use that to separate the network where you want to
> join. That would be clearer, and better way of doing that.

[PT] Too late, not enough room. But yes, the discussion is either this or a key.

> > messaging footprint in 6LoWPAN, and if that happens, we need to make
> > sure that the overlapping protocol elements never mix in a same
> > network.
> 

[PT] Not all 802.15.4 obey 6LoWPAN's hopeful thinking. As it goes, even with 6LoWPAN horizon, there is a need to differentiate route-over from mesh under so as to reuse the 33% of the space that was engulfed by mesh-under. So we are discussing a plan B for sorting out network type A from network type B. And yes, we expect that whoever handles non-default keys is conscious enough not to use the WirelessHART key for a 6TiSCH network.

> Only if they are not using the same well known keys. I.e. if you cannot
> coordinate protocol A and B running on the same are not to mess up each other,
> there is nothing saying you cannot have same mixup happening over the same
> well-known keys.
> 
[PT] The default key is part of the standard. Any other key would be admin, and certainly there's the limit.
We can only hope that an admin who is capable of configuring a non-default key is capable enough to avoid configuring the same key for incompatible networks. Considering the range of 6TiSCH networks, I'd ignore the probability of having 2 different admins come up with the same key in the same area. 

> Anyways even if the device gets garbage in, that should not cause any
> catastrophic problems, it might just cause some upper layer processes to start
> up and see garbage and then throw things out. The system should be robust
> against such attacks, regardless whether they are from the real attackers or
> from someone just happening to using same band for some other traffic.
> 
[PT] We are compressing things to a point that nothing is garbage anymore. Agreeably devices may not go wrong, but is a command is interpreted as a reset, reset it will cause. In fact, there is more to an SSID than the MAC encoding. We need something to select a network, by name or type, in the first place.

> > IOW, the beacon key can be seen as an SSID that will isolate networks
> > that are incompatible or should not be mixing for some policy reasons.
> 

[PT] Maybe. The issue is still barring others.

> > actually), and on that bundle, no actual security can be expected, so
> > all sort of preventive actions, such as defense against DoS, will be
> > activated.
> 
> Key Identifier Mode 0, cannot be used, as it is peer to peer keys, and there is
> only one of those keys between the peers, i.e. if you use Key Identifier Mode 0,
> then this is the ONLY key that can be used between the coordinator and peer.
> 
> Also as the new device joining the network do not know who is going to send
> beacons, it cannot create the KeyDescriptor entries for it, i.e.
> macCoordExtendedAddress, i.e the device needs to know the extended address
> of the coordinator sending the beacon beforehand. This is bit hard to set up...
> 
> For the same reason you cannot use Key Identifier Mode 1, as that would
> require configuring the extended address of the coordinator in the
> macDefaultKeySource PIB entry.
> 
> Hmmm..actually even Key Identifier Modes 2 or 3 cannot be used, as they also
> require the MAC to fill the KeyDescriptor beforehand, and there they will need to
> now the extended address of the coordinator.
> 
> Of course the 15.4 does not tell how the KeyDescritors are created, I have
> always assumed that upper layer creates them when the inbound security
> processing fails with UNAVAILABLE_KEY. I.e. this error would somehow be
> passed to the upper layer along with the KeyIdMode, KeySource, KeyIndex,
> device addressing mode, device PANID and device address. The upper layer
> would then see if it can create KeyDescriptor entry for the key and if so, it would
> do so and for the next packet from the same peer the entry would be there. All
> of this is of course NOT specified in the 15.4, so there is no way to say what
> implementations do.
> 
> So if this kind of joining key for beacon is wanted, I think the best way would be
> to use Key Identifier Mode 3, as then the beacon actually has all the information
> needed to create the KeyDescriptor. This will then mean that beacons will have
> 14 bytes of auxiliary security header, and 4 to 16 bytes of MIC. Adding for
> example 10-byte SSID Header IE would make packets smaller...
> 
[PT] Thanks a bunch for the insight, Tero.

> Note, that receiving peer needs to know the extended address of the sender in
> the 15.4 to be able to decrypt the packet, as the nonce generation depends on
> that. There is no way around that.

[PT] Ack

Pascal

---

From: Kris Pister <[email-masked]>
Date: Tue, 25 Nov 2014 14:51:51 -0800

No, when someone defines protocol B that is not compatible with protocol 
A then
they will pick a different well-known key.  That is the whole idea.

ksjp

---

From: Thomas Watteyne <[email-masked]>
Date: Sat, 29 Nov 2014 08:20:06 -0800

Tero, all,

> it from the flash, and add big enough counter to it to make sure that

IEEE802.15.4e-2012 TSCH [1], the ASN is used as the Frame Counter for
security operations, so you don't have to store the frame counters to
stable storage, right?

Thomas

[1] http://standards.ieee.org/getieee802/download/802.15.4e-2012.pdf

On Tue, Nov 25, 2014 at 2:51 PM, Kris Pister <[email-masked]> wrote:

> No, when someone defines protocol B that is not compatible with protocol A
> then

---

From: Michael Richardson <[email-masked]>
Date: Sun, 30 Nov 2014 16:36:01 -0500

> default well-known key then you still have the problem...

The point is that protocol A says, "join key is FOO",
and protocol B says "join key is BAR".  They never conflict that way.

    > Didn't 6LoWPAN add some multiplexer in the beginning of data, or do I

Yes-ish, but it's only a few bits.

    > NOT specified in the 15.4, so there is no way to say what

I'm hoping that Jonathan and Chris will chime in here and explain how they
implemented the well known join key in WirelessHART.

    > generation depends on that. There is no way around that. 

When you say "extended address", do you mean 64-bit EUI?

---

From: Michael Richardson <[email-masked]>
Date: Sun, 30 Nov 2014 16:41:47 -0500

> There are 4 different values for the Key Identifier Mode:

So, it's not enough to say "use 15.9" for key derivation, having provided
locally significant certificates.  

We also need a way to define a key for multicast operations, and I don't see
a way to do this other than having the join process provision one.