Download RPL (pronounced ripple) Routing Protocol for Low Power and Lossy

ROLL RPL
IETF Virtual Interim WG Meeting
– June 2010
draft-ietf-roll-rpl-09
RPL Author Team
Slide #1
RPL Status
• New version draft-ietf-roll-rpl-09
• Major additions
– Security
– Manageability
• Also:
– Source Route path failure
– Decouple metrics / constraints from OF
– 6MAN drafts (RH4, RRH and RPL header) – see next
slide
– Sequence number handling (bootstrap, to be refined)
=> specific slides
Slide #2
6man Companion Drafts
• draft-hui-6man-rpl-option
– RPLInstanceID and Loop detection
• draft-hui-6man-rpl-routing-header
– Source routing
– Simple but effective compression of common prefix
– Fixes security concerns that caused deprecation of RH0
• Above used only within a RPL domain
– Insert/remove when crossing RPL domain boundary
• IP-in-IP tunneling when inserting headers
– Ensures original datagram is delivered unmodified
– ICMP errors sent to source of extension header
– Increase MTU to 1280 + outer IP header to avoid IP-layer frag
Recent ML discussions
• Siblings process
– Decision to remove from base specification
Slide #4
Interim Meeting– Roll WG – June 2010
Tickets
Ticket
Summary
Type
Owner
Status
Created
#42
adding the SLLA and MTU options in the RPL spec ?
defect
Pascal
new
2010-06-01
#45
RPL08 - Few questions
defect
Pascal, Tim
new
2010-06-05
#49
Few items to add in RPL 09
defect
new
2010-06-07
#50
Two Clarifications for Rev 09
defect
Tim
new
2010-06-09
#11
Decision on prefix packing in DAO messages
enhancement
JP
new
2009-11-02
#22
RPL Variables
task
Tim
new
2009-12-08
#24
Discussion P2P
task
Phil => will move to
P2P
new
2010-03-08
#25
RPL satisfying the MUST requirements
task
JP
new
2010-03-08
#48
Manageability section - next update
defect
JP
new
2010-06-07
#51
New Appendix A (former Appendix B) can be
removed
defect
Tim
new
2010-06-12
#30
Clearly documenting Multicast mode of operation
task
Richard/Jonathan/T
im
reopened
2010-03-29
Pascal, Tim
Ticket #42: SLLA and MTU
•
SLLA option
– Decision to not add now
• MTU option
– Tentative Decision not to add now
– Still being discussed…
Slide #6
Interim Meeting– Roll WG – June 2010
Ticket #45: Mads’ questions
• Problem: Various inconsistencies
•.Question: Mostly fixed by now, still questions on
using Target option in DIO and DIS.
• Proposed approach:
– Adapt to P2P just published
– Consistent text on target option in DIS DIO
• Ticket owners: Pascal / Tim
Slide #7
Interim Meeting– Roll WG – June 2010
Ticket #11: Packing
• Problem: DAO used to be very inefficient
•.Question: How to save control bytes in DAO?
• Proposed approach:
– Already better with the target/transit options
– Source route also improved with the per hop advert.
• Ticket owner: JP
Slide #8
Interim Meeting– Roll WG – June 2010
Ticket #24: P2P
• Problem: P2P could be more efficient
•.Question: quick setup and repair for P2P
• Proposed approach:
– separate spec
– retrofit stuff in main spec
– create 6MAN docs for LSRR
• Ticket owner: Phil => will be moved
Slide #9
Interim Meeting– Roll WG – June 2010
Ticket #25: RPL MUST
Requirements
• JP providing update
Satisfied
Partially satisfied
Non Satisfied
(Partially) non satisfied but consensus
Differed or N/A
Origin
Description
Features
B
B
The routing protocol MUST take into account device characteristics such as power budget
Sleeping devices MUST be able to receive inbound data
B
Messages sent to battery powered nodes MUST be buffered and retried by the last hop router for a period of at least 20 seconds when the destination node is currently in its sleep cycle
B
B
The routing protocol MUST provide routes between arbitrary hosts within the appropriate administrative domain
Routing MUST support anycast, unicast, and multicast.
B
The routing protocol MUST support a metric of route quality and optimize selection according to such metrics within constraints established for links along the routes.
B
Communication routes MUST be adaptive and converge toward optimality of the chosen metric (e.g., signal quality, hop count) in time.
B
The routing protocol MUST gracefully handle routing temporal security updates (e.g., dynamic keys) to sleeping devices on their 'awake cycle to assure that sleeping devices can readily and efficiently access the network
I
The routing protocol MUST be able to compute a set of unidirectional routes with potentially different costs that are composed of one or more non-congruent paths
I
The routing protocol MUST support the ability to recompute paths based on network-layer abstractions of the underlying link attributes/metrics that may change dynamically.
I
The routing protocol MUST be able to compute paths of not-necessarily-equal cost toward a given destination so as to enable load-balancing across a variety of paths
U
The routing protocol MUST be able to accommodate traffic bursts by dynamically computing and selecting multiple paths towards the same destination.
U
Routing protocols activated in urban sensor networks MUST support unicast (traffic is sent to a single field device), multicast (traffic is sent to a set of devices that are subscribed to the same multicast group), and anycast (where multiple field devices are configured to accept traffic sent on a single IP anycast address) transmission schemes
I
The routing protocol MUST support the ability to (re)compute paths based on network-layer abstractions of upper-layer constraints to maintain the level of operation within required parameters.
I
The routing protocol MUST be able to compute paths of not-necessarily-equal cost toward a given destination so as to enable load-balancing across a variety of paths.
Constrained Based Routing
B
The routing protocol MUST be able to provide routes with different characteristics, also referred to as "QoS" routing
B
The routing protocol MUST take into account node properties such as 'Low-powered node' which produce efficient low latency routes that minimize radio 'on' time for these devices.
I
The routing algorithm MUST support node-constrained routing (e.g., taking into account the existing energy state as a node constraint). Node constraints include power and memory, as well as constraints placed on the device by the user, such as battery life.
U
To this end, the routing protocol(s) MUST support parameter-constrained routing, where examples of such parameters (CPU, memory size, battery level, etc.) have been given in the previous paragraph. In other words, the routing protocol MUST be able to advertise node capabilities that will be exclusively used by the routing protocol engine for routing decision.
H
The routing protocol MUST support constraint-based routing taking into account node properties (CPU, memory, level of energy, sleep intervals, safety/convenience of changing battery).
Performances
I
The routing protocol MUST converge after the addition of a new device within several minutes,
I
Any routing algorithm used to determine how to route packets in the network, MUST be capable of routing packets to and from a newly added device within several minutes of its addition, and SHOULD be able to perform this function within tens of seconds.
I
The routing protocol MUST distribute sufficient information about link failures to enable traffic to be routed such that all service requirements (especially latency) continue to be met
I
H
H
Any algorithm that computes routes for packets in the network MUST be able to perform route computations in advance of needing to use the route.
The routing protocol MUST converge within 0.5 second if no nodes have moved.
The routing protocol MUST converge within 4 seconds if nodes have moved.
Scalability
B
The routing protocol MUST be able to support networks with at least 2000 nodes where 1000 nodes would act as routers and the other 1000 nodes would be hosts.
U
The routing protocol(s) MUST be capable of supporting the organization of a large number of sensing nodes into regions containing on the order of 10^2 to 10^4 sensing nodes each.
U
H
The routing protocol(s) MUST be scalable so as to accommodate a very large and increasing number of nodes without deteriorating selected performance parameters below configurable thresholds.
The routing protocol MUST support 250 devices in the network.
Security
B
Authentication policy and updates MUST be routable over-the-air.
B
B
These requirements mean that at least one LLN routing protocol solution specification MUST include support for authentication.
Data encryption of packets MUST be supported by all protocol solution specifications.
B
The routing protocol MUST allow routing a packet encrypted with an application key through forwarding devices without requiring each node in the route to have the application key.
B
The encryption policy MUST support both encryption of the payload only or of the entire packet.
B
Due to the limited resources of an LLN, the security policy defined within the LLN MUST be able to differ from that of the rest of the IP network within the facility yet packets MUST still be able to route to or through the LLN from/to these networks.
I
The routing MUST be configured and managed using secure messages and protocols that prevent outsider attacks and limit insider attacks from field devices installed in insecure locations in the plant.
U
The U-LLN MUST deny any node that has not been authenticated to the U-LLN and authorized to participate to the routing decision process.
U
An attacker SHOULD be prevented from manipulating or disabling the routing function, for example, by compromising routing control messages. To this end, the routing protocol(s) MUST support message integrity.
U
Mechanisms MUST be in place to deny any node that attempts to take malicious advantage of self-configuration and self-organization procedures. Such attacks may attempt, for example, to cause DoS, drain the energy of power-constrained devices, or to hijack the routing mechanism.
U
A node MUST authenticate itself to a trusted node that is already associated with the U-LLN before the former can take part in self-configuration or self-organization.
U
A node that has already authenticated and associated with the U-LLN MUST deny, to the maximum extent possible, the allocation of resources to any unauthenticated peer. The routing protocol(s) MUST deny service to any node that has not clearly established trust with the U-LLN.
U
routing protocol(s) proposed in the context of U-LLNs MUST support authentication and integrity measures and SHOULD support confidentiality (routing security) measures.
I
The routing protocol MUST also support different metric types for each link used to compute the path according to some objective function (e.g., minimize latency) depending on the nature of the traffic.
I
The routing algorithm MUST be able to generate different routes with different characteristics (e.g., optimized according to different costs, etc.).
H
H
The HC-LLN MUST be able to authenticate a new node prior to allowing it to participate in the routing decision process.
The routing protocol MUST support message integrity.
H
Mechanisms MUST be in place to deny any node that attempts to take malicious advantage of self-configuration and self-organization procedures.
H
A node MUST authenticate itself to a trusted node that is already associated with the HC-LLN before the former can take part in self-configuration or self-organization.
H
A node that has already authenticated and associated with the HC-LLN MUST deny, to the maximum extent possible, the allocation of resources to any unauthenticated peer.
H
The routing protocol(s) MUST deny service to any node that has not clearly established trust with the HC-LLN.
H
Routing protocol(s) proposed in the context of HC-LLNs MUST support authentication and integrity measures
Comissioning
B
B
It MUST be possible to fully commission network devices without requiring any additional commissioning device (e.g., laptop)
The routing protocols MUST support hosts and routers that advertise multiple IPv6 addresses.
I
The routing protocol MUST enable the full discovery and setup of the environment (available links, selected peers, reachable network). The protocol MUST enable the distribution of its own configuration to be performed by some external mechanism from a centralized management controller.
I
To this end, the routing protocol(s) MUST provide a set of features including zero-configuration at network ramp-up, (network-internal) self-organization and configuration due to topological changes, and the ability to support (network-external) patches and configuration updates.
H
The routing protocol designed for home automation networks MUST provide a set of features including zero-configuration of the routing protocol for a new node to be added to the network
Slide #10
Interim Meeting– Roll WG – June 2010
Status
Ticket #48: Update
Manageability Section
• Problem: Update manageability section
•Ticket owner: JP
Slide #11
Interim Meeting– Roll WG – June 2010
Ticket #30: multicast
• Problem: Missing mcast in non storing
• Question: How can we do multicast in SR
• Proposed approach:
– propose both many P2P and flooding
– Root decides
– Flood needs pack ID in RPL header
• May not be in scope of main spec (to be
determined)
• Ticket owner: Richard/Jonathan/Tim
Slide #12
Interim Meeting– Roll WG – June 2010
More discussion …
Slide #13
Interim Meeting– Roll WG – June 2010
Sequence Counter
• Lollipop Straight part
64
– used for reboot
– starts anywhere
• Lollipop Circular part
– Normal operation
– Wraps from 127 to 0
0 127
• Out of sync defined as
255
– apart by more than 2^N,
– N in 4..6
128
Radia’s lollipop
Slide #14
Interim Meeting– Roll WG – June 2010
Sequence Counter (cont)
•
•
•
•
A >127, B > 127
Expect a single reboot
Simple arithmetics
A>B
 A is more recent
• B>A
255
 B is more recent
BB
• A=B
 same age
128
A
A
Radia’s lollipop
Slide #15
Interim Meeting– Roll WG – June 2010
Sequence Counter (cont)
• A > 127, B < 128
64
B’
• B – A <= 2 ^N
 In sync
 B is post reboot
 B is most recent
B 0 127
255
A
A
• B’ – A > 2 ^N
 Out of sync
 B’ is pre reboot
 A is most recent
Slide #16
128
Radia’s lollipop
Interim Meeting– Roll WG – June 2010
Sequence Counter (cont)
64
• A < 128 , B < 128
• A == B
A
B
 In sync
 Same age
• B – A <= 2 ^N
B’
 In sync
 B is most recent
0
255
• A – B <= 2 ^N
 In sync
 A is most recent
128
• Else Out of sync
Slide #17
127
Radia’s lollipop
Interim Meeting– Roll WG – June 2010
Sequence Counter (cont)
• How do we cleanup states?
• DAO lifetime can be set to
be smaller than 2^N
increments
• Then need a lifetime for the
version as well
64
A
B
B’
0
255
127
128
Radia’s lollipop
Slide #18
Interim Meeting– Roll WG – June 2010
Target in DIO
• to PULL DAO
• Fast Repair
– Anders’ scenario of button and lamp
– Quick targetted repair if the root has no route
• Call in from outside
– Richard’s scenario of device rarely contacted
• P2P
– On demand DODAG
Slide #19
Interim Meeting– Roll WG – June 2010
Ticket #42: MTU options
• Problem: Inconsistent MTU in a RPL network
 PMTUD causes per destination states
 Need 1280 + tunnel overhead for non storing
 RPL does not depend on RAs so far
More in http://tools.ietf.org/html/draft-van-beijnum-multi-mtu-02
•.Question: Do we disseminate MTU option?
• Proposed approach:
– Add MTU option to DIO (MAY, no need if 1280)
– Do not participate as router on interfaces of less MTU
• Ticket owner: Pascal Thubert
Slide #20
Interim Meeting– Roll WG – June 2010
Scalability
• DAD
– Do we depend on 6LoWPAN ND?
– Can we register to all LBRs?
– Should RPL manage its own DAD?
– See draft-thubert-6lowpan-backbone-router-02
• Router role
– Existing large metering networks elect routers
– Proposal on the table, not resolved so far
Slide #21
Interim Meeting– Roll WG – June 2010
Security DT Update
Slide #22
Interim Meeting– Roll WG – June 2010
Overview RoLL Security
• René Struik
• E-mail: [email protected]
June 16, 2010
Slide 23
René Struik
Basic Security Services
Data confidentiality
Assurance that transmitted information is only disclosed to parties for which it is
intended.
Data authenticity
Assurance of the source of transmitted information (and, hereby, that
information was not modified in transit).
Replay protection
Capability to detect duplicates of transmitted information.
Timeliness (delay protection)
Assurance that transmitted information is received in a timely manner.
Actual security services provided is suitable combination of above services.
– Replay protection is always provided if security is “switched on”;
– Timeliness is provided if devices have clock on board.
Note: Replay protection is provided via use of non-repeating value (‘nonce’).
June 16, 2010
Slide 24
René Struik
Granularity of Security Services
Granularity of security services depends on key type:
– Peer-to-peer key;
– Group key;
– Network-wide key;
– Digital signature key.
Cryptographic protection against outsider devices only and not against potential
malicious devices in key-sharing group.
Granularity of data authenticity via
– public-key techniques: unique originator of transmitted information;
– symmetric-key techniques: entity in key-sharing group.
Signatures useful in group communications (multicast, broadcast) that require
data authentication or if non-repudiation required.
June 16, 2010
Slide 25
René Struik
Deployment Scenarios vs. Security Design
Diverse deployment scenarios
• Home Automation
draft-ietf-roll-home-routing-reqs-11
• Building Automation
draft-ietf-roll-building-routing-reqs-09
• Urban Settings
RFC 5548 - Routing Requirements for Urban Low-Power and
Lossy Networks (May 2009)
• Industrial Control
RFC 5673 - Industrial Routing Requirements (October 2009)
Actual security design
Unified design that fits these diverse deployment scenarios
– concise set of cryptographic and security mechanisms;
– single security policy framework;
– configuration parameters application-dependent.
This allows for mass-scale production, while still allowing for customization (e.g., as to
security services provided, granularity of assurances, used keys, device roles, etc.)
This may require consideration of system perspective, taking into account the entire
system
and device lifecycle andSlide
ease-of-use
and ease-of-deployment (even if realization
June 16, 2010
26
is outside scope)
René Struik
Incoming Security Processing
Security provisions:
– Confidentiality, data authenticity, replay protection, timeliness
– Granularity of protection via key used
Security policy checks:
 Check whether protection applied to incoming packet conforms to what is
expected
.
 Check whether key applied to secure packet conforms to what is expected
 Check timeliness of receipt of incoming packet
Notes:
 Cryptographic processing requires access to logical device identifier
 Replay protection requires maintaining some state for originating device
(nonce)
 Delay protection available for devices that have clock on board
 There is some additional facility to by-pass certain security policy checks for
devices
June 16, 2010
Slide 27
that do not have keying material yet (e.g., during initial membership
Renéphase)
Struik
Details of Packet Protection
PSDU data rate supported: 1 packet per ms (or, more precisely: per 2-10 s).
Determined by granularity of time source used at sender
Maximum time delay supported: 250ms {with 1-byte counters}
Determined by reconstruction of counter from compressed counter at
recipient
Notes: (1) time delay includes clock skew and communication latency
(2) no constraints at all if full 4-byte counters used {crappy clock
possible}
Key lifetime supported: 222 seconds  48.5 days
Counter lifetime supported: 234 seconds  545 years
Note: this assumes 5 ½ -octet counters and time (and granularity 2-10 s)
May 25, 2010
Slide 28
Note: Implementation can
be securely reused across different layers of the
René Struik
Slide 28
stack
Future Work
More details needed in following areas:
 More stringent specification of outgoing/incoming processing;
 Inclusion of more details processing, when signatures are used;
 Impact of counter compression and time-related counters
More consideration of cross-layer topics, including the following:
– Keying material (structure
of keys, including policy fields; key identification);
.
– Security policy parameters and initial keying material (for joining process);
– Key management (including, e.g., correlating key updates and DODAG
iterations);
– I/O parameters (e.g., status parameters, failure notification/recovery)
Note: draft rpl-09 already includes mechanism for synchronizing counter values
(Consistency check mechanism – cf. §5.6 of rpl-09)
June 16, 2010
Slide 29
René Struik