Subject: Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-minimal-19.txt

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Mon, 6 Feb 2017 08:57:32 +0100

Dear Qin,

thanks so much for your detailed review and sorry for the delay in our
answer. Find inline our comments.

2017-01-25 20:04 GMT+01:00 Qin Wang <[email-masked]>:

> Hi Xavi,
>
> I have just read minimal v19, and the difference between v18 and v19. I
> have some comments as follows.
> (1) In section 8, K2 is used to replace KL in the sentence "Provisioning
> a network with a fixed link key K2 is not secure." I wonder if it should
> be K1 instead of K2 to be used to replace KL.
>
> As we discussed during the last interim meeting we mean K2 here.

> (2) In section 8 there is a discussion about "the impact these fake EBs
> can have, depending on what key(s) are pre-provisioned". I think that
> case 1 (K1 and K2 are pre-provisioned) and case 2 (K1 is pre-provisioned)
> have same problem with fake EBs as case 3 (neither K1 nor K2 is
> pre-provisioned) in term of security. Attacker can make fake EBs with the
> pre-provisioned K1, because K1 is very easy to get. But, if other networks
> instead of attackers are our concern, I will agree that a node has more
> chance to join in correct network in case 1 and case 2.
>
> The assumption is that the attacker does not know the keys. I think the
text is correct here as well.

kind regards,
Xavi

>
> On Wednesday, January 25, 2017 3:39 AM, Xavi Vilajosana Guillen <
> [email-masked]> wrote:
>
>
> Dear all,
>
> we have submitted a new version of minimal addressing the last comments
> received during the call last Friday. Main changes affect the security
> section where Tero's comments have been taken into consideration.
>
> thanks everybody who contributed and kind regards,
> Xavi
>
>
> ---------- Forwarded message ----------
> From: <[email-masked]>
> Date: 2017-01-25 9:36 GMT+01:00
> Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-19.txt
> To: [email-masked]
> Cc: [email-masked]
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e
> of the IETF.
>
>         Title           : Minimal 6TiSCH Configuration
>         Authors         : Xavier Vilajosana
>                           Kris Pister
>                           Thomas Watteyne
>         Filename        : draft-ietf-6tisch-minimal-19. txt
>         Pages           : 26
>         Date            : 2017-01-25
>
> Abstract:
>    This document describes a minimal mode of operation for a 6TiSCH
>    Network.  A minimal mode of operation is a baseline set of protocols,
>    recommended configurations and modes of operation sufficient to
>    enable a 6TiSCH functional network.  6TiSCH provides IPv6
>    connectivity over a Time Synchronized Channel Hopping (TSCH) mesh
>    composed of IEEE Std 802.15.4 TSCH links.  This minimal mode uses a
>    collection of protocols with the respective configurations, including
>    the 6LoWPAN framework, enabling interoperable IPv6 connectivity over
>    IEEE Std 802.15.4 TSCH.  This minimal configuration provides the
>    necessary bandwidth for network and security bootstrap, and defines
>    the proper link between the IETF protocols that interface to IEEE Std
>    802.15.4 TSCH.  This minimal mode of operation should be implemented
>    by all 6TiSCH compliant devices.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/ doc/draft-ietf-6tisch-minimal/
> <https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/>
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/ draft-ietf-6tisch-minimal-19
> <https://tools.ietf.org/html/draft-ietf-6tisch-minimal-19>
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff? url2=draft-ietf-6tisch- minimal-19
> <https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-19>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet- drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>
> ______________________________ _________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/ listinfo/6tisch
> <https://www.ietf.org/mailman/listinfo/6tisch>
>
>
>
> --
> Dr. Xavier Vilajosana
> Wireless Networks Lab
>
> *Internet Interdisciplinary Institute (IN3)Professor*
> (+34) 646 633 681 <+34%20646%2063%2036%2081>
> [email-masked] <[email-masked]>
> http://xvilajosana.org
> http://wine.rdi.uoc.edu
> Parc Mediterrani de la Tecnologia
> Av Carl Friedrich Gauss 5, B3 Building
> 08860 Castelldefels (Barcelona). Catalonia. Spain
> 
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
[email-masked] <[email-masked]>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain

---

From: Jiliang Wang <[email-masked]>
Date: Tue, 7 Feb 2017 17:47:05 +0800

I also have several questions as listed below:

1. How to set the length (in time) of each cell. This should be related to the number of retransmissions, i.e., for a higher number of retransmissions, the cell length should accordingly be set longer? This may incur some efficiency issue?

2. What is default channelslot offset of EB, on which a new node unjoined node should listen?

3. If neither K1 nor K2 is pre-provisioned, a joining node uses the secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4) to process all correctly-formatted EBs.

Here I found no secExempt mechanism in Section 9.2.4 in IEEE Std 802.15.4

4. “Many mechanisms exist for discrimination between networks, the details of which are out of scope.” According to current field setting, it is difficult to differentiate different networks. Does it mean EB contains other field that can be used for this purpose?

Best,

Jiliang Wang

School of software, Tsinghua University

On 01/26/2017 06:30, Suresh Krishnan wrote:

Hi Xavi,

Thanks for addressing the reviews. I have placed this version on the Feb 16 2017 telechat so Tero, Ralph and Brian will have a chance to chime in by then.

Regards

Suresh

On 1/25/17, 3:39 AM, "6tisch on behalf of Xavi Vilajosana Guillen" <[email-masked] on behalf of [email-masked]> wrote:

Dear all,

we have submitted a new version of minimal addressing the last comments received during the call last Friday. Main changes affect the security section where Tero's comments have been taken into consideration.

Xavi

---------- Forwarded message ----------

Cc: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e of the IETF.

Kris Pister

Thomas Watteyne

Filename        : draft-ietf-6tisch-minimal-19.txt

Pages           : 26

Date            : 2017-01-25

Abstract:

https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/

https://tools.ietf.org/html/draft-ietf-6tisch-minimal-19

https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-19

Please note that it may take a couple of minutes from the time of submission

until the htmlized version and diff are available at

tools.ietf.org <http://tools.ietf.org>.

ftp://ftp.ietf.org/internet-drafts/

6tisch mailing list

[email-masked]

--

Dr. Xavier Vilajosana

Wireless Networks Lab

Internet Interdisciplinary Institute (IN3)

Professor

(+34) 646 633 681

[email-masked] <mailto:[email-masked]>

http://xvilajosana.org

http://wine.rdi.uoc.edu

6tisch mailing list

[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 7 Feb 2017 16:20:08 +0200

Jiliang Wang writes:
> 1. How to set the length (in time) of each cell. This should be related to the
> number of retransmissions, i.e., for a higher number of retransmissions, the
> cell length should accordingly be set longer? This may incur some efficiency
> issue?

No. Each cell contains exactly on transmitted frame, and the ack
related to it. If there is needs for retransmissions they will be done
on the later cell, i.e., the transmitter delays sending until there is
cell to the same recipient, and also if this is shared cell, it will
also use backoff alcorithm so it will not use the next shared cell,
but skip some of them etc. For if the next cell is dedicated link,
then it will use it for retransmission.

See section 6.2.5.3 TSCH CSMA-CA retransmission algorithm in
802.15.4-2015, especially figure 6-6 center part, which covers the
TSCH retransmissions which are not priority access.

There is step "Delay for random (2^BE - 1) shared links or until
dedicated link" there which will cause the delay.

The Timeslot length is set by sending EB with TSCH Timeslot IE having
different value for macTsTimeslotLength.

> unjoined node should listen?

It is what is sent in the TSCH Slotframe and Link IE of the EB, and
the section 4 recommends that slotOffset is set to 0x0000, and
chOffset is set to 0x0000.

> 3. If neither K1 nor K2 is pre-provisioned, a joining node uses the secExempt
> mechanism (IEEE Std 802.15.4, Section 9.2.4) to process all
> correctly-formatted EBs.

IEEE Std 802.15.4-2015 section 9.2.4 step f) will check for secExempt.

Note, that this section has changed since 802.15.4-2011 and earlier
versions of the 802.15.4, so you need to get the 802.15.4-2015 for the
section numbers to match. The actual functionality was there in
earlier versions also, but there were some mistakes in the state
machine, and it was harder to read.

Note, that 802.15.4-2015 is available for free from the IEEE Get
program, i.e. go to the
http://standards.ieee.org/getieee802/download/802.15.4-2015.pdf to get
it.

> 4. “Many mechanisms exist for discrimination between networks, the details of
> which are out of scope.” According to current field setting, it is difficult
> to differentiate different networks. Does it mean EB contains other field that
> can be used for this purpose?

There is ongoing work to allocate IE for IETF, and that IE could be
used to provide for example the DAG root or something similar in the
EB, which would allow finding the proper network during the joining
process, especially if you have been part of the network before.
-- 
[email-masked]

---

From: Jiliang Wang <[email-masked]>
Date: Wed, 8 Feb 2017 20:59:28 +0800

thanks very much. There is one more question.  Please see inclined.

On 02/07/2017 22:20, Tero Kivinen wrote:

> 2. What is default channelslot offset of EB, on which a new node

> unjoined node should listen?

It is still required a initial channel to receive the very first EB? How to set this?

program, i.e. go to the

it.

--

[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 8 Feb 2017 15:54:27 +0200

>     It is still required a initial channel to receive the very first EB? How

To find the initial EB you need to do passive scan to find out the
networks which are available. That means you need to listen several
channels for some time to see if you listen any EBs on any of then,
and collect all of those EBs and then pick which network you want to
join. See section 6.3 for scanning through channels and doing active
and passive scans in general, and section 6.3.6 for TSCH.
-- 
[email-masked]

---

From: Jiliang Wang <[email-masked]>
Date: Thu, 9 Feb 2017 18:02:06 +0800

On 02/08/2017 21:54, Tero Kivinen wrote:

>     It is still required a initial channel to receive the very first EB? How

>     to set this?

Yes, there is channel scanning.  Actually I have a question here. By current scanning mechanism, does it mean there is no guarantee for a scanning node and beaconing node to meet? Meanwhile, it may also take a long time to for two nodes to meet.
--

[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 10 Feb 2017 13:46:06 +0200

Jiliang Wang writes:
>     Yes, there is channel scanning.  Actually I have a question here. By
>     current scanning mechanism, does it mean there is no guarantee for a
>     scanning node and beaconing node to meet? Meanwhile, it may also take a
>     long time to for two nodes to meet.

Yes. If you do scanning do fast or incorrectly it is possible that you
never hear EB. On the other hand if you do it so that you are sure to
hear the EBs it might take tens of minutes...

You can of course do all kind of implementation depending things to
make this better. For example if you do energy detection on the
channel first. If there is nobody ever on the channel for long time,
that might mean that channel is not part of the schedule, and
listening it might not be useful. On the other hand if there is too
much energy on the channel, it might be because there is some other
radio transmitter on the channel, and it might not be used for channel
hopping because of that reason. If you hear any 802.15.4 TSCH frames
on the channel, you can assume that this channel is in the current
channel hopping sequence, and if network is set properly there should
be EB on the channel at some point of time. On the other hand you
might need to wait for it for EB_PERIOD * slotframe size * timeslot
length * number of channels * n, where n depends how many dropped
beacons you want to wait. I.e. with typical settings this might be few
minutes. If you do not see EB during that time, you move to next
channel and repeat...
-- 
[email-masked]

---

From: Jiliang Wang <[email-masked]>
Date: Sat, 11 Feb 2017 11:05:48 +0800

On 02/10/2017 19:46, Tero Kivinen wrote:

>     long time to for two nodes to meet.

Thanks for your explanation.  I believe this is an important step in the entire protocol. The specification should avoid the scenario that the meeting time is too long or even unlimited (in any case) rather than depending on the implementation?

channel and repeat...

--

[email-masked]