Transcript 6TiSCH

IETF92 - Dallas
Chairs:
Pascal Thubert
Thomas Watteyne
Mailing list:
[email protected]
Jabber:
[email protected]
Etherpad for minutes:
http://etherpad.tools.ietf.org:9000/p/notes-ietf-92-6tisch
IPv6 over the TSCH
mode of IEEE 802.15.4e
6TiSCH@IETF92
1
Note Well
Any submission to the IETF intended by the Contributor for publication as all or part of an IETF InternetDraft or RFC and any statement made within the context of an IETF activity is considered an "IETF
Contribution". Such statements include oral statements in IETF sessions, as well as written and
electronic communications made at any time or place, which are addressed to:
–
–
–
–
–
–
–
The IETF plenary session
The IESG, or any member thereof on behalf of the IESG
Any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list
functioning under IETF auspices
Any IETF working group or portion thereof
Any Birds of a Feather (BOF) session
The IAB or any member thereof on behalf of the IAB
The RFC Editor or the Internet-Drafts function
All IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879).
Statements made outside of an IETF session, mailing list or other function, that are clearly not intended
to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice.
Please consult RFC 5378 and RFC 3979 for details.
A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best
Current Practices RFCs and IESG Statements.
A participant in any IETF activity acknowledges that written, audio and video records of meetings may
be made and may be available to the public.
6TiSCH@IETF92
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/notes-ietf-91-6tisch
** Recordings and Minutes are public and may be subject to discovery in the
event of litigation.
*** Please make sure you sign the blue sheets
6TiSCH@IETF92
3
Administrivia
• Blue Sheets
• Scribes
• Jabber
6TiSCH@IETF92
4
Objectives
• Monday (1520-1650 CDT, Continental)
– DetNet
– Security
• Thursday (0900-1130 CDT, Continental)
– WG drafts, including in last call
– Plugtest
– Distributed scheduling
– Rechartering discussion
6TiSCH@IETF92
5
Agenda
Intro and Status
[2min] (Chairs)
Note-Well, Blue Sheets, Scribes, Agenda Bashing
DetNet
*
*
*
*
*
<draft-finn-detnet-architecture-00>
<draft-gunther-detnet-proaudio-req-00>
<draft-wetterwald-detnet-utilities-reqs-01>
Deterministic 6TiSCH: PCE, CCAMP and TEAS
<draft-wang-6tisch-track-use-cases-00>
[20min]
[10min]
[10min]
[40min]
[10min]
(Norm Finn)
(Jouni Korhonen)
(Patrick Wetterwald)
(Pascal Thubert)
(Chonggang Wang)
Security
[30min]
* DT status and design goals
(Michael Richardson)
* <draft-struik-6tisch-security-considerations-01>
(Rene Struik)
Wrap up for rechartering
6TiSCH@IETF92
[8min] (Chairs)
6
(6TiSCH)
Applying PCE
Deterministic
6TiSCH:
to
PCE, CCAMP and
(IPv6-based)
TEAS
Deterministic Networks
(in IoT)
Pascal
Thubert
Cisco
Systems
March 23rd, 2015
7
New level of (Deterministic?) guarantees
–
–
–
–
A differentiator for high-end forwarding engines
Sharing physical resources with classical networking
For traffic known a priori (control loops…)
Time Synchronization and global Schedule
6TiSCH@IETF92
End-to-End latency enforced by timed pause at station
Periodic trains along a same path and same schedule
Collision avoidance on the rails guaranteed by
schedule
6TiSCH@IETF92
9
A bus every T. minutes, Stop A to Stop B in X. minutes
Worst end-to-end delivery time < (T + X)
Every packet in an Airbus 380 takes a bus across the
fabric
6TiSCH@IETF92
10
Two classes of bleeding-edge customers, Industrial and Audio/Video.
Both have moved into the digital world, and some are using packets, but now
they all realize they must move to Ethernet, and most will move to the Internet
Protocols.
1.Industrial: process control, machine control, and vehicles.
–
–
–
–
On LLNs, this is a Wireless HART, ISA100.11a, WIA-PA/FA, … and 6TiSCH
On Ethernet, this is IEEE 802.1 Time-Sensitive Networking (TSN)
Data rate per stream very low, but can be large numbers of streams.
Latency critical to meeting control loop frequency requirements.
2.Audio/video: streams in live production studios.
–
–
–
At Layer 2, this is IEEE 802.1 Audio Video Bridging (AVB).
Not so many flows, but one flow is 3 Gb/s now, 12 Gb/s tomorrow.
Latency and jitter are important, as buffers are scarce at these speeds.
3.Vehicule, SmartGrid: streams in live production studios
6TiSCH@IETF92
Norm Finn
11
It’s not about
– Classical Layers
– Standard bodies
– QoS and stat mux
It’s all about
–Real boxes and links
–Real buffers and
queues
–Real packets
–Real Time
6TiSCH@IETF92
12
• Single nailed-up path
Per-Flow
State
Flow
ID
NIC
Receiver
(Listener)
6TiSCH@IETF92
NIC
Sender
(Talker)
13
Replication & Elimination of individual
packets
Per-Flow
State
Flow
ID
NIC
Receiver
(Listener)
6TiSCH@IETF92
NIC
Sender
(Talker)
14
Service (northbound)
interface
Topology,
resources
Controller
Control (southbound)
interface
NIC
Receiver
(Listener)
6TiSCH@IETF92
NIC
Sender
(Talker)
15
User/app/
service
User/app/
service
?
Service (northbound)
interface
TSpec
Controller
Control (southbound)
interface
Reservation
request
Per-Flow
State
Flow
ID
NIC
Receiver
(Listener)
6TiSCH@IETF92
NIC
Sender
(Talker)
16
User/app/
service
User/app/
service
?
Service (northbound)
interface
TSpec
Controller
?
Control (southbound)
interface
?
Per-Flow
State
Flow
ID
NIC
Receiver
(Listener)
UNI
6TiSCH@IETF92interface
NIC
UNI
interface
Sender
(Talker)
17
Service (northbound)
interface
Command and
Configuration
(CLI-type
operation)
Push
update
Control (southbound)
6TiSCH@IETF92
interface
Track
Computation
And
Maintenance
(PCE)
Controller
Measurement
and
Fault
Management
(ops
management)
Trigger
recompute
• Time synchronization for network nodes and hosts to order
of (10s of) µs.
• Software for resource reservation for critical data streams
(buffers and schedulers in network nodes and bandwidth on
links), via configuration, management, and/or protocol action.
PCE/CCAMP/TEAS connections.
• Ensure extraordinarily low packet loss ratios, order of 10–5
or better, and a guaranteed end-to-end latency for a
reserved flow along track.
• Convergence of critical data streams and other QoS
features, including best-effort RPL, on a single scheduled
network, even when critical data streams are 75% of the
bandwidth.
6TiSCH@IETF92
Norm Finn
19
Use Cases and Requirements
for Using Track in 6TiSCH
Networks
Zhuo Chen, Chonggang Wang
6TiSCH@IETF92
20
Status
• Status:
– Latest version -00 published on 03.06.15
available at: http://tools.ietf.org/html/draft-wang-6tisch-track-usecases-00
6TiSCH@IETF92
draft-short-name
21
Use Case – Industrial Networks
• Industry Process Control and Automation Applications
• Industrial Monitoring Applications
6TiSCH@IETF92
22
Handling Tracks in 6TiSCH
Networks
• Benefits for Using Track
– Less process delay and overhead than layer3 forwarding
– Guaranteed delay, jitter, and throughput
– Enable sleeping node and save energy
– Better reliability
• Track Reservation
– Remote track reservation
– Hop-by-hop track reservation
6TiSCH@IETF92
23
Requirements for Track
Reservation
• Centralized Track Reservation
– Need a protocol for LLN devices to report their
topology and TSCH schedule information to the
central controller.
– Need a lightweight protocol for the central controller
to configure hard cells of LLN Devices.
• Distributed Track Reservation
– Need a fast reaction protocol to reserve a Track.
– Need a protocol which can quickly detect a Track
reservation failure.
– Need an efficient negotiation protocol between LLN
Devices multi-hop away from each other.
6TiSCH@IETF92
24
Next Step
• TBD
6TiSCH@IETF92
25
Security DT status
6TiSCH@IETF92
26
6TiSCH Security
Considerations
(draft-struik-6tisch-security-architectural-considerations-01)
Subir Das
Yoshihiro Ohba
René Struik
6TiSCH@IETF92
27
• Status:
Status
– Latest version -01 published January 9, 2015
available at https://datatracker.ietf.org/doc/draft-struik-6tisch-securityconsiderations/
• Intent:
– Work-in-progress document capturing security architectural design
considerations, including the join process; fit with 802.15.4e/TSCH
specification; gap analysis; identification of outstanding issues that
need to be addressed; contributions towards addressing these.
– Current version: frame work, no full specifications (yet)
• Changes since IETF-91:
− Extensive detail on MAC operations, join protocol flows, and rationale
(compared to draft-struik-6tisch-security-architecture-elements-01)
Note: Security not yet part of current 6TiSCH charter
6TiSCH@IETF92
draft-ietf-6tisch-security-architecture-elements-01
28
Device Enrolment Steps
Device authentication. Joining Node A and Join Assistant B
authenticate each other and establish a shared key (so as to ensure
on-going authenticated communications). This may involve server
KDC as third party.
Authorization. Join Assistant B decides on whether/how to authorize
device A (if denied, this may result in loss of bandwidth). Authorization
decision may be delegated to server KDC or other 3rd-party device.
Configuration/Parameterization. Router B distributes configuration
information to Node A, such as  IP address assignment info; 
Bandwidth/usage constraints;  Scheduling info (including on reauthentication policy details). This may originate from other network
devices, for which it acts as proxy.
6TiSCH@IETF92
Networking Joining (1)
Joining node A
Joining
Node
Neighbor B
Server, etc.
typical roles
Join
Assistant
CA
certificate issuance
Authorization
membership test,
fine-grained access control
Routing
IP address assignment,
routing info
Gateway
Backbone, cloud
Bandwidth
TSCH schedule (PCE)
Authentication
Authorization
Configuration
NOTE: in some existing applications, Router B acts as relay
only and third-party provides both authentication and authorization.
6TiSCH@IETF92
Desired Properties
Security:
 Authenticated key agreement (incl. PFS)
 Mitigation DoS attacks (both re computation, communication)
 End-to-end security (joining node vs. server (PCE, JCE, etc.))
Privacy:
 Hiding of device identity joining node (against passive observers)
Communication:
 Minimization of non-local flows*
Computation:
 Shift from constrained node to less constrained node
General:
 “Separation of concerns”
 Minimization of dependencies
 Flexibility re deployment models
6TiSCH@IETF92
Network Joining (2)
Joining node A
Joining
Node
Neighbor B
Server, etc.
typical roles
Join
Assistant
CA
certificate issuance
Authorization
membership test,
fine-grained access control
Routing
IP address assignment,
routing info
Gateway
Backbone, cloud
Bandwidth
TSCH schedule (PCE)
beacon
key establishment
key establishment
authentication
configuration data, authentication
NOTE: Router B may transfer configuration data to Node A as part
of its authentication to Node A.
6TiSCH@IETF92
Network Joining (3)
Joining node A
Joining
Node
Neighbor B
Server, etc.
typical roles
Join
Assistant
CA
certificate issuance
Authorization
membership test,
fine-grained access control
Routing
IP address assignment,
routing info
Gateway
Backbone, cloud
Bandwidth
TSCH schedule (PCE)
beacon
caching
NOTE: Optimized flows, based on caching of server-side information
on Router B (this would benefit from secure multicast…)
6TiSCH@IETF92
Realized Properties w/ Current Draft
Security:
 Authenticated key agreement (incl. PFS)
 Mitigation DoS attacks (both re
computation, communication)
 End-to-end security (joining node vs.
server (PCE, JCE, etc.))
Privacy:
 Hiding of device identity joining node
Communication:
 Minimization of non-local flows*
Computation:
 Shift from constrained node to less
constrained node
General:
 “Separation of concerns”
 Minimization of dependencies
6TiSCH@IETF92
Security and 802.15.4e aspects:
 No need to trust ASN in beacon for
security
Security vs. status information:
 Prioritization of DoS attack prevention
Separation of concerns:
 802.15.4e: no need for other beacon
 Routing: no need for “tweaks” (e.g.,
joining node can use link local address)
 Extensibility: fits with semi-automatic
network management concepts and
provisioning/configuration concepts
Protocol easy to analyze by security and
crypto community (no “short cuts”)
Network Joining (4)
The “big picture”...
Joining node
Neighbor node
Server, etc.
6TiSCH@IETF92
Current Draft …
• Current draft includes
– Extensive detail on behavior MAC (802.15.4e/TSCH)
– Extensive detail on join protocol
• Protocol flows
• Design considerations
• Security assumptions and threat model:
− Security-first approach, tailored towards 6TiSCH-typical constraints
(e.g., minimization protocol flows)
− Initial set-up description, assuming public-key -based crypto
NOTE: Model also fits PSK-approach
• Routing model:
− Communication path between Join Assistant and “server”
No need to be secured (simply “should be there”)
6TiSCH@IETF92
36
... and Next Draft
• Next draft:
– Include description when current initial set-up requirements not met
• This includes out-of-sync behavior (no cert, etc.)
• This includes non-public-key based approach (“PSK”)
• Join Protocol:
– Add details (formats, byte count, etc.)
• Security assumptions and threat model:
− TO-DO: Study impact “relaxing” security conditions
− TO-DO: Include description of non-public-key based approach
− TO-DO: Add more details on initial keying and (deployment lifecycle)
− TO-DO: Add text on privacy considerations
− TO-DO: Add material on impact key compromise, etc.
• Routing model:
− TO-DO: Add IPv6-addressing-related detail
37
6TiSCH@IETF92
− TO-DO: Add more details on network discovery, etc.
Final Note
Plethora of drafts circulating in various IETF groups can be unified, as
extension of current join protocol model:
− 6TiSCH, 6lo, Anima, etc.
Flexible use cases can be supported, including:
− Random provisioning order
− Sequential provisioning order
Most differences can be captured with security policy “profile”
6TiSCH@IETF92
38
Network Joining (4a)
The “big picture”... But now with multiple servers
Joining node
Neighbor node
Server, etc.
This facilitates distributed/decentralized schemes
6TiSCH@IETF92
Network Joining (4b)
The “big picture”... But now with sprinkled-in
initial provisioning nodes (aka “throw-away nodes)
Joining node
Neighbor node
Server, etc.
This facilitates “random” provisioning order use cases
6TiSCH@IETF92
Sprinkled-in Router
Wrap Up session 1
6TiSCH@IETF92
41
Wrap-up for Rechartering
• DetNet
– Mature requirements
– Elaborate architecture
– Continue incubation or spinoff?
• Security
– Mature join model – Charter the work?
– Should we document PSK? In what form?
– Relation with other IoT security work
6TiSCH@IETF92
42
Any Other Business?
6TiSCH@IETF92
43
Thank you!
6TiSCH@IETF92
44