Slide #1

ROLL RPL

IETF Virtual Interim WG Meeting – June 2010

draft-ietf-roll-rpl-09

RPL Author Team

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

TicketsTicket 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 Pascal, Tim

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/Tim

reopened 2010-03-29

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: JPSlide #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

Slide #10 Interim Meeting– Roll WG – June 2010

• JP providing update  Satisfied  Partially satisfied  Non Satisfied  (Partially) non satisfied but consensus  Differed or N/A

Origin Description Status

Features

B The routing protocol MUST take into account device characteristics such as power budget  B 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 The routing protocol MUST provide routes between arbitrary hosts within the appropriate administrative domain  B 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 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.  H The routing protocol MUST converge within 0.5 second if no nodes have moved.  H 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 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.  H The routing protocol MUST support 250 devices in the network.  

SecurityB Authentication policy and updates MUST be routable over-the-air.  

B These requirements mean that at least one LLN routing protocol solution specification MUST include support for authentication.  B 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 The HC-LLN MUST be able to authenticate a new node prior to allowing it to participate in the routing decision process.  H 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 It MUST be possible to fully commission network devices without requiring any additional commissioning device (e.g., laptop)  B 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  

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 – used for reboot– starts anywhere

• Lollipop Circular part – Normal operation– Wraps from 127 to 0

• Out of sync defined as– apart by more than 2^N, – N in 4..6

Slide #14 Interim Meeting– Roll WG – June 2010

Radia’s lollipop

255

64

128

0 127

Sequence Counter (cont)

• A >127, B > 127• Expect a single reboot• Simple arithmetics• A > B

A is more recent

• B > A B is more recent

• A = B same age

Slide #15 Interim Meeting– Roll WG – June 2010

Radia’s lollipop

A

BB

A

255

128

Sequence Counter (cont)

• A > 127, B < 128

• B – A <= 2 ^N In sync B is post reboot B is most recent

• B’ – A > 2 ^N Out of sync B’ is pre reboot A is most recent

Slide #16 Interim Meeting– Roll WG – June 2010

Radia’s lollipop

A

B’

B

A

255

64

128

0 127

Sequence Counter (cont)

• A < 128 , B < 128• A == B

In sync Same age

• B – A <= 2 ^N In sync B is most recent

• A – B <= 2 ^N In sync A is most recent

• Else Out of sync

Slide #17 Interim Meeting– Roll WG – June 2010

255

0 127

Radia’s lollipop

128

A

B

B’

64

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

Slide #18 Interim Meeting– Roll WG – June 2010

255

0 127

Radia’s lollipop

128

A

B

B’

64

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 ThubertSlide #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

June 16, 2010 René StruikSlide 23

Overview RoLL Security

• René Struik • E-mail: rstruik.ext@gmail.com

June 16, 2010

René Struik

Slide 24

Basic Security Services

Data confidentialityAssurance that transmitted information is only disclosed to parties for which it is intended.Data authenticityAssurance of the source of transmitted information (and, hereby, that information was not modified in transit).Replay protectionCapability 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

René Struik

Slide 25

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

René Struik

Slide 26

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 designUnified 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 and ease-of-use and ease-of-deployment (even if realization is outside scope)

June 16, 2010

René Struik

Slide 27

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 that do not have keying material yet (e.g., during initial membership phase)

.

May 25, 2010

René Struik

Slide 28

Slide 28

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)

Note: Implementation can be securely reused across different layers of the stack

(thus, allowing sharing of keying material, status info on per-device level)

Details of Packet Protection

June 16, 2010

René Struik

Slide 29

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)

.