draft-ietf-roll-security-threats-04.txt   draft-ietf-roll-security-threats-05.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: March 08, 2014 M. Dohler Expires: April 23, 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
September 04, 2013 October 20, 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-04 draft-ietf-roll-security-threats-05
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 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 March 08, 2014. This Internet-Draft will expire on April 23, 2014.
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
skipping to change at page 2, line 35 skipping to change at page 2, line 35
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Considerations on ROLL Security . . . . . . . . . . . . . . . 4 3. Considerations on ROLL Security . . . . . . . . . . . . . . . 4
3.1. Routing Assets and Points of Access . . . . . . . . . . . 5 3.1. Routing Assets and Points of Access . . . . . . . . . . . 5
3.2. The ISO 7498-2 Security Reference Model . . . . . . . . . 7 3.2. The ISO 7498-2 Security Reference Model . . . . . . . . . 7
3.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 8 3.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 8
3.4. ROLL Security Objectives . . . . . . . . . . . . . . . . 10 3.4. ROLL Security Objectives . . . . . . . . . . . . . . . . 11
4. Threat Sources . . . . . . . . . . . . . . . . . . . . . . . 12 4. Threat Sources . . . . . . . . . . . . . . . . . . . . . . . 12
5. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 12 5. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 12
5.1. Threats due to failures to Authenticate . . . . . . . . . 12 5.1. Threats due to failures to Authenticate . . . . . . . . . 13
5.1.1. Node Impersonation . . . . . . . . . . . . . . . . . 12 5.1.1. Node Impersonation . . . . . . . . . . . . . . . . . 13
5.1.2. Dummy Node . . . . . . . . . . . . . . . . . . . . . 13 5.1.2. Dummy Node . . . . . . . . . . . . . . . . . . . . . 13
5.1.3. Node Resource Spam . . . . . . . . . . . . . . . . . 13 5.1.3. Node Resource Spam . . . . . . . . . . . . . . . . . 13
5.2. Threats and Attacks on Confidentiality . . . . . . . . . 13 5.2. Threats and Attacks on Confidentiality . . . . . . . . . 13
5.2.1. Routing Exchange Exposure . . . . . . . . . . . . . . 13 5.2.1. Routing Exchange Exposure . . . . . . . . . . . . . . 14
5.2.2. Routing Information (Routes and Network Topology) 5.2.2. Routing Information (Routes and Network Topology)
Exposure . . . . . . . . . . . . . . . . . . . . . . 13 Exposure . . . . . . . . . . . . . . . . . . . . . . 14
6. Threats and Attacks on Integrity . . . . . . . . . . . . . . 14 6. Threats and Attacks on Integrity . . . . . . . . . . . . . . 15
6.1. Routing Information Manipulation . . . . . . . . . . . . 14 6.1. Routing Information Manipulation . . . . . . . . . . . . 15
6.2. Node Identity Misappropriation . . . . . . . . . . . . . 15 6.2. Node Identity Misappropriation . . . . . . . . . . . . . 15
7. Threats and Attacks on Availability . . . . . . . . . . . . . 15 7. Threats and Attacks on Availability . . . . . . . . . . . . . 16
7.1. Routing Exchange Interference or Disruption . . . . . . . 16 7.1. Routing Exchange Interference or Disruption . . . . . . . 16
7.2. Network Traffic Forwarding Disruption . . . . . . . . . . 16 7.2. Network Traffic Forwarding Disruption . . . . . . . . . . 16
7.3. Communications Resource Disruption . . . . . . . . . . . 17 7.3. Communications Resource Disruption . . . . . . . . . . . 18
7.4. Node Resource Exhaustion . . . . . . . . . . . . . . . . 17 7.4. Node Resource Exhaustion . . . . . . . . . . . . . . . . 18
8. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 18 8. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Confidentiality Attack Countermeasures . . . . . . . . . 18 8.1. Confidentiality Attack Countermeasures . . . . . . . . . 19
8.1.1. Countering Deliberate Exposure Attacks . . . . . . . 19 8.1.1. Countering Deliberate Exposure Attacks . . . . . . . 19
8.1.2. Countering Sniffing Attacks . . . . . . . . . . . . . 19 8.1.2. Countering Passive Wiretapping Attacks . . . . . . . 20
8.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 20 8.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 21
8.1.4. Countering Remote Device Access Attacks . . . . . . . 21 8.1.4. Countering Remote Device Access Attacks . . . . . . . 21
8.2. Integrity Attack Countermeasures . . . . . . . . . . . . 21 8.2. Integrity Attack Countermeasures . . . . . . . . . . . . 22
8.2.1. Countering Unauthorized Modification Attacks . . . . 22 8.2.1. Countering Unauthorized Modification Attacks . . . . 22
8.2.2. Countering Overclaiming and Misclaiming Attacks . . . 22 8.2.2. Countering Overclaiming and Misclaiming Attacks . . . 23
8.2.3. Countering Identity (including Sybil) Attacks . . . . 22 8.2.3. Countering Identity (including Sybil) Attacks . . . . 23
8.2.4. Countering Routing Information Replay Attacks . . . . 23 8.2.4. Countering Routing Information Replay Attacks . . . . 23
8.2.5. Countering Byzantine Routing Information Attacks . . 23 8.2.5. Countering Byzantine Routing Information Attacks . . 24
8.3. Availability Attack Countermeasures . . . . . . . . . . . 24 8.3. Availability Attack Countermeasures . . . . . . . . . . . 25
8.3.1. Countering HELLO Flood Attacks and ACK Spoofing 8.3.1. Countering HELLO Flood Attacks and ACK Spoofing
Attacks . . . . . . . . . . . . . . . . . . . . . . . 24 Attacks . . . . . . . . . . . . . . . . . . . . . . . 25
8.3.2. Countering Overload Attacks . . . . . . . . . . . . . 26 8.3.2. Countering Overload Attacks . . . . . . . . . . . . . 26
8.3.3. Countering Selective Forwarding Attacks . . . . . . . 27 8.3.3. Countering Selective Forwarding Attacks . . . . . . . 27
8.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 28 8.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 28
8.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 29 8.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 28
9. ROLL Security Features . . . . . . . . . . . . . . . . . . . 29 9. ROLL Security Features . . . . . . . . . . . . . . . . . . . 29
9.1. Confidentiality Features . . . . . . . . . . . . . . . . 30 9.1. Confidentiality Features . . . . . . . . . . . . . . . . 30
9.2. Integrity Features . . . . . . . . . . . . . . . . . . . 31 9.2. Integrity Features . . . . . . . . . . . . . . . . . . . 31
9.3. Availability Features . . . . . . . . . . . . . . . . . . 32 9.3. Availability Features . . . . . . . . . . . . . . . . . . 31
9.4. Key Management . . . . . . . . . . . . . . . . . . . . . 33 9.4. Key Management . . . . . . . . . . . . . . . . . . . . . 32
9.5. Consideration on Matching Application Domain Needs . . . 34 9.5. Consideration on Matching Application Domain Needs . . . 32
9.5.1. Security Architecture . . . . . . . . . . . . . . . . 34 9.5.1. Security Architecture . . . . . . . . . . . . . . . . 32
9.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 37 9.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 35
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
11. Security Considerations . . . . . . . . . . . . . . . . . . . 39 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
13.1. Normative References . . . . . . . . . . . . . . . . . . 40 13.1. Normative References . . . . . . . . . . . . . . . . . . 38
13.2. Informative References . . . . . . . . . . . . . . . . . 40 13.2. Informative References . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
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,
packet size, etc.), but also form factors that may rule out user packet size, etc.), but also form factors that may rule out user
skipping to change at page 4, line 30 skipping to change at page 4, line 30
Access Control, Data Confidentiality, Data Integrity, and Non- Access Control, Data Confidentiality, Data Integrity, and Non-
Repudiation but to which Availability is added. Repudiation but to which Availability is added.
All of this document concerns itself with control plane traffic only. All of this document concerns itself with control plane traffic only.
2. Terminology 2. 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
with section 1 of [RFC6192].
3. Considerations on ROLL Security 3. Considerations on ROLL 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
skipping to change at page 6, line 21 skipping to change at page 6, line 23
................................................... ...................................................
| |
|Forwarding | |Forwarding |
|On Node_l|<-------------------------------------------+ |On Node_l|<-------------------------------------------+
Notation: Notation:
(Proc) A process Proc (Proc) A process Proc
________ ________
DataBase A data storage DataBase topology A structure storing neighbor adjacency (parent/child)
--------
________
routes A structure storing the forwarding information base (FIB)
-------- --------
|Node_n| An external entity Node_n |Node_n| An external entity Node_n
-------> 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
skipping to change at page 9, line 51 skipping to change at page 10, line 5
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 as a higher valued attack target. In security consequences as a higher valued attack target. In
fact, when Point-to-MultiPoint (P2MP) and MultiPoint-to-Point fact, when Point-to-MultiPoint (P2MP) and MultiPoint-to-Point
(MP2P) traffic represents a majority of the traffic, routing (MP2P) traffic represents a majority of the traffic, routing
attacks consisting of advertising incorrect preferred routes attacks consisting of advertising incorrect preferred routes
can cause serious damage. can cause serious damage.
While it might seem that nodes higher up in the cyclic graph
(i.e. those with lower rank) should be secured in a stronger
fashion, it is not in general easy to predict which nodes will
occupy those positions until after deployment. Issues of
redundancy and inventory control suggests that any node might
wind up in such a sensitive attack position, so all nodes need
to be equally secure.
In addition, even if it were possible to predict which nodes
will occupy positions of lower rank and provision them with
stronger security mechanisms, in the absense of a strong
authorization model, any node could advertise an incorrect
preferred route.
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 limited number of applications require On the one hand, only a limited number of applications require
the support of mobile nodes, e.g., a home LLN that includes the support of mobile nodes, e.g., a home LLN that includes
skipping to change at page 16, line 21 skipping to change at page 16, line 41
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. o Overload attacks. (Section 8.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.
7.2. Network Traffic Forwarding Disruption 7.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;
skipping to change at page 17, line 26 skipping to change at page 18, line 4
Good Link \ | | Good Link \ | |
To Node_5 \ | | To Node_5 \ | |
\ 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|
(c) Sinkhole (c) Sinkhole
Figure 4: Selective Forwarding, Wormhole, and Sinkhole Attacks Figure 4: Selective Forwarding, Wormhole, and Sinkhole Attacks
These attacks are generally done to both control plane and forwarding
plane traffic. A system that prevents control plane traffic (RPL
messages) from being diverted in these ways will also prevent actual
data from being diverted.
7.3. Communications Resource Disruption 7.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
skipping to change at page 18, line 30 skipping to change at page 19, line 11
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;
o Routing information replay attacks; o Routing information replay attacks;
o HELLO flood attacks; o HELLO flood attacks;
o Overload attacks. o Overload attacks. (Section 8.3.2)
8. Countermeasures 8. 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 developing capabilities within this analysis provides the basis for developing capabilities within
ROLL protocols to deter the identified attacks and mitigate the ROLL protocols 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. However, the considerations here services are more readily visible. However, the considerations here
skipping to change at page 19, line 5 skipping to change at page 19, line 34
appropriate for a secured ROLL protocol. appropriate for a secured ROLL protocol.
8.1. Confidentiality Attack Countermeasures 8.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
sniffing 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.
8.1.1. Countering Deliberate Exposure Attacks 8.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.
A prerequisite to countering this attack is to ensure that the A prerequisite to countering this attack is to ensure that the
skipping to change at page 19, line 35 skipping to change at page 20, line 16
with another peer without the knowledge of both communicating with another peer without the knowledge of both communicating
peerscan. For a deliberate exposure attack to succeed, the comprised peerscan. For a deliberate exposure attack to succeed, the comprised
node will need to more overt and take independent actions in order to node will need to 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.
8.1.2. Countering Sniffing Attacks 8.1.2. Countering Passive Wiretapping Attacks
A sniffing attack seeks to breach routing confidentiality through A passive wiretap attack seeks to breach routing confidentiality
passive, direct analysis and processing of the information exchanges through passive, direct analysis and processing of the information
between nodes. exchanges between nodes.
Sniffing attacks can be directly countered through the use of data Passive wiretap attacks can be directly countered through the use of
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 strength of the encryption algorithm and encryption algorithm. The strength of the encryption algorithm and
session key sizes will determine the minimum requirement for an session key sizes will determine the minimum requirement for an
attacker mounting this passive security attack. The possibility of attacker mounting this passive security attack. The possibility of
incorporating options for security level and algorithms is further incorporating options for security level and algorithms is further
considered in Section 9.5. Because of the resource constraints of considered in Section 9.5. Because of the resource constraints of
LLN devices, symmetric (private) key encryption will provide the best LLN devices, symmetric (private) key encryption will provide the best
trade-off in terms of node and channel resource overhead and the trade-off in terms of node and channel resource overhead and the
level of security achieved. This will of course not preclude the use level of security achieved. This will of course not preclude the use
skipping to change at page 20, line 45 skipping to change at page 21, line 25
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-3 routing information read the immutable source/destination layer-3 routing information
that must remain unencrypted to permit network routing. that must remain unencrypted to permit network routing.
Alternatively, attacks can be mounted through the injection of
unauthorized discovery traffic into the network. By implementing
authentication measures between communicating nodes, active traffic
analysis attacks can be prevented within the LLN thereby reducing
confidentiality vulnerabilities to those associated with passive
analysis.
One way in which passive traffic analysis attacks can be muted is One way in which passive traffic analysis attacks can be muted is
through the support of load balancing that allows traffic to a given through the support of load balancing that allows traffic to a given
destination to be sent along diverse routing paths. Where the destination to be sent along diverse routing paths. Where the
routing protocol supports load balancing along multiple links at each routing protocol supports load balancing along multiple links at each
node, the number of routing permutations in a wide area network node, the number of routing permutations in a wide area network
surges thus increasing the cost of traffic analysis. ROLL does not surges thus increasing the cost of traffic analysis. ROLL does not
generally support multi-path routing within a single DODAG. Multiple generally support multi-path routing within a single DODAG. Multiple
DODAGs are supported in the protocol, but few deployments will have DODAGs are supported in the protocol, but few deployments will have
space for more than half a dozen, and there are at present no clear space for more than half a dozen, and there are at present no clear
ways to multiplex traffic for a single application across multiple ways to multiplex traffic for a single application across multiple
skipping to change at page 23, line 16 skipping to change at page 23, line 33
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.
The countering of identity attacks need to ensure the authenticity
and liveliness of the parties of a message exchange. The means may
be through the use of shared key- or public key-based authentication
scheme. On the one hand, the large-scale nature of the LLNs makes
the network-wide shared key scheme undesirable from a security
perspective; on the other hand, public-key based approaches generally
require more computational resources. Each system will need to make
trade-off decisions based on its security requirements. As an
example, [Wander2005] compared the energy consumption between two
public-key algorithms on a low-power microcontroller, with reference
to a symmetric-key algorithm and a hash algorithm.
8.2.4. Countering Routing Information Replay Attacks 8.2.4. Countering Routing Information Replay Attacks
In routing, message replay can result in false topology and/or In many routing protocols, message replay can result in false
routes. The counter of replay attacks needs to ensure the freshness topology and/or routes. This is often counted with some kind of
of the message. On the one hand, there are a number of mechanisms counter to ensure the freshness of the message. Replay of a current,
commonly used for countering replay, e.g., with a counter. On the literal RPL message are in general idempotent to the topology. An
other hand, the choice should take into account how a particular older (lower DODAGVersionNumber) message, if replayed would be
mechanism is made available in an LLN. For example, many LLNs have a rejected as being stale. The trickle algorithm further dampens the
central source of time and have it distributed by relaying, such that affect of any such replay, as if the message was current, then it
secured time distribution becomes a prerequisite of using would contain the same information as before, and it would cause no
timestamping to counter replay. network changes.
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
must be assumed to occur naturally.
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
change in apparent power might change the metrics through changes to
the ETX and therefore might affect the routing even though the
contents of the packet were never changed. Any replay which appears
to be different should be analyzed as a Selective Forwarding Attack,
Sinkhole Attack or Wormhole Attack.
8.2.5. Countering Byzantine Routing Information Attacks 8.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
skipping to change at page 25, line 4 skipping to change at page 25, line 19
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 8.2.3 and as a replay attack, as was addressed in Section 8.2.3 and
Section 8.2.4, respectively. Section 8.2.4, respectively.
8.3.1. Countering HELLO Flood Attacks and ACK Spoofing Attacks 8.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.
The origin of facilitating a HELLO flood attack lies in the fact that A HELLO attack mounted against RPL would involve sending out (or
many routing protocols require nodes to send HELLO packets either replaying) DIO messages by the attacker. Lower power LLN nodes might
upon joining or in regular intervals so as to announce or confirm then attempt to join the DODAG at a lower rank than they would
their existence to the network. Those nodes that receive the HELLO otherwise.
packet assume that they are indeed neighbors.
With this in mind, a malicious node can send or replay HELLO packets
using, e.g., a higher transmission power. That creates the false
illusion of being a neighbor to an increased number of nodes in the
network, thereby effectively increasing its unidirectional
neighborhood cardinality. The high quality of the falsely advertised
link may coerce nodes to route data via the malicious node. However,
those affected nodes, for which the malicious node is in fact
unreachable, never succeed in their delivery and the packets are
effectively dropped. The symptoms are hence similar to those of a
sinkhole, wormhole and selective forwarding attack.
A malicious HELLO flood attack clearly distorts the network topology.
It thus affects protocols building and maintaining the network
topology as well as routing protocols as such, since the attack is
primarily targeted on protocols that require sharing of information
for topology maintenance or flow control.
To counter HELLO flood attacks, several mutually non-exclusive
methods are feasible:
o restricting neighborhood cardinality; The most effective method from [I-D.suhopark-hello-wsn] is the verify
bidirectionality. A number of layer-2 links are arranged in
controller/spoke arrangements, and continuously are validating
connectivity at layer 2.
o facilitating multipath routing; In addition, in order to calculate metrics, the ETX must be computed,
and this involves, in general, sending a number of messages between
nodes which are believed to be adjacent.
[I-D.kelsey-intarea-mesh-link-establishment] is one such protocol.
o verifying bidirectionality. 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
bidirectionality at the control plane.
Restricting the neighborhood cardinality prevents malicious nodes As discussed in section 5.1, [I-D.suhopark-hello-wsn] a receiver with
from having an extended set of neighbors beyond some tolerated a sensitive receiver could well hear the DAOs, and even send DAO-ACKs
threshold and thereby preventing topologies to be built where as well. Such a node is a form of WormHole attack.
malicious nodes have a false neighborhood set. Furthermore, as shown
in [I-D.suhopark-hello-wsn], if the routing protocol supports
multiple paths from a sensing node towards several LBRs then HELLO
flood attacks can also be diminished; however, the energy-efficiency
of such approach is clearly sub-optimal. Finally, verifying that the
link is truly bidirectional by means of, e.g., an ACK handshake and
appropriate security measures ensures that a communication link is
only established if not only the affected node is within range of the
malicious node but also vice versa. Whilst this does not really
eliminate the problem of HELLO flooding, it greatly reduces the
number of affected nodes and the probability of such an attack
succeeding.
As for the latter, the adversary may spoof the ACK messages to These attacks are also all easily defended against using either
convince the affected node that the link is truly bidirectional and layer-2 or layer-3 authentication. Such an attack could only be made
thereupon drop, tunnel or selectively forward messages. Such ACK against a completely open network (such as might be used for
spoofing attack is possible if the malicious node has a receiver provisioning new nodes), or by a compromised node.
which is significantly more sensitive than that of a normal node,
thereby effectively extending its range. Since an ACK spoofing
attack facilitates a HELLO flood attack, similar countermeasure are
applicable here. Viable counter and security measures for both
attacks have been exposed in [I-D.suhopark-hello-wsn]
8.3.2. Countering Overload Attacks 8.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.
skipping to change at page 26, line 41 skipping to change at page 26, line 26
depleting the energy of an LLN node is to have the malicious node depleting the energy of an LLN node is to have the malicious node
overload the network with irrelevant traffic. This impacts overload the network with irrelevant traffic. This impacts
availability since certain routes get congested which: availability since certain routes get congested which:
o renders them useless for affected nodes and data can hence not be o renders them useless for affected nodes and data can hence not be
delivered; delivered;
o makes routes longer as shortest path algorithms work with the o makes routes longer as shortest path algorithms work with the
congested network; congested network;
o depletes battery and energy scavenging nodes quicker and thus o depletes battery and energy scavenging nodes more quickly and thus
shortens the network's availability at large. shortens the network's availability at large.
Overload attacks can be countered by deploying a series of mutually Overload attacks can be countered by deploying a series of mutually
non-exclusive security measures: non-exclusive security measures:
o introduce quotas on the traffic rate each node is allowed to send; o introduce quotas on the traffic rate each node is allowed to send;
o isolate nodes which send traffic above a certain threshold based o isolate nodes which send traffic above a certain threshold based
on system operation characteristics; on system operation characteristics;
skipping to change at page 28, line 48 skipping to change at page 28, line 33
non-exclusive security measures: non-exclusive security measures:
o use geographical insights for flow control; o use geographical insights for flow control;
o isolate nodes which receive traffic above a certain threshold; o isolate nodes which receive traffic above a certain threshold;
o dynamically pick up next hop from set of candidates; o dynamically pick up next hop from set of candidates;
o allow only trusted data to be received and forwarded. o allow only trusted data to be received and forwarded.
Whilst most of these countermeasures have been discussed before, the Some LLNs may provide for geolocation services, often derived from
use of geographical information deserves further attention. solving triangulation equations from radio delay calculations, such
Essentially, if geographic positions of nodes are available, then the calculations could in theory be subverted by a sinkhole that
network can assure that data is actually routed towards the intended transmitted at precisely the right power in a node to node fashion.
destination and not elsewhere. On the other hand, geographic
position is a sensitive information that has security and/or privacy While geographic knowledge could help assure that traffic always went
consequences (see Section 9.1). in the physical direction desired, it would not assure that the
traffic was taking the most efficient route, as the lowest cost real
route might be match the physical topology; such as when different
parts of an LLN are connected by high-speed wired networks.
8.3.5. Countering Wormhole Attacks 8.3.5. Countering Wormhole Attacks
In wormhole attacks at least two malicious nodes shortcut or divert In wormhole attacks at least two malicious nodes claim to have a
the usual routing path by means of a low-latency out-of-band channel short path between themselves [Karlof2003]. This changes the
[Karlof2003]. This changes the availability of certain routing paths availability of certain routing paths and hence constitutes a serious
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. In conjunction the intrusion or where messages are replayed, etc.
with selective forwarding, wormhole attacks can create race
conditions which impact topology maintenance, routing protocols as In conjunction with selective forwarding, wormhole attacks can create
well as any security suits built on "time of check" and "time of race conditions which impact topology maintenance, routing protocols
as well as any security suits built on "time of check" and "time of
use". use".
Wormhole attacks are very difficult to detect in general but can be A pure Wormhole attack is nearly impossible to detect. A wormhole
mitigated using similar strategies as already outlined above in the which is used in order to subsequently mount another kind of attack
context of sinkhole attacks. would be defeated by defeating the other attack. A perfect wormhole,
in which there is nothing adverse that occurs to the traffic, would
be difficult to call an attack. The worst thing that a benign
wormhole can do in such a situation is to cease to operate (become
unstable), causing the network to have to recalculate routes.
A highly unstable wormhole is no different than a radio opaque (i.e.
metal) door that opens and closes a lot. RPL includes hystersis in
its objective functions [RFC6719] in an attempt to deal with frequent
changes to the ETX between nodes.
9. ROLL Security Features 9. ROLL Security Features
The assessments and analysis in Section 5 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 8 were reached without confining countermeasures presented in Section 8 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 and provides a framework for
addressing the derived set of security objectives that must be met by addressing the derived set of security objectives that must be met by
the routing protocol(s) specified by the ROLL Working Group. It the routing protocol(s) specified by the ROLL Working Group. It
skipping to change at page 30, line 45 skipping to change at page 30, line 43
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 5.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 ROLL protocol: should be protected. Thus, a secured ROLL protocol:
o MUST implement payload encryption; o MUST implement payload encryption;
o MUST provide privacy when geographic information is used (see,
e.g., [RFC3693]);
o MAY provide tunneling; o MAY provide tunneling;
o MAY provide load balancing. o MAY provide load balancing.
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. In
terms of the life time of the keys, the opportunity to periodically terms of the life time of the keys, the opportunity to periodically
change the encryption key increases the offered level of security for change the encryption key increases the offered level of security for
skipping to change at page 31, line 35 skipping to change at page 31, line 29
with the implementation of node device authentication can thus reduce with the implementation of node device authentication can thus reduce
the overhead associated with supporting data confidentiality. If a the overhead associated with supporting data confidentiality. If a
new ciphering key is concurrently generated or updated in conjunction new ciphering key is concurrently generated or updated in conjunction
with the mandatory authentication exchange occurring with each with the mandatory authentication exchange occurring with each
routing peer association, signaling exchange overhead can be reduced. routing peer association, signaling exchange overhead can be reduced.
9.2. Integrity Features 9.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, a secured ROLL protocol: To protect integrity, RPL must either run using only the Secure
versions of the messages, or must run over a layer-2 that uses
o MUST provide and verify message integrity (including integrity of channel binding between node identity and transmissions. (i.e.: a
the encrypted message when confidentiality is applied); layer-2 which has an identical network-wide transmission key can not
defend against many attacks)
o MUST verify the authenticity and liveness of both principals of a
connection (independent of the device interface over which the
information is received or accessed);
o MUST verify message sequence;
o SHOULD incorporate protocol-specific parameter validity range
checks, change increments, and message event frequency checks,
etc. as a means of countering intentional or unintentional
Byzantine threats;
o MAY incorporate external consistency checking and auditing of
routing information to protect against intentional or
unintentional Byzantine-induced network anomalies.
In conjunction with the integrity protection requirements, a secured
ROLL protocol SHOULD log, against the offending node, any security
failure that occurs after a valid integrity check. The record policy
configuration) can provide the basis for nodes to avoid initiating
routing access to the offender or be used for further system
countermeasures in the case of potential insider attacks. All
integrity security failures SHOULD be logged, where feasible, but
cannot be reliably considered as countering against the offending
source(s).
Depending on the nature of the routing protocol, e.g., distance XXX. Logging is critical, but presently impossible.
vector or link state, additional measures may be necessary when the
validity of the routing information is of concern. In the most basic
form, verification of routing peer authenticity and liveliness can be
used to build a "chain of trust" along the path the routing
information flows, such that network-wide information is validated
through the concatenation of trust established at each individual
routing peer exchange. This is particularly important in the case of
distance vector-based routing protocols, where information is updated
at intermediate nodes, In such cases, there are no direct means
within routing for a receiver to verify the validity of the routing
information beyond the current exchange; as such, nodes would need to
be able to communicate and request information from non-adjacent
peers (see [Wan2004]) to provide information integrity assurances.
With link state-based protocols, on the other hand, routing
information can be signed at the source thus providing a means for
validating information that originates beyond a routing peer.
Therefore, where necessary, a secured ROLL protocol MAY use security
auditing mechanisms that are external to routing to verify the
validity of the routing information content exchanged among routing
peers.
9.3. Availability Features 9.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 (see
Section 9.5). Where availability of the network is compromised, Section 9.5). Where availability of the network is compromised,
routing information availability will be accordingly affected. routing information availability will be accordingly affected.
However, to specifically assist in protecting routing availability: However, to specifically 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.
9.4. Key Management 9.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 ROLL security credentials. Therefore, even though not directly a ROLL 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 (including use of trusted platform modules where associated devices. Anti-tampering SHOULD be a consideration in
feasible and appropriate to the operating environment). Beyond physical design. Beyond initial credential configuration, an LLN is
initial credential configuration, an LLN is also encouraged to have also encouraged to have automatic procedures for the revocation and
automatic procedures for the revocation and replacement of the replacement of the maintained security credentials.
maintained security credentials.
Peer associations and signaling exchanges require the generation and
use of keys that MAY be derived from secret or public key exchanges
as part of the routing signaling exchange or be directly obtained
through device configuration. The routing protocol specification
MUST include mechanisms to identify and synchronize these keys.
For keys used to establish peer associations, the routing protocol(s)
specified by the ROLL Working Group SHOULD employ key management
mechanisms consistent with the guidelines given in [RFC4107]. Based
on that RFC's recommendations, many LLNs, particularly given the
intended scale and ad hoc device associations, will meet the
requirement for supporting automated key management in conjunction
with the routing protocol operation. These short-term, automated
routing session keys may be derived from pre-stored security
credentials or can be generated through key management mechanisms
that are defined as part of the routing protocol exchange. Beyond
the automated short-term keys, a long-term key management mechanism
SHOULD also be defined for changing or updating the credentials from
which short-term routing association key material is derived.
The use of a public key infrastructure (PKI), where feasible, can be
used to support authenticated short-term key management as well as
the distribution of long-term routing security keying material. Note
that where the option for a PKI is supported for security of the
routing protocol itself, the routing protocol MUST include provisions
for public key certificates to be included or referenced within
routing messages to allow a node's public key to be shared with
communicating peers. Even if the certificate itself is not
distributed by the node, there needs to be a mechanism to inform the
receiving node where to find the certificate and obtain associated
validation information; see [RFC5055] for an example of the kind of
localized PKI support that may be applied in a given LLN environment.
Where PKI systems are not feasible, the key management system MUST
support means for secure configuration, device authentication, and
adherence to secure key wrapping principles for the secure
distribution and update of device keys.
LLN routing protocols SHOULD be designed to allow the use of existing While RPL has secure modes, but some modes are impractical without
and validated key management schemes. As part of the LLN use of public key cryptography believed to be too expensive by many.
optimization, these schemes may be independent of the routing RPL layer-3 security will often depend upon existing LLN layer-2
protocol and part of the broader LLN system security specifications. security mechanisms, which provides for node authentication, but
Where the long-term key management is defined separately from the little in the way of node authorization.
routing protocol security, LLN application domains can appropriately
employ IETF-standard key management specifications. Established key
management solutions such as IKEv2 [RFC5996] or MIKEY [RFC3830],
which supports several alternative private, public key distributions
methods (see [RFC5197]), can thus be adapted for use in LLNs. For
example, see [I-D.alexander-roll-mikey-lln-key-mgmt]. Group key
management and distribution methods may also be developed based on
the architecture principles defined in MSEC [RFC4046].
9.5. Consideration on Matching Application Domain Needs 9.5. Consideration on Matching Application Domain Needs
Providing security within an LLN requires considerations that extend Providing security within an LLN requires considerations that extend
beyond routing security to the broader LLN application domain beyond routing security to the broader LLN application domain
security implementation. In other words, as routing is one component security implementation. In other words, as routing is one component
of an LLN system, the actual strength of the implemented security of an LLN system, the actual strength of the implemented security
algorithms for the routing protocol MUST be made to conform to the algorithms for the routing protocol MUST be made to conform to the
system's target level of security. The development so far takes into system's target level of security. The development so far takes into
account collectively the impacts of the issues gathered from account collectively the impacts of the issues gathered from
skipping to change at page 40, line 19 skipping to change at page 38, line 19
solutions to the threads are application and layer-2 specific, and solutions to the threads 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 kept track of the many issues that were raised during the
development of this document development of this document
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-04 (work in
progress), September 2010.
[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
Key Management", BCP 107, RFC 4107, June 2005. Key Management", BCP 107, RFC 4107, June 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
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
Hysteresis Objective Function", RFC 6719, September 2012.
13.2. Informative References 13.2. Informative References
[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
skipping to change at page 41, line 5 skipping to change at page 39, line 18
Networks and Applications, San Diego, CA, USA, pp. Networks and Applications, San Diego, CA, USA, pp.
141-150, Sept. 19 2003. 141-150, Sept. 19 2003.
[I-D.alexander-roll-mikey-lln-key-mgmt] [I-D.alexander-roll-mikey-lln-key-mgmt]
Alexander, R. and T. Tsao, "Adapted Multimedia Internet Alexander, R. and T. Tsao, "Adapted Multimedia Internet
KEYing (AMIKEY): An extension of Multimedia Internet KEYing (AMIKEY): An extension of Multimedia Internet
KEYing (MIKEY) Methods for Generic LLN Environments", KEYing (MIKEY) Methods for Generic LLN Environments",
draft-alexander-roll-mikey-lln-key-mgmt-04 (work in draft-alexander-roll-mikey-lln-key-mgmt-04 (work in
progress), September 2012. progress), September 2012.
[I-D.ietf-roll-terminology] [I-D.kelsey-intarea-mesh-link-establishment]
Vasseur, J., "Terminology in Low power And Lossy Kelsey, R., "Mesh Link Establishment", draft-kelsey-
Networks", draft-ietf-roll-terminology-04 (work in intarea-mesh-link-establishment-05 (work in progress),
progress), September 2010. February 2013.
[I-D.suhopark-hello-wsn] [I-D.suhopark-hello-wsn]
Park, S., "Routing Security in Sensor Network: HELLO Flood Park, S., "Routing Security in Sensor Network: HELLO Flood
Attack and Defense", draft-suhopark-hello-wsn-00 (work in Attack and Defense", draft-suhopark-hello-wsn-00 (work in
progress), December 2005. progress), December 2005.
[IEEE1149.1] [IEEE1149.1]
, "IEEE Standard Test Access Port and Boundary Scan , "IEEE Standard Test Access Port and Boundary Scan
Architecture", IEEE-SA Standards Board, Jun. 14 2001. Architecture", IEEE-SA Standards Board, Jun. 14 2001.
skipping to change at page 42, line 16 skipping to change at page 40, line 30
1142, February 1990. 1142, February 1990.
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997. January 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November
1998. 1998.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
"Multicast Security (MSEC) Group Key Management "Multicast Security (MSEC) Group Key Management
Architecture", RFC 4046, April 2005. Architecture", RFC 4046, April 2005.
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", RFC 4593, October 2006. Routing Protocols", RFC 4593, October 2006.
skipping to change at page 43, line 21 skipping to change at page 41, line 33
5826, April 2010. 5826, April 2010.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power and "Building Automation Routing Requirements in Low-Power and
Lossy Networks", RFC 5867, June 2010. Lossy Networks", RFC 5867, June 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5996, September 2010. 5996, September 2010.
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
Router Control Plane", RFC 6192, March 2011.
[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. 56 change blocks. 
263 lines changed or deleted 180 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/