Re: [6tisch] WGLC for draft-ietf-roll-dao-projection

[Pascal Thubert (pthubert)]

Dear all: 

A gentle reminder that RAW, DetNet and 6TiSCH are (quickly) mentioned in this 
document;

In particular RAW terminology is being used and it is mentioned that this work 
could be used to install RAW Tracks in RPL domains, with limitations (no 
north-south segments).

Please let us know if you see anything wrong / inappropriate in that work.

All the best to you all;

Pascal

> -Original Message-
> From: RAW  On Behalf Of Pascal Thubert (pthubert)
> Sent: jeudi 5 janvier 2023 10:22
> To: r...@ietf.org
> Cc: det...@ietf.org; 6tisch@ietf.org
> Subject: [Raw] WGLC for draft-ietf-roll-dao-projection
> 
> Dear all
> 
> As you know, in particular with the discussion on the term "Track", ROLL is
> reusing terminology from RAW. This is done in particular in draft-ietf-roll-
> dao-projection.
> 
> As it goes, the draft also has a discussion on how the specification could be
> used for RAW in section 3.7.2.4 https://www.ietf.org/archive/id/draft-ietf-
> roll-dao-projection-31.html#name-providing-for-raw.
> 
> There's also a snippet on how this spec can be used to extend 6TiSCH
> capabilities, and how it could be mapped into the DetNet architecture, as
> sections 3.7.2.1 and 3.7.1.2 respectively.
> 
> During his A-D review, Alvaro indicated that we should have formally
> requested reviews from those groups as well. Sorry for failing to do that.
> For those interested, please have a look at section 3.7.2 or the whole
> document if you can, and provide comments with cc to the ROLL mailing list.
> 
> All the best for this new year!
> 
> Pascal
> 
> --
> RAW mailing list
> r...@ietf.org
> https://www.ietf.org/mailman/listinfo/raw

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] WGLC for draft-ietf-roll-dao-projection

[Pascal Thubert (pthubert)]

Dear all

As you know, in particular with the discussion on the term "Track", ROLL is 
reusing terminology from RAW. This is done in particular in 
draft-ietf-roll-dao-projection. 

As it goes, the draft also has a discussion on how the specification could be 
used for RAW in section 3.7.2.4 
https://www.ietf.org/archive/id/draft-ietf-roll-dao-projection-31.html#name-providing-for-raw.

There's also a snippet on how this spec can be used to extend 6TiSCH 
capabilities, and how it could be mapped into the DetNet architecture, as 
sections 3.7.2.1 and 3.7.1.2 respectively.

During his A-D review, Alvaro indicated that we should have formally requested 
reviews from those groups as well. Sorry for failing to do that. For those 
interested, please have a look at section 3.7.2 or the whole document if you 
can, and provide comments with cc to the ROLL mailing list.

All the best for this new year!

Pascal 

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] time to close WG

[Pascal Thubert (pthubert)]

Hello Michael

We kept it open in case new work comes up. This might happen once RAW has 
progressed to the point that it requires interfaces that 6TiSCH can implement 
in the 802.15.4 TSCH case. Maybe we can observe RAW, wait and see ?

Keep safe;

Pascal

> -Original Message-
> From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Michael Richardson
> Sent: mercredi 23 mars 2022 17:41
> To: 6tisch@ietf.org
> Subject: [6tisch] time to close WG
> 
> 
> Hallway discussion was: why is 6tisch still open?
> All the drafts are published, and I don't think we are rechartering.
> 
> We never got ultra-constrained onboarding specificed, but EDHOC might pick
> that up.
> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks
> [
> ]   Michael Richardson, Sandelman Software Works| network architect
> [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Finally !!

[Pascal Thubert (pthubert)]

Dear all

It is our greatest pleasure to announce that the following RFCs were just 
published on the IETF data tracker:



RFC 9030 (was 
draft-ietf-6tisch-architecture)
An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 
802.15.4 (6TiSCH)
2021-05
57 pages
New
Informational RFC


RFC 9031 (was 
draft-ietf-6tisch-minimal-security)
Constrained Join Protocol (CoJP) for 6TiSCH
2021-05
41 pages
New
Proposed Standard RFC


RFC 9032 (was 
draft-ietf-6tisch-enrollment-enhanced-beacon)
Encapsulation of 6TiSCH Join and Enrollment Information Elements
2021-05
10 pages
New
Proposed Standard RFC


RFC 9033 (was draft-ietf-6tisch-msf)
6TiSCH Minimal Scheduling Function (MSF)
2021-05
20 pages
New
Proposed Standard RFC

This concludes the work items that this working group had on its plate.

Many thanks to you all for years of hard work, in standards, open source 
implementation, and interop testing.

Keep safe!

The chairs
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Nomcom needs you

[Pascal Thubert (pthubert)]

NomCom is considering nominees for AD positions, IETF Chair, IAB, LLC Board, 
and IETF Trust. We need more input from the community both on specific nominees 
and on over-arching topics regarding what the community wants from these 
specific groups and wants from its leadership in general. We need *your* input.

** Deadline for community feedback is Friday November 20. **

We've paid attention to discussions on the ietf list. Issues raised there have 
been brought up in interviews.

We've also asked questions of nominees based on feedback received, and based on 
the "Topics" that people said were important.
We're listening to you.

But most of the input to date has come from a few consistently vocal people. We 
need to hear from more of you.

I scheduled our office hours during the 2 weeks before next week's IETF, 
because IETF week is so busy. We have one more left (18:00-19:00 UTC November 
11). No-one but NomCom members showed up for our first 3. ☹ If there is demand 
for more office hours, I'll schedule them; but this really doesn't seem to be 
the preferred format for input.

Most input is coming in as either
- email to nomco...@ietf.org
- feedback on https://datatracker.ietf.org/nomcom/2020/feedback/
On the feedback page, the specific nominees are all listed at the top. General 
Topics are at the bottom.
We pay attention to all the comments we get through these channels.

I'll also try to hang out in Gather.Town during IETF breaks next week.
I'm not going to have a specific NomCom area in Gather.Town, because it was 
really lonely hanging out there during IETF 108.
But please feel free to hunt me down and bend my ear -- on NomCom issues or 
just to chat.
I miss seeing all of y'all!
Barbara

Barbara Stark
NomCom 2020 Chair

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] FW: [802.15-ALL] Sad news about Dr. Robert F. Heile

[Pascal Thubert (pthubert)]

Dear all, I thought you wanted to know. Bob was the chair of IEEE 802.15 for a 
great many years.

From: pat.kin...@kinneyconsultingllc.com 
Sent: vendredi 25 septembre 2020 18:13
To: stds-802-w...@listserv.ieee.org
Subject: [802.15-ALL] Sad news about Dr. Robert F. Heile

It is with my greatest regrets and deepest sorrow that I must inform you of the 
passing of Dr Robert F Heile’s last night.  As you know Bob’s condition was 
deteriorating rapidly.  He was at home, in no pain, and with his wife, Bonnie, 
and two daughters, Sarah and Beth, when he peacefully passed away.

At this time, I have not heard of the arrangements nor services, I will send 
out additional information as I find out.

Sincerely,  Pat

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG chair, IEEE 802.15 SCm chair, IEEE 802.15.12 chair
ISA100 co-chair, ISA100.20 chair
M: +1.847.997.3775
O: +1.847.960.3715
pat.kin...@kinneyconsultingllc.com


To unsubscribe from the STDS-802-WPAN list, click the following link: 
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-WPAN&A=1
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] FW: New Version Notification for draft-ietf-6tisch-architecture-29.txt

[Pascal Thubert (pthubert)]

Dear all

There was one instance of a mistake in the Track Identification description (by 
destination not source of the packet). 
The definition was correct though.

Also clarified that the Track ID is not the flow ID, that there can be more 
than one flow in a Track. 
This becomes especially important when oOAM traffic needs to be carried in a 
same Track as the observed flow, which is a concern at DetNet and RAW.

Please let me know if you see an issue with this or some leftover mistake in 
the text. 

FYI, the draft is still help in MISREF in cluster C310 
https://www.rfc-editor.org/cluster_info.php?cid=C310, longing for the unaware 
leaves, the MSF, the CORE stateless and the enhanced beacons drafts.

Keep safe!

Pascal


-Original Message-
From: internet-dra...@ietf.org  
Sent: jeudi 27 août 2020 11:38
To: Pascal Thubert (pthubert) 
Subject: New Version Notification for draft-ietf-6tisch-architecture-29.txt


A new version of I-D, draft-ietf-6tisch-architecture-29.txt
has been successfully submitted by Pascal Thubert and posted to the IETF 
repository.

Name:   draft-ietf-6tisch-architecture
Revision:   29
Title:  An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4
Document date:  2020-08-27
Group:  6tisch
Pages:  71
URL:
https://www.ietf.org/internet-drafts/draft-ietf-6tisch-architecture-29.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture/
Htmlized:   https://tools.ietf.org/html/draft-ietf-6tisch-architecture-29
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-architecture
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-architecture-29

Abstract:
   This document describes a network architecture that provides low-
   latency, low-jitter and high-reliability packet delivery.  It
   combines a high-speed powered backbone and subnetworks using IEEE
   802.15.4 time-slotted channel hopping (TSCH) to meet the requirements
   of LowPower wireless deterministic applications.


  


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.

The IETF Secretariat


___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Fwd: Nomcom 2020-2021 Second Call For Volunteers

[Pascal Thubert (pthubert)]

As Fred says... non-com is a foundation of the IETF open and diverse activities.

Please volunteer if you can...

Pascal

Expéditeur: Fred Baker 
Date: 11 juin 2020 à 00:02:17 UTC+2
Destinataire: IPv6 Operations 
Objet: [v6ops] Fwd: Nomcom 2020-2021 Second Call For Volunteers

 Folks: the nomcom chair asked that you volunteer to serve on the nomcom. I 
would ask that, and ask that you also be willing to serve in management roles 
in the IETF. If there’s something you wish were different, it would be your 
chance to change it.

Sent from my iPad

Begin forwarded message:

From: NomCom Chair 2020 
Date: June 10, 2020 at 1:55:21 PM CDT
To: IETF Announcement List 
Cc: "i...@ietf.org" 
Subject: Nomcom 2020-2021 Second Call For Volunteers

This is the second sending of the call for volunteers for the 2020-2021 NomCom.

I wanted to mention a few updates from the previous email (sent 2 weeks ago):
- I've fixed the URL at the bottom of the email to point to 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_nomcom_2020_&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=ZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI&s=NgIu-7Ij0nEdsFcbJOLcl2M56RxyREhLAtcaHLatD34&e=
  instead of /2019/. This was a test to see if anyone was paying attention. 
Apparently, some people were. ;)
- The IETF 108 registration form includes a checkbox that will let you 
volunteer. You can use this instead of emailing me, when you register for IETF 
108.
- I currently have 39 volunteers. Last year had 149. I need more volunteers!
-
The IETF NomCom appoints people to fill the open slots on the LLC, IETF Trust, 
the IAB, and the IESG.

Ten voting members for the NomCom are selected in a verifiably random way from 
a pool of volunteers. The more volunteers, the better chance we have of 
choosing a random yet representative cross section of the IETF population.

The details of the operation of the NomCom can be found in BCP 10 (RFC 8713). 
RFC 3797 details the selection algorithm.

Special for this year (and only this year), we also have RFC 8788 (one-off 
update to RFC 8713 / BCP 10) to tell us who is eligible to volunteer:

 Members of the IETF community must have attended at least three of
 the last five in-person IETF meetings in order to volunteer.

 The five meetings are the five most recent in-person meetings that
 ended prior to the date on which the solicitation for NomCom
 volunteers was submitted for distribution to the IETF community.
 Because no IETF 107 in-person meeting was held, for the 2020-2021
 Nominating Committee those five meetings are IETFs
   102 [Montreal, Canada; July 2018],
   103 [Bangkok, Thailand; November 2018],
   104 [Prague, Czech Republic; March 2019],
   105 [Montreal, Canada; July 2019], and
   106 [Singapore; November 2019].

Keep in mind that eligibility is based on in-person attendance at the five 
listed meetings. You can check your eligibility at: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_registration_nomcom.py&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=ZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI&s=7_9x9PPoUIajJs2AnUFYg0KnEg8gkD3Jnwf1v079EQo&e=
 .

If you qualify, please volunteer. Before you decide to volunteer, please 
remember that anyone appointed to this NomCom will not be considered as a 
candidate for any of the positions that the 2020 - 2021 NomCom is responsible 
for filling.

People commonly volunteer by ticking the box on IETF registration forms. The 
IETF 106 form did not ask whether people were willing to volunteer. IETF 107 
did ask, but all those registrations were canceled. I have asked the 
Secretariat if it is possible to get the list if volunteers from canceled IETF 
107 registrations. If that list is available, I will contact all who are 
verified as eligible. But given the uncertainty of this process, I would 
encourage people to volunteer directly (see the bottom of this email for 
instructions). Thank you for volunteering!

The list of people and posts whose terms end with the March 2021 IETF meeting, 
and thus the positions for which this NomCom is responsible, are

IETF Trust:
   Joel Halpern

LLC:
   Maja Andjelkovic

IAB:
   Jari Arkko
   Jeff Tantsura
   Mark Nottingham
   Stephen Farrell
   Wes Hardaker
   Zhenbin Li

IESG:
   Alissa Cooper, IETF Chair/GEN AD
   Alvaro Retana, RTG AD
   Barry Leiba, ART AD
   Deborah Brungard, RTG AD
   Éric Vyncke, INT AD
   Magnus Westerlund, TSV AD
   Roman Danyliw, SEC AD
   Warren Kumari, OPS AD

All appointments are for 2 years. The Routing area has 3 ADs and the General 
area has 1; all other areas have 2 ADs. Thus, all areas (that have more than 
one AD) have at least one continuing AD.

The primary activity for this NomCom will begin in July 2020 and should be 
completed in January 2021.  The NomCom will have regularly scheduled confer

Re: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16: (with COMMENT)

[Pascal Thubert (pthubert)]

Hello Benjamin and Tengfei;

What I did is pick one randomly, and  picked this;

“

   MSF works closely with RPL, specifically the routing parent defined
   in [RFC6550].  This specification only describes how MSF works with
   one routing parent, which is phrased as "selected parent".  The

nit: I suggest '''one routing parent; this parent is referred to as the
"selected parent"'''.

“

Then I looked at 16 and the text is still


   MSF works closely with the IPv6 Routing Protocol for Low-Power and
   Lossy Networks (RPL), specifically the routing parent defined in
   [RFC6550<https://tools.ietf.org/html/rfc6550>].  This specification only 
describes how MSF works with the
   selected routing parent, which is phrased as "selected parent".  The
   activity of MSF towards the single routing parent is called a "MSF
   session".  Though the performance of MSF is evaluated only when the
   "selected parent" represents the node's preferred parent, there

This tells me that the handling of Benjamin’s review is not complete, so I 
asked Tengfei to double check.

Take care;

Pascal




From: Tengfei Chang 
Sent: lundi 11 mai 2020 17:00
To: Pascal Thubert (pthubert) 
Cc: tengfei chang ; Benjamin Kaduk ; 
iesg ; draft-ietf-6tisch-msf ; 
6tisch <6tisch@ietf.org>; 6tisch-chairs <6tisch-cha...@ietf.org>
Subject: Re: [6tisch] Benjamin Kaduk's No Objection on 
draft-ietf-6tisch-msf-16: (with COMMENT)

Hi Pascal,

If comparing the comments to draft-ietf-6tisch-msf-12 from another thread 
previously, you will find out they are actually the same.

Those comments are indeed fixed with the MSF versions after 12, including 
draft-ietf-6tisch-msf-16.


Regards,
Tengfei



Stay Healthy! Stay Optimistic!


Dr. Tengfei Chang
Post-doctoral Researcher

Wireless Networking for Evolving & Adaptive Applications (EVA)

National Inst. for Research in Comp. Sci. and Automation (Inria)

(+33)1 80 49 41 43
tengfei.ch...@inria.fr<mailto:tengfei.ch...@inria.fr>
www.tchang.org<http://www.tchang.org>

[cid:image001.jpg@01D627BF.14EEA7F0]



From: "Pascal Thubert, pthubert" mailto:pthub...@cisco.com>>
To: "tengfei chang" mailto:tengfei.ch...@gmail.com>>, 
"Benjamin Kaduk" mailto:ka...@mit.edu>>
Cc: "iesg" mailto:i...@ietf.org>>, "draft-ietf-6tisch-msf" 
mailto:draft-ietf-6tisch-...@ietf.org>>, 
"6tisch" <6tisch@ietf.org<mailto:6tisch@ietf.org>>, "6tisch-chairs" 
<6tisch-cha...@ietf.org<mailto:6tisch-cha...@ietf.org>>
Sent: Monday, May 11, 2020 4:23:12 PM
Subject: RE: [6tisch] Benjamin Kaduk's No Objection on 
draft-ietf-6tisch-msf-16: (with COMMENT)
Hello Tengfei

My reading is that the comments below apply to version 16 as the title 
indicates.
I randomly checked the proposed nit fixes and the issues are effectively still 
left to be fixed.
Can you please have a look?

Take care,

Pascal



From: Tengfei Chang mailto:tengfei.ch...@gmail.com>>
Sent: lundi 11 mai 2020 14:06
To: Benjamin Kaduk mailto:ka...@mit.edu>>
Cc: The IESG mailto:i...@ietf.org>>; 
draft-ietf-6tisch-...@ietf.org<mailto:draft-ietf-6tisch-...@ietf.org>; 6tisch 
<6tisch@ietf.org<mailto:6tisch@ietf.org>>; 
6tisch-cha...@ietf.org<mailto:6tisch-cha...@ietf.org>; Pascal Thubert 
(pthubert) mailto:pthub...@cisco.com>>
Subject: Re: [6tisch] Benjamin Kaduk's No Objection on 
draft-ietf-6tisch-msf-16: (with COMMENT)

Hi Benjamin,

Thanks for updating the comments!

I believe the change from the current email comparing to previous one is that 
the DISCUSSION part is removed as we fixed it in another previous thread.
The other comments from the current email are actually for old version of MSF, 
which are all resolved in the latest version MSF-16.

For the administration,

I want to clarify that  the draft-ietf-6tisch-msf-16 has resolved all comments 
which were discussed.
Please advise me if there is any further action required. Thanks a lot!

Regards,
Tengfei


On Fri, Apr 3, 2020 at 5:38 AM Benjamin Kaduk via Datatracker 
mailto:nore...@ietf.org>> wrote:
Benjamin Kaduk has entered the following ballot position for
draft-ietf-6tisch-msf-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/



--
COMMENT:

Re: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16: (with COMMENT)

[Pascal Thubert (pthubert)]

Hello Tengfei

My reading is that the comments below apply to version 16 as the title 
indicates.
I randomly checked the proposed nit fixes and the issues are effectively still 
left to be fixed.
Can you please have a look?

Take care,

Pascal



From: Tengfei Chang 
Sent: lundi 11 mai 2020 14:06
To: Benjamin Kaduk 
Cc: The IESG ; draft-ietf-6tisch-...@ietf.org; 6tisch 
<6tisch@ietf.org>; 6tisch-cha...@ietf.org; Pascal Thubert (pthubert) 

Subject: Re: [6tisch] Benjamin Kaduk's No Objection on 
draft-ietf-6tisch-msf-16: (with COMMENT)

Hi Benjamin,

Thanks for updating the comments!

I believe the change from the current email comparing to previous one is that 
the DISCUSSION part is removed as we fixed it in another previous thread.
The other comments from the current email are actually for old version of MSF, 
which are all resolved in the latest version MSF-16.

For the administration,

I want to clarify that  the draft-ietf-6tisch-msf-16 has resolved all comments 
which were discussed.
Please advise me if there is any further action required. Thanks a lot!

Regards,
Tengfei


On Fri, Apr 3, 2020 at 5:38 AM Benjamin Kaduk via Datatracker 
mailto:nore...@ietf.org>> wrote:
Benjamin Kaduk has entered the following ballot position for
draft-ietf-6tisch-msf-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/



--
COMMENT:
--

Thanks for clarifying the non-issue nature of my original Discuss points!

Original COMMENT section preserved below (possibly stale).

I support Roman's Discuss -- we need more information for this to be a
useful reference; even what seem to be the official DASFAA 1997
proceedings (https://dblp.org/db/conf/dasfaa/dasfaa97) do not have an
associated document).

Basing various scheduling aspects on (a hash of) the EUI64 ties
functionality to a persistent identifier for a device.  How significant
a disruption would be incurred if a device periodically changes its
presented EUI64 for anonymization purposes?

There seems to be a general pattern of "if you don't have a
6P-negotiated Tx cell, install and AutoTxCell to send your one message
and then remove it after sending"; I wonder if it would be easier on the
reader to consolidate this as a general principle and not repeat the
details every time it occurs.

Requirements Language

"NOT RECOMMENDED" is not in the RFC2119 boilerplate (but is a BCP 14 keyword).

Section 1

   the 6 steps described in Section 4.  The end state of the join
   process is that the node is synchronized to the network, has mutually
   authenticated to the network, has identified a routing parent, and

nit(?): I guess maybe "mutually authenticated with" is more correct for
the bidirectional operation.

   It does so for 3 reasons: to match the link-layer resources to the
   traffic, to handle changing parent, to handle a schedule collision.

nit: end the list with "or" (or "and"?).

   MSF works closely with RPL, specifically the routing parent defined
   in [RFC6550].  This specification only describes how MSF works with
   one routing parent, which is phrased as "selected parent".  The

nit: I suggest '''one routing parent; this parent is referred to as the
"selected parent"'''.

   activity of MSF towards to single routing parent is called as a "MSF

nit: "towards the"

   *  We added sections on the interface to the minimal 6TiSCH
  configuration (Section 2), the use of the SIGNAL command
  (Section 6), the MSF constants (Section 14), the MSF statistics
  (Section 15).

nit: end the list with "and".

Section 2

   In a TSCH network, time is sliced up into time slots.  The time slots
   are grouped as one of more slotframes which repeat over time.  The

nit(?): should this be "one or more"?

   channel) is indicated as a cell of TSCH schedule.  MSF is one of the
   policies defining how to manage the TSCH schedule.

nit: if there is only one such policy active at a given time for a given
network, I suggest "MSF is a policy for managing the TCSH schedule".
(If multiple policies are active simultaneously, no change is needed.)

   MSF uses the minimal cell for broadcast frames such as Enhanced
   Beacons (EBs) [IEEE802154] and broadcast DODAG Information Objects
   (DIOs) [RFC6550].  Cells scheduled by MSF are meant to be used only
   for unica

Re: [6tisch] MSF traffic adaptation under stress

[Pascal Thubert (pthubert)]

Hello David

I’m really interested to see your results and proposal for improvements.

If people are interested we could set up an hour virtual interim. We must have 
it 3 weeks in advance which means early June.

In the meantime, yes please consider whether there are simple adjustments to 
the spec that could be made before we ship it. We’re very late in the process 
so we have to act swiftly.

Many thanks!

Pascal

> Le 10 avr. 2020 à 00:27, David Hauweele  a écrit :
> 
> Dear 6TiSCH,
> 
> In the last few months, we performed a small scale study of the
> behavior of 6TiSCH's minimal scheduling function (MSF) under stress. We
> were especially interested in the dynamics of MSF's automated
> adaptation to traffic load. Some of our conclusions have been
> summarized in a paper that we submitted to IEEE ISCC 2020. A copy of
> the evaluation section of our submission is attached to this mail.
> 
> Among our surprising findings, we observed that
> 
> 1) The time required for MSF to adapt to a traffic change depends on
> the current number of cells allocated. To give an example, it takes
> much longer to go from 0 to 10 cells than from 10 to 20 cells. We
> attribute this behavior to the way MSF measures cell occupancy by
> counting the number of used and passed cells. Adaptation only occurs
> when the number of passed cells reaches a maximum. However, with light
> cell allocation, it takes longer to reach that maximum than with higher
> cell allocation.
> 
> 2) MSF can lead to severe over-provisioning, which can be harmful in an
> environment where the resources are scarce. We noticed that releasing
> cells was especially hard for MSF due to the fixed hysteresis
> thresholds. Indeed, the estimated cell occupancy must drop below 25%
> for cells to be released.
> 
> We already have ideas to improve MSF's traffic adaptation mechanism,
> that we plan to put under test in the coming weeks. We can also provide
> you with more details if you wish. If you see interest in our evaluation
> and proposals, we are eager to discuss this further with the WG.
> 
> Best regards,
> David, Bruno, Aris and Georgios
> 
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-msf-12: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

Hello Ben
´
> Le 3 avr. 2020 à 05:37, Benjamin Kaduk  a écrit :
> 
> Hi Pascal,
> 
>> On Thu, Apr 02, 2020 at 09:57:07AM +0000, Pascal Thubert (pthubert) wrote:
>> Hello Benjamin and authors:
>> 
>> Thomas is really the MAC expert, (virtually) collocated with him, and more 
>> fluent in English than I'll ever be. But I'll take a chance at it.
>> 
>> I understand that the problem you're concerned with happens when the 
>> automatic slot offset for node A ends up the same as that for node B. Note 
>> that it does not take a hash collision, because the problem is independent 
>> of the 
>> channel offset. All it takes is a collision in time, because if I'm busy 
>> transmitting I cannot receive on a half duplex radio. The chance of this to 
>> occur is 1/slotframe_size for a random pick for which the hash is an 
>> approximation.  
>> 
>> In that case (same auto slot for A and B), an arbitrary node  C (which could 
>> be A or any other node) will fail to talk to B if B has something to 
>> transmit to A, because if B xmit has precedence, and when B's radio is busy 
>> and it will not to receive from C, even on a different channel (it's half 
>> duplex). So if B keeps talking a lot to A, that will make it mostly deaf. 
>> But if B is a relay as opposed to the generator of traffic, the xmit queue 
>> will dry out and B will listen again. 
>> 
>> If C is A, meaning that A sends to B and B sends to A at the same time, and 
>> in the absence of other traffic, the retries will happen at different times 
>> and will not collide, all good. If the traffic in both direction becomes 
>> intense, the retries will cause even more collisions and we'll end in 
>> congestion collapse.
> 
> The "retries will happen at different times" is the part that I was
> missing, and Tengfei just added a description of that in the -16, so I
> think I'm all set as far as this goes.
> 
> Thanks for the detailed explanation!
> 

All good then; I misunderstood and thought you expected a finer description of 
the case in the spec.

>> Potential defenses include:
>> - MSF could be more aggressive at establishing cells to nodes that end with 
>> the same automatic slotOffset as self
>> - In densely used networks (which are unusual for battery operated 
>> networks), define multiple timeslots with different auto slotOffset for each 
>> node, using different seeds for the hash (like a nmber 1 ..n),  and have the 
>> sender use a random one for Tx.
>> 
>> Is that what you are after?
> 
> It's not clear to me that we need to mandate either of these as part of a
> *minimal* scheduling function, though having a description of the potential
> issues would be reasonable.

This is what I expected, though it is not a security issue per say, it is still 
a pitfall that the deployment should be aware of. Also the reader may have the 
same intuition as you did and having the description handy makes sense to me. 
That could be an annex though. I did not expect to mandate solutions just to 
express them like we do in a security section. Note that renumbering is another 
remediation and still an open question in your COMMENTS.


>  (Should we expect higher-layer protocols to
> eventually back off and remedy the congestion collapse?)
> 

I’d not suggest that. It would work but misuse the network and waste energy.

 The root issue is not the load between A and B but the MAC addresses that they 
picked and the shape If the mesh. IMHO this should be addressed under IP.

> I'm going to go clear my Discuss now, as those points are resolved, which
> of course does not preclude making further changes.
> 

Many thanks Ben!



> -Ben
> 
>> Thomas (or Simon): I'm sure I'm missing stuff, what more is there?
>> 
>> You all keep safe
>> 
>> Pascal
>> 
>> 
>> 
>>>>>> DISCUSS:
>>>>>> 
>>>>> 
>>>>> --
>>>>>> 
>>>>>> I'm concerned that the scheduling function for autonomous cells can
>>>>>> cause an infinite loop in the case of hash collision -- Section 3
>>>>>> specifies that AutoTxCell always takes precedence over
>>>>>> AutoRxCell,
>>>>> but
>>>>>> if those two cells collide, the corresponding cells on the peer in
>>>>>> question will also collide.  If both peers try to send at the
>>>>>> same
>>>>> time
>>>>>> and the

Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-msf-12: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

Hello Benjamin and authors:

Thomas is really the MAC expert, (virtually) collocated with him, and more 
fluent in English than I'll ever be. But I'll take a chance at it.

I understand that the problem you're concerned with happens when the automatic 
slot offset for node A ends up the same as that for node B. Note that it does 
not take a hash collision, because the problem is independent of the 
channel offset. All it takes is a collision in time, because if I'm busy 
transmitting I cannot receive on a half duplex radio. The chance of this to 
occur is 1/slotframe_size for a random pick for which the hash is an 
approximation.  

In that case (same auto slot for A and B), an arbitrary node  C (which could be 
A or any other node) will fail to talk to B if B has something to transmit to 
A, because if B xmit has precedence, and when B's radio is busy and it will not 
to receive from C, even on a different channel (it's half duplex). So if B 
keeps talking a lot to A, that will make it mostly deaf. But if B is a relay as 
opposed to the generator of traffic, the xmit queue will dry out and B will 
listen again. 

If C is A, meaning that A sends to B and B sends to A at the same time, and in 
the absence of other traffic, the retries will happen at different times and 
will not collide, all good. If the traffic in both direction becomes intense, 
the retries will cause even more collisions and we'll end in congestion 
collapse.

Potential defenses include:
- MSF could be more aggressive at establishing cells to nodes that end with the 
same automatic slotOffset as self
- In densely used networks (which are unusual for battery operated networks), 
define multiple timeslots with different auto slotOffset for each node, using 
different seeds for the hash (like a nmber 1 ..n),  and have the sender use a 
random one for Tx.

Is that what you are after?

Thomas (or Simon): I'm sure I'm missing stuff, what more is there?

You all keep safe

Pascal



> > > >  DISCUSS:
> > > >
> > > 
> > > --
> > > >
> > > >  I'm concerned that the scheduling function for autonomous cells can
> > > >  cause an infinite loop in the case of hash collision -- Section 3
> > > >  specifies that AutoTxCell always takes precedence over
> > > > AutoRxCell,
> > > but
> > > >  if those two cells collide, the corresponding cells on the peer in
> > > >  question will also collide.  If both peers try to send at the
> > > > same
> > > time
> > > >  and the hashes collide, they will both attempt to transmit
> > > indefinitely
> > > >  and never be received.
> > > >
> > > >
> > > >>. Notice that the AutoTxCell  is a shared cell, where the back-off
> > > >mechanism is applied.
> > > >> In case there is a collision on that cell, a back-off with 
> > > > different
> > > >exponent will be used on each side.
> > > >> The cell will be used AutoTxCell on each side at different timing.
> > >
> > > Ah, it seems I was misinterpreting "take precedence over" to apply
> > > to the entire local scheduling, not merely the case when independent
> > > tx and rx scheduling land on the same cell.  Thanks for clarifying
> > > here; is there anything useful to say in the document about how even
> > > if there is a collision in the assigned slot there's still a Tx
> > > backoff, so the cell is usable for Rx some of the time?
> > >
> >
> > * RESPONSE: * We could add the following sentence right after the
> > hashing collision statement:
> >
> > Notice AutoTxCell is a shared type cell which applies back off mechanism.
> > When the AutoTxCell and AutoRxCell are collided,  AutoTxCell takes
> > precedence if there is a packet to transmit.
> > In case in a back-off period, AutoRxCell is used.
> 


___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Alissa Cooper's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

Hello Alissa and Michael

(chair hat on)

Please keep in mind that this draft does not have vocation to update RFC 4944. 
6TiSCH does not have that vocation either. If something was needed, it would 
belong to 6lo. 
Arguably the art of 6LoWPAN allows a node to apply RFC 8064/8065 if it likes. I 
expect it will become more common as larger MTUs arise. 

Using short addresses and deriving IPv6 addresses from them is how RFC 4944 
enabled IPv6 in some environments where it was not applied before (because IPv6 
was deemed impossible with a MTU of 127 bytes or below).  IEEE std 802.15.4 
short addresses can be renewed, which will cause the IPv6 addresses that are 
derived from them will change too. If short addresses are chosen 
pseudo-randomly and renewed periodically, privacy can be improved at the 
expense of complexity, a trade off that each use case will have to make.

As most of the 6TiSCH standard track work, this draft operates at the interface 
between IETF and IEEE. A spec that modifies IEEE beacons is probably not the 
best place to discuss address allocation.
The draft does not make a "recommendation" on which mechanism to use, it  just 
enables to signal which of the existing mechanisms is used. 

All in all, I believe that the DISCUSS should be removed; point taken to 
discuss this more at 6lo, though.

Take care,

Pascal


> -Original Message-
> From: Michael Richardson 
> Sent: jeudi 20 février 2020 19:35
> To: Alissa Cooper 
> Cc: The IESG ; Pascal Thubert (pthubert)
> ; 6tisch-cha...@ietf.org; 6tisch@ietf.org; draft-ietf-
> 6tisch-enrollment-enhanced-bea...@ietf.org
> Subject: Re: [6tisch] Alissa Cooper's Discuss on draft-ietf-6tisch-enrollment-
> enhanced-beacon-13: (with DISCUSS and COMMENT)
> 
> 
> Alissa Cooper via Datatracker  wrote:
> > == Section 2 ==
> 
> > "If this field is not present, then IID is derived from the layer-2
> > address of the sender as per SLAAC ({?RFC4662})."
> 
> > RFC 8064 recommends that the default IID generation scheme for use with
> > SLAAC is not to use the layer-2 address, but to use the mechanism
> > specified in RFC 7217. Is there a reason this specification is making a
> > different recommendation?
> 
> Yes.
> We have this conversation pretty much every single time that 802.15.4 is
> discussed.
> 
> 1) 6lowpan compression depends upon the layer-3 address being derived from
>the layer-2 address so that the usless bytes are not transmitted every
>single time.
> 
> 2) however, 802.15.4 beacons are always sent using the 64-bit EUI64 L2 source
>addresses.  The device does not have to use IEEE OUI assigned addresses,
>but could use IEEE randomized MAC addresses if the firmware decides to do
>this.
> 
> 3) 802.15.4 prefers to use assign 2-byte short addresses (and to derive the
>L3 address from that short-address).
>The recently approved 6tisch-minimal-security CoJP protocol includes
>assignment of 2-byte address using a central process.  As such, during
>normal operation neither the L2 and L3 addresses have manufacturer
>specific OUI content.
> 
> I believe that other documents have said this already, so I don't think there
> needs to be any further repeating.  Let me know if you feel differently.
> 
> > --
> > COMMENT:
> > --
> 
> > == Section 1.3 ==
> 
> > This sentence is not comprehensible:
> 
> > "Although However, even in this case, a unicast RS may be transmitted
> > in response[RFC6775] reduces the amount of multicast necessary to do
> > address resolution via Neighbor Solicitation (NS) messages, it still
> > requires multicast of either RAs or RS."
> 
> > == Section 2 ==
> 
> > s/({?RFC4662})/[RFC4862]
> 
> both already fixed.
> 
> > == Section 4 ==
> 
> > A network doesn't have privacy considerations. The draft might want to
> > discuss how this specification reveals information about network
> > topology, but that isn't a privacy consideration.
> 
> I think that every single draft should have privacy considerations.
> If you have a LLN as part of your household automation, then being able to
> map the extent of the LLN reveals which parts of the building belong to you.
> 
> If I had a house with many pieces (parking spot, storage in the basement,
> etc) and I had active nodes in those places, I would want to consider whether
> or not I want to use the same subnet (with backbone), or whether I'd want to
> split things up.
> 

[6tisch] Fwd: REMINDER: Early Bird Cutoff is Monday, February 3rd at 23:59

[Pascal Thubert (pthubert)]

Regards,

Pascal

Début du message transféré :

Expéditeur: "Rob Wilton (rwilton)" 
Date: 3 février 2020 à 17:22:03 UTC+1
Destinataire: "ietf-interest(mailer list)" 
Objet: FW:  REMINDER: Early Bird Cutoff is Monday, February 3rd at 23:59

A reminder that the early bird cutoff for IETF 107 is at 23:59 UTC today.


-Original Message-
From: ietf  On Behalf Of IETF Secretariat
Sent: 31 January 2020 18:12
To: IETF Announcement List 
Cc: recentattend...@ietf.org; i...@ietf.org; 107...@ietf.org
Subject: REMINDER: Early Bird Cutoff is Monday, February 3rd at 23:59

IETF 107
Vancouver, Canada
March 21-27, 2020
Hosted By: Huawei

IETF 107 Information: https://www.ietf.org/how/meetings/107/
Register online at: https://ietf.org/how/meetings/register/

1.  Registration
2.  Visas & Letters of Invitation
3.  Accommodations
4.  Code Sprint
5.  Hackathon

1. Registration:

Early Bird Deadline

The early bird deadline for registration is Monday, February 3rd.
Be sure to register and pay before the deadline passes!
Register online at: https://www.ietf.org/how/meetings/register/

NOTE: If you have started the registration process but not completed
payment, your registration record will be deleted at UTC 23:59 on
February 3rd. After February 3rd at UTC 23:59 you will be required to
re-enter your data and the registration fee will be $875 USD until
the next registration deadline on March 9th, at which the
registration fee will become $1,000 USD.

2. Visas & Letters of Invitation:

   NOTE: If you require a visa for IETF 107, please request a letter of
invitation immediately and begin the application process. The IETF
is providing the letter of invitation for IETF 107. If you
experience issues using this letter to obtain a visa, please contact
regist...@ietf.org immediately for assistance.

If you’ve previously attended an IETF meeting, you can request a
letter of invitation here: 
https://www.ietf.org/registration/letterofinvite/singleletter.py


3.  Accommodations:

  NOTE: Daily Breakfast is NOT included with any IETF hotel rates below.

1. Hyatt Regency Vancouver - Meeting Venue (Headquarters Hotel, block of 450 
rooms)
Room Rate: $249 CAD (single/double)
Room Rates DO NOT include daily breakfast.
Room rate includes in-room high-speed Internet access and health club benefits.
Taxes of 5% GST, 8% PST, 3% Occupancy, and 1.5% Destination Fee (subject to 
change)
are excluded in the above rate. Taxes subject to change without notice.
Reservation Cutoff Date: 02 March 2020
Cancel with No Penalty: 3 days prior to check-in/arrival
Distance to Meeting Venue: N/A
Reservations: https://tinyurl.com/107HYATT

Overflow Hotel:

2. Sutton Place Hotel - (Overflow Hotel, block of 200 rooms)
Room Rate: $230 CAD (single) $250 CAD (double)
Room Rates DO NOT include daily breakfast.
Room Rate includes in-room high-speed Internet access and complimentary access
to in-house Business Center and Fitness Center.
Lodging taxes of 12.5% and GST of 5% are not included in the above rate
and are subject to change.
Reservation Cutoff Date: 06 March 2020
Cancel with No Penalty: 72 hours prior to check-in/arrival
Distance to Meeting Venue: 350 meters (5 minute walk)
Reservations: https://tinyurl.com/107SUTTON

3. Metropolitan Hotel - (Overflow Hotel, block of 23 rooms)
Room Rate: $229 CAD (single/double)
Room Rates DO NOT include daily breakfast.
Room Rate includes in-room high speed internet access and to Hotel Business 
Center,
Fitness area, pools and saunas.
   Lodging rates of 11% and GST 5% (subject to change) are not included
   in the above rate.
Reservation Cutoff Date: 26 February 2020
Cancel with No Penalty: 72 hours prior to check-in/arrival
Distance to Meeting Venue: 350 meters (5 minute walk)
Reservations: https://tinyurl.com/107METROPOLITAN

4. Coast Coal Harbour Hotel - (Overflow Hotel, block of 50 rooms)
Room Rate: $195 CAD (single/double)
Room Rates DO NOT include daily breakfast.
Room Rate includes in-room high speed internet and access to Hotel Business 
Center,
Fitness area, pools and whirlpool.
Lodging taxes of 17.5% (subject to change) are not included in Room Rate.
Reservation Cutoff Date: 26 February 2020
Cancel with No Penalty: 72 Hour prior to check in (Non-refundable 1 night 
deposit)
Distance to Meeting Venue: 350 meters (5 minute walk)
Reservations: https://tinyurl.com/107COASTCOAL


5. Fairmont Hotel Vancouver - (Overflow Hotel, Based on overall hotel 
availability)
Room Rate: $249 CAD (single/double)
Room Rates DO NOT include daily breakfast.
   Room Rate includes complimentary in-room internet.
Municipal Hotel Tax 11%, GST 5% and Destination Marketing Fee Tax of 1.5% are 
not
   included in the above room rate. Taxes subject to change without notice.
Reservation Cutoff Date: N/A
Cancel with No Penalty: 48 Hour prior to check in/ arrival (Non-refundable 1 
night deposit)
Distance to Meeting Venue: 650 meters (9 minute walk)
Reservations: https://tinyurl.com/107FAIRMONT


More details at: htt

Re: [6tisch] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06

[Pascal Thubert (pthubert)]

Hello Michael 

I agree with the format you selected, things are readable this way.
There are 2 or 3 typos in the new text that can be fixed with the editor.
Also I’m happy with the conclusions you made on the possible attacks.

All the best,

Pascal

> Le 22 janv. 2020 à 23:21, Michael Richardson  a écrit :
> 
> 
> https://www.ietf.org/rfcdiff?url1=draft-ietf-6tisch-enrollment-enhanced-beacon-08&url2=draft-ietf-6tisch-enrollment-enhanced-beacon-09
> 
> I have interspersed the security issues with each of the fields within the
> description of the fields in section 2.  This avoids enumerating the fields a
> second time, and is probably more in the face for implementers.
> This also makes it easier to review and avoids repeating what each field is.
> 
> On the other hand, it may a poor way to present this.
> 
> I am asking for the WG's opinion on whether to do it this way, or move it all
> to the Security Considerations section.
> 
> -- 
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works|IoT architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 
> 
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] New Version Notification for draft-karaagac-6tisch-int-00.txt

[Pascal Thubert (pthubert)]

Hello Yatch : )


> 
> I have comments, some of which Pascal's email covers, though.
> 
> - L3 seems a better place to implement such a mechanism than L2. L2 has no 
> idea whether the packet (frame) under process is going toward the border 
> router nor not. 

True, at L3 we could sign end to end. 

On the other hand it is hard to inject headers on the fly at L3 l, you have to 
do IP in IP. The IE technique avoids that problem.

In non storing all packets reach the root so I guess the proposal has a wide 
domain of applicability.

Take care,

Pascal 
> -Original Message-
>> 
>> From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Pascal Thubert
>> (pthubert)
>> Sent: Tuesday, January 14, 2020 10:11 PM
>> To: Abdulkadir Karaağaç (UGent-imec) ;
>> 6tisch@ietf.org
>> Subject: Re: [6tisch] New Version Notification for
>> draft-karaagac-6tisch-int-00.txt
>> 
>> Dear authors
>> 
>> This draft strikes me as very mature for a 00, and a very useful piece of 
>> work as
>> well.
>> It looks like you have implemented and tried it out already, correct?
>> 
>> A few comments and questions:
>> 
>> * Since you are using IEs Fig 1 could represent the insertion before the IPv6
>> payload.
>> * There could be a Fig describing the typical format of the inserted IE at 
>> the end
>> of 2.2
>> * A discussion on the chances of loss that are augmented as the frame are
>> enlarged could be useful in the intro
>> * A discussion of the INT header used as a hidden channel could be useful in
>> the security section
>> * It seems that the data can only be reported on packets that are going
>> outwards. You may want to indicate that in a classical non-storing network
>> with the root acting as backbone router, all packets fly through the 6BBR and
>> can be instrumented.
>> * Because of the Q bit it seems that the INT IE is also used in packets going
>> down: the source routing header may make it complicated to instrument such
>> packets. More description on the operation and size of inserted header in
>> downwards packets could be useful. Maybe we could make the query a
>> different IE altogether and save the Q bit for the future.
>> * If the telemetry relates to a transmission by a child, then the node ID is 
>> not
>> enough to identify the link since the child has multiple parents.
>> * Apparently in HbH mode 1 only the first nodes may insert data if the 
>> network
>> is deep and the room limited.
>> * In HbH mode 2, how do we balance the use of the space so that all hops have
>> an equal chance to report their information? Is that what 2.3.1 is all about?
>> * In section 2.3
>> ** I believe that if nodes use different strategies some may starve. Like 
>> for the
>> objective function, there should be a single strategy, that may have to be 
>> tuned
>> for the shape of the network.
>> ** in 2.3.1 if all nodes source traffic and not only the deepest ones, 
>> actually the
>> nodes near the root may have more opportunities, it really depends on the
>> shape of the network.
>> ** in 2.3.2 we seem to assume that only nodes deep in the network source
>> packets. In reality, say that there can be 3 values stored, then the number 
>> of
>> chances is proportional to the number of children and grandchildren, and
>> nodes deep in the network may have less of these.
>> ** it could be good that a node that refrains to insert redundant 
>> information may
>> still indicate that already sent information (sequence) is unchanged. Along
>> that line of thought how do we handle loss? A same sequence sent several
>> times?
>> * Security section should indicate that the payload IE is modified at each 
>> hop
>> and there is no guarantee that the original information is preserved
>> 
>> Great work!
>> 
>> Pascal
>> 
>> 
>> 
>> 
>> 
>>> -Original Message-
>>> From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Abdulkadir
>>> Karaagaç
>>> (UGent-imec)
>>> Sent: mardi 14 janvier 2020 10:43
>>> To: 6tisch@ietf.org
>>> Subject: [6tisch] FW: New Version Notification for
>>> draft-karaagac-6tisch-int- 00.txt
>>> 
>>> Dear all,
>>> We have submitted a new draft describing an efficient and timely
>>> monitoring solution for 6TiSCH Networks. We believe that this
>>> mechanism can become a very powerful tool for 6TiSCH Networks with the
>>> contribution of the 6TiSCH community.
>>> 
>>> All kinds of feedback and co

Re: [6tisch] New Version Notification for draft-karaagac-6tisch-int-00.txt

[Pascal Thubert (pthubert)]

Dear authors

This draft strikes me as very mature for a 00, and a very useful piece of work 
as well.
It looks like you have implemented and tried it out already, correct?

A few comments and questions:

* Since you are using IEs Fig 1 could represent the insertion before the IPv6 
payload.
* There could be a Fig describing the typical format of the inserted IE at the 
end of 2.2
* A discussion on the chances of loss that are augmented as the frame are 
enlarged could be useful in the intro
* A discussion of the INT header used as a hidden channel could be useful in 
the security section
* It seems that the data can only be reported on packets that are going 
outwards. You may want to indicate that in a classical non-storing network with 
the root acting as backbone router, all packets fly through the 6BBR and can be 
instrumented. 
* Because of the Q bit it seems that the INT IE is also used in packets going 
down: the source routing header may make it complicated to instrument such 
packets. More description on the operation and size of inserted header in 
downwards packets could be useful. Maybe we could make the query a different IE 
altogether and save the Q bit for the future. 
* If the telemetry relates to a transmission by a child, then the node ID is 
not enough to identify the link since the child has multiple parents.
* Apparently in HbH mode 1 only the first nodes may insert data if the network 
is deep and the room limited. 
* In HbH mode 2, how do we balance the use of the space so that all hops have 
an equal chance to report their information? Is that what 2.3.1 is all about? 
* In section 2.3 
** I believe that if nodes use different strategies some may starve. Like for 
the objective function, there should be a single strategy, that may have to be 
tuned for the shape of the network. 
** in 2.3.1 if all nodes source traffic and not only the deepest ones, actually 
the nodes near the root may have more opportunities, it really depends on the 
shape of the network.
** in 2.3.2 we seem to assume that only nodes deep in the network source 
packets. In reality, say that there can be 3 values stored, then the number of 
chances is proportional to the number of children and grandchildren, and nodes 
deep in the network may have less of these.
** it could be good that a node that refrains to insert redundant information 
may still indicate that already sent information (sequence) is unchanged. Along 
that line of thought how do we handle loss? A same sequence sent several times?
* Security section should indicate that the payload IE is modified at each hop 
and there is no guarantee that the original information is preserved

Great work!

Pascal





> -Original Message-
> From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Abdulkadir Karaagaç
> (UGent-imec)
> Sent: mardi 14 janvier 2020 10:43
> To: 6tisch@ietf.org
> Subject: [6tisch] FW: New Version Notification for draft-karaagac-6tisch-int-
> 00.txt
> 
> Dear all,
> We have submitted a new draft describing an efficient and timely monitoring
> solution for 6TiSCH Networks. We believe that this mechanism can become a
> very powerful tool for 6TiSCH Networks with the contribution of the 6TiSCH
> community.
> 
> All kinds of feedback and comments are very welcome. Thanks a lot!
> 
> Kind regards,
> Abdulkadir
> 
> 
> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Saturday, January 11, 2020 23:21
> To: Jeroen Hoebeke (UGent-imec) ; Abdulkadir
> Karaağaç (UGent-imec) 
> Subject: New Version Notification for draft-karaagac-6tisch-int-00.txt
> 
> 
> A new version of I-D, draft-karaagac-6tisch-int-00.txt has been successfully
> submitted by Abdulkadir Karaagac and posted to the IETF repository.
> 
> Name: draft-karaagac-6tisch-int
> Revision: 00
> Title:In-band Network Telemetry for 6TiSCH Networks
> Document date:2020-01-11
> Group:Individual Submission
> Pages:14
> URL:
> https://www.ietf.org/internet-drafts/draft-karaagac-6tisch-int-
> 00.txt
> Status: https://datatracker.ietf.org/doc/draft-karaagac-6tisch-int/
> Htmlized:   https://tools.ietf.org/html/draft-karaagac-6tisch-int-00
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-karaagac-6tisch-int
> 
> 
> Abstract:
>This document describes In-band Network Telemetry for 6TiSCH
>Networks, offering a flexible monitoring solution with minimal
>resource consumption and communication overhead while supporting a
>wide range of monitoring operations and strategies for dealing with
>various network scenarios and use cases.  It enables 6TiSCH networks
>to collect per-packet and per-hop monitoring information by
>piggybacking telemetry information onto the data packets by
>exploiting the remaining space in the IEEE 802.15.4e frames, thus not
>impacting network behavior and performance.  This document also
>discusses the data fields a

Re: [6tisch] WGLC on draft-ietf-6tisch-msf-09

[Pascal Thubert (pthubert)]

My issues seem resolved Tengfei

I’ll make a pass tomorrow and if / when I get all the authors to answer me on 
the IPR I’ll make the publication request.


Regards,

Pascal

Le 12 déc. 2019 à 18:29, Tengfei Chang  a écrit :


Hi All,

As you may notice that the  draft-ietf-6tisch-msf-09  is just published.
We believe it resolved the comments mostly from Yatch and Pascal's review. 
(Thanks a lot for those comments again!)

Yatch, Pascal, could you confirm they does resolve the issues?
Also anyone else is more than welcome to review and put comments!

Regards,
Tengfei



--
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] hepherd write up for draft-ietf-6tisch-msf: IPR statement

[Pascal Thubert (pthubert)]

Dear all

It is time to publish draft-ietf-6tisch-msf, and as part of the process I need 
to confirm whether there is IPR on this specification.

Authors: please confirm whether any and all appropriate IPR disclosures 
required for full conformance with the provisions of BCP 78 and BCP 79 have 
already been filed. If not, explain why. You may for instance answer with "I'm 
not aware of any IPR that applies to this draft" or indicate a link to an IETF 
disclosure.

Others: If you are aware of IPR that encumbers this draft, please reply to this 
mail with relevant information.


Note that there's oner disclosure against the draft already 
(https://datatracker.ietf.org/ipr/3270/). The title of the IPR disclosure is 
"Cisco's Statement about IPR related to draft-ietf-6tisch-msf"

Many thanks

Pascal

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF adapts to traffic only for secured packets

[Pascal Thubert (pthubert)]

A nit Tengfei :

« before it is  passed to MSF. “
Would be
“before it is passed to the 6top sublayer where MSF can observe it.” Or 
something similar?

Otherwise, all good!

Pascal

From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Tengfei Chang
Sent: jeudi 12 décembre 2019 17:51
To: 6tisch <6tisch@ietf.org>
Subject: Re: [6tisch] MSF adapts to traffic only for secured packets

All,

The following is our internal discuss about this issue.

We will add the following text in "Security Consideration " section in MSF-09:

   MSF adapts to traffics containing packets from IP layer.  It is
   possible that the IP packet has a non-zero DSCP (Diffserv Code Point
   [RFC2597]) value in its IPv6 header.  The decision whether to hand
   over that packet to MAC layer to transmit or to drop that packet
   belongs to the upper layer and is out of scope of MSF.  As long as
   the decision is made to hand over to MAC layer to transmit, MSF will
   take that packet into account when adapting to traffic.

   Note that non-zero DSCP value may imply that the traffic is
   originated at unauthenticated pledges, referring to
   [I-D.ietf-6tisch-minimal-security].  The implementation at IPv6 layer
   SHOULD ensure that this join traffic is rate-limited before it is
   passed to MSF.  In case there is no rate limit for join traffic,
   intermediate nodes in the 6TiSCH network may be prone to a resource
   exhaustion attack, with the attacker injecting unauthenticated
   traffic from the network edge.  The assumption is that the rate
   limiting function is aware of the available bandwidth in the 6top L3
   bundle(s) towards a next hop, not directly from MSF, but from an
   interaction with the 6top sublayer that manages ultimately the
   bundles under MSF's guidance.  How this rate limit is set is out of
   scope of MSF.




On Thu, Dec 12, 2019 at 5:26 PM Tengfei Chang 
mailto:tengfei.ch...@gmail.com>> wrote:
Thanks for the confirmation Yatch!

I will forward our discuss back to the mailing list for information.



On Thu, Dec 12, 2019 at 5:22 PM Yasuyuki Tanaka 
mailto:yasuyuki.tan...@inria.fr>> wrote:
Thank you, all.

The proposed text looks very good to me. It resolves my concerns.

Best,
Yatch

On 12/12/2019 6:01 AM, Tengfei Chang wrote:
> Cool!  Thanks for the additional info! Integrated as well!
>
> On Thu, Dec 12, 2019 at 4:55 PM Pascal Thubert (pthubert)
> mailto:pthub...@cisco.com> 
> <mailto:pthub...@cisco.com<mailto:pthub...@cisco.com>>> wrote:
>
> Hello again
>
>
>  > Note that non-zero DSCP value may imply that the traffic is
> originated at unauthenticated pledges, see {{minimal-security}}.
>  > The implementation at IPv6 layer SHOULD ensure that this join
> traffic is rate-limited before it is passed to MSF.
>  > In case there is no rate limit for join traffic, intermediate
> nodes in the 6TiSCH network may be prone to a resource exhaustion
> attack, with the attacker injecting unauthenticated traffic from the
> network edge.
>  > How this rate limit is set is out of scope of MSF.
>
> This would be a nice addition to the security section : )
>
> Note that the upper layer can only do load control if it is aware of
> the amount of bandwidth that the current bundles provide. 6top
> knows. So either 6top does the whole rate limiting, or there is an
> interface between the IP layer and 6top, that is not described, even
> in the architecture.
>
> The idea was to describe all this in
> https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer but that
> will probably not happen anytime soon.
>
> So maybe complementing Malisa's text as follows:
>
> ."
> Note that non-zero DSCP value may imply that the traffic is
> originated at unauthenticated pledges, see {{minimal-security}}.
> The implementation at IPv6 layer SHOULD ensure that this join
> traffic is rate-limited before it is passed to MSF.
> In case there is no rate limit for join traffic, intermediate nodes
> in the 6TiSCH network may be prone to a resource exhaustion attack,
> with the attacker injecting unauthenticated traffic from the network
> edge.
> The assumption is that the rate limiting function is aware of the
> available bandwidth in the 6top L3 bundle(s) towards a next hop, not
> directly from MSF, but from an interaction with the 6top sublayer
> that manages ultimately the bundles under MSF's guidance. How this
> rate limit is set is out of scope of MSF.
> "
>
> Pascal
>
>
> On Wed, Dec 11, 2019 at 6:03 PM Yasuyuki Tanaka
> <mailto:yasuyuki.tan...@inria.fr<mailto:yasuyuki.tan...@inria.fr> 
> <mailto:yasuyuki.tan...@inria.fr<mailto:ya

[6tisch] Fwd: Protocol Action: 'Constrained Join Protocol (CoJP) for 6TiSCH' to Proposed Standard (draft-ietf-6tisch-minimal-security-15.txt)

[Pascal Thubert (pthubert)]

Malisa and all: great work and congrats!!!

Pascal

Début du message transféré :

Expéditeur: The IESG 
Date: 11 décembre 2019 à 21:09:50 UTC+1
Destinataire: IETF-Announce 
Cc: The IESG , "Pascal Thubert (pthubert)" , 
"Pascal Thubert (pthubert)" , "6tisch-cha...@ietf.org" 
<6tisch-cha...@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, 
"draft-ietf-6tisch-minimal-secur...@ietf.org" 
, "sur...@kaloom.com" 
, "rfc-edi...@rfc-editor.org" 
Objet: Protocol Action: 'Constrained Join Protocol (CoJP) for 6TiSCH' to 
Proposed Standard (draft-ietf-6tisch-minimal-security-15.txt)

The IESG has approved the following document:
- 'Constrained Join Protocol (CoJP) for 6TiSCH'
 (draft-ietf-6tisch-minimal-security-15.txt) as Proposed Standard

This document is the product of the IPv6 over the TSCH mode of IEEE 802.15.4e
Working Group.

The IESG contact persons are Éric Vyncke and Suresh Krishnan.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/





Technical Summary

  This document describes a new Constrained Join Protocol (CoJP) and the
  associated framework required for a new device, called "pledge", to
  securely join a 6TiSCH network by leveraging a central server, the JRC.
  The framework requires that the pledge and the JRC share a symmetric key
  before the join process starts (pre-shared key). How this key is
  provisioned is out of scope of this document.

  Through a single CoAP request-response exchange secured by OSCORE, the
  pledge requests admission into the network and the JRC configures it
  with link-layer keying material and other parameters.

  Join Request and Join Response messages defined for this purpose are to
  be used as a generic transport based on CoAP for AKE messages between
  the pledge and the JRC, through a Join Proxy. This enables bidirectional
  communication of the pledge and the JRC, triggered by the pledge.

  What AKE transports within those messages is not very relevant,
  be it PSK, RPK or cert-authenticated DH. Once AKE completes and a
  shared secret is in place at the pledge and the JRC, the join exchange
  from this draft can take place, secured with OSCORE keys derived from
  the shared secret.

Working Group Summary

  There was a controversy on OSCORE that this draft uses. OSCORE is now
  approved by IESG. The draft does not have a dependency on EDHOC.
  The chairs launched a second shorted WGLC after IETF 103.
  More in https://www.mail-archive.com/6tisch@ietf.org/msg02875.html.
  Issues raised by Göran Selander are now solved in -10
  More in https://www.mail-archive.com/6tisch@ietf.org/msg02973.html

Document Quality

 The protocol is implemented in OpenWSN.

Personnel

 Pascal Thubert is the Document Shepherd. Suresh Krishnan is the Responsible 
Area Director.
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF Shepherd review

[Pascal Thubert (pthubert)]

Very good Tengfei

This addresses my comments.

Note that the uppercase NOT is not a valid BCP14 term by itself. I’d reword to 
say that the distribution of traffic over multiple parents is a routing 
decision that is out of scope for MSF...


Regards,

Pascal

Le 6 déc. 2019 à 12:01, Tengfei Chang  a écrit :


I will add the following text at the intro part of MSF draft:

MSF works closely with RPL, specifically the routing parent 
defined in .
This specification only describes how MSF works with one 
routing parent, which is phrased as "selected parent".
The activity of MSF towards to single routing parent is called 
as a "MSF session".
Though the performance of MSF is evaluated only when the 
"selected parent" represents node's preferred parent, there should be no 
restrictions to go multiple MSF sessions, one per parent.
In case that traffic goes into multiple parents, MSF is NOT in 
charge of deciding how many traffic to assign or to which parent.
This should be decided by either upper layer or some other 
entity in charge of traffic distributing.

Then replace the sentence in the draft from "preferred parent" to "selected 
parent".

What are your comments on this, Pascal, Yatch?

On Sat, Nov 30, 2019 at 12:31 AM Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:
Hello Yatch



> Le 29 nov. 2019 à 22:48, Yasuyuki Tanaka 
> mailto:yasuyuki.tan...@inria.fr>> a écrit :
>
> Thank you, Pascal for your comment.
>
>> On 11/29/2019 9:34 PM, Pascal Thubert (pthubert) wrote:
>> RPL underneath is designed to operate with multiple parents, and for a good 
>> reason.
>
> I understand that point.
>
> My point is, rephrasing the word alone couldn't be enough.
>
>> Bandwidth allocation doesn’t care what traffic that is or it’s direction. It 
>> cares about the amount of traffic that needs to circulate over the hop.
>
> In general, yes. According to the current text of MSF, the direction is 
> relevant. For a upward neighbor, MSF allocates one negotiated TX cell just 
> after recognizing it. For a downward neighbor, it doesn't.
>
> On parent switch, the number of negotiated cells is carried over to a new 
> parent. But what if a node has one parents at some point, then it selects an 
> additional parent to handle some portion of traffic? How many negotiated 
> cells should be scheduled with the new (additional) parent? MSF would have no 
> idea.
>
> To me, this seems a totally new thing to MSF.
>

Not that new just the logical continuation.

If a child has 2 parents a and b these are independent links, each with a 
number of cells. If it loses one parent a then the traffic on that link is 
rerouted. The cells on that link have to be moved to other parents which can 
include b.

The existing cells to the parent b are not touched. If some traffic is rerouted 
to parent b then new cells are allocated there.


> Again, having multiple MSF instances could be a solution, which doesn't need 
> the rephrasing.

For me instance is related to RPL I do not want to run multiple instances of 
RPL with one preferred parent each.

What I want is to run what the draft describes but several times in parallel 
once per active parent.

That’s what I called session. RPL says that a node can run separate instances 
like ship in the night and then describes the operw of one instance. Similarly 
MSF can run multiple sessions one per link as ship in the night. pretty much 
the draft needs to do is say that in introduction and then say that the rest of 
the draft describes one session with one parent.

>> And it is possible to run an MSF session at L2 with each of them totally 
>> independently.
>
> What do you mean by "MSF session"? If you have multiple MSF instances with 
> different SFIDs or values for the Metadata field, they can be associated with 
> different RPL DODAGsm and they will work independently.
>

The draft describes a session between a parent and a child. They start the 
session, allocate resources in unison and when the session is broken they 
release the resources on each side. This happens within a L2 link. Sessions can 
live independently on different L2 links.



> On 11/29/2019 9:40 PM, Prof. Diego Dujovne wrote:
> > Would it be then a neighbour instead of a parent? (Assuming the
> > neighbour has joined the network)
>
> I don't think so.
>

As Yatch said the draft describes a child handling both sides so the link is 
directional, there’s a master and a slave.

This may become a problem for east west traffic with PDAO. But there’s still a 
direction so it’s doable just need to agree that the parent is towards the 
destination.

All the best,

Pascal


> Best

Re: [6tisch] MSF adapts to traffic only for secured packets

[Pascal Thubert (pthubert)]

Yes I do


Regards,

Pascal

Le 6 déc. 2019 à 09:49, Tengfei Chang  a écrit :


Pascal,

Yes, MSF indeed aware of the routing information such as RPL parent, I consider 
this is like an information stored at IPv6 layer that MSF can read it from 
without touching the frame L2 payload.
In such sense, I could consider the DSCP value can be another information 
stored at upper layer that MSF have read access to it.

Thinking in this way, it seems OK for me.
Do you agree such interpreting?

Tengfei

On Thu, Dec 5, 2019 at 5:50 PM Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:
Hello Tengfei

Architecturally speaking, MSF right now is used to allocate cells in the L3 
bundle with a parent.

“

Layer-2 vs. Layer-3 bundle:
Bundles are associated for either Layer-2 (switching) or Layer-3 (routing) 
forwarding operations. A pair of Layer-3 bundles (one for each direction) maps 
to an IP Link with a neighbor, whereas a set of Layer-2 bundles (of an 
"arbitrary" cardinality and direction) corresponds to the relation of one or 
more incoming bundle(s) from the previous-hop neighbor(s) with one or more 
outgoing bundle(s) to the next-hop neighbor(s) along a Track as part of the 
switching role, which may include replication and elimination


“

So even if it is operating under IP, it is working for IP. Even the notion that 
the neighbor is a parent is an IP layer consideration. So MSF is IPv6-aware.
IOW the IP layer passes an IP packet to the lower layer (6top), and 6top needs 
to assign the packet to a bundle. Once that is done, if the bundle is managed 
by MSF, then MSF observes the transmission. Same goes for incoming traffic.

Do you want me to provide the sentences or do you feel safe about putting your 
own words?


From: 6tisch <6tisch-boun...@ietf.org<mailto:6tisch-boun...@ietf.org>> On 
Behalf Of Tengfei Chang
Sent: jeudi 5 décembre 2019 08:18
To: 6tisch <6tisch@ietf.org<mailto:6tisch@ietf.org>>
Subject: [6tisch] MSF adapts to traffic only for secured packets

Hi All,

For securing the MSF, (comments from minimal security, thanks for the input!)

In the next version of MSF, we need to add sentence saying MSF only adapts the 
traffic which is secured, practically by checking the DSCP value set with zero 
or no, which is in IPv6 header.

In other hands, MSF is a link layer protocol, it doesn't suppose to know the 
frame is a IPv6 packet or not. no need to say a field value.

I would like to have some suggestions/comments on this issue.
Does anyone know other way to make the SF not adapt to unsecured traffic 
without knowing upper layer field?

Thanks!
Tengfei
--
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/<http://www.tchang.org/>
——


--
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/<http://www.tchang.org/>
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF adapts to traffic only for secured packets

[Pascal Thubert (pthubert)]

Hello Tengfei

Architecturally speaking, MSF right now is used to allocate cells in the L3 
bundle with a parent.

“

Layer-2 vs. Layer-3 bundle:
Bundles are associated for either Layer-2 (switching) or Layer-3 (routing) 
forwarding operations. A pair of Layer-3 bundles (one for each direction) maps 
to an IP Link with a neighbor, whereas a set of Layer-2 bundles (of an 
"arbitrary" cardinality and direction) corresponds to the relation of one or 
more incoming bundle(s) from the previous-hop neighbor(s) with one or more 
outgoing bundle(s) to the next-hop neighbor(s) along a Track as part of the 
switching role, which may include replication and elimination


“

So even if it is operating under IP, it is working for IP. Even the notion that 
the neighbor is a parent is an IP layer consideration. So MSF is IPv6-aware.
IOW the IP layer passes an IP packet to the lower layer (6top), and 6top needs 
to assign the packet to a bundle. Once that is done, if the bundle is managed 
by MSF, then MSF observes the transmission. Same goes for incoming traffic.

Do you want me to provide the sentences or do you feel safe about putting your 
own words?


From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Tengfei Chang
Sent: jeudi 5 décembre 2019 08:18
To: 6tisch <6tisch@ietf.org>
Subject: [6tisch] MSF adapts to traffic only for secured packets

Hi All,

For securing the MSF, (comments from minimal security, thanks for the input!)

In the next version of MSF, we need to add sentence saying MSF only adapts the 
traffic which is secured, practically by checking the DSCP value set with zero 
or no, which is in IPv6 header.

In other hands, MSF is a link layer protocol, it doesn't suppose to know the 
frame is a IPv6 packet or not. no need to say a field value.

I would like to have some suggestions/comments on this issue.
Does anyone know other way to make the SF not adapt to unsecured traffic 
without knowing upper layer field?

Thanks!
Tengfei
--
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

Regards,

Pascal

> Le 5 déc. 2019 à 04:06, Mirja Kuehlewind  a écrit :
> 
> Hi Michael,
> 
> Sorry for my late reply (but I guess you could have just went ahead and push 
> a new version anyway…). Please see below.
> 
>>> On 1. Nov 2019, at 22:15, Michael Richardson  wrote:
>>> 
>>> 
>>> <#secure method=pgpmime mode=sign>
>>> 
>>> Mirja Kühlewind via Datatracker  wrote:
>>> 1) I hope this point can be resolved quickly as it seems to only need a
>>> bit more specifics but I think this part is not sufficient:
>> 
>>> Sec 6.1: "The Join Proxy implements a data cap on outgoing join traffic
>>> through CoAP's congestion control mechanism."
>> 
>>> I think this needs an normative requirement here. Congestion control is
>>> supposed to avoid network overload but also to make use available
>>> resources.  The congestion control as currently defined for CoAP would
>>> probably limit the join traffic appropriately (to something like one
>>> packet per RTT likely) but CoAP could in theory use any time a
>>> different more aggrieve congestion and therefore just relying on
>>> congestion control generically doesn't seem to be sufficient.
>> 
>>> I
>>> recommend to define a hard limit, e.g. 1 packet per RTT or 1 packet per
>>> 3 seconds if RTT is unknown (as recommended in RFC8085) and say that
>>> this can be achieved by congestion control as specified in the base
>>> CoAP spec.
>> 
>> okay, how about:
>> 
>> + The Join Proxy implements a data cap on outgoing join traffic by 
>> implementing
>> + the  section 3.1.3 recommendation of 1 packet per 
>> 3
>> + seconds.
>> + This can be achieved with the congestion control mechanism specified
>> + in  section 4.7.
> 
> Great! Thanks!
> 
>> 
>> 
>>> Further on there seems to be an implicit requirement that
>>> the JP MUST implement rate limit using the PROBING_RATE parameter,
>>> however, that is never explicitly spelled out as a normative
>>> requirement. However, if this rate is not provided by the JRC, it
>>> doesn't seem that any rate limiting has to be enforced. So maybe it
>>> would be good to be more strict here.
>> 
>> I think you are saying that we should have a default PROBING_RATE, if the JRC
>> does not specify one.  I think that we assumed that the RFC7257 section 4.8
>> value of 1 byte/second would apply. please confirm?
> 
> Yes, stating this explicitly would be good!
> 
>> 
>>> 2) Also, not sure if this editorial or a real issue but I'm not sure I
>>> fully understand this sentence:
>> 
>>> Sec 6.1.1: "A Join Proxy that does not set the DSCP on traffic
>>> forwarded should set it to zero so that it is compressed out."  If the
>>> proxy does NOT SET DSCP, why should it SET it to zero?
>> 
>> Because RFC6282 (and friends) has specific encoding to omit DSCP if it is 
>> zero.
> 
> I understand what you want to do but saying “does not set” but “should set” 
> seems to be contracting. I think this is only a wording issue though. I guess 
> it could be something like this:
> 
> "A Join Proxy that does not require a specific DSCP value on traffic
> forwarded should set it to zero so that it is compressed out.”
> 
> 
>> 
>>> I would think it
>>> either sets it to AF43 or it does nothing about it because DSCP is not
>>> really used in that network.
>> 
>> In 6tisch networks, different DSCP points can be used to get different
>> behaviours, see  UHM. Let me get back to you on this, because the
>> reference has evaporated.
> 
> A reference would be good (in the draft) :-)
> 
>> 
>>> 3) This may also be mostly editorial but just to be sure: Section 7.2
>>> provides default values for some of the CoAP transport parameter (where
>>> 2 of 3 are the same as defined in RFC7252) but not for all. Why is
>>> that?
>> 
>> We got pushback about relying on 7252 defaults, because what if they changed.
> 
> That’s fine but the you need to add all values!
> 
>> 
>>> 4 ) And then finally on references (again): Given that use of
>>> I-D.ietf-core-stateless is recommend, I believe it should be normative
>>> (and wait for publication of that doc).
>> 
>> I guess since it's a MUST for the JRC, we need to do that.
> 
> Good. Thanks!
> 
> 
>> 
>>> --
>>> COMMENT:
>>> --
>> 
>>> I'm putting this one question in the comments section because there is
>>> no concern that it does not work as specified but I wonder about the
>>> design of the Parameter Update Response Message. Given the Parameter
>>> Update Message is a confirmable CoAP message that is transmitted
>>> reliable and the content of the Parameter Update Response Message is
>>> empty, why do you need to send the Parameter Update Response Message at
>>> all?
>> 
>>> And some minor comments (mostly editorial proposals):
>> 
>>> 0) I'd recommend to "Constrained Join Protocol (CoJP)" in the document
>>> title to make clear that this is a protocol spec and not "only" and
>>> abstract framework or s

Re: [6tisch] MSF Shepherd review

[Pascal Thubert (pthubert)]

Hello Yatch



> Le 29 nov. 2019 à 22:48, Yasuyuki Tanaka  a écrit :
> 
> Thank you, Pascal for your comment.
> 
>> On 11/29/2019 9:34 PM, Pascal Thubert (pthubert) wrote:
>> RPL underneath is designed to operate with multiple parents, and for a good 
>> reason.
> 
> I understand that point.
> 
> My point is, rephrasing the word alone couldn't be enough.
> 
>> Bandwidth allocation doesn’t care what traffic that is or it’s direction. It 
>> cares about the amount of traffic that needs to circulate over the hop.
> 
> In general, yes. According to the current text of MSF, the direction is 
> relevant. For a upward neighbor, MSF allocates one negotiated TX cell just 
> after recognizing it. For a downward neighbor, it doesn't.
> 
> On parent switch, the number of negotiated cells is carried over to a new 
> parent. But what if a node has one parents at some point, then it selects an 
> additional parent to handle some portion of traffic? How many negotiated 
> cells should be scheduled with the new (additional) parent? MSF would have no 
> idea.
> 
> To me, this seems a totally new thing to MSF.
> 

Not that new just the logical continuation. 

If a child has 2 parents a and b these are independent links, each with a 
number of cells. If it loses one parent a then the traffic on that link is 
rerouted. The cells on that link have to be moved to other parents which can 
include b. 

The existing cells to the parent b are not touched. If some traffic is rerouted 
to parent b then new cells are allocated there.


> Again, having multiple MSF instances could be a solution, which doesn't need 
> the rephrasing.

For me instance is related to RPL I do not want to run multiple instances of 
RPL with one preferred parent each.

What I want is to run what the draft describes but several times in parallel 
once per active parent.

That’s what I called session. RPL says that a node can run separate instances 
like ship in the night and then describes the operw of one instance. Similarly 
MSF can run multiple sessions one per link as ship in the night. pretty much 
the draft needs to do is say that in introduction and then say that the rest of 
the draft describes one session with one parent. 

>> And it is possible to run an MSF session at L2 with each of them totally 
>> independently.
> 
> What do you mean by "MSF session"? If you have multiple MSF instances with 
> different SFIDs or values for the Metadata field, they can be associated with 
> different RPL DODAGsm and they will work independently.
> 

The draft describes a session between a parent and a child. They start the 
session, allocate resources in unison and when the session is broken they 
release the resources on each side. This happens within a L2 link. Sessions can 
live independently on different L2 links.



> On 11/29/2019 9:40 PM, Prof. Diego Dujovne wrote:
> > Would it be then a neighbour instead of a parent? (Assuming the
> > neighbour has joined the network)
> 
> I don't think so.
> 

As Yatch said the draft describes a child handling both sides so the link is 
directional, there’s a master and a slave. 

This may become a problem for east west traffic with PDAO. But there’s still a 
direction so it’s doable just need to agree that the parent is towards the 
destination.

All the best,

Pascal 


> Best,
> Yatch
> 
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF Shepherd review

[Pascal Thubert (pthubert)]

Spot on Yatch

MSF manages the bandwidth over one L2 hop based on the packets that L3 places 
on that hop. 

Bandwidth allocation doesn’t care what traffic that is or it’s direction. It 
cares about the amount of traffic that needs to circulate over the hop.

The sense of direction came from the design decision that the child makes the 
request in both directions. That’s your design and that’s fine with me.

 But the child can have multiple L2 Links to different parents. Even if they 
use the same radio it is still as many links that live independent lives. And 
it is possible to run an MSF session at L2 with each of them totally 
independently.

Whether you already tested it is another topic. We do not need to test it 
immediately to progress the draft. But a draft that supports only one parent is 
not acceptable because it degrades the routing functionality too much. RPL 
underneath is designed to operate with multiple parents, and for a good reason. 

Regards,

Pascal

> Le 29 nov. 2019 à 20:41, Yasuyuki Tanaka  a écrit :
> 
> Hi Pascal,
> 
> pascal> My problem is that there’s only one preferred parent, but a
> pascal> node may use several parents for data traffic. This is why we
> pascal> build dodags in the first place.
> pascal>
> pascal> I believe that the node may allocate cells with all of those
> pascal> “selected parents” if it likes. The use of “preferred parent”
> pascal> in that text would prevent this.
> 
> I feel this scenario is outside of the scope of the *minimal*
> scheduling function. If I remember correctly, such a case hasn't been
> discussed nor evaluated with implementations.
> 
> The latest MSF spec may be able to be applied to the multiple parents
> case without any modification, or may not. We don't know because we'd
> not taken it into account. Regarding the multiple DODAGs case, a
> possible solution is having a separate MSF instance per DODAG, using a
> different SFID. Another idea is using the Metadata field to associate
> a 6P transaction with a DODAG.
> 
> In any case, I prefer having "the preferred parent" in the text,
> although "parent" sounds like a L3 term. L2 doesn't maintain
> parent-child relationships.
> 
> My two cents.
> 
> Best,
> Yatch
> 
> 
>> On 11/29/2019 4:23 PM, Pascal Thubert (pthubert) wrote:
>> Please do not call him preferred parent that’s something specific in RPL, 
>> the best parent for forwarding up the dodag.
>> Why not just say “the parent “ explaining that the 6P protocol can be used 
>> in parallel with multiple parents?
>> Regards,
>> Pascal
>>>> Le 29 nov. 2019 à 16:19, Tengfei Chang  a écrit :
>>> 
>>> 
>>> Hi Pascal,
>>> 
>>> For the preferred parent issue:
>>> 
>>> When running MSF, the node is deal with one parent at a time out of the 
>>> parent set, which we called preferred parent.
>>> It doesn't mean there is only one parent for each nodes.
>>> The node may change its preferred parent to other parent, which responded 
>>> in the switching_parent section in MSF.
>>> 
>>> For the sentence:
>>> 
>>>It is recommended to set MAX_NUMCELLS value at least 4x of the
>>>maximum link traffic load of the network with unit of packets per
>>>slotframe.
>>> 
>>> 
>>> The following example helps to understand the meaning:
>>> 
>>>For example, a 2 packets/slotframe traffic load results an average
>>>4 cells scheduled, using the value of double number of scheduled
>>>cells (which is 8) as MAX_NUM_CELLS gives a good resolution on
>>>cell usage calculation.
>>> 
>>> Any recommendation on the rephrasing?
>>> 
>>> Tengfei
>>> 
>>> 
>>> 
>>>> On Wed, Nov 27, 2019 at 10:07 PM Pascal Thubert (pthubert) 
>>>> mailto:pthub...@cisco.com>> wrote:
>>> 
>>>Hello Tengfei
>>> 
>>> 
>>>Please see below
>>> 
>>>>Le 27 nov. 2019 à 21:44, Tengfei Chang >>><mailto:tengfei.ch...@gmail.com>> a écrit :
>>>> 
>>>>
>>>>Thanks a lot for the reviewing, I responded inline:
>>>> 
>>>>On Mon, Nov 25, 2019 at 6:42 PM Pascal Thubert (pthubert)
>>>>mailto:pthub...@cisco.com>> wrote:
>>>> 
>>>>Dear all
>>>> 
>>>>__ __
>>>> 
>>>>Please find some comments below: 
>>>> 
>>>>__ __
>>>> 

Re: [6tisch] MSF Shepherd review

[Pascal Thubert (pthubert)]

Please do not call him preferred parent that’s something specific in RPL, the 
best parent for forwarding up the dodag.

Why not just say “the parent “ explaining that the 6P protocol can be used in 
parallel with multiple parents?


Regards,

Pascal

Le 29 nov. 2019 à 16:19, Tengfei Chang  a écrit :


Hi Pascal,

For the preferred parent issue:

When running MSF, the node is deal with one parent at a time out of the parent 
set, which we called preferred parent.
It doesn't mean there is only one parent for each nodes.
The node may change its preferred parent to other parent, which responded in 
the switching_parent section in MSF.

For the sentence:

It is recommended to set MAX_NUMCELLS value at least 4x of the maximum link 
traffic load of the network with unit of packets per slotframe.

The following example helps to understand the meaning:

For example, a 2 packets/slotframe traffic load results an average 4 cells 
scheduled, using the value of double number of scheduled cells (which is 8) as 
MAX_NUM_CELLS gives a good resolution on cell usage calculation.

Any recommendation on the rephrasing?

Tengfei



On Wed, Nov 27, 2019 at 10:07 PM Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:
Hello Tengfei


Please see below

Le 27 nov. 2019 à 21:44, Tengfei Chang 
mailto:tengfei.ch...@gmail.com>> a écrit :


Thanks a lot for the reviewing, I responded inline:

On Mon, Nov 25, 2019 at 6:42 PM Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:
Dear all

Please find some comments below:




Please migrate to XML2RFC v3. This will save time in the future.

TC: got it! Will used in version 9.

:)



   However, an implementor MAY implement MSF without implementing

   Minimal 6TiSCH Configuration.


This is not helpful without explanations. What is the tradeoff? How does the  
network operates in that case?

TC: Yes, the sentence is misleading. What we try to say is MSF can work with 
other specifications protocols, rather then minimal 6TiSCH configuration, as 
long as the protocols gives a way to communicate the EB and DIO among the 
network.


Those words in the draft will make me a happy shepherd...





For example, a Trickle Timer defined in

[RFC6550<https://tools.ietf.org/html/rfc6550>] MAY be applied on DIOs. However, 
this behavior is

implementation-specific which is out of the scope of MSF.



This is not for this spec to define. RPL already mandates trickle. Suggestion:


For example, the Trickle operation defined in [RFC6206]

is applied on DIO Messages [RFC6550<https://tools.ietf.org/html/rfc6550>]. This 
behavior is

out of the scope of MSF.



TC: agreed!





MSF RECOMMENDS the use of 3 slotframes.

Discussion on slotframes and cells comes without an introduction to TSCH.
I’d suggest you add a few words on RFC 7554 appendix A and 6TiSCH architecture 
section 4.3.5. to introduce those concepts.
They should probably be normative references.

TC: I added the following text at beginning of section 2:
In a TSCH network, time is sliced up into time slots.
The time slots are grouped as one of more slotframes which repeat 
over time.
The TSCH schedule instructs a node what to do at each time slots, 
such as transmit, receive or sleep .
In case of a slot to transmit or receive, a channel is assigned to 
the time slot.
The tuple (slot, channel) is indicated as a cell of TSCH schedule.
MSF is one of the policies defining how to manage the TSCH schedule.

Excellent




Section 4 has numerous SHOULD. Trouble is, when SHOULD is used, the author 
SHOULD explain the alternate, what if the SHOULD is not followed.
Sometimes it’s quite obvious, like when using random in 4.2. But SHOULD use 
minimal is less obvious. Please consider adding text after the SHOULDs.

TC: agreed!  I have resolved this SHOULD issues in a new version. either the 
unnecessaries are removed or alternative explanation is added

I’ll review once you published




   field it contains, the presence and contents of the IE defined in

   
[I-D.richardson-6tisch-join-enhanced-beacon<https://tools.ietf.org/html/draft-ietf-6tisch-msf-08#ref-I-D.richardson-6tisch-join-enhanced-beacon>],
 or the key used to

   authenticate it.

The reference is now draft-ietf.. I agree that it should be normative; no 
worries the draft is already submitted for publication.
More important: Please move the reference to 6tisch-dtsecurity-zerotouch-join 
to informational. This is a DOWNREF today and your draft may be stuck in 
MISSREF in the future.

TC: I have updated  richardson-6tisch-join-enhanced-beacon to  
ietf-6tisch-enrollment-enhanced-beacon.
I didn't get it how "move the reference to 6tisch-dtsecurity-zerotouch-join to 
informational" is done in the draft?


Sorry I was unclear. The draft is currently listed as a normative reference. 
This means that MSF will be held forever in miss ref at the R

Re: [6tisch] MSF Shepherd review

[Pascal Thubert (pthubert)]

Well my text was a proposal for rephrasing :)


Regards,

Pascal

Le 29 nov. 2019 à 16:19, Tengfei Chang  a écrit :


Hi Pascal,

For the preferred parent issue:

When running MSF, the node is deal with one parent at a time out of the parent 
set, which we called preferred parent.
It doesn't mean there is only one parent for each nodes.
The node may change its preferred parent to other parent, which responded in 
the switching_parent section in MSF.

For the sentence:

It is recommended to set MAX_NUMCELLS value at least 4x of the maximum link 
traffic load of the network with unit of packets per slotframe.

The following example helps to understand the meaning:

For example, a 2 packets/slotframe traffic load results an average 4 cells 
scheduled, using the value of double number of scheduled cells (which is 8) as 
MAX_NUM_CELLS gives a good resolution on cell usage calculation.

Any recommendation on the rephrasing?

Tengfei



On Wed, Nov 27, 2019 at 10:07 PM Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:
Hello Tengfei


Please see below

Le 27 nov. 2019 à 21:44, Tengfei Chang 
mailto:tengfei.ch...@gmail.com>> a écrit :


Thanks a lot for the reviewing, I responded inline:

On Mon, Nov 25, 2019 at 6:42 PM Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:
Dear all

Please find some comments below:




Please migrate to XML2RFC v3. This will save time in the future.

TC: got it! Will used in version 9.

:)



   However, an implementor MAY implement MSF without implementing

   Minimal 6TiSCH Configuration.


This is not helpful without explanations. What is the tradeoff? How does the  
network operates in that case?

TC: Yes, the sentence is misleading. What we try to say is MSF can work with 
other specifications protocols, rather then minimal 6TiSCH configuration, as 
long as the protocols gives a way to communicate the EB and DIO among the 
network.


Those words in the draft will make me a happy shepherd...





For example, a Trickle Timer defined in

[RFC6550<https://tools.ietf.org/html/rfc6550>] MAY be applied on DIOs. However, 
this behavior is

implementation-specific which is out of the scope of MSF.



This is not for this spec to define. RPL already mandates trickle. Suggestion:


For example, the Trickle operation defined in [RFC6206]

is applied on DIO Messages [RFC6550<https://tools.ietf.org/html/rfc6550>]. This 
behavior is

out of the scope of MSF.



TC: agreed!





MSF RECOMMENDS the use of 3 slotframes.

Discussion on slotframes and cells comes without an introduction to TSCH.
I’d suggest you add a few words on RFC 7554 appendix A and 6TiSCH architecture 
section 4.3.5. to introduce those concepts.
They should probably be normative references.

TC: I added the following text at beginning of section 2:
In a TSCH network, time is sliced up into time slots.
The time slots are grouped as one of more slotframes which repeat 
over time.
The TSCH schedule instructs a node what to do at each time slots, 
such as transmit, receive or sleep .
In case of a slot to transmit or receive, a channel is assigned to 
the time slot.
The tuple (slot, channel) is indicated as a cell of TSCH schedule.
MSF is one of the policies defining how to manage the TSCH schedule.

Excellent




Section 4 has numerous SHOULD. Trouble is, when SHOULD is used, the author 
SHOULD explain the alternate, what if the SHOULD is not followed.
Sometimes it’s quite obvious, like when using random in 4.2. But SHOULD use 
minimal is less obvious. Please consider adding text after the SHOULDs.

TC: agreed!  I have resolved this SHOULD issues in a new version. either the 
unnecessaries are removed or alternative explanation is added

I’ll review once you published




   field it contains, the presence and contents of the IE defined in

   
[I-D.richardson-6tisch-join-enhanced-beacon<https://tools.ietf.org/html/draft-ietf-6tisch-msf-08#ref-I-D.richardson-6tisch-join-enhanced-beacon>],
 or the key used to

   authenticate it.

The reference is now draft-ietf.. I agree that it should be normative; no 
worries the draft is already submitted for publication.
More important: Please move the reference to 6tisch-dtsecurity-zerotouch-join 
to informational. This is a DOWNREF today and your draft may be stuck in 
MISSREF in the future.

TC: I have updated  richardson-6tisch-join-enhanced-beacon to  
ietf-6tisch-enrollment-enhanced-beacon.
I didn't get it how "move the reference to 6tisch-dtsecurity-zerotouch-join to 
informational" is done in the draft?


Sorry I was unclear. The draft is currently listed as a normative reference. 
This means that MSF will be held forever in miss ref at the RFC editor. Please 
move the link to the reference in the informational references section.




   After selected a preferred parent, the joined node MUST generate a 6P

Grammar: “After selecting”

Re: [6tisch] MSF Shepherd review

[Pascal Thubert (pthubert)]

Hello Tengfei


Please see below

Le 27 nov. 2019 à 21:44, Tengfei Chang  a écrit :


Thanks a lot for the reviewing, I responded inline:

On Mon, Nov 25, 2019 at 6:42 PM Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:
Dear all

Please find some comments below:




Please migrate to XML2RFC v3. This will save time in the future.

TC: got it! Will used in version 9.

:)



   However, an implementor MAY implement MSF without implementing

   Minimal 6TiSCH Configuration.


This is not helpful without explanations. What is the tradeoff? How does the  
network operates in that case?

TC: Yes, the sentence is misleading. What we try to say is MSF can work with 
other specifications protocols, rather then minimal 6TiSCH configuration, as 
long as the protocols gives a way to communicate the EB and DIO among the 
network.


Those words in the draft will make me a happy shepherd...





For example, a Trickle Timer defined in

[RFC6550<https://tools.ietf.org/html/rfc6550>] MAY be applied on DIOs. However, 
this behavior is

implementation-specific which is out of the scope of MSF.



This is not for this spec to define. RPL already mandates trickle. Suggestion:


For example, the Trickle operation defined in [RFC6206]

is applied on DIO Messages [RFC6550<https://tools.ietf.org/html/rfc6550>]. This 
behavior is

out of the scope of MSF.



TC: agreed!





MSF RECOMMENDS the use of 3 slotframes.

Discussion on slotframes and cells comes without an introduction to TSCH.
I’d suggest you add a few words on RFC 7554 appendix A and 6TiSCH architecture 
section 4.3.5. to introduce those concepts.
They should probably be normative references.

TC: I added the following text at beginning of section 2:
In a TSCH network, time is sliced up into time slots.
The time slots are grouped as one of more slotframes which repeat 
over time.
The TSCH schedule instructs a node what to do at each time slots, 
such as transmit, receive or sleep .
In case of a slot to transmit or receive, a channel is assigned to 
the time slot.
The tuple (slot, channel) is indicated as a cell of TSCH schedule.
MSF is one of the policies defining how to manage the TSCH schedule.

Excellent




Section 4 has numerous SHOULD. Trouble is, when SHOULD is used, the author 
SHOULD explain the alternate, what if the SHOULD is not followed.
Sometimes it’s quite obvious, like when using random in 4.2. But SHOULD use 
minimal is less obvious. Please consider adding text after the SHOULDs.

TC: agreed!  I have resolved this SHOULD issues in a new version. either the 
unnecessaries are removed or alternative explanation is added

I’ll review once you published




   field it contains, the presence and contents of the IE defined in

   
[I-D.richardson-6tisch-join-enhanced-beacon<https://tools.ietf.org/html/draft-ietf-6tisch-msf-08#ref-I-D.richardson-6tisch-join-enhanced-beacon>],
 or the key used to

   authenticate it.

The reference is now draft-ietf.. I agree that it should be normative; no 
worries the draft is already submitted for publication.
More important: Please move the reference to 6tisch-dtsecurity-zerotouch-join 
to informational. This is a DOWNREF today and your draft may be stuck in 
MISSREF in the future.

TC: I have updated  richardson-6tisch-join-enhanced-beacon to  
ietf-6tisch-enrollment-enhanced-beacon.
I didn't get it how "move the reference to 6tisch-dtsecurity-zerotouch-join to 
informational" is done in the draft?


Sorry I was unclear. The draft is currently listed as a normative reference. 
This means that MSF will be held forever in miss ref at the RFC editor. Please 
move the link to the reference in the informational references section.




   After selected a preferred parent, the joined node MUST generate a 6P

Grammar: “After selecting” or “once it has selected” sound better.

TC: the latter sounds better! Thanks!



Section Section 
8<https://tools.ietf.org/html/draft-ietf-6tisch-msf-08#section-8>

The  already generates the word “section”. If you write it too, it 
becomes duplicated as above.

TC: agreed!




For a node, this translates into

   monitoring the current usage of the cells it has to its preferred

   parent:


This is disturbing. MSF should not be used only with preferred parents. The 
whole game of doing a DODAG is to have and possibly use multiple parents.
A node can for instance send a NSM DAO with multiple transit options to the 
root. Also, it could be good to clarify that the child manages both directions.
Proposal:


For a node, this translates into

   monitoring the current usage of the cells it has to the parents it uses

   at this point of time for sending and receiving traffic:

Later there a numerous references to “preferred parent” => I’d suggest you use 
just “selected parent” or “active parent” or  something in that vein.
TC: I think "preferred parent" is

[6tisch] MSF Shepherd review

[Pascal Thubert (pthubert)]

Dear all

Please find some comments below:




Please migrate to XML2RFC v3. This will save time in the future.



   However, an implementor MAY implement MSF without implementing

   Minimal 6TiSCH Configuration.


This is not helpful without explanations. What is the tradeoff? How does the  
network operates in that case?





For example, a Trickle Timer defined in

[RFC6550] MAY be applied on DIOs. However, 
this behavior is

implementation-specific which is out of the scope of MSF.



This is not for this spec to define. RPL already mandates trickle. Suggestion:


For example, the Trickle operation defined in [RFC6206]

is applied on DIO Messages [RFC6550]. This 
behavior is

out of the scope of MSF.







MSF RECOMMENDS the use of 3 slotframes.

Discussion on slotframes and cells comes without an introduction to TSCH.
I'd suggest you add a few words on RFC 7554 appendix A and 6TiSCH architecture 
section 4.3.5. to introduce those concepts.
They should probably be normative references.




Section 4 has numerous SHOULD. Trouble is, when SHOULD is used, the author 
SHOULD explain the alternate, what if the SHOULD is not followed.
Sometimes it's quite obvious, like when using random in 4.2. But SHOULD use 
minimal is less obvious. Please consider adding text after the SHOULDs.




   field it contains, the presence and contents of the IE defined in

   
[I-D.richardson-6tisch-join-enhanced-beacon],
 or the key used to

   authenticate it.

The reference is now draft-ietf. I agree that it should be normative; no 
worries the draft is already submitted for publication.
More important: Please move the reference to 6tisch-dtsecurity-zerotouch-join 
to informational. This is a DOWNREF today and your draft may be stuck in 
MISSREF in the future.




   After selected a preferred parent, the joined node MUST generate a 6P

Grammar: "After selecting" or "once it has selected" sound better.




Section Section 
8

The  already generates the word "section". If you write it too, it 
becomes duplicated as above.




For a node, this translates into

   monitoring the current usage of the cells it has to its preferred

   parent:


This is disturbing. MSF should not be used only with preferred parents. The 
whole game of doing a DODAG is to have and possibly use multiple parents.
A node can for instance send a NSM DAO with multiple transit options to the 
root. Also, it could be good to clarify that the child manages both directions.
Proposal:


For a node, this translates into

   monitoring the current usage of the cells it has to the parents it uses

   at this point of time for sending and receiving traffic:

Later there a numerous references to "preferred parent" => I'd suggest you use 
just "selected parent" or "active parent" or  something in that vein.



Cell installed at initial


Not sure this is correct. Maybe "at init time"





It is recommended to set MAX_NUMCELLS value at

   least 4 times than the maximum link traffic load of the network in

   packets per slotframe.




This does not parse. Can you please rephrase?




Section 8 does not try to avoid collisions with autocells. But it's easy to 
compute the slot offset of autocells for self and parent and avoids those. Why 
not do that?



Section 16 will require more attention, either now or during secdir review, 
probably both. You should start now. Think, say, what if an attacker claims 
many cells to all its neighbors? Can it attack someone's autocells to block him?



Voila!

Pascal as shepherd.






___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] MSF review

[Pascal Thubert (pthubert)]

Hello Yatch

Many thanks again for agreeing to perform another review one the latest MSF..
Once this is last round is complete, the shepherd will perform the request for 
publication.

All the best,

Pascal

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] tentative agenda for Singapore

[Pascal Thubert (pthubert)]

Dear all

We published a draft agenda for  Singapore at 
https://datatracker.ietf.org/doc/agenda-106-6tisch/
Like in Montreal Mališa Vučinić and I will be seating at the chairs positions, 
Thomas being remote.
Please have a look and let us know if any change is needed.

All the best,

Pascal
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] WGLC for draft-ietf-6tisch-msf-07

[Pascal Thubert (pthubert)]

Dear all

The WGLC has now completed. I asked the authors to publish before cutoff based 
on the comments raised so we can have a status at the IETF meeting.

I'll start a shepherd review based on that level.

All the best

Pascal

From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Pascal Thubert (pthubert)
Sent: vendredi 18 octobre 2019 15:33
To: 6tisch@ietf.org
Subject: [6tisch] WGLC for draft-ietf-6tisch-msf-07

Dear WG :

We are launching a WG last call for MSF 
https://tools.ietf.org/html/draft-ietf-6tisch-msf-07 .

The call starts today and runs for 2 weeks, ending November 1st.

This leaves a small window around the week end to publish final changes before 
the draft publication cutoff on November 4th.

Please review and comment asap so we can agree on changes before cutoff!

Many thanks;

The chairs



___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Remote presentations at IETF106 - cutoff date November 16

[Pascal Thubert (pthubert)]

Dear all:

Please keep in mind that remote presenters need a meetecho access. 

So please do not forget to tell me as part of your presentation proposal that 
you'll be remote, and I'll make sure you're listed with meetecho.
Also, cutoff date is approaching to normal rate and draft publication 
https://datatracker.ietf.org/meeting/important-dates/ , don't be late!

All the best;

Pascal

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] 6TiSCH @ IETF 106: Call for agenda items

[Pascal Thubert (pthubert)]

Dear 6TiSCHers,

The agenda for IETF 106 has been published at: 
https://datatracker.ietf.org/meeting/106/agenda.html. Keep this link, it's 
always useful with a number of pointers to meeting needful things. Also 
consider the IETF application for your smartphone...

So 6TISCH will be meeting on Friday November 22nd from 10:00 to 12:00, during 
Morning session I in room 
Hullet.

If you'd like a slot to present a draft, please send a request to the chairs 
(cc) by Friday November 8th. Usual suspects, please DO NOT expect that you'll 
get a slot without asking, and DO NOT wait for the chairs to ask you 
personally, but just kindly answer this mail. Please provide the following 
information:

  *   Draft name
  *   Presenter name
  *   Remote vs. Local presentation
  *   Expected duration
  *   Objective of the discussion

 We kindly request to send your slides for presentations by Friday November 
16th. A template will be provided.

 Any WG draft not being discussed/presented needs a status update sent to the 
list by Friday November 16th as well.

 As always - we would appreciate your help in taking notes and jabber, please 
do volunteer!

 Looking forward to seeing you in all Singapore,

 Thomas and Pascal


___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] WGLC for draft-ietf-6tisch-msf-07

[Pascal Thubert (pthubert)]

Dear WG :

We are launching a WG last call for MSF 
https://tools.ietf.org/html/draft-ietf-6tisch-msf-07 .

The call starts today and runs for 2 weeks, ending November 1st.

This leaves a small window around the week end to publish final changes before 
the draft publication cutoff on November 4th.

Please review and comment asap so we can agree on changes before cutoff!

Many thanks;

The chairs



___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] downstream traffic adaptation

[Pascal Thubert (pthubert)]

Hello Tengfei and all

I see that the 2 issues of IETF 105

  *   Rules for CellList
  *   Downward traffic adaptation
Were discussed and there was no objection. Do you fell ready for WGLC now?

All the best

Pascal

From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Tengfei Chang
Sent: vendredi 4 octobre 2019 07:25
To: Pascal Thubert (pthubert) 
Cc: 6tisch <6tisch@ietf.org>
Subject: Re: [6tisch] downstream traffic adaptation

Hi Pascal,

Yes, it is implemented and tested, the result is shown in the (long) email 
"[6tisch] validating the downstream traffic adaptation in 
draft-ietf-6tisch-msf-06".
I attached the figure here as well.

Though that email is long, all the information is the explaination of the 
result figure, trying to make it clear.
You can check the figure directly, I think is understandable for people 
following the msf well.

Tengfei

On Fri, Aug 23, 2019 at 4:23 PM Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:
Looks good Tengfei. Did you already implement and test?

Pascal

From: 6tisch <6tisch-boun...@ietf.org<mailto:6tisch-boun...@ietf.org>> On 
Behalf Of Tengfei Chang
Sent: vendredi 23 août 2019 14:28
To: 6tisch <6tisch@ietf.org<mailto:6tisch@ietf.org>>
Subject: [6tisch] downstream traffic adaptation

Hi All,

As discussed in IETF 105, we are going to support adapting downstream traffic.
And now this feature is added in draft-ietf-6tisch-msf-06 published one weeks 
ago.

Some main changes related to this feature are:

  1.  After joined the network and got Rank, the node will only add one Tx Cell 
to its parent (NOT add Rx Cell)
  2.  When adapting downstream traffic, the mote will check the cell usage on 
the Rx Cells.
  3.  At each Rx cell to parent, the NUMCELLELAPSE increments
  4.  If there is any frames received on the Rx cell, the NUMCELLUSED increments
  5.  If NUMCELLELAPSE reaches MAX_NUMCELLS, check the percentage of cell 
usage, if higher than the high threshold, add one Rx cell to parent, if lower 
than the low threshold, remove one Rx cell to parent.
  6.  The AutoRx cell is used for downstream as well and will never be removed.
Those changes are integrated into version 06 content.. You can read it to check 
exactly how we did the changes.
Please let me know if you have comments on them.. Thanks!

Tengfei

--
Chang Tengfei,
Postdoctoral Research Engineer, Inria


--
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tcahng.org<http://www.tcahng.org>
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch-architecture-24: (with COMMENT)

[Pascal Thubert (pthubert)]

With the default of 10 ms it takes 350 years to wrap ASN. That's  long memory 
to keep for an attacker. Modern storage technology does not last that long.

But hey, 6TiSCH is designed to be easily portable to other deterministic MAC 
technologies (think RAW) which would be much faster. A reasonable time slot in 
802.11 ax would be below 1ms, which would take is down to 35 years. But there 
are alternatives:

- At some point we do not slot anymore, just provide precise time for 
transmission (think time-based shapers).

- If we keep resource blocks of 10ms in 5G, there will be multiple packets, so 
ASN will need an extension (at least an additional octet that would be signaled 
in band) to count the packet with a finer granularity than ASN, within the time 
slot.

I modified Archie based on Tero's comment to make it more abstract - just say 
nonce-reuse attack deferring to others on what the result of the attack can be 
- and indicate the 350 years. Please ssee if that's enough.

All the best,

Pascal

> -Original Message-
> From: Michael Richardson 
> Sent: mardi 27 août 2019 19:44
> To: Tero Kivinen 
> Cc: Pascal Thubert (pthubert) ; Roman Danyliw
> ; shwetha.bhand...@gmail.com; 6tisch-cha...@ietf.org; The
> IESG ; 6tisch@ietf.org; 
> draft-ietf-6tisch-architect...@ietf.org;
> Benjamin Kaduk 
> Subject: Re: [6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch-
> architecture-24: (with COMMENT)
> 
> 
> Tero Kivinen  wrote:
> > Pascal Thubert (pthubert) writes:
> >> o The cryptographic mechanisms used by [IEEE802154] include the 2-
> byte
> >> short address in the calculation of the context.  If the 2-byte short
> >> address is reassigned to another node while the same network-wide
> keys
> >> are in operation, it is possible that this could result in disclosure
> >> of the network-wide key due to reused of the
> 
> > Even when the nonce reuse happens, I do not think there is any leak of
> > the network-wide keys in that case. What is lost is the confidentiality
> > of the those messages sharing nonce, i.e., only those messages are
> > broken, not the whole network key.
> 
> I had understood that it was worse.
> The text has slightly changed since, but can you suggest better text?
> So I've overstated the risk.
> 
> >> o Many cipher algorithms have some suggested limits on how many
> bytes
> >> should be encrypted with that algorithm before a new key is used.
> >> These numbers are typically in the many to hundreds of gigabytes of
> >> data.  On very fast backbone networks this becomes an important
> >> concern.  On LLNs with typical data rates in the kilobits/second, this
> >> concern is significantly less.  However, the LLN may be expected to
> >> operate for decades at a time, and operators are advised to plan for
> >> the need to rekey.
> 
> > Note, that TSCH in general allows maximally of 2^40 frames to be sent
> > before ASN rolls over. In normal case the maximum packet size is 2^7
> > octets, meaning the total amount of bytes that can be transferred over
> > TSCH network is 2^47 octects, meaning 2^43 blocks of AES. Currently
> > only cipher supported by the TSCH is AES-CCM-128 (altough 802.15.4y
> > will be adding support for other algorithms too), but I think the
> > maximum number of blocks recommened for one key for AES is more
> than
> > 2^43, so this should not be a problem at all. I.e., the ASN frame
> > counter will be problem before this will be problem. Even if using the
> > PHY with 2^11 max frame length that gives only 2^47 blocks at maximum.
> 
> This analysis should be included, and I'll try to do that.
> 
> I think that we MUST rekey before the ASN rolls over too?
> Is that a major concern?
> 
> I understood the ASN advances every 10ms in many networks, sometimes as
> slow as 50ms.  So let's call it 2^6/s?  So the ASN rolls over after 544 years?
> 2^(40-6) / (86400 * 365) = 544.
> 
> I guess the point is that we don't have to rekey for cryptographic of ASN 
> roll-
> over reasons.
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] I-D Action: draft-ietf-6tisch-architecture-26.txt

[Pascal Thubert (pthubert)]

Many thanks Michael!


Regards,

Pascal

> Le 27 août 2019 à 19:31, Michael Richardson  a écrit :
> 
> 
> internet-dra...@ietf.org wrote:
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-architecture-26
> 
> The updates in -26 are mostly text that I changed to explain the rekeying
> occurances.  Some typos and awkward phrasing has since been fixed by Pascal
> and I.
> 
> -- 
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works|IoT architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [Roll] WG adoption call for draft-richardson-6tisch-roll-enrollment-priority-02 - Extended (fwd) Ines Robles: [Roll] WG adoption call for draft-richardson-6tisch-roll-enrollment-priority-

[Pascal Thubert (pthubert)]

+1


Regards,

Pascal

> Le 27 août 2019 à 20:09, Michael Richardson  a écrit :
> 
> 
> This document is part of the enhanced beacon process.
> Comments appreciated to *ADOPT*.
> 
> 
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch-architecture-24: (with COMMENT)

[Pascal Thubert (pthubert)]

All the best,

Pascal

> -Original Message-
> From: Tero Kivinen 
> Sent: mardi 27 août 2019 15:01
> To: Pascal Thubert (pthubert) 
> Cc: Roman Danyliw ; The IESG ; Benjamin
> Kaduk ; shwetha.bhand...@gmail.com; 6tisch@ietf.org;
> 6tisch-cha...@ietf.org; draft-ietf-6tisch-architect...@ietf.org
> Subject: Re: [6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch-
> architecture-24: (with COMMENT)
> 
> Pascal Thubert (pthubert) writes:
> >o  The cryptographic mechanisms used by [IEEE802154] include the
> >   2-byte short address in the calculation of the context.  If the
> >   2-byte short address is reassigned to another node while the same
> >   network-wide keys are in operation, it is possible that this could
> >   result in disclosure of the network-wide key due to reused of
> > the
> 
> Even when the nonce reuse happens, I do not think there is any leak of the
> network-wide keys in that case. What is lost is the confidentiality of the 
> those
> messages sharing nonce, i.e., only those messages are broken, not the whole
> network key.

I'd really like to understand that. This is too deep for Archie anyway. I'll 
change the text to indicate that a nonce-reuse attack would be possible.
Does the below work?

" 
  The cryptographic mechanisms used by IEEE Std. 802.15.4 include the 2-byte
  short address in the calculation of the context.
  A nonce-reuse attack may become feasible if a short address is reassigned
  to another node while the  same network-wide keys are in operation.
"


> 
> >o  Many cipher algorithms have some suggested limits on how many
> >   bytes should be encrypted with that algorithm before a new key is
> >   used.  These numbers are typically in the many to hundreds of
> >   gigabytes of data.  On very fast backbone networks this becomes an
> >   important concern.  On LLNs with typical data rates in the
> >   kilobits/second, this concern is significantly less.  However, the
> >   LLN may be expected to operate for decades at a time, and
> >   operators are advised to plan for the need to rekey.
> 
> Note, that TSCH in general allows maximally of 2^40 frames to be sent before
> ASN rolls over. In normal case the maximum packet size is 2^7 octets,
> meaning the total amount of bytes that can be transferred over TSCH
> network is 2^47 octects, meaning 2^43 blocks of AES. Currently only cipher
> supported by the TSCH is AES-CCM-128 (altough 802.15.4y will be adding
> support for other algorithms too), but I think the maximum number of blocks
> recommened for one key for AES is more than 2^43, so this should not be a
> problem at all. I.e., the ASN frame counter will be problem before this will 
> be
> problem. Even if using the PHY with 2^11 max frame length that gives only
> 2^47 blocks at maximum.

Many thanks, Tero, all this is really useful. What about:

" 
  With TSCH as it stands at the time of this writing, the ASN will wrap
  after 2^40 timeslot durations, which means with the default values around
  350 years. Wrapping ASN is not expected to happen within the lifetime of
  most LLNs. Yet, should the ASN wrap, the network must be rekeyed to avoid
  a nonce-reuse attack.

  Many cipher algorithms have some suggested limits on how many bytes
  should be encrypted with that algorithm before a new key is used.
  These numbers are typically in the many to hundreds of gigabytes of
  data.  On very fast backbone networks this becomes an important
  concern. On LLNs with typical data rates in the kilobits/second,
  this concern is significantly less. With IEEE Std. 802.15.4 as it stands
  at the time of this writing, the ASN will wrap before the limits of the
  current L2 crypto (AES-CCM-128) are reached, so the problem should never
  occur.

  In any fashion, if the LLN is expected to operate continuously for decades
  then the operators are advised to plan for the need to rekey.
"

All the best;

Pascal

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch-architecture-24: (with COMMENT)

[Pascal Thubert (pthubert)]

s should consider the need to rekey the network on
  a periodic basis in order to recover 2-byte addresses.  The rekey
  can update the short addresses for active nodes if desired, but
  there is actually no need to do this as long as the key has been
  changed.

   o  Many cipher algorithms have some suggested limits on how many
  bytes should be encrypted with that algorithm before a new key is
  used.  These numbers are typically in the many to hundreds of
  gigabytes of data.  On very fast backbone networks this becomes an
  important concern.  On LLNs with typical data rates in the
  kilobits/second, this concern is significantly less.  However, the
  LLN may be expected to operate for decades at a time, and
  operators are advised to plan for the need to rekey.

   Except for urgent rekeys caused by malicious nodes, the rekey
   operation described in [I-D.ietf-6tisch-minimal-security] can be done
   as a background task and can be done incrementally.  It is a make-
   before-break mechanism.  The switch over to the new key is not
   signaled by time, but rather by observation that the new key is in
   use.  As such, the update can take as long as needed, or occur in as
   short a time as practical.

"

This is candidate to -26 to be published soon. Please come back to us if this 
needs additional work  : )

All the best,

Pascal

> -Original Message-
> From: Roman Danyliw 
> Sent: jeudi 22 août 2019 22:57
> To: Pascal Thubert (pthubert) ; The IESG
> 
> Cc: draft-ietf-6tisch-architect...@ietf.org; 6tisch-cha...@ietf.org;
> shwetha.bhand...@gmail.com; 6tisch@ietf.org
> Subject: RE: Roman Danyliw's No Objection on draft-ietf-6tisch-architecture-
> 24: (with COMMENT)
> 
> Hi Pascal!
> 
> Thank you for publishing -25.  It addresses my concern.  I have one detailed
> response below about a possible edit based on your question.
> 
> Roman
> 
> > -Original Message-
> > From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com]
> > Sent: Thursday, August 22, 2019 11:19 AM
> > To: Roman Danyliw ; The IESG 
> > Cc: draft-ietf-6tisch-architect...@ietf.org; 6tisch-cha...@ietf.org;
> > shwetha.bhand...@gmail.com; 6tisch@ietf.org
> > Subject: RE: Roman Danyliw's No Objection on
> > draft-ietf-6tisch-architecture-
> > 24: (with COMMENT)
> >
> > Hello Roman:
> >
> > Many thanks for your review, your time is much appreciated.
> >
> > Please see below:
> >
> > >
> > > 
> > > --
> > > COMMENT:
> > > 
> > > --
> > >
> > > ** Why are both Section 3.4 and Section 4.4 needed?  Both appear to
> > > explain the four scheduling mechanisms.  Section 4.4. appears to
> > > have
> > more details.
> >
> > Section 3 is a high level architecture, section 4 a low level. Having
> > both in 1 document was  a conscious decision since the early review by
> > Ralph. We split in a high and a low level architecture and kept them
> > combined to avoid the explosion of documents. For the same reason, we
> > later incorporated the terminology that was initially a separate spec.
> >
> > As a result this draft has 2/3 documents in one, with commonalities in
> > section
> > 3.4 and 4.4 for instance. That's where we are and as you say, there is
> > no fundamental new reason to undo that.
> >
> > There was a desire to make section 4 self-sufficient, with the idea of
> > possibly splitting section 3 and 4 which we never did. Still it might
> > be useful to the reader who just reads that section.
> > And there was a desire to have a discussion at the high level
> > architecture on this topic so removing 3.4 is not good either.
> >
> > I'm quite afraid to destabilize the document by doing a major change now.
> 
> Understood.  I can appreciate the intent here.
> 
> >
> > > ** Section 3.6. Per the summary table in this section, what is the
> > > routing technique “reactive P2P”.  It doesn’t appear to be explained
> > > in the
> > text above.
> >
> > PT> I removed the P2P which is not explained. The relevant text
> > PT> otherwise is
> > "
> > or by in a distributed fashion using a reactive routing protocol and
> >a Hop-by-Hop scheduling protocol.
> > "
> >
> >
> > > ** Section 3.6.  Per the “Hop-by-Hop  (TBD)” in the scheduling
> > > column in the summary table, to what does the “TBD”?
> >
> > PT> good catch. It is now AODV RPL, upda

Re: [6tisch] downstream traffic adaptation

[Pascal Thubert (pthubert)]

Looks good Tengfei. Did you already implement and test?

Pascal

From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Tengfei Chang
Sent: vendredi 23 août 2019 14:28
To: 6tisch <6tisch@ietf.org>
Subject: [6tisch] downstream traffic adaptation

Hi All,

As discussed in IETF 105, we are going to support adapting downstream traffic.
And now this feature is added in draft-ietf-6tisch-msf-06 published one weeks 
ago.

Some main changes related to this feature are:

  1.  After joined the network and got Rank, the node will only add one Tx Cell 
to its parent (NOT add Rx Cell)
  2.  When adapting downstream traffic, the mote will check the cell usage on 
the Rx Cells.
  3.  At each Rx cell to parent, the NUMCELLELAPSE increments
  4.  If there is any frames received on the Rx cell, the NUMCELLUSED increments
  5.  If NUMCELLELAPSE reaches MAX_NUMCELLS, check the percentage of cell 
usage, if higher than the high threshold, add one Rx cell to parent, if lower 
than the low threshold, remove one Rx cell to parent.
  6.  The AutoRx cell is used for downstream as well and will never be removed.
Those changes are integrated into version 06 content. You can read it to check 
exactly how we did the changes.
Please let me know if you have comments on them. Thanks!

Tengfei

--
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] cell rules in MSF

[Pascal Thubert (pthubert)]

Hello Tengfei

The text below:

whether there is any incoming frame on those cells
could be understood like it is a unicast frame to this node.
In fact the text should describe promiscuous listening of traffic between 
arbitrary nodes.
I’m OK to use carrier sense since an interference is only interesting if it is 
TSCH.

I would suggest



   As a consequence of randomly cell selection, there is a non-zero

   chance that nodes in the vicinity installed cells with same

   slotOffset and channelOffset.  An implementer MAY implement a

   strategy to monitor the candidate cells before adding them in

   CellList to avoid collision.  For example, a node MAY maintain a

   candidate cell pool for the CellList.  The candidate cells in the

   pool are pre-configured as Rx cells to promiscuously listen to

   detect transmissions on those cells.  If IEEE802.15.4 transmissions

   are observed on one cell over multiple iterations of the schedule,

   that cell is probably used by a TSCH neighbor. It is

   moved out from the pool and a new cell is selected as a candidate

   cell.  The cells in CellList are picked from the candidate pool
   directly when required.


All the best,

Pascal

From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Tengfei Chang
Sent: vendredi 23 août 2019 14:11
To: 6tisch <6tisch@ietf.org>
Subject: [6tisch] cell rules in MSF

Hi all,

As we discussed in IETF 105, we may need some way to monitor the candidate 
cells to schedule before adding them.

Hence the following paragraph is added in version 06:


 As a consequence of randomly cell selection, there is a non-zero

   chance that nodes in the vicinity installed cells with same

   slotOffset and channelOffset.  An implementer MAY implement a

   strategy to monitor the candidate cells before adding them in

   CellList to avoid collision.  For example, a node MAY maintain a

   candidate cell pool for the CellList.  The candidate cells in the

   pool are pre-configured as Rx cells to listen whether there is any

   incoming frame on those cells.  If any IEEE802.15.4 frames are

   received within a pre-defined duration on one cell, that cell will be

   moved out from the pool and a new cell is selected as a candidate

   cell.  The cells in CellList are picked from the candidate pool
   directly when required.

Please let me know if you have any comments on this fix. Thanks!

Tengfei

--
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] moving on with MSF

[Pascal Thubert (pthubert)]

Dear authors

At IETF 105, we mentioned that 2 issues were remaining and that we'd last call 
by fall. Which is soon.
I'd like to restart the discussion and I'm asking you to start a thread for 
each of these issues so we can solve them and move forward.

The ball is in you camp.

Many thanks : )

Pascal
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Normative references in Archie

[Pascal Thubert (pthubert)]

Dear all :

Following the latest round of IESG reviews and upon a suggestion by Mirja 
seconded by Benjamin, we promoted a number of references to normative in 
https://tools.ietf.org/html/draft-ietf-6tisch-architecture-25

This means that Archie will not ship until all of these references are RFC. A 
positive side effect is that it is possible to update Archie to fit any change 
that would happen to these specs between now and publication.
This is in particular relevant when section numbers are used with the 
references. A particular mention to minimal security that is the reference 
repository for security considerations.

Most of these specs are well-advanced, and apart from MSF passed WGLC. So we're 
not talking about waiting forever. It's just that Archie has also a role of 
cataloguing the efforts that we made over the years and pointing the reader to 
the relevant publication with the overall goal to make IETF's IOT work more 
accessible.

The least advanced specs are MSF and RPL-unaware leaves. I'll be trying to give 
them more focus to get the picture complete. I'd have loved to make the 
zerotouch spec normative as well, depends on the content that is added there 
and on the progress on constrained voucher by the time we're ready to ship 
Archie.

All the best

Pascal

PS The full list on normative references still in progress, from the least to 
the most advanced, is:

 Spec   
   Status





   [I-D.ietf-roll-unaware-leaves]Active in ROLL WG



   [I-D.ietf-6tisch-msf] Active in 6TiSCH WG



   [I-D.ietf-6lo-backbone-router]Passed WGLC, 
pending 6MAN review by Tim Winters



   [I-D.ietf-6tisch-enrollment-enhanced-beacon]Passed WGLC, pending I-D 
Revision for nits



   [I-D.ietf-6lo-fragment-recovery]  Passed WGLC, 
pending Shepherd publication request



   [I-D.ietf-6lo-minimal-fragment]   Passed WGLC, 
pending Shepherd publication request



   [I-D.ietf-6lo-ap-nd]  AD Evaluation



   [I-D.ietf-6tisch-minimal-security]AD Evaluation



   [I-D.ietf-roll-useofrplinfo]  RFC Ed Queue: EDIT



   [I-D.ietf-detnet-architecture]RFC Ed Queue: 
AUTH48



___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Intelligent JP / validating the MASA

[Pascal Thubert (pthubert)]

: )

I used the heavy weaponry in -25;  madi minimal a normative reference and added:

"
6.7.  Deeper Considerations

   The reader is encouraged to review the security section of
   [I-D.ietf-6tisch-minimal-security], which discusses 6TiSCH security
   issues in more details.

"

Works?

Pascal

> -Original Message-
> From: Benjamin Kaduk 
> Sent: vendredi 23 août 2019 01:49
> To: Michael Richardson 
> Cc: Pascal Thubert (pthubert) ; =?utf-
> 8?B?TWFsacWhYSBWdcSNaW5pxIc=?= ; Tero Kivinen
> ; 6tisch@ietf.org
> Subject: Re: Intelligent JP / validating the MASA
> 
> On Thu, Aug 22, 2019 at 05:00:39PM -0400, Michael Richardson wrote:
> >
> > Pascal Thubert (pthubert)  wrote:
> > > I’m reading a question of possibility multiple JRC whereby the pledge
> > > would indicate which JRC to use and possibly leverage that for an
> > > attack on anyone outside.
> >
> > No, the pledge intentionally has no way to signal alternate destinations.
> 
> Cool; I think I had missed that or confused myself.
> Combined with the defenses in minimal-security that Mališa pointed out, it
> sounds like we're in pretty good shape.  Now Pascal just has to figure out how
> to point to the text in minimal-security without bloating -architecture too
> much!
> 
> Thanks,
> 
> Ben
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch-architecture-24: (with COMMENT)

[Pascal Thubert (pthubert)]

Hello Roman:

I elided the pieces where we are in sync
 

> > > ** Section 6.  Per “Section 9 of [RFC8453] applies equally to
> > > 6TiSCH”, this reference organizes threats and mitigations around the
> > > CMI and MPI interfaces.
> > > What is the analog to those in this architecture?
> >
> > PT> This is the same parallel as done in the DetNet architecture from
> > PT> which
> > this is inherited, using the same reference.
> > The security issues that arise when a centralized control is separate
> > from the forwarding plane are similar: rogue access to one of the
> > components, and attacks on the connectivity on the control path,
> > including interception, blackholing or latency injection.
> > I can remove the reference and replace by text like the above, please 
> > advise.
> > In parammme please condsider the security section of the detnet
> > architecture, it is in AUTH 48 but still changeable.
> 
> I would recommend taking a hybrid approach.  I think it's worth making the
> more specific statement you propose but also citing that the more general
> version of this consideration comes from [RFC8453].
> 

PT> I caught that hint and gave it a try in 25, which is already a change in 
that direction:

   As with DetNet in general, the communication with the PCE must be
   secured and should be protected against DoS attacks, including delay
   injection and blackholing attacks, and secured as discussed in the
   security considerations defined for Abstraction and Control of
   Traffic Engineered Networks (ACTN) in Section 9 of [RFC8453], which
   applies equally to DetNet and 6TiSCH.  In a similar manner, the
   communication with the JRC must be secured and should be protected
   against DoS attacks when possible. 

PT> I'm happy to modify it deeper in 26, and would appreciate a suggestion : )

Many thanks again!

Pascal

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch-architecture-24: (with COMMENT)

[Pascal Thubert (pthubert)]

Hello Roman:

Many thanks for your review, your time is much appreciated.

Please see below:

> 
> --
> COMMENT:
> --
> 
> ** Why are both Section 3.4 and Section 4.4 needed?  Both appear to explain
> the four scheduling mechanisms.  Section 4.4. appears to have more details.

Section 3 is a high level architecture, section 4 a low level. Having both in 1 
document was  a conscious decision since the early review by Ralph. We split in 
a high and a low level architecture and kept them combined to avoid the 
explosion of documents. For the same reason, we later incorporated the 
terminology that was initially a separate spec.

As a result this draft has 2/3 documents in one, with commonalities in section 
3.4 and 4.4 for instance. That's where we are and as you say, there is no 
fundamental new reason to undo that.
 
There was a desire to make section 4 self-sufficient, with the idea of possibly 
splitting section 3 and 4 which we never did. Still it might be useful to the 
reader who just reads that section.
And there was a desire to have a discussion at the high level architecture on 
this topic so removing 3.4 is not good either.

I'm quite afraid to destabilize the document by doing a major change now.


> ** Section 3.6. Per the summary table in this section, what is the routing
> technique “reactive P2P”.  It doesn’t appear to be explained in the text 
> above.

PT> I removed the P2P which is not explained. The relevant text otherwise is
"
or by in a distributed fashion using a reactive routing protocol and
   a Hop-by-Hop scheduling protocol.
"


> ** Section 3.6.  Per the “Hop-by-Hop  (TBD)” in the scheduling column in the
> summary table, to what does the “TBD”?

PT> good catch. It is now AODV RPL, updated the picture


> ** Section 6.  In reviewing the Security Considerations section, there is a
> substantial amount of technical detail (thank you!).  However, despite this
> detail, understanding the overall security properties of the architecture and
> associate implementations mechanisms used by the architecture was
> challenging for me.  Specifically, if 6TiSCH “is subject to the observations 
> in
> section 5 of [I-D.ietf-detnet-architecture]”, then per [I-D.ietf-detnet-
> architecture] it should provide “confidentiality of data traversing the 
> DetNet”,
> “authentication and authorization … for each connected device”, availability,
> and precision timing. The text needs to be clearer on how those properties are
> realized, and if there are residual threat.  My recommended way to realize 
> this
> clarity is restructure the text into blocks around the relevant security
> properties and explicitly state the property as an introduction. 

PT >  I made an attempt at it, please see -25 once published.
The outlook would be

   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  51
 6.1.  Availability of Remote Services . . . . . . . . . . . . .  51
 6.2.  MAC-Layer Security  . . . . . . . . . . . . . . . . . . .  52
 6.3.  Time Synchronization  . . . . . . . . . . . . . . . . . .  53
 6.4.  Selective Jamming . . . . . . . . . . . . . . . . . . . .  53
 6.5.  Validating ASN  . . . . . . . . . . . . . . . . . . . . .  53
 6.6.  Rekeying  . . . . . . . . . . . . . . . . . . . . . . . .  54
 6.7.  Deeper Considerations . . . . . . . . . . . . . . . . . .  54

More below


> A few additional points:
> 
> -- Per precision timing, the text in this section says “measures must be taken
> to protect the time synchronization, and for 6TiSCH this includes ensuring 
> that
> the Absolute Slot Number (ASN), which is used as ever incrementing counter
> for the computation of the Link-Layer security nonce, is not compromised,
> more below on this.”  In the subsequent text there is “[t]he standard
> [IEEE802154] assumes that the ASN is distributed securely by other means.
> The ASN is not passed explicitly in the data frames”.  To confirm, is this the
> intended guidance on avoiding “compromising” the ASN – distribute it out of
> band and don’t pass it in the data frame?

PT > ASN is not passed in the frame because it would was 5 octets. A network is 
non-functional if nodes do not have the right sense of ASN so if the network 
works, it means the 5 bytes can be saved.
PT > With 6TiSCH, ASN is learned from unsecured beacons, and needs t be proven 
before used. We hint how that is done in this spec, and detail in minimal 
security.
PT > once installed and as long as the node is synchronized to the network ASN 
is implicit and cannot be compromised.
PT > One of the new sections deals with ASN protection and the details are in 
the 6tisch minimal security draft

> -- Per confidentiality (but it is really more than that), a series of security
> mechanisms/assumptions are inherited from [IEEE Std. 802.15.4] around link-
> layer security. They n

Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

Hello Benjamin:

Many thanks for your in depth review of the draft, this is really appreciated.

Please see below:
> --
> DISCUSS:
> --
> 
> Section 4.3.4 asserts:
> 
>[...]  We'll note that the Join
>Priority is now specified between 0 and 0x3F leaving 2 bits in the
>octet unused in the IEEE Std. 802.15.4e specification.  After
>consultation with IEEE authors, it was asserted that 6TiSCH can make
>a full use of the octet to carry an integer value up to 0xFF.
> 
> I'm extremely reluctant to publish this text in the IETF stream without a 
> citation.
> 
> 
> I also think there are more topics that need to be covered in the security
> considerations (see Comment, and not just the Section-6 portions), especially
> with respect to the reliance on the link-layer security mechanism and its
> network-wide shared key.
> 

PT> We checked on a separate thread and the latest 802.15.4 aligned to our 
requirements and made it a full byte, so we're all good and I removed the 
sentence altogether.


> 
> --
> COMMENT:
> --
> 
> [The shepherd writeup's answer for the question about "why is this the proper
> type of RFC" did not change when the intended status changed from Proposed
> Standard to Informational, which would have been nice to see recorded.]
> 

PT> agreed. Did the IESG discuss on what's the best track for this document?


> It would be good to see some architectural discussion about key management
> for the link-layer keys.  (Given that 802.15.4 leaves key management as out of
> scope, it is clearly our problem.)  Thus far I don't even have a sense for 
> when it is
> possible to rotate a network's keys.
> 

PT> I took that to a separate thread with Michael, Tero and Malisa. It is 
certainly possible to rotate keys with minimal security. The tooling for 
peer-wise keys is also there. 
PT> We isolated cases where this is desirable in the discussion on the minimal 
security draft. I'm unclear how deep we need to go in this regards vs what 
belongs to the minimal security specification.
PT> I'm seeing reluctance in adding yet new text to the architecture, when 
minimal security is the central repository.
 
PT> Proposed text:

"
   Though it is possible to use peer-wise keys, a 6TiSCH network
   typically uses a network-wide key that is common for all
   transmissions in the LLN.  [I-D.ietf-6tisch-minimal-security] enables
   to obtain that key and to rekey the network when needed.  Since the
   ASN is expressed in 5 octets, it should never wrap during a network
   lifetime, and it is possible that a network never needs to rekey.
   Still, there are occasions where rekeying is necessary, for instance:

   o  An unwelcome node has joined and needs to be expelled

   o  The JRC needs to reassign a short address that was already
  assigned while the current network key was in use.

   o  Any action that may cause ASN to reuse a past value, e.g.,
  resetting Epoch time when rebooting the network.
"

> I'd like to see some discussion somewhere that the Join Proxy needs to take 
> care
> to not be an open redirector by which an unauthenticated pledge can attack
> arbitrary network elements (whether within the LLN or on the broader
> network), e.g., by performing some validation on the claimed MASA identifier.
> Similarly, that the JRC will be exposed to lots of untrusted input and needs 
> to be
> implemented in an especially robust manner.
> 

PT> I took that to a separate thread as well. People tend to defer that 
discussion to the minimal security draft.

I made the minimal security draft a normative reference and suggest to add:
"
   The reader is encouraged to review the security section of
   [I-D.ietf-6tisch-minimal-security], which discusses 6TiSCH security
   issues in more details.
"
Also added a discussion on protecting the path to the JRC as we already did for 
the PCE:
"
   In a similar manner, the communication with the
   JRC must be secured and should be protected against DoS attacks when
   possible.
"


> In some qualitative sense that's hard to describe, this document feels like a
> mash-up of two or maybe three different documents written at different levels
> of abstraction.  I don't know if it's even worth considering trying to tease 
> them
> apart, though.
> 

PT> this was  a conscious decision since the early review by Ralph. We split 
the document in a high and a low level architecture and kept them combined to 
avoid the explosion of documents. For the same reason, we later incorporated 
the terminology that was initially a separate spec.
PT> As a result this draft has 2/3 documents in one, with commonalities in 
section 3.4 and 4.4 for instance. That's where we 

Re: [6tisch] Intelligent JP / validating the MASA

[Pascal Thubert (pthubert)]

Many thanks Malisa

I agree but I’m not sure it’s just that.

I’m reading a question of possibility multiple JRC whereby the pledge would 
indicate which JRC to use and possibly leverage that for an attack on anyone 
outside.

For all I know the knowledge of the JRC is in the root, and it’s not provided 
by the pledge. So that problem does not exist.

The network is so slow that it can hardly be used to DoS the outside. The 
mechanism you describe is mostly there to protect the network itself starting 
with the JP.

I tend to agree with Michael that we have enough text in the Architecture and 
that a normative Reference to minimal security and a pointer to its security 
section have us covered.

Regards,

Pascal

Le 22 août 2019 à 12:12, Mališa Vučinić 
mailto:malisa.vuci...@inria.fr>> a écrit :

Hello Pascal,

The issue that Ben outlines was solved through two separate mechanisms that are 
detailed in draft-ietf-6tisch-minimal-security:

1) The traffic that JP redirects into the network on behalf of unauthenticated 
pledges is tagged using IPv6 DSCP such that it can be distinguished from the 
legitimate network traffic. This allows e.g. the 6tisch scheduling function to 
explicitly ignore the unauthenticated traffic when adapting link resources to 
traffic requirements. This is detailed in Section 6.1 of 
draft-ietf-6tisch-minimal-security.

2) The use of the CoJP “join_rate” parameter that allows the JRC to set the 
rate at which each JP in the network forwards the unauthenticated traffic. This 
mechanism serves as the bandwidth cap for the unauthenticated traffic before it 
is being forwarded into the network. The details are in Section 8.4.2 of 
draft-ietf-6tisch-minimal-security, and there is also a paragraph in the 
Security Considerations detailing the issue.

Mališa

On 20 Aug 2019, at 18:20, Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:

Dear all:

I’m looking for a consensus on how to address the following review comment on 
the 6TiSCH Architecture by Benjamin:

> I'd like to see some discussion somewhere that the Join Proxy needs to take 
> care
> to not be an open redirector by which an unauthenticated pledge can attack
> arbitrary network elements (whether within the LLN or on the broader
> network), e.g., by performing some validation on the claimed MASA identifier.
> Similarly, that the JRC will be exposed to lots of untrusted input and needs 
> to be
> implemented in an especially robust manner.

Then again I’d like to discuss the split of what goes in the architecture and 
what goes in Minimal security or elsewhere.

What do you think?

Pascal

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] rekeying the 6TiSCH network

[Pascal Thubert (pthubert)]

Yes, Don. 

So far I have not seen any 6TiSCH implementation using 802.15.9 but I guess it 
could be added. If people did try please let us now, now is a good time.
It results that at the moment we do not have text on 15.9 at all. It seems a 
bit late to add it now.

What do others think?

All the best,

Pascal

> -Original Message-
> From: Don Sturek 
> Sent: mardi 20 août 2019 22:17
> To: Michael Richardson ; Pascal Thubert (pthubert)
> ; Benjamin Kaduk ; Mališa Vučinić
> ; Tero Kivinen ; 6tisch@ietf.org
> Subject: Re: [6tisch] rekeying the 6TiSCH network
> 
> Š. On the rekeying topic for IEEE 802.15.4.
> 
> Have a look at IEEE 802.15.9.   It takes existing key establishment
> protocols (IEEE 802.1x, etc.) and provides encapsulation over IEEE 802.15.4.
> 
>  IEEE 802.15.9 does not solve all of your rekey needs but the tools are there
> when you agree on how you want rekeying to work.
> 
> Don
> 
> 
> 
> On 8/20/19, 1:03 PM, "6tisch on behalf of Michael Richardson"
> <6tisch-boun...@ietf.org on behalf of mcr+i...@sandelman.ca> wrote:
> 
> >
> >Pascal Thubert (pthubert)  wrote:
> >> I'm looking for a consensus on how to address the following review
> >> comment on the 6TiSCH Architecture by Benjamin:
> >
> >>> It would be good to see some architectural discussion about key
> >>> management
> >>> for the link-layer keys.  (Given that 802.15.4 leaves key
> >management
> >>> as out of
> >>> scope, it is clearly our problem.)  Thus far I don't even have a
> >sense
> >>> for when it is
> >>> possible to rotate a network's keys.
> >
> >PT> I'll take that to a separate thread with Michael, Tero and
> >Malisa. It
> >PT> is certainly possible to rotate keys. We had a draft about
> >rekeying
> >PT> that went stale. We isolated cases where this is desirable in the
> >PT> discussion on the minimal security draft. I'm unclear how deep we
> >PT> need to go in this regards vs. what belongs to the minimal
> >security
> >PT> specification.
> >
> >6tisch-minimal-security has a section 8.2 "Parameter Update Exchange"
> >Maybe it should include "(and Rekey)"
> >
> >We further have section 8.4.3.1 and 8.4.3.2 to explain how to use that
> >to rekey the entire network.
> >
> >I'm not sure what's in the Architecture document about this, but I'd
> >rather that it just said less.
> >
> >--
> >Michael Richardson , Sandelman Software Works
> >-= IPv6 IoT consulting =-
> >
> >
> >
> >___
> >6tisch mailing list
> >6tisch@ietf.org
> >https://www.ietf.org/mailman/listinfo/6tisch
> 

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

I agree, Mirja;

By default I’ll move the most comprehensive list to the normative section and 
from there will wait for Suresh to propose an update if he thinks a correction 
is needed.

Many thanks for your patience : )

Pascal
De : Mirja Kuehlewind<mailto:i...@kuehlewind.net>
Envoyé le :mercredi 21 août 2019 11:59
À : Pascal Thubert (pthubert)<mailto:pthub...@cisco.com>
Cc : Suresh Krishnan<mailto:suresh.krish...@gmail.com>; Shwetha 
Bhandari<mailto:shwetha.bhand...@gmail.com>; 
6tisch@ietf.org<mailto:6tisch@ietf.org>; 
6tisch-cha...@ietf.org<mailto:6tisch-cha...@ietf.org>; The 
IESG<mailto:i...@ietf.org>; 
draft-ietf-6tisch-architect...@ietf.org<mailto:draft-ietf-6tisch-architect...@ietf.org>
Objet :Re: Mirja Kühlewind's Discuss on draft-ietf-6tisch-architecture-24: 
(with DISCUSS and COMMENT)

Hi Pascal,

Thanks for doing this pass. Please see below.

> On 21. Aug 2019, at 11:34, Pascal Thubert (pthubert)  
> wrote:
>
> Hello again Mirja:
>
> I made the pass. On the one hand one could say that as expected the text is 
> readable as is, and that the references are complement of information on the 
> detailed howto.
> I found exceptions that really need to be moved anyway per your description 
> of normative:
>
>
>  
>  
>  
>  
>
> Another extreme view would say that the reading is only complete if some of 
> the drafts are read as well. Taking that other extreme view and adding it all 
> together I obtained the following list:
>
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>
> These are the document that really give a comprehensive picture of the RPL 
> network. I'm OK to move them in the normative reference section. That will 
> certainly delay the shipping of the RFC for the architecture, but that will 
> allow us to validate at the last minute that the architecture is still a 
> correct reflection of what those drafts specify.

I personally think that having this ability to check at the end is a plus, 
however, as I’m not the expert here, so I will reply on Suresh making a final 
call.

Mirja


>
> Please let me know if that matches the need that you identified,
>
> Pascal
>
>> -Original Message-
>> From: Pascal Thubert (pthubert)
>> Sent: mardi 20 août 2019 18:06
>> To: Mirja Kuehlewind 
>> Cc: Suresh Krishnan ; Shwetha Bhandari
>> ; 6tisch@ietf.org; 6tisch-cha...@ietf.org; The
>> IESG ; draft-ietf-6tisch-architect...@ietf.org
>> Subject: RE: Mirja Kühlewind's Discuss on draft-ietf-6tisch-architecture-24: 
>> (with
>> DISCUSS and COMMENT)
>>
>> Back from vacations : )
>>
>> I think I see your point Mirja. What we tried to do here is build a 
>> self-sufficient
>> document at the architecture level.
>> The specs referenced (exception from DetNet and those which have both
>> Architecture and specification content such as IPv6) are pointed because they
>> implement the architecture, but reading them should not be necessary to
>> understand the words in the architecture. I'll need a full pass to check if 
>> we did
>> that right.
>>
>> All the best,
>>
>> Pascal
>>
>>> -Original Message-
>>> From: Mirja Kuehlewind 
>>> Sent: jeudi 8 août 2019 18:16
>>> To: Pascal Thubert (pthubert) 
>>> Cc: Suresh Krishnan ; Shwetha Bhandari
>>> ; 6tisch@ietf.org; 6tisch-cha...@ietf.org;
>>> The IESG ; draft-ietf-6tisch-architect...@ietf.org
>>> Subject: Re: Mirja Kühlewind's Discuss on
>>> draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)
>>>
>>> See below.
>>>
>>>> On 8. Aug 2019, at 18:05, Pascal Thubert (pthubert)
>>>> 
>>> wrote:
>>>>
>>>> Hello Suresh and Mirja
>>>>
>>>> I’m happy to get recommendations on that topic. I understand Mirja’s
>>> recommendation on how to use normative refs; it makes sense, more so
>>> for std track. For informational, I’m still puzzled: Why call
>>> something normative in a document that is not establishing a standard?
>>>
>>> Let me give you a simple example. An informational document that
>>> describes operational practice for protocol X, needs to have the
>>> reference to the spec describing protocol X as a normative reference
>>> because if you don’t know anything about the protocol X, you will not
>>> be able to understand the operational guidance given.
>>>
>>> This is an easy example and I know that there are many cases where
>>> this is less clear, 

Re: [6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

Hello again Mirja:

I made the pass. On the one hand one could say that as expected the text is 
readable as is, and that the references are complement of information on the 
detailed howto.
I found exceptions that really need to be moved anyway per your description of 
normative:


   
   
   
  

Another extreme view would say that the reading is only complete if some of the 
drafts are read as well. Taking that other extreme view and adding it all 
together I obtained the following list:

  
  
  
  
  
  
  
  
   
  

These are the document that really give a comprehensive picture of the RPL 
network. I'm OK to move them in the normative reference section. That will 
certainly delay the shipping of the RFC for the architecture, but that will 
allow us to validate at the last minute that the architecture is still a 
correct reflection of what those drafts specify.

Please let me know if that matches the need that you identified,

Pascal

> -Original Message-
> From: Pascal Thubert (pthubert)
> Sent: mardi 20 août 2019 18:06
> To: Mirja Kuehlewind 
> Cc: Suresh Krishnan ; Shwetha Bhandari
> ; 6tisch@ietf.org; 6tisch-cha...@ietf.org; The
> IESG ; draft-ietf-6tisch-architect...@ietf.org
> Subject: RE: Mirja Kühlewind's Discuss on draft-ietf-6tisch-architecture-24: 
> (with
> DISCUSS and COMMENT)
> 
> Back from vacations : )
> 
> I think I see your point Mirja. What we tried to do here is build a 
> self-sufficient
> document at the architecture level.
> The specs referenced (exception from DetNet and those which have both
> Architecture and specification content such as IPv6) are pointed because they
> implement the architecture, but reading them should not be necessary to
> understand the words in the architecture. I'll need a full pass to check if 
> we did
> that right.
> 
> All the best,
> 
> Pascal
> 
> > -----Original Message-
> > From: Mirja Kuehlewind 
> > Sent: jeudi 8 août 2019 18:16
> > To: Pascal Thubert (pthubert) 
> > Cc: Suresh Krishnan ; Shwetha Bhandari
> > ; 6tisch@ietf.org; 6tisch-cha...@ietf.org;
> > The IESG ; draft-ietf-6tisch-architect...@ietf.org
> > Subject: Re: Mirja Kühlewind's Discuss on
> > draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)
> >
> > See below.
> >
> > > On 8. Aug 2019, at 18:05, Pascal Thubert (pthubert)
> > > 
> > wrote:
> > >
> > > Hello Suresh and Mirja
> > >
> > > I’m happy to get recommendations on that topic. I understand Mirja’s
> > recommendation on how to use normative refs; it makes sense, more so
> > for std track. For informational, I’m still puzzled: Why call
> > something normative in a document that is not establishing a standard?
> >
> > Let me give you a simple example. An informational document that
> > describes operational practice for protocol X, needs to have the
> > reference to the spec describing protocol X as a normative reference
> > because if you don’t know anything about the protocol X, you will not
> > be able to understand the operational guidance given.
> >
> > This is an easy example and I know that there are many cases where
> > this is less clear, however, it can definitely make sense to have
> > normative references in informational document because it solely
> > indicated which other documents are a MUST read in order to understand this
> document.
> >
> > Mirja
> >
> >
> > >
> > > On the topic of refinement section 4 goes clearly deeper down than section
> 3.
> > This is by design. We did not want to split and have to maintain and
> > keep in sync
> > 2 documents. Also we got hints from you guys that overloading the IESG
> > with many small documents was not the right way.
> > >
> > > Regards,
> > >
> > > Pascal
> > >
> > > Le 8 août 2019 à 16:01, Suresh Krishnan 
> > > a
> > écrit :
> > >
> > >> Hi Mirja,
> > >>
> > >> On Thu, Aug 8, 2019, 6:29 AM Mirja Kuehlewind 
> > wrote:
> > >> Hi Pascal,
> > >>
> > >> See below.
> > >>
> > >> > On 7. Aug 2019, at 20:31, Pascal Thubert (pthubert)
> >  wrote:
> > >> >
> > >> > Hello Mirja
> > >> >
> > >> > It certainly does not hurt to have a second look at how the split
> > >> > was done
> > and why.
> > >> >
> > >> > With one exception - the DetNet Architecture - the references
> > >> > fall in the
> > c

Re: [6tisch] rekeying the 6TiSCH network

[Pascal Thubert (pthubert)]

Hello Michael

I agree that the details of how it is done in practice belong to minimal 
security.
My expectation would be that we discuss times when it is appropriate to rekey, 
and what it takes to do that.

Out of my hat (but please come back with cases that I missed) I can see that:
 
- we need to rekey to expel undesired nodes.
- we need to rekey if a short address is reassigned to avoid nonce-replay 
attacks with an ASN in the past
- the ASN-based nonce never wraps in practice, but should we reset ASN -or 
allow it to go back in time - for whatever reason, we'd need to rekey as well.
- based on Mirja's comment - seconded by Benjamin - minimal security should be 
a normative reference since it expands on the security considerations

I think it does not hurt to have a word on that in the architecture, even if 
more details are found in minimal security

All the best,

Pascal

> -Original Message-
> From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Michael Richardson
> Sent: mardi 20 août 2019 22:03
> To: Pascal Thubert (pthubert) ; Benjamin Kaduk
> ; =?iso-8859-2?Q?Mali=B9a_Vu=E8ini=E6?=
> ; Tero Kivinen ; 6tisch@ietf.org
> Subject: Re: [6tisch] rekeying the 6TiSCH network
> 
> 
> Pascal Thubert (pthubert)  wrote:
> > I'm looking for a consensus on how to address the following review
> > comment on the 6TiSCH Architecture by Benjamin:
> 
> >> It would be good to see some architectural discussion about key
> >> management
> >> for the link-layer keys.  (Given that 802.15.4 leaves key management
> >> as out of
> >> scope, it is clearly our problem.)  Thus far I don't even have a sense
> >> for when it is
> >> possible to rotate a network's keys.
> 
> PT> I'll take that to a separate thread with Michael, Tero and Malisa. It
> PT> is certainly possible to rotate keys. We had a draft about rekeying
> PT> that went stale. We isolated cases where this is desirable in the
> PT> discussion on the minimal security draft. I'm unclear how deep we
> PT> need to go in this regards vs. what belongs to the minimal security
> PT> specification.
> 
> 6tisch-minimal-security has a section 8.2 "Parameter Update Exchange"
> Maybe it should include "(and Rekey)"
> 
> We further have section 8.4.3.1 and 8.4.3.2 to explain how to use that to 
> rekey
> the entire network.
> 
> I'm not sure what's in the Architecture document about this, but I'd rather 
> that it
> just said less.
> 
> --
> Michael Richardson , Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
> 

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Intelligent JP / validating the MASA

[Pascal Thubert (pthubert)]

Dear all:

I'm looking for a consensus on how to address the following review comment on 
the 6TiSCH Architecture by Benjamin:



> I'd like to see some discussion somewhere that the Join Proxy needs to take 
> care

> to not be an open redirector by which an unauthenticated pledge can attack

> arbitrary network elements (whether within the LLN or on the broader

> network), e.g., by performing some validation on the claimed MASA identifier.

> Similarly, that the JRC will be exposed to lots of untrusted input and needs 
> to be

> implemented in an especially robust manner.



Then again I'd like to discuss the split of what goes in the architecture and 
what goes in Minimal security or elsewhere.


What do you think?

Pascal

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] rekeying the 6TiSCH network

[Pascal Thubert (pthubert)]

Dear all:

I'm looking for a consensus on how to address the following review comment on 
the 6TiSCH Architecture by Benjamin:



> It would be good to see some architectural discussion about key management

> for the link-layer keys.  (Given that 802.15.4 leaves key management as out of

> scope, it is clearly our problem.)  Thus far I don't even have a sense for 
> when it is

> possible to rotate a network's keys.

>



To which I answered:


PT> I'll take that to a separate thread with Michael, Tero and Malisa. It is 
certainly possible to rotate keys. We had a draft about rekeying that went 
stale. We isolated cases where this is desirable in the discussion on the 
minimal security draft. I'm unclear how deep we need to go in this regards vs. 
what belongs to the minimal security specification.

What do you think?

Pascal
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

Back from vacations : )

I think I see your point Mirja. What we tried to do here is build a 
self-sufficient document at the architecture level.
The specs referenced (exception from DetNet and those which have both 
Architecture and specification content such as IPv6) are pointed because they 
implement the architecture, but reading them should not be necessary to 
understand the words in the architecture. I'll need a full pass to check if we 
did that right. 

All the best,

Pascal

> -Original Message-
> From: Mirja Kuehlewind 
> Sent: jeudi 8 août 2019 18:16
> To: Pascal Thubert (pthubert) 
> Cc: Suresh Krishnan ; Shwetha Bhandari
> ; 6tisch@ietf.org; 6tisch-cha...@ietf.org; The
> IESG ; draft-ietf-6tisch-architect...@ietf.org
> Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-6tisch-architecture-24: 
> (with
> DISCUSS and COMMENT)
> 
> See below.
> 
> > On 8. Aug 2019, at 18:05, Pascal Thubert (pthubert) 
> wrote:
> >
> > Hello Suresh and Mirja
> >
> > I’m happy to get recommendations on that topic. I understand Mirja’s
> recommendation on how to use normative refs; it makes sense, more so for std
> track. For informational, I’m still puzzled: Why call something normative in a
> document that is not establishing a standard?
> 
> Let me give you a simple example. An informational document that describes
> operational practice for protocol X, needs to have the reference to the spec
> describing protocol X as a normative reference because if you don’t know
> anything about the protocol X, you will not be able to understand the
> operational guidance given.
> 
> This is an easy example and I know that there are many cases where this is 
> less
> clear, however, it can definitely make sense to have normative references in
> informational document because it solely indicated which other documents are
> a MUST read in order to understand this document.
> 
> Mirja
> 
> 
> >
> > On the topic of refinement section 4 goes clearly deeper down than section 
> > 3.
> This is by design. We did not want to split and have to maintain and keep in 
> sync
> 2 documents. Also we got hints from you guys that overloading the IESG with
> many small documents was not the right way.
> >
> > Regards,
> >
> > Pascal
> >
> > Le 8 août 2019 à 16:01, Suresh Krishnan  a
> écrit :
> >
> >> Hi Mirja,
> >>
> >> On Thu, Aug 8, 2019, 6:29 AM Mirja Kuehlewind 
> wrote:
> >> Hi Pascal,
> >>
> >> See below.
> >>
> >> > On 7. Aug 2019, at 20:31, Pascal Thubert (pthubert)
>  wrote:
> >> >
> >> > Hello Mirja
> >> >
> >> > It certainly does not hurt to have a second look at how the split was 
> >> > done
> and why.
> >> >
> >> > With one exception - the DetNet Architecture - the references fall in the
> category of solutions which is a level below this spec in the design cascade.
> >> >
> >> > They explain how things are done when this spec tries to limit at what 
> >> > gets
> done and tries to be complete at it. We can point on the solution specs 
> because
> we only publish once the work is mostly done as opposed to a as a preamble to
> the work like in the case of DetNet. Then again that was a conscious decision 
> be
> the group which is more of an integrator than a creator.
> >> >
> >> > From that perspective only the DetNet Architecture would be normative,
> the other specs playing at a different level and not needed for understanding
> things at Architecture level.
> >> >
> >> > OTOH it would be grand for this spec to reference RFCs as opposed to
> drafts. That would help the reader. But then there are many solution draft and
> we could keep building new ones forever.
> >> >
> >> > I’m unsure what you mean by strongly wrt the fragment drafts. They have
> a purpose and the Architecture describes that purpose. Since it has an
> Architecture impact with per packet l’avales and stuff we had to explain it. 
> Did
> we go too far into explaining the solution?
> >>
> >> Yes, I had the feeling that is went too much into details a couple of 
> >> times.
> However, as I said, I didn’t read the document in depth and therefore can’t 
> give
> strong advise.
> >>
> >> @Suresh: Can you maybe have another look at the reference. If you are okay
> with the current approach, I’m happy to clear my discuss. Mainly wanted to
> double-check!
> >>
> >> I was fine with the current approach to references but I do see your 
> >> point. I
> will try to see if I can propose something to simplify this.
> >>
> >> Thanks
> >> Suresh

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Éric Vyncke's No Objection on draft-ietf-6tisch-architecture-24: (with COMMENT)

[Pascal Thubert (pthubert)]

Hello Eric : )

Many thanks for your kind review.
 
Please see below

> --
> COMMENT:
> --
> 
> Pascal,
> 
> Thank you for the hard work put into this document. It is extensive and
> comprehensive. I really appreciate this well-written document as it is clear
> (albeit long...), so, the COMMENTs and NITs are to improve the document
> quality and not as a negative criticism; your reply + comments will be welcome
> though.
> 
> Regards, Bien à toi,
> 
> -éric
> 
> == COMMENTS ==
> 
> -- Section 1 --
> Suggest to be more specific about the backbone: layer-2 or IP backbone ?

When a backbone router is used top proxy ND, then it is a L2 backbone. 
The architecture allows a more complex routed structure, if the backbone router 
redistributes in a routing protocol, e.g., using a L3 fat tree.
I guess it does not hurt to add a sentence that clarifies this.

proposal:


before <
   6TiSCH provides large scaling capabilities, which, in a number of
   scenarios, require the addition of a high-speed and reliable backbone
   and the use of IP version 6 (IPv6) [RFC8200].  The 6TiSCH
   Architecture leverages 6LoWPAN [RFC4944] to adapt IPv6 to the
   constrained media and RPL [RFC6550] for the distributed routing
   operations.

   The 6TiSCH Architecture introduces an IPv6 Multi-Link subnet model
   that is composed of a federating backbone, e.g., an Ethernet bridged
   network, and a number of IEEE Std. 802.15.4 TSCH low-power wireless
   networks federated and synchronized by Backbone Routers.
>

After <
The 6TiSCH Architecture relies on IPv6 [RFC8200] and the use of
   routing to provide large scaling capabilities.  The addition of a
   high-speed federating backbone adds yet another degree of scalability
   to the design.  The backbone is typically a Layer-2 transit Link,
   e.g., an Ethernet bridged network, but it can also be a more complex
   routed structure.

   The 6TiSCH Architecture introduces an IPv6 Multi-Link subnet model
   that is composed of a federating backbone and a number of IEEE Std.
   802.15.4 TSCH low-power wireless networks federated and synchronized
   by Backbone Routers.  If the backbone is a Layer-2 transit Link then
   the Backbone Routers can operate as an IPv6 Neighbor Discovery (IPv6
   ND) [RFC4861] proxy.

   The 6TiSCH Architecture leverages 6LoWPAN [RFC4944] to adapt IPv6 to
   the constrained media and RPL [RFC6550] for the distributed routing
   operations.


>

--

> 
> -- Section 2.1 --
> Please define 'PAN' before first use.

PT> Removed, was not so useful where used.


> The choice of 'ASN' in an IETF document was probably not the choice... ;-) I 
> was
> unable to understand the concept and use of layer-2 bundle by reading the
> definition. Let's hope it is defined/explained later... It is probably too 
> late to
> change now, but, this section is really too heavy and by alphabetical order, 
> so,
> its usefulness is reduced for first-time readers. Section 3 is rather easy to 
> read
> for similar explanations.

PT> Agreed. This is an IEEE term... no choice there. Updated definition to 
indicate that:

   ASN (Absolute Slot Number):  Defined in [IEEE802154], the ASN is the
   total number of timeslots that have elapsed since the
   Epoch Time when the TSCH network started.  Incremented by
   one at each timeslot.  It is wide enough to not roll over
   in practice.

> -- Section 3.2 --
> For my own curiosity, reducing mcast is always good of course but not critical
> on the backbone if it is wired Ethernet. So, why mentioning this fact in this
> memo?

PT> Arguable. If you consider modern fabrics with overlays, mcast is really 
detrimental. 
Even in flat networks, ARP/ ND related cast is one of the reasons why subnets 
can't scale beyond certain numbers, I'm hearing in the 10K order.
For a large factory we are aiming towards a goal of 100K nodes.
Also if the hop to the BBR is wireless, e.g., the BBR is an IOT gateway that 
connects to the backbone with Wi-Fi; and that hop would suffer from mcast.
Not sure you're asking for text though so I'd rather leave as is unless you 
hint me otherwise.

> -- Section 3.4 --
> Minor inconsistency between the list of the schedule management ways and the
> enumeration. Nothing critical though but confusing.

PT> fixed

>
 In "Neighbor-to-Neighbor
> Scheduling", perhaps replace "between adjacent routers" by "between adjacent
> peers" as the text is mainly about peers?

PT> agreed

> 
> -- Section 3.6 --
> It is probably useful to define what "feasable" means in the context of this
> memo. 

PT> "Feasible Successor" comes from the art of Distance Vector from which RPL 
inherits, namely JJ Garcia Luna Aceves 's DUAL.
DV has a feasibility condition, that determines that the peers's distance is 
such that if I give him the packet then I will not see t

Re: [6tisch] starting WGLC for draft-ietf-6tisch-enrollment-enhanced-beacon-02

[Pascal Thubert (pthubert)]

The WGLC is officially ended.

Authors: please publish a refresher if you saw any feedback (I did not).
Authors: please confirm whether any and all appropriate IPR disclosures 
required for full conformance with the provisions of BCP 78 and BCP 79 have 
already been filed. If not, explain why. You may for instance answer with "I'm 
not aware of any IPR that applies to this draft" or indicate a link to an IETF 
disclosure.
 Others: If you are aware of IPR that encumbers this draft, please reply to 
this mail with relevant information.

All the best,

Pascal

From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Pascal Thubert (pthubert)
Sent: vendredi 26 juillet 2019 19:32
To: 6tisch@ietf.org
Subject: [6tisch] starting WGLC for 
draft-ietf-6tisch-enrollment-enhanced-beacon-02

Dear all

This is officially starting a 3 weeks WGLC window for 
https://tools.ietf.org/html/draft-ietf-6tisch-enrollment-enhanced-beacon-02, a 
longer period than usual to cover possible vacation time.
Please send comments by August 16th 2019.

Many thanks in advance

The chairs

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] call for review: draft-ietf-6tisch-msf-04

[Pascal Thubert (pthubert)]

Great, Tengfei

This is very much what I was asking for.


Regards,

Pascal

Le 9 août 2019 à 13:05, Tengfei Chang 
mailto:tengfei.ch...@gmail.com>> a écrit :

Thanks Tero and Pascal for the comments!

I understand What Pascal and Tero are saying. According to the discussion above 
and during the IETF 105 6TiSCH meeting, I would add the following content in 
the next version of the draft in Rule of Celllist section:

Since  the Cell is randomly selected, there is a non-zero chance that several 
nodes in vicinity are using the same cells.
An implementer implements MSF MAY implement a CCA strategy to monitor the Tx 
cell before using it to avoid this situation.
The node MAY configure the Tx cell to be installed as Rx cell to listen any 
incoming frames.
Within a pre-defined time window, if there is no frames received, the Tx cell 
will replace the Rx cell to transmit frames.

The content will be something like this, we can rephrase it later.

Please let me know what you think. Thanks!

Tengfei


On Mon, Jul 22, 2019 at 5:35 PM Tero Kivinen 
mailto:kivi...@iki.fi>> wrote:
Pascal Thubert (pthubert) writes:
> In a 6TiSCH network, CCA is useless between synchronized devices because
> they’ll talk at the same time. So LBT must be done some other way.

Note, that 802.15.4 do allow doing CCA if TschCca was set on when
MLME-TSCHE-MODE.request primitive is called to turn TSCH mode on. In
that case the node will do CCA at macTsCcaOffset time for macTsCca,
and all this is done before the actual macTsTxOffset happens, i.e.,
before the node is supposed to send its frame. This CCA does not
protect against other nodes in the TSCH, but it will protect against
other users on the same band, thus it should be enough for the legal
LBT requirements.

See figure 6-30 of 802.15.4-2015 in Section 6.5.4.1 and Section
6.2.5.2 covering TSCH CCA algorithm.

> The bright side is that the future collision can be detected before it even
> happens. Doing CCA on cells before allocating them, etc… I think you must
> provide a method for that. A trade off would be to provide that method in the
> draft and make it optional.

Note, that doing CCA on cells is bit pointless, as that will only
detect someone inside the same syncronized network using that slot, it
will not detect anybody else. I think it would be better to get
information of allocated slots from some kind of centralized node,
keeping track of nodes allocated and making sure there is no
collisions inside that one network.

Also, you cannot use the normal TSCH CCA for that, as it is done
BEFORE the actual time for TSCH frame to be sent on the channel. I do
not think there is a good way to do that specified in the 802.15.4. In
theory you could do it by configuring the specific slot for receiving
before starting to use it for transmission, and enabling promiscuous
mode, so you get all frames even when they are not addressed to you.

So requiring such feature to be provided for 6TiSCH to work, might
make it so that not all radios can do this, depending how much of TSCH
is actually implemented on MAC and how much is implemented in upper
layer.
--
kivi...@iki.fi<mailto:kivi...@iki.fi>


--
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

Great!

We asked for that change at the time, and clearly it was implemented.
This means that the text in the Architecture is now obsolete and I’ll remove it.

Many thanks Tero.

Pascal

> Le 8 août 2019 à 23:58, Tero Kivinen  a écrit :
> 
> Benjamin Kaduk via Datatracker writes:
>> --
>> DISCUSS:
>> --
>> 
>> Section 4.3.4 asserts:
>> 
>>   [...]  We'll note that the Join
>>   Priority is now specified between 0 and 0x3F leaving 2 bits in the
>>   octet unused in the IEEE Std. 802.15.4e specification.  After
>>   consultation with IEEE authors, it was asserted that 6TiSCH can make
>>   a full use of the octet to carry an integer value up to 0xFF.
>> 
>> I'm extremely reluctant to publish this text in the IETF stream without
>> a citation.
> 
> IEEE Std 802.15.4-2015 says:
> 
> --
> 7.4.4.2 TSCH Synchronization IE
> 
> The TSCH Synchronization IE Content field shall be formatted as
> illustrated in Figure 7-50.
> 
>  +-+---+
>  |  Octets: 5  |   1   |
>  +-+---+
>  | ASN |  Join Metric  |
>  +-+---+
> 
> Figure 7-50 -- TSCH Synchronization IE Content field format
>   
> The ASN field contains the ASN corresponding to the timeslot in which
> the enhanced beacon is sent. The ASN is used as the Frame Counter for
> security operations if enabled.
> 
> The Join Metric field is an unsigned integer and shall be set to
> macJoinMetric.
> --
> 
> And
> 
> --
> 
> Section 8.4.2.2 TSCH-specific MAC PIB attributes
> 
> ...
> 
>   Table 8-83 -- TSCH-specific MAC PIB attributes
> 
> AttributeType Range   Description Default
> ...
> macJoinMetricInteger 0x00–0xff   The sum of one and the 1
> value of the Join Metric
> field from the TSCH
> Synchronization IE, 7.4.4.2,
> received in the Enhanced Beacon
> frame used by the device
> joining the network. If the
> device is the an endpoint, the
> value shall be set to zero.
> 
> --
> 
> So it is very clear that Join Metric can be any number between
> 0x00-0xff. 
> 
>>   scheduled cell:  A cell which is assigned a neighbor MAC address
>>   (broadcast address is also possible), and one or more of
>>   the following flags: TX, RX, shared, timeskeeping.  A
>> 
>> "timeskeeping" does not seem to be defined anywhere.
> 
> Timekeeping comes from the IEEE Std 802.15.4-2015 Section 7.4.4.3 TSCH
> Slotframe and Link IE:
> 
> --
>   The Timekeeping field shall be set to one if the link is to be used
>   for clock synchronization and shall be set to zero otherwise. RX
>   links shall have the Timekeeping field set to one.
> -- 
> kivi...@iki.fi
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

Hello Suresh and Mirja

I’m happy to get recommendations on that topic. I understand Mirja’s 
recommendation on how to use normative refs; it makes sense, more so for std 
track. For informational, I’m still puzzled: Why call something normative in a 
document that is not establishing a standard?

On the topic of refinement section 4 goes clearly deeper down than section 3. 
This is by design. We did not want to split and have to maintain and keep in 
sync 2 documents. Also we got hints from you guys that overloading the IESG 
with many small documents was not the right way.

Regards,

Pascal

Le 8 août 2019 à 16:01, Suresh Krishnan 
mailto:suresh.krish...@gmail.com>> a écrit :

Hi Mirja,

On Thu, Aug 8, 2019, 6:29 AM Mirja Kuehlewind 
mailto:i...@kuehlewind.net>> wrote:
Hi Pascal,

See below.

> On 7. Aug 2019, at 20:31, Pascal Thubert (pthubert) 
> mailto:pthub...@cisco.com>> wrote:
>
> Hello Mirja
>
> It certainly does not hurt to have a second look at how the split was done 
> and why.
>
> With one exception - the DetNet Architecture - the references fall in the 
> category of solutions which is a level below this spec in the design cascade.
>
> They explain how things are done when this spec tries to limit at what gets 
> done and tries to be complete at it. We can point on the solution specs 
> because we only publish once the work is mostly done as opposed to a as a 
> preamble to the work like in the case of DetNet. Then again that was a 
> conscious decision be the group which is more of an integrator than a creator.
>
> From that perspective only the DetNet Architecture would be normative, the 
> other specs playing at a different level and not needed for understanding 
> things at Architecture level.
>
> OTOH it would be grand for this spec to reference RFCs as opposed to drafts. 
> That would help the reader. But then there are many solution draft and we 
> could keep building new ones forever.
>
> I’m unsure what you mean by strongly wrt the fragment drafts. They have a 
> purpose and the Architecture describes that purpose. Since it has an 
> Architecture impact with per packet l’avales and stuff we had to explain it. 
> Did we go too far into explaining the solution?

Yes, I had the feeling that is went too much into details a couple of times. 
However, as I said, I didn’t read the document in depth and therefore can’t 
give strong advise.

@Suresh: Can you maybe have another look at the reference. If you are okay with 
the current approach, I’m happy to clear my discuss. Mainly wanted to 
double-check!

I was fine with the current approach to references but I do see your point. I 
will try to see if I can propose something to simplify this.

Thanks
Suresh
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

Hello Mirja

It certainly does not hurt to have a second look at how the split was done and 
why.

With one exception - the DetNet Architecture - the references fall in the 
category of solutions which is a level below this spec in the design cascade.

They explain how things are done when this spec tries to limit at what gets 
done and tries to be complete at it. We can point on the solution specs because 
we only publish once the work is mostly done as opposed to a as a preamble to 
the work like in the case of DetNet. Then again that was a conscious decision 
be the group which is more of an integrator than a creator.

From that perspective only the DetNet Architecture would be normative, the 
other specs playing at a different level and not needed for understanding 
things at Architecture level.

OTOH it would be grand for this spec to reference RFCs as opposed to drafts. 
That would help the reader. But then there are many solution draft and we could 
keep building new ones forever.

I’m unsure what you mean by strongly wrt the fragment drafts. They have a 
purpose and the Architecture describes that purpose. Since it has an 
Architecture impact with per packet l’avales and stuff we had to explain it. 
Did we go too far into explaining the solution?

Regards,

Pascal

> Le 7 août 2019 à 19:04, Mirja Kuehlewind  a écrit :
> 
> Hi Pascal,
> 
> The document status (informational) and the kind of references used are 
> completely independent of each other. A normative reference is a reference 
> that need to be considered in order to fully understand the document (or 
> fully implement a spec in case of PS). For me it seems that many drafts that 
> are currently listed as informative fall into that category. 
> 
> If you have a normative reference to a draft that also means that this 
> document will be published together with that draft and therefore will “wait” 
> for this draft in the RFC editor queue. That also gives the authors the 
> chance to double-check these dependencies before final publication (to make 
> sure the referenced draft content still fits to the content in your document).
> 
> If you have an informative reference to a draft, that reference will always 
> point to the draft version indicated. That can be fine as well but then there 
> should be no dependencies to the detailed content of final version of the 
> referenced draft.
> 
> As I said I’m not the person to make a final judgement call here, but your 
> reply below indicates to me that the concept of informative vs. normative was 
> not considered correctly and needs to be double-checked.
> 
> Mirja
> 
> 
>> On 7. Aug 2019, at 18:50, Pascal Thubert (pthubert)  
>> wrote:
>> 
>> Hello Mirja
>> 
>> Your time is appreciated, many thanks for considering this draft.
>> 
>> The 6TiSCH Architecture has been a WIZp throughout the lifespan of the WG. 
>> It may be seen as its main product, most of the needed components being 
>> requested from other WGs.
>> 
>> This may be unusual but that was the plan from the start: produce a rather 
>> generic iot stack out of IETF components, which when we started were full of 
>> gaps and overlaps.
>> 
>> 5 years later we have open source implementations that went through multiple 
>> interop tests, all under the group’s monitoring.
>> 
>> So the Architecture is not there to tell us what to do next but rather how 
>> what we (many iot relater WGs) built and how it works together.
>> 
>> The decision to go for informational is not mine. But what’s the point to 
>> have normative References in an informational draft?
>> 
>> Again, many thanks.
>> 
>> Pascal
>> 
>>> Le 7 août 2019 à 17:48, Mirja Kühlewind via Datatracker  
>>> a écrit :
>>> 
>>> Mirja Kühlewind has entered the following ballot position for
>>> draft-ietf-6tisch-architecture-24: Discuss
>>> 
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>> 
>>> 
>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture/
>>> 
>>> 
>>> 
>>> --
>>> DISCUSS:
>>> --
>>> 
>>> I onl

Re: [6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

Hello Mirja

Your time is appreciated, many thanks for considering this draft.

The 6TiSCH Architecture has been a WIZp throughout the lifespan of the WG. It 
may be seen as its main product, most of the needed components being requested 
from other WGs.

This may be unusual but that was the plan from the start: produce a rather 
generic iot stack out of IETF components, which when we started were full of 
gaps and overlaps.

5 years later we have open source implementations that went through multiple 
interop tests, all under the group’s monitoring.

So the Architecture is not there to tell us what to do next but rather how what 
we (many iot relater WGs) built and how it works together.

The decision to go for informational is not mine. But what’s the point to have 
normative References in an informational draft?

Again, many thanks.

Pascal

> Le 7 août 2019 à 17:48, Mirja Kühlewind via Datatracker  a 
> écrit :
> 
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-6tisch-architecture-24: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> I only had a quick read of this document, however, it seems to me that there
> are strong dependencies on a whole bunch of drafts, that are only listed as
> informational. I don't have a deep enough understanding to make a final
> judgement of which draft would need to be listed as normative references,
> however, I wanted to raise this point on the discuss level in order to ensure
> that this is considered before publication.
> 
> To give an example: Section 4.6.3 goes quite seep into details of what's
> described in [I-D.ietf-6lo-fragment-recovery]. However as long as
> [I-D.ietf-6lo-fragment-recovery] is not published yet, the 6tisch arch should
> probably not rely on the content of this draft that strongly. Putting
> [I-D.ietf-6lo-fragment-recovery] as a normative reference ensures that this
> draft will not be published before [I-D.ietf-6lo-fragment-recovery].
> 
> 
> --
> COMMENT:
> --
> 
> As I said, I only had a rather brief read, however, I had a bit of problems to
> follow exactly which parts of the architecture rely on existing protocols and
> mechanisms and where 6tsch actually needs to define new approaches. Maybe a
> short, even higher-level overview than section 3, could address this and help
> the reader.
> 
> 
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] ASN replay attack -- proposed text

[Pascal Thubert (pthubert)]

All good, I expected it and wanted confirm : )

All the best,

Pascal

> -Original Message-
> From: Mališa Vučinić 
> Sent: mardi 30 juillet 2019 05:24
> To: Pascal Thubert (pthubert) 
> Cc: Thomas Watteyne ; 6tisch <6tisch@ietf.org>
> Subject: Re: ASN replay attack -- proposed text
> 
> Pascal,
> 
> As Tero outlined, this information is typically available as the metadata to 
> the
> frame being received. It is up to the implementations to ensure that such
> information is available when processing the frame with a delay, otherwise
> things won’t really work..
> 
> Mališa
> 
> > On 26 Jul 2019, at 23:20, Pascal Thubert (pthubert) 
> wrote:
> >
> > Agreed:
> >
> > I'm wondering about the delayed security processing. That processing may
> be delayed beyond the current ASN. Is the ASN of the receive time attached to
> the frame as a meta of sorts to enable the delayed validation?
> >
> > All the best,
> >
> > Pascal
> >
> >> -Original Message-
> >> From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Thomas Watteyne
> >> Sent: vendredi 26 juillet 2019 17:08
> >> To: Mališa Vučinić 
> >> Cc: 6tisch <6tisch@ietf.org>
> >> Subject: Re: [6tisch] ASN replay attack -- proposed text
> >>
> >> Malisa,
> >> The text IMO explains both the problem and the solution very well,
> congrats.
> >> Thomas
> >>
> >>> On 26 Jul 2019, at 20:23, Mališa Vučinić  wrote:
> >>>
> >>> Dear all,
> >>>
> >>> I worked on the initial version of the text describing the ASN replay 
> >>> attack
> >> and its resolution discussed during the Montreal meeting.
> >>>
> >>> The text can be found at:
> >>>
> >>> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-
> >> security/commits/4ea5f58b1a3245a1e2a2b46f95f0fd48b2f4bb31
> >>>
> >>> Please let me know if you have any comments.
> >>>
> >>> Mališa
> >>> ___
> >>> 6tisch mailing list
> >>> 6tisch@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/6tisch
> >> ___
> >> 6tisch mailing list
> >> 6tisch@ietf.org
> >> https://www.ietf.org/mailman/listinfo/6tisch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] ASN replay attack -- proposed text

[Pascal Thubert (pthubert)]

Agreed:

I'm wondering about the delayed security processing. That processing may be 
delayed beyond the current ASN. Is the ASN of the receive time attached to the 
frame as a meta of sorts to enable the delayed validation?

All the best,

Pascal

> -Original Message-
> From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Thomas Watteyne
> Sent: vendredi 26 juillet 2019 17:08
> To: Mališa Vučinić 
> Cc: 6tisch <6tisch@ietf.org>
> Subject: Re: [6tisch] ASN replay attack -- proposed text
> 
> Malisa,
> The text IMO explains both the problem and the solution very well, congrats.
> Thomas
> 
> > On 26 Jul 2019, at 20:23, Mališa Vučinić  wrote:
> >
> > Dear all,
> >
> > I worked on the initial version of the text describing the ASN replay attack
> and its resolution discussed during the Montreal meeting.
> >
> > The text can be found at:
> >
> > https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-
> security/commits/4ea5f58b1a3245a1e2a2b46f95f0fd48b2f4bb31
> >
> > Please let me know if you have any comments.
> >
> > Mališa
> > ___
> > 6tisch mailing list
> > 6tisch@ietf.org
> > https://www.ietf.org/mailman/listinfo/6tisch
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] draft-tiloca-6tisch-robust-scheduling

[Pascal Thubert (pthubert)]

Dear Pat:

This is about 
https://datatracker.ietf.org/doc/draft-tiloca-6tisch-robust-scheduling/
This work was presented at 6TiSCH at this and previous IETFs, and we wanted to 
follow up with you and the 6TiSCH IG.
Basically, we recognize that the technique can be valuable to protect the TSCH 
medium against targeted PHY DOS attacks.
We also recognize that it cannot be implemented above the MAC and thus belongs 
to the IEEE 802.15.4, not to the IETF.

So we're querying you to see if there is interest on the IEEE side to follow 
suite to this idea.

Many thanks

Pascal
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] starting WGLC for draft-ietf-6tisch-enrollment-enhanced-beacon-02

[Pascal Thubert (pthubert)]

Dear all

This is officially starting a 3 weeks WGLC window for 
https://tools.ietf.org/html/draft-ietf-6tisch-enrollment-enhanced-beacon-02, a 
longer period than usual to cover possible vacation time.
Please send comments by August 16th 2019.

Many thanks in advance

The chairs

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Agenda bashing

[Pascal Thubert (pthubert)]

Dear all

Please note that the agenda for 6TiSCH @ IETF 105 
(https://datatracker.ietf..org/doc/agenda-105-6tisch/) was amended to place 
Marco at the very end in order to address a WG collision.

All the best

Pascal

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] call for review: draft-ietf-6tisch-msf-04

[Pascal Thubert (pthubert)]

Hello Tengfei:

When the schedule gets more loaded the chances will become bad. Xavi 
demonstrated that a half loaded CDU matrix causes the allocation to pretty much 
never converge.

I do not agree that the schedule will necessarily be lightly used. Note that 
LBT is a mandatory practice in the ISM bands in Europe - unless you have a 
very, very low duty cycle. There’s a reason for that. Politeness is important 
in the ISM band. I do not agree that all nodes will have a very low duty cycle 
either (think, the root).

In a 6TiSCH network, CCA is useless between synchronized devices because 
they’ll talk at the same time. So LBT must be done some other way.

The bright side is that the future collision can be detected before it even 
happens. Doing CCA on cells before allocating them, etc… I think you must 
provide a method for that. A trade off would be to provide that method in the 
draft and make it optional.

All the best,

Pascal

From: Tengfei Chang 
Sent: mercredi 17 juillet 2019 08:32
To: Pascal Thubert (pthubert) 
Cc: 6tisch@ietf.org
Subject: Re: [6tisch] call for review: draft-ietf-6tisch-msf-04

Hi Pascal,

It is good for me to confirm it is about the hidden terminal collision issue. 
Great!

For your first question that where those cells come from, it is not mentioned 
in the MSF draft, but what I assumed is using the CDU matrix.

I understand what you are saying and agree the collision could happen without 
performing CCA.
But with 101 slotframe length and 16 channels,  the chance to choose the same 
cell (slot,channel) for two nodes in the same propagation range is around 
1/1616.
Though, along more cells are scheduled, the probability goes higher,  it's fine 
with the fact most of the application doesn't have much traffic load (less than 
packet / second).

The complexity to introduce CCA to have a collision-free schedule looks for me 
not worthy, comparing to use simple, but maybe long discovering process 
strategy, according to my opinion.

Tengfei

On Wed, Jul 17, 2019 at 4:02 PM Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:
Hello Tengfei:

You start from a cell list from which a parent can select cells to talk with 
its children. But where do those cells come from?
Is that all the CDU matrix? Or a chunk off it (see discussion in Archie)? Or 
just a pseudo-random selection, possibly dependent on that parent’s MAC?

Bottom line is that unless there is a central entity that allocates a non 
-overlapping chunk for each parent there might be a cell CellA that parent P1 
wants to use with child C1 and parent P2 wants to use with child C2. If P1 
allocates CellA first, then P2 should discover that and refrain from using it. 
For that, P2 needs to monitor (CCA) CellA before it allocates it. This is the 
same idea as listen-before-talk but applied to cell allocation. Ideally, once a 
parent proposes a cell to a child for parent-> child communication, the child 
should also listen to the cell before accepting in order to avoid the hidden 
terminal collision.

The process of discovering later that the cell collisions is long and 
inefficient. If the cells are not used a lot it will take time. I disagree that 
it can be the sole procedure to avoid collisions.

All the best,

Pascal

From: Tengfei Chang mailto:tengfei.ch...@gmail.com>>
Sent: mercredi 17 juillet 2019 06:12
To: Pascal Thubert (pthubert) mailto:pthub...@cisco.com>>
Cc: 6tisch@ietf.org<mailto:6tisch@ietf.org>
Subject: Re: [6tisch] call for review: draft-ietf-6tisch-msf-04

Hi Pascal,

For the synchronization, I agree. It should be listening for a certain period 
of time and then choose which EB to use for synchronizing. Will update in the 
next version.

For the rule of celllist:

  *   > Not the same problem. Think about this, where does the list of free 
cells come from? How does the parent decided let me propose cells 5, 6, 7 and 
10?

Any cells that not being used by the node or marked as "locked" are a candidate 
cell in the celllist. The parent just randomly select several cells from them.



  *   > One possibility is that the controller has given them away as a chunk 
of cells that the parent manages, we have text in Archie for that.
  *   > The other is that the parent picks them pseudo randomly. Which means 
that another parent next to him might pick the same. If that is the case they 
will collide

Actually I didn't get what you say here about the parent and another parent , 
you mean a node has two parents?

The 6P packets are negotiated only with one hop neighbor node, I agree the same 
cells could be scheduled  by other links in the same propagation range, which 
is the "hidden terminal" issue.  MSF won't trying to resolve it when choosing 
cell. It could  later on use the reallocation process to move the colliding 
cell to another place as mentioned in 
https://tools.ietf.org/html/draft-ietf-6tisch-msf-05#section-5.3

For each node

Re: [6tisch] New datatracker feature: Allow presenters to upload slides

[Pascal Thubert (pthubert)]

Dear all:

On the side, please keep in mind that the chromebooks only play PDFs, and use 
that form to upload your slides.

All the best,

Pascal

From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Pascal Thubert (pthubert)
Sent: lundi 15 juillet 2019 07:22
To: lp-...@ietf.org; 6tisch@ietf.org
Subject: [6tisch] Fwd: New datatracker feature: Allow presenters to upload 
slides

Dear all,

Please see below, you can now upload your slides directly !
Regards,

Pascal

Début du message transféré :
Expéditeur: Robert Sparks mailto:rjspa...@nostrum.com>>
Date: 12 juillet 2019 à 17:51:56 UTC+2
Destinataire: IETF WG Chairs mailto:wgcha...@ietf.org>>
Objet: New datatracker feature: Allow presenters to upload slides
Shortly after IETF 104, we added the ability for presenters to upload slides 
and suggesting to the chairs that they be added to a session.

On the meeting materials page for a group (for example 
<https://datatracker.ietf.org/meeting/105/session/stir>) anyone logged in who 
is not a chair/secretary for the group gets a [Suggest New Slides] button.

When they upload slides using that, the chairs will get email, and the 
suggestions will appear in a new block on that page.

Chairs can then accept or reject each suggestion.

RjS
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] call for review: draft-ietf-6tisch-msf-04

[Pascal Thubert (pthubert)]

Hello Tengfei:

You start from a cell list from which a parent can select cells to talk with 
its children. But where do those cells come from?
Is that all the CDU matrix? Or a chunk off it (see discussion in Archie)? Or 
just a pseudo-random selection, possibly dependent on that parent’s MAC?

Bottom line is that unless there is a central entity that allocates a non 
-overlapping chunk for each parent there might be a cell CellA that parent P1 
wants to use with child C1 and parent P2 wants to use with child C2. If P1 
allocates CellA first, then P2 should discover that and refrain from using it. 
For that, P2 needs to monitor (CCA) CellA before it allocates it. This is the 
same idea as listen-before-talk but applied to cell allocation. Ideally, once a 
parent proposes a cell to a child for parent-> child communication, the child 
should also listen to the cell before accepting in order to avoid the hidden 
terminal collision.

The process of discovering later that the cell collisions is long and 
inefficient. If the cells are not used a lot it will take time. I disagree that 
it can be the sole procedure to avoid collisions.

All the best,

Pascal

From: Tengfei Chang 
Sent: mercredi 17 juillet 2019 06:12
To: Pascal Thubert (pthubert) 
Cc: 6tisch@ietf.org
Subject: Re: [6tisch] call for review: draft-ietf-6tisch-msf-04

Hi Pascal,

For the synchronization, I agree. It should be listening for a certain period 
of time and then choose which EB to use for synchronizing. Will update in the 
next version.

For the rule of celllist:

  *   > Not the same problem. Think about this, where does the list of free 
cells come from? How does the parent decided let me propose cells 5, 6, 7 and 
10?

Any cells that not being used by the node or marked as "locked" are a candidate 
cell in the celllist. The parent just randomly select several cells from them.



  *   > One possibility is that the controller has given them away as a chunk 
of cells that the parent manages, we have text in Archie for that.
  *   > The other is that the parent picks them pseudo randomly. Which means 
that another parent next to him might pick the same. If that is the case they 
will collide

Actually I didn't get what you say here about the parent and another parent , 
you mean a node has two parents?

The 6P packets are negotiated only with one hop neighbor node, I agree the same 
cells could be scheduled  by other links in the same propagation range, which 
is the "hidden terminal" issue.  MSF won't trying to resolve it when choosing 
cell. It could  later on use the reallocation process to move the colliding 
cell to another place as mentioned in 
https://tools.ietf.org/html/draft-ietf-6tisch-msf-05#section-5.3

For each node, as long as those cells are free to allocate according to its own 
schedule, that's fine.  If there are two on going 6P transactions for one node 
with different neighbors, the "locked" feature can resolve it.


  *   > This is an impolite behavior, the sort why we do CCA / LBT. In TSCH CCA 
and LBT are useless between synchronized nodes within a cell, but they can be 
useful before pseudo randomly grabbing a cell to add to the schedule. That cell 
should be observed using CCA for a while before it is proposed to the child in 
6P. IOW there should be a pool of cells that are not used (yet) but observed 
(CCA) so you know you can allocate them safely later.

Tengfei


On Wed, Jul 10, 2019 at 11:54 AM Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:
Hello Tengfei

I think you missed my points


>The text was not expected to become normative as is; obviously the usual 
> ways apply like time out if some but not all beacons are received and sync to 
> the best.

>

Yes, I agree with what you said, I replied with a wrong typing word. What I 
mean is: I have changed the sentence as you suggested:
It's rephrased as:


During this step, the pledge SHOULD NOT synchronize until it received

   enough EB from the network it wishes to join.


>I meant if you are configured to get 10 beacons but after an hour you get 
> only one, will you wait for 1000 years?

>  During this step, the pledge SHOULD NOT synchronize until it received

> enough EB from the network it wishes to join or times out trying





And here there should be an idea of a value for a number of beacons and a time 
out value. IESG reviews will ask that anyway so you better have something 
meaningful already.


 “
8<https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-8>.  Rules for 
CellList

“
Maybe add a rule to listen to the cells for a few slotframes to ensure that 
they are not used by neighbors. This can be done proactively, like the node 
monitors the 5 randomly chosen cells all the time, even when there is no excess 
traffic, so a list of empty cells is ready when needed.

I think it's not necessary to listen on the

[6tisch] Fwd: New datatracker feature: Allow presenters to upload slides

[Pascal Thubert (pthubert)]

Dear all,

Please see below, you can now upload your slides directly !

Regards,

Pascal

Début du message transféré :

Expéditeur: Robert Sparks mailto:rjspa...@nostrum.com>>
Date: 12 juillet 2019 à 17:51:56 UTC+2
Destinataire: IETF WG Chairs mailto:wgcha...@ietf.org>>
Objet: New datatracker feature: Allow presenters to upload slides

Shortly after IETF 104, we added the ability for presenters to upload slides 
and suggesting to the chairs that they be added to a session.

On the meeting materials page for a group (for example 
) anyone logged in who 
is not a chair/secretary for the group gets a [Suggest New Slides] button.

When they upload slides using that, the chairs will get email, and the 
suggestions will appear in a new block on that page.

Chairs can then accept or reject each suggestion.

RjS

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Tentative Agenda for IETF 105

[Pascal Thubert (pthubert)]

Dear all:

We posted the tentative agenda at 
https://datatracker.ietf.org/doc/agenda-105-6tisch/
I understand that all the presenter will be showing up person, so there is no 
speaker request to be done to meetecho.
Please check the agenda whether you have the speaking position you expected and 
come back to us in case of an issue.
Mališa Vučinić will be sitting next to me and Thomas will join remotely via 
meetecho.

See you in Montreal!

Pascal

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] TSCH and CCM security proofs

[Pascal Thubert (pthubert)]

Many thanks Tero. 

Do you have an intention to add text like this in a draft or in annex of a 
draft?

All the best,

Pascal

> -Original Message-
> From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Tero Kivinen
> Sent: mercredi 10 juillet 2019 23:47
> To: 6tisch@ietf.org
> Subject: [6tisch] TSCH and CCM security proofs
> 
> When I was doing 802.15.4 revision review, I found out that the Annex B says
> that security proofs for CCM* only apply when nonce contains security level.
> In TSCH mode nonce, the nonce does NOT include security level so the CCM*
> security proofs cannot be used, thus it needs to revert back to normal CCM
> security proofs, and that means that same key cannot be used with different
> mic lengths. I.e., if you want to use MIC-32, MIC-64, and MIC-128 you must
> use different keys for each of them.
> 
> With non-TSCH mode it is safe to use same key for all of them, and the
> security proofs still work. With TSCH not so much.
> 
> I do not think there is any practical attack, as the security axiliary header
> which is part of the MIC does contain the security level even in TSCH case, 
> but
> perhaps we still want to mandate in 6tisch that different key lengths MUST
> use different keys just to keep in sync with CCM security proofs.
> 
> This is text that has been there since 2006, but which I did just noticed now,
> and which those who specified TSCH nonce generation also had missed. I
> noticed it now when I started making proposed changes to fix the text and
> remove all references to M=0 case, as we did remove encrypt only feature in
> 2015.
> 
> So from 802.15.4-2015:
> 
> --
> B.4.3 Restrictions
> 
> All implementations shall limit the total amount of data that is encrypted
> with a single key. The CCM* encryption and authentication transformation
> shall invoke not more than 2^61 block cipher encryption function invocations
> with the same key in total.
> 
> The CCM* decryption and authentication checking transformation shall not
> expose any information if any verification check fails. The only information
> that may be exposed in this case is that the authenticity verification
> transformation failed; all other information, such as the purported plaintext,
> shall be destroyed.
> 
> NOTE 1 — With regard to security of the CCM* mode of operation, the
> CCM* mode coincides with the original CCM mode specification (ANSI
> X9.63-2001 [B2]) for messages that require authentication and, possibly,
> encryption, but also offers support for messages that require only encryption.
> Moreover, it can be used in implementation environments for which the use
> of variable-length authentication tags, rather than fixed-length 
> authentication
> tags only, is beneficial. As with the CCM mode, the CCM* mode requires only
> one key. The CCM* specification differs from the CCM specification, as
> follows:
> 
> — The CCM* mode allows the length of the Authentication field M to be
>   zero as well (the value M = 0 corresponding to disabling
>   authenticity because then the Authentication field is the empty
>   string).
> 
> — The CCM* mode imposes a further restriction on the nonce N: it shall
>   encode the potential values for M so that one can uniquely determine
>   from N the actually used value of M.
> 
> As a result, if M is fixed and the value M = 0 is not allowed, then there are 
> no
> additional restrictions on N, in which case the CCM* mode reduces to the
> CCM mode. In particular, the proof of the CCM mode applies (Jonsson [B7]
> and [B8]).
> 
> For fixed-length authentication tags, the CCM* mode is equally secure as the
> original CCM mode. For variable-length authentication tags, the
> CCM* mode completely avoids, by design, the vulnerabilities that do apply to
> the original CCM mode.
> 
> For fixed-length authentication tags, the security proof of the original CCM
> mode carries over to that of the CCM* mode (also for M = 0), by observing
> that the proof of the original CCM mode relies on the following properties,
> which slightly relax those stated in Jonsson [B7] and [B8] (relaxed property
> indicated in italics):
> 
> 
> — The B_0 field uniquely determines the value of the nonce N.
> 
> — The authentication transformation operates on input strings B_0 ||
>   B_1 || B_2 || ... || B_t from which one can uniquely determine the
>   input strings a and m (as well as the nonce N). In fact, for any two
>   input strings corresponding to distinct triples (N, m, a), neither
>   one is a prefix string of the other.
> 
> — All the A_i fields are distinct from the B_0 fields that are
>   actually used (over the lifetime of the key), as those have a Flags
>   field with a nonzero encoding of M in the positions where all A_i
>   fields have an all-zero encoding of the integer 0.
> 
> Hence, if M is fixed, then the CCM* mode offers the same security properties
> as the original CCM mode: confidentiality over the inp

Re: [6tisch] call for review: draft-ietf-6tisch-msf-04

[Pascal Thubert (pthubert)]

Hello Tengfei

I think you missed my points


>The text was not expected to become normative as is; obviously the usual 
> ways apply like time out if some but not all beacons are received and sync to 
> the best.

>

Yes, I agree with what you said, I replied with a wrong typing word. What I 
mean is: I have changed the sentence as you suggested:
It's rephrased as:


During this step, the pledge SHOULD NOT synchronize until it received

   enough EB from the network it wishes to join.


ØI meant if you are configured to get 10 beacons but after an hour you get 
only one, will you wait for 1000 years?

Ø  During this step, the pledge SHOULD NOT synchronize until it received

Ø enough EB from the network it wishes to join or times out trying





And here there should be an idea of a value for a number of beacons and a time 
out value. IESG reviews will ask that anyway so you better have something 
meaningful already.


 “
8.  Rules for 
CellList

“
Maybe add a rule to listen to the cells for a few slotframes to ensure that 
they are not used by neighbors. This can be done proactively, like the node 
monitors the 5 randomly chosen cells all the time, even when there is no excess 
traffic, so a list of empty cells is ready when needed.

I think it's not necessary to listen on the cells because when the 6P 
transaction starts , those cells should be locked and not be applied for other 
6P transactions.



  *   The point is that another pair of devices may have negotiated a cell that 
shows in the list, which you may discover if you screen the cells you want to 
use before you start using them.
  *   It really depends if you have a pool of cells that you own (e.g., admin) 
or just grab them pseudorandomly. In the latter case no checking the cells is 
impolite, and checking them just before using them may miss a partial usage. 
Listening to a pool of cell even when you do not allocate them is safer.


I think this feature is defined in 6TOP  (RFC8480) with the term locked:


   Nodes A and B MAY support having two transactions going on at the

   same time, one in each direction.  Similarly, a node MAY support

   concurrent 6P Transactions with different neighbors.  In this case,

   the cells involved in an ongoing 6P Transaction MUST be "locked"

   until the transaction finishes.  ..

   If the requested cells are locked, it MUST reply to

   that request with a 6P Response with return code RC_ERR_LOCKED (as

   per Figure 38).  The node receiving RC_ERR_BUSY or RC_ERR_LOCKED MAY

   implement a retry mechanism as defined by the SF.



  *   Not the same problem. Think about this, where does the list of free cells 
come from? How does the parent decided let me propose cells 5, 6, 7 and 10?
  *   One possibility is that the controller has given them away as a chunk of 
cells that the parent manages, we have text in Archie for that.
  *   The other is that the parent picks them pseudo randomly. Which means that 
another parent next to him might pick the same. If that is the case they will 
collide
  *   This is an impolite behavior, the sort why we do CCA / LBT. In TSCH CCA 
and LBT are useless between synchronized nodes within a cell, but they can be 
useful before pseudo randomly grabbing a cell to add to the schedule. That cell 
should be observed using CCA for a while before it is proposed to the child in 
6P. IOW there should be a pool of cells that are not used (yet) but observed 
(CCA) so you know you can allocate them safely later.

Thanks a lot again for reviewing the draft and the comments!

That’s a great spec  : )


Pascal

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] call for review: draft-ietf-6tisch-msf-04

[Pascal Thubert (pthubert)]

Hello Tengfei
tions address is correct. Thanks!


“

   During this step, the pledge MAY synchronize to any EB it receives

   from the network it wishes to join.
“
In TSCH, time creates an event horizon whereby one only hears transmissions 
that start during guard time around the scheduled Rx time. If the text quoted 
above means only listen to timeslots that are aligned to the time in the 
particular EB, then the node will no more hear beacons that are not aligned 
with this. E.g., an attacker could offset EBs by 2ms from the network and nodes 
that synchronize will not hear other beacons any more. So a suggestion is that 
a node that listen to beacons does not synchronize till it has heard the count 
of beacons it is supposed to get.

Thanks a lot for the comments. I have checked the sentence as  what you 
suggested.


ØThe text was not expected to become normative as is; obviously the usual 
ways apply like time out if some but not all beacons are received and sync to 
the best.

Ø

 “
8.  Rules for 
CellList

“
Maybe add a rule to listen to the cells for a few slotframes to ensure that 
they are not used by neighbors. This can be done proactively, like the node 
monitors the 5 randomly chosen cells all the time, even when there is no excess 
traffic, so a list of empty cells is ready when needed.

I think it's not necessary to listen on the cells because when the 6P 
transaction starts , those cells should be locked and not be applied for other 
6P transactions.



  *   The point is that another pair of devices may have negotiated a cell that 
shows in the list, which you may discover if you screen the cells you want to 
use before you start using them.
  *   It really depends if you have a pool of cells that you own (e.g., admin) 
or just grab them pseudorandomly. In the latter case no checking the cells is 
impolite, and checking them just before using them may miss a partial usage. 
Listening to a pool of cell even when you do not allocate them is safer.


“
6P Timeout Value

“
I guess it is per peer? Shouldn’t it evolve like the RTO in RFC 6298 ?

I think it's different from the RTO in RFC6298. In stead of traffic congestion 
control, the Timeout here is mostly influenced by one hop link quality.

Which evolves and your value may track that, else it can be very big.

Thanks a lot again for reviewing the draft and the comments!

That’s a great spec  : )


Pascal
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] call for review: draft-ietf-6tisch-msf-04

[Pascal Thubert (pthubert)]

Hello Tengfei

Many thanks for this update : )

Please find some comments below


“
   To ensure there is enough bandwidth available on the minimal cell, a
   node implementing MSF SHOULD enforce some rules for limiting the
   traffic of broadcast frames.  For example, a Trickle Timer defined in
   [RFC6550] MAY be applied on DIOs.  
However, this behvaior is
   implementation-specific which is out of the scope of MSF.

“
As you point out that text does not really belong here. Maybe just say that the 
normal operation of this spec requires some bandwidth available, e.g., on the 
minimal cell.
Typo in behavior


“4.1.  Start 
State
“
This phase also includes a 6LoWPAN ND phase to exchange link local addresses 
with the JP and later with the 6LR. Seems that some implementation bypass that 
but that’s really not clean. Suggestion to add a reference to 
https://tools.ietf.org/html/draft-ietf-6tisch-architecture-24#section-4.2 to 
describe that phase and say that it requires both minimal sec ad 6LoWPAN ND 
(now RFC 8505).


“

  Autonomous Tx Cell (AutoTxCell), one cell at a

  [slotOffset,channelOffset] computed as a hash of the layer 2 EUI64

  source address in the frame to be transmitted (detailed in

  Section 
4.4).  Its 
cell options bits are assigned as TX=1, RX=0,

  SHARED=1.
“
You mean the destination address as opposed to source address?


“

   During this step, the pledge MAY synchronize to any EB it receives

   from the network it wishes to join.
“
In TSCH, time creates an event horizon whereby one only hears transmissions 
that start during guard time around the scheduled Rx time. If the text quoted 
above means only listen to timeslots that are aligned to the time in the 
particular EB, then the node will no more hear beacons that are not aligned 
with this. E.g., an attacker could offset EBs by 2ms from the network and nodes 
that synchronize will not hear other beacons any more. So a suggestion is that 
a node that listen to beacons does not synchronize till it has heard the count 
of beacons it is supposed to get.


“
4.5.  Step 4 
- Acquiring a RPL rank


   Per [RFC6550], the joined node receives 
DIOs, computes its own rank,
   and selects a preferred parent.

“

Suggestion to uppercase Rank like in RFC 6550


“
8.  Rules for 
CellList

“
Maybe add a rule to listen to the cells for a few slotframes to ensure that 
they are not used by neighbors. This can be done proactively, like the node 
monitors the 5 randomly chosen cells all the time, even when there is no excess 
traffic, so a list of empty cells is ready when needed.


“
6P Timeout Value

“
I guess it is per peer? Shouldn’t it evolve like the RTO in RFC 6298 ?


“

   | IANA_6TISCH_SFID_MSF | Minimal Scheduling Function | RFC |
   |  | (MSF)   | (NOTE:this) |

“

  *   maybe

   | IANA_6TISCH_SFID_MSF | Minimal Scheduling Function | RFC_THIS|
   |  | (MSF)   | |


All the best,

Pascal

From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Tengfei Chang
Sent: mardi 2 juillet 2019 12:57
To: 6tisch@ietf.org
Subject: [6tisch] call for review: draft-ietf-6tisch-msf-04

Dear all,

As you may noticed that a new version of MSF is just published at here:
https://tools.ietf.org/html/draft-ietf-6tisch-msf-04
There are some moderate changes comparing to previous one.

Mainly in two aspects:

1. change the concept of autonomous cell

In the new version, there will be two type of autonomous cells:
- autoTxCell, which is scheduled on demand for just transmitting
-autoTxCell, which is schedule permanently, for just receiving
(the previous version the autonomous cell are used as bidirectional)

More details about how to use those autonomous cell is available in the draft.

2. re-added the downstream traffic adaptation feature

Though, there are cases that the node doesn't receive packet because of 
collision, we assume the influence won't be much to adapt the downstream 
traffic.
We will evaluate the performance of this changes.

We are targeting to have a new version before the submission deadline.
During the time, we will evaluate the v4 MSF and would like to have your 
comments as well.

Thanks in advance!

Tengfei

--
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [6lo] ND cache entries creation on first-hop routers

[Pascal Thubert (pthubert)]

Sorry Brian I miss your point.

The discussion here is to find a way for the node to autoconf an address and 
then notice the router(s) proactively so the ND NCE is ready when the first 
packet comes from the outside for this node.

I agree wholeheartedly with Jen’s requirement.

I agree less with the idea of overstretching ND as it stands to achieve this, 
for reasons I gave already. So prepopulate the NCE, yes, but do it right with 
protocol elements that guarantee a state that is accurate, secure, and 
persistent for a committed lifetime, not with yet another patch to the old 
structure.

I’m interested to have a parallel discussion on where RFC 8505 can not apply. 
In the products and use cases I’m aware of, it could, since we are actually 
faking it by snooping ND and DHCP to achieve similar but less accurate results.

Take care,

Pascal

> Le 3 juil. 2019 à 22:39, Brian E Carpenter  a 
> écrit :
> 
> On 03-Jul-19 20:13, Pascal Thubert (pthubert) wrote:
> 
> ...
>> I'm baffled that the reactive ND is still the official technique for IPv6 
>> lookup at 6MAN.
> 
> How can it be otherwise when a node can give itself a new address at any time 
> without notice?
> 
> I'm not arguing with you about RFC 6775/8505 networks, but that doesn't apply 
> everywhere.
> 
>Brian
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [6lo] ND cache entries creation on first-hop routers

[Pascal Thubert (pthubert)]

Hello Michael 

Please see below 

> 
> Pascal Thubert (pthubert)  wrote:
>> 6LoWPAN ND is immune to the remote DOS attacks on the ND cache, the
>> ones coming from the outside of the subnet, i.e., from a place that is
>> out of touch and virtually nowhere.
> 
>> This is because in an RFC 6775/8505-only network, there is no reactive
>> operation, a packet coming from the outside of the subnet for a node
>> that is not registered to the router is just dropped. Just like an AP
>> does not copy a packet on the wireless for a MAC that is not
>> associated.
> 
> There are a few attacks on the ND cache that I can think of.
> One of them that we see on the IETF network is the script kiddies who
> sequentially scan IP addresses.  We have a lot of them, and so we flood the
> wifi with ARP queries (v4) and NS (v6).  We have mitigations for this.
> 
> In the route-over 6tisch/RPL space, we don't (as you indicate), use NS by the
> router, we know who is on our network, and we would just have no /128 routes,
> and just drop the packets.  Is this the attack that you are speak of as a
> remote DOS?

Yes, 

Scanning in v6 can hardly be used to discover addresses but it can be used as a 
DOS attack against the CPU because the silicon needs to punt on cache miss. It 
can also be used to DOS the neighbor cache. And it is hard to differentiate 
from legitimate new traffic.

The possibility for such an attack comes from the reactive nature of ND, which 
was designed when IP routing was in software and the network a happy Woodstock. 
Times have changed and a modern ND should protect itself and the addresses it 
manages (think SeND and SAVI) and should be friendly to fabrics, to wireless 
and to hardware forwarders. We have that on tiny devices but it’s still missing 
in the big irons.

> 
>> Your point below remains correct, since the attack you describe is from
>> a node that reaches the router at L2. Arguably, that attack is
>> physically much harder to perform than the DOS packet from outer
>> space.
> 
> When I mentioned attacks on the ND cache, I am referring to those that can
> occur from within the 6tisch network from malicious pledge nodes.  We have to
> limit the NCE usage by untrusted nodes so that we have space for as many
> registered nodes.
> I think you are agreeing with me above.
> 

Yes I certainly followed you there and agree. We had that discussion for 6TiSCH 
minimal security. My point was that this local DOS attack requires a physical 
presence and is much harder to achieve than the remote DOS.


> I believe that the issue that Jen is describing would for unaware leaves that
> were sleepy.

Unaware Leaves that follow the ROLL specs register their addresses and sleep. 
They can sleep for the whole lifetime of their registration, the router will 
maintain an ND entry and the network will protect the address ownership.
To your point the node must wake up and refresh the registration before it 
expires.

What’s left of Jen’s issue with registration is the asymmetrical routing. In 
the ROLL specs the router that has the registration injects the route in the 
MLSN and gets the traffic back so the issue does not exist. In a transit 
network the router would forward the registration state to a 6LBR that can 
answer unicast lookups from other routers, still incurring a delay, or may push 
a state to other routers or to a load balancer so the router with the 
registration gets the traffic first.

All the best,

Pascal 

> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [6lo] ND cache entries creation on first-hop routers

[Pascal Thubert (pthubert)]

Hi again Lorenzo,

First, complexity. Recovering state in the presence of router crashes is 
complex.


  *   True; so far we have not designed for the case where the router dies and 
no-one knows. In the fabric models, the router relays to a central mapping 
system that it can query later. The case of an intermediate network could be 
addressed e.g., with a RA(I’m back), an interesting subject if 6MAN takes over 
the work. Compare this with the case where the router crashes, loses all ND 
caches, and has 100s of flows through for which a full ND operation (punt, 
lookup, program) must be done on the first packet.

Also, depending on what guarantees the network needs to provide to hosts, a 
registration-based model will likely use more router memory in the common case 
that most hosts are well-behaved (because it cannot aggressively time out 
entries that with classic ND can simply be thrown away after a while).


ØThe router can reject a registration if out of memory and the node needs 
to register somewhere else or free an old registration of his. At least the use 
of memory is deterministic. Compare this with an ND cache that has less room 
than the active flows, LRU will create a permanent situation of flush/lookup.


Second, an explicit registration model where the router can refuse to create an 
address entry provides a supported path for operators to limit the number of IP 
addresses used by hosts, which has the negative consequences described in RFC 
7934. In fact, such a model is explicitly NOT RECOMMENDED by RFC 7934 for 
general-purpose hosts. The relevant text is "it is RECOMMENDED that the network 
give the host the ability to use new addresses without requiring explicit 
requests."




Ø  The router can always refrain from creating an NCE if it does not want to, 
e.g., by policies that protect the ND cache. The registration does not create 
that situation. Thanks to your contribution, RFC 8505 SHOULDs conformance to 
RFC 7934 and has “The ability to return errors to address registrations is not 
intended to be used to restrict the ability of hosts to form and use multiple 
addresses. “. The rest is in the hands of the network admins, make sure they 
deploy resources adequately.



Cheers;



Pascal
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [6lo] ND cache entries creation on first-hop routers

[Pascal Thubert (pthubert)]

Hello Jen

The routers that Michael is talking about are real routers, deployed in large 
volumes in the field, e.g., in Smartgrid networks. 
They are not running ND as RFC 4861/4862 but as RFC 6775/8505, and then operate 
RPL routing within the ML subnet.
It would be great to have a section that describes that new ND operation and 
shows how it changes the deal. I'd be happy to help you on that if you need.
There are some hints in 
https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/.

All the best,

Pascal

> -Original Message-
> From: 6lo <6lo-boun...@ietf.org> On Behalf Of Jen Linkova
> Sent: mercredi 3 juillet 2019 08:52
> To: Michael Richardson 
> Cc: 6tisch@ietf.org; 6man <6...@ietf.org>; V6 Ops List ;
> 6...@ietf.org
> Subject: Re: [6lo] ND cache entries creation on first-hop routers
> 
> On Wed, Jul 3, 2019 at 1:37 AM Michael Richardson
>  wrote:
> > I think that the discussion here is particularly relevant to
> > constrained devices/routers on route-over MESH(RPL,etc.) networks.
> >
> > I also think that for L=0 networks, which RPL creates with RPL DIO
> > messages rather than (just) RAs, and 6LRs that need to support join
> > operations (like draft-ietf-6tisch-minimal-security) this may matter.
> 
> Disclaimer: I have very limited knowledge in that area.
> 
> > In particular, in the minimal-security case, we need to partition the
> > ND cache such that untrusted (unverified) malicious pledge nodes can
> > not attack the ND cache.
> 
> The next version of the draft will have much more details on discussing the
> security considerations indeed.
> 
> > The behaviour 2.2.1.  Host Sending Unsolicited NA, should probably
> > never flush an old entry out of the ND.
> 
> I'd say that the router behaviour for creating a STALE entry upon receiving an
> unsolicited NA should be the same as for creating an entry for any other
> reason (e.g. for receiving an RS with SLLAO).
> The same safety rules shall apply.
> 
> > I think that under attack
> > (whether from untrusted pledges, or from p0woned devices already on
> > the network), it is better to prefer communication from existing nodes
> > rather than new ones.  2.2.1.2 mentions this.
> 
> I guess your routers do purge old stale entries?
> 
> > {typo:
> >   -It's recommended that thsi functionality is configurable and
> >   +It's recommended that this functionality is configurable and }
> 
> Thanks, will fix in -01.
> 
> > I didn't really understand 2.2.2: is it exploiting some corner case in
> > the spec, or maybe just some part I am not well clued in about.  So
> > maybe an extra paragraph to explain things.
> 
> It's just using the standard ND process: when the node B receives an NS from
> node A and that NS contains the node B  address as a target address and
> SLLAO contains node A LLA, the node B would respond with NA and would
> create a STALE entry for the node A -
> https://tools.ietf.org/html/rfc4861#section-7.2.3
> 
> > I kinda like the ping all routers trick.
> 
> I think it's a hack ;( we do have a mechanism for communicating neighbours
> addresses/reachability called ND. It would be nice to utilise its machinery.
> Pinging creates additional overhead on routers and could get filtered.
> But I'd not be surprised if it's the only way we have realistically to 
> mitigate the
> issue..
> 
> >
> > Jen Linkova  wrote:
> > > I wrote a short draft to discuss and document an operational issue
> > > related to the ND state machine and packet loss caused by how routers
> > > create ND cache entries for new host addressed:
> >
> > >
> > https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/
> >
> > > (taking into account some vendors have implemented one of the
> proposed
> > > solution already, I guess it's a well-known problem but it might still
> > > worth documenting)
> >
> > > Comments are appreciated!
> >
> > > --
> > > SY, Jen Linkova aka Furry
> >
> > > 
> > > IETF IPv6 working group mailing list
> > > i...@ietf.org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > >
> > 
> >
> >
> > --
> > Michael Richardson , Sandelman Software Works
> > -= IPv6 IoT consulting =-
> >
> >
> >
> 
> 
> --
> SY, Jen Linkova aka Furry
> 
> ___
> 6lo mailing list
> 6...@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [6lo] ND cache entries creation on first-hop routers

[Pascal Thubert (pthubert)]

Hello Michael

6LoWPAN ND is immune to the remote DOS attacks on the ND cache, the ones coming 
from the outside of the subnet, i.e., from a place that is out of touch and 
virtually nowhere.
This is because in an RFC 6775/8505-only network, there is no reactive 
operation, a packet coming from the outside of the subnet for a node that is 
not registered to the router is just dropped. Just like an AP does not copy a 
packet on the wireless for a MAC that is not associated.

I'm baffled that the reactive ND is still the official technique for IPv6 
lookup at 6MAN. The operations that you have to do in an enterprise-class 
router on a data packet, punt the packet to software, run ND, program the 
hardware, protect ND cache and CPU against DOS, are just from another age. So 
we have to run our own things (e.g., a LISP MSMR) on our fabrics when 
modernizing ND would do the trick in a standard fashion (see 
draft-thubert-6lo-unicast-lookup) .

Your point below remains correct, since the attack you describe is from a node 
that reaches the router at L2. Arguably, that attack is physically much harder 
to perform than the DOS packet from outer space.

All the best,

Pascal

> -Original Message-
> From: 6lo <6lo-boun...@ietf.org> On Behalf Of Michael Richardson
> Sent: mardi 2 juillet 2019 17:38
> To: 6...@ietf.org; Jen Linkova ; 6tisch@ietf.org
> Cc: V6 Ops List ; 6man <6...@ietf.org>
> Subject: Re: [6lo] ND cache entries creation on first-hop routers
> 
> 
> I think that the discussion here is particularly relevant to constrained
> devices/routers on route-over MESH(RPL,etc.) networks.
> 
> I also think that for L=0 networks, which RPL creates with RPL DIO messages
> rather than (just) RAs, and 6LRs that need to support join operations (like
> draft-ietf-6tisch-minimal-security) this may matter.
> 
> In particular, in the minimal-security case, we need to partition the ND cache
> such that untrusted (unverified) malicious pledge nodes can not attack the ND
> cache.
> 
> The behaviour 2.2.1.  Host Sending Unsolicited NA, should probably never flush
> an old entry out of the ND.  I think that under attack (whether from untrusted
> pledges, or from p0woned devices already on the network), it is better to
> prefer communication from existing nodes rather than new ones.  2.2.1.2
> mentions this.
> 
> {typo:
>   -It's recommended that thsi functionality is configurable and
>   +It's recommended that this functionality is configurable and }
> 
> I didn't really understand 2.2.2: is it exploiting some corner case in the 
> spec, or
> maybe just some part I am not well clued in about.  So maybe an extra
> paragraph to explain things.
> 
> I kinda like the ping all routers trick.
> 
> 
> Jen Linkova  wrote:
> > I wrote a short draft to discuss and document an operational issue
> > related to the ND state machine and packet loss caused by how routers
> > create ND cache entries for new host addressed:
> 
> > https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/
> 
> > (taking into account some vendors have implemented one of the proposed
> > solution already, I guess it's a well-known problem but it might still
> > worth documenting)
> 
> > Comments are appreciated!
> 
> > --
> > SY, Jen Linkova aka Furry
> 
> > 
> > IETF IPv6 working group mailing list
> > i...@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > 
> 
> 
> --
> Michael Richardson , Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
> 

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Opsdir last call review of draft-ietf-6tisch-architecture-22

[Pascal Thubert (pthubert)]

Many thanks Qin !



I posted -23 in the hope that it satisfies all your comments. Please let us 
know is there is any additional issue we need to look at.



All the best,



Pascal




De : Qin Wu 
Envoyé : Friday, June 28, 2019 8:57:22 AM
À : Pascal Thubert (pthubert); ops-...@ietf.org
Cc : 6tisch@ietf.org; i...@ietf.org; 
draft-ietf-6tisch-architecture@ietf.org; Eliot Lear (elear); Carlos 
Pignataro (cpignata)
Objet : RE: Opsdir last call review of draft-ietf-6tisch-architecture-22

-邮件原件-
发件人: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com]
发送时间: 2019年6月28日 0:37
收件人: Qin Wu ; ops-...@ietf.org
抄送: 6tisch@ietf.org; i...@ietf.org; 
draft-ietf-6tisch-architecture@ietf.org; Eliot Lear (elear) 
; Carlos Pignataro (cpignata) 
主题: RE: Opsdir last call review of draft-ietf-6tisch-architecture-22

Hello Qin

I looked at it again and found that it was great to move

 3.8.  Communication Paradigms and Interaction Models  . . . . .  21
[Qin]: Can we remove it or consolidated it into other existing sections.
I don't see this section adds anything besides providing a bunches of 
references.

But not such a great idea to move

 4.2.  Network Access and Addressing . . . . . . . . . . . . . .  23
   4.2.1.  Join Process  . . . . . . . . . . . . . . . . . . . .  23
   4.2.2.  Registration  . . . . . . . . . . . . . . . . . . . .  25

So my suggestion for the latter is to better introduce the join process and the 
registration in section 3.1.
Proposed text:

'
6TiSCH nodes join a mesh network by attaching to nodes that are
   already members of the mesh (see Section 4.2.1).  The security
   aspects of the join process are further detailed in Section 6.  In a
   mesh network, 6TiSCH nodes are not necessarily reachable from one
   another at Layer-2 and an LLN may span over multiple links.

   This forms an homogeneous non-broadcast multi-access (NBMA) subnet,
   which is beyond the scope of IPv6 Neighbor Discovery (IPv6 ND)
   [RFC4861][RFC4862]. 6LoWPAN Neighbor Discovery (6LoWPAN ND)
   [RFC6775][RFC8505] specifies extensions to IPv6 ND that enable ND
   operations in this type of subnet.

   Once it has joined the 6TiSCH network, a node acquires IPv6 Addresses
   and register them using 6LoWPAN ND.  This guarantees that the
   addresses are unique and protects the address ownership over the
   subnet, more in Section 4.2.2.

'

Does that work?

[Qin]: Much better, thanks.

Pascal

> -Original Message-----
> From: Pascal Thubert (pthubert)
> Sent: jeudi 27 juin 2019 16:48
> To: Qin Wu ; ops-...@ietf.org
> Cc: 6tisch@ietf.org; i...@ietf.org;
> draft-ietf-6tisch-architecture@ietf.org;
> Eliot Lear (elear) ; Carlos Pignataro (cpignata)
> 
> Subject: RE: Opsdir last call review of
> draft-ietf-6tisch-architecture-22
>
> Hello Qin
>
> Many thanks for your review and for the important amount of time you
> obviously spent on our work. This is really appreciated.
> Please see below:
>
> > By looking at high level architecture section, it is hard to create
> > a whole picture for what this architecture looks like and how these
> > architecture component can be put together. Also architecture
> > components defined in architecture component section seem not to
> > align with high level architecture section. For Some architecture
> > component,e.g.,Communication Paradigms and Interaction Models,
> > Network access and addressing haven't appeared in the high level 
> > architecture first.
>
> This is an interesting comment.
>
> If you look back at say, draft 18, the sections in the high level
> architecture have been modified and quite a bit of text went from section 3 
> to section 4.
> The reason is that the first reviews we got from outside the WG told
> us to shrink section 3 to the minimum, which caused us to move text to 
> section 4.
>
> I'm intrigued by your comment " seem not to align with high level
> architecture ". This is certainly something we need to act upon; but
> there is a difference between the fact that a discussion appears only
> in section 4 and a misalignment, which I read as a discrepancy or an
> inconsistency in the architecture. Could you please provide
> suggestions on where to focus without undoing what we did for the
> previous reviewers?  If this is about moving text back to section 3, I
> generally agree but need to confirm with the original reviewers (cc), more 
> below.
>
>
> A few editorial comments and suggestions
> > 1.Section 1 IT and OT should be part of terminology section too.
>
> Expanded both in first use and added a terminology for OT. IT is a bit
> too obvious for a terminology section isn't it?
> "
> 
> OT refers to technology used in automa

Re: [6tisch] Opsdir last call review of draft-ietf-6tisch-architecture-22

[Pascal Thubert (pthubert)]

Hello Qin

I looked at it again and found that it was great to move 

 3.8.  Communication Paradigms and Interaction Models  . . . . .  21

But not such a great idea to move 

 4.2.  Network Access and Addressing . . . . . . . . . . . . . .  23
   4.2.1.  Join Process  . . . . . . . . . . . . . . . . . . . .  23
   4.2.2.  Registration  . . . . . . . . . . . . . . . . . . . .  25

So my suggestion for the latter is to better introduce the join process and the 
registration in section 3.1.
Proposed text:

'
6TiSCH nodes join a mesh network by attaching to nodes that are
   already members of the mesh (see Section 4.2.1).  The security
   aspects of the join process are further detailed in Section 6.  In a
   mesh network, 6TiSCH nodes are not necessarily reachable from one
   another at Layer-2 and an LLN may span over multiple links.

   This forms an homogeneous non-broadcast multi-access (NBMA) subnet,
   which is beyond the scope of IPv6 Neighbor Discovery (IPv6 ND)
   [RFC4861][RFC4862]. 6LoWPAN Neighbor Discovery (6LoWPAN ND)
   [RFC6775][RFC8505] specifies extensions to IPv6 ND that enable ND
   operations in this type of subnet.

   Once it has joined the 6TiSCH network, a node acquires IPv6 Addresses
   and register them using 6LoWPAN ND.  This guarantees that the
   addresses are unique and protects the address ownership over the
   subnet, more in Section 4.2.2.

'

Does that work?

Pascal

> -Original Message-
> From: Pascal Thubert (pthubert)
> Sent: jeudi 27 juin 2019 16:48
> To: Qin Wu ; ops-...@ietf.org
> Cc: 6tisch@ietf.org; i...@ietf.org; 
> draft-ietf-6tisch-architecture@ietf.org;
> Eliot Lear (elear) ; Carlos Pignataro (cpignata)
> 
> Subject: RE: Opsdir last call review of draft-ietf-6tisch-architecture-22
> 
> Hello Qin
> 
> Many thanks for your review and for the important amount of time you
> obviously spent on our work. This is really appreciated.
> Please see below:
> 
> > By looking at high level architecture section, it is hard to create a
> > whole picture for what this architecture looks like and how these
> > architecture component can be put together. Also architecture
> > components defined in architecture component section seem not to align
> > with high level architecture section. For Some architecture
> > component,e.g.,Communication Paradigms and Interaction Models, Network
> > access and addressing haven't appeared in the high level architecture first.
> 
> This is an interesting comment.
> 
> If you look back at say, draft 18, the sections in the high level architecture
> have been modified and quite a bit of text went from section 3 to section 4.
> The reason is that the first reviews we got from outside the WG told us to
> shrink section 3 to the minimum, which caused us to move text to section 4.
> 
> I'm intrigued by your comment " seem not to align with high level architecture
> ". This is certainly something we need to act upon; but there is a difference
> between the fact that a discussion appears only in section 4 and a
> misalignment, which I read as a discrepancy or an inconsistency in the
> architecture. Could you please provide suggestions on where to focus without
> undoing what we did for the previous reviewers?  If this is about moving text
> back to section 3, I generally agree but need to confirm with the original
> reviewers (cc), more below.
> 
> 
> A few editorial comments and suggestions
> > 1.Section 1 IT and OT should be part of terminology section too.
> 
> Expanded both in first use and added a terminology for OT. IT is a bit too
> obvious for a terminology section isn't it?
> "
> 
> OT refers to technology used in automation, for instance 
> in
> industrial control networks. The convergence of IT and OT 
> is
> the main object of the Industrial Internet of Things 
> (IIOT).
> "
> 
> > 2.Section 2
> > ND-proxying and binding should provide reference,e.g.,RFC4389
> 
> Well, this reference would be misleading because it considers specific network
> models that are not the one we need in 6TiSCH. So we refrained from using it.
> Turns out that there is no IPv6 RFC that would be equivalent to ARP proxya
> and that we could reference. That's until now since we are doing the backbone
> router. Which is what the architecture discusses later. Sorry but I have no
> clean path to fix this...
> 
> > 3.Section 3 I
> > think Architecture Components Defined in section 4 should be
> > consistent with high level architecture, e.g.,Network access and
> > Adressing component seems not to be discussed in high level architecture
> section.
> 
> See  https:/

Re: [6tisch] Opsdir last call review of draft-ietf-6tisch-architecture-22

[Pascal Thubert (pthubert)]

Hello Qin

Many thanks for your review and for the important amount of time you obviously 
spent on our work. This is really appreciated.
Please see below:

> By looking at high level architecture section, it is hard to create a whole
> picture for what this architecture looks like and how these architecture
> component can be put together. Also architecture components defined in
> architecture component section seem not to align with high level architecture
> section. For Some architecture component,e.g.,Communication Paradigms and
> Interaction Models, Network access and addressing haven't appeared in the
> high level architecture first. 

This is an interesting comment. 

If you look back at say, draft 18, the sections in the high level architecture 
have been modified and quite a bit of text went from section 3 to section 4.
The reason is that the first reviews we got from outside the WG told us to 
shrink section 3 to the minimum, which caused us to move text to section 4.

I'm intrigued by your comment " seem not to align with high level architecture 
". This is certainly something we need to act upon; but there is a difference 
between the fact that a discussion appears only in section 4 and a 
misalignment, which I read as a discrepancy or an inconsistency in the 
architecture. Could you please provide suggestions on where to focus without 
undoing what we did for the previous reviewers?  If this is about moving text 
back to section 3, I generally agree but need to confirm with the original 
reviewers (cc), more below.


A few editorial comments and suggestions
> 1.Section 1 IT and OT should be part of terminology section too. 

Expanded both in first use and added a terminology for OT. IT is a bit too 
obvious for a terminology section isn't it?
"

OT refers to technology used in automation, for instance in
industrial control networks. The convergence of IT and OT is
the main object of the Industrial Internet of Things (IIOT).
"

> 2.Section 2
> ND-proxying and binding should provide reference,e.g.,RFC4389 

Well, this reference would be misleading because it considers specific network 
models that are not the one we need in 6TiSCH. So we refrained from using it.
Turns out that there is no IPv6 RFC that would be equivalent to ARP proxya and 
that we could reference. That's until now since we are doing the backbone 
router. Which is what the architecture discusses later. Sorry but I have no 
clean path to fix this...

> 3.Section 3 I
> think Architecture Components Defined in section 4 should be consistent with
> high level architecture, e.g.,Network access and Adressing component seems
> not to be discussed in high level architecture section. 

See  https://tools.ietf.org/html/draft-ietf-6tisch-architecture-17 section 3.7, 
that subsection was in section 3. This is how I thought it should be 
structured. But then it was moved to 4 on request of a previous IESG review to 
improve the clarity y making section 3 more concise.  I'm happy to move it back 
but cc the original reviewers to make sure we all agree on the final result.

Please confirm that this is effectively your recommendation.

> 4. Section 3.1 figure1
> NME and PCE should be part of terminology section 


Added terminology + verified that the terms are expanded in first use. 
Note that I got the exact reverse remark from another reviewer, said something 
like expanding in first use is the IETF way and sufficient.
A hint that there is no perfection ; )

5.Section 4.3.1.1,1st
> paragraph The first sentence should not belong to this section since this
> section focuses on introduction of Hard cell. 

Agreed; moved above the section boundary.

6.Section 4.3.1.1, Section 4.3.1.2
> Two section seesm only to discuss how to use hard cells or soft cell, but
> doesn't define what it is. Please clarify the difference between hard cell or 
> soft
> cell 

Actually it does but it could be a lot more clear. 

Proposed text:

On hard cells

"Hard" cells are cells that are
are owned and managed by a separate scheduling entity (e.g. a PCE)
that specifies the slotOffset/channelOffset of the cells to be
added/moved/deleted, in which case 6top can only act as instructed,
and may not move hard cells in the TSCH schedule on its own.

On soft cells

In contrast, "soft" cells are cells that 6top can manage locally.
6top contains a monitoring process which monitors the performance of
cells, and can add, remove soft cells in the TSCH schedule to adapt
to the traffic needs, or move one when it performs poorly.


> 7. Section 4.4 How this section is related to high level architecture
> described in section 3 

If that is what you have in mind, yes, this section is mostly an introduction 
to sections 4.5 to 4.8.
If that corrects the issue as you see it, then I agree to move it to sec

Re: [6tisch] [secdir] secdir review of draft-ietf-6tisch-architecture-21

[Pascal Thubert (pthubert)]

Hello Malisa

Please find below the proposed text; note that last paragraph is commented out 
to leave space for minimal to complete the story.


The operation of 6TiSCH Tracks inherits its high level operation from DetNet
and is subject to the observations in section 5 of
. As discussed there, measures
must be taken to protect the time synchronization, and for 6TiSCH this
includes ensuring that the Absolute Slot Number (ASN), which is used as ever
incrementing counter for the computation of the Link-Layer security nonce,
is not compromised, more below on this. Also, the installation and the
maintenance of the 6TiSCH Tracks depends on the availability of a controller
with a PCE to compute and push them in the network. When that connectivity
is lost, existing Tracks may continue to operate until the end of their
lifetime, but cannot be removed or updated, and new Tracks cannot be
installed. As with DetNet in general, the communication with the PCE must be
secured and should be protected against DoS attacks, and the discussion on
the security considerations defined for Abstraction and Control of Traffic
Engineered Networks (ACTN) in Section 9 of , applies
equally to 6TiSCH.

 
In a TSCH network as specified by
IEEE Std. 802.15.4, the nonce that is used
to secure Link-Layer frames includes an address of the source and the ASN.
The ASN itself is supposed to be distributed securely by other means. With
TSCH, the ASN is included in the CCM* nonce for the computation of the
Message Integrity Code (MIC), but it is only implicit in the data frames.
This is not considered as a complete replay protection and upper layer
protocols must provide a way to detect duplicates and cope with them.


 
If the receiver and the sender have a different sense of ASN, the MIC will
not validate and the frame will be dropped. In that sense, TSCH induces an
event horizon whereby only nodes that have a common sense of ASN can talk to
one another in an authenticated manner. With 6TiSCH, the pledge discovers a
tentative ASN in beacons from nodes that have already joined the network.
But even if the beacon can be authenticated, the ASN cannot be trusted as it
could be a replay by an attacker and thus could announce an ASN that
represents a time in the  past. If the pledge uses an ASN that is learned
from a replayed beacon for an encrypted transmission, a nonce-reuse attack
becomes possible and the network keys may be compromised.


Time Synchronization in TSCH induces another event horizon whereby a node
will only communicate with another node if they are synchronized within a
guard time. The pledge discovers the synchronization of the network based
on the time of reception of the beacon. If an attacker synchronizes a pledge
outside of the guard time of the legitimate nodes then the pledge will never
see a legitimate beacon and may not discover the attack.


After obtaining the tentative ASN, the pledge authenticates itself to the
network using some mechanism outside of IEEE Std. 802.15.4. With 6TiSCH,
a Join Proxy (JP) helps the pledge for the join procedure by relaying the
link-scope Join Request over the IP network to a Join Registrar/Coordinator
(JRC) that can authenticate the pledge and validate that it is attached to
the appropriate network. As a result of this exchange the pledge is in
possession of a Link-Layer material including keys and a short address, and
if the ASN is known to be correct, all traffic can now be secured using CCM*
at the Link-Layer.


The authentication steps must be such that they cannot be replayed by an
attacker, and they must not depend on the tentative ASN being valid.
During the authentication, the keying material that the pledge obtains from
the JRC does not provide protection against spoofed ASN. Once the pledge has
obtained the keys to use in the network, it may still need to verify the 
ASN.
If the nonce used in the Layer-2 security derives from the extended (MAC-64)
address, then replaying the ASN alone cannot enable a nonce-reuse attack
unless the same node is lost its state with a previous ASN. But
if the nonce derives from the short address (e.g., assigned by the JRC) then
the JRC must ensure that it never assigns short addresses that were already
given to this or other nodes with the same keys. In other words, the network
must be rekeyed before the JRC runs out of short addresses.


These issues is are discussed in more details in
.



All the best,

Pascal

From: Mališa Vučinić 
Sent: jeudi 27 juin 2019 12:48
To: Pascal Thubert (pthubert) 
Cc: Michael Richardson ; 6tisch@ietf.org; Tero Kivinen 

Subject: Re: [6tisch] [secdir] secdir review of 
draft-ietf-6tisch-architecture-21

Pascal

Re: [6tisch] [secdir] secdir review of draft-ietf-6tisch-architecture-21

[Pascal Thubert (pthubert)]

Hello Michael

Both ASN and sync create event horizons.
* A wrong ASN will cause MIC processing to fail and the packet will be ignored.
* If an attacker syncs a pledge outside of the network sync's beyond guard 
time, the pledge will not even see that legitimate nodes are sending.

In both cases, a node that believes an attacker has no way to validate ASN 
right there. It needs an additional one-hop authenticated exchange with a 
legitimate node with a, e.g., random nonce in payload. Some people will want 
that step even if the window is narrow. I think we should describe it in archie 
and in minimal sec.

6P or MSF could be used for that purpose when present but cannot be the only 
way since they are optional.

All the best,

Pascal

> -Original Message-
> From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Michael Richardson
> Sent: mercredi 26 juin 2019 17:49
> To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= 
> Cc: Pascal Thubert (pthubert) ; 6tisch@ietf.org; Tero
> Kivinen 
> Subject: Re: [6tisch] [secdir] secdir review of 
> draft-ietf-6tisch-architecture-21
> 
> 
> Mališa Vučinić  wrote:
> >> Mališa Vučinić  wrote:
> >>> Instead, as with traditional TSCH, the joined node can obtain its time
> >>> information from its time source neighbor, i.e. RPL preferred parent,
> >>> by triggering an exchange of link-layer frames with L2 security
> >>> features enabled. The MSF draft already mandates that the first
> >>> outgoing message from the joined node after joining is the 6P ADD
> >>> message to its preferred parent, which consequently gets protected
> with
> >>> L2 security.
> >>
> >> But, how can the L2-security work if the newly-joined node has an
> ancient
> >> ASN?  Won't the parent just drop the packet as being a replay, and then
> what?
> 
> > Yes, so the node will desynchronize eventually, fall out of network and
> > restart the join process, hopefully with a different network.
> 
> hmm.   Or, it sees a new beacon, which it can integrity check, and then sees
> the ASN jump forward.  This would be the same as if it had slept for awhile.
> 
> Unless the attacker can continuously *block* the node from seeing the latest
> beacons, and continuously feeds it old beacons, the problem should go away.
> 
> So maybe this is really not as a big a deal as I thought.
> 
> >>> What needs to be specified clearly is that this first 6P
> >>> exchange should not be encrypted but only authenticated at L2.
> >>> Upon successful completion of the first 6P exchange with its time
> (routing)
> >>> parent, the joined node obtains a negotiated cell and as a side effect
> >>> proves freshness of the ASN used.
> >>
> >> I'd rather that we added a new exchange, rather than special casing 
> some
> 6P
> >> interaction here.   An RPL DIS would be a better choice here, I think, 
> with
> >> an RPL DAO unicast reply.  Still, I hate to special case this as being
> >> authenticated only.
> >> Doesn't that have to happen first?
> 
> > Whatever packet we send here, be it DIS or 6P, they need to have
> > special handling in terms of L2 security… Is DIS mandatory to send upon
> > preferred parent selection?
> 
> I think that we can do nothing.
> 
> Maybe the replayed beacon attack (and solution: wait for another beacon)
> belongs in the Security Considerations of the Architecture.
> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works|IoT architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 
> 
> --
> Michael Richardson , Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
> 

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [secdir] secdir review of draft-ietf-6tisch-architecture-21

[Pascal Thubert (pthubert)]

Hello Malisa

> >> Instead, as with traditional TSCH, the joined node can obtain its
> >> time information from its time source neighbor, i.e. RPL preferred
> >> parent, by triggering an exchange of link-layer frames with L2
> >> security features enabled. The MSF draft already mandates that the
> >> first outgoing message from the joined node after joining is the 6P
> >> ADD message to its preferred parent, which consequently gets
> >> protected with
> >> L2 security.
> >
> > But, how can the L2-security work if the newly-joined node has an
> > ancient ASN?  Won't the parent just drop the packet as being a replay, and
> then what?
> 
> Yes, so the node will desynchronize eventually, fall out of network and 
> restart
> the join process, hopefully with a different network.

My own Q&A

How is the bad ASN identified? -> I guess it can be picked from the frame 
counter in the Auxillary Security Header.
But then does the spec require that the receiver checks the frame counter that 
the sender used ? Is that implemented?
What is the reaction of the receiver in case of a bad ASN?  -> It could send a 
beacon with a correct ASN I guess.
But then how can we determine who of the 2 has the correct ASN? -> I guess a 
node should not have the right to act as coordinator until it confirmed his 
sense of ASN.

Otherwise, a bad ASN with the good modulo gets the frame in the right channel 
offset...

> 
> >> What needs to be specified clearly is that this first 6P exchange
> >> should not be encrypted but only authenticated at L2.
> >> Upon successful completion of the first 6P exchange with its time
> >> (routing) parent, the joined node obtains a negotiated cell and as a
> >> side effect proves freshness of the ASN used.
> >
> > I'd rather that we added a new exchange, rather than special casing some 6P
> > interaction here.   An RPL DIS would be a better choice here, I think, with
> > an RPL DAO unicast reply.  Still, I hate to special case this as being
> > authenticated only.
> > Doesn't that have to happen first?
> 
> Whatever packet we send here, be it DIS or 6P, they need to have special
> handling in terms of L2 security… Is DIS mandatory to send upon preferred
> parent selection?

It is not mandatory but we could use it. A more generic method would be for the 
pledge to solicit a beacon with a nonce that does not depend on ASN and see 
check the MIC/MAC of the beacon.
 
All the best,

Pascal
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [secdir] secdir review of draft-ietf-6tisch-architecture-21

[Pascal Thubert (pthubert)]

Hello Malisa
 
> The issue raised seems valid and going through minimal-security and the MSF
> draft it seems that some clarification is needed. We purposely avoided keeping
> the network notion of time at the JRC in order to facilitate deployments where
> JRC is outside of the local network and is managing multiple 6tisch networks. 
> I
> do not believe we want to change that, as it would be quite challenging to
> require the synchronization of the JRC with each 6tisch network.

Yes, I remember that discussion. Bottom line is that the proposal that Tero 
mentioned is not used.
Note that since we use RPL, the absolute source of Truth is the Root. But the 
root is several hops away and we cannot get the ASN directly so whatever we 
transfer to the node will be offset by the propagation time.


> 
> Instead, as with traditional TSCH, the joined node can obtain its time
> information from its time source neighbor, i.e. RPL preferred parent, by
> triggering an exchange of link-layer frames with L2 security features enabled.

Yes, but as Tero mentioned even an authenticated beacon can be replayed, making 
the node believe it is somewhere in the past. 


> The MSF draft already mandates that the first outgoing message from the
> joined node after joining is the 6P ADD message to its preferred parent, which
> consequently gets protected with L2 security. What needs to be specified
> clearly is that this first 6P exchange should not be encrypted but only

Is MSF the best place for this? 

I believe that the architecture should say something vague like " a first 
exchange is needed with a node that is trusted and already joined, e.g., a RPL 
time parent, and that message should not be encrypted but only authenticated at 
L2. The request from the pledge should contain a nonce and the response should 
contain the signed nonce+ASN+stuff. " On that base, MSF and minimal-security 
could elaborate on which message exactly is used.

> authenticated at L2. Upon successful completion of the first 6P exchange with
> its time (routing) parent, the joined node obtains a negotiated cell and as a
> side effect proves freshness of the ASN used.

Am I missing something? Looks like an ASN would appear to work if it is correct 
modulo the number of channels, something like 16... Which the attacker can 
derive by observing the period of transmissions by a node, doing, e.g., 6tisch 
minimal support.

> What seems missing is some text in minimal-security adding guidance for
> other scheduling function and stressing this issue beyond the text in the last
> paragraph of Section 9 of draft-ietf-6tisch-minimal-security-11 that is rather
> vague.

Yes : ) I'm working on high level text in archie, and will propose it to you 
and Tero. I'll be happy that you refer to it and refine it in minimal-security.

All the best

Pascal



> Mališa
> 
> > On 25 Jun 2019, at 09:29, Pascal Thubert (pthubert) 
> wrote:
> >
> > Hello Malisa:
> >
> > I went through the security section of minimal-security and found that the
> text below would be useful there to. Alt a pointer to the security section of 
> the
> architecture would do once I incorporate some of the below.
> > (Though I thought it did at a time) minimal-security does not indicate that
> the JRC should be aware of the network ASN to enable the protection that
> Tero is discussing below, does it?
> >
> > All the best,
> >
> > Pascal
> >
> >
> >
> >> -Original Message-
> >> From: David Mandelberg 
> >> Sent: mardi 25 juin 2019 02:31
> >> To: Tero Kivinen ; Pascal Thubert (pthubert)
> >> 
> >> Cc: sec...@ietf.org; i...@ietf.org;
> >> draft-ietf-6tisch-architecture....@ietf.org;
> >> Thomas Watteyne ; Michael Richardson
> >> ; Mališa Vučinić 
> >> Subject: Re: [secdir] secdir review of
> >> draft-ietf-6tisch-architecture-21
> >>
> >>
> >>
> >> On 6/24/19 7:45 PM, Tero Kivinen wrote:
> >>> Pascal Thubert (pthubert) writes:
> >>>> Hello David:
> >>>>
> >>>> Many thanks for your review. I do hope that you found it interesting.
> >>>>
> >>>>> Sections 4.2.1 and 4.3.4 talk about the security of joining a
> >>>>> network, and time synchronization, respectively. Do any of the
> >>>>> security mechanisms in 4.2.1 rely on having an accurate clock?
> >>>>> (E.g., to distrust old/expired keys.) Is time synchronization done
> >>>>> before the join process, and is there any way to exploit time
> >>>>> synchronization in order to cause a node to join a malicious
> >>>>> network?
> >

[6tisch] FW: [secdir] secdir review of draft-ietf-6tisch-architecture-21

[Pascal Thubert (pthubert)]

Hello Malisa:

I went through the security section of minimal-security and found that the text 
below would be useful there to. Alt a pointer to the security section of the 
architecture would do once I incorporate some of the below.
(Though I thought it did at a time) minimal-security does not indicate that the 
JRC should be aware of the network ASN to enable the protection that Tero is 
discussing below, does it?

All the best,

Pascal



> -Original Message-
> From: David Mandelberg 
> Sent: mardi 25 juin 2019 02:31
> To: Tero Kivinen ; Pascal Thubert (pthubert) 
> 
> Cc: sec...@ietf.org; i...@ietf.org; 
> draft-ietf-6tisch-architecture@ietf.org;
> Thomas Watteyne ; Michael Richardson 
> ; Mališa Vučinić 
> Subject: Re: [secdir] secdir review of 
> draft-ietf-6tisch-architecture-21
> 
> 
> 
> On 6/24/19 7:45 PM, Tero Kivinen wrote:
> > Pascal Thubert (pthubert) writes:
> >> Hello David:
> >>
> >> Many thanks for your review. I do hope that you found it interesting.
> >>
> >>> Sections 4.2.1 and 4.3.4 talk about the security of joining a 
> >>> network, and time synchronization, respectively. Do any of the 
> >>> security mechanisms in 4.2.1 rely on having an accurate clock?
> >>> (E.g., to distrust old/expired keys.) Is time synchronization done 
> >>> before the join process, and is there any way to exploit time 
> >>> synchronization in order to cause a node to join a malicious 
> >>> network?
> >>
> >> This is really a MAC layer question for IEEE. I'm cc'ing Thomas who 
> >> was one of the inventors of TSCH, as well as Michael and Malisa who 
> >> led the join process study.
> >>
> >> Time synchronization (date):
> >> --
> >> For all I know, the time sync is about giving a epoch time from 
> >> which an Absolute Slot Number (ASN, expressed in slot duration 
> >> e.g.,
> >> 10ms) is derived. ASN plays a key role as it is used in NONCE. An 
> >> attack that one could think of would be to fool the new node into 
> >> thinking that ASN is earlier. This could happen before the keys are 
> >> exchanged, or if an authorized peer is compromised. For the former, 
> >> I'll defer to the others to answer fully how we protect the new 
> >> comer. For the latter, 6TiSCH provides an additional protection 
> >> since we derive time from a RPL parent. RPL has its own 
> >> protections, some of them in the standard itself, some of them in 
> >> zerotrust papers that need publishing.
> >
> > In normal TSCH in 802.15.4 the joining node will listen to beacons 
> > sent by the nodes already part of the network, and they will find 
> > out the ASN from there. As they do not yet have keys for the network 
> > they cannot verify the message integrity code authenticating the 
> > beacon, and even if they did have the keys, they still cannot verify 
> > it as it could be replay by attacker.
> >
> > After they find out the ASN, they need to authenticate themself to 
> > the network using some mechanism outside the 802.15.4. This 
> > authentication step must be such that it cannot be replayed by 
> > attacker, i.e., they must not trust ASN giving them any protection.
> >
> > Note, that in general 802.15.4 TSCH DOES NOT provide replay 
> > protection at all. I.e., attacker can cause legimite node to 
> > retransmit its previous message by destroying ack, and upper layer 
> > protocol must provide way to detect replays and cope with them.
> >
> > During the authentication the JRC needs to provide the keying 
> > material to the joining node, but that does NOT provide protection 
> > against spoofed ASN. After the node has actual keys used in the 
> > network it still needs to verify the ASN by sending some message to 
> > JRC using authentication and verify that JRC replies to that.
> >
> > If this 2nd step is omitted attacker do following attack:
> >
> > Joining node (JN)   attacker  JRC
> > <- beacon for ASN=23  <- beacon for ASN=44
> > See beacon
> > from attacker,
> > assume ASN=23.
> >
> > Auth->JRC
> > (no security) Check authentication
> >   Return keys
> >   keys->JN
> >
> > Receive keys
> > send first
> > frame using
> > keys using ASN=23->
> >
> >
> > Now, if JN is using 

[6tisch] 6TiSCH @ IETF 105: call for agenda items

[Pascal Thubert (pthubert)]

Dear 6TiSCHers,



The final agenda for IETF 105 has been published at: 
https://datatracker.ietf.org/meeting/105/agenda.html. Keep this link, it's 
always useful with a number of pointers to meeting needful things. Also 
consider the IETF application for your smartphone...



So 6TiSCH will be meeting on Thursday July 25th from 17:40 to 19:10, during 
Afternoon session III in room 
Duluth.



If you'd like a slot to present a draft, please send a request to the chairs 
(cc) by Friday July 12th.



Please provide the following information:

  *   Draft name
  *   Presenter name
  *   Remote vs. Local presentation
  *   Expected duration
  *   Objective of the discussion



We kindly request to send your slides for presentations by Tuesday July 23rd. A 
template will be provided.



Any WG draft not being discussed/presented needs a status update sent to the 
list by Tuesday July 23rd as well.



As always - we would appreciate your help in taking notes and jabber, please do 
volunteer!



Looking forward to seeing you in all Montreal,



Thomas and Pascal


___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] I-D Action: draft-ietf-6tisch-architecture-22.txt

[Pascal Thubert (pthubert)]

This version addresses comments by Andy Malis for RTG DIR and David Mandelberg 
for SEC DIR.
A major item was and may still be the amount of non-WG-docs references.
We also touched the security section to inherit from DetNet.

All the best,

Pascal

> -Original Message-
> From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of internet-dra...@ietf.org
> Sent: lundi 24 juin 2019 15:07
> To: i-d-annou...@ietf.org
> Cc: 6tisch@ietf.org
> Subject: [6tisch] I-D Action: draft-ietf-6tisch-architecture-22.txt
> 
> 
> 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 WG
> of the IETF.
> 
> Title   : An Architecture for IPv6 over the TSCH mode of IEEE 
> 802.15.4
> Author  : Pascal Thubert
>   Filename: draft-ietf-6tisch-architecture-22.txt
>   Pages   : 64
>   Date: 2019-06-24
> 
> Abstract:
>This document describes a network architecture that provides low-
>latency, low-jitter and high-reliability packet delivery.  It
>combines a high-speed powered backbone and subnetworks using IEEE
>802.15.4 time-slotted channel hopping (TSCH) to meet the requirements
>of LowPower wireless deterministic applications.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6tisch-architecture-22
> https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-architecture-22
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-architecture-22
> 
> 
> 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/
> 
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] RtgDir review: draft-ietf-6tisch-architecture-21.txt

[Pascal Thubert (pthubert)]

Hello Andrew

Please see below

Le 24 juin 2019 à 14:40, Andrew G. Malis 
mailto:agma...@gmail.com>> a écrit :

Pascal,

On Mon, Jun 24, 2019 at 4:24 AM Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:
Hello Andrew:

Many thanks for your in-depth review.

Please see below:



>  The primary editor of this draft is also active in the DetNet working group, 
> and leverages the work being done there to support the work in this draft. 
> The draft does reference some DetNet technologies that have not yet been 
> completely specified to the point where they can be implemented such as PREOF 
> (Packet Replication, Elimination and Ordering Functions), although such 
> specifications are an expected deliverable in the DetNet WG. So a full 
> implementation of this architecture may have to wait for the completion of 
> the related DetNet specification work.

 Very true. Note that 6TiSCH was not chartered to deliver specifications to 
implement the deterministic side of the architecture. We hope to form RAW to do 
that, and RAW would inherit from DetNet’s specifications that are on the works 
now. At the architecture level, the reference we need is the DetNet 
architecture that introduces PREOFs, not the specs. And as you know, the DetNet 
architecture will be RFC before this. So I guess we do not have an issue there 
but rather a clear order in which things will get done, do we?

I wasn't aware that while deterministic delivery was in the architecture draft, 
it's not yet in the charter. Perhaps it should be made more explicit in the 
architecture. Right now, "deterministic" is everywhere in the draft, starting 
with the abstract.


Rightly so. The architecture was in the charter. We even had a data model 
chartered to configure tracks but we dropped the item. It was too early; even 
before DetNet formed. Instead some of us went in and helped form DetNet with a 
goal to inherit in a consistent way. Since we never rechartered for tracks. We 
feel that the RAW WG should do it.


> With respect to routing and forwarding, this draft builds upon the work 
> already done in the 6lowpan WG, such as RPL for routing and 6lowpan header 
> compression. It adds the necessary scheduling and time synchronization 
> functions needed to support the TSCH aspects of IEEE 802.15.4, which is the 
> point of this work. But other than these new aspects, routing and forwarding 
> should continue to work to the extent that they work in the 6lowpan 
> specifications. My one concern regarding IPv6 forwarding is the use of 
> draft-svshah-tsvwg-lln-diffserv-recommendations in section 4.7.2. See my 
> major issues below for more on this concern.

 That will be entirely removed, please see below.

Thanks.


Major issues:

--

I'm concerned with the number of references to individual drafts (even if 
informational) in a major architecture specification, since the rest of the 
work on this technology, including solution documents, will rest on the 
correctness and completeness of the architecture. If these references are 
essential, then I would recommend that publication of the architecture be 
delayed until it's more clear whether these individual drafts will be adopted 
by a WG, and any abandoned individual drafts be removed. Otherwise, how can a 
published architecture depend on unpublished, abandoned work? Speaking of 
which, I note that one of those referenced drafts, 
draft-svshah-tsvwg-lln-diffserv-recommendations, hasn't been updated in over 
four years, and should either be removed or adopted by the 6tisch WG. Another, 
draft-thubert-bier-replication-elimination, hasn't been updated in over a year. 
Is it still alive? At least the remaining individual drafts have fairly recent 
updates.

 Yes, the link to svshah-tsvwg-lln-diffserv-recommendations is not really 
used in the architecture, it’s more of a pointer to work that we thought years 
ago would happen at TSVWG and never did. DetNet never seemed to depend on it 
either. I should really have removed that link on my own in addition to the 
changes I did in reaction to Gorry’s review, it will be gone in -22. I’ll also 
remove what is section 4.8.3 in -21. Looking at the other non-WG doc 
references, I do not think that the same reasoning applies, but I’m happy to 
discuss that in more depth.

Of the other references, I'm most concerned about 
draft-thubert-bier-replication-elimination. It would be really good for both 
6tisch and DetNet if you could work with the bier WG to get it active and 
adopted there.


Actually we are working on a RAW OAM spec and when published I could update the 
reference.


Minor issue:

To the extent that this architecture makes use of centralized control 
mechanisms such as PCE, the security considerations should mention this 
dependency and perhaps have a short discussion of effects on the network if 
connectivity betwe

Re: [6tisch] RtgDir review: draft-ietf-6tisch-architecture-21.txt

[Pascal Thubert (pthubert)]

Hello Andrew:

Many thanks for your in-depth review.

Please see below:



>  The primary editor of this draft is also active in the DetNet working group, 
> and leverages the work being done there to support the work in this draft. 
> The draft does reference some DetNet technologies that have not yet been 
> completely specified to the point where they can be implemented such as PREOF 
> (Packet Replication, Elimination and Ordering Functions), although such 
> specifications are an expected deliverable in the DetNet WG. So a full 
> implementation of this architecture may have to wait for the completion of 
> the related DetNet specification work.

 Very true. Note that 6TiSCH was not chartered to deliver specifications to 
implement the deterministic side of the architecture. We hope to form RAW to do 
that, and RAW would inherit from DetNet’s specifications that are on the works 
now. At the architecture level, the reference we need is the DetNet 
architecture that introduces PREOFs, not the specs. And as you know, the DetNet 
architecture will be RFC before this. So I guess we do not have an issue there 
but rather a clear order in which things will get done, do we?

> With respect to routing and forwarding, this draft builds upon the work 
> already done in the 6lowpan WG, such as RPL for routing and 6lowpan header 
> compression. It adds the necessary scheduling and time synchronization 
> functions needed to support the TSCH aspects of IEEE 802.15.4, which is the 
> point of this work. But other than these new aspects, routing and forwarding 
> should continue to work to the extent that they work in the 6lowpan 
> specifications. My one concern regarding IPv6 forwarding is the use of 
> draft-svshah-tsvwg-lln-diffserv-recommendations in section 4.7.2. See my 
> major issues below for more on this concern.

 That will be entirely removed, please see below.

Major issues:

--

I'm concerned with the number of references to individual drafts (even if 
informational) in a major architecture specification, since the rest of the 
work on this technology, including solution documents, will rest on the 
correctness and completeness of the architecture. If these references are 
essential, then I would recommend that publication of the architecture be 
delayed until it's more clear whether these individual drafts will be adopted 
by a WG, and any abandoned individual drafts be removed. Otherwise, how can a 
published architecture depend on unpublished, abandoned work? Speaking of 
which, I note that one of those referenced drafts, 
draft-svshah-tsvwg-lln-diffserv-recommendations, hasn't been updated in over 
four years, and should either be removed or adopted by the 6tisch WG. Another, 
draft-thubert-bier-replication-elimination, hasn't been updated in over a year. 
Is it still alive? At least the remaining individual drafts have fairly recent 
updates.

 Yes, the link to svshah-tsvwg-lln-diffserv-recommendations is not really 
used in the architecture, it’s more of a pointer to work that we thought years 
ago would happen at TSVWG and never did. DetNet never seemed to depend on it 
either. I should really have removed that link on my own in addition to the 
changes I did in reaction to Gorry’s review, it will be gone in -22. I’ll also 
remove what is section 4.8.3 in -21. Looking at the other non-WG doc 
references, I do not think that the same reasoning applies, but I’m happy to 
discuss that in more depth.

 The other non-WG docs are given as an informational early sense of how 
things could be implemented. We have this “Architecture Components” (section 4) 
that goes deeper than the usual architecture docs (more like our section 3). 
This is because this architecture tracked the WG as it went (like a spiral 
design or an agile approach) as opposed to the traditional cascading design 
stages. So we had those references live as we went over the last 5 years, from 
which svshah-tsvwg-lln-diffserv-recommendations appears like a unfiltered 
leftover. Also, the architecture is really an IOT architecture, that positions 
work done in multiple IETF WGs and ensures the global consistency and 
completeness. We value the archiving of section 4 because it provides the 
missing link between the high level architecture and what the group actually 
worked on (e.g., 6P) or pushed to other WGs such as ROLL and 6lo to obtain that 
overall consistency that was really missing 5 years ago.

 OTOH, the architecture does not depend on those informational references. 
e.g.,  selander-ace-cose-ecdhe : LAKE BoF is happening at IETF 105. The 6TiSCH 
zerotouch will depend on LAKE as indicated in the architecture, but the 
architecture itself does not. This is given as an indication of how zerotouch 
could be done. For all I know, Thread is working on their own zerotouch that 
must have an equivalent functionality and that may not be edhoc. Fine with me 
at the architecture level, the key is to describe the model and po

Re: [6tisch] RtgDir review: draft-ietf-6tisch-architecture-21.txt

[Pascal Thubert (pthubert)]

Hello Andrew

Many thanks for the huge investment of time you spent on our technology. I hope 
you found the context of interest.

Gory provided a similar feedback and I published 21 to address the specific 
point of references. Some were removed, some are now WG docs that were not, and 
the language was clarified to indicate some references are given as examples of 
how a particular feature could be achieved.

Would you please pick 21 and reassess your main comment below in the light of 
that update ?

All the best,

Pascal

Le 22 juin 2019 à 18:17, Andrew G. Malis 
mailto:agma...@gmail.com>> a écrit :

One quick follow-up to my review - I just noticed that while the draft's 
intended status (in the draft) is Informational, the Datatracker lists it as 
Proposed Standard. The Datatracker should be updated.

Thanks,
Andy

On Fri, Jun 21, 2019 at 5:28 PM Andrew G. Malis 
mailto:agma...@gmail.com>> wrote:
Hello,

I have been selected as the Routing Directorate reviewer for this draft. The 
Routing Directorate seeks to review all routing or routing-related drafts as 
they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs. 
For more information about the Routing Directorate, please see 
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.

Document: draft-ietf-6tisch-architecture-21.txt
Reviewer: Andy Malis
Review Date: 21 June 2019
IETF LC End Date: 26 June 2019
Intended Status: Informational

Summary:

I have significant concerns about this document and recommend that the Routing 
ADs discuss these issues further with the authors.

Overall comments:

For this review, I was asked to "Focus on the impact/implications of the 
architecture on routing/forwarding." I will leave minor details such as 
editorial nits to others.

This is a very long and detailed document, and I have no prior experience with 
IEEE 802.15.4, 6lowpan, 6tisch, RPL, and related technologies. To prepare for 
this review I did some basic background reading, such an online introduction to 
IEEE 802.15.4 and RFC 7554. So in this review, I really don't feel competent to 
comments on some of the more technical aspects related to those technologies. 
However, I do feel competent to comment from the viewpoint of a naive reader 
with a general background in routing. As a naive reader, I appreciated the 
introduction to the technology in sections 1-3.

The primary editor of this draft is also active in the DetNet working group, 
and leverages the work being done there to support the work in this draft. The 
draft does reference some DetNet technologies that have not yet been completely 
specified to the point where they can be implemented such as PREOF (Packet 
Replication, Elimination and Ordering Functions), although such specifications 
are an expected deliverable in the DetNet WG. So a full implementation of this 
architecture may have to wait for the completion of the related DetNet 
specification work.

With respect to routing and forwarding, this draft builds upon the work already 
done in the 6lowpan WG, such as RPL for routing and 6lowpan header compression. 
It adds the necessary scheduling and time synchronization functions needed to 
support the TSCH aspects of IEEE 802.15.4, which is the point of this work. But 
other than these new aspects, routing and forwarding should continue to work to 
the extent that they work in the 6lowpan specifications. My one concern 
regarding IPv6 forwarding is the use of 
draft-svshah-tsvwg-lln-diffserv-recommendations in section 4.7.2. See my major 
issues below for more on this concern.

Major issues:

I'm concerned with the number of references to individual drafts (even if 
informational) in a major architecture specification, since the rest of the 
work on this technology, including solution documents, will rest on the 
correctness and completeness of the architecture. If these references are 
essential, then I would recommend that publication of the architecture be 
delayed until it's more clear whether these individual drafts will be adopted 
by a WG, and any abandoned individual drafts be removed. Otherwise, how can a 
published architecture depend on unpublished, abandoned work? Speaking of 
which, I note that one of those referenced drafts, 
draft-svshah-tsvwg-lln-diffserv-recommendations, hasn't been updated in over 
four years, and should either be removed or adopted by the 6tisch WG. Another, 
draft-thubert-bier-replication-elimination, hasn't been updated in over a year. 
Is it still alive? At least the remaining individual drafts have fairly recent 
updates.

A related concern is that this draft specifically depends on work to be done 
elsew

Re: [6tisch] RtgDir review: draft-ietf-6tisch-architecture-21.txt

[Pascal Thubert (pthubert)]

Hello Andrew:

This is another change with Gorry’s review.
The spec was intended to follow the path of the DetNet architecture as ses 
track but we’ll follow the A-Ds and the message was to shoot for informational. 
So we just changed for it.


Regards,

Pascal

Le 22 juin 2019 à 18:17, Andrew G. Malis 
mailto:agma...@gmail.com>> a écrit :

One quick follow-up to my review - I just noticed that while the draft's 
intended status (in the draft) is Informational, the Datatracker lists it as 
Proposed Standard. The Datatracker should be updated.

Thanks,
Andy

On Fri, Jun 21, 2019 at 5:28 PM Andrew G. Malis 
mailto:agma...@gmail.com>> wrote:
Hello,

I have been selected as the Routing Directorate reviewer for this draft. The 
Routing Directorate seeks to review all routing or routing-related drafts as 
they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs. 
For more information about the Routing Directorate, please see 
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.

Document: draft-ietf-6tisch-architecture-21.txt
Reviewer: Andy Malis
Review Date: 21 June 2019
IETF LC End Date: 26 June 2019
Intended Status: Informational

Summary:

I have significant concerns about this document and recommend that the Routing 
ADs discuss these issues further with the authors.

Overall comments:

For this review, I was asked to "Focus on the impact/implications of the 
architecture on routing/forwarding." I will leave minor details such as 
editorial nits to others.

This is a very long and detailed document, and I have no prior experience with 
IEEE 802.15.4, 6lowpan, 6tisch, RPL, and related technologies. To prepare for 
this review I did some basic background reading, such an online introduction to 
IEEE 802.15.4 and RFC 7554. So in this review, I really don't feel competent to 
comments on some of the more technical aspects related to those technologies. 
However, I do feel competent to comment from the viewpoint of a naive reader 
with a general background in routing. As a naive reader, I appreciated the 
introduction to the technology in sections 1-3.

The primary editor of this draft is also active in the DetNet working group, 
and leverages the work being done there to support the work in this draft. The 
draft does reference some DetNet technologies that have not yet been completely 
specified to the point where they can be implemented such as PREOF (Packet 
Replication, Elimination and Ordering Functions), although such specifications 
are an expected deliverable in the DetNet WG. So a full implementation of this 
architecture may have to wait for the completion of the related DetNet 
specification work.

With respect to routing and forwarding, this draft builds upon the work already 
done in the 6lowpan WG, such as RPL for routing and 6lowpan header compression. 
It adds the necessary scheduling and time synchronization functions needed to 
support the TSCH aspects of IEEE 802.15.4, which is the point of this work. But 
other than these new aspects, routing and forwarding should continue to work to 
the extent that they work in the 6lowpan specifications. My one concern 
regarding IPv6 forwarding is the use of 
draft-svshah-tsvwg-lln-diffserv-recommendations in section 4.7.2. See my major 
issues below for more on this concern.

Major issues:

I'm concerned with the number of references to individual drafts (even if 
informational) in a major architecture specification, since the rest of the 
work on this technology, including solution documents, will rest on the 
correctness and completeness of the architecture. If these references are 
essential, then I would recommend that publication of the architecture be 
delayed until it's more clear whether these individual drafts will be adopted 
by a WG, and any abandoned individual drafts be removed. Otherwise, how can a 
published architecture depend on unpublished, abandoned work? Speaking of 
which, I note that one of those referenced drafts, 
draft-svshah-tsvwg-lln-diffserv-recommendations, hasn't been updated in over 
four years, and should either be removed or adopted by the 6tisch WG. Another, 
draft-thubert-bier-replication-elimination, hasn't been updated in over a year. 
Is it still alive? At least the remaining individual drafts have fairly recent 
updates.

A related concern is that this draft specifically depends on work to be done 
elsewhere in and outside of the IETF that is currently unchartered (see section 
A.2). Many of the individual drafts discussed in the previous paragraph are 
referenced in this section. To the extent that 6tisch depends on this work for 
its own eventual success, the WG may