Subject: [6tisch] comment on draft-ietf-6tisch-6top-interface-03

From: Rene Struik <[email-masked]>
Date: Thu, 26 Mar 2015 18:06:51 -0400

Dear colleagues:

I suggest the following changes to draft-ietf-6tisch-6top-interface-03:

1) Section 4.1:

typedef nodeaddresstype {
     type uint64;
     description "The type to store node address. It can be 64bits EUI 
address; or the short address defined by 6top, constrained by TSCH 
macNodeAddress size, 2-octets. If using TSCH as MAC, the
     higher 6-octets should be filled with 0, and lowest 2-octets is 
neighbor short address";
}

Question mark: To my knowledge, 802.15.4 has extended addresses (64-bit 
EUI), short addresses (16-bit), and PAN IDs (16-bit). Here, I would 
expect the short address to be conveyed as part of the configuration 
step of the join protocol (which is currently not fully specified yet). 
I do not understand the zero-appended version of 16-bit addresses 
alluded to in the description above. Please explain.

2)  Section 4.3:

Remove this entire section (stretching on pp. 32-34), except for the item

leaf PanID {
     type uint16;
     description "2 Bytes the network PANID";
}

(which seems to be misplaced).

Note: In Section 4.2, p. 28, l. 1-2, it is suggested that "TODO the 
security related attributes will be added after 6TiSCH WG has consensus 
on the security scheme of 6top". So, let us simply do this, instead of 
incorporating speculative items now.

3) Right now, draft-ietf-6tisch-minimal-06 suggests the use of the keys 
K1 and K2 (see Section 8), which could potentially be pre-configured. If 
so,
Here, I would expect the keying material to be either derived from a 
shared key determined at the authentication step of the join protocol 
(which is not fully specified yet) or conveyed as part of a key 
distribution scheme (which also is not fully specified yet).

Note: In one case -- pre-configuration via a physical (non-wireless) 
interface -- we might need an interface to set this keying material in 
the MAC PIB. This is currently not defined in the draft, but also has no 
interoperability aspects, since can be considered to occur via an out of 
scope mechanism.

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

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 27 Mar 2015 05:55:15 +0100

Dear Rene,

XV>thanks for your comments. See my answers inline.

Dear colleagues:

1) Section 4.1:

Question mark: To my knowledge, 802.15.4 has extended addresses (64-bit
EUI), short addresses (16-bit), and PAN IDs (16-bit). Here, I would expect
the short address to be conveyed as part of the configuration step of the
join protocol (which is currently not fully specified yet). I do not
understand the zero-appended version of 16-bit addresses alluded to in the
description above. Please explain.

XV> For us this is just a container and a data representation model that is
used by the 6top operation layer. It should be able to hold the address. If
someone needs 16bit only will only use that space from that container. The
Data model also supports YANG RPCs which define communication between
peers, the model is used to format the messages that are exchanged. In some
cases the nodes need only to exchange the short address and thus we want to
support that. However I agree with you that by configuration the 0-appended
address does not make sense. We will review that. thanks.

2)  Section 4.3:

leaf PanID {
    type uint16;

XV>Yes we move PanID to the correct section.

Note: In Section 4.2, p. 28, l. 1-2, it is suggested that "TODO the
security related attributes will be added after 6TiSCH WG has consensus on
the security scheme of 6top". So, let us simply do this, instead of
incorporating speculative items now.

XV>This 4.3 section is a result of what we discussed in a 6tisch WG meeting
by Nov 2014 and the subsequent discussion on the ML. We asked for
information to the security team about the security attributes that would
be required. We got this answer
http://www.ietf.org/mail-archive/web/6tisch/current/msg02734.html

XV>After some days it seemed that nobody had objection or commented on that
so in January-February we proceed to integrate that information into the
draft.
We can remove now but I would like to ask few things:
1) is there consensus on that? Are these fields covering (or partially
covering) what is required?
2) Would the security group advice us with the set of attributes that are
needed? Could the current fields be used as an starting point and we
modify/add/remove according to your advances in the security architecture
and requirements?

3) Right now, draft-ietf-6tisch-minimal-06 suggests the use of the keys K1
and K2 (see Section 8), which could potentially be pre-configured. If so,
Here, I would expect the keying material to be either derived from a shared
key determined at the authentication step of the join protocol (which is
not fully specified yet) or conveyed as part of a key distribution scheme
(which also is not fully specified yet).

XV>This is not specified yet. Note that 6top interface only defined the MIB
elements. If this 2 keys need to be represented by an MIB entry we will add
that. Again let's first consolidate the text in the minimal draft through
consensus.

Note: In one case -- pre-configuration via a physical (non-wireless)
interface -- we might need an interface to set this keying material in the
MAC PIB. This is currently not defined in the draft, but also has no
interoperability aspects, since can be considered to occur via an out of
scope mechanism

Thanks for your pro-activity, I appreciate that.

kind regards,
Xavi

2015-03-26 23:06 GMT+01:00 Rene Struik <[email-masked]>:

> EUI), short addresses (16-bit), and PAN IDs (16-bit). Here, I would expect
> the short address to be conveyed as part of the configuration step of the
> join protocol (which is currently not fully specified yet). I do not
> understand the zero-appended version of 16-bit addresses alluded to in the
> description above. Please explain.
>
> 2)  Section 4.3:
>
> security related attributes will be added after 6TiSCH WG has consensus on
> the security scheme of 6top". So, let us simply do this, instead of
> 3) Right now, draft-ietf-6tisch-minimal-06 suggests the use of the keys K1
> and K2 (see Section 8), which could potentially be pre-configured. If so,
> interface -- we might need an interface to set this keying material in the
> MAC PIB. This is currently not defined in the draft, but also has no
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

---

From: Rene Struik <[email-masked]>
Date: Fri, 27 Mar 2015 11:35:35 -0400

On 3/27/2015 12:55 AM, Xavier Vilajosana wrote:
> Question mark: To my knowledge, 802.15.4 has extended addresses 
> (64-bit EUI), short addresses (16-bit), and PAN IDs (16-bit). Here, I 
> would expect the short address to be conveyed as part of the 
> configuration step of the join protocol (which is currently not fully 
> specified yet). I do not understand the zero-appended version of 
> 16-bit addresses alluded to in the description above. Please explain.
>
> XV> For us this is just a container and a data representation model 
> that is used by the 6top operation layer. It should be able to hold 
> the address. If someone needs 16bit only will only use that space from 
> that container. The Data model also supports YANG RPCs which define 
> communication between peers, the model is used to format the messages 
> that are exchanged. In some cases the nodes need only to exchange the 
> short address and thus we want to support that. However I agree with 
> you that by configuration the 0-appended address does not make sense. 
> We will review that. thanks.
RS>> great. So, let us table that one for now.
<<RS
> security related attributes will be added after 6TiSCH WG has 
> consensus on the security scheme of 6top". So, let us simply do this, 
> instead of incorporating speculative items now.
>
> XV>This 4.3 section is a result of what we discussed in a 6tisch WG 
> meeting by Nov 2014 and the subsequent discussion on the ML. We asked 
> for information to the security team about the security attributes 
> that would be required. We got this answer
> XV>After some days it seemed that nobody had objection or commented on 
> that so in January-February we proceed to integrate that information 
> into the draft.
RS>>
I don't think any of this was discussed in the 6tisch security group. 
More importantly, though, the material raises quite a few questions (see 
below, where I expand on this), so at this point is best removed (as I 
believe intention is that the interface draft is more or less stable at 
this point in time).
<<RS
> 2) Would the security group advice us with the set of attributes that 
> are needed? Could the current fields be used as an starting point and 
> we modify/add/remove according to your advances in the security 
> architecture and requirements?
>
RS>>
[personal suggestion - I cannot speak for 6TiSCH security group at this 
point in time]
I had a close look at what could easily stay, but it seems best to 
simple scrap all (except moving the PANID). For a detailed assessment, 
see below.

a) leaf SecurityMode:
not sure whether this is a switch and, if so, whether it only can be set 
to support one of the options specified. Right now, it is also unclear 
what triggered this enumeration.
b) leaf-list Certificate:
the specific details of certificates and particular format picks that 
have not been analyzed on merit and decided yet. Moreover, it is not 
clear how PSK ended up here.
c) leaf DevID:
this seems to relate to notions floating around in some Anima drafts. 
Right now, it is unclear whether this is all needed and, if so, in which 
form.
d) leaf-list PSK:
this seems to suggest a path to inject pre-shared keys (do we want this, 
or should this be a Write-only attribute?). This does not seem to impact 
interoperability.
e) leaf PanID:
as already said in my previous email, this seems to have been misplaced, 
since does not belong in security attribute section.
f) leaf JoinAssistant:
not sure why there should be an on/off switch for the JA role. This does 
not seem to impact interoperability. BTW - If there is a need to remote 
change roles, I would expect the corresponding state change to be 
triggered by receipt of a (perhaps, ACE?) command.
leaf-list ULA: this seems to relate to address of the joining node 
during join. Not sure why this is needed (see also 
draft-struik-6tisch-security-considerations-01, Secton 1.3.2, Step 10; 
Section 1.3.3, item #7-#10).
g) leaf BeaconWellKnownKey:
it is not clear why this attribute would be needed. Moreover, one can 
"inject" a key into the MAC PIB table via GET/SET commands, where the 
keying table contains cryptographic keys and related attributes, 
independent of differences in intended use. The 802.15.4 requirement is 
that these are write-only attributes (so as to enforce that key values 
never get exposed to the outside world).
h) leaf-list JCEAddress:
not sure on which "device" this gets implemented. It is hard to 
understand how a joining node would know which JCE to contact (after 
all, the JA may pick his favorite one -- see also 
draft-struik-6tisch-security-considerations-01, Section 1.3.3, item #10).

<<RS
> 3) Right now, draft-ietf-6tisch-minimal-06 suggests the use of the 
> keys K1 and K2 (see Section 8), which could potentially be 
> pre-configured. If so,
> XV>This is not specified yet. Note that 6top interface only defined 
> the MIB elements. If this 2 keys need to be represented by an MIB 
> entry we will add that. Again let's first consolidate the text in the 
> minimal draft through consensus.
RS>>
Great. From emails on the list, it seemed that the suggested "new" para 
is consensus or very close to this 
(http://www.ietf.org/mail-archive/web/6tisch/current/msg03100.html).
<<RS
> the MAC PIB. This is currently not defined in the draft, but also has 
> no interoperability aspects, since can be considered to occur via an 
> out of scope mechanism
>
> 2015-03-26 23:06 GMT+01:00 Rene Struik <[email-masked] 
> <mailto:[email-masked]>>:
>
>     Dear colleagues:
>
>         description "The type to store node address. It can be 64bits
>     EUI address; or the short address defined by 6top, constrained by
>     TSCH macNodeAddress size, 2-octets. If using TSCH as MAC, the
>         higher 6-octets should be filled with 0, and lowest 2-octets
>     is neighbor short address";
>     }
>
>     Question mark: To my knowledge, 802.15.4 has extended addresses
>     (64-bit EUI), short addresses (16-bit), and PAN IDs (16-bit).
>     Here, I would expect the short address to be conveyed as part of
>     the configuration step of the join protocol (which is currently
>     not fully specified yet). I do not understand the zero-appended
>     version of 16-bit addresses alluded to in the description above.
>     Please explain.
>
>     2)  Section 4.3:
>
>     Note: In Section 4.2, p. 28, l. 1-2, it is suggested that "TODO
>     the security related attributes will be added after 6TiSCH WG has
>     consensus on the security scheme of 6top". So, let us simply do
>     this, instead of incorporating speculative items now.
>
>     3) Right now, draft-ietf-6tisch-minimal-06 suggests the use of the
>     keys K1 and K2 (see Section 8), which could potentially be
>     pre-configured. If so,
>     Here, I would expect the keying material to be either derived from
>     a shared key determined at the authentication step of the join
>     protocol (which is not fully specified yet) or conveyed as part of
>     a key distribution scheme (which also is not fully specified yet).
>
>     Note: In one case -- pre-configuration via a physical
>     (non-wireless) interface -- we might need an interface to set this
>     keying material in the MAC PIB. This is currently not defined in
>     the draft, but also has no interoperability aspects, since can be
>     considered to occur via an out of scope mechanism.
>
>     -- 
>     email: [email-masked] <mailto:[email-masked]> |
>     Skype: rstruik
>     cell: +1 (647) 867-5658 <tel:%2B1%20%28647%29%20867-5658> | US: +1
>     (415) 690-7363 <tel:%2B1%20%28415%29%20690-7363>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Qin Wang <[email-masked]>
Date: Fri, 27 Mar 2015 16:03:50 +0000 (UTC)

Hi Rene,
Regarding to your point 1). I agree with Xavi. The description in nodeAddressType just tells how to store 16bits address in the 64bits space.
Regarding to your point 2). the TODO in section 4.2 refers to the security attributes defined in 15.4. The security attributes defined in 6top are in section 4.3. Everything in the 6top-interface draft needs to be discussed in the next step. Thus, I would like to keep the current structure of draft at this moment. What do you think?
ThanksQin

     On Friday, March 27, 2015 11:36 PM, Rene Struik <[email-masked]> wrote:

 Dear Rene, 

 1) Section 4.1:
 
 typedef nodeaddresstype {
     type uint64;
     description "The type to store node address. It can be 64bits EUI address; or the short address defined by 6top, constrained by TSCH macNodeAddress size, 2-octets. If using TSCH as MAC, the
     higher 6-octets should be filled with 0, and lowest 2-octets is neighbor short address";
 }
 
 Question mark: To my knowledge, 802.15.4 has extended addresses (64-bit EUI), short addresses (16-bit), and PAN IDs (16-bit). Here, I would expect the short address to be conveyed as part of the configuration step of the join protocol (which is currently not fully specified yet). I do not understand the zero-appended version of 16-bit addresses alluded to in the description above. Please explain.
 
 XV> For us this is just a container and a data representation model that is used by the 6top operation layer. It should be able to hold the address. If someone needs 16bit only will only use that space from that container. The Data model also supports YANG RPCs which define communication between peers, the model is used to format the messages that are exchanged. In some cases the nodes need only to exchange the short address and thus we want to support that. However I agree with you that by configuration the 0-appended address does not make sense. We will review that. thanks.  
 RS>> great. So, let us table that one for now.
 <<RS

 2)  Section 4.3:

 leaf PanID {
     type uint16;

 Note: In Section 4.2, p. 28, l. 1-2, it is suggested that "TODO the security related attributes will be added after 6TiSCH WG has consensus on the security scheme of 6top". So, let us simply do this, instead of incorporating speculative items now.
 
 XV>This 4.3 section is a result of what we discussed in a 6tisch WG meeting by Nov 2014 and the subsequent discussion on the ML. We asked for information to the security team about the security attributes that would be required. We got this answer http://www.ietf.org/mail-archive/web/6tisch/current/msg02734.html 
  XV>After some days it seemed that nobody had objection or commented on that so in January-February we proceed to integrate that information into the draft.  
  We can remove now but I would like to ask few things: 1) is there consensus on that? Are these fields covering (or partially covering) what is required?  
 RS>>
 I don't think any of this was discussed in the 6tisch security group. More importantly, though, the material raises quite a few questions (see below, where I expand on this), so at this point is best removed (as I believe intention is that the interface draft is more or less stable at this point in time).
 <<RS
 
  2) Would the security group advice us with the set of attributes that are needed? Could the current fields be used as an starting point and we modify/add/remove according to your advances in the security architecture and requirements? 
   
 RS>>
 [personal suggestion - I cannot speak for 6TiSCH security group at this point in time]
 I had a close look at what could easily stay, but it seems best to simple scrap all (except moving the PANID). For a detailed assessment, see below.
  
 a) leaf SecurityMode:
 not sure whether this is a switch and, if so, whether it only can be set to support one of the options specified. Right now, it is also unclear what triggered this enumeration.
 b) leaf-list Certificate: 
 the specific details of certificates and particular format picks that have not been analyzed on merit and decided yet. Moreover, it is not clear how PSK ended up here.
 c) leaf DevID: 
 this seems to relate to notions floating around in some Anima drafts. Right now, it is unclear whether this is all needed and, if so, in which form.
 d) leaf-list PSK: 
 this seems to suggest a path to inject pre-shared keys (do we want this, or should this be a Write-only attribute?). This does not seem to impact interoperability.
 e) leaf PanID: 
 as already said in my previous email, this seems to have been misplaced, since does not belong in security attribute section.
 f) leaf JoinAssistant: 
 not sure why there should be an on/off switch for the JA role. This does not seem to impact interoperability. BTW - If there is a need to remote change roles, I would expect the corresponding state change to be triggered by receipt of a (perhaps, ACE?) command.
 leaf-list ULA: this seems to relate to address of the joining node during join. Not sure why this is needed (see also draft-struik-6tisch-security-considerations-01, Secton 1.3.2, Step 10; Section 1.3.3, item #7-#10).
 g) leaf BeaconWellKnownKey: 
 it is not clear why this attribute would be needed. Moreover, one can "inject" a key into the MAC PIB table via GET/SET commands, where the keying table contains cryptographic keys and related attributes, independent of differences in intended use. The 802.15.4 requirement is that these are write-only attributes (so as to enforce that key values never get exposed to the outside world).
 h) leaf-list JCEAddress: 
 not sure on which "device" this gets implemented. It is hard to understand how a joining node would know which JCE to contact (after all, the JA may pick his favorite one -- see also draft-struik-6tisch-security-considerations-01, Section 1.3.3, item #10).
 
 <<RS
 
    3) Right now, draft-ietf-6tisch-minimal-06 suggests the use of the keys K1 and K2 (see Section 8), which could potentially be pre-configured. If so,
 Here, I would expect the keying material to be either derived from a shared key determined at the authentication step of the join protocol (which is not fully specified yet) or conveyed as part of a key distribution scheme (which also is not fully specified yet).

 XV>This is not specified yet. Note that 6top interface only defined the MIB elements. If this 2 keys need to be represented by an MIB entry we will add that. Again let's first consolidate the text in the minimal draft through consensus. 
   
 RS>>
 Great. From emails on the list, it seemed that the suggested "new" para is consensus or very close to this (http://www.ietf.org/mail-archive/web/6tisch/current/msg03100.html).
 <<RS

 Note: In one case -- pre-configuration via a physical (non-wireless) interface -- we might need an interface to set this keying material in the MAC PIB. This is currently not defined in the draft, but also has no interoperability aspects, since can be considered to occur via an out of scope mechanism
  
  kind regards, Xavi  
 
Dear colleagues:

 1) Section 4.1:
 
 typedef nodeaddresstype {
     type uint64;
     description "The type to store node address. It can be 64bits EUI address; or the short address defined by 6top, constrained by TSCH macNodeAddress size, 2-octets. If using TSCH as MAC, the
     higher 6-octets should be filled with 0, and lowest 2-octets is neighbor short address";
 }
 
 Question mark: To my knowledge, 802.15.4 has extended addresses (64-bit EUI), short addresses (16-bit), and PAN IDs (16-bit). Here, I would expect the short address to be conveyed as part of the configuration step of the join protocol (which is currently not fully specified yet). I do not understand the zero-appended version of 16-bit addresses alluded to in the description above. Please explain.
 
 2)  Section 4.3:

 leaf PanID {
     type uint16;

 Note: In Section 4.2, p. 28, l. 1-2, it is suggested that "TODO the security related attributes will be added after 6TiSCH WG has consensus on the security scheme of 6top". So, let us simply do this, instead of incorporating speculative items now.
 
 3) Right now, draft-ietf-6tisch-minimal-06 suggests the use of the keys K1 and K2 (see Section 8), which could potentially be pre-configured. If so,
 Here, I would expect the keying material to be either derived from a shared key determined at the authentication step of the join protocol (which is not fully specified yet) or conveyed as part of a key distribution scheme (which also is not fully specified yet).
 
 Note: In one case -- pre-configuration via a physical (non-wireless) interface -- we might need an interface to set this keying material in the MAC PIB. This is currently not defined in the draft, but also has no interoperability aspects, since can be considered to occur via an out of scope mechanism.

---

From: Rene Struik <[email-masked]>
Date: Fri, 27 Mar 2015 12:22:37 -0400

On 3/27/2015 12:03 PM, Qin Wang wrote:
> Hi Rene,
>
> Regarding to your point 1). I agree with Xavi. The description in 
> nodeAddressType just tells how to store 16bits address in the 64bits 
> space.
RS>>
Question is where this address ends up with. (If it is dropped into the 
64-bit address slot in 802.15.4, security may break down, since it 
assumes globally unique addresses.)
<<RS
>
> Regarding to your point 2). the TODO in section 4.2 refers to the 
> security attributes defined in 15.4. The security attributes defined 
> in 6top are in section 4.3. Everything in the 6top-interface draft 
> needs to be discussed in the next step. Thus, I would like to keep the 
> current structure of draft at this moment. What do you think?
RS>>
Well, the TODO Note in In Section 4.2 says "TODO the security related 
attributes will be added after 6TiSCH WG has consensus on the security 
scheme of 6top", which suggests something else than attributes in 15.4 
to me.
As to Section 4.3, I think my suggestion is clear: simly remove, except 
for the misplaced PANId. I provided rationale for this in my earlier 
email to Xavier.
<<RS
> Thanks
> Qin
>> the address. If someone needs 16bit only will only use that space 
>> from that container. The Data model also supports YANG RPCs which 
>> define communication between peers, the model is used to format the 
>> messages that are exchanged. In some cases the nodes need only to 
>> exchange the short address and thus we want to support that. However 
>> I agree with you that by configuration the 0-appended address does 
>> not make sense. We will review that. thanks.
>> XV>After some days it seemed that nobody had objection or commented 
>> on that so in January-February we proceed to integrate that 
>> information into the draft.
>> 1) is there consensus on that? Are these fields covering (or 
>> partially covering) what is required?
> RS>>
> More importantly, though, the material raises quite a few questions 
> (see below, where I expand on this), so at this point is best removed 
> (as I believe intention is that the interface draft is more or less 
> stable at this point in time).
> <<RS
> not sure whether this is a switch and, if so, whether it only can be 
> set to support one of the options specified. Right now, it is also 
> unclear what triggered this enumeration.
> Right now, it is unclear whether this is all needed and, if so, in 
> which form.
> d) leaf-list PSK:
> this seems to suggest a path to inject pre-shared keys (do we want 
> this, or should this be a Write-only attribute?). This does not seem 
> to impact interoperability.
> e) leaf PanID:
> as already said in my previous email, this seems to have been 
> misplaced, since does not belong in security attribute section.
> f) leaf JoinAssistant:
> not sure why there should be an on/off switch for the JA role. This 
> does not seem to impact interoperability. BTW - If there is a need to 
> remote change roles, I would expect the corresponding state change to 
> be triggered by receipt of a (perhaps, ACE?) command.
> independent of differences in intended use. The 802.15.4 requirement 
> is that these are write-only attributes (so as to enforce that key 
> values never get exposed to the outside world).
> h) leaf-list JCEAddress:
> Great. From emails on the list, it seemed that the suggested "new" 
> para is consensus or very close to this 
>> interface -- we might need an interface to set this keying material 
>> in the MAC PIB. This is currently not defined in the draft, but also 
>> has no interoperability aspects, since can be considered to occur via 
>> an out of scope mechanism
>>
>>     3) Right now, draft-ietf-6tisch-minimal-06 suggests the use of
>>     the keys K1 and K2 (see Section 8), which could potentially be
>>     pre-configured. If so,
>>     Here, I would expect the keying material to be either derived
>>     from a shared key determined at the authentication step of the
>>     join protocol (which is not fully specified yet) or conveyed as
>>     part of a key distribution scheme (which also is not fully
>>     specified yet).
>>
>>     (non-wireless) interface -- we might need an interface to set
>>     this keying material in the MAC PIB. This is currently not
>>     defined in the draft, but also has no interoperability aspects,
>>     since can be considered to occur via an out of scope mechanism.
>>
>>     -- 
> email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik