1 / 21

A Security Framework for ROLL

A Security Framework for ROLL. draft-tsao-roll-security-framework-01.txt T. Tsao R. Alexander M. Dohler V. Daza A. Lozano. Overview. Summary of what was in v00 Close look at the changes Case studies Discussion of next steps. What was in v00. A model of routing Security needs

parker
Download Presentation

A Security Framework for ROLL

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. A Security Framework for ROLL draft-tsao-roll-security-framework-01.txt T. Tsao R. Alexander M. Dohler V. Daza A. Lozano

  2. Overview • Summary of what was in v00 • Close look at the changes • Case studies • Discussion of next steps ROLL WG Interim Meeting, 9/30/2009

  3. What was in v00 • A model of routing • Security needs • ROLL issues • Threat, attacks, and counters • ROLL security features ROLL WG Interim Meeting, 9/30/2009

  4. Changes • Editorial changes • Rational and caveat on the inclusion of physical security • Updates of cited I-D numbers • A new subsection on how to adapt to application domain needs • Architecture • Mechanisms and protocol operations ROLL WG Interim Meeting, 9/30/2009

  5. Architecture (1/2) • A flexible architecture that MUST allow security mechanisms to be configurable • Application domain/user decides security strength consistent with the application’s security policy • Could be realized by the protocol itself, lower layers’ services, or a combination • If ROLL affords its own security, it needs to specify, e.g., • ROLL security options (security mechanisms) • A security option field in protocol packet header • How to create security associations ROLL WG Interim Meeting, 9/30/2009

  6. Architecture (2/2) • If ROLL solely relies on lower layer security services • No additional header field to be defined • Just use IPv6’s security services • May be part of an overall design towards a more efficient system better suited for LLN ROLL WG Interim Meeting, 9/30/2009

  7. Mechanisms and Operations (1/2) • Examples of security mechanisms • SHA-2, AES-CBC-MAC, and Digital signature • AES-CCM • Sequence number for anti-replaying • Choice of mechanisms needs also to be defined • How to form auxiliaries, e.g., sequence number, nonce, and initialization vector • How to process data, e.g., key in both prefix and suffix positions to go into MD5 ROLL WG Interim Meeting, 9/30/2009

  8. Mechanisms and Operations (2/2) • Protocol operations may have security consequences • Flooding vs. information aggregation • Hop-by-hop mutating field • Hierarchical routing ROLL WG Interim Meeting, 9/30/2009

  9. 8 0 4 12 16 20 24 28 32 Version Number Type Packet Length Router ID Area ID Check Sum Authentication Type (AuType) Authentication Message Body OSPF Common Header Format Case I – OSPF V2 (1/2) • An example where a protocol affords its own security • All messages are authenticated (except when AuType = 0, Null authentication) ROLL WG Interim Meeting, 9/30/2009

  10. 0 4 8 12 16 20 24 28 32 0 Key ID Auth Data Length Cryptographic Sequence Number Content of the Authentication field when using cryptographic authentication Case I – OSPF V2 (2/2) • Sequence number from a counter for anti-replaying • The LS Age field in LSA Header is not included in MAC and is exposed to tampering ROLL WG Interim Meeting, 9/30/2009

  11. Case II – OSPF V3 • An example where a protocol relies on lower layer’s services • AuType and Authentication in v2 header are removed • Calls out to rely on IPv6’s AH and ESP • RFC 4552, “Authentication/Confidentiality for OSPFv3,” mandates that • Support of authentication is MUST and confidentiality SHOULD • Support of transport mode is MUST and tunnel mode MAY ROLL WG Interim Meeting, 9/30/2009

  12. Discussions • There are other options, e.g., a protocol may afford its own security and also require lower layers’ support • In an open-trust model, trust extends across layers • A security service performed at a lower layer may not need to be repeated at a higher layer • If applicable, it can lead to a more efficient system • In LLNs, it is more desirable to require security services to be afforded by lower layers ROLL WG Interim Meeting, 9/30/2009

  13. Backup Slides

  14. Approach (1/3) • Four steps • Examine ROLL security issues • Analyze threats and attacks • Consider the countermeasures • Make recommendations for securing ROLL • The basis • Identify the assets and points of access of routing • Evaluate their security needs based on the CIA model in the context of LLNs ROLL WG Interim Meeting, 9/30/2009

  15. Approach (2/3) • The CIA principles are widely employed to understand, uncover, and formulate security needs • Confidentiality concerns unauthorized disclosure • Integrity concerns unauthorized alteration • Availability concerns if information and resources are accessible when needed • They can be limiting for certain applications • Other views include, e.g., non-repudiation ROLL WG Interim Meeting, 9/30/2009

  16. Approach (3/3) • Data flow diagram decomposition of routing ROLL WG Interim Meeting, 9/30/2009

  17. Security Needs • Routing/topology information • Integrity, confidentiality, and authorized use • Neighbor discovery process • Not to undermine routing availability • Routing/topology exchange process • Authentication, integrity, and confidentiality • Communication channels and node resources • Availability • Stored information, and routing and route generation processes • Confidentiality and Integrity ROLL WG Interim Meeting, 9/30/2009

  18. ROLL Issues • Limited energy reserve, memory, and processing resources • Large scale of rolled out network • Autonomous operations • Certain types of networks may have highly directional traffic • Unattended locations and limited physical security • Support for mobility • Support for multicast and anycast ROLL WG Interim Meeting, 9/30/2009

  19. Threats, Attacks, and Counters • Confidentiality • Routing exchange exposure • Routing information (routes and network topology) exposure • Integrity • Routing information manipulation • Node identity misappropriation • Availability • Routing exchange interference or disruption • Network traffic forwarding disruption • Communications resource disruption • Node resource exhaustion ROLL WG Interim Meeting, 9/30/2009

  20. ROLL Security Features (1/2) • Confidentiality • SHOULD provide payload encryption and privacy, e.g., when geographic information is used • MAY provide tunneling and load balancing • Integrity • MUST verify the liveliness of both principals of a connection, message freshness, and message sequence and integrity • Availability • MAY restrict neighborhood cardinality, randomly use multiple paths and/or destinations, set quotas to limit transmit or receive volume, and use geographic insights for flow control ROLL WG Interim Meeting, 9/30/2009

  21. ROLL Security Features (2/2) • Additional related features • If a LLN employs multicast and/or anycast, it MUST secure these protocols • MUST provide adequate physical tamper resistance to ensure the integrity of stored routing information. • MUST include a process for key and credential distribution; a LLN is encouraged to have procedures for their revocation and replacement ROLL WG Interim Meeting, 9/30/2009

More Related