draft-ietf-roll-security-threats-01.txt | draft-ietf-roll-security-threats-02.txt | |||
---|---|---|---|---|
Networking Working Group T. Tsao | Networking Working Group T. Tsao | |||
Internet-Draft R. Alexander | Internet-Draft R. Alexander | |||
Intended status: Informational Cooper Power Systems | Intended status: Informational Cooper Power Systems | |||
Expires: August 29, 2013 M. Dohler | Expires: December 13, 2013 M. Dohler | |||
CTTC | CTTC | |||
V. Daza | V. Daza | |||
A. Lozano | A. Lozano | |||
Universitat Pompeu Fabra | Universitat Pompeu Fabra | |||
February 25, 2013 | June 11, 2013 | |||
A Security Threat Analysis for Routing over Low-Power and Lossy Networks | A Security Threat Analysis for Routing over Low-Power and Lossy Networks | |||
draft-ietf-roll-security-threats-01 | draft-ietf-roll-security-threats-02 | |||
Abstract | Abstract | |||
This document presents a security threat analysis for routing over | This document presents a security threat analysis for routing over | |||
low-power and lossy networks (LLN). The development builds upon | low-power and lossy networks (LLN). The development builds upon | |||
previous work on routing security and adapts the assessments to the | previous work on routing security and adapts the assessments to the | |||
issues and constraints specific to low-power and lossy networks. A | issues and constraints specific to low-power and lossy networks. A | |||
systematic approach is used in defining and evaluating the security | systematic approach is used in defining and evaluating the security | |||
threats. Applicable countermeasures are application specific and are | threats. Applicable countermeasures are application specific and are | |||
addressed in relevant applicability statements. These assessments | addressed in relevant applicability statements. These assessments | |||
skipping to change at page 2, line 4 | skipping to change at page 2, line 4 | |||
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 August 29, 2013. | This Internet-Draft will expire on December 13, 2013. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3. Considerations on ROLL Security . . . . . . . . . . . . . . . 5 | 3. Considerations on ROLL Security . . . . . . . . . . . . . . . 6 | |||
3.1. Routing Assets and Points of Access . . . . . . . . . . . 6 | 3.1. Routing Assets and Points of Access . . . . . . . . . . . 6 | |||
3.2. The CIA Security Reference Model . . . . . . . . . . . . . 9 | 3.2. The ISO 7498-2 Security Reference Model . . . . . . . . . 9 | |||
3.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 10 | 3.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 11 | |||
3.4. ROLL Security Objectives . . . . . . . . . . . . . . . . . 12 | 3.4. ROLL Security Objectives . . . . . . . . . . . . . . . . . 12 | |||
4. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 13 | 4. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 14 | |||
4.1. Threats and Attacks on Confidentiality . . . . . . . . . . 14 | 4.1. Threats and Attacks on Confidentiality . . . . . . . . . . 14 | |||
4.1.1. Routing Exchange Exposure . . . . . . . . . . . . . . 14 | 4.1.1. Routing Exchange Exposure . . . . . . . . . . . . . . 14 | |||
4.1.2. Routing Information (Routes and Network Topology) | 4.1.2. Routing Information (Routes and Network Topology) | |||
Exposure . . . . . . . . . . . . . . . . . . . . . . . 15 | Exposure . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
4.2. Threats and Attacks on Integrity . . . . . . . . . . . . . 15 | 4.2. Threats and Attacks on Integrity . . . . . . . . . . . . . 16 | |||
4.2.1. Routing Information Manipulation . . . . . . . . . . . 15 | 4.2.1. Routing Information Manipulation . . . . . . . . . . . 16 | |||
4.2.2. Node Identity Misappropriation . . . . . . . . . . . . 16 | 4.2.2. Node Identity Misappropriation . . . . . . . . . . . . 16 | |||
4.3. Threats and Attacks on Availability . . . . . . . . . . . 16 | 4.3. Threats and Attacks on Availability . . . . . . . . . . . 17 | |||
4.3.1. Routing Exchange Interference or Disruption . . . . . 17 | 4.3.1. Routing Exchange Interference or Disruption . . . . . 17 | |||
4.3.2. Network Traffic Forwarding Disruption . . . . . . . . 17 | 4.3.2. Network Traffic Forwarding Disruption . . . . . . . . 17 | |||
4.3.3. Communications Resource Disruption . . . . . . . . . . 18 | 4.3.3. Communications Resource Disruption . . . . . . . . . . 19 | |||
4.3.4. Node Resource Exhaustion . . . . . . . . . . . . . . . 19 | 4.3.4. Node Resource Exhaustion . . . . . . . . . . . . . . . 19 | |||
5. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 19 | 5. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
5.1. Confidentiality Attack Countermeasures . . . . . . . . . . 20 | 5.1. Confidentiality Attack Countermeasures . . . . . . . . . . 20 | |||
5.1.1. Countering Deliberate Exposure Attacks . . . . . . . . 20 | 5.1.1. Countering Deliberate Exposure Attacks . . . . . . . . 20 | |||
5.1.2. Countering Sniffing Attacks . . . . . . . . . . . . . 20 | 5.1.2. Countering Sniffing Attacks . . . . . . . . . . . . . 21 | |||
5.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 21 | 5.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 22 | |||
5.1.4. Countering Physical Device Compromise . . . . . . . . 22 | 5.1.4. Countering Physical Device Compromise . . . . . . . . 23 | |||
5.1.5. Countering Remote Device Access Attacks . . . . . . . 24 | 5.1.5. Countering Remote Device Access Attacks . . . . . . . 25 | |||
5.2. Integrity Attack Countermeasures . . . . . . . . . . . . . 25 | 5.2. Integrity Attack Countermeasures . . . . . . . . . . . . . 25 | |||
5.2.1. Countering Unauthorized Modification Attacks . . . . . 25 | 5.2.1. Countering Unauthorized Modification Attacks . . . . . 25 | |||
5.2.2. Countering Overclaiming and Misclaiming Attacks . . . 25 | 5.2.2. Countering Overclaiming and Misclaiming Attacks . . . 26 | |||
5.2.3. Countering Identity (including Sybil) Attacks . . . . 26 | 5.2.3. Countering Identity (including Sybil) Attacks . . . . 26 | |||
5.2.4. Countering Routing Information Replay Attacks . . . . 26 | 5.2.4. Countering Routing Information Replay Attacks . . . . 27 | |||
5.2.5. Countering Byzantine Routing Information Attacks . . . 26 | 5.2.5. Countering Byzantine Routing Information Attacks . . . 27 | |||
5.3. Availability Attack Countermeasures . . . . . . . . . . . 27 | 5.3. Availability Attack Countermeasures . . . . . . . . . . . 28 | |||
5.3.1. Countering HELLO Flood Attacks and ACK Spoofing | 5.3.1. Countering HELLO Flood Attacks and ACK Spoofing | |||
Attacks . . . . . . . . . . . . . . . . . . . . . . . 28 | Attacks . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
5.3.2. Countering Overload Attacks . . . . . . . . . . . . . 29 | 5.3.2. Countering Overload Attacks . . . . . . . . . . . . . 29 | |||
5.3.3. Countering Selective Forwarding Attacks . . . . . . . 30 | 5.3.3. Countering Selective Forwarding Attacks . . . . . . . 31 | |||
5.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 31 | 5.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 31 | |||
5.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 32 | 5.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 32 | |||
6. ROLL Security Features . . . . . . . . . . . . . . . . . . . . 32 | 6. ROLL Security Features . . . . . . . . . . . . . . . . . . . . 32 | |||
6.1. Confidentiality Features . . . . . . . . . . . . . . . . . 33 | 6.1. Confidentiality Features . . . . . . . . . . . . . . . . . 34 | |||
6.2. Integrity Features . . . . . . . . . . . . . . . . . . . . 34 | 6.2. Integrity Features . . . . . . . . . . . . . . . . . . . . 35 | |||
6.3. Availability Features . . . . . . . . . . . . . . . . . . 35 | 6.3. Availability Features . . . . . . . . . . . . . . . . . . 36 | |||
6.4. Security Key Management . . . . . . . . . . . . . . . . . 36 | 6.4. Security Key Management . . . . . . . . . . . . . . . . . 36 | |||
6.5. Consideration on Matching Application Domain Needs . . . . 37 | 6.5. Consideration on Matching Application Domain Needs . . . . 38 | |||
6.5.1. Security Architecture . . . . . . . . . . . . . . . . 38 | 6.5.1. Security Architecture . . . . . . . . . . . . . . . . 38 | |||
6.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 40 | 6.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 41 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 43 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 43 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 43 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 43 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 | |||
1. Introduction | 1. Introduction | |||
skipping to change at page 5, line 28 | skipping to change at page 5, line 28 | |||
lossy networks (LLNs), however, are drawing efforts to examine and | lossy networks (LLNs), however, are drawing efforts to examine and | |||
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 Routing Over | This document presents a threat analysis for securing Routing Over | |||
LLNs (ROLL) through an analysis that starts from the routing basics. | LLNs (ROLL) through an analysis that starts from the routing basics. | |||
The objective is two-fold. First, the analysis will be used to | The objective is two-fold. First, the analysis will be used to | |||
identify pertinent security issues. Second, it will facilitate both | identify pertinent security issues. Second, it will facilitate both | |||
the assessment of a protocol's security threats and the | the assessment of a protocol's security threats and the | |||
identification of the necessary features for development of secure | identification of necessary countermeasures to secure the ROLL | |||
protocols for the ROLL Working Group. | protocols. The approach adopted is a five step process, 1) examine | |||
security issues in ROLL, 2) describe the threat sources, 3) analyze | ||||
threats and attacks, 4) consider countermeasures, and 5) provide | ||||
recommendations for securing ROLL. | ||||
The approach adopted in this effort proceeds in four steps, to | This document uses [IS07498-2] model, which includes Authentication, | |||
examine security issues in ROLL, to analyze threats and attacks, to | Access Control, Data Confidentiality, Data Integrity, and Non- | |||
consider the countermeasures, and then to make recommendations for | Repudiation but to which Availability is added. | |||
securing ROLL. The basis is found on identifying the assets and | ||||
points of access of routing and evaluating their security needs based | spt: If this is just about control plane security then we should say | |||
on the Confidentiality, Integrity, and Availability (CIA) model in | so right up front. | |||
the context of LLN. | ||||
2. Terminology | 2. Terminology | |||
This document adopts the terminology defined in [RFC6550] and in | This document adopts the terminology defined in [RFC6550] and in | |||
[RFC4949], with the following addition: | [RFC4949], with the following addition: | |||
Control Sequence Control plane: Supports routing and management | ||||
functions. | ||||
Data Plane Data plane: See Forwarding plane. | ||||
Data Plane Forwarding plane: Responsible for receiving a packet on | ||||
an incoming interface, performing a lookup to identify the | ||||
packet's next hop and determine the best outgoing interface | ||||
towards the destination, and forwarding the packet out through | ||||
the appropriate outgoing interface. | ||||
Node An element of a low-power, lossy network that may be a router | Node An element of a low-power, lossy network that may be a router | |||
or a host. | or a host. | |||
Sleepy Node A sleepy node is a Node that may sometimes go into a | ||||
sleep mode (i.e. go into a low power state to conserve power) | ||||
and temporarily suspends communication but that is immediately | ||||
available. | ||||
3. Considerations on ROLL Security | 3. Considerations on ROLL Security | |||
Security, in essence, entails implementing measures to ensure | Routing security, in essence, ensures that the routing protocol | |||
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 proper authorization for actions, authentication, and | not only authorization of injector's actions, authentication of | |||
potentially integrity and confidentiality, but also proper order of | injectors, authentication, integrity, and potentially confidentiality | |||
state changes through timeliness, since seriously delayed state | of routing data, but also proper order of state changes through | |||
changes, such as commands or updates of routing tables, may | timeliness, since seriously delayed state changes, such as commands | |||
negatively impact system operation. A security assessment can | or updates of routing tables, may negatively impact system operation. | |||
therefore begin with a focus on the assets or elements of information | ||||
that may be the target of the state changes and the access points in | ||||
terms of interfaces and protocol exchanges through which such changes | ||||
may occur. In the case of routing security the focus is directed | ||||
towards the elements associated with the establishment and | ||||
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 problem, while also drawing references from other | routing security, while also drawing references from other reviews | |||
reviews and assessments found in the literature, particularly, | and assessments found in the literature, particularly, [RFC4593] and | |||
[RFC4593] and [Karlof2003]; thus, the work presented herein may find | [Karlof2003]. The subsequent subsections begin with a focus on the | |||
use beyond routing for LLNs. The subsequent subsections begin with a | elements of a generic routing process that is used to establish | |||
focus on the elements of a generic routing process that is used to | routing assets and points of access to the routing functionality. | |||
establish routing assets and points of access to the routing | Next, the ISO 7498-2 security model is briefly described. Then, | |||
functionality. Next, the CIA security model is briefly described. | consideration is given to issues specific to or amplified in LLNs. | |||
Then, consideration is given to issues specific to or amplified in | This section concludes with the formulation of a set of security | |||
LLNs. This section concludes with the formulation of a set of | objectives for ROLL. | |||
security objectives for ROLL. | ||||
3.1. Routing Assets and Points of Access | 3.1. Routing Assets and Points of Access | |||
An asset implies an important system component (including | An asset implies an important system component (including | |||
information, process, or physical resource), the access to, | information, process, or physical resource), the access to, | |||
corruption or loss of which adversely affects the system. In the | corruption or loss of which adversely affects the system. In the | |||
control plane context, an asset is information about the network, | control plane context, an asset is information about the network, | |||
processes used to manage and manipulate this data, and the physical | processes used to manage and manipulate this data, and the physical | |||
devices on which this data is stored and manipulated. The corruption | devices on which this data is stored and manipulated. The corruption | |||
or loss of these assets may adversely impact the control plane of the | or loss of these assets may adversely impact the control plane of the | |||
skipping to change at page 7, line 5 | skipping to change at page 7, line 20 | |||
components. Identifying these assets and points of access will | components. Identifying these assets and points of access will | |||
provide a basis for enumerating the attack surface of the control | provide a basis for enumerating the attack surface of the control | |||
plane. | 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 | |||
components and mechanisms in an individual routing protocol can be | assets, points of access, and process in an individual routing | |||
readily identified, but also to be as general as possible to maximize | protocol can be readily identified. | |||
the relevancy of this effort for the various existing and future | ||||
protocols. Nevertheless, there may be discrepancies, likely in the | ||||
form of additional elements, when the model is applied to some | ||||
protocols. For such cases, the analysis approach laid out in this | ||||
document should still provide a valid and illustrative path for their | ||||
security assessment. | ||||
Figure 1 shows that nodes participating in the routing process | Figure 1 shows that nodes participating in the routing process | |||
transmit messages to discover neighbors and to exchange routing | transmit messages to discover neighbors and to exchange routing | |||
information; routes are then generated and stored, which may be | information; routes are then generated and stored, which may be | |||
maintained in the form of the protocol forwarding table. The nodes | maintained in the form of the protocol forwarding table. The nodes | |||
use the derived routes for making forwarding decisions. | use the derived routes for making forwarding decisions. | |||
................................................... | ................................................... | |||
: : | : : | |||
: : | : : | |||
skipping to change at page 8, line 44 | skipping to change at page 8, line 44 | |||
-------> Data flow | -------> Data flow | |||
Figure 1: Data Flow Diagram of a Generic Routing Process | Figure 1: Data Flow Diagram of a Generic Routing Process | |||
It is seen from Figure 1 that | It is seen from Figure 1 that | |||
o Assets include | o Assets include | |||
* routing and/or topology information; | * routing and/or topology information; | |||
* route generation process; | ||||
* communication channel resources (bandwidth); | * communication channel resources (bandwidth); | |||
* node resources (computing capacity, memory, and remaining | * node resources (computing capacity, memory, and remaining | |||
energy); | energy); | |||
* node identifiers (including node identity and ascribed | * node identifiers (including node identity and ascribed | |||
attributes such as relative or absolute node location). | attributes such as relative or absolute node location). | |||
o Points of access include | o Points of access include | |||
skipping to change at page 9, line 23 | skipping to change at page 9, line 26 | |||
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 CIA Security Reference Model | 3.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 ROLL in particular is concerned with the | general and applied to ROLL in particular is concerned with the | |||
primary issues of confidentiality, integrity, and availability. In | primary issues of authentication, access control, data | |||
the context of ROLL: | confidentiality, data integrity, and non-repudiation. In the context | |||
of ROLL | ||||
Authentication | ||||
Authentication involves the mutual authentication of the | ||||
routing peers prior to exchanging route information (i.e., peer | ||||
authentication) as well as ensuring that the source of the | ||||
route data is from the peer (i.e., data origin | ||||
authentication).From 5478 LLNs can be drained by | ||||
unauthenticated peers before confirguratin From 5673 This | ||||
requires availability of open and untrusted side channels for | ||||
new joiners, and it requires strong and automated | ||||
authentication so that networks can automatically accept or | ||||
reject new joiners. spt: Do we need more here? | ||||
Access Control | ||||
Access Control provides protection against unauthorized use of | ||||
the asset. | ||||
Confidentiality | Confidentiality | |||
Confidentiality involves the protection of routing information | Confidentiality involves the protection of routing information | |||
as well as routing neighbor maintenance exchanges so that only | as well as routing neighbor maintenance exchanges so that only | |||
authorized and intended network entities may view or access it. | authorized and intended network entities may view or access it. | |||
Because LLNs are most commonly found on a publicly accessible | Because LLNs are most commonly found on a publicly accessible | |||
shared medium, e.g., air or wiring in a building, and sometimes | shared medium, e.g., air or wiring in a building, and sometimes | |||
formed ad hoc, confidentiality also extends to the neighbor | formed ad hoc, confidentiality also extends to the neighbor | |||
state and database information within the routing device since | state and database information within the routing device since | |||
the deployment of the network creates the potential for | the deployment of the network creates the potential for | |||
unauthorized access to the physical devices themselves. | unauthorized access to the physical devices themselves. | |||
Integrity | Integrity | |||
Integrity, as a security principle, entails the protection of | IIntegrity entails the protection of routing information and | |||
routing information and routing neighbor maintenance exchanges, | routing neighbor maintenance exchanges, as well as derived | |||
as well as derived information maintained in the database, from | information maintained in the database, from unauthorized | |||
unauthorized modification or from misuse. Misuse, for example, | modification, insertions, deletions or replays. to be addressed | |||
may take the form of a delayed or inappropriately replayed | beyond the routing protocol. | |||
message even where confidentiality protection is maintained. | ||||
Hence, in addition to the data itself, integrity also concerns | Non-repudiation | |||
the authenticity of claimed identity of the origin and | Non-repudiation is the assurance that the transmission and/or | |||
destination of a message and its timeliness or freshness. On | reception of a message cannot later be denied. The service of | |||
the other hand, the access to and/or removal of data, execution | non-repudiation applies after-the-fact and thus relies on the | |||
of the routing process, and use of a device's computing and | logging or other capture of on-going message exchanges and | |||
energy resources, while relevant to routing security are | signatures. Applied to routing, non-repudiation is not an | |||
considered larger system integrity issues [RFC4949] to be | issue because it does not apply to routing protocols, which are | |||
addressed beyond the routing protocol. | machine-to-machine protocols. Further, with the LLN | |||
application domains as described in RFC5548 [RFC5867], | ||||
proactive measures are much more critical than retrospective | ||||
protections. Finally, given the significant practical limits | ||||
to on-going routing transaction logging and storage and | ||||
individual device digital signature verification for each | ||||
exchange, non-repudiation in the context of routing is an | ||||
unsupportable burden that bears no further considered as a ROLL | ||||
security issue. | ||||
It is recognized that, besides those security issues captured in the | ||||
ISO 7498-2 model, availability, is a security requirement: | ||||
Availability | Availability | |||
Availability ensures that routing information exchanges and | Availability ensures that routing information exchanges and | |||
forwarding services need to be available when they are required | forwarding services need to be available when they are required | |||
for the functioning of the serving network. Availability will | for the functioning of the serving network. Availability will | |||
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 is recognized that, besides those security issues captured in the | ||||
CIA model, non-repudiation, that is, the assurance that the | ||||
transmission and/or reception of a message cannot later be denied, | ||||
may be a security requirement under certain circumstances. The | ||||
service of non-repudiation applies after-the-fact and thus relies on | ||||
the logging or other capture of on-going message exchanges and | ||||
signatures. Applied to routing, non-repudiation will involve | ||||
providing some ability to allow traceability or network management | ||||
review of participants of the routing process including the ability | ||||
to determine the events and actions leading to a particular routing | ||||
state. As such, non-repudiation of routing may thus be more useful | ||||
when interworking with networks of different ownerships. For the LLN | ||||
application domains as described in [RFC5548], [RFC5673], [RFC5826], | ||||
and [RFC5867], particularly with regard to routing security, | ||||
proactive measures are much more critical than retrospective | ||||
protections. Furthermore, given the significant practical limits to | ||||
on-going routing transaction logging and storage and individual | ||||
device signature authentication for each exchange, non-repudiation in | ||||
the context of routing is not further considered as a ROLL security | ||||
issue. | ||||
It should be emphasized here that for routing security the above CIA | IIt should be emphasized here that for routing 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 routing protocol implementation. | a given routing protocol implementation. | |||
3.3. Issues Specific to or Amplified in LLNs | 3.3. Issues Specific to or Amplified in LLNs | |||
The work [RFC5548], [RFC5673], [RFC5826], and [RFC5867] have | The work [RFC5548], [RFC5673], [RFC5826], and [RFC5867] have | |||
identified specific issues and constraints of routing in LLNs for the | identified specific issues and constraints of routing in LLNs for the | |||
urban, industrial, home automation, and building automation | urban, industrial, home automation, and building automation | |||
application domains, respectively. The following is a list of | application domains, respectively. The following is a list of | |||
observations and evaluation of their impact on routing security | observations and evaluation of their impact on routing security | |||
considerations. | 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. In addition, the choices of | during the system design process. The chosen security | |||
security mechanisms are more stringent. Synchronization of | mechanisms also needs to work within these constraints. | |||
security states with sleepy nodes is yet another issue. | Synchronization of security states with sleepy nodes is yet | |||
another issue. | ||||
Large scale of rolled out network | Large scale of rolled out network | |||
The possibly numerous nodes to be deployed, e.g., an urban | The possibly numerous nodes to be deployed, e.g., an urban | |||
deployment can see several hundreds of thousands of nodes, as | deployment can see several hundreds of thousands of nodes, as | |||
well as the generally low level of expertise expected of the | well as the generally low level of expertise expected of the | |||
installers, make manual on-site configuration unlikely. | installers, make manual on-site configuration unlikely. | |||
Prolonged rollout and delayed addition of nodes, which may be | Prolonged rollout and delayed addition of nodes, which may be | |||
from old inventory, over the lifetime of the network, also | from old inventory, over the lifetime of the network, also | |||
complicate the operations of key management. | complicate the operations of key management. | |||
skipping to change at page 11, line 37 | skipping to change at page 11, line 50 | |||
configuration for initialization or local filtering rules. | configuration for initialization or local filtering rules. | |||
Network topology/ownership changes, partitioning or merging, as | Network topology/ownership changes, partitioning or merging, as | |||
well as node replacement, can all contribute to complicating | well as node replacement, can all contribute to complicating | |||
the operations of key management. | the operations of key management. | |||
Highly directional traffic | Highly directional traffic | |||
Some types of LLNs see a high percentage of their total traffic | Some types of LLNs see a high percentage of their total traffic | |||
traverse between the nodes and the LLN Border Routers (LBRs) | traverse between the nodes and the LLN Border Routers (LBRs) | |||
where the LLNs connect to non-LLNs. The special routing status | where the LLNs connect to non-LLNs. The special routing status | |||
of and the greater volume of traffic near the LBRs have routing | of and the greater volume of traffic near the LBRs have routing | |||
security consequences. In fact, when Point-to-MultiPoint | security consequences as a higher valued attack target. In | |||
(P2MP) and MultiPoint-to-Point (MP2P) traffic represents a | fact, when Point-to-MultiPoint (P2MP) and MultiPoint-to-Point | |||
majority of the traffic, routing attacks consisting of | (MP2P) traffic represents a majority of the traffic, routing | |||
advertising untruthfully preferred routes may cause serious | attacks consisting of advertising incorrect preferred routes | |||
damage. | can cause serious damage. | |||
Unattended locations and limited physical security | Unattended locations and limited physical security | |||
Many applications have the nodes deployed in unattended or | Many applications have the nodes deployed in unattended or | |||
remote locations; furthermore, the nodes themselves are often | remote locations; furthermore, the nodes themselves are often | |||
built with minimal physical protection. These constraints | built with minimal physical protection. These constraints | |||
lower the barrier of accessing the data or security material | lower the barrier of accessing the data or security material | |||
stored on the nodes through physical means. | stored on the nodes through physical means. | |||
Support for mobility | Support for mobility | |||
On the one hand, only a number of applications require the | On the one hand, only a number of applications require the | |||
skipping to change at page 12, line 20 | skipping to change at page 12, line 30 | |||
routing protocol is indeed used in such applications, it will | routing protocol is indeed used in such applications, it will | |||
clearly need to have corresponding security mechanisms. | clearly need to have corresponding security mechanisms. | |||
Support for multicast and anycast | Support for multicast and anycast | |||
Support for multicast and anycast is called out chiefly for | Support for multicast and anycast is called out chiefly for | |||
large-scale networks. Since application of these routing | large-scale networks. Since application of these routing | |||
mechanisms in autonomous operations of many nodes is new, the | mechanisms in autonomous operations of many nodes is new, the | |||
consequence on security requires careful consideration. | consequence on security requires careful consideration. | |||
The above list considers how an LLN's physical constraints, size, | The above list considers how an LLN's physical constraints, size, | |||
operations, and varieties 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. ROLL Security Objectives | 3.4. ROLL Security Objectives | |||
This subsection applies the CIA model to the 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 ROLL security objectives. | of ROLL 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 is not tampered during transfer and | o routing/topology information iintegrity remains intact during | |||
in storage; | transfer and in storage; | |||
o routing/topology information is not misappropriated; | 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 of | In conjunction, it is necessary to be assured that | |||
o the authenticity and legitimacy of the participants of the routing | o authorized peers authenticate themselves during the routing | |||
neighbor discovery process; | neighbor discovery process; | |||
o the routing/topology information received was faithfully generated | o the routing/topology information received is generated according | |||
according to the protocol design. | to the protocol design. | |||
However, when trust cannot be fully vested through authentication of | However, when trust cannot be fully vested through authentication of | |||
the principals alone, i.e., concerns of insider attack, assurance of | the principals alone, i.e., concerns of insider attack, assurance of | |||
the truthfulness and timeliness of the received routing/topology | the truthfulness and timeliness of the received routing/topology | |||
information is necessary. With regard to confidentiality, protecting | information is necessary. With regard to confidentiality, protecting | |||
the routing/topology information from eavesdropping or unauthorized | the routing/topology information from eavesdropping or unauthorized | |||
exposure may be desirable in certain cases but is in itself less | exposure may be desirable in certain cases but is in itself less | |||
pertinent in general to the routing function. | pertinent in general to the routing function. | |||
One of the main problems of synchronizing security states of sleepy | One of the main problems of synchronizing security states of sleepy | |||
skipping to change at page 14, line 23 | skipping to change at page 14, line 34 | |||
Section 3.1. The assessment steps through the security concerns of | Section 3.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 manifestation of the attacks is assumed to be from | literature. The manifestation of the attacks is assumed to be from | |||
either inside or outside attackers, whose capabilities may be limited | either inside or outside attackers, whose capabilities may be limited | |||
to node-equivalent or more sophisticated computing platforms. | to node-equivalent or more sophisticated computing platforms. | |||
4.1. Threats and Attacks on Confidentiality | 4.1. Threats and Attacks on Confidentiality | |||
The assessment in Section 3.2 indicates that routing information | The assessment in CIA indicates that routing information assets are | |||
assets are exposed to confidentiality threats from all points of | exposed to confidentiality threats from all points of access. The | |||
access. The confidentiality threat space is thus defined by the | confidentiality threat space is thus defined by the access to routing | |||
access to routing information achievable through the communication | information achievable through the communication exchanges between | |||
exchanges between routing nodes together with the direct access to | routing nodes together with the direct access to information | |||
information maintained within the nodes. | maintained within the nodes. | |||
4.1.1. Routing Exchange Exposure | 4.1.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 3.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 memory, remaining power, etc., | |||
that may be metrics of the routing protocol. | that may be metrics of the routing protocol. | |||
skipping to change at page 15, line 40 | skipping to change at page 16, line 7 | |||
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). | |||
More detailed descriptions of the exposure attacks on routing | More detailed descriptions of the exposure attacks on routing | |||
exchange and information will be given in Section 5 together with the | exchange and information will be given in Section 5 together with the | |||
corresponding countermeasures. | corresponding countermeasures. | |||
4.2. Threats and Attacks on Integrity | 4.2. Threats and Attacks on Integrity | |||
The assessment in Section 3.2 indicates that information and identity | The assessment in CIA indicates that information and identity assets | |||
assets are exposed to integrity threats from all points of access. | are exposed to integrity threats from all points of access. In other | |||
In other words, the integrity threat space is defined by the | words, the integrity threat space is defined by the potential for | |||
potential for exploitation introduced by access to assets available | exploitation introduced by access to assets available through routing | |||
through routing exchanges and the on-device storage. | exchanges and the on-device storage. | |||
4.2.1. Routing Information Manipulation | 4.2.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. Manipulation of | impact the forwarding decisions made in the network. Manipulation of | |||
topology and reachability information will allow unauthorized sources | topology and reachability information will allow unauthorized sources | |||
to influence the nodes with which routing information is exchanged | to influence the nodes with which routing information is exchanged | |||
and updated. The consequence of manipulating routing exchanges can | and updated. The consequence of manipulating routing exchanges can | |||
skipping to change at page 16, line 48 | skipping to change at page 17, line 15 | |||
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 in which a malicious | |||
node illegitimately assumes multiple identities; | node illegitimately assumes multiple identities; | |||
o Routing information replay. | o Routing information replay. | |||
4.3. Threats and Attacks on Availability | 4.3. Threats and Attacks on Availability | |||
The assessment in Section 3.2 indicates that the process and | The assessment in CIA indicates that the process and resources assets | |||
resources assets are exposed to availability threats; attacks of this | are exposed to availability threats; attacks of this category may | |||
category may exploit directly or indirectly information exchange or | exploit directly or indirectly information exchange or forwarding | |||
forwarding (see [RFC4732] for a general discussion). | (see [RFC4732] for a general discussion). | |||
4.3.1. Routing Exchange Interference or Disruption | 4.3.1. Routing Exchange Interference or Disruption | |||
Interference or disruption of routing information exchanges will | Interference or disruption of routing information exchanges will | |||
allow unauthorized sources to influence the operation and convergence | allow unauthorized sources to influence the operation and convergence | |||
of the routing protocols by impeding the regularity of routing | of the routing protocols by impeding the regularity of 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 | |||
End of changes. 45 change blocks. | ||||
139 lines changed or deleted | 155 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |