| < draft-ietf-roll-security-threats-06.txt | draft-ietf-roll-security-threats-07.txt > | |||
|---|---|---|---|---|
| Routing Over Low-Power and Lossy Networks T. Tsao | Routing Over Low-Power and Lossy Networks T. Tsao | |||
| Internet-Draft R. Alexander | Internet-Draft R. Alexander | |||
| Intended status: Informational Cooper Power Systems | Intended status: Informational Cooper Power Systems | |||
| Expires: June 18, 2014 M. Dohler | Expires: December 12, 2014 M. Dohler | |||
| CTTC | CTTC | |||
| V. Daza | V. Daza | |||
| A. Lozano | A. Lozano | |||
| Universitat Pompeu Fabra | Universitat Pompeu Fabra | |||
| M. Richardson | M. Richardson | |||
| Sandelman Software Works | Sandelman Software Works | |||
| December 15, 2013 | June 10, 2014 | |||
| A Security Threat Analysis for Routing Protocol for Low-power and lossy | A Security Threat Analysis for Routing Protocol for Low-power and lossy | |||
| networks (RPL) | networks (RPL) | |||
| draft-ietf-roll-security-threats-06 | draft-ietf-roll-security-threats-07 | |||
| Abstract | Abstract | |||
| This document presents a security threat analysis for the Routing | This document presents a security threat analysis for the Routing | |||
| Protocol for Low-power and lossy networks (RPL, ROLL). The | Protocol for Low-power and lossy networks (RPL, ROLL). The | |||
| development builds upon previous work on routing security and adapts | development builds upon previous work on routing security and adapts | |||
| the assessments to the issues and constraints specific to low-power | the assessments to the issues and constraints specific to low-power | |||
| and lossy networks. A systematic approach is used in defining and | and lossy networks. A systematic approach is used in defining and | |||
| evaluating the security threats. Applicable countermeasures are | evaluating the security threats. Applicable countermeasures are | |||
| application specific and are addressed in relevant applicability | application specific and are addressed in relevant applicability | |||
| skipping to change at page 2, line 10 ¶ | skipping to change at page 2, line 10 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on June 18, 2014. | This Internet-Draft will expire on December 12, 2014. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2014 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Relationship to other documents . . . . . . . . . . . . . . . 4 | |||
| 3. Considerations on RPL Security . . . . . . . . . . . . . . . 4 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3.1. Routing Assets and Points of Access . . . . . . . . . . . 5 | 4. Considerations on RPL Security . . . . . . . . . . . . . . . 5 | |||
| 3.2. The ISO 7498-2 Security Reference Model . . . . . . . . . 7 | 4.1. Routing Assets and Points of Access . . . . . . . . . . . 5 | |||
| 3.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 9 | 4.2. The ISO 7498-2 Security Reference Model . . . . . . . . . 7 | |||
| 3.4. RPL Security Objectives . . . . . . . . . . . . . . . . . 11 | 4.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 9 | |||
| 4. Threat Sources . . . . . . . . . . . . . . . . . . . . . . . 12 | 4.4. RPL Security Objectives . . . . . . . . . . . . . . . . . 11 | |||
| 5. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 12 | 5. Threat Sources . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 5.1. Threats due to failures to Authenticate . . . . . . . . . 13 | 6. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 5.1.1. Node Impersonation . . . . . . . . . . . . . . . . . 13 | 6.1. Threats due to failures to Authenticate . . . . . . . . . 13 | |||
| 5.1.2. Dummy Node . . . . . . . . . . . . . . . . . . . . . 13 | 6.1.1. Node Impersonation . . . . . . . . . . . . . . . . . 13 | |||
| 5.1.3. Node Resource Spam . . . . . . . . . . . . . . . . . 13 | 6.1.2. Dummy Node . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 5.2. Threats and Attacks on Confidentiality . . . . . . . . . 13 | 6.1.3. Node Resource Spam . . . . . . . . . . . . . . . . . 14 | |||
| 5.2.1. Routing Exchange Exposure . . . . . . . . . . . . . . 14 | 6.2. Threats and Attacks on Confidentiality . . . . . . . . . 14 | |||
| 5.2.2. Routing Information (Routes and Network Topology) | 6.2.1. Routing Exchange Exposure . . . . . . . . . . . . . . 14 | |||
| 6.2.2. Routing Information (Routes and Network Topology) | ||||
| Exposure . . . . . . . . . . . . . . . . . . . . . . 14 | Exposure . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 5.3. Threats and Attacks on Integrity . . . . . . . . . . . . 15 | 6.3. Threats and Attacks on Integrity . . . . . . . . . . . . 15 | |||
| 5.3.1. Routing Information Manipulation . . . . . . . . . . 15 | 6.3.1. Routing Information Manipulation . . . . . . . . . . 15 | |||
| 5.3.2. Node Identity Misappropriation . . . . . . . . . . . 16 | 6.3.2. Node Identity Misappropriation . . . . . . . . . . . 16 | |||
| 5.4. Threats and Attacks on Availability . . . . . . . . . . . 16 | 6.4. Threats and Attacks on Availability . . . . . . . . . . . 17 | |||
| 5.4.1. Routing Exchange Interference or Disruption . . . . . 16 | 6.4.1. Routing Exchange Interference or Disruption . . . . . 17 | |||
| 5.4.2. Network Traffic Forwarding Disruption . . . . . . . . 16 | 6.4.2. Network Traffic Forwarding Disruption . . . . . . . . 17 | |||
| 5.4.3. Communications Resource Disruption . . . . . . . . . 18 | 6.4.3. Communications Resource Disruption . . . . . . . . . 18 | |||
| 5.4.4. Node Resource Exhaustion . . . . . . . . . . . . . . 18 | 6.4.4. Node Resource Exhaustion . . . . . . . . . . . . . . 19 | |||
| 6. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 19 | 7. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 6.1. Confidentiality Attack Countermeasures . . . . . . . . . 19 | 7.1. Confidentiality Attack Countermeasures . . . . . . . . . 20 | |||
| 6.1.1. Countering Deliberate Exposure Attacks . . . . . . . 19 | 7.1.1. Countering Deliberate Exposure Attacks . . . . . . . 20 | |||
| 6.1.2. Countering Passive Wiretapping Attacks . . . . . . . 20 | 7.1.2. Countering Passive Wiretapping Attacks . . . . . . . 21 | |||
| 6.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 21 | 7.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 21 | |||
| 6.1.4. Countering Remote Device Access Attacks . . . . . . . 22 | 7.1.4. Countering Remote Device Access Attacks . . . . . . . 22 | |||
| 6.2. Integrity Attack Countermeasures . . . . . . . . . . . . 22 | 7.2. Integrity Attack Countermeasures . . . . . . . . . . . . 22 | |||
| 6.2.1. Countering Unauthorized Modification Attacks . . . . 22 | 7.2.1. Countering Unauthorized Modification Attacks . . . . 23 | |||
| 6.2.2. Countering Overclaiming and Misclaiming Attacks . . . 23 | 7.2.2. Countering Overclaiming and Misclaiming Attacks . . . 23 | |||
| 6.2.3. Countering Identity (including Sybil) Attacks . . . . 23 | 7.2.3. Countering Identity (including Sybil) Attacks . . . . 24 | |||
| 6.2.4. Countering Routing Information Replay Attacks . . . . 23 | 7.2.4. Countering Routing Information Replay Attacks . . . . 24 | |||
| 6.2.5. Countering Byzantine Routing Information Attacks . . 24 | 7.2.5. Countering Byzantine Routing Information Attacks . . 25 | |||
| 6.3. Availability Attack Countermeasures . . . . . . . . . . . 25 | 7.3. Availability Attack Countermeasures . . . . . . . . . . . 25 | |||
| 6.3.1. Countering HELLO Flood Attacks and ACK Spoofing | 7.3.1. Countering HELLO Flood Attacks and ACK Spoofing | |||
| Attacks . . . . . . . . . . . . . . . . . . . . . . . 25 | Attacks . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
| 6.3.2. Countering Overload Attacks . . . . . . . . . . . . . 26 | 7.3.2. Countering Overload Attacks . . . . . . . . . . . . . 26 | |||
| 6.3.3. Countering Selective Forwarding Attacks . . . . . . . 27 | 7.3.3. Countering Selective Forwarding Attacks . . . . . . . 28 | |||
| 6.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 28 | 7.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 29 | |||
| 6.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 29 | 7.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 30 | |||
| 7. RPL Security Features . . . . . . . . . . . . . . . . . . . . 29 | 8. RPL Security Features . . . . . . . . . . . . . . . . . . . . 30 | |||
| 7.1. Confidentiality Features . . . . . . . . . . . . . . . . 30 | 8.1. Confidentiality Features . . . . . . . . . . . . . . . . 31 | |||
| 7.2. Integrity Features . . . . . . . . . . . . . . . . . . . 31 | 8.2. Integrity Features . . . . . . . . . . . . . . . . . . . 32 | |||
| 7.3. Availability Features . . . . . . . . . . . . . . . . . . 32 | 8.3. Availability Features . . . . . . . . . . . . . . . . . . 33 | |||
| 7.4. Key Management . . . . . . . . . . . . . . . . . . . . . 32 | 8.4. Key Management . . . . . . . . . . . . . . . . . . . . . 33 | |||
| 7.5. Consideration on Matching Application Domain Needs . . . 33 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 | |||
| 7.5.1. Mechanisms and Operations . . . . . . . . . . . . . . 33 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 34 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 | 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
| 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 34 | |||
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 | 12.2. Informative References . . . . . . . . . . . . . . . . . 35 | |||
| 11.1. Normative References . . . . . . . . . . . . . . . . . . 35 | ||||
| 11.2. Informative References . . . . . . . . . . . . . . . . . 35 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
| 1. Introduction | 1. Introduction | |||
| In recent times, networked electronic devices have found an | In recent times, networked electronic devices have found an | |||
| increasing number of applications in various fields. Yet, for | increasing number of applications in various fields. Yet, for | |||
| reasons ranging from operational application to economics, these | reasons ranging from operational application to economics, these | |||
| wired and wireless devices are often supplied with minimum physical | wired and wireless devices are often supplied with minimum physical | |||
| resources; the constraints include those on computational resources | resources; the constraints include those on computational resources | |||
| (RAM, clock speed, storage), communication resources (duty cycle, | (RAM, clock speed, storage), communication resources (duty cycle, | |||
| skipping to change at page 4, line 15 ¶ | skipping to change at page 4, line 14 ¶ | |||
| address their potential networking challenges. Securing the | address their potential networking challenges. Securing the | |||
| establishment and maintenance of network connectivity among these | establishment and maintenance of network connectivity among these | |||
| deployed devices becomes one of these key challenges. | deployed devices becomes one of these key challenges. | |||
| This document presents a threat analysis for securing the Routing | This document presents a threat analysis for securing the Routing | |||
| Protocol for LLNs (RPL). The process requires two steps. First, the | Protocol for LLNs (RPL). The process requires two steps. First, the | |||
| analysis will be used to identify pertinent security issues. The | analysis will be used to identify pertinent security issues. The | |||
| second step is to identify necessary countermeasures to secure RPL. | second step is to identify necessary countermeasures to secure RPL. | |||
| As there are multiple ways to solve the problem and the specific | As there are multiple ways to solve the problem and the specific | |||
| tradeoffs are deployment specific, the specific countermeasure to be | tradeoffs are deployment specific, the specific countermeasure to be | |||
| used is detailed in applicatbility statements. | used is detailed in applicability statements. | |||
| This document uses [IS07498-2] model, which includes Authentication, | This document uses [IS07498-2] model, which describes Authentication, | |||
| Access Control, Data Confidentiality, Data Integrity, and Non- | Access Control, Data Confidentiality, Data Integrity, and Non- | |||
| Repudiation but to which Availability is added. | Repudiation security services and to which Availability is added. | |||
| All of this document concerns itself with securing the control plane | All of this document concerns itself with securing the control plane | |||
| traffic. As such it does not address authorization or authentication | traffic. As such it does not address authorization or authentication | |||
| of application traffic, nor does it deal with multicast traffic | of application traffic. RPL uses multicast as part of it's protocol, | |||
| controls. Mechanisms used to secure RPL traffic SHOULD be leveraged | and therefore mechanisms which RPL uses to secure this traffic MAY be | |||
| to secure other protocols. | applicable to MPL control traffic as well: the important part is that | |||
| the threats are similiar. | ||||
| 2. Terminology | 2. Relationship to other documents | |||
| ROLL has specified a set of routing protocols for Lossy and Low- | ||||
| resource Networks (LLN) [RFC6550]. A number of applicability texts | ||||
| 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 | ||||
| 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 | This document adopts the terminology defined in [RFC6550], in | |||
| [RFC4949], and in [I-D.ietf-roll-terminology]. | [RFC4949], and in [I-D.ietf-roll-terminology]. | |||
| The terms control plane and forwarding plane are used consistently | The terms control plane and forwarding plane are used consistently | |||
| with section 1 of [RFC6192]. | with section 1 of [RFC6192]. | |||
| 3. Considerations on RPL Security | 4. Considerations on RPL Security | |||
| Routing security, in essence, ensures that the routing protocol | Routing security, in essence, ensures that the routing protocol | |||
| operates correctly. It entails implementing measures to ensure | operates correctly. It entails implementing measures to ensure | |||
| controlled state changes on devices and network elements, both based | controlled state changes on devices and network elements, both based | |||
| on external inputs (received via communications) or internal inputs | on external inputs (received via communications) or internal inputs | |||
| (physical security of device itself and parameters maintained by the | (physical security of device itself and parameters maintained by the | |||
| device, including, e.g., clock). State changes would thereby involve | device, including, e.g., clock). State changes would thereby involve | |||
| not only authorization of injector's actions, authentication of | not only authorization of injector's actions, authentication of | |||
| injectors, and potentially confidentiality of routing data, but also | injectors, and potentially confidentiality of routing data, but also | |||
| proper order of state changes through timeliness, since seriously | proper order of state changes through timeliness, since seriously | |||
| delayed state changes, such as commands or updates of routing tables, | delayed state changes, such as commands or updates of routing tables, | |||
| may negatively impact system operation. A security assesment can | may negatively impact system operation. A security assessment can | |||
| therefore begin with a focus on the assets [RFC4949] that may be the | therefore begin with a focus on the assets [RFC4949] that may be the | |||
| target of the state changes and the access points in terms of | target of the state changes and the access points in terms of | |||
| interfaces and protocol exchanges through which such changes may | interfaces and protocol exchanges through which such changes may | |||
| occur. In the case of routing security the focus is directed towards | occur. In the case of routing security, the focus is directed | |||
| the elements associated with the establishment and maintenance of | towards the elements associated with the establishment and | |||
| network connectivity. | maintenance of network connectivity. | |||
| This section sets the stage for the development of the analysis by | This section sets the stage for the development of the analysis by | |||
| applying the systematic approach proposed in [Myagmar2005] to the | applying the systematic approach proposed in [Myagmar2005] to the | |||
| routing security, while also drawing references from other reviews | routing security, while also drawing references from other reviews | |||
| and assessments found in the literature, particularly, [RFC4593] and | and assessments found in the literature, particularly, [RFC4593] and | |||
| [Karlof2003]. The subsequent subsections begin with a focus on the | [Karlof2003]. The subsequent subsections begin with a focus on the | |||
| elements of a generic routing process that is used to establish | elements of a generic routing process that is used to establish | |||
| routing assets and points of access to the routing functionality. | routing assets and points of access to the routing functionality. | |||
| Next, the [ISO.7498-2.1988] security model is briefly described. | Next, the [ISO.7498-2.1988] security model is briefly described. | |||
| Then, consideration is given to issues specific to or amplified in | Then, consideration is given to issues specific to or amplified in | |||
| LLNs. This section concludes with the formulation of a set of | LLNs. This section concludes with the formulation of a set of | |||
| security objectives for RPL. | security objectives for RPL. | |||
| 3.1. Routing Assets and Points of Access | 4.1. Routing Assets and Points of Access | |||
| An asset is an important system resource (including information, | An asset is an important system resource (including information, | |||
| process, or physical resource), the access to, corruption or loss of | process, or physical resource), the access to, corruption or loss of | |||
| which adversely affects the system. In the control plane context, an | which adversely affects the system. In the control plane context, an | |||
| asset is information about the network, processes used to manage and | asset is information about the network, processes used to manage and | |||
| manipulate this data, and the physical devices on which this data is | manipulate this data, and the physical devices on which this data is | |||
| stored and manipulated. The corruption or loss of these assets may | stored and manipulated. The corruption or loss of these assets may | |||
| adversely impact the control plane of the network. Within the same | adversely impact the control plane of the network. Within the same | |||
| context, a point of access is an interface or protocol that | context, a point of access is an interface or protocol that | |||
| facilitates interaction between control plane components. | facilitates interaction between control plane assets. Identifying | |||
| Identifying these assets and points of access will provide a basis | these assets and points of access will provide a basis for | |||
| for enumerating the attack surface of the control plane. | enumerating the attack surface of the control plane. | |||
| A level-0 data flow diagram [Yourdon1979] is used here to identify | A level-0 data flow diagram [Yourdon1979] is used here to identify | |||
| the assets and points of access within a generic routing process. | the assets and points of access within a generic routing process. | |||
| The use of a data flow diagram allows for a clear and concise model | The use of a data flow diagram allows for a clear and concise model | |||
| of the way in which routing nodes interact and process information, | of the way in which routing nodes interact and process information, | |||
| and hence provides a context for threats and attacks. The goal of | and hence provides a context for threats and attacks. The goal of | |||
| the model is to be as detailed as possible so that corresponding | the model is to be as detailed as possible so that corresponding | |||
| assets, points of access, and process in an individual routing | assets, points of access, and process in an individual routing | |||
| protocol can be readily identified. | protocol can be readily identified. | |||
| skipping to change at page 7, line 26 ¶ | skipping to change at page 7, line 42 ¶ | |||
| A focus on the above list of assets and points of access enables a | A focus on the above list of assets and points of access enables a | |||
| more directed assessment of routing security; for example, it is | more directed assessment of routing security; for example, it is | |||
| readily understood that some routing attacks are in the form of | readily understood that some routing attacks are in the form of | |||
| attempts to misrepresent routing topology. Indeed, the intention of | attempts to misrepresent routing topology. Indeed, the intention of | |||
| the security threat analysis is to be comprehensive. Hence, some of | the security threat analysis is to be comprehensive. Hence, some of | |||
| the discussion which follows is associated with assets and points of | the discussion which follows is associated with assets and points of | |||
| access that are not directly related to routing protocol design but | access that are not directly related to routing protocol design but | |||
| nonetheless provided for reference since they do have direct | nonetheless provided for reference since they do have direct | |||
| consequences on the security of routing. | consequences on the security of routing. | |||
| 3.2. The ISO 7498-2 Security Reference Model | 4.2. The ISO 7498-2 Security Reference Model | |||
| At the conceptual level, security within an information system in | 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 | primary issues of authentication, access control, data | |||
| confidentiality, data integrity, and non-repudiation. In the context | confidentiality, data integrity, and non-repudiation. In the context | |||
| of RPL | of RPL | |||
| Authentication | Authentication | |||
| Authentication involves the mutual authentication of the | Authentication involves the mutual authentication of the | |||
| routing peers prior to exchanging route information (i.e., peer | routing peers prior to exchanging route information (i.e., peer | |||
| authentication) as well as ensuring that the source of the | authentication) as well as ensuring that the source of the | |||
| route data is from the peer (i.e., data origin authentication). | route data is from the peer (i.e., data origin authentication). | |||
| [RFC5548] points out that LLNs can be drained by | [RFC5548] points out that LLNs can be drained by | |||
| skipping to change at page 9, line 5 ¶ | skipping to change at page 9, line 22 ¶ | |||
| apply to maintaining efficient and correct operation of routing | apply to maintaining efficient and correct operation of routing | |||
| and neighbor discovery exchanges (including needed information) | and neighbor discovery exchanges (including needed information) | |||
| and forwarding services so as not to impair or limit the | and forwarding services so as not to impair or limit the | |||
| network's central traffic flow function | network's central traffic flow function | |||
| It should be emphasized here that for RPL security the above | It should be emphasized here that for RPL security the above | |||
| requirements must be complemented by the proper security policies and | requirements must be complemented by the proper security policies and | |||
| enforcement mechanisms to ensure that security objectives are met by | enforcement mechanisms to ensure that security objectives are met by | |||
| a given RPL implementation. | a given RPL implementation. | |||
| 3.3. Issues Specific to or Amplified in LLNs | 4.3. Issues Specific to or Amplified in LLNs | |||
| The work [RFC5548], [RFC5673], [RFC5826], and [RFC5867] have | The requirements work detailed in Urban Requirements ([RFC5548]), | |||
| identified specific issues and constraints of routing in LLNs for the | Industrial Requirements ([RFC5673]), Home Automation ([RFC5826], and | |||
| urban, industrial, home automation, and building automation | Building Automation ([RFC5867]) have identified specific issues and | |||
| application domains, respectively. The following is a list of | constraints of routing in LLNs. The following is a list of | |||
| observations and evaluation of their impact on routing security | observations from those requirements and evaluation of their impact | |||
| considerations. | on routing security considerations. | |||
| Limited energy, memory, and processing node resources | Limited energy, memory, and processing node resources | |||
| As a consequence of these constraints, there is an even more | As a consequence of these constraints, there is an even more | |||
| critical need than usual for a careful study of trade-offs on | critical need than usual for a careful study of trade-offs on | |||
| which and what level of security services are to be afforded | which and what level of security services are to be afforded | |||
| during the system design process. The chosen security | during the system design process. The chosen security | |||
| mechanisms also needs to work within these constraints. | mechanisms also needs to work within these constraints. | |||
| Synchronization of security states with sleepy nodes is yet | Synchronization of security states with sleepy nodes is yet | |||
| another issue. | another issue. | |||
| skipping to change at page 11, line 15 ¶ | skipping to change at page 11, line 26 ¶ | |||
| The above list considers how an LLN's physical constraints, size, | The above list considers how an LLN's physical constraints, size, | |||
| operations, and variety of application areas may impact security. | operations, and variety of application areas may impact security. | |||
| However, it is the combinations of these factors that particularly | However, it is the combinations of these factors that particularly | |||
| stress the security concerns. For instance, securing routing for a | stress the security concerns. For instance, securing routing for a | |||
| large number of autonomous devices that are left in unattended | large number of autonomous devices that are left in unattended | |||
| locations with limited physical security presents challenges that are | locations with limited physical security presents challenges that are | |||
| not found in the common circumstance of administered networked | not found in the common circumstance of administered networked | |||
| routers. The following subsection sets up the security objectives | routers. The following subsection sets up the security objectives | |||
| for the routing protocol designed by the ROLL WG. | for the routing protocol designed by the ROLL WG. | |||
| 3.4. RPL Security Objectives | 4.4. RPL Security Objectives | |||
| This subsection applies the ISO 7498-2 model to routing assets and | This subsection applies the ISO 7498-2 model to routing assets and | |||
| access points, taking into account the LLN issues, to develop a set | access points, taking into account the LLN issues, to develop a set | |||
| of RPL security objectives. | of RPL security objectives. | |||
| Since the fundamental function of a routing protocol is to build | Since the fundamental function of a routing protocol is to build | |||
| routes for forwarding packets, it is essential to ensure that: | routes for forwarding packets, it is essential to ensure that: | |||
| o routing/topology information iintegrity remains intact during | o routing/topology information integrity remains intact during | |||
| transfer and in storage; | transfer and in storage; | |||
| o routing/topology information is used by authorized entities; | o routing/topology information is used by authorized entities; | |||
| o routing/topology information is available when needed. | o routing/topology information is available when needed. | |||
| In conjunction, it is necessary to be assured that | In conjunction, it is necessary to be assured that | |||
| o authorized peers authenticate themselves during the routing | o authorized peers authenticate themselves during the routing | |||
| neighbor discovery process; | neighbor discovery process; | |||
| skipping to change at page 12, line 32 ¶ | skipping to change at page 12, line 42 ¶ | |||
| confidentiality, of stored information, as well as the integrity of | confidentiality, of stored information, as well as the integrity of | |||
| routing and route generation processes. | routing and route generation processes. | |||
| Each individual system's use and environment will dictate how the | Each individual system's use and environment will dictate how the | |||
| above objectives are applied, including the choices of security | above objectives are applied, including the choices of security | |||
| services as well as the strengths of the mechanisms that must be | services as well as the strengths of the mechanisms that must be | |||
| implemented. The next two sections take a closer look at how the RPL | implemented. The next two sections take a closer look at how the RPL | |||
| security objectives may be compromised and how those potential | security objectives may be compromised and how those potential | |||
| compromises can be countered. | compromises can be countered. | |||
| 4. Threat Sources | 5. Threat Sources | |||
| [RFC4593] provides a detailed review of the threat sources: outsiders | [RFC4593] provides a detailed review of the threat sources: outsiders | |||
| and byzantine. RPL has the same threat sources. | and byzantine. RPL has the same threat sources. | |||
| 5. Threats and Attacks | 6. Threats and Attacks | |||
| This section outlines general categories of threats under the ISO | This section outlines general categories of threats under the ISO | |||
| 7498-2 model and highlights the specific attacks in each of these | 7498-2 model and highlights the specific attacks in each of these | |||
| categories for RPL. As defined in [RFC4949], a threat is "a | categories for RPL. As defined in [RFC4949], a threat is "a | |||
| potential for violation of security, which exists when there is a | potential for violation of security, which exists when there is a | |||
| circumstance, capability, action, or event that could breach security | circumstance, capability, action, or event that could breach security | |||
| and cause harm." | and cause harm." | |||
| An attack is "an assault on system security that derives from an | An attack is "an assault on system security that derives from an | |||
| intelligent threat, i.e., an intelligent act that is a deliberate | intelligent threat, i.e., an intelligent act that is a deliberate | |||
| attempt (especially in the sense of a method or technique) to evade | attempt (especially in the sense of a method or technique) to evade | |||
| security services and violate the security policy of a system." | security services and violate the security policy of a system." | |||
| The subsequent subsections consider the threats and the attacks that | The subsequent subsections consider the threats and the attacks that | |||
| can cause security breaches under the ISO 7498-2 model to the routing | can cause security breaches under the ISO 7498-2 model to the routing | |||
| assets and via the routing points of access identified in | assets and via the routing points of access identified in | |||
| Section 3.1. The assessment steps through the security concerns of | Section 4.1. The assessment steps through the security concerns of | |||
| each routing asset and looks at the attacks that can exploit routing | each routing asset and looks at the attacks that can exploit routing | |||
| points of access. The threats and attacks identified are based on | points of access. The threats and attacks identified are based on | |||
| the routing model analysis and associated review of the existing | the routing model analysis and associated review of the existing | |||
| literature. The source of the attacks is assumed to be from either | literature. The source of the attacks is assumed to be from either | |||
| inside or outside attackers. The capability these attackes may be | inside or outside attackers. While some attackers inside the network | |||
| limited to node-equivalent, but also to more sophisticated computing | will be using compromised nodes, and therefore are only able to do | |||
| platforms. | 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. | ||||
| 5.1. Threats due to failures to Authenticate | 6.1. Threats due to failures to Authenticate | |||
| 5.1.1. Node Impersonation | An attacker can assert an arbitrary identity, including the identity | |||
| of another node is said to be able to assert "any" identity. | ||||
| If an attacker can join a network with any identify, then it may be | 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 | able to assume the role of a legitimate (and existing node). It may | |||
| be able to report false readings (in metering applications), or | be able to report false readings (in metering applications), or | |||
| provide inappropriate control messages (in control systems involving | provide inappropriate control messages (in control systems involving | |||
| actuators) if the security of the application is leveraged from the | actuators) if the security of the application is implied by the | |||
| security of the routing system. | security of the routing system. | |||
| In other systems where there is separate application layer security, | Even in systems where there application layer security, the ability | |||
| the ability to impersonate a node would permit an attacker to direct | to impersonate a node would permit an attacker to direct traffic to | |||
| traffic to itself, which facilitates on-path attacks including | itself. This may permit various on-path attacks which would | |||
| replaying, delaying, or duplicating control messages. | otherwise be difficult, such replaying, delaying, or duplicating | |||
| (application) control messages. | ||||
| 5.1.2. Dummy Node | 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 with any identify, then it can | |||
| pretend to be a legitimate node, receiving any service legitimate | pretend to be a legitimate node, receiving any service legitimate | |||
| nodes receive. It may also be able to report false readings (in | nodes receive. It may also be able to report false readings (in | |||
| metering applications), or provide inappropriate authorizations (in | metering applications), or provide inappropriate authorizations (in | |||
| control systems involving actuators), or perform any other attacks | control systems involving actuators), or perform any other attacks | |||
| that are facilitated by being able to direct traffic towards itself. | that are facilitated by being able to direct traffic towards itself. | |||
| 5.1.3. Node Resource Spam | 6.1.3. Node Resource Spam | |||
| If an attacker can join a network with any identify, then it can | If an attacker can join a network with any identify, then it can | |||
| continously do so, draining down the resources of the network to | continously do so with new (random) identities. This act may drain | |||
| store identity and routing information, potentionally forcing | down the resources of the network (battery, ram, bandwidth). This | |||
| legitimate nodes of the network. | may cause legitimate nodes of the network to be unable to | |||
| communicate. | ||||
| 5.2. Threats and Attacks on Confidentiality | 6.2. Threats and Attacks on Confidentiality | |||
| The assessment in Section 3.2 indicates that there are threat actions | ||||
| The assessment in Section 4.2 indicates that there are attacks | ||||
| against the confidentiality of routing information at all points of | against the confidentiality of routing information at all points of | |||
| access. This threat results in disclosure, as described in | access. This threat results in disclosure, as described in | |||
| Section 3.1.2 of [RFC4593], and it involves a disclosure of routing | Section 3.1.2 of [RFC4593], and may involve a disclosure of routing | |||
| information. | information. | |||
| 5.2.1. Routing Exchange Exposure | 6.2.1. Routing Exchange Exposure | |||
| Routing exchanges include both routing information as well as | Routing exchanges include both routing information as well as | |||
| information associated with the establishment and maintenance of | information associated with the establishment and maintenance of | |||
| neighbor state information. As indicated in Section 3.1, the | neighbor state information. As indicated in Section 4.1, the | |||
| associated routing information assets may also include device | associated routing information assets may also include device | |||
| specific resource information, such as memory, remaining power, etc., | specific resource information, such as available memory, remaining | |||
| that may be metrics of the routing protocol. | power, etc., that may be metrics of the routing protocol. | |||
| The routing exchanges will contain reachability information, which | The routing exchanges will contain reachability information, which | |||
| would identify the relative importance of different nodes in the | would identify the relative importance of different nodes in the | |||
| network. Nodes higher up in the DODAG, to which more streams of | network. Nodes higher up in the DODAG, to which more streams of | |||
| information flow, would be more interesting targets for other | information flow, would be more interesting targets for other | |||
| attacks, and routing exchange exposures can identify them. | attacks, and routing exchange exposures can identify them. | |||
| 5.2.2. Routing Information (Routes and Network Topology) Exposure | 6.2.2. Routing Information (Routes and Network Topology) Exposure | |||
| Routes (which may be maintained in the form of the protocol | Routes (which may be maintained in the form of the protocol | |||
| forwarding table) and neighbor topology information are the products | forwarding table) and neighbor topology information are the products | |||
| of the routing process that are stored within the node device | of the routing process that are stored within the node device | |||
| databases. | databases. | |||
| The exposure of this information will allow attachers to gain direct | The exposure of this information will allow attackers to gain direct | |||
| access to the configuration and connectivity of the network thereby | access to the configuration and connectivity of the network thereby | |||
| exposing routing to targeted attacks on key nodes or links. Since | exposing routing to targeted attacks on key nodes or links. Since | |||
| routes and neighbor topology information is stored within the node | routes and neighbor topology information is stored within the node | |||
| device, threats or attacks on the confidentiality of the information | device, attacks on the confidentiality of the information will apply | |||
| will apply to the physical device including specified and unspecified | to the physical device including specified and unspecified internal | |||
| internal and external interfaces. | and external interfaces. | |||
| The forms of attack that allow unauthorized access or disclosure of | The forms of attack that allow unauthorized access or disclosure of | |||
| the routing information (other than occurring through explicit node | the routing information will include: | |||
| exchanges) will include: | ||||
| o Physical device compromise; | o Physical device compromise; | |||
| o Remote device access attacks (including those occurring through | o Remote device access attacks (including those occurring through | |||
| remote network management or software/field upgrade interfaces). | remote network management or software/field upgrade interfaces). | |||
| Both of these attack vectors are considered a device specific issue, | Both of these attack vectors are considered a device specific issue, | |||
| and are out of scope for RPL to defend against. In some | and are out of scope for RPL to defend against. In some | |||
| applications, physical device compromise may be a real threat and it | applications, physical device compromise may be a real threat and it | |||
| may be necessary to provide for other devices to react quickly to | may be necessary to provide for other devices to securely detect a | |||
| exclude a compromised device. | compromised device and react quickly to exclude it. | |||
| 5.3. Threats and Attacks on Integrity | 6.3. Threats and Attacks on Integrity | |||
| The assessment in Section 3.2 indicates that information and identity | The assessment in Section 4.2 indicates that information and identity | |||
| assets are exposed to integrity threats from all points of access. | assets are exposed to integrity threats from all points of access. | |||
| In other words, the integrity threat space is defined by the | In other words, the integrity threat space is defined by the | |||
| potential for exploitation introduced by access to assets available | potential for exploitation introduced by access to assets available | |||
| through routing exchanges and the on-device storage. | through routing exchanges and the on-device storage. | |||
| 5.3.1. Routing Information Manipulation | 6.3.1. Routing Information Manipulation | |||
| Manipulation of routing information that range from neighbor states | Manipulation of routing information that range from neighbor states | |||
| to derived routes will allow unauthorized sources to influence the | to derived routes will allow unauthorized sources to influence the | |||
| operation and convergence of the routing protocols and ultimately | operation and convergence of the routing protocols and ultimately | |||
| impact the forwarding decisions made in the network. | impact the forwarding decisions made in the network. | |||
| Manipulation of topology and reachability information will allow | Manipulation of topology and reachability information will allow | |||
| unauthorized sources to influence the nodes with which routing | unauthorized sources to influence the nodes with which routing | |||
| information is exchanged and updated. The consequence of | information is exchanged and updated. The consequence of | |||
| manipulating routing exchanges can thus lead to sub-optimality and | manipulating routing exchanges can thus lead to sub-optimality and | |||
| skipping to change at page 15, line 40 ¶ | skipping to change at page 16, line 23 ¶ | |||
| A sub-optimal network may use too much power and/or may congest some | A sub-optimal network may use too much power and/or may congest some | |||
| routes leading to premature failure of a node, and a denial of | routes leading to premature failure of a node, and a denial of | |||
| service on the entire network. | service on the entire network. | |||
| In addition, being able to attract network traffic can make a | In addition, being able to attract network traffic can make a | |||
| blackhole attack more damaging. | blackhole attack more damaging. | |||
| The forms of attack that allow manipulation to compromise the content | The forms of attack that allow manipulation to compromise the content | |||
| and validity of routing information include | and validity of routing information include | |||
| o Falsification, including overclaiming and misclaiming; | o Falsification, including overclaiming and misclaiming (claiming | |||
| routes to devices which the device can not in fact reach); | ||||
| o Routing information replay; | o Routing information replay; | |||
| o Byzantine (internal) attacks that permit corruption of routing | o Byzantine (internal) attacks that permit corruption of routing | |||
| information in the node even where the node continues to be a | information in the node even where the node continues to be a | |||
| validated entity within the network (see, for example, [RFC4593] | validated entity within the network (see, for example, [RFC4593] | |||
| for further discussions on Byzantine attacks); | for further discussions on Byzantine attacks); | |||
| o Physical device compromise or remote device access attacks. | o Physical device compromise or remote device access attacks. | |||
| 5.3.2. Node Identity Misappropriation | 6.3.2. Node Identity Misappropriation | |||
| Falsification or misappropriation of node identity between routing | Falsification or misappropriation of node identity between routing | |||
| participants opens the door for other attacks; it can also cause | participants opens the door for other attacks; it can also cause | |||
| incorrect routing relationships to form and/or topologies to emerge. | incorrect routing relationships to form and/or topologies to emerge. | |||
| Routing attacks may also be mounted through less sophisticated node | Routing attacks may also be mounted through less sophisticated node | |||
| identity misappropriation in which the valid information broadcast or | identity misappropriation in which the valid information broadcast or | |||
| exchanged by a node is replayed without modification. The receipt of | exchanged by a node is replayed without modification. The receipt of | |||
| seemingly valid information that is however no longer current can | seemingly valid information that is however no longer current can | |||
| result in routing disruption, and instability (including failure to | result in routing disruption, and instability (including failure to | |||
| converge). Without measures to authenticate the routing participants | converge). Without measures to authenticate the routing participants | |||
| and to ensure the freshness and validity of the received information | and to ensure the freshness and validity of the received information | |||
| the protocol operation can be compromised. The forms of attack that | the protocol operation can be compromised. The forms of attack that | |||
| misuse node identity include | misuse node identity include | |||
| o Identity attacks, including Sybil attacks in which a malicious | o Identity attacks, including Sybil attacks (see [Sybil2002]) in | |||
| node illegitimately assumes multiple identities; | which a malicious node illegitimately assumes multiple identities; | |||
| o Routing information replay. | o Routing information replay. | |||
| 5.4. Threats and Attacks on Availability | 6.4. Threats and Attacks on Availability | |||
| The assessment in Section 3.2 indicates that the process and | The assessment in Section 4.2 indicates that the process and | |||
| resources assets are exposed to threats against availability; attacks | resources assets are exposed to threats against availability; attacks | |||
| in this category may exploit directly or indirectly information | in this category may exploit directly or indirectly information | |||
| exchange or forwarding (see [RFC4732] for a general discussion). | exchange or forwarding (see [RFC4732] for a general discussion). | |||
| 5.4.1. Routing Exchange Interference or Disruption | 6.4.1. Routing Exchange Interference or Disruption | |||
| Interference is the threat action and disruption is threat | Interference is the threat action and disruption is threat | |||
| consequence that allows attackers to influence the operation and | consequence that allows attackers to influence the operation and | |||
| convergence of the routing protocols by impeding the routing | convergence of the routing protocols by impeding the routing | |||
| information exchange. | information exchange. | |||
| The forms of attack that allow interference or disruption of routing | The forms of attack that allow interference or disruption of routing | |||
| exchange include: | exchange include: | |||
| o Routing information replay; | o Routing information replay; | |||
| o ACK spoofing; | o ACK spoofing; | |||
| o Overload attacks. (Section 6.3.2) | o Overload attacks. (Section 7.3.2) | |||
| In addition, attacks may also be directly conducted at the physical | In addition, attacks may also be directly conducted at the physical | |||
| layer in the form of jamming or interfering. | layer in the form of jamming or interfering. | |||
| 5.4.2. Network Traffic Forwarding Disruption | 6.4.2. Network Traffic Forwarding Disruption | |||
| The disruption of the network traffic forwarding capability will | The disruption of the network traffic forwarding capability will | |||
| undermine the central function of network routers and the ability to | undermine the central function of network routers and the ability to | |||
| handle user traffic. This affects the availability of the network | handle user traffic. This affects the availability of the network | |||
| because of the potential to impair the primary capability of the | because of the potential to impair the primary capability of the | |||
| network. | network. | |||
| In addition to physical layer obstructions, the forms of attack that | In addition to physical layer obstructions, the forms of attack that | |||
| allows disruption of network traffic forwarding include [Karlof2003] | allows disruption of network traffic forwarding include [Karlof2003] | |||
| o Selective forwarding attacks; | o Selective forwarding attacks; | |||
| |Node_1|--(msg1|msg2|msg3)-->|Attacker|--(msg1|msg3)-->|Node_2| | |Node_1|--(msg1|msg2|msg3)-->|Attacker|--(msg1|msg3)-->|Node_2| | |||
| Figure 2: Selective Forwarding | Figure 2: Selective forwarding example | |||
| o Wormhole attacks; | o Wormhole attacks; | |||
| |Node_1|-------------Unreachable---------x|Node_2| | |Node_1|-------------Unreachable---------x|Node_2| | |||
| | ^ | | ^ | |||
| | Private Link | | | Private Link | | |||
| '-->|Attacker_1|===========>|Attacker_2|--' | '-->|Attacker_1|===========>|Attacker_2|--' | |||
| Figure 3: Wormhole Attacks | Figure 3: Wormhole Attacks | |||
| o Sinkhole attacks. | o Sinkhole attacks. | |||
| |Node_1| |Node_4| | |Node_1| |Node_4| | |||
| skipping to change at page 18, line 21 ¶ | skipping to change at page 18, line 29 ¶ | |||
| \ V V | \ V V | |||
| |Node_2|-->|Attacker|--Not Forwarded---x|Node_5| | |Node_2|-->|Attacker|--Not Forwarded---x|Node_5| | |||
| ^ ^ \ | ^ ^ \ | |||
| | | \ Falsify as | | | \ Falsify as | |||
| | | \Good Link | | | \Good Link | |||
| / | To Node_5 | / | To Node_5 | |||
| ,-------' | | ,-------' | | |||
| | | | | | | |||
| |Node_3| |Node_i| | |Node_3| |Node_i| | |||
| Figure 4: Selective Forwarding, Wormhole, and Sinkhole Attacks | Figure 4: sinkhole attack example | |||
| These attacks are generally done to both control plane and forwarding | These attacks are generally done to both control plane and forwarding | |||
| plane traffic. A system that prevents control plane traffic (RPL | plane traffic. A system that prevents control plane traffic (RPL | |||
| messages) from being diverted in these ways will also prevent actual | messages) from being diverted in these ways will also prevent actual | |||
| data from being diverted. | data from being diverted. | |||
| 5.4.3. Communications Resource Disruption | 6.4.3. Communications Resource Disruption | |||
| Attacks mounted against the communication channel resource assets | Attacks mounted against the communication channel resource assets | |||
| needed by the routing protocol can be used as a means of disrupting | needed by the routing protocol can be used as a means of disrupting | |||
| its operation. However, while various forms of Denial of Service | its operation. However, while various forms of Denial of Service | |||
| (DoS) attacks on the underlying transport subsystem will affect | (DoS) attacks on the underlying transport subsystem will affect | |||
| routing protocol exchanges and operation (for example physical layer | routing protocol exchanges and operation (for example physical layer | |||
| RF jamming in a wireless network or link layer attacks), these | RF jamming in a wireless network or link layer attacks), these | |||
| attacks cannot be countered by the routing protocol. As such, the | attacks cannot be countered by the routing protocol. As such, the | |||
| threats to the underlying transport network that supports routing is | threats to the underlying transport network that supports routing is | |||
| considered beyond the scope of the current document. Nonetheless, | considered beyond the scope of the current document. Nonetheless, | |||
| attacks on the subsystem will affect routing operation and so must be | attacks on the subsystem will affect routing operation and so must be | |||
| directly addressed within the underlying subsystem and its | directly addressed within the underlying subsystem and its | |||
| implemented protocol layers. | implemented protocol layers. | |||
| 5.4.4. Node Resource Exhaustion | 6.4.4. Node Resource Exhaustion | |||
| A potential threat consequence can arise from attempts to overload | A potential threat consequence can arise from attempts to overload | |||
| the node resource asset by initiating exchanges that can lead to the | the node resource asset by initiating exchanges that can lead to the | |||
| exhaustion of processing, memory, or energy resources. The | exhaustion of processing, memory, or energy resources. The | |||
| establishment and maintenance of routing neighbors opens the routing | establishment and maintenance of routing neighbors opens the routing | |||
| process to engagement and potential acceptance of multiple | process to engagement and potential acceptance of multiple | |||
| neighboring peers. Association information must be stored for each | neighboring peers. Association information must be stored for each | |||
| peer entity and for the wireless network operation provisions made to | peer entity and for the wireless network operation provisions made to | |||
| periodically update and reassess the associations. An introduced | periodically update and reassess the associations. An introduced | |||
| proliferation of apparent routing peers can therefore have a negative | proliferation of apparent routing peers can therefore have a negative | |||
| skipping to change at page 19, line 17 ¶ | skipping to change at page 19, line 39 ¶ | |||
| Node resources may also be unduly consumed by attackers attempting | Node resources may also be unduly consumed by attackers attempting | |||
| uncontrolled topology peering or routing exchanges, routing replays, | uncontrolled topology peering or routing exchanges, routing replays, | |||
| or the generating of other data traffic floods. Beyond the | or the generating of other data traffic floods. Beyond the | |||
| disruption of communications channel resources, these consequences | disruption of communications channel resources, these consequences | |||
| may be able to exhaust node resources only where the engagements are | may be able to exhaust node resources only where the engagements are | |||
| able to proceed with the peer routing entities. Routing operation | able to proceed with the peer routing entities. Routing operation | |||
| and network forwarding functions can thus be adversely impacted by | and network forwarding functions can thus be adversely impacted by | |||
| node resources exhaustion that stems from attacks that include: | node resources exhaustion that stems from attacks that include: | |||
| o Identity (including Sybil) attacks; | o Identity (including Sybil) attacks (see [Sybil2002]); | |||
| o Routing information replay attacks; | o Routing information replay attacks; | |||
| o HELLO-type flood attacks; | o HELLO-type flood attacks; | |||
| o Overload attacks. (Section 6.3.2) | o Overload attacks. (Section 7.3.2) | |||
| 6. Countermeasures | 7. Countermeasures | |||
| By recognizing the characteristics of LLNs that may impact routing, | By recognizing the characteristics of LLNs that may impact routing, | |||
| this analysis provides the basis for understanding the capabilities | this analysis provides the basis for understanding the capabilities | |||
| within RPL used to deter the identified attacks and mitigate the | within RPL used to deter the identified attacks and mitigate the | |||
| threats. The following subsections consider such countermeasures by | threats. The following subsections consider such countermeasures by | |||
| grouping the attacks according to the classification of the ISO | grouping the attacks according to the classification of the ISO | |||
| 7498-2 model so that associations with the necessary security | 7498-2 model so that associations with the necessary security | |||
| services are more readily visible. | services are more readily visible. | |||
| 6.1. Confidentiality Attack Countermeasures | 7.1. Confidentiality Attack Countermeasures | |||
| Attacks to disclosure routing information may be mounted at the level | Attacks to disclosure routing information may be mounted at the level | |||
| of the routing information assets, at the points of access associated | of the routing information assets, at the points of access associated | |||
| with routing exchanges between nodes, or through device interface | with routing exchanges between nodes, or through device interface | |||
| access. To gain access to routing/topology information, the attacker | access. To gain access to routing/topology information, the attacker | |||
| may rely on a compromised node that deliberately exposes the | may rely on a compromised node that deliberately exposes the | |||
| information during the routing exchange process, may rely on passive | information during the routing exchange process, may rely on passive | |||
| wiretapping or traffic analysis, or may attempt access through a | wiretapping or traffic analysis, or may attempt access through a | |||
| component or device interface of a tampered routing node. | component or device interface of a tampered routing node. | |||
| 6.1.1. Countering Deliberate Exposure Attacks | 7.1.1. Countering Deliberate Exposure Attacks | |||
| A deliberate exposure attack is one in which an entity that is party | A deliberate exposure attack is one in which an entity that is party | |||
| to the routing process or topology exchange allows the routing/ | to the routing process or topology exchange allows the routing/ | |||
| topology information or generated route information to be exposed to | topology information or generated route information to be exposed to | |||
| an unauthorized entity. | an unauthorized entity. | |||
| For instance, due to mis-configuration or inappropriate enabling of a | For instance, due to mis-configuration or inappropriate enabling of a | |||
| diagnostic interface, an entity might be copying ("bridging") traffic | diagnostic interface, an entity might be copying ("bridging") traffic | |||
| from a secured ESSID/PAN to an unsecured interface. | from a secured ESSID/PAN to an unsecured interface. | |||
| A prerequisite to countering this attack is to ensure that the | A prerequisite to countering this attack is to ensure that the | |||
| communicating nodes are authenticated prior to data encryption | communicating nodes are authenticated prior to data encryption | |||
| applied in the routing exchange. Authentication ensures that the | applied in the routing exchange. Authentication ensures that the | |||
| nodes are who they claim to be even though it does not provide an | nodes are who they claim to be even though it does not provide an | |||
| indication of whether the node has been compromised. | indication of whether the node has been compromised. | |||
| To mitigate the risk of deliberate exposure, the process that | To mitigate the risk of deliberate exposure, the process that | |||
| communicating nodes use to establish session keys must be peer-to- | communicating nodes use to establish session keys must be peer-to- | |||
| peer (i.e., between the routing initiating and responding nodes). | peer (i.e., between the routing initiating and responding nodes). | |||
| This helps ensure that neither node is exchaning routing information | This helps ensure that neither node is exchanging routing information | |||
| with another peer without the knowledge of both communicating peers. | with another peer without the knowledge of both communicating peers. | |||
| For a deliberate exposure attack to succeed, the comprised node will | For a deliberate exposure attack to succeed, the comprised node will | |||
| need to be more overt and take independent actions in order to | need to be more overt and take independent actions in order to | |||
| disclose the routing information to 3rd party. | disclose the routing information to 3rd party. | |||
| Note that the same measures which apply to securing routing/topology | Note that the same measures which apply to securing routing/topology | |||
| exchanges between operational nodes must also extend to field tools | exchanges between operational nodes must also extend to field tools | |||
| and other devices used in a deployed network where such devices can | and other devices used in a deployed network where such devices can | |||
| be configured to participate in routing exchanges. | be configured to participate in routing exchanges. | |||
| 6.1.2. Countering Passive Wiretapping Attacks | 7.1.2. Countering Passive Wiretapping Attacks | |||
| A passive wiretap attack seeks to breach routing confidentiality | A passive wiretap attack seeks to breach routing confidentiality | |||
| through passive, direct analysis and processing of the information | through passive, direct analysis and processing of the information | |||
| exchanges between nodes. | exchanges between nodes. | |||
| Passive wiretap attacks can be directly countered through the use of | Passive wiretap attacks can be directly countered through the use of | |||
| data encryption for all routing exchanges. Only when a validated and | data encryption for all routing exchanges. Only when a validated and | |||
| authenticated node association is completed will routing exchange be | authenticated node association is completed will routing exchange be | |||
| allowed to proceed using established session keys and an agreed | allowed to proceed using established session keys and an agreed | |||
| encryption algorithm. The mandatory to implement CCM mode AES-128 | encryption algorithm. The mandatory to implement CCM mode AES-128 | |||
| method, is described in [RFC3610], and is believed to be secure | 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-equiped adversary. | |||
| The significant challenge for RPL is in the provisioning of the key, | The significant challenge for RPL is in the provisioning of the key, | |||
| which in some modes of RFC6550 is used network-wide. RFC6550 does | which in some modes of RFC6550 is used network-wide. RFC6550 does | |||
| not solve this problem, and it is the subject of significant future | not solve this problem, and it is the subject of significant future | |||
| work: see, for instance: [AceCharterProposal], [SolaceProposal], | work: see, for instance: [AceCharterProposal], [SolaceProposal], | |||
| [SmartObjectSecurityWorkshop]. | [SmartObjectSecurityWorkshop]. | |||
| A number of deployments, such as [ZigBeeIP] specify no layer-3/RPL | A number of deployments, such as [ZigBeeIP] specify no layer-3/RPL | |||
| encryption or authentication and rely upon similiar security at | encryption or authentication and rely upon similiar security at | |||
| layer-2. These networks are immune to outside wiretapping attacks, | layer-2. These networks are immune to outside wiretapping attacks, | |||
| but are particularly vulnerable to passive (and active) attacks | but are particularly vulnerable to passive (and active) attacks | |||
| through compromises of nodes. | through compromises of nodes. | |||
| Section 10.9 of [RFC6550] specifies AES-128 in CCM mode with a 32-bit | Section 10.9 of [RFC6550] specifies AES-128 in CCM mode with a 32-bit | |||
| MAC. | MAC. | |||
| Section 5.6 Zigbee IP [ZigBeeIP] specifies use of CCM, with PANA and | Section 5.6 Zigbee IP [ZigBeeIP] specifies use of CCM, with PANA and | |||
| EAP-TLS for key management. | EAP-TLS for key management. | |||
| 6.1.3. Countering Traffic Analysis | 7.1.3. Countering Traffic Analysis | |||
| Traffic analysis provides an indirect means of subverting | Traffic analysis provides an indirect means of subverting | |||
| confidentiality and gaining access to routing information by allowing | confidentiality and gaining access to routing information by allowing | |||
| an attacker to indirectly map the connectivity or flow patterns | an attacker to indirectly map the connectivity or flow patterns | |||
| (including link-load) of the network from which other attacks can be | (including link-load) of the network from which other attacks can be | |||
| mounted. The traffic analysis attack on an LLN, especially one | mounted. The traffic analysis attack on an LLN, especially one | |||
| founded on shared medium, is passive and relies on the ability to | founded on shared medium, is passive and relies on the ability to | |||
| read the immutable source/destination layer-2 and/or layer-3 routing | read the immutable source/destination layer-2 and/or layer-3 routing | |||
| information that must remain unencrypted to permit network routing. | information that must remain unencrypted to permit network routing. | |||
| skipping to change at page 22, line 5 ¶ | skipping to change at page 22, line 30 ¶ | |||
| destinations through the generation of arbitrary traffic flows; the | destinations through the generation of arbitrary traffic flows; the | |||
| drawback of course would be the consequent overhead and energy | drawback of course would be the consequent overhead and energy | |||
| expenditure. | expenditure. | |||
| The only means of fully countering a traffic analysis attack is | The only means of fully countering a traffic analysis attack is | |||
| through the use of tunneling (encapsulation) where encryption is | through the use of tunneling (encapsulation) where encryption is | |||
| applied across the entirety of the original packet source/destination | applied across the entirety of the original packet source/destination | |||
| addresses. Deployments which use layer-2 security that includes | addresses. Deployments which use layer-2 security that includes | |||
| encryption already do this for all traffic. | encryption already do this for all traffic. | |||
| 6.1.4. Countering Remote Device Access Attacks | 7.1.4. Countering Remote Device Access Attacks | |||
| Where LLN nodes are deployed in the field, measures are introduced to | Where LLN nodes are deployed in the field, measures are introduced to | |||
| allow for remote retrieval of routing data and for software or field | allow for remote retrieval of routing data and for software or field | |||
| upgrades. These paths create the potential for a device to be | upgrades. These paths create the potential for a device to be | |||
| remotely accessed across the network or through a provided field | remotely accessed across the network or through a provided field | |||
| tool. In the case of network management a node can be directly | tool. In the case of network management a node can be directly | |||
| requested to provide routing tables and neighbor information. | requested to provide routing tables and neighbor information. | |||
| To ensure confidentiality of the node routing information against | To ensure confidentiality of the node routing information against | |||
| attacks through remote access, any local or remote device requesting | attacks through remote access, any local or remote device requesting | |||
| routing information must be authenticated, and must be authorized for | routing information must be authenticated, and must be authorized for | |||
| that access. Since remote access is not invoked as part of a routing | that access. Since remote access is not invoked as part of a routing | |||
| protocol security of routing information stored on the node against | protocol, security of routing information stored on the node against | |||
| remote access will not be addressable as part of the routing | remote access will not be addressable as part of the routing | |||
| protocol. | protocol. | |||
| 6.2. Integrity Attack Countermeasures | 7.2. Integrity Attack Countermeasures | |||
| Integrity attack countermeasures address routing information | Integrity attack countermeasures address routing information | |||
| manipulation, as well as node identity and routing information | manipulation, as well as node identity and routing information | |||
| misuse. Manipulation can occur in the form of falsification attack | misuse. Manipulation can occur in the form of falsification attack | |||
| and physical compromise. To be effective, the following development | and physical compromise. To be effective, the following development | |||
| considers the two aspects of falsification, namely, the unauthorized | considers the two aspects of falsification, namely, the unauthorized | |||
| modifications and the overclaiming and misclaiming content. The | modifications and the overclaiming and misclaiming content. The | |||
| countering of physical compromise was considered in the previous | countering of physical compromise was considered in the previous | |||
| section and is not repeated here. With regard to misuse, there are | section and is not repeated here. With regard to misuse, there are | |||
| two types of attacks to be deterred, identity attacks and replay | two types of attacks to be deterred, identity attacks and replay | |||
| attacks. | attacks. | |||
| 6.2.1. Countering Unauthorized Modification Attacks | 7.2.1. Countering Unauthorized Modification Attacks | |||
| Unauthorized modifications may occur in the form of altering the | Unauthorized modifications may occur in the form of altering the | |||
| message being transferred or the data stored. Therefore, it is | message being transferred or the data stored. Therefore, it is | |||
| necessary to ensure that only authorized nodes can change the portion | necessary to ensure that only authorized nodes can change the portion | |||
| of the information that is allowed to be mutable, while the integrity | of the information that is allowed to be mutable, while the integrity | |||
| of the rest of the information is protected, e.g., through well- | of the rest of the information is protected, e.g., through well- | |||
| studied cryptographic mechanisms. | studied cryptographic mechanisms. | |||
| Unauthorized modifications may also occur in the form of insertion or | Unauthorized modifications may also occur in the form of insertion or | |||
| deletion of messages during protocol changes. Therefore, the | deletion of messages during protocol changes. Therefore, the | |||
| skipping to change at page 23, line 4 ¶ | skipping to change at page 23, line 28 ¶ | |||
| studied cryptographic mechanisms. | studied cryptographic mechanisms. | |||
| Unauthorized modifications may also occur in the form of insertion or | Unauthorized modifications may also occur in the form of insertion or | |||
| deletion of messages during protocol changes. Therefore, the | deletion of messages during protocol changes. Therefore, the | |||
| protocol needs to ensure the integrity of the sequence of the | protocol needs to ensure the integrity of the sequence of the | |||
| exchange sequence. | exchange sequence. | |||
| The countermeasure to unauthorized modifications needs to: | The countermeasure to unauthorized modifications needs to: | |||
| o implement access control on storage; | o implement access control on storage; | |||
| o provide data integrity service to transferred messages and stored | o provide data integrity service to transferred messages and stored | |||
| data; | data; | |||
| o include sequence number under integrity protection. | o include sequence number under integrity protection. | |||
| 6.2.2. Countering Overclaiming and Misclaiming Attacks | 7.2.2. Countering Overclaiming and Misclaiming Attacks | |||
| Both overclaiming and misclaiming aim to introduce false routes or | Both overclaiming and misclaiming aim to introduce false routes or a | |||
| topology that would not be generated by the network otherwise, while | false topology that would not occur otherwise, while there are not | |||
| there are not necessarily unauthorized modifications to the routing | necessarily unauthorized modifications to the routing messages or | |||
| messages or information. In order to counter overclaiming, the | information. In order to counter overclaiming, the capability to | |||
| capability to determine unreasonable routes or topology is required. | determine unreasonable routes or topology is required. | |||
| The counter to overclaiming and misclaiming may employ: | The counter to overclaiming and misclaiming may employ: | |||
| o comparison with historical routing/topology data; | o comparison with historical routing/topology data; | |||
| o designs which restrict realizable network topologies. | o designs which restrict realizable network topologies. | |||
| RPL includes no specific mechanisms in the protocol to counter | RPL includes no specific mechanisms in the protocol to counter | |||
| overlaims. An implementation could have specific heuristics | overclaims or misclaims. An implementation could have specific | |||
| implemented locally. | heuristics implemented locally. | |||
| 6.2.3. Countering Identity (including Sybil) Attacks | 7.2.3. Countering Identity (including Sybil) Attacks | |||
| Identity attacks, sometimes simply called spoofing, seek to gain or | Identity attacks, sometimes simply called spoofing, seek to gain or | |||
| damage assets whose access is controlled through identity. In | damage assets whose access is controlled through identity. In | |||
| routing, an identity attacker can illegitimately participate in | routing, an identity attacker can illegitimately participate in | |||
| routing exchanges, distribute false routing information, or cause an | routing exchanges, distribute false routing information, or cause an | |||
| invalid outcome of a routing process. | invalid outcome of a routing process. | |||
| A perpetrator of Sybil attacks assumes multiple identities. The | A perpetrator of Sybil attacks assumes multiple identities. The | |||
| result is not only an amplification of the damage to routing, but | result is not only an amplification of the damage to routing, but | |||
| extension to new areas, e.g., where geographic distribution is | extension to new areas, e.g., where geographic distribution is | |||
| explicitly or implicitly an asset to an application running on the | explicitly or implicitly an asset to an application running on the | |||
| LLN, for example, the LBR in a P2MP or MP2P LLN. | LLN, for example, the LBR in a P2MP or MP2P LLN. | |||
| RPL includes specific public key based authentication at layer-3 that | RPL includes specific public key based authentication at layer-3 that | |||
| provide for authorization. Many deployments use layer-2 security | provide for authorization. Many deployments use layer-2 security | |||
| that includes admission controls at layer-2 using mechanisms such as | that includes admission controls at layer-2 using mechanisms such as | |||
| PANA. | PANA. | |||
| 6.2.4. Countering Routing Information Replay Attacks | 7.2.4. Countering Routing Information Replay Attacks | |||
| In many routing protocols, message replay can result in false | In many routing protocols, message replay can result in false | |||
| topology and/or routes. This is often counted with some kind of | topology and/or routes. This is often counted with some kind of | |||
| counter to ensure the freshness of the message. Replay of a current, | counter to ensure the freshness of the message. Replay of a current, | |||
| literal RPL message are in general idempotent to the topology. An | literal RPL message are in general idempotent to the topology. An | |||
| older (lower DODAGVersionNumber) message, if replayed would be | older (lower DODAGVersionNumber) message, if replayed would be | |||
| rejected as being stale. The trickle algorithm further dampens the | rejected as being stale. The trickle algorithm further dampens the | |||
| affect of any such replay, as if the message was current, then it | effect of any such replay, as if the message was current, then it | |||
| would contain the same information as before, and it would cause no | would contain the same information as before, and it would cause no | |||
| network changes. | network changes. | |||
| Replays may well occur in some radio technologies (not very likely, | Replays may well occur in some radio technologies (not very likely, | |||
| 802.15.4) as a result of echos or reflections, and so some replays | 802.15.4) as a result of echos or reflections, and so some replays | |||
| must be assumed to occur naturally. | must be assumed to occur naturally. | |||
| Note that for there to be no affect at all, the replay must be done | Note that for there to be no affect at all, the replay must be done | |||
| with the same apparent power for all nodes receiving the replay. A | with the same apparent power for all nodes receiving the replay. A | |||
| change in apparent power might change the metrics through changes to | change in apparent power might change the metrics through changes to | |||
| the ETX and therefore might affect the routing even though the | the ETX and therefore might affect the routing even though the | |||
| contents of the packet were never changed. Any replay which appears | contents of the packet were never changed. Any replay which appears | |||
| to be different should be analyzed as a Selective Forwarding Attack, | to be different should be analyzed as a Selective Forwarding Attack, | |||
| Sinkhole Attack or Wormhole Attack. | Sinkhole Attack or Wormhole Attack. | |||
| 6.2.5. Countering Byzantine Routing Information Attacks | 7.2.5. Countering Byzantine Routing Information Attacks | |||
| Where a node is captured or compromised but continues to operate for | Where a node is captured or compromised but continues to operate for | |||
| a period with valid network security credentials, the potential | a period with valid network security credentials, the potential | |||
| exists for routing information to be manipulated. This compromise of | exists for routing information to be manipulated. This compromise of | |||
| the routing information could thus exist in spite of security | the routing information could thus exist in spite of security | |||
| countermeasures that operate between the peer routing devices. | countermeasures that operate between the peer routing devices. | |||
| Consistent with the end-to-end principle of communications, such an | Consistent with the end-to-end principle of communications, such an | |||
| attack can only be fully addressed through measures operating | attack can only be fully addressed through measures operating | |||
| directly between the routing entities themselves or by means of | directly between the routing entities themselves or by means of | |||
| skipping to change at page 25, line 15 ¶ | skipping to change at page 25, line 46 ¶ | |||
| performing routing information validation. S-RIP [Wan2004] is an | performing routing information validation. S-RIP [Wan2004] is an | |||
| example of the implementation of this type of dedicated routing | example of the implementation of this type of dedicated routing | |||
| protocol security where the correctness of aggregate distance vector | protocol security where the correctness of aggregate distance vector | |||
| information can only be validated by initiating confirmation | information can only be validated by initiating confirmation | |||
| exchanges directly between nodes that are not routing neighbors. | exchanges directly between nodes that are not routing neighbors. | |||
| RPL does not provide any direct mechanisms like S-RIP. It does | RPL does not provide any direct mechanisms like S-RIP. It does | |||
| listen to multiple parents, and may switch parents if it begins to | listen to multiple parents, and may switch parents if it begins to | |||
| suspect that it is being lied to. | suspect that it is being lied to. | |||
| 6.3. Availability Attack Countermeasures | 7.3. Availability Attack Countermeasures | |||
| As alluded to before, availability requires that routing information | As alluded to before, availability requires that routing information | |||
| exchanges and forwarding mechanisms be available when needed so as to | exchanges and forwarding mechanisms be available when needed so as to | |||
| guarantee proper functioning of the network. This may, e.g., include | guarantee proper functioning of the network. This may, e.g., include | |||
| the correct operation of routing information and neighbor state | the correct operation of routing information and neighbor state | |||
| information exchanges, among others. We will highlight the key | information exchanges, among others. We will highlight the key | |||
| features of the security threats along with typical countermeasures | features of the security threats along with typical countermeasures | |||
| to prevent or at least mitigate them. We will also note that an | to prevent or at least mitigate them. We will also note that an | |||
| availability attack may be facilitated by an identity attack as well | availability attack may be facilitated by an identity attack as well | |||
| as a replay attack, as was addressed in Section 6.2.3 and | as a replay attack, as was addressed in Section 7.2.3 and | |||
| Section 6.2.4, respectively. | Section 7.2.4, respectively. | |||
| 6.3.1. Countering HELLO Flood Attacks and ACK Spoofing Attacks | 7.3.1. Countering HELLO Flood Attacks and ACK Spoofing Attacks | |||
| HELLO Flood [Karlof2003],[I-D.suhopark-hello-wsn] and ACK Spoofing | HELLO Flood [Karlof2003],[I-D.suhopark-hello-wsn] and ACK Spoofing | |||
| attacks are different but highly related forms of attacking an LLN. | attacks are different but highly related forms of attacking an LLN. | |||
| They essentially lead nodes to believe that suitable routes are | They essentially lead nodes to believe that suitable routes are | |||
| available even though they are not and hence constitute a serious | available even though they are not and hence constitute a serious | |||
| availability attack. | availability attack. | |||
| A HELLO attack mounted against RPL would involve sending out (or | A HELLO attack mounted against RPL would involve sending out (or | |||
| replaying) DIO messages by the attacker. Lower power LLN nodes might | replaying) DIO messages by the attacker. Lower power LLN nodes might | |||
| then attempt to join the DODAG at a lower rank than they would | then attempt to join the DODAG at a lower rank than they would | |||
| skipping to change at page 26, line 11 ¶ | skipping to change at page 26, line 39 ¶ | |||
| and this involves, in general, sending a number of messages between | and this involves, in general, sending a number of messages between | |||
| nodes which are believed to be adjacent. | nodes which are believed to be adjacent. | |||
| [I-D.kelsey-intarea-mesh-link-establishment] is one such protocol. | [I-D.kelsey-intarea-mesh-link-establishment] is one such protocol. | |||
| In order to join the DODAG, a DAO message is sent upwards. In RPL | In order to join the DODAG, a DAO message is sent upwards. In RPL | |||
| the DAO is acknowledged by the DAO-ACK message. This clearly checks | the DAO is acknowledged by the DAO-ACK message. This clearly checks | |||
| bidirectionality at the control plane. | bidirectionality at the control plane. | |||
| As discussed in section 5.1, [I-D.suhopark-hello-wsn] a receiver with | As discussed in section 5.1, [I-D.suhopark-hello-wsn] a receiver with | |||
| a sensitive receiver could well hear the DAOs, and even send DAO-ACKs | a sensitive receiver could well hear the DAOs, and even send DAO-ACKs | |||
| as well. Such a node is a form of WormHole attack. | as well. Such a node is a form of wormhole attack. | |||
| These attacks are also all easily defended against using either | These attacks are also all easily defended against using either | |||
| layer-2 or layer-3 authentication. Such an attack could only be made | layer-2 or layer-3 authentication. Such an attack could only be made | |||
| against a completely open network (such as might be used for | against a completely open network (such as might be used for | |||
| provisioning new nodes), or by a compromised node. | provisioning new nodes), or by a compromised node. | |||
| 6.3.2. Countering Overload Attacks | 7.3.2. Countering Overload Attacks | |||
| Overload attacks are a form of DoS attack in that a malicious node | Overload attacks are a form of DoS attack in that a malicious node | |||
| overloads the network with irrelevant traffic, thereby draining the | overloads the network with irrelevant traffic, thereby draining the | |||
| nodes' energy store more quickly, when the nodes rely on batteries or | nodes' energy store more quickly, when the nodes rely on batteries or | |||
| energy scavenging. It thus significantly shortens the lifetime of | energy scavenging. It thus significantly shortens the lifetime of | |||
| networks of energy-constrained nodes and constitutes another serious | networks of energy-constrained nodes and constitutes another serious | |||
| availability attack. | availability attack. | |||
| With energy being one of the most precious assets of LLNs, targeting | With energy being one of the most precious assets of LLNs, targeting | |||
| its availability is a fairly obvious attack. Another way of | its availability is a fairly obvious attack. Another way of | |||
| skipping to change at page 27, line 27 ¶ | skipping to change at page 28, line 16 ¶ | |||
| encrypt messages need to be cautious of cryptographic processing | encrypt messages need to be cautious of cryptographic processing | |||
| usage when validating signatures and encrypting messages. Where | usage when validating signatures and encrypting messages. Where | |||
| feasible, certificates should be validated prior to use of the | feasible, certificates should be validated prior to use of the | |||
| associated keys to counter potential resource overloading attacks. | associated keys to counter potential resource overloading attacks. | |||
| The associated design decision needs to also consider that the | The associated design decision needs to also consider that the | |||
| validation process requires resources and thus itself could be | validation process requires resources and thus itself could be | |||
| exploited for attacks. Alternatively, resource management limits can | exploited for attacks. Alternatively, resource management limits can | |||
| be placed on routing security processing events (see the comment in | be placed on routing security processing events (see the comment in | |||
| Section 6, paragraph 4, of [RFC5751]). | Section 6, paragraph 4, of [RFC5751]). | |||
| 6.3.3. Countering Selective Forwarding Attacks | 7.3.3. Countering Selective Forwarding Attacks | |||
| Selective forwarding attacks are a form of DoS attack which impacts | Selective forwarding attacks are a form of DoS attack which impacts | |||
| the availability of the generated routing paths. | the availability of the generated routing paths. | |||
| A selective forwarding attack may be done by a node involved with the | A selective forwarding attack may be done by a node involved with the | |||
| routing process, or it may be done by what otherwise appears to be a | routing process, or it may be done by what otherwise appears to be a | |||
| passive antenna or other RF feature or device, but is in fact an | passive antenna or other RF feature or device, but is in fact an | |||
| active (and selective) device. An RF antenna/repeater which is not | active (and selective) device. An RF antenna/repeater which is not | |||
| selective, is not a threat. | selective, is not a threat. | |||
| skipping to change at page 28, line 4 ¶ | skipping to change at page 28, line 41 ¶ | |||
| if coupled with sinkhole attacks since inherently a large amount of | if coupled with sinkhole attacks since inherently a large amount of | |||
| traffic is attracted to the malicious node and thereby causing | traffic is attracted to the malicious node and thereby causing | |||
| significant damage. In a shared medium, an outside malicious node | significant damage. In a shared medium, an outside malicious node | |||
| would selectively jam overheard data flows, where the thus caused | would selectively jam overheard data flows, where the thus caused | |||
| collisions incur selective forwarding. | collisions incur selective forwarding. | |||
| Selective Forwarding attacks can be countered by deploying a series | Selective Forwarding attacks can be countered by deploying a series | |||
| of mutually non-exclusive security measures: | of mutually non-exclusive security measures: | |||
| o multipath routing of the same message over disjoint paths; | o multipath routing of the same message over disjoint paths; | |||
| o dynamically selecting the next hop from a set of candidates. | o dynamically selecting the next hop from a set of candidates. | |||
| The first measure basically guarantees that if a message gets lost on | The first measure basically guarantees that if a message gets lost on | |||
| a particular routing path due to a malicious selective forwarding | a particular routing path due to a malicious selective forwarding | |||
| attack, there will be another route which successfully delivers the | attack, there will be another route which successfully delivers the | |||
| data. Such a method is inherently suboptimal from an energy | data. Such a method is inherently suboptimal from an energy | |||
| consumption point of view; it is also suboptimal from a network | consumption point of view; it is also suboptimal from a network | |||
| utilization perspective. The second method basically involves a | utilization perspective. The second method basically involves a | |||
| constantly changing routing topology in that next-hop routers are | constantly changing routing topology in that next-hop routers are | |||
| chosen from a dynamic set in the hope that the number of malicious | chosen from a dynamic set in the hope that the number of malicious | |||
| nodes in this set is negligible. A routing protocol that allows for | nodes in this set is negligible. A routing protocol that allows for | |||
| disjoint routing paths may also be useful. | disjoint routing paths may also be useful. | |||
| 6.3.4. Countering Sinkhole Attacks | 7.3.4. Countering Sinkhole Attacks | |||
| In sinkhole attacks, the malicious node manages to attract a lot of | In sinkhole attacks, the malicious node manages to attract a lot of | |||
| traffic mainly by advertising the availability of high-quality links | traffic mainly by advertising the availability of high-quality links | |||
| even though there are none [Karlof2003]. It hence constitutes a | even though there are none [Karlof2003]. It hence constitutes a | |||
| serious attack on availability. | serious attack on availability. | |||
| The malicious node creates a sinkhole by attracting a large amount | The malicious node creates a sinkhole by attracting a large amount | |||
| of, if not all, traffic from surrounding neighbors by advertising in | of, if not all, traffic from surrounding neighbors by advertising in | |||
| and outwards links of superior quality. Affected nodes hence eagerly | and outwards links of superior quality. Affected nodes hence eagerly | |||
| route their traffic via the malicious node which, if coupled with | route their traffic via the malicious node which, if coupled with | |||
| skipping to change at page 29, line 8 ¶ | skipping to change at page 30, line 11 ¶ | |||
| solving triangulation equations from radio delay calculations, such | solving triangulation equations from radio delay calculations, such | |||
| calculations could in theory be subverted by a sinkhole that | calculations could in theory be subverted by a sinkhole that | |||
| transmitted at precisely the right power in a node to node fashion. | transmitted at precisely the right power in a node to node fashion. | |||
| While geographic knowledge could help assure that traffic always went | While geographic knowledge could help assure that traffic always went | |||
| in the physical direction desired, it would not assure that the | in the physical direction desired, it would not assure that the | |||
| traffic was taking the most efficient route, as the lowest cost real | traffic was taking the most efficient route, as the lowest cost real | |||
| route might be match the physical topology; such as when different | route might be match the physical topology; such as when different | |||
| parts of an LLN are connected by high-speed wired networks. | parts of an LLN are connected by high-speed wired networks. | |||
| 6.3.5. Countering Wormhole Attacks | 7.3.5. Countering Wormhole Attacks | |||
| In wormhole attacks at least two malicious nodes claim to have a | In wormhole attacks at least two malicious nodes claim to have a | |||
| short path between themselves [Karlof2003]. This changes the | short path between themselves [Karlof2003]. This changes the | |||
| availability of certain routing paths and hence constitutes a serious | availability of certain routing paths and hence constitutes a serious | |||
| security breach. | security breach. | |||
| Essentially, two malicious insider nodes use another, more powerful, | Essentially, two malicious insider nodes use another, more powerful, | |||
| transmitter to communicate with each other and thereby distort the | transmitter to communicate with each other and thereby distort the | |||
| would-be-agreed routing path. This distortion could involve | would-be-agreed routing path. This distortion could involve | |||
| shortcutting and hence paralyzing a large part of the network; it | shortcutting and hence paralyzing a large part of the network; it | |||
| could also involve tunneling the information to another region of the | could also involve tunneling the information to another region of the | |||
| network where there are, e.g., more malicious nodes available to aid | network where there are, e.g., more malicious nodes available to aid | |||
| the intrusion or where messages are replayed, etc. | the intrusion or where messages are replayed, etc. | |||
| In conjunction with selective forwarding, wormhole attacks can create | In conjunction with selective forwarding, wormhole attacks can create | |||
| race conditions which impact topology maintenance, routing protocols | race conditions which impact topology maintenance, routing protocols | |||
| as well as any security suits built on "time of check" and "time of | as well as any security suits built on "time of check" and "time of | |||
| use". | use". | |||
| A pure Wormhole attack is nearly impossible to detect. A wormhole | A pure wormhole attack is nearly impossible to detect. A wormhole | |||
| which is used in order to subsequently mount another kind of attack | which is used in order to subsequently mount another kind of attack | |||
| would be defeated by defeating the other attack. A perfect wormhole, | would be defeated by defeating the other attack. A perfect wormhole, | |||
| in which there is nothing adverse that occurs to the traffic, would | in which there is nothing adverse that occurs to the traffic, would | |||
| be difficult to call an attack. The worst thing that a benign | 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 | wormhole can do in such a situation is to cease to operate (become | |||
| unstable), causing the network to have to recalculate routes. | unstable), causing the network to have to recalculate routes. | |||
| A highly unstable wormhole is no different than a radio opaque (i.e. | A highly unstable wormhole is no different than a radio opaque (i.e. | |||
| metal) door that opens and closes a lot. RPL includes hystersis in | metal) door that opens and closes a lot. RPL includes hysteresis in | |||
| its objective functions [RFC6719] in an attempt to deal with frequent | its objective functions [RFC6719] in an attempt to deal with frequent | |||
| changes to the ETX between nodes. | changes to the ETX between nodes. | |||
| 7. RPL Security Features | 8. RPL Security Features | |||
| The assessments and analysis in Section 6 examined all areas of | ||||
| The assessments and analysis in Section 5 examined all areas of | ||||
| threats and attacks that could impact routing, and the | threats and attacks that could impact routing, and the | |||
| countermeasures presented in Section 6 were reached without confining | countermeasures presented in Section 7 were reached without confining | |||
| the consideration to means only available to routing. This section | the consideration to means only available to routing. This section | |||
| puts the results into perspective and provides a framework for | puts the results into perspective; dealing with those threats which | |||
| addressing the derived set of security objectives that must be met by | are endemnic to this field, those which have been mitigated through | |||
| the routing protocol(s) specified by the RPL Working Group. It bears | RPL protocol design, and those which require specific decisions to be | |||
| emphasizing that the target here is a generic, universal form of the | made as part of provisioning a network. | |||
| protocol(s) specified and the normative keywords are mainly to convey | ||||
| the relative level of importance or urgency of the features | ||||
| specified. | ||||
| In this view, 'MUST' is used to define the requirements that are | The first part of this section, Section 8.1 to Section 8.3, is a | |||
| specific to the routing protocol and that are essential for an LLN | description of RPL security features that address specific threats. | |||
| routing protocol to ensure that routing operation can be maintained. | The second part of this section, Section 8.4, discusses issues of | |||
| Adherence to MUST requirements is needed to directly counter attacks | provisioning of security aspects that may impact routing but that | |||
| that can affect the routing operation (such as those that can impact | also require considerations beyond the routing protocol, as well as | |||
| maintained or derived routing/forwarding tables). 'SHOULD' is used | potential approaches. | |||
| to define requirements that counter indirect routing attacks where | ||||
| such attacks do not of themselves affect routing but can assist an | ||||
| attacker in focusing its attack resources to impact network operation | ||||
| (such as DoS targeting of key forwarding nodes). 'MAY' covers | ||||
| optional requirements that can further enhance security by increasing | ||||
| the space over which an attacker must operate or the resources that | ||||
| must be applied. While in support of routing security, where | ||||
| appropriate, these requirements may also be addressed beyond the | ||||
| network routing protocol at other system communications layers. | ||||
| The first part of this section, Section 7.1 to Section 7.3, is a | RPL employs multicast and so these alternative communications modes | |||
| prescription of RPL security features of measures that can be | MUST be secured with the same routing security services specified in | |||
| addressed as part of the routing protocol itself. As routing is one | this section. Furthermore, irrespective of the modes of | |||
| component of an LLN system, the actual strength of the security | communication, nodes MUST provide adequate physical tamper resistance | |||
| services afforded to it should be made to conform to each system's | commensurate with the particular application domain environment to | |||
| security policy; how a design may address the needs of the urban, | ensure the confidentiality, integrity, and availability of stored | |||
| industrial, home automation, and building automation application | routing information. | |||
| domains also needs to be considered. The second part of this | ||||
| section, Section 7.4 and Section 7.5, discusses system security | ||||
| aspects that may impact routing but that also require considerations | ||||
| beyond the routing protocol, as well as potential approaches. | ||||
| If an LLN employs multicast and/or anycast, these alternative | 8.1. Confidentiality Features | |||
| communications modes MUST be secured with the same routing security | ||||
| services specified in this section. Furthermore, irrespective of the | ||||
| modes of communication, nodes MUST provide adequate physical tamper | ||||
| resistance commensurate with the particular application domain | ||||
| environment to ensure the confidentiality, integrity, and | ||||
| availability of stored routing information. | ||||
| 7.1. Confidentiality Features | ||||
| With regard to confidentiality, protecting the routing/topology | With regard to confidentiality, protecting the routing/topology | |||
| information from unauthorized disclosure is not directly essential to | information from unauthorized disclosure is not directly essential to | |||
| maintaining the routing function. Breaches of confidentiality may | maintaining the routing function. Breaches of confidentiality may | |||
| lead to other attacks or the focusing of an attacker's resources (see | lead to other attacks or the focusing of an attacker's resources (see | |||
| Section 5.2) but does not of itself directly undermine the operation | Section 6.2) but does not of itself directly undermine the operation | |||
| of the routing function. However, to protect against, and reduce | of the routing function. However, to protect against, and reduce | |||
| consequences from other more direct attacks, routing information | consequences from other more direct attacks, routing information | |||
| should be protected. Thus, a secured RPL protocol: | should be protected. Thus, to secure RPL: | |||
| o MUST implement payload encryption; | ||||
| o MAY provide tunneling; | o implement payload encryption using layer-3 mechanisms described in | |||
| [RFC6550]; | ||||
| o MAY provide load balancing. | o or: implement layer-2 confidentiality; | |||
| Where confidentiality is incorporated into the routing exchanges, | Where confidentiality is incorporated into the routing exchanges, | |||
| encryption algorithms and key lengths need to be specified in | encryption algorithms and key lengths need to be specified in | |||
| accordance with the level of protection dictated by the routing | accordance with the level of protection dictated by the routing | |||
| protocol and the associated application domain transport network. In | protocol and the associated application domain transport network. | |||
| terms of the life time of the keys, the opportunity to periodically | For most networks, this means use of AES128 in CCM mode, but this | |||
| change the encryption key increases the offered level of security for | needs to be specified clearly in the applicability statement. | |||
| any given implementation. However, where strong cryptography is | ||||
| employed, physical, procedural, and logical data access protection | In terms of the life time of the keys, the opportunity to | |||
| considerations may have more significant impact on cryptoperiod | periodically change the encryption key increases the offered level of | |||
| selection than algorithm and key size factors. Nevertheless, in | security for any given implementation. However, where strong | |||
| general, shorter cryptoperiods, during which a single key is applied, | cryptography is employed, physical, procedural, and logical data | |||
| will enhance security. | access protection considerations may have more significant impact on | |||
| cryptoperiod selection than algorithm and key size factors. | ||||
| Nevertheless, in general, shorter cryptoperiods, during which a | ||||
| single key is applied, will enhance security. | ||||
| Given the mandatory protocol requirement to implement routing node | Given the mandatory protocol requirement to implement routing node | |||
| authentication as part of routing integrity (see Section 7.2), key | authentication as part of routing integrity (see Section 8.2), key | |||
| exchanges may be coordinated as part of the integrity verification | exchanges may be coordinated as part of the integrity verification | |||
| process. This provides an opportunity to increase the frequency of | process. This provides an opportunity to increase the frequency of | |||
| key exchange and shorten the cryptoperiod as a complement to the key | key exchange and shorten the cryptoperiod as a complement to the key | |||
| length and encryption algorithm required for a given application | length and encryption algorithm required for a given application | |||
| domain. For LLNs, the coordination of confidentiality key management | domain. | |||
| with the implementation of node device authentication can thus reduce | ||||
| the overhead associated with supporting data confidentiality. If a | ||||
| new ciphering key is concurrently generated or updated in conjunction | ||||
| with the mandatory authentication exchange occurring with each | ||||
| routing peer association, signaling exchange overhead can be reduced. | ||||
| 7.2. Integrity Features | 8.2. Integrity Features | |||
| The integrity of routing information provides the basis for ensuring | The integrity of routing information provides the basis for ensuring | |||
| that the function of the routing protocol is achieved and maintained. | that the function of the routing protocol is achieved and maintained. | |||
| To protect integrity, RPL must either run using only the Secure | To protect integrity, RPL must either run using only the Secure | |||
| versions of the messages, or must run over a layer-2 that uses | versions of the messages, or must run over a layer-2 that uses | |||
| channel binding between node identity and transmissions. (i.e.: a | channel binding between node identity and transmissions. | |||
| layer-2 which has an identical network-wide transmission key can not | ||||
| defend against many attacks) | ||||
| While logging is critical, it is often impossible. | Some layer-2 security mechanisms use a single key for the entire | |||
| network, and these networks can not provide significant amount of | ||||
| integrity protection, as any node that has that key may impersonate | ||||
| any other node. This mode of operation is likely acceptable when an | ||||
| entire deployment is under the control of a single administrative | ||||
| entity. | ||||
| 7.3. Availability Features | 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. | ||||
| 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. | ||||
| 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. | ||||
| 8.3. Availability Features | ||||
| Availability of routing information is linked to system and network | Availability of routing information is linked to system and network | |||
| availability which in the case of LLNs require a broader security | availability which in the case of LLNs require a broader security | |||
| view beyond the requirements of the routing entities (see | view beyond the requirements of the routing entities. Where | |||
| Section 7.5). Where availability of the network is compromised, | availability of the network is compromised, routing information | |||
| routing information availability will be accordingly affected. | availability will be accordingly affected. However, to specifically | |||
| However, to specifically assist in protecting routing availability: | assist in protecting routing availability: | |||
| o MAY restrict neighborhood cardinality; | o MAY restrict neighborhood cardinality; | |||
| o MAY use multiple paths; | o MAY use multiple paths; | |||
| o MAY use multiple destinations; | o MAY use multiple destinations; | |||
| o MAY choose randomly if multiple paths are available; | o MAY choose randomly if multiple paths are available; | |||
| o MAY set quotas to limit transmit or receive volume; | o MAY set quotas to limit transmit or receive volume; | |||
| o MAY use geographic information for flow control. | o MAY use geographic information for flow control. | |||
| 7.4. Key Management | 8.4. Key Management | |||
| The functioning of the routing security services requires keys and | The functioning of the routing security services requires keys and | |||
| credentials. Therefore, even though not directly a RPL security | credentials. Therefore, even though not directly a RPL security | |||
| requirement, an LLN MUST have a process for initial key and | requirement, an LLN MUST have a process for initial key and | |||
| credential configuration, as well as secure storage within the | credential configuration, as well as secure storage within the | |||
| associated devices. Anti-tampering SHOULD be a consideration in | associated devices. Anti-tampering SHOULD be a consideration in | |||
| physical design. Beyond initial credential configuration, an LLN is | physical design. Beyond initial credential configuration, an LLN is | |||
| also encouraged to have automatic procedures for the revocation and | also encouraged to have automatic procedures for the revocation and | |||
| replacement of the maintained security credentials. | replacement of the maintained security credentials. | |||
| While RPL has secure modes, but some modes are impractical without | While RPL has secure modes, but some modes are impractical without | |||
| use of public key cryptography believed to be too expensive by many. | use of public key cryptography believed to be too expensive by many. | |||
| RPL layer-3 security will often depend upon existing LLN layer-2 | RPL layer-3 security will often depend upon existing LLN layer-2 | |||
| security mechanisms, which provides for node authentication, but | security mechanisms, which provides for node authentication, but | |||
| little in the way of node authorization. | little in the way of node authorization. | |||
| 7.5. Consideration on Matching Application Domain Needs | 9. IANA Considerations | |||
| Providing security within an LLN requires considerations that extend | ||||
| beyond routing security to the broader LLN application domain | ||||
| security implementation. In other words, as routing is one component | ||||
| of an LLN system, the actual strength of the implemented security | ||||
| algorithms for the routing protocol MUST be made to conform to the | ||||
| system's target level of security. The development so far takes into | ||||
| account collectively the impacts of the issues gathered from | ||||
| [RFC5548], [RFC5673], [RFC5826], and [RFC5867]. The following two | ||||
| subsections first consider from an architectural perspective how the | ||||
| security design of a RPL protocol may be made to adapt to the four | ||||
| application domains, and then examine mechanisms and protocol | ||||
| operations issues. | ||||
| 7.5.1. Mechanisms and Operations | ||||
| Figure 5 provides an overview of the larger context of system | ||||
| security and the relationship between RPL requirements and measures | ||||
| and those that relate to the LLN system. | ||||
| Security Services for | ||||
| RPL-Addressable | ||||
| Security Requirements | ||||
| | | | ||||
| +---+ +---+ | ||||
| Node_i | | Node_j | ||||
| _____v___ ___v_____ | ||||
| Specify Security / \ / \ Specify Security | ||||
| Requirements | Routing | | Routing | Requirements | ||||
| +---------| Protocol| | Protocol|---------+ | ||||
| | | Entity | | Entity | | | ||||
| | \_________/ \_________/ | | ||||
| | | | | | ||||
| |RPL-Specified | | RPL-Specified| | ||||
| ---Interface | | Interface--- | ||||
| | ...................................... | | ||||
| | : | | : | | ||||
| | : +-----+----+ +----+-----+ : | | ||||
| | : |Transport/| |Transport/| : | | ||||
| ____v___ : +>|Network | |Network |<+ : ___v____ | ||||
| / \ : | +-----+----+ +----+-----+ | : / \ | ||||
| | |-:-+ | | +-:-| | | ||||
| |Security| : +-----+----+ +----+-----+ : |Security| | ||||
| +->|Services|-:-->| Link | | Link |<--:-|Services|<-+ | ||||
| | |Entity | : +-----+----+ +----+-----+ : |Entity | | | ||||
| | | |-:-+ | | +-:-| | | | ||||
| | \________/ : | +-----+----+ +----+-----+ | : \________/ | | ||||
| | : +>| Physical | | Physical |<+ : | | ||||
| Application : +-----+----+ +----+-----+ : Application | ||||
| Domain User : | | : Domain User | ||||
| Configuration : |__Comm. Channel_| : Configuration | ||||
| : : | ||||
| ...Protocol Stack..................... | ||||
| Figure 5: LLN Device Security Model | ||||
| 8. IANA Considerations | ||||
| This memo includes no request to IANA. | This memo includes no request to IANA. | |||
| 9. Security Considerations | 10. Security Considerations | |||
| The analysis presented in this document provides security analysis | The analysis presented in this document provides security analysis | |||
| and design guidelines with a scope limited to RPL. Security services | and design guidelines with a scope limited to RPL. Security services | |||
| are identified as requirements for securing RPL. The specific | are identified as requirements for securing RPL. The specific | |||
| mechanisms to be used to deal with each threat is specified in link- | mechanisms to be used to deal with each threat is specified in link- | |||
| layer and deployment specific applicability statements. | layer and deployment specific applicability statements. | |||
| 10. Acknowledgments | 11. Acknowledgments | |||
| The authors would like to acknowledge the review and comments from | The authors would like to acknowledge the review and comments from | |||
| Rene Struik and JP Vasseur. The authors would also like to | Rene Struik and JP Vasseur. The authors would also like to | |||
| acknowledge the guidance and input provided by the RPL Chairs, David | acknowledge the guidance and input provided by the RPL Chairs, David | |||
| Culler, and JP Vasseur, and the Area Director Adrian Farrel. | Culler, and JP Vasseur, and the Area Director Adrian Farrel. | |||
| This document started out as a combined threat and solutions | This document started out as a combined threat and solutions | |||
| document. As a result of security review, the document was split up | document. As a result of security review, the document was split up | |||
| by RPL co-Chair Michael Richardson and security Area Director Sean | by RPL co-Chair Michael Richardson and security Area Director Sean | |||
| Turner as it went through the IETF publication process. The | Turner as it went through the IETF publication process. The | |||
| solutions to the threads are application and layer-2 specific, and | solutions to the threats are application and layer-2 specific, and | |||
| have therefore been moved to the relevant applicability statements. | have therefore been moved to the relevant applicability statements. | |||
| Ines Robles kept track of the many issues that were raised during the | Ines Robles and Robert Craigie kept track of the many issues that | |||
| development of this document | were raised during the development of this document | |||
| 11. References | 12. References | |||
| 11.1. Normative References | ||||
| 12.1. Normative References | ||||
| [I-D.ietf-roll-terminology] | [I-D.ietf-roll-terminology] | |||
| Vasseur, J., "Terminology in Low power And Lossy | Vasseur, J., "Terminology in Low power And Lossy | |||
| Networks", draft-ietf-roll-terminology-04 (work in | Networks", draft-ietf-roll-terminology-04 (work in | |||
| progress), September 2010. | progress), September 2010. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic | [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic | |||
| skipping to change at page 35, line 32 ¶ | skipping to change at page 35, line 17 ¶ | |||
| Alexander, "RPL: IPv6 Routing Protocol for Low-Power and | Alexander, "RPL: IPv6 Routing Protocol for Low-Power and | |||
| Lossy Networks", RFC 6550, March 2012. | Lossy Networks", RFC 6550, March 2012. | |||
| [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with | [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with | |||
| Hysteresis Objective Function", RFC 6719, September 2012. | Hysteresis Objective Function", RFC 6719, September 2012. | |||
| [ZigBeeIP] | [ZigBeeIP] | |||
| ZigBee Public Document 15-002r00, "ZigBee IP | ZigBee Public Document 15-002r00, "ZigBee IP | |||
| Specification", 2013. | Specification", 2013. | |||
| 11.2. Informative References | 12.2. Informative References | |||
| [AceCharterProposal] | [AceCharterProposal] | |||
| Kepeng, L., Ed., "Authentication and Authorization for | Li, Kepeng., Ed., "Authentication and Authorization for | |||
| Constrained Environment Charter (work-in-progress)", | Constrained Environment Charter (work-in-progress)", | |||
| December 2013, <http://www.ietf.org/mail-archive/web/ace/ | December 2013, <http://trac.tools.ietf.org/wg/core/trac/ | |||
| current/msg00007.html>. | wiki/ACE_charter>. | |||
| [FIPS197] , "Federal Information Processing Standards Publication | [FIPS197] , "Federal Information Processing Standards Publication | |||
| 197: Advanced Encryption Standard (AES)", US National | 197: Advanced Encryption Standard (AES)", US National | |||
| Institute of Standards and Technology, Nov. 26 2001. | Institute of Standards and Technology, Nov. 26 2001. | |||
| [Huang2003] | [Huang2003] | |||
| Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J. | Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J. | |||
| Zhang, "Fast Authenticated Key Establishment Protocols for | Zhang, "Fast Authenticated Key Establishment Protocols for | |||
| Self-Organizing Sensor Networks", in Proceedings of the | Self-Organizing Sensor Networks", in Proceedings of the | |||
| 2nd ACM International Conference on Wireless Sensor | 2nd ACM International Conference on Wireless Sensor | |||
| skipping to change at page 36, line 36 ¶ | skipping to change at page 36, line 19 ¶ | |||
| [ISO.7498-2.1988] | [ISO.7498-2.1988] | |||
| International Organization for Standardization, | International Organization for Standardization, | |||
| "Information Processing Systems - Open Systems | "Information Processing Systems - Open Systems | |||
| Interconnection Reference Model - Security Architecture", | Interconnection Reference Model - Security Architecture", | |||
| ISO Standard 7498-2, 1988. | ISO Standard 7498-2, 1988. | |||
| [Karlof2003] | [Karlof2003] | |||
| Karlof, C. and D. Wagner, "Secure routing in wireless | Karlof, C. and D. Wagner, "Secure routing in wireless | |||
| sensor networks: attacks and countermeasures", Elsevier | sensor networks: attacks and countermeasures", Elsevier | |||
| AdHoc Networks Journal, Special Issue on Sensor Network | AdHoc Networks Journal, Special Issue on Sensor Network | |||
| Applications and Protocols, 1(2):293-315, September 2003. | Applications and Protocols, 1(2):293-315, September 2003, | |||
| <http://nest.cs.berkeley.edu/papers/sensor-route- | ||||
| security.pdf>. | ||||
| [Kasumi3gpp] | [Kasumi3gpp] | |||
| , "3GPP TS 35.202 Specification of the 3GPP | , "3GPP TS 35.202 Specification of the 3GPP | |||
| confidentiality and integrity algorithms; Document 2: | confidentiality and integrity algorithms; Document 2: | |||
| Kasumi specification", 3GPP TSG SA3, 2009. | Kasumi specification", 3GPP TSG SA3, 2009. | |||
| [Messerges2003] | [Messerges2003] | |||
| Messerges, T., Cukier, J., Kevenaar, T., Puhl, L., Struik, | Messerges, T., Cukier, J., Kevenaar, T., Puhl, L., Struik, | |||
| R., and E. Callaway, "Low-Power Security for Wireless | R., and E. Callaway, "Low-Power Security for Wireless | |||
| Sensor Networks", in Proceedings of the 1st ACM Workshop | Sensor Networks", in Proceedings of the 1st ACM Workshop | |||
| skipping to change at page 38, line 49 ¶ | skipping to change at page 38, line 33 ¶ | |||
| [SmartObjectSecurityWorkshop] | [SmartObjectSecurityWorkshop] | |||
| Klausen, T., Ed., "Workshop on Smart Object Security", | Klausen, T., Ed., "Workshop on Smart Object Security", | |||
| March 2012, <http://www.lix.polytechnique.fr/hipercom/ | March 2012, <http://www.lix.polytechnique.fr/hipercom/ | |||
| SmartObjectSecurity>. | SmartObjectSecurity>. | |||
| [SolaceProposal] | [SolaceProposal] | |||
| Bormann, C., Ed., "Notes from the SOLACE ad-hoc at IETF85 | Bormann, C., Ed., "Notes from the SOLACE ad-hoc at IETF85 | |||
| (work-in-progress)", November 2012, <http://www.ietf.org/ | (work-in-progress)", November 2012, <http://www.ietf.org/ | |||
| mail-archive/web/solace/current/msg00015.html>. | mail-archive/web/solace/current/msg00015.html>. | |||
| [Sybil2002] | ||||
| Douceur, J., "The Sybil Attack", First International | ||||
| Workshop on Peer-to-Peer Systems , March 2002. | ||||
| [Szcze2008] | [Szcze2008] | |||
| Szczechowiak1, P., Oliveira, L., Scott, M., Collier, M., | Szczechowiak1, P., Oliveira, L., Scott, M., Collier, M., | |||
| and R. Dahab, "NanoECC: testing the limits of elliptic | and R. Dahab, "NanoECC: testing the limits of elliptic | |||
| curve cryptography in sensor networks", pp. 324-328, 2008, | curve cryptography in sensor networks", pp. 324-328, 2008, | |||
| <http://www.ic.unicamp.br/~leob/publications/ewsn/ | <http://www.ic.unicamp.br/~leob/publications/ewsn/ | |||
| NanoECC.pdf>. | NanoECC.pdf>. | |||
| [Wan2004] Wan, T., Kranakis, E., and PC. van Oorschot, "S-RIP: A | [Wan2004] Wan, T., Kranakis, E., and PC. van Oorschot, "S-RIP: A | |||
| Secure Distance Vector Routing Protocol", in Proceedings | Secure Distance Vector Routing Protocol", in Proceedings | |||
| of the 2nd International Conference on Applied | of the 2nd International Conference on Applied | |||
| End of changes. 124 change blocks. | ||||
| 326 lines changed or deleted | 305 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||