1. Slide #1 ROLL RPL IETF Virtual Interim WG Meeting – June 2010 draft-ietf-roll-rpl-09 RPL Author Team

2. 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

3. 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

4. Recent ML discussions Siblings process –Decision to remove from base specification Slide #4Interim Meeting– Roll WG – June 2010

5. Tickets TicketSummaryTypeOwnerStatusCreated #42adding the SLLA and MTU options in the RPL spec ?defectPascalnew2010-06-01 #45RPL08 - Few questionsdefectPascal, Timnew2010-06-05 #49Few items to add in RPL 09defect Pascal, Tim new2010-06-07 #50Two Clarifications for Rev 09defectTimnew2010-06-09 #11Decision on prefix packing in DAO messagesenhancementJPnew2009-11-02 #22RPL VariablestaskTimnew2009-12-08 #24Discussion P2Ptask Phil => will move to P2P new2010-03-08 #25RPL satisfying the MUST requirementstaskJPnew2010-03-08 #48Manageability section - next updatedefectJPnew2010-06-07 #51 New Appendix A (former Appendix B) can be removed defectTimnew2010-06-12 #30Clearly documenting Multicast mode of operationtask Richard/Jonathan/T im reopened2010-03-29

6. Ticket #42: SLLA and MTU SLLA option –Decision to not add now MTU option –Tentative Decision not to add now –Still being discussed… Slide #6Interim Meeting– Roll WG – June 2010

7. 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 #7Interim Meeting– Roll WG – June 2010

8. 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 #8Interim Meeting– Roll WG – June 2010

9. 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 #9Interim Meeting– Roll WG – June 2010

10. Ticket #25: RPL MUST Requirements Slide #10Interim Meeting– Roll WG – June 2010 JP providing update Satisfied Partially satisfied Non Satisfied (Partially) non satisfied but consensus Differed or N/A OriginDescriptionStatus 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. Security B 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

11. Ticket #48: Update Manageability Section Problem: Update manageability section Ticket owner: JP Slide #11Interim Meeting– Roll WG – June 2010

12. 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 #12Interim Meeting– Roll WG – June 2010

13. More discussion … Slide #13Interim Meeting– Roll WG – June 2010

14. 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 #14Interim Meeting– Roll WG – June 2010 Radia’s lollipop 255 64 128 0 127

15. 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 #15Interim Meeting– Roll WG – June 2010 Radia’s lollipop A B B A 255 128

16. 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 #16Interim Meeting– Roll WG – June 2010 Radia’s lollipop A B’ B A 255 64 128 0 127

17. 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 #17Interim Meeting– Roll WG – June 2010 255 0 127 Radia’s lollipop 128 A B B’ 64

18. 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 #18Interim Meeting– Roll WG – June 2010 255 0 127 Radia’s lollipop 128 A B B’ 64

19. 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 #19Interim Meeting– Roll WG – June 2010

20. 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-02http://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 #20Interim Meeting– Roll WG – June 2010

21. 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 #21Interim Meeting– Roll WG – June 2010

22. Security DT Update Slide #22Interim Meeting– Roll WG – June 2010

23. June 16, 2010 René Struik Slide 23 Overview RoLL Security René Struik E-mail: rstruik.ext@gmail.com

24. June 16, 2010 René Struik Slide 24 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’).

25. 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.

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

27. 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).

28. May 25, 2010 René Struik 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: 2 22 seconds  48.5 days Counter lifetime supported: 2 34 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

29. 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).