12 19 2014 Webex IPv 6 over the TSCH mode

12/19/2014 Webex IPv 6 over the TSCH mode of IEEE 802. 15. 4 e Chairs: Pascal Thubert Thomas Watteyne Etherpad for minutes: http: //etherpad. tools. ietf. org: 9000/p/6 tisch

Note Well This summary is only meant to point you in the right direction, and doesn't have all the nuances. The IETF's IPR Policy is set forth in BCP 79; please read it carefully. The brief summary: • By participating with the IETF, you agree to follow IETF processes. • If you are aware that a contribution of yours (something you write, say, or discuss in any IETF context) is covered by patents or patent applications, you need to disclose that fact. • You understand that meetings might be recorded, broadcast, and publicly archived. For further information, talk to a chair, ask an Area Director, or review the following: • BCP 9 (on the Internet Standards Process) • BCP 25 (on the Working Group processes) • BCP 78 (on the IETF Trust) • BCP 79 (on Intellectual Property Rights in the IETF) 2

Reminder: Minutes are taken * This meeting is recorded ** Presence is logged *** * Scribe; please contribute online to the minutes at http: //etherpad. tools. ietf. org: 9000/p/6 tisch? use. Monospace. Font=true ** Recordings and Minutes are public and may be subject to discovery in the event of litigation. *** From the Webex login 3

Agenda • Administrivia [2 min] – Approval agenda – Approval minutes last call • status draft-ietf-6 tisch-tsch [5 min] • last call draft-ietf-6 tisch-minimal [5 min] • last call draft-ietf-6 tisch-coap [5 min] • preparation for draft-ietf-6 tisch-terminology last call [10 min] • preparation for draft-ietf-6 tisch-architecture last call [10 min] • open mike rechartering [10 min] • • summary of security discussions AOB [10 min] [3 min] 4

Administrivia

Admin is trivia • Approval Agenda • Approval minutes last call 6

status draft-ietf-6 tisch-tsch Thomas Watteyne Maria Rita Palattella Alfredo Grieco

Status Last call on 28 November http: //www. ietf. org/mail-archive/web/6 tisch/current/msg 02759. html Discussed during 5 December call 3 open items: http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/33 http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/24 http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/34 draft-ietf-6 tisch-tsch-04 published 19 December

clarify use of join priority http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/24 Nodes already part of the network can periodically send Enhanced Beacon (EB) frames to announce the presence of the network. These contain information about the size of the timeslot used in the network, the current ASN, information about the slotframes and timeslots the beaconing node is listening on, and a 1 byte join priority. The join priority field gives information to make a better decision of which node to join. Even if a node is configured to send all EB frames on the same channel offset, because of the channel hopping nature of TSCH described in Appendix A. 7, this channel offset translates into a different frequency at different slotframe cycles. As a result, EB frames are sent on all frequencies.

cleaner text for Multi-Hop Topology issue 33 • OLD • Define a mechanism to gather topological information, which it can then feed to RPL. • NEW • Define a mechanism to gather topological information, node and link state, which it can then feed to RPL.

clarify meaning of "these" issue 34 • OLD • A TSCH schedule looks like a matrix of width "slotframe size", S, and of height "number of frequencies", n. Freq. For a scheduling algorithm, these can be considered atomic "units" to schedule. In particular, because of the channel hopping nature of TSCH, the scheduling algorithm should not worry about the actual frequency communication happens on, since it changes at each slotframe iteration. • NEW • A TSCH schedule looks like a matrix of width "slotframe size", S, and of height "number of frequencies", n. Freq. For a scheduling algorithm, cells can be considered atomic "units" to schedule. In particular, because of the channel hopping nature of TSCH, the scheduling algorithm should not worry about the actual frequency communication happens on, since it changes at each slotframe iteration.

Misc. changes • OLD • Special thanks to Jonathan Simon for his review and valuable comments. Thanks to the Io. T 6 European Project (STREP) of the 7 th Framework Program (Grant 288445). • NEW • Special thanks to Jonathan Simon for his review and valuable comments. Thanks to Guillaume Gaillard and Dominique Barthel for their in-depth review. Thanks to the Io. T 6 European Project (STREP) of the 7 th Framework Program (Grant 288445). • OLD • 30695 Huntwood Avenue • Hayward, CA 94544 • NEW • 32990 Alvarado-Niles Road, Suite 910 • Union City, CA 94587

last call draft-ietf-6 tischminimal

LC completed • Comments on impact of join discussion by Kris • (Pascal Answered) Minimal starts after key is obtained • Maybe a need to be more open to the way the key and schedule are obtained (if a result of a join process) • Comments on Time Sync by Kris • Solved on bitbucket • Open issue on NHC reference • What of we do not reference anything • Else what should default be • Status on appeal to ADs • See Brian’s answer next slide

Talk with Brian Haberman > All in all, if you agree, we can progress the draft in IESG review leaving that particular reference open to be changed till later in the process? Why would you expect that to be acceptable? If a piece of the spec is needed for interoperability, it needs to be there during the review. Why send it to the IESG if there are still questions on how that piece will be done? If it is left out, how will anyone know if there is consensus on the spec as a whole? It seems to me that: 1. There have been several proposals put forth 2. Issues have been raised on each one So, it seems prudent (to me) to look at each of the alternatives and determine which warts everyone concerned is willing to live with. Running code is a good way to do that. Making that determination needs to be done before the spec is sent to the IESG.

last call draft-ietf-6 tisch-coap

Status draft-ietf-6 tisch-coap-02 published 04 December 2014 To avoid parallel last calls, proposes to do last call beginning of January 2015

preparation for draft-ietf-6 tisch -terminology last call

Status draft-ietf-6 tisch-terminology-02 published 4 July 2014 A number of new definitions emerged from 6 Ti. SCH-security work: Proposed by Michael: http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/32 Modifications suggested by Pascal: http: //www. ietf. org/mailarchive/web/6 tisch/current/msg 02811. html

JCE Michael: the Join Coordination Entity. This acronym is chosen to parallel the PCE. Pascal: the Join Coordination Entity joining node (JN) The newly unboxed constrained node that needs to join a network. join protocol the protocol which secures initial communication between the joining node and the JCE join assistant (JA) A constrained node near the joining node that will act as it's first 6 LR, and will relay traffic to/from the joining node. unique join key a key shared between a newly joining node, and the JCE. This key supports smaller installations for which asymmetric methods are considered too large production network A 802. 15. 4 e network whose encryption/authentication keys are determined by somealgorithm/protocol. There may have network-wide group keys, or per-link keys. production network key A L 2 -key known by all authorized nodes, used for multicast messages per-peer L 2 key a key that results from an exchange (such as MLE) hat creates a pair-wise L 2 key which is known only to the two nodes involved, [I-D. piro-6 tisch-security-issues] calls this a Link. Key?

The following terms are used in this document and come from other documents: Dev. ID [IEEE. 802. 1 AR] defines the secure DEVice IDentifier as a device identifier that is cryptographically bound to the device and is composed of the Secure Device Identifier Secret and the Secure Device Identifier Credential. IDev. ID The Initial secure DEVice IDentifier (IDev. ID) is the Device Identifier which was installed on the device by the manufacturer. LDev. ID A Locally significant secure DEVice IDentifiers (LDev. IDs) is a Secure Device Identifier credential that is unique in the local administrative domain in which the device is used. The LDev. ID is usually a new certificate provisioned by some local means, such as the 6 top mechanism defined in this document. Co. AP The Co. AP protocol, defined in [RFC 7252] is an HTTP-like resource access protocol. Co. AP runs over UDP. DTLS The datagram version of TLS, defined in [RFC 6347], and which can be used to secure Co. AP in the same way that TLS secures HTTP. ARO [RFC 6775] defines a number of new Neighbor Discovery options including the Address Registration Option DAR/DAC [RFC 6775] defines the Duplicate Address Request and Duplicate Address Confirmation options to turn the multicasted Duplicate Address Detection protocol into a client/server process EARO [I-D. thubert-6 lo-rfc 6775 -update-reqs] extends the ARO option to include some additional fields necessary to distinguish duplicate addresses from nodes that have moved networks when there are mulitple LLNs linked over a backbone.

preparation for draft-ietf-6 tisch -architecture last call

Preparing Last call • Missing security text, Last call adjourned • Otherwise ready • Comments?

open mike rechartering

Rechartering • Revise current charter to point on 802. 14. 52015? • When should we recharter? • Potential new items for rechartering • • • Join Process Dynamic scheduling OTF Chunks appropriation Det. Net / Tracks

summary of security discussions

AOB ?

Thank you!