--- 1/draft-ietf-roll-security-threats-07.txt 2014-07-21 07:14:38.241876746 -0700 +++ 2/draft-ietf-roll-security-threats-08.txt 2014-07-21 07:14:38.317878535 -0700 @@ -1,26 +1,26 @@ Routing Over Low-Power and Lossy Networks T. Tsao Internet-Draft R. Alexander Intended status: Informational Cooper Power Systems -Expires: December 12, 2014 M. Dohler +Expires: January 20, 2015 M. Dohler CTTC V. Daza A. Lozano Universitat Pompeu Fabra - M. Richardson + M. Richardson, Ed. Sandelman Software Works - June 10, 2014 + July 19, 2014 A Security Threat Analysis for Routing Protocol for Low-power and lossy networks (RPL) - draft-ietf-roll-security-threats-07 + draft-ietf-roll-security-threats-08 Abstract This document presents a security threat analysis for the Routing Protocol for Low-power and lossy networks (RPL, ROLL). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability @@ -41,21 +41,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 12, 2014. + This Internet-Draft will expire on January 20, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -81,56 +81,56 @@ 6.1.1. Node Impersonation . . . . . . . . . . . . . . . . . 13 6.1.2. Dummy Node . . . . . . . . . . . . . . . . . . . . . 14 6.1.3. Node Resource Spam . . . . . . . . . . . . . . . . . 14 6.2. Threats and Attacks on Confidentiality . . . . . . . . . 14 6.2.1. Routing Exchange Exposure . . . . . . . . . . . . . . 14 6.2.2. Routing Information (Routes and Network Topology) Exposure . . . . . . . . . . . . . . . . . . . . . . 14 6.3. Threats and Attacks on Integrity . . . . . . . . . . . . 15 6.3.1. Routing Information Manipulation . . . . . . . . . . 15 6.3.2. Node Identity Misappropriation . . . . . . . . . . . 16 - 6.4. Threats and Attacks on Availability . . . . . . . . . . . 17 - 6.4.1. Routing Exchange Interference or Disruption . . . . . 17 + 6.4. Threats and Attacks on Availability . . . . . . . . . . . 16 + 6.4.1. Routing Exchange Interference or Disruption . . . . . 16 6.4.2. Network Traffic Forwarding Disruption . . . . . . . . 17 6.4.3. Communications Resource Disruption . . . . . . . . . 18 - 6.4.4. Node Resource Exhaustion . . . . . . . . . . . . . . 19 - 7. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 20 - 7.1. Confidentiality Attack Countermeasures . . . . . . . . . 20 - 7.1.1. Countering Deliberate Exposure Attacks . . . . . . . 20 - 7.1.2. Countering Passive Wiretapping Attacks . . . . . . . 21 + 6.4.4. Node Resource Exhaustion . . . . . . . . . . . . . . 18 + 7. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 19 + 7.1. Confidentiality Attack Countermeasures . . . . . . . . . 19 + 7.1.1. Countering Deliberate Exposure Attacks . . . . . . . 19 + 7.1.2. Countering Passive Wiretapping Attacks . . . . . . . 20 7.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 21 - 7.1.4. Countering Remote Device Access Attacks . . . . . . . 22 + 7.1.4. Countering Remote Device Access Attacks . . . . . . . 21 7.2. Integrity Attack Countermeasures . . . . . . . . . . . . 22 - 7.2.1. Countering Unauthorized Modification Attacks . . . . 23 + 7.2.1. Countering Unauthorized Modification Attacks . . . . 22 7.2.2. Countering Overclaiming and Misclaiming Attacks . . . 23 - 7.2.3. Countering Identity (including Sybil) Attacks . . . . 24 - 7.2.4. Countering Routing Information Replay Attacks . . . . 24 - 7.2.5. Countering Byzantine Routing Information Attacks . . 25 + 7.2.3. Countering Identity (including Sybil) Attacks . . . . 23 + 7.2.4. Countering Routing Information Replay Attacks . . . . 23 + 7.2.5. Countering Byzantine Routing Information Attacks . . 24 7.3. Availability Attack Countermeasures . . . . . . . . . . . 25 7.3.1. Countering HELLO Flood Attacks and ACK Spoofing - Attacks . . . . . . . . . . . . . . . . . . . . . . . 26 + Attacks . . . . . . . . . . . . . . . . . . . . . . . 25 7.3.2. Countering Overload Attacks . . . . . . . . . . . . . 26 - 7.3.3. Countering Selective Forwarding Attacks . . . . . . . 28 - 7.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 29 - 7.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 30 - 8. RPL Security Features . . . . . . . . . . . . . . . . . . . . 30 - 8.1. Confidentiality Features . . . . . . . . . . . . . . . . 31 - 8.2. Integrity Features . . . . . . . . . . . . . . . . . . . 32 - 8.3. Availability Features . . . . . . . . . . . . . . . . . . 33 - 8.4. Key Management . . . . . . . . . . . . . . . . . . . . . 33 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 34 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 34 - 12.2. Informative References . . . . . . . . . . . . . . . . . 35 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 + 7.3.3. Countering Selective Forwarding Attacks . . . . . . . 27 + 7.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 28 + 7.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 29 + 8. RPL Security Features . . . . . . . . . . . . . . . . . . . . 29 + 8.1. Confidentiality Features . . . . . . . . . . . . . . . . 30 + 8.2. Integrity Features . . . . . . . . . . . . . . . . . . . 31 + 8.3. Availability Features . . . . . . . . . . . . . . . . . . 31 + 8.4. Key Management . . . . . . . . . . . . . . . . . . . . . 32 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 33 + 12.2. Informative References . . . . . . . . . . . . . . . . . 34 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction In recent times, networked electronic devices have found an increasing number of applications in various fields. Yet, for reasons ranging from operational application to economics, these wired and wireless devices are often supplied with minimum physical resources; the constraints include those on computational resources (RAM, clock speed, storage), communication resources (duty cycle, packet size, etc.), but also form factors that may rule out user @@ -169,21 +169,21 @@ describes a subset of these protocols and the conditions which make the subset the correct choice. The text recommends and motivates the accompanying parameter value ranges. Multiple applicability domains are recognized including: Building and Home, and Advanced Metering Infrastructure. The applicability domains distinguish themselves in the way they are operated, their performance requirements, and the most probable network structures. Each applicability statement identifies the distinguishing properties according to a common set of subjects described in as many sections. - The common set of security threats are herein are referred to by the + The common set of security threats herein are referred to by the applicability statements, and that series of documents describes the preferred security settings and solutions within the applicability statement conditions. This applicability statements may recommend more light weight security solutions and specify the conditions under which these solutions are appropriate. 3. Terminology This document adopts the terminology defined in [RFC6550], in [RFC4949], and in [I-D.ietf-roll-terminology]. @@ -317,24 +317,24 @@ attempts to misrepresent routing topology. Indeed, the intention of the security threat analysis is to be comprehensive. Hence, some of the discussion which follows is associated with assets and points of access that are not directly related to routing protocol design but nonetheless provided for reference since they do have direct consequences on the security of routing. 4.2. The ISO 7498-2 Security Reference Model At the conceptual level, security within an information system in - general and applied to RPL; in particular is concerned with the + general and applied to RPL in particular is concerned with the primary issues of authentication, access control, data confidentiality, data integrity, and non-repudiation. In the context - of RPL + of RPL: Authentication Authentication involves the mutual authentication of the routing peers prior to exchanging route information (i.e., peer authentication) as well as ensuring that the source of the route data is from the peer (i.e., data origin authentication). [RFC5548] points out that LLNs can be drained by unauthenticated peers before configuration. [RFC5673] requires availability of open and untrusted side channels for new joiners, and it requires strong and automated authentication so @@ -590,60 +590,57 @@ inside or outside attackers. While some attackers inside the network will be using compromised nodes, and therefore are only able to do what an ordinary node can ("node-equivalent"), other attacks may not limited in memory, CPU, power consumption or long term storage. Moore's law favours the attacker with access to the latest capabilities, while the defenders will remain in place for years to decades. 6.1. Threats due to failures to Authenticate - An attacker can assert an arbitrary identity, including the identity - of another node is said to be able to assert "any" identity. - 6.1.1. Node Impersonation If an attacker can join a network using any identity, then it may be able to assume the role of a legitimate (and existing node). It may be able to report false readings (in metering applications), or provide inappropriate control messages (in control systems involving actuators) if the security of the application is implied by the security of the routing system. Even in systems where there application layer security, the ability to impersonate a node would permit an attacker to direct traffic to itself. This may permit various on-path attacks which would otherwise be difficult, such replaying, delaying, or duplicating (application) control messages. 6.1.2. Dummy Node - If an attacker can join a network with any identify, then it can + If an attacker can join a network using any identify, then it can pretend to be a legitimate node, receiving any service legitimate nodes receive. It may also be able to report false readings (in metering applications), or provide inappropriate authorizations (in control systems involving actuators), or perform any other attacks that are facilitated by being able to direct traffic towards itself. 6.1.3. Node Resource Spam If an attacker can join a network with any identify, then it can continously do so with new (random) identities. This act may drain - down the resources of the network (battery, ram, bandwidth). This + down the resources of the network (battery, RAM, bandwidth). This may cause legitimate nodes of the network to be unable to communicate. 6.2. Threats and Attacks on Confidentiality The assessment in Section 4.2 indicates that there are attacks against the confidentiality of routing information at all points of - access. This threat results in disclosure, as described in + access. This threat may result in disclosure, as described in Section 3.1.2 of [RFC4593], and may involve a disclosure of routing information. 6.2.1. Routing Exchange Exposure Routing exchanges include both routing information as well as information associated with the establishment and maintenance of neighbor state information. As indicated in Section 4.1, the associated routing information assets may also include device specific resource information, such as available memory, remaining @@ -925,33 +924,34 @@ A passive wiretap attack seeks to breach routing confidentiality through passive, direct analysis and processing of the information exchanges between nodes. Passive wiretap attacks can be directly countered through the use of data encryption for all routing exchanges. Only when a validated and authenticated node association is completed will routing exchange be allowed to proceed using established session keys and an agreed encryption algorithm. The mandatory to implement CCM mode AES-128 method, is described in [RFC3610], and is believed to be secure - against a brute force attack by even the most well-equiped adversary. + against a brute force attack by even the most well-equipped + adversary. The significant challenge for RPL is in the provisioning of the key, which in some modes of RFC6550 is used network-wide. RFC6550 does not solve this problem, and it is the subject of significant future work: see, for instance: [AceCharterProposal], [SolaceProposal], [SmartObjectSecurityWorkshop]. A number of deployments, such as [ZigBeeIP] specify no layer-3/RPL encryption or authentication and rely upon similiar security at layer-2. These networks are immune to outside wiretapping attacks, - but are particularly vulnerable to passive (and active) attacks - through compromises of nodes. + but are vulnerable to passive (and active) routing attacks through + compromises of nodes. (see Section 8.2). Section 10.9 of [RFC6550] specifies AES-128 in CCM mode with a 32-bit MAC. Section 5.6 Zigbee IP [ZigBeeIP] specifies use of CCM, with PANA and EAP-TLS for key management. 7.1.3. Countering Traffic Analysis Traffic analysis provides an indirect means of subverting @@ -1353,26 +1352,27 @@ be difficult to call an attack. The worst thing that a benign wormhole can do in such a situation is to cease to operate (become unstable), causing the network to have to recalculate routes. A highly unstable wormhole is no different than a radio opaque (i.e. metal) door that opens and closes a lot. RPL includes hysteresis in its objective functions [RFC6719] in an attempt to deal with frequent changes to the ETX between nodes. 8. RPL Security Features + The assessments and analysis in Section 6 examined all areas of threats and attacks that could impact routing, and the countermeasures presented in Section 7 were reached without confining the consideration to means only available to routing. This section puts the results into perspective; dealing with those threats which - are endemnic to this field, those which have been mitigated through + are endemic to this field, those which have been mitigated through RPL protocol design, and those which require specific decisions to be made as part of provisioning a network. The first part of this section, Section 8.1 to Section 8.3, is a description of RPL security features that address specific threats. The second part of this section, Section 8.4, discusses issues of provisioning of security aspects that may impact routing but that also require considerations beyond the routing protocol, as well as potential approaches. @@ -1439,44 +1439,45 @@ entire deployment is under the control of a single administrative entity. Other layer-2 security mechanisms form a unique session key for every pair of nodes that needs to communicate; this is often called a per- link key. Such networks can provide a strong degree of origin authentication and integrity on unicast messages. However, some RPL messages are broadcast, and even when per-node layer-2 security mechanisms are used, the integrity and origin - authentication of broadcast messages can not be as securely known. + authentication of broadcast messages can not be as trusted due to the + proliferation of the key used to secure them. - RPL has two specific messages which are broadcast: the DODAG - Information Object (DIO), and the DODAG Information Solicitation - (DIS). The purpose of the DIS is to cause potential parents to reply - with a DIO, so the integrity of the DIS is not of great concern. The - DIS may also be unicast. + RPL has two specific options which are broadcast in RPL Control + Messages: the DODAG Information Object (DIO), and the DODAG + Information Solicitation (DIS). The purpose of the DIS is to cause + potential parents to reply with a DIO, so the integrity of the DIS is + not of great concern. The DIS may also be unicast. The DIO is a critical piece of routing and carries many critical - parameters. RPL provides for assymetric authentication at layer-3 of - the DIO, and this may be waranteed in some deployments. A node - could, if it felt that the DIO that it had received was suspicious, - send a unicast DIS message to the node in question, and that node - would reply with a unicast DIS. Those messages could be protected - with the per-link key. + parameters. RPL provides for asymmetric authentication at layer 3 of + the RPL Control Message carrying the DIO and this may be warranted in + some deployments. A node could, if it felt that the DIO that it had + received was suspicious, send a unicast DIS message to the node in + question, and that node would reply with a unicast DIS. Those + messages could be protected with the per-link key. 8.3. Availability Features Availability of routing information is linked to system and network availability which in the case of LLNs require a broader security view beyond the requirements of the routing entities. Where availability of the network is compromised, routing information availability will be accordingly affected. However, to specifically - assist in protecting routing availability: + assist in protecting routing availability, nodes: o MAY restrict neighborhood cardinality; o MAY use multiple paths; o MAY use multiple destinations; o MAY choose randomly if multiple paths are available; o MAY set quotas to limit transmit or receive volume; @@ -1518,22 +1520,22 @@ acknowledge the guidance and input provided by the RPL Chairs, David Culler, and JP Vasseur, and the Area Director Adrian Farrel. This document started out as a combined threat and solutions document. As a result of security review, the document was split up by RPL co-Chair Michael Richardson and security Area Director Sean Turner as it went through the IETF publication process. The solutions to the threats are application and layer-2 specific, and have therefore been moved to the relevant applicability statements. - Ines Robles and Robert Craigie kept track of the many issues that - were raised during the development of this document + Ines Robles and Robert Cragie kept track of the many issues that were + raised during the development of this document 12. References 12.1. Normative References [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-04 (work in progress), September 2010. @@ -1773,25 +1774,25 @@ Email: mischa.dohler@cttc.es Vanesa Daza Universitat Pompeu Fabra P/ Circumval.lacio 8, Oficina 308 Barcelona 08003 Spain Email: vanesa.daza@upf.edu + Angel Lozano Universitat Pompeu Fabra P/ Circumval.lacio 8, Oficina 309 Barcelona 08003 Spain Email: angel.lozano@upf.edu - - Michael Richardson (ed) + Michael Richardson (ed) (editor) Sandelman Software Works 470 Dawson Avenue Ottawa, ON K1Z5V7 Canada Email: mcr+ietf@sandelman.ca