Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4691A129533 for <6tisch@ietfa.amsl.com>; Fri, 31 Mar 2017 09:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yri6JYY6pibl for <6tisch@ietfa.amsl.com>; Fri, 31 Mar 2017 09:38:55 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176781287A5 for <6tisch@ietf.org>; Fri, 31 Mar 2017 09:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=84028; q=dns/txt; s=iport; t=1490978331; x=1492187931; h=from:to:subject:date:message-id:mime-version; bh=cvQsa5gpYmPsH+th51mSBEDkJMVnFwEiVvzLcbE7xQQ=; b=Ka/ehN6MxcznBPfX+G76w3WrvggWwjoQQuEFBDhGdElvs+bhnxDjh4zs pHApRp4VrZboCxX/ZELSEXao8TU/qBp2f7Voez/zIBr0h9k9HRHRN2bNP WDK0j7NxQu3wBN3zFr0ZXnf9FmxHgdJhV+ZUrEdI7icOc+4AdgSlPjbfJ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQBKhd5Y/5tdJa1SChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuZmGBCweNbZRykjOCCwMfAQyFLIQSPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?aAwEYAQIQPgMEGQEaJgE0CxcPAQQTCBKJcw6dS5Isil0BAQEBAQUBAQEBAQEBI?= =?us-ascii?q?YZOgm15hTUECgSCYoMZBYkbDAWIB4Q2hwEBhnyLSoIGVIJggXiDWYY4iFyGb4Q?= =?us-ascii?q?lAR84gQVbFUGEWAEdgWIBdQGHHYEwgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,252,1486425600"; d="scan'208,217";a="404704156" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Mar 2017 16:38:48 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2VGcmec023900 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <6tisch@ietf.org>; Fri, 31 Mar 2017 16:38:48 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 31 Mar 2017 11:38:47 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Fri, 31 Mar 2017 11:38:47 -0500 From: "Pascal Thubert (pthubert)" To: "'6tisch@ietf.org'" <6tisch@ietf.org> Thread-Topic: Minutes, IETF 98 6TiSCH WG Meeting Thread-Index: AdKqPLZtBg3mmtf1SPOmmg4iOMPqmQ== Date: Fri, 31 Mar 2017 16:37:19 +0000 Deferred-Delivery: Fri, 31 Mar 2017 16:35:50 +0000 Message-ID: <1fe7e4dfed5c49e88534a8a555953d43@XCH-RCD-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.99.85] Content-Type: multipart/alternative; boundary="_000_1fe7e4dfed5c49e88534a8a555953d43XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [6tisch] Minutes, IETF 98 6TiSCH WG Meeting X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 16:39:07 -0000 --_000_1fe7e4dfed5c49e88534a8a555953d43XCHRCD001ciscocom_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Dear all: Please find the minutes of the 6TiSCH meeting. Deepest thanks to our faithful note takes and jabber scribes who made this = possible. Agenda and Meeting information Meeting : IETF 98; Tuesday, March 28, 2017 (CST) Time : 9:00-11:30, Tuesday Morning session I Location : Room Zurich C, Chicago Swisshotel Concourse Level Chairs : Pascal Thubert Thomas Watteyne (remote) Michael Richardson (acting) Responsible AD : Suresh Krishnan URLs : http://tools.ietf.org/wg/6tisch/ https://datatracker.ietf.org/wg/6tisch/ https://www.ietf.org/mailman/listinfo/6tisch https://bitbucket.org/6tisch * Intro and Status (10mn) (Chairs) * Note-Well, Blue Sheets, Scribes, Agenda Bashing [ 5min] * draft-ietf-6tisch-minimal-21, draft-ietf-6tisch-terminology-08, progress vs. charter [ 5min] * Security (75min, lead by Michael) * Presenting the drafts and the flow between them (Michael) [20min] * draft-ietf-6tisch-dtsecurity-secure-join-01 (Michael) [15min] * draft-ietf-6tisch-minimal-security-02 (Mali=B9a) [15mi= n] * draft-richardson-6tisch-join-enhanced-beacon-01 [10min] * draft-richardson-6tisch-minimal-rekey-01 [10min] * 6top protocol draft-ietf-6tisch-6top-protocol-03 (Xavi) [15min] * Service Function 0 draft-ietf-6tisch-6top-sf0-03 (Diego) [15min] * Architecture draft-ietf-6tisch-architecture-11 (Pascal) [10min] * News from IEEE 802.15.4 (Pat) [15min] * Detnet backhaul draft-wang-detnet-backhaul-architecture-00 (Lun) [10min] * Any Other Business (Chairs) [ 5min] Resources * agenda: https://datatracker.ietf.org/meeting/98/agenda/6tisch/ * presented slides: https://www.ietf.org/proceedings/98/slides/slides-9= 8-6tisch-aggregated-slides-06.pdf Summary _This summary is also posted in the INT area wiki, https://trac.ietf.org/tr= ac/int/wiki/IETF98 The Working Group meeting went smoothly and according to agenda, started an= d completed in time. All the expected slots took place except for the last one on detnet-backhau= l-architecture which was informative to the group. The group is ready to call for adoption for the 6P and SF0 documents, with = restrictions. The first restriction is the lack of feedback information from SF on whethe= r the panel of capabilities from 6P is sufficient to achieve all the needs = to an abstract SF. This will be alleviated by experience from the interop t= est in Prague so we expect to be ready then. Also remarks on the lack of definition of the service interface between SF = and 6P, e.g. pointing on the responsibility of the timeouts and the values = incurred. The largest piece of the meeting dealt with security. The framework was pre= sented in which the minimal security based on PSK can be seen as an optiona= l portion of the larger flow that starts with private keys / certificates a= nd fits within the ANIMA framework. A status was given on related work in other WG and at the IEEE. Volunteers * notetaker 1: Dominique Barthel * notetaker 2: Geraldine Texier * notetaker 3: Francesca Palombini * notetaker 4: Alexander Pelov * notetaker 5: Tero Kivinen * notetaker 6: Xavi Vilajosana * notetaker 7: Pascal Thubert * Jabber scribe 1: Diego Dujovne * Jabber scribe 2: Ines Robles * Jabber scribe 3: Michael Richardson Minutes * [09.01] (expected: 09.00) meeting starts * Thomas calling in from Paris * [09.03] (expected: 09.00) Intro and Status (10mn) (Chairs) * [09.03] (expected: 09.00) Note-Well, Blue Sheets, Scribes, Agenda = Bashing [ 5min] * Pascal goes through agenda: * 70 min dedicated to security, will be able to do some work inst= ead just present slides. * -minimal: Xavi now integrated all comments/reviews. -21 should = go to IESG * [??.??] (expected: 09.05) draft-ietf-6tisch-minimal-21, draft-ietf= -6tisch-terminology-08, progress vs. charter [ 5min] * mcr: plans for future plugtest ? * Thomas: yes, at Prague, probably 14 and 15 July, or after meeting.= Physical meeting but tools for online testing. At the next interim meeting= we'll discuss the scope of the interop. Likely -minimal, 6top, minimal sec= . * we'll have an expert team to write the test description * Kerry: 6lo plugtest as well? Pascal: will see. * Suresh: -minimal underwent major review, many reviewers provided c= omments. Going to RFC editors. was approved a week ago. * [09.12] (expected: 09.10) Security (75min, lead by Michael) * presented at Detnet and ANIMA yesterday. Will repeat intro anyway. * [09.13] (expected: 09.10) Presenting the drafts and the flow betwe= en them (Michael) [20min] * goal: explain how the drafts fit together. * every 2 weeks phone meetings * new Doodle poll. If you couldnt make it to the past times, cast= your vote for better times. * security considerations in ROLL actually applies to all LLNs * zero-touch: designed for networks that need to scale to huge nu= mber of nodes * the two security drafts were adopted after last IETF meeting * -enhanced-beacon: could not wait for -minimal, wrote ED usage d= escription in separate draft * new terminology used: pledge - join registrar/coordinator - joi= n proxy * took some terms form ANIMA. E.g. MASA Manufacturer Auhtorised S= igning Autority * sets PSK if manufacturers knows which customer the device is sh= ipped to. * Michael goes through decision tree for Pledge node to join. Hea= ring first EB can be very long, consumes energy. Subir: reason for going ba= ck in decision tree? mcr: if heared EB from wrong network * table of constraints: Michael interestsed in knowing other cont= raints that migh have been missed * * high level explanation of PSK and RPK cases. For FPK, needs to = do EDHOC first (see ACE presentation) * Thomas: re. time to join. you can optimize many things, we are = talking about seconds not minutes though. one of the constraints is that yo= u get all the nodes to join roughly at the same time ("flood of join"). One= use-case: when installing a network in a plant, booting the router last, e= very nodes will join at the same time * Benjamin Damm: ? mcr: bring question to the list, it's a diffic= ult one. One example is two "identical" parts were swapped during shipment = to two customers. "Just" need to redo pre-provisioning, not swap the part. = How? * * [09.34] (expected: 09.30) draft-ietf-6tisch-dtsecurity-secure-join= -01 (Michael) [15min] * status of the document: reduced this to the scope of the zero-t= ouch, pushed some content to -minimal or other * Thomas: will we have an opportunity to talk about IP-IP vs. CoA= P? mcr: good question, let's take that at the end. * will use CBOR Web Token as a voucher, will reuse a lot of code = (COSE, CBOR already in place) * ANIMA so far not using CBOR, negociation going-in to unify. * presentation of anima document. Revocation not needed. * Max: you can find this in the notes from Anima meeting * Suresh: regardin one and zero-touch: what is going to be the up= date of one vs the other? mcr: goal to make the on-the-wire mechanism as cl= ose as possible. Expect to see devices that are both-capable. You can see t= hat the differences are not big right now (Ack for bandwith control). * one difference is rate of requests: if Pledge drives the timing= and many pledges, not much control. Il JCR drives its own rate, can contro= l. * Suresh: at some point you still have to choose between those tw= o. mcr: if you have a manifacturer that can put a PSK in it for you, you ca= n do that. If you have a large number of devices or many manifacturers, you= may want to go to one touch instead. * Thomas: or you can have a configuration step * Suresh: question still remains. What if you have one mechanism?= Is it possible to reduce these two processes into one? * mcr: trying to build a protocol that allows you to deal with di= fferent cases: if we have the PSK, we can do the simplest thing, otherwise = we can do this other thing. For example, might have a PSK for network A, an= d if deployed in network B, still ok since has a DevID. * Suresh: . * mcr: proposal by Goran, but doesn't have a home yet. * mcr goes through questions listed at ANIMA. * Please help articulate the benefit of using of CWT instead of a= dding PKCS7. * Open Issues * pictures ideal outcome, with convergence between 6Tisch, ANIMA = , * [09.56] (expected: 09.45) draft-ietf-6tisch-minimal-security-02 (M= ali=B9a) [15min] * status: -02 includes major editorial restructuring, stabilizes = the Join Process * this is one touch scenario draft * presentation of the join process * security handshake: this is the current version, and is not set= in stone * Mohit: security hanshake, said could use EDHOC. Why rely on EDH= OC if using P SK? * Malisa: in case of PSK it's optional to run EDHOC, if you requi= re perfect forward secrecy you can run EDHOC with PSK, in case of RPK it's = mandatory. * mcr: 3a (refer to message in the slides) (AAA) is optional when= you don't use PSK. * Join Proxy operated as CoAP proxy in previous version of draft.= Now new CoAP option to carry state between Proxy and Server, * could do IP-in-IP but proble is 3 IP headers, how about compres= sion. * Pascal: provide example on the list for discussion. If all pref= ixes same as LBR, might be able to compress. * Carsten: could you present the status of this doc (incl. Join P= roxy) at CoRE meeting end of the week? mcr: Friday morning. Malisa can make= it. * Thomas: re. IP-in-IP vs. CoAP: CoAP can use well-known resource= s, saves a lot of exchanges that we have to do with IP-in-IP. * mcr: I dont think we have to do all that: specifically, the add= ress of JRC could be LL-anycast, and I don't think that there any other add= resses that the pledge needs to know. * describes how nonce and key are generated in OSCOAP at the pled= ge and at the JRC * Mohit: which values provide enthropy? Malisa: we are using the = OSCOAP mechanism, we only use it in our case. Mohit: ok, will check with au= thors and carry forward on the mailing list. * Pascal: Interested in the discussion about the nonce transport = because LoRaWAN seems to use similar mechanism so if real pb would like to = know! * [10.16] (expected: 10.00) draft-richardson-6tisch-join-enhanced-be= acon-01 [10min] * Diego presents. * Draft meant to add join information into EB to make joining mor= e efficient. * beware that EB is not encrypted, should not put here stuff that= should not be seen by attacker, e.g. PIO. * Erik: it is not clear what this Network ID is. mcr: hash of DOD= AG id. Issue is that it's constant across time. As long as connected to sam= e root. * Malisa: why is PAN ID not enough? mcr: we might decide that we = always use a constant PAN ID, maybe it is enough. Diego: a combination of b= oth * Thomas: Ask same question about PAN ID. PAN ID might be the sim= plest way. * Subir: slide 3. How do you identify JCE? mcr: This is from the = Join Proxy. L2 address and ... * Benjamin: Frequency bands/channels to use. How does it get to k= now about it? mcr: not an IETF problem. * Diego: asking for comments about adoption. * Pascal: interest in the document. Should this document be adopt= ed at some point by this WG? (about two in favour), (nobody against), (two = have read document) * Samita: ? Diego: * mcr: next presentation will respond to Samita's question. * [10.28] (expected: 10.10) draft-richardson-6tisch-minimal-rekey-01= [10min] * Michael presents new draft. Presentation about the concept behi= nd it. Uses CoMI. * when node receives draft with a given key in table, will start = sending traffic with this same key. * Mohit: do keys have key id? mcr: yes, on the wire * allows to eliminate malicious node off the network, but may tak= e a long time because need to rekey all the other nodes, that may be sleepy= and will keepy accepting previous keys for some time. * Kerry Lynn: are there requirements that nodes wake up every n d= ays? mcr: if you dont wake up every time and then you would lose desyncroni= sation AND you would loose the keys as well, so it's not a big addition to = the requirements. * Interested in adopting this, using CoMI (possibly CoMI co-autho= r) * [10.34] (expected: 10.25) 6top protocol draft-ietf-6tisch-6top-protoc= ol-03 (Thomas replacing Xavi) [15min] * stable document. About distributed 6TiSCH cell allocation. * few cahnges from previous version. Most notable is relocate comman= d to improve on delete+create cell. * authors believe the draft is ready, but few unknows: relation with= SF, missing functionalities? * will know from 6TiSCH plugtest event in July. * Pascal: ask for in depth reviews, in particular from an allocation= expert. Diego, Charlie will review this document. * Pascal: after review, will ask for last call. * Thomas (as chair): would feel more confortable moving it to last c= all if all the pieces fit together, in particular feedback from implementor= s about 6P+SF0 * [10.40] (expected: 10.35) Scheduling Function 0 draft-ietf-6tisch-6to= p-sf0-03 (Diego) [15min] * this draft is about a simple scheduling function. * following discussion at IETF97, adopted one mechanism for bandwith= estimation. * Packet Delivery Ratio estimation computed on last 10 packet transm= ission. Is 10 a good value? * Timeout: Yasuyuki proposed algorithm. See discussion on mailing li= st (Dec 2016 onward). * Thomas: algorithm already implemented in 6P. The 6top draft says t= imeout value is left to the SF, because it's the only entity in the node th= at has the full view. diego: we are thinking about the whole transaction, i= nstead of a timeout for each of the exchanges. Now you have to calculate th= e worst timeout between all the exchanges, which is very long. Pascal: let'= s take that to the mailing list. * discussion on cell relocation: oprions are * when PDR gets significantly worse that average for all cells * constant relocation to number of random cells () * leave it to implementation * Tengfei: For the PDR_THRESHOLD, each cell is provisioned by differ= ent SFs, so as long as the cell is related by the corresponding SF, which i= s running on one side, there is no issue for interoperability. (Copied over= from jabber) Thomas Requested to start a Thread on the ML on that Malisa o= n mic: there is a 6tsich simulator available on the bitbucket page that is = convenient for simulating this sorts of algorithms. please take a look. * Muhammad Majhal (yyy univ UK): ? Thoams: TSCH link layer provides = duty cycling. * PAscal: this draft should ship together wth 6top. But pobably as i= nformational, and make second version as standards track when we have more = experience * Malisa (from jabber): there is a 6tsich simulator available on the= bitbucket page that is convenient for simulating this sorts of algorithms.= please take a look. * [11.00] (expected: 10.50) Architecture draft-ietf-6tisch-architecture= -11 (Pascal) [10min] * considerationa about "tracks". Also provided in Detnet draft. A 6T= iSCH is not just a serial sequence of cells along a path. Can include repli= cation/elimination. * published draft at BIER to describe how this path replication (usi= ng Arc routing) works. * Tests have been performed to combine BierTE mechanism with tracks.= A bitmap tells the path to take. * The bitmap indicate the paths that failed or not, enabeling an OAM= mechanism and a control loop * Kerry Lynn: how does this compare to FEC? Pascal: we are mostly ai= ming at protecting against node failure; TSCH is pretty good at reducing li= nk failure probability. * Pascal: take advantage of inherent broadcasting of radio to do "bi= -casting", by having two receivers and one transmitter per cell. This incre= ases reliability. * Also expose node multiple parents to RPL root (in non-storing mode= ), shows the full structure. Root can find shorter pathes. Effectively redu= ces latency. * Recap: tracks are much more than sequence of cell. * Tengfei: we are conducting large-scale experiments of 6P SF0 on th= e IoT-lab, with 100-nodes runnign openWSN. will contribute results to the g= roup verifying the current of 6p and SF0 work. * Malisa: working on 6TiSCH simulator, on BitBucket. Will contribute= the results to the group. Explore the code and contribute. * Pascal: please write that in the mailing list * [11.15] (expected: 11.00) News from IEEE 802.15.4 (Pat) [15min] * 15.4q: new low power PHY, has Amplitude Shift Keying. Not backward= comptabible. * 15.4t: 2Mbps, backward compatible with current radios. * next 15.4 revision will integrate 6 amendments and include corrige= nda. * 15.9: Information Elements for Key Management Protocols. o 15.10: layer 2 routing. Meant to support "large scale" networks (node c= ount in the thousands). Randy Turner asked what is large scale, Charlie answered thousand o 15.12: upper layer over 15.4. Defines concept of profiles (e.g. for WiS= un or Thread). * Muhammad: 15.6 ? Pat: 15.6 is medical Body Area Network. MAC simil= ar to 15.4. But nobody at 15.6 asked 15.12 to consider their techno * Carsten: Is this all done? Pat: no it's underway right now. We do = need help. * Bob: 15.6 has a limited stack architecture, star topology, very is= olated approach to many things, very closed, trying to put 15.6 in discussi= on is challenging at best, talking about 15.7 would be much better. * Need participation from this group. * [xx.xx] Detnet backhaul draft-wang-detnet-backhaul-architecture-00= (Lun) [10min] * skipped for lack of time * [11.29] (expected: 11.25) Any Other Business (Chairs) [ 5min] * Samita: please come to 6lo * [11.30] (expected: 11.30) meeting ends --_000_1fe7e4dfed5c49e88534a8a555953d43XCHRCD001ciscocom_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Dear all:

Please find the minutes of the 6TiSCH meeting.=

Deepest thanks to our faithful note takes and jabbe= r scribes who made this possible.

Agenda and Meeting information

Meeting      &n=
bsp; :   IETF <=
span class=3D"mi">98; Tue=
sday, March 28, 2017 (CST) 
Time       =
;    :   9:00-11:30, Tuesday=
 Morning session <=
span class=3D"n">I
Location       =
:   Room Zurich C, Chicago Swisshotel Concourse Level<=
/pre>

Chairs      &nb=
sp;  :   Pascal Thubert <pthubert@cis=
co.com>


           &nbs=
p;       Thomas Watteyne <thomas.watteyne=
@inria.fr> (remote)=



           &nbs=
p;       Michael Richardson <mcr+ietf@sandelman.ca> (acting)<=
/span>


Responsible AD :   Suresh Krishnan


URLs       =
;    :   http://tools.ietf.org/wg/6tisch/<=
/o:p>


           &nbs=
p;       https://datatracker.ietf.org/wg/6tisch/


           &nbs=
p;       https://www.ietf.org/mailman/listinfo/6=
tisch


           &nbs=
p;       https://bitbucket.=
org/6tisch


 


* Intro and Status (10mn)=
 (Chairs)


    * Note-Well, Blue Sheets, Scribes=
, Agenda Bashing&n=
bsp;            =
;  [ 5min]


    * draft<=
/span>-ietf-6tisch-minimal-21, 


      draft-ietf-6tisch-terminology-08, 


      progress =
vs. cha=
rter          &nbs=
p;            &=
nbsp;           &nbs=
p;      [ 5min]


* Security (75min, lead by=
 Michael)


    * Presen=
ting the drafts and the f=
low between them <=
span class=3D"o">(Michael=
)     [20min]


    * draft<=
/span>-ietf-6tisch-dtsecurity-<=
/span>secure-join-01 (Michael)=
         [=
15min]


    * draft<=
/span>-ietf-6tisch-minimal-security-02 (Mali=B9a)           &nbs=
p;    [15=
min]


    * draft<=
/span>-richardson-6tisch=
-join-<=
/span>enhanced-beacon-01=
            &nb=
sp;  [10min]


    * draft<=
/span>-richardson-6tisch=
-minimal-rekey-01         &nb=
sp;            [10min]


* 6top protocol  draf=
t-ietf-6tisch-6top-protocol-03  (Xavi)   &=
nbsp;     [=
15min]<=
/pre>

* Service Function 0 draft=
-ietf-6tisch-6top-sf0=
-03  (Diego)     =
    [15min]


* Architecture draft-ietf-6tisch-architecture-11 (=
Pascal)  =
;         [10min=
]


* News from IEEE 802.15<=
/span>.4 (Pat) &nbs=
p;            &=
nbsp;           &nbs=
p;          =
[15min]


* Detnet backhaul draft-wang-detnet-backhaul<=
span class=3D"o">-architecture-00 (Lun)  [=
10min]


* Any Other Business (Chairs)  &nbs=
p;            &=
nbsp;           &nbs=
p;           [ 5min]


Resources



Summary


_This summary is also posted in the INT area wiki, 
https://trac.ietf.org/trac/int/wiki/IETF98


The Working Group meeting went smoothly and according to agenda, start=
ed and completed in time.


All the expected slots took place except for the last one on detnet-ba=
ckhaul-architecture which was informative to the group.


The group is ready to call for adoption for the 6P and SF0 documents, =
with restrictions.


The first restriction is the lack of feedback information from SF on w=
hether the panel of capabilities from 6P is sufficient to achieve all the n=
eeds to an abstract SF. This will be alleviated by experience from the inte=
rop test in Prague so we expect to be ready then.


Also remarks on the lack of definition of the service interface betwee=
n SF and 6P, e.g. pointing on the responsibility of the timeouts and the va=
lues incurred.


The largest piece of the meeting dealt with security. The framework wa=
s presented in which the minimal security based on PSK can be seen as an op=
tional portion of the larger flow that starts with private keys / certifica=
tes and fits within the ANIMA framework.


A status was given on related work in other WG and at the IEEE. <=
/o:p>


Volunteers


    

  • 
notetaker 1: Dominique Barthel
  • 
notetaker 2: Geraldine Texier
  • 
notetaker 3: Francesca Palombini
    • 
notetaker 4: Alexander Pelov
  • 
notetaker 5: Tero Kivinen
  • 
notetaker 6: Xavi Vilajosana
  • 
notetaker 7: Pascal Thubert
  • 
Jabber scribe 1: Diego Dujovne
  • 
Jabber scribe 2: Ines Robles
  • 
Jabber scribe 3: Michael Richardson


Minutes


    

  • 
[09.01] (expected: 09.00) meeting starts

      

    • 
Thomas calling in from Paris
    

  • 
[09.03] (expected: 09.00) Intro and Status (10mn) (Chairs)

      

    • 
[09.03] (expected: 09.00) Note-Well, Blue Sheets, Scribes, Agenda Bashing [=
 5min]

        

      • 
Pascal goes through agenda:
      • 
70 min dedicated to security, will be able to do some work instead just pre=
sent slides.
      • 
-minimal: Xavi now integrated all comments/reviews. -21 should go to IESG
      

    • 
[??.??] (expected: 09.05) draft-ietf-6tisch-minimal-21, draft-ietf-6tisch-t=
erminology-08, progress vs. charter [ 5min]
    • 
mcr: plans for future plugtest ? 
    • 
Thomas: yes, at Prague, probably 14 and 15 July, or after meeting. Physical=
 meeting but tools for online testing. At the next interim meeting we'll di=
scuss the scope of the interop.
Likely -minimal, 6top, minimal sec.
    • 
we'll have an expert team to write the test description
    • 
Kerry: 6lo plugtest as well? Pascal: will see.=

    • 
Suresh: -minimal underwent major review, many reviewers provided comments. =

Going to RFC editors. was approved a week ago.
    

  • 
[09.12] (expected: 09.10) Security (75min, lead by Michael)

      

    • 
presented at Detnet and ANIMA yesterday. Will repeat intr=
o anyway.
    • 
[09.13] (expected: 09.10) Presenting the drafts and the flow between them (=
Michael) [20min]

        

      • 
goal: explain how the drafts fit together.
      • 
every 2 weeks phone meetings
      • 
new Doodle poll. If you couldnt make it to the past times, cast your vote f=
or better times.
      • 
security considerations in ROLL actually applies to all LLNs
      • 
zero-touch: designed for networks that need to scale to huge number of node=
s
      • 
the two security drafts were adopted after last IETF meeting
      • 
-enhanced-beacon: could not wait for -minimal, wrote ED usage description i=
n separate draft
      • 
new terminology used: pledge - join registrar/coordinator - join proxy=

      • 
took some terms form ANIMA. E.g. MASA Manufacturer Auhtorised Signing Autor=
ity
      • 
sets PSK if manufacturers knows which customer the device is shipped to.
      • 
Michael goes through decision tree for Pledge node to join. Hearing first E=
B can be very long, consumes energy. Subir: reason for going back in decisi=
on tree? mcr: if heared EB from wrong network
      • 
table of constraints: Michael interestsed in knowing other contraints that =
migh have been missed
      • 
 
      • 
high level explanation of PSK and RPK cases. For FPK, needs to do EDHOC fir=
st (see ACE presentation)
      • 
Thomas: re. time to join. you can optimize many things, we are talking abou=
t seconds not minutes though. one of the constraints is that you get all th=
e nodes to join roughly at the same time ("flood of join"). One u=
se-case: when installing a network in a plant,
 booting the router last, every nodes will join at the same time=

      • 
Benjamin Damm: ? mcr: bring question to the list, it's a difficult one. One=
 example is two "identical" parts were swapped during shipment to=
 two customers. "Just" need to redo pre-provisioning, not swap th=
e part.
How?
      • 
 
      

    • 
[09.34] (expected: 09.30) draft-ietf-6tisch-dtsecurity-secure-join-01 (Mich=
ael) [15min]

        

      • 
status of the document: reduced this to the scope of the zero-touch, pushed=
 some content to -minimal or other
      • 
Thomas: will we have an opportunity to talk about IP-IP vs. CoAP? mcr: good=
 question, let's take that at the end.
      • 
will use CBOR Web Token as a voucher, will reuse a lot of code (COSE, CBOR =
already in place)
      • 
ANIMA so far not using CBOR, negociation going-in to unify.
        • =

      • 
presentation of anima document. Revocation not needed. 
      • 
Max: you can find this in the notes from Anima meeting
      • 
Suresh: regardin one and zero-touch: what is going to be the update of one =
vs the other? mcr: goal to make the on-the-wire mechanism as close as possi=
ble. Expect to see devices that are both-capable. You can see that the diff=
erences are not big right now (Ack
 for bandwith control).
      • 
one difference is rate of requests: if Pledge drives the timing and many pl=
edges, not much control.
Il JCR drives its own rate, can control.
      • 
Suresh: at some point you still have to choose between those two. mcr: if y=
ou have a manifacturer that can put a PSK in it for you, you can do that. I=
f you have a large number of devices or many manifacturers, you may want to=
 go to one touch instead.
      • 
Thomas: or you can have a configuration step 
      • 
Suresh: question still remains. What if you have one mechanism? Is it possi=
ble to reduce these two processes into one?
      • 
mcr: trying to build a protocol that allows you to deal with different case=
s: if we have the PSK, we can do the simplest thing, otherwise we can do th=
is other thing. For example, might have a PSK for network A, and if deploye=
d in network B, still ok since has
 a DevID.
      • 
Suresh: .
      • 
mcr: proposal by Goran, but doesn't have a home yet.
      • 
mcr goes through questions listed at ANIMA.
      • 
Please help articulate the benefit of using of CWT instead of adding PKCS7.=

      • 
Open Issues
      • 
pictures ideal outcome, with convergence between 6Tisch, ANIMA ,=

      

    • 
[09.56] (expected: 09.45) draft-ietf-6tisch-minimal-security-02 (Mali=B9a) =
[15min]

        

      • 
status: -02 includes major editorial restructuring, stabilizes the Join Pro=
cess
      • 
this is one touch scenario draft
      • 
presentation of the join process
        • 
security handshake: this is the current version, and is not set in stone
      • 
Mohit: security hanshake, said could use EDHOC. Why rely on EDHOC if using =
P SK?
      • 
Malisa: in case of PSK it's optional to run EDHOC, if you require perfect f=
orward secrecy you can run EDHOC with PSK, in case of RPK it's mandatory.
      • 
mcr: 3a (refer to message in the slides) (AAA) is optional when you don't u=
se PSK.
      • 
Join Proxy operated as CoAP proxy in previous version of draft. Now new CoA=
P option to carry state between Proxy and Server,
      • 
could do IP-in-IP but proble is 3 IP headers, how about compression.
      • 
Pascal: provide example on the list for discussion. If all prefixes same as=
 LBR, might be able to compress.
      • 
Carsten: could you present the status of this doc (incl. Join Proxy) at CoR=
E meeting end of the week? mcr: Friday morning.
Malisa can make it.
      • 
Thomas: re. IP-in-IP vs. CoAP: CoAP can use well-known resources, saves a l=
ot of exchanges that we have to do with IP-in-IP.

      • 
mcr: I dont think we have to do all that: specifically, the address of JRC =
could be LL-anycast, and I don't think that there any other addresses that =
the pledge needs to know.
      • 
describes how nonce and key are generated in OSCOAP at the pledge and at th=
e JRC
      • 
Mohit: which values provide enthropy? Malisa: we are using the OSCOAP mecha=
nism, we only use it in our case. Mohit: ok, will check with authors and ca=
rry forward on the mailing list.
      • 
Pascal: Interested in the discussion about the nonce transport because LoRa=
WAN seems to use similar mechanism so if real pb would like to know!
      

    • 
[10.16] (expected: 10.00) draft-richardson-6tisch-join-enhanced-beacon-01 [=
10min]

        

      • 
Diego presents.
      • 
Draft meant to add join information into EB to make joining more efficient.=

      • 
beware that EB is not encrypted, should not put here stuff that should not =
be seen by attacker, e.g. PIO.
      • 
Erik: it is not clear what this Network ID is. mcr: hash of DODAG id. Issue=
 is that it's constant across time. As long as connected to same root.=

      • 
Malisa: why is PAN ID not enough? mcr: we might decide that we always use a=
 constant PAN ID, maybe it is enough.
Diego: a combination of both
      • 
Thomas: Ask same question about PAN ID. PAN ID might be the simplest way.
      • 
Subir: slide 3. How do you identify JCE? mcr: This is from the Join Proxy. =

L2 address and ...
      • 
Benjamin: Frequency bands/channels to use. How does it get to know about it=
? mcr: not an IETF problem.
      • 
Pascal: interest in the document. Should this document be adopted at some point<=
/em> by this WG? (about two in favour), (nobody against), (two have read do=
cument)
      • 
Samita: ? Diego: 
      • 
mcr: next presentation will respond to Samita's question.
        • 

      • 
[10.28] (expected: 10.10) draft-richardson-6tisch-minimal-rekey-01 [10min]<=
o:p>

          

        • 
Michael presents new draft. Presentation about the concept behind it. 
Uses CoMI.
        • 
when node receives draft with a given key in table, will start sending traf=
fic with this same key.
        • 
Mohit: do keys have key id? mcr: yes, on the wire
        • 
allows to eliminate malicious node off the network, but may take a long tim=
e because need to rekey all the other nodes, that may be sleepy and will ke=
epy accepting previous keys for some time.
        • 
Kerry Lynn: are there requirements that nodes wake up every n days? mcr: if=
 you dont wake up every time and then you would lose desyncronisation AND y=
ou would loose the keys as well, so it's not a big addition to the requirem=
ents.
        • 
Interested in adopting this, using CoMI (possibly CoMI co-author)
        

      

    • 
[10.34] (expected: 10.25) 6top protocol draft-ietf-6tisch-6top-protocol-03 =
(Thomas replacing Xavi) [15min]

        

      • 
stable document. About distributed 6TiSCH cell allocation=
.
      • 
few cahnges from previous version. Most notable is relocate command to impr=
ove on delete+create cell.
      • 
authors believe the draft is ready, but few unknows: relation with SF, miss=
ing functionalities?
      • 
will know from 6TiSCH plugtest event in July.
      • 
Pascal: ask for in depth reviews, in particular from an allocation expert. =

Diego, Charlie will review this document.
      • 
Pascal: after review, will ask for last call.
      • 
Thomas (as chair): would feel more confortable moving it to last call if al=
l the pieces fit together, in particular feedback from implementors about 6=
P+SF0
      

    • 
[10.40] (expected: 10.35) Scheduling Function 0 draft-ietf-6tisch-6top-sf0-=
03 (Diego) [15min]

        

      • 
this draft is about a simple scheduling function.
      • 
following discussion at IETF97, adopted one mechanism for bandwith estimati=
on.
      • 
Packet Delivery Ratio estimation computed on last 10 packet transmission. <=
span lang=3D"FR">
Is 10 a good value?
      • 
Timeout: Yasuyuki proposed algorithm. See discussion on mailing list (Dec 2=
016 onward).
      • 
Thomas: algo=
rithm already implemented in 6P. The 6top draft says timeout
value=
 is left to the SF, because it's the only entity in the node that has =
the full view. diego: we are thinking about the whole transaction, instead =
of a timeout for each of the exchanges. Now
 you have to calculate the worst timeout between all the exchanges, which i=
s very long.
Pascal: let's take that to the mailing list.
      • 
discussion on cell relocation: oprions are

          

        • 
when PDR gets significantly worse that average for all cells
        • 
constant relocation to number of random cells (<did I get this right?>=
;)
        • 
leave it to implementation
        

      • 
Tengfei: For the PDR_THRESHOLD, each cell is provisioned by different SFs, =
so as long as the cell is related by the corresponding SF, which is running=
 on one side, there is no issue for interoperability. (Copied over from jab=
ber) Thomas Requested to start a
 Thread on the ML on that Malisa on mic: there is a 6tsich simulator availa=
ble on the bitbucket page that is convenient for simulating this sorts of a=
lgorithms. please take a look.
      • 
Muhammad Majhal (yyy univ UK): ? Thoams: TSCH link layer provides duty cycl=
ing.
      • 
PAscal: this draft should ship together wth 6top. But pobably as informatio=
nal, and make second version as standards track when we have more experienc=
e
      • 
Malisa (from jabber): there is a 6tsich simulator available on the bitbucke=
t page that is convenient for simulating this sorts of algorithms. please t=
ake a look.
      

    • 
[11.00] (expected: 10.50) Architecture draft-ietf-6tisch-architecture-11 (P=
ascal) [10min]

        

      • 
considerationa about "tracks". Also provided in Detnet draft. A 6=
TiSCH is not just a serial sequence of cells along a path.
Can include replication/elimination.
      • 
published draft at BIER to describe how this path replication (using Arc ro=
uting) works.

      • 
Tests have been performed to combine BierTE mechanism with tracks. 
A bitmap tells the path to take.
      • 
The bitmap indicate the paths that failed or not, enabeling an OAM mechanis=
m and a control loop
      • 
Kerry Lynn: how does this compare to FEC? Pascal: we are mostly aiming at p=
rotecting against node failure; TSCH is pretty good at reducing link failur=
e probability.
      • 
Pascal: take advantage of inherent broadcasting of radio to do "bi-cas=
ting", by having two receivers and one transmitter per cell.
This increases reliability.
      • 
Also expose node multiple parents to RPL root (in non-storing mode), shows =
the full structure.
Root can find shorter pathes. Effectively reduces latency=
.
      • 
Recap: track=
s are much more than sequence of cell.
      • 
Tengfei: we are conducting large-scale experiments of 6P SF0 on the IoT-lab=
, with 100-nodes runnign openWSN. will contribute results to the group veri=
fying the current of 6p and SF0 work.
      • 
Malisa: working on 6TiSCH simulator, on BitBucket. Will contribute the resu=
lts to the group.
Explore the code and contribute. 
        • <=
li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;mso-list:l0 level2 lfo3">
Pascal: please write that in the mailing list
      

    

    <=
span style=3D"mso-list:Ignore">·       
[11.15] (expected: 11.00) News from IEEE 802=
.15.4 (Pat) [15min]
    

      

        

      • 
15.4q: new low power PHY, has Amplitude Shift Keying. Not=
 backward comptabible.
      • 
15.4t: 2Mbps, backward compatible with current radios.
      • 
next 15.4 revision will integrate 6 amendments and include corrigenda. 
      • 
15.9: Information Elements for Key Management Protocols.
        • 

      

      o  
15.10: layer 2 routing. Meant to support &qu=
ot;large scale" networks (node count in the thousands).
      

      Randy Turner asked what is large scale, Cha=
rlie answered thousand
      

      o  
15.12: upper layer over 15.4. Defines concep=
t of profiles (e.g. for WiSun or Thread).
      

        

          

        • 
Muhammad: 15.6 ? Pat: 15.6 is medical Body Area Network. MAC similar to 15.=
4. But nobody at 15.6 asked 15.12 to consider their techno
          • <=
li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;mso-list:l0 level2 lfo3">
Carsten: Is this all done? Pat: no it's underway right now. We do need help.
        • 
Bob: 15.6 has a limited stack architecture, star topology, very isolated ap=
proach to many things, very closed, trying to put 15.6 in discussion is cha=
llenging at best, talking about 15.7 would be much better.
          • <=
li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;mso-list:l0 level2 lfo3">
Need participation from this group.
        • 
[xx.xx] Detnet backhaul draft-wang-detnet-backhaul-architecture-00 (Lun) [1=
0min]
        • 
skipped for lack of time
        • 
[11.29] (expected: 11.25) Any Other Business (Chairs) [ 5min]
        • 
Samita: please come to 6lo
        • 
[11.30] (expected: 11.30) meeting ends<=
/li>
        

      

       
--_000_1fe7e4dfed5c49e88534a8a555953d43XCHRCD001ciscocom_--