Subject: [6tisch] last call for draft-ietf-6tisch-minimal-04

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 12 Dec 2014 18:40:31 +0000

Dear all:

As discussed at the interim meeting last week, it is now time to last call a number of drafts that the group produced over the course of the last 2 years.
This call is the first of a series, and is about the TSCH draft http://tools.ietf.org/html/draft-ietf-6tisch-minimal-04   .
The call will last for one week and the conclusion will be discussed at the interim call on Friday 19-Dec-2014;
please express support or concerns about the publication of this work, which is originally aimed at informational status.

Cheers,

Pascal and Thomas

---

From: Rene Struik <[email-masked]>
Date: Fri, 19 Dec 2014 10:56:50 -0500

Hi Pascal:

Some brief feedback:
1) several clauses of the draft reproduce information that is also 
contained in the 802.15.4e-2012 specification. There should be some 
verbiage that, in case of discrepency, the 802.15.4 specification is 
"leading". This is esp. important if one decides to move towards another 
update of 802.15.4.
2) I am still concerned about the TSCH mode, Join priority language 
(which, I think, 6tisch should ignore or, at least, make optional). 
Currently, e.g., the join priority parameter text seems to make random 
installation order very hard (see also email correspondence with Peter 
van der Stok, Tue-Wed Dec 16-17, 2014, 
http://www.ietf.org/mail-archive/web/roll/current/msg09039.html)
3) Shouldn't one have some language in the draft about how enhanced 
beacons are to be secured?
4) Shouldn't one add some language as to how one deals with conflicting 
ASN entries from more than one beacon (e.g., if NUM_NEIGHBOURS_TO_WAIT 
is larger than one)?
5) Change Clause 8, as follows:

    [OLD]
    Key distribution is out of scope of this document, but examples
    include pre-configured keys at the nodes, shared keys amongst peers
    or well-known keys. Refer to
    the 6TiSCH architecture document [I-D.ietf-6tisch-architecture] for
    further details on security aspects

    [NEW]
    Key distribution is out of scope of this document. Refer to the
    6TiSCH architecture document [I-D.ietf-6tisch-architecture] for
    further details on security aspects

Rene

On 12/12/2014 1:40 PM, Pascal Thubert (pthubert) wrote:
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

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

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 19 Dec 2014 18:17:53 +0100

Hi Rene,

thanks you very much for the comments. See inline please.

that's a good point. I will add that. Thanks.

2) I am still concerned about the TSCH mode, Join priority language (which,
I think, 6tisch should ignore or, at least, make optional). Currently,
e.g., the join priority parameter text seems to make random installation
order very hard (see also email correspondence with Peter van der Stok,
Tue-Wed Dec 16-17, 2014,
http://www.ietf.org/mail-archive/web/roll/current/msg09039.html)

Minimal is not inteded to support all possible modes of operation. We are
recommending a defined procedure to ensure everybody joins a network in a
certain manner. Being less restrictive or more open would lead to different
interpretations which is what we want to avoid.

3) Shouldn't one have some language in the draft about how enhanced beacons
are to be secured?

We follow 15.4e specification. We assume nodes know the key. Maybe we
should make clear that. Would that in your opinion be fine?
4) Shouldn't one add some language as to how one deals with conflicting ASN
entries from more than one beacon (e.g., if NUM_NEIGHBOURS_TO_WAIT is
larger than one)?

That's a good point. I´ll check that too.

[OLD]
Key distribution is out of scope of this document, but examples include
pre-configured keys at the nodes, shared keys amongst peers or well-known
keys. Refer to
the 6TiSCH architecture document [I-D.ietf-6tisch-architecture] for further
details on security aspects

[NEW]
Key distribution is out of scope of this document. Refer to the 6TiSCH
architecture document [I-D.ietf-6tisch-architecture] for further details on
security aspects

thank, I agree with that proposal. I will amend it.

regards,
Xavi

2014-12-19 16:56 GMT+01:00 Rene Struik <[email-masked]>:
> installation order very hard (see also email correspondence with Peter van
> der Stok, Tue-Wed Dec 16-17, 2014,
> ASN entries from more than one beacon (e.g., if NUM_NEIGHBOURS_TO_WAIT is
> larger than one)?
> Key distribution is out of scope of this document, but examples include
> pre-configured keys at the nodes, shared keys amongst peers or well-known
> keys. Refer to
> Key distribution is out of scope of this document. Refer to the 6TiSCH
> architecture document [I-D.ietf-6tisch-architecture] for further details on
> security aspects
>
> Rene
>
>
> 6tisch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tisch
>
>
>
> --

---

From: Rene Struik <[email-masked]>
Date: Fri, 19 Dec 2014 12:30:51 -0500

Hi Xavier:

Brief feedback on your feedback below:

Best regards, Rene

On 12/19/2014 12:17 PM, Xavier Vilajosana wrote:
> "leading". This is esp. important if one decides to move towards 
> another update of 802.15.4.
>
> van der Stok, Tue-Wed Dec 16-17, 
> 2014,http://www.ietf.org/mail-archive/web/roll/current/msg09039.html)
>
> Minimal is not inteded to support all possible modes of operation. We 
> are recommending a defined procedure to ensure everybody joins a 
> network in a certain manner. Being less restrictive or more open would 
> lead to different interpretations which is what we want to avoid.
RS>> that should work if the idea is to generate more "minimal" drafts 
should some of the non-tree-shape enrolment orders be considered at some 
later moment in time. You may wish to add a cautionary note here.
<<RS
> should make clear that. Would that in your opinion be fine?
RS>>
The 802.15.4e specification has lots of configuration parameter 
settings. Perhaps, one should add something to the effect that enhanced 
beacons are only authenticated (we do not have too much choice here, 
since 802.15.4e puts some of the IE Fields into the payload, even though 
these would have more logically fitted into the header (since processed 
by the MAC without higher layer interference), so encrypting the payload 
does not work with the current 802.15.4e spec). If you believe we should 
simply remain silent on this and being silent on this would not cause 
trouble, please let me know.
<<RS
> 4) Shouldn't one add some language as to how one deals with 
> conflicting ASN entries from more than one beacon (e.g., if 
> NUM_NEIGHBOURS_TO_WAIT is larger than one)?
>
RS>> Please let me know offline if you have some suggestions (I have 
been looking into lots of mismatch recovery scenario mechanisms lately, 
of which this is one). Technically, it perhaps is not strictly a 
"minimal draft" issue, so if we should tackle the issue elsewhere, 
please let me know. No matter where one puts this, it does require 
thought, though.
<<RS
>     include pre-configured keys at the nodes, shared keys amongst
>     peers or well-known keys. Refer to
>     the 6TiSCH architecture document [I-D.ietf-6tisch-architecture]
>     for further details on security aspects
>
>     [NEW]
> 2014-12-19 16:56 GMT+01:00 Rene Struik <[email-masked] 
> <mailto:[email-masked]>>:
>
>     Hi Pascal:
>
>     Some brief feedback:
>     contained in the 802.15.4e-2012 specification. There should be
>     some verbiage that, in case of discrepency, the 802.15.4
>     specification is "leading". This is esp. important if one decides
>     to move towards another update of 802.15.4.
>     2) I am still concerned about the TSCH mode, Join priority
>     language (which, I think, 6tisch should ignore or, at least, make
>     optional). Currently, e.g., the join priority parameter text seems
>     to make random installation order very hard (see also email
>     correspondence with Peter van der Stok, Tue-Wed Dec 16-17, 2014,
>     3) Shouldn't one have some language in the draft about how
>     enhanced beacons are to be secured?
>     4) Shouldn't one add some language as to how one deals with
>     conflicting ASN entries from more than one beacon (e.g., if
>     NUM_NEIGHBOURS_TO_WAIT is larger than one)?
>         Key distribution is out of scope of this document, but
>         examples include pre-configured keys at the nodes, shared keys
>         amongst peers or well-known keys. Refer to
>         the 6TiSCH architecture document
>         [I-D.ietf-6tisch-architecture] for further details on security
>         aspects
>
>         [NEW]
>         Key distribution is out of scope of this document. Refer to
>         the 6TiSCH architecture document
>         [I-D.ietf-6tisch-architecture] for further details on security
>         aspects
>
>     Rene
>
>
>>     This call is the first of a series, and is about the TSCH drafthttp://tools.ietf.org/html/draft-ietf-6tisch-minimal-04    .
>>     [email-masked]  <mailto:[email-masked]>
>     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]>