A Security Framework for ROLL

1. A Security Framework for ROLL draft-tsao-roll-security-framework-02.txt T. Tsao R. Alexander M. Dohler V. Daza A. Lozano

2. Overview • Major change to v01 is application of the framework analysis to RPL • A handoff point for the actual RPL security design • This presentation • Starts with the required features from the framework • Concentrates on threat analysis for RPL • Summarizes design guidelines ROLL WG Meeting, 3/22/2010

3. Required Features from the Framework • To ensure message integrity and authenticity • To authenticate and check for liveliness of the principals of a connection • To guard against message replay • Encryption may be desirable • To use mechanism of selectable security strength ROLL WG Meeting, 3/22/2010

4. Threat Analysis for RPL • Application of Security Policy • Attacker Capability • Trust • Attack Surface ROLL WG Meeting, 3/22/2010

5. Application of Security Policy • Security of an LLN device requires consistent application of security policy to all components • Functioning of one part of the device should not conflict with the security operations of another part • Self-forming may cause conflict in security policy settings when security service is shared • For example, IPsec for ICMP Neighbor Discovery may not always be feasible, so the creation of RFC3971 SEND • Consequences • Need to equip RPL with built-in mechanisms to protect itself • Allow a user to switch off RPL security mechanisms when other security services suffice ROLL WG Meeting, 3/22/2010

6. Attacker Capability • LLN applications may be the target, including for exploitation to gain pathway to other assets, of • Neighborhood pranksters who do not usually use sophisticated tools • Crime or terrorist organizations of skilled personnel and advanced equipment • A fixed attacker capability model as design goal is inadequate • Consequence • Use options in security mechanisms to accommodate diversified attacker profiles ROLL WG Meeting, 3/22/2010

7. Trust (1/2) • Insider vs. outsider attack and end-to-end security • Protection against insider attacks likely beyond most LLN devices’ capacity • If only against outsider attacks, may assume a chain of trust and, e.g., be able to rely on link layer security • Consequence • Design for protection against outsider attack as baseline ROLL WG Meeting, 3/22/2010

8. Trust (2/2) • Single ownership LLN device likely • Reasonable to assume secure within a device • Possible to reuse or relegate security services • Identity • Having a shared secret is one of the simpler ways to establish trust • A fix unique identity allows binding of security credentials • Consequences • Protection of security materials and protocol assets becomes system issue • Desirable to have unique LLN device ID ROLL WG Meeting, 3/22/2010

9. Access Methods: Unicast and link-local multicast Access Points: Protocol messages and information on Flow Labels Attack Surface ROLL WG Meeting, 3/22/2010

10. Design Guidelines • To equip RPL with mechanisms to realize the required features • Selectable strengths • Services may be disabled • All protocol messages and information protected with such mechanisms • As a baseline • To address outsider attacks • To assume an instance-wide shared key • At the system level, desirable to have unique device ID ROLL WG Meeting, 3/22/2010