23 January 2015 Webex
IPv6 over the TSCH
mode of IEEE 802.15.4e
Chairs:
Pascal Thubert
Thomas Watteyne
Etherpad for minutes:
http://etherpad.tools.ietf.org:9000/p/6tisch?useMonospaceFont=true
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/6tisch?useMonospaceFont=true
** Recordings and Minutes are public and may be subject to discovery in the
event of litigation.
*** From the Webex login
3
Agenda
•
Administrivia
[2min]
– Approval agenda
– Approval minutes last call
– Updates since last call
•
draft-dujovne-6tisch-on-the-fly-04 [Diego Dujovne]
[20min]
•
draft-piro-6tisch-security-issues [Giuseppe Piro]
[20min]
•
announcement ROLL interim meeting
[5min]
•
AOB
[3min]
4
Administrivia
Admin is trivia
• Approval Agenda
• Approval minutes last call
6
draft-dujovne-6tischon-the-fly-04
missed
Diego Dujovne
On-The-Fly scheduling
Layer-3 mechanism
Dynamically adapt aggregate bandwidth
Between neighbours
Based on application constraints
Distributed
Requires 6top-to-6top negotiation
Allocation Policy
Allocated cells from the Best Effort (ID=00)
track.
OTF manges global bandwidth between
nodes; no track management
Schedule collision is possible: same cell
allocated by different pairs of interfering
nodes
Allocation Policy
Algorithm to decides when to change allocated
BW between neighbours
To satisfy traffic requirements (latency,
throughput…)
We define:
Scheduled cells: Those already on the BE track
Required cells: Number of cells requested from
OTF to 6top
OTF Threshold: Over-provisioning
Allocation Policy
This replaces our former definitions of
Proactive, Reactive or Hybrid.
Required Cells > Scheduled Cells -> Add 1+
cells
(Required Cells >= Scheduled Cells-OTF
Threshold) && (Required Cells <=
Scheduled Cells) -> Do nothing
Required Cells < Scheduled Cells-OTF
Threshold -> Delete 1+ cells
Allocation Policy
This Policy adds hystheresis to the system,
reducing 6top negotiation traffic
Overprovisioning depends on OTF Threshold
Allocation Methods
How OTF and 6top communicate
Soft cell and Bundle allocation methods
Create/Resize bundles according to
requirements
Bundles are internally managed by 6top
A Bundle is created to use the BE track
(ID=00)
Extract statistics from 6top
CellList: Per-cell statistics / Per-bundle statistics
MonitoringStatusList: Per-neighbour / Slotframe stats
(hardcells, softcells, QoS , metrics, overprovision)
NeighborList: per-neighbor stats; connectivity. Used
to reallocate cells on other links depending on
thresholds
QueueList: per-queue stats; traffic load (avg length,
avg. age of packets)
COAP-YANG model
OTF asks to add/remove cells (bandwidth) only
Triggers
OTF algorithms are event-oriented
Reduces power consumption
OTF generates events (allocation requests)
The relationship: BW <- BWA(B,T,S(B,T))
defines the triggering event.
BW: Bandwidth, BWA: Algorithm, T: Track,
B:Bundle, S(B,T): Stats for B on T, M(B,T):
B size on T.
Triggers
Event A: New Bundle
Request 6top for Stats S (B,T)
Calculate BW allocation according to the
Algorithm
Ask 6top to Allocate the BW
Increase the value of M for B on T
Triggers
Event B: Saturated queue (no cell avail.)
Request 6top for Stats S (B,T)
Calculate BW allocation according to the
Algorithm
Ask 6top to increase size of B
If successful, increase the value of M for B on T
Triggers
Event C: Overprovisioned Bundle
Request 6top for Stats S (B,T)
Calculate BW allocation according to the
Algorithm
Ask 6top to decrease size of B to BW
If successful, increase the value of M for B on T
Triggers
Event D: Underprovisioned Bundle
Request 6top for Stats S (B,T)
Calculate BW allocation according to the
Algorithm
Ask 6top to increase size of B to BW
If successful, increase the value of M for B on T
Triggers
Event E: Bundle is deleted. No longer used.
Purge M (B,T)
Bandwidth Estimation
Algorithms
OTF can support different pre-stored
estimation algorithms
Applied to links between the nodes and its
neighbors.
Algorithms are numbered 0-255, 0 is
reserved to the default algorithm
Algorithm selection is done by GET/SET
commands.
Default algorithm
1- Collect BW requests from child nodes
2- Collect self BW requirement
3- Collect outgoing BW
4- if outgoing<incoming+self, ADD
softcells/bundles to satisfy requirements
5- if putgoing>incoming+self, DELETE
unused softcells
6 Go back to 1.
External CoAP/YANG interface
To select algorithm and provide parameters
'6t/e/otf/alg' for SET and GET
'/6t/e/otf/alg/par' for Parameters
draft-piro-6tisch-securityissues
G. Piro, G. Boggia, L. A. Grieco
23 Jan. 2015
General details
● title: Layer-2 security aspects for the IEEE
802.15.4e MAC
● focus: MAC layer security
o IEEE 802.15.4(e) overview
o definition of keys
o security configurations
o key management
● current version: 03 (submitted on Dec.
2014)
o http://www.ietf.org/id/draft-piro-6tischsecurity-issues-03.txt
25
L2 keys (1/2)
● master l2 key: initial secret shared among all the
motes and configured by the manufacturer or by the
network administrator before the network
deployment
● production network key: secret shared by all the
authorized nodes and obtained during the join
procedure
● per-peer L2 key: negotiated only between a couple
of nodes through a KMP strategy
26
L2 keys (2/2)
● master L2 key protects enhanced beacon
messages and data frames carrying messages
exchanged during the join procedure
● production network key protects broadcast
messages and MAC frames exchanged during the
KMP
● per-peer L2 key protects messages exchanged
between two nodes at the MAC layer
27
Security configurations
● Fully Secured network: all the devices forming the
network are configured to fully support security services
and they have already obtained (or negotiated) all the
keys
● Unsecured network: security services are not
supported
● Partial Secured network: only the integrity of message
is supported
● Hybrid Secured network: a network falls in this
configuration when there still are a group of devices that
have not yet
authenticated by the network (because
they have not yet correctly completed the join
28
Establishing L2 security links
29
Bootstrap of the coordinator
30
Bootstrap of the remote node
31
Join phase
● This aspect is investigated in both [I-D.draft-richardson6tisch-security-architecture] and [I-D.draft-struik-6tischsecurity-architecture-elements]
● It is out of scope of this Internet Draft
● At the end of the join procedure, the "joining node"
obtains the "production network key" and updates
security MAC attributes as described for the "master L2
key"
32
Key Negotiation Phase
● Used to negotiate the per-peer L2 key
● Messages are exchanged through new Information
Elements
o Crypto Information Element
o Authentication Information Element
● It is composed by 6 steps
● At the end, nodes has negotiated a link keys from which
extracting per-peer L2 keys
33
Key Negotiation Phase - KMP
1. A sends to B: Cert_A and Rand_A
2. B sends to A: Cert_B and Rand_B
3. A and node B computes the PreLinkKey, P_k, by using the
ECDH algorithm
4. A sends to B the authentication parameter as for the Station-ToStation protocol:
i. AuthField_A = E(P_k, sign)
ii. sign = S(PVK_A, H_128 {P_k || RAND_B || RAND_A})
5. B sends to A the authentication parameter as for the Station-ToStation protocol:
i. AuthField_B = E(P_k, sign)
ii. sign = S(PVK_B, H_128 {P_k || RAND_A || RAND_B})
6. nodes A and B verifies the authenticity of received AuthField
parameters (according to the Station-To-Station protocol) and
computes the "per-peer L2 key"
i. L_k = H_128 (i | PAN_ID | P_k).
34
ROLL interim meeting
virtual interim meeting for
ROLL: Feb10, 2015, 15:00 UTC
Goal: conclude on the approach that we decide to follow for the RPI
Participants: WG members: roll, 6lo, 6tisch, ADs
Links:
https://datatracker.ietf.org/secr/proceedings/interim-2015-roll-1/roll/
Items: Approach to be analyzed (TBD)
1- flow-label approach: TBD the advantages/disvadvantages
2- NHC approach: TBD the advantages/disvadvantages
3- Dispatch approach: TBD the advantages/disvadvantages
4- Consensus time: TBD....
5- Next steps....
36
virtual interim meeting for
ROLL: 2015-02-10, 15:00 UTC
The goal of this interim meeting is to do a deep technical dive
into the different ways of optimizing the byte/power cost of
the RFC6553 (RPI) and RFC6554 (RH3) options.
This could involve compression or recoding, or???
We invite submissions on this. Please post your -00 draft by
January 23 if possible, or point us at your other drafts.
We will use JITSI for audio, video and slides, with the following
URL:
https://jitsi.tools.ietf.org/Roll20150210VirtualInterim
37
AOB ?
Thank you!