html5-img
1 / 11

ROLL RPL Security IETF 77 status

ROLL RPL Security IETF 77 status. draft-sdt-roll-rpl-security Kris Pister, pister@eecs.berkeley.edu Security Design Team. Status. Drafts: draft-tsao-roll-security-framework-02 draft-sdt-roll-rpl-security-00 draft-struik-roll-rpl-security-design-00 Related:

liana
Download Presentation

ROLL RPL Security IETF 77 status

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ROLL RPL SecurityIETF 77 status draft-sdt-roll-rpl-security Kris Pister, pister@eecs.berkeley.edu Security Design Team IETF 77 – Roll WG – March 2010

  2. Status • Drafts: • draft-tsao-roll-security-framework-02 • draft-sdt-roll-rpl-security-00 • draft-struik-roll-rpl-security-design-00 • Related: • Draft-oflynn-6lowapp-bootstrapping-00 IETF 77 – Roll WG – March 2010

  3. Scope Routing Security Provide mechanisms to protect RPL {DIS, DIO, DAO, “flow label”} from outsider attack Later or out of scope Policy Key distribution Insider attack Relationship to other security (L2, L4, …)

  4. Range of RPL Applications Toys No security ok? Consumer/commercial Perception of risk varies widely Enterprise-critical Appropriate paranoia • Need to satisfy “enterprise-critical” without driving away “consumer/commercial”

  5. “Protect” DIO, DIS, DAO, flow label Packets are not modified during transport Participant IDs are authentic Retransmissions are detected Content optionally encrypted

  6. Mechanisms AES128 CCM* Where to draw the “MUST support” line? 1) no security 2) shared instance-wide key 3) shared pair-wise keys 4) digital signatures

  7. Authentication Proposed 4 levels No authentication Pre-configured, instance-wide join key Pre-configured join key(s) with access control list at LBR Public key certificate

  8. Implementation Still several options for where to put security material DIS, DIO, DAO Sub-option “security-field-present” bit Flow label Hop-by-hop option (hui-6man-rpl-option) TLV or “security present” bit 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (sub-TLVs) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  9. March 22, 2010 Example Packet format (1) RPL Control Message Security bit indicates whether packet is secured, and auxiliary security header is present. Slide 9

  10. March 22, 2010 Example packet format (2) • Auxiliary Security Header (cont’d) • - Only present if security field set • Security control field: indication as to which security services enabled • Granularity: specific combinations of data confidentiality & data integrity • Counter field: indication of non-repeating value used in crypto construct • Compression option provided (if devices have clock on board and timeliness possible) • Key Identifier field: indication as to which key was used to secure packet • Granularity: peer-to-peer key, group key, network-wide key, {signature key} MIC: message integrity code Slide 10

  11. Summary Can provide simple, standard, lightweight mechanisms to protect routing information Min 2B? per data packet (flow label) Typ 5B? per DIS/DIO/DAO Still lots of detail work to do Open issues Insider attack: LBR consistency checking? Error/alarm messages

More Related