draft-ietf-roll-security-threats-03.txt   draft-ietf-roll-security-threats-04.txt 
Networking Working Group 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: December 27, 2013 M. Dohler Expires: March 08, 2014 M. Dohler
CTTC CTTC
V. Daza V. Daza
A. Lozano A. Lozano
Universitat Pompeu Fabra Universitat Pompeu Fabra
June 25, 2013 M. Richardson
Sandelman Software Works
September 04, 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-03 draft-ietf-roll-security-threats-04
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
provide the basis of the security recommendations for incorporation provide the basis of the security recommendations for incorporation
into low-power, lossy network routing protocols. into low-power, lossy network routing protocols.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 27, 2013.
This Internet-Draft will expire on March 08, 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Considerations on ROLL Security . . . . . . . . . . . . . . . 6 3. Considerations on ROLL Security . . . . . . . . . . . . . . . 4
3.1. Routing Assets and Points of Access . . . . . . . . . . . 7 3.1. Routing Assets and Points of Access . . . . . . . . . . . 5
3.2. The ISO 7498-2 Security Reference Model . . . . . . . . . 9 3.2. The ISO 7498-2 Security Reference Model . . . . . . . . . 7
3.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 11 3.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 8
3.4. ROLL Security Objectives . . . . . . . . . . . . . . . . . 12 3.4. ROLL Security Objectives . . . . . . . . . . . . . . . . 10
4. Threat Sources . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Threat Sources . . . . . . . . . . . . . . . . . . . . . . . 12
5. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 14 5. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 12
5.1. Threats due to failures to Authenticate . . . . . . . . . 14 5.1. Threats due to failures to Authenticate . . . . . . . . . 12
5.2. Threats due to failures to Authenticate . . . . . . . . . 14 5.1.1. Node Impersonation . . . . . . . . . . . . . . . . . 12
5.3. Threats and Attacks on Confidentiality . . . . . . . . . . 14 5.1.2. Dummy Node . . . . . . . . . . . . . . . . . . . . . 13
5.3.1. Routing Exchange Exposure . . . . . . . . . . . . . . 15 5.1.3. Node Resource Spam . . . . . . . . . . . . . . . . . 13
5.3.2. Routing Information (Routes and Network Topology) 5.2. Threats and Attacks on Confidentiality . . . . . . . . . 13
Exposure . . . . . . . . . . . . . . . . . . . . . . . 15 5.2.1. Routing Exchange Exposure . . . . . . . . . . . . . . 13
6. Threats and Attacks on Integrity . . . . . . . . . . . . . . . 16 5.2.2. Routing Information (Routes and Network Topology)
6.1. Routing Information Manipulation . . . . . . . . . . . . . 16 Exposure . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Node Identity Misappropriation . . . . . . . . . . . . . . 17 6. Threats and Attacks on Integrity . . . . . . . . . . . . . . 14
7. Threats and Attacks on Availability . . . . . . . . . . . . . 17 6.1. Routing Information Manipulation . . . . . . . . . . . . 14
7.1. Routing Exchange Interference or Disruption . . . . . . . 17 6.2. Node Identity Misappropriation . . . . . . . . . . . . . 15
7.2. Network Traffic Forwarding Disruption . . . . . . . . . . 18 7. Threats and Attacks on Availability . . . . . . . . . . . . . 15
7.3. Communications Resource Disruption . . . . . . . . . . . . 19 7.1. Routing Exchange Interference or Disruption . . . . . . . 16
7.4. Node Resource Exhaustion . . . . . . . . . . . . . . . . . 20 7.2. Network Traffic Forwarding Disruption . . . . . . . . . . 16
8. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 20 7.3. Communications Resource Disruption . . . . . . . . . . . 17
8.1. Confidentiality Attack Countermeasures . . . . . . . . . . 21 7.4. Node Resource Exhaustion . . . . . . . . . . . . . . . . 17
8.1.1. Countering Deliberate Exposure Attacks . . . . . . . . 21 8. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 18
8.1.2. Countering Sniffing Attacks . . . . . . . . . . . . . 21 8.1. Confidentiality Attack Countermeasures . . . . . . . . . 18
8.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 22 8.1.1. Countering Deliberate Exposure Attacks . . . . . . . 19
8.1.4. Countering Physical Device Compromise . . . . . . . . 23 8.1.2. Countering Sniffing Attacks . . . . . . . . . . . . . 19
8.1.5. Countering Remote Device Access Attacks . . . . . . . 25 8.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 20
8.2. Integrity Attack Countermeasures . . . . . . . . . . . . . 26 8.1.4. Countering Remote Device Access Attacks . . . . . . . 21
8.2.1. Countering Unauthorized Modification Attacks . . . . . 26 8.2. Integrity Attack Countermeasures . . . . . . . . . . . . 21
8.2.2. Countering Overclaiming and Misclaiming Attacks . . . 26 8.2.1. Countering Unauthorized Modification Attacks . . . . 22
8.2.3. Countering Identity (including Sybil) Attacks . . . . 27 8.2.2. Countering Overclaiming and Misclaiming Attacks . . . 22
8.2.4. Countering Routing Information Replay Attacks . . . . 27 8.2.3. Countering Identity (including Sybil) Attacks . . . . 22
8.2.5. Countering Byzantine Routing Information Attacks . . . 27 8.2.4. Countering Routing Information Replay Attacks . . . . 23
8.3. Availability Attack Countermeasures . . . . . . . . . . . 28 8.2.5. Countering Byzantine Routing Information Attacks . . 23
8.3. Availability Attack Countermeasures . . . . . . . . . . . 24
8.3.1. Countering HELLO Flood Attacks and ACK Spoofing 8.3.1. Countering HELLO Flood Attacks and ACK Spoofing
Attacks . . . . . . . . . . . . . . . . . . . . . . . 29 Attacks . . . . . . . . . . . . . . . . . . . . . . . 24
8.3.2. Countering Overload Attacks . . . . . . . . . . . . . 30 8.3.2. Countering Overload Attacks . . . . . . . . . . . . . 26
8.3.3. Countering Selective Forwarding Attacks . . . . . . . 31 8.3.3. Countering Selective Forwarding Attacks . . . . . . . 27
8.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 32 8.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 28
8.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 33 8.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 29
9. ROLL Security Features . . . . . . . . . . . . . . . . . . . . 33 9. ROLL Security Features . . . . . . . . . . . . . . . . . . . 29
9.1. Confidentiality Features . . . . . . . . . . . . . . . . . 34 9.1. Confidentiality Features . . . . . . . . . . . . . . . . 30
9.2. Integrity Features . . . . . . . . . . . . . . . . . . . . 35 9.2. Integrity Features . . . . . . . . . . . . . . . . . . . 31
9.3. Availability Features . . . . . . . . . . . . . . . . . . 36 9.3. Availability Features . . . . . . . . . . . . . . . . . . 32
9.4. Key Management . . . . . . . . . . . . . . . . . . . . . . 37 9.4. Key Management . . . . . . . . . . . . . . . . . . . . . 33
9.5. Consideration on Matching Application Domain Needs . . . . 38 9.5. Consideration on Matching Application Domain Needs . . . 34
9.5.1. Security Architecture . . . . . . . . . . . . . . . . 38 9.5.1. Security Architecture . . . . . . . . . . . . . . . . 34
9.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 41 9.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 37
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
11. Security Considerations . . . . . . . . . . . . . . . . . . . 43 11. Security Considerations . . . . . . . . . . . . . . . . . . . 39
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
13.1. Normative References . . . . . . . . . . . . . . . . . . . 44 13.1. Normative References . . . . . . . . . . . . . . . . . . 40
13.2. Informative References . . . . . . . . . . . . . . . . . . 44 13.2. Informative References . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
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 5, line 25 skipping to change at page 4, line 12
simply safety considerations (e.g., with gas meters). As a simply safety considerations (e.g., with gas meters). As a
consequence, the resulting networks are more prone to loss of traffic consequence, the resulting networks are more prone to loss of traffic
and other vulnerabilities. The proliferation of these low-power and and other vulnerabilities. The proliferation of these low-power and
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 process requires two steps. First, the analysis will be used to
identify pertinent security issues. Second, it will facilitate both identify pertinent security issues. The second step is to identify
the assessment of a protocol's security threats and the necessary countermeasures to secure the ROLL protocols. As there are
identification of necessary countermeasures to secure the ROLL multiple ways to solve the problem and the specific tradeoffs are
protocols. The approach adopted is a five step process, 1) examine deployment specific, the specific countermeasure to be used is
security issues in ROLL, 2) describe the threat sources, 3) analyze detailed in applicatbility statements.
threats and attacks, 4) consider countermeasures, and 5) provide
recommendations for securing ROLL.
This document uses [IS07498-2] model, which includes Authentication, This document uses [IS07498-2] model, which includes Authentication,
Access Control, Data Confidentiality, Data Integrity, and Non- Access Control, Data Confidentiality, Data Integrity, and Non-
Repudiation but to which Availability is added. Repudiation but to which Availability is added.
spt: If this is just about control plane security then we should say All of this document concerns itself with control plane traffic only.
so right up front.
2. Terminology 2. Terminology
This document adopts the terminology defined in [RFC6550] and in This document adopts the terminology defined in [RFC6550], in
[RFC4949], with the following addition: [RFC4949], and in [I-D.ietf-roll-terminology].
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
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
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, authentication, integrity, and potentially confidentiality injectors, and potentially confidentiality of routing data, but also
of routing data, but also proper order of state changes through proper order of state changes through timeliness, since seriously
timeliness, since seriously delayed state changes, such as commands delayed state changes, such as commands or updates of routing tables,
or updates of routing tables, may negatively impact system operation. may negatively impact system operation. A security assesment can
A security assesment can therefore begin with a focus on the therefore begin with a focus on the assets [RFC4949] that may be the
assetsRFC4949 [RFC4949]that may be the target of the state changes target of the state changes and the access points in terms of
and the access points in terms of interfaces and protocol exchanges interfaces and protocol exchanges through which such changes may
through which such changes may occur. In the case of routing occur. In the case of routing security the focus is directed towards
security the focus is directed towards the elements associated with the elements associated with the establishment and maintenance of
the establishment and maintenance of network connectivity. network connectivity.
This section sets the stage for the development of the analysis by This section sets the stage for the development of the analysis by
applying the systematic approach proposed in [Myagmar2005] to the applying the systematic approach proposed in [Myagmar2005] to the
routing security, while also drawing references from other reviews routing security, while also drawing references from other reviews
and assessments found in the literature, particularly, [RFC4593] and and assessments found in the literature, particularly, [RFC4593] and
[Karlof2003]. The subsequent subsections begin with a focus on the [Karlof2003]. The subsequent subsections begin with a focus on the
elements of a generic routing process that is used to establish elements of a generic routing process that is used to establish
routing assets and points of access to the routing functionality. routing assets and points of access to the routing functionality.
Next, the ISO 7498-2 security model is briefly described. Then, Next, the [ISO.7498-2.1988] 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 is an important system resource (including information, An asset is an important system resource (including information,
process, or physical resource), the access to, corruption or loss of process, or physical resource), the access to, corruption or loss of
which adversely affects the system. In the control plane context, an which adversely affects the system. In the control plane context, an
asset is information about the network, processes used to manage and asset is information about the network, processes used to manage and
manipulate this data, and the physical devices on which this data is manipulate this data, and the physical devices on which this data is
stored and manipulated. The corruption or loss of these assets may stored and manipulated. The corruption or loss of these assets may
adversely impact the control plane of the network. Within the same adversely impact the control plane of the network. Within the same
skipping to change at page 9, line 39 skipping to change at page 7, line 31
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 authentication, access control, data primary issues of authentication, access control, data
confidentiality, data integrity, and non-repudiation. In the context confidentiality, data integrity, and non-repudiation. In the context
of ROLL of ROLL
Authentication Authentication
Authentication involves the mutual authentication of the Authentication involves the mutual authentication of the
routing peers prior to exchanging route information (i.e., peer routing peers prior to exchanging route information (i.e., peer
authentication) as well as ensuring that the source of the authentication) as well as ensuring that the source of the
route data is from the peer (i.e., data origin authentication). route data is from the peer (i.e., data origin authentication).
From 5478 LLNs can be drained by unauthenticated peers before [RFC5548] points out that LLNs can be drained by
confirguratin From 5673 This requires availability of open and unauthenticated peers before configuration. [RFC5673] requires
untrusted side channels for new joiners, and it requires strong availability of open and untrusted side channels for new
and automated authentication so that networks can automatically joiners, and it requires strong and automated authentication so
accept or reject new joiners. spt: Do we need more here? that networks can automatically accept or reject new joiners.
Access Control Access Control
Access Control provides protection against unauthorized use of Access Control provides protection against unauthorized use of
the asset, and deals with the authorization of a node. the asset, and deals with the authorization of a node.
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 entails the protection of routing information and Integrity entails the protection of routing information and
routing neighbor maintenance exchanges, as well as derived routing neighbor maintenance exchanges, as well as derived
skipping to change at page 10, line 27 skipping to change at page 8, line 20
beyond the routing protocol. beyond the routing protocol.
Non-repudiation Non-repudiation
Non-repudiation is the assurance that the transmission and/or Non-repudiation is the assurance that the transmission and/or
reception of a message cannot later be denied. The service of reception of a message cannot later be denied. The service of
non-repudiation applies after-the-fact and thus relies on the non-repudiation applies after-the-fact and thus relies on the
logging or other capture of on-going message exchanges and logging or other capture of on-going message exchanges and
signatures. Applied to routing, non-repudiation is not an signatures. Applied to routing, non-repudiation is not an
issue because it does not apply to routing protocols, which are issue because it does not apply to routing protocols, which are
machine-to-machine protocols. Further, with the LLN machine-to-machine protocols. Further, with the LLN
application domains as described in RFC5548 [RFC5867], application domains as described in [RFC5867] and [RFC5548],
proactive measures are much more critical than retrospective proactive measures are much more critical than retrospective
protections. Finally, given the significant practical limits protections. Finally, given the significant practical limits
to on-going routing transaction logging and storage and to on-going routing transaction logging and storage and
individual device digital signature verification for each individual device digital signature verification for each
exchange, non-repudiation in the context of routing is an exchange, non-repudiation in the context of routing is an
unsupportable burden that bears no further considered as a ROLL unsupportable burden that bears no further considered as a ROLL
security issue. security issue.
It is recognized that, besides those security issues captured in the It is recognized that, besides those security issues captured in the
ISO 7498-2 model, availability, is a security requirement: ISO 7498-2 model, availability, is a security requirement:
skipping to change at page 11, line 24 skipping to change at page 9, line 21
Limited energy, memory, and processing node resources Limited energy, memory, and processing node resources
As a consequence of these constraints, there is an even more As a consequence of these constraints, there is an even more
critical need than usual for a careful study of trade-offs on critical need than usual for a careful study of trade-offs on
which and what level of security services are to be afforded which and what level of security services are to be afforded
during the system design process. The chosen security during the system design process. The chosen security
mechanisms also needs to work within these constraints. mechanisms also needs to work within these constraints.
Synchronization of security states with sleepy nodes is yet Synchronization of security states with sleepy nodes is yet
another issue. another issue.
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 make manual on-site
deployment can see several hundreds of thousands of nodes, as configuration unlikely. For example, an urban deployment can
well as the generally low level of expertise expected of the see several hundreds of thousands of nodes being installed by
installers, make manual on-site configuration unlikely. many installers with a low level of expertise. Nodes may be
Prolonged rollout and delayed addition of nodes, which may be installed and not activated for many years, and additional
from old inventory, over the lifetime of the network, also nodes may be added later on, which may be from old inventory.
complicate the operations of key management. The lifetime of the network is measured in decades, and this
complicates the operation of key management.
Autonomous operations Autonomous operations
Self-forming and self-organizing are commonly prescribed Self-forming and self-organizing are commonly prescribed
requirements of LLNs. In other words, a routing protocol requirements of LLNs. In other words, a routing protocol
designed for LLNs needs to contain elements of ad hoc designed for LLNs needs to contain elements of ad hoc
networking and in most cases cannot rely on manual networking and in most cases cannot rely on manual
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.
skipping to change at page 12, line 13 skipping to change at page 10, line 11
can cause serious 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 limited number of applications require
support of mobile nodes, e.g., a home LLN that includes nodes the support of mobile nodes, e.g., a home LLN that includes
on wearable health care devices or an industry LLN that nodes on wearable health care devices or an industry LLN that
includes nodes on cranes and vehicles. On the other hand, if a includes nodes on cranes and vehicles. On the other hand, if a
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.
Additionally nodes may appear to move from one side of a wall
to another without any actual motion involved, the result of
changes to electromagnetic properties, such as opening and
closing of a metal door.
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 variety of application areas may impact security. operations, and variety of application areas may impact security.
However, it is the combinations of these factors that particularly However, it is the combinations of these factors that particularly
stress the security concerns. For instance, securing routing for a stress the security concerns. For instance, securing routing for a
skipping to change at page 14, line 7 skipping to change at page 12, line 9
Each individual system's use and environment will dictate how the Each individual system's use and environment will dictate how the
above objectives are applied, including the choices of security above objectives are applied, including the choices of security
services as well as the strengths of the mechanisms that must be services as well as the strengths of the mechanisms that must be
implemented. The next two sections take a closer look at how the implemented. The next two sections take a closer look at how the
ROLL security objectives may be compromised and how those potential ROLL security objectives may be compromised and how those potential
compromises can be countered. compromises can be countered.
4. Threat Sources 4. Threat Sources
provides a detailed review of the threat sources: outsiders and [RFC4593] provides a detailed review of the threat sources: outsiders
byzantine. ROLL has the same threat sources. [RFC4593] and byzantine. ROLL has the same threat sources.
5. Threats and Attacks 5. Threats and Attacks
This section outlines general categories of threats under the ISO This section outlines general categories of threats under the ISO
7498-2 model and highlights the specific attacks in each of these 7498-2 model and highlights the specific attacks in each of these
categories for ROLL. As defined in [RFC4949], a threat is "a categories for ROLL. As defined in [RFC4949], a threat is "a
potential for violation of security, which exists when there is a potential for violation of security, which exists when there is a
circumstance, capability, action, or event that could breach security circumstance, capability, action, or event that could breach security
and cause harm." and cause harm."
skipping to change at page 14, line 32 skipping to change at page 12, line 34
security services and violate the security policy of a system." security services and violate the security policy of a system."
The subsequent subsections consider the threats and the attacks that The subsequent subsections consider the threats and the attacks that
can cause security breaches under the ISO 7498-2 model to the routing can cause security breaches under the ISO 7498-2 model to the routing
assets and via the routing points of access identified in assets and via the routing points of access identified in
Section 3.1. The assessment steps through the security concerns of Section 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 source of the attacks is assumed to be from either literature. The source of the attacks is assumed to be from either
inside or outside attackers Section 4, whose capabilities may be inside or outside attackers. The capability these attackes may be
limited to node-equivalent or more sophisticated computing platforms. limited to node-equivalent, but also to more sophisticated computing
platforms.
5.1. Threats due to failures to Authenticate 5.1. Threats due to failures to Authenticate
5.2. Threats due to failures to Authenticate 5.1.1. Node Impersonation
5.3. Threats and Attacks on Confidentiality If an attacker can join a network with any identify, then it may be
able to assume the role of a legitimate (and existing node). It may
be able to report false readings (in metering applications), or
provide inappropriate control messages (in control systems involving
actuators) if the security of the application is leveraged from the
security of the routing system.
In other systems where there is separate application layer security,
the ability to impersonate a node would permit an attacker to direct
traffic to itself, which facilitates on-path attacks including
replaying, delaying, or duplicating control messages.
5.1.2. Dummy Node
If an attacker can join a network with any identify, then it can
pretend to be a legitimate node, receiving any service legitimate
nodes receive. It may also be able to report false readings (in
metering applications), or provide inappropriate authorizations (in
control systems involving actuators), or perform any other attacks
that are facilitated by being able to direct traffic towards itself.
5.1.3. Node Resource Spam
If an attacker can join a network with any identify, then it can
continously do so, draining down the resources of the network to
store identity and routing information, potentionally forcing
legitimate nodes of the network.
5.2. Threats and Attacks on Confidentiality
The assessment in Section 3.2 indicates that there are threat actions The assessment in Section 3.2 indicates that there are threat actions
against the confidentiality of routing information at all points of against the confidentiality of routing information at all points of
access. The confidentiality threat consequences is disclosure, see access. The confidentiality threat consequences is disclosure, see
Section 3.1.2 of [RFC4593]. For ROLL this is the disclosure of Section 3.1.2 of [RFC4593]. For ROLL this is the disclosure of
routing information either by evesdropping on the communication routing information either by evesdropping on the communication
exchanges between routing nodes or by direct access of node's exchanges between routing nodes or by direct access of node's
information. information.
5.3.1. Routing Exchange Exposure 5.2.1. Routing Exchange Exposure
Routing exchanges include both routing information as well as Routing exchanges include both routing information as well as
information associated with the establishment and maintenance of information associated with the establishment and maintenance of
neighbor state information. As indicated in Section 3.1, the neighbor state information. As indicated in Section 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.
The routing exchanges will contain reachability information, which The routing exchanges will contain reachability information, which
would identify the relative importance of different nodes in the would identify the relative importance of different nodes in the
network. Nodes higher up in the DODAG, to which more streams of network. Nodes higher up in the DODAG, to which more streams of
information flow, would be more interesting targets for other information flow, would be more interesting targets for other
attacks, and routing exchange exposures can identify them. attacks, and routing exchange exposures can identify them.
5.3.2. Routing Information (Routes and Network Topology) Exposure 5.2.2. Routing Information (Routes and Network Topology) Exposure
Routes (which may be maintained in the form of the protocol Routes (which may be maintained in the form of the protocol
forwarding table) and neighbor topology information are the products forwarding table) and neighbor topology information are the products
of the routing process that are stored within the node device of the routing process that are stored within the node device
databases. databases.
The exposure of this information will allow attachers to gain direct The exposure of this information will allow attachers to gain direct
access to the configuration and connectivity of the network thereby access to the configuration and connectivity of the network thereby
exposing routing to targeted attacks on key nodes or links. Since exposing routing to targeted attacks on key nodes or links. Since
routes and neighbor topology information is stored within the node routes and neighbor topology information is stored within the node
device, threats or attacks on the confidentiality of the information device, threats or attacks on the confidentiality of the information
skipping to change at page 18, line 18 skipping to change at page 16, line 39
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;
o Wormhole attacks; |Node_1|--(msg1|msg2|msg3)-->|Attacker|--(msg1|msg3)-->|Node_2|
o Sinkhole attacks. (a) Selective Forwarding
For reference, Figure 2 depicts the above listed three types of Figure 2: Selective Forwarding
attacks.
|Node_1|--(msg1|msg2|msg3)-->|Attacker|--(msg1|msg3)-->|Node_2| o Wormhole attacks;
(a) Selective Forwarding |Node_1|-------------Unreachable---------x|Node_2|
| ^
| Private Link |
'-->|Attacker_1|===========>|Attacker_2|--'
|Node_1|-------------Unreachable---------x|Node_2| (b) Wormhole
| ^
| Private Link |
'-->|Attacker_1|===========>|Attacker_2|--'
(b) Wormhole Figure 3: Wormhole Attacks
|Node_1| |Node_4| o Sinkhole attacks.
| |
`--------. |
Falsify as \ |
Good Link \ | |
To Node_5 \ | |
\ V V
|Node_2|-->|Attacker|--Not Forwarded---x|Node_5|
^ ^ \
| | \ Falsify as
| | \Good Link
/ | To Node_5
,-------' |
| |
|Node_3| |Node_i|
(c) Sinkhole |Node_1| |Node_4|
| |
`--------. |
Falsify as \ |
Good Link \ | |
To Node_5 \ | |
\ V V
|Node_2|-->|Attacker|--Not Forwarded---x|Node_5|
^ ^ \
| | \ Falsify as
| | \Good Link
/ | To Node_5
,-------' |
| |
|Node_3| |Node_i|
Figure 2: Selective Forwarding, Wormhole, and Sinkhole Attacks (c) Sinkhole
Figure 4: Selective Forwarding, Wormhole, and Sinkhole Attacks
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
skipping to change at page 21, line 47 skipping to change at page 19, line 39
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 Sniffing Attacks
A sniffing attack seeks to breach routing confidentiality through A sniffing attack seeks to breach routing confidentiality through
passive, direct analysis and processing of the information exchanges passive, direct analysis and processing of the information exchanges
between nodes. A sniffing attack in an LLN that is not based on a between nodes.
physical device compromise will rely on the attacker attempting to
directly derive information from the over-the-shared-medium routing/
topology communication exchange (neighbor discovery exchanges may of
necessity be conducted in the clear thus limiting the extent to which
the information can be kept confidential).
Sniffing attacks can be directly countered through the use of data Sniffing attacks can be directly countered through the use of data
encryption for all routing exchanges. Only when a validated and 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
skipping to change at page 22, line 39 skipping to change at page 20, line 27
routing protection. This session key shall be applied in conjunction routing protection. This session key shall be applied in conjunction
with an encryption algorithm that has been publicly vetted and where with an encryption algorithm that has been publicly vetted and where
applicable approved for the level of security desired. Algorithms applicable approved for the level of security desired. Algorithms
such as the Advanced Encryption Standard (AES) [FIPS197], adopted by such as the Advanced Encryption Standard (AES) [FIPS197], adopted by
the U.S. government, or Kasumi-Misty [Kasumi3gpp], adopted by the the U.S. government, or Kasumi-Misty [Kasumi3gpp], adopted by the
3GPP 3rd generation wireless mobile consortium, are examples of 3GPP 3rd generation wireless mobile consortium, are examples of
symmetric-key algorithms capable of ensuring robust confidentiality symmetric-key algorithms capable of ensuring robust confidentiality
for routing exchanges. The key length, algorithm and mode of for routing exchanges. The key length, algorithm and mode of
operation will be selected as part of the overall security trade-off operation will be selected as part of the overall security trade-off
that also achieves a balance with the level of confidentiality that also achieves a balance with the level of confidentiality
afforded by the physical device in protecting the routing assets (see afforded by the physical device in protecting the routing assets.
Section 8.1.4 below).
As with any encryption algorithm, the use of ciphering As with any encryption algorithm, the use of ciphering
synchronization parameters and limitations to the usage duration of synchronization parameters and limitations to the usage duration of
established keys should be part of the security specification to established keys should be part of the security specification to
reduce the potential for brute force analysis. reduce the potential for brute force analysis.
8.1.3. Countering Traffic Analysis 8.1.3. Countering Traffic Analysis
Traffic analysis provides an indirect means of subverting Traffic analysis provides an indirect means of subverting
confidentiality and gaining access to routing information by allowing confidentiality and gaining access to routing information by allowing
an attacker to indirectly map the connectivity or flow patterns an attacker to indirectly map the connectivity or flow patterns
(including link-load) of the network from which other attacks can be (including link-load) of the network from which other attacks can be
mounted. The traffic analysis attack on an LLN, especially one mounted. The traffic analysis attack on an LLN, especially one
founded on shared medium, is passive and relies on the ability to founded on shared medium, is passive and relies on the ability to
read the immutable source/destination routing information that must read the immutable source/destination layer-3 routing information
remain unencrypted to permit network routing. Alternatively, attacks that must remain unencrypted to permit network routing.
can be mounted through the injection of unauthorized discovery
traffic into the network. By implementing authentication measures Alternatively, attacks can be mounted through the injection of
between communicating nodes, active traffic analysis attacks can be unauthorized discovery traffic into the network. By implementing
prevented within the LLN thereby reducing confidentiality authentication measures between communicating nodes, active traffic
vulnerabilities to those associated with passive analysis. 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. Network surges thus increasing the cost of traffic analysis. ROLL does not
analysis through this passive attack will require a wider array of generally support multi-path routing within a single DODAG. Multiple
analysis points and additional processing on the part of the DODAGs are supported in the protocol, but few deployments will have
attacker. Note however that where network traffic is dispersed as a space for more than half a dozen, and there are at present no clear
countermeasure there may be implications beyond routing with regard ways to multiplex traffic for a single application across multiple
to general traffic confidentiality. Another approach to countering DODAGs.
passive traffic analysis could be for nodes to maintain constant
amount of traffic to different destinations through the generation of Another approach to countering passive traffic analysis could be for
arbitrary traffic flows; the drawback of course would be the nodes to maintain constant amount of traffic to different
consequent overhead. In LLNs, the diverse radio connectivity and destinations through the generation of arbitrary traffic flows; the
dynamic links (including potential frequency hopping), or a complex drawback of course would be the consequent overhead.
wiring system hidden from sight, will help to further mitigate
traffic analysis attacks when load balancing is also implemented.
The only means of fully countering a traffic analysis attack is The only means of fully countering a traffic analysis attack is
through the use of tunneling (encapsulation) where encryption is through the use of tunneling (encapsulation) where encryption is
applied across the entirety of the original packet source/destination applied across the entirety of the original packet source/destination
addresses. With tunneling there is a further requirement that the addresses. Deployments which use layer-2 security that includes
encapsulating intermediate nodes apply an additional layer of routing encryption already do this for all traffic.
so that traffic arrives at the destination through dynamic routes.
For some LLNs, memory and processing constraints as well as the
limitations of the communication channel will preclude both the
additional routing traffic overhead and the node implementation
required for tunneling countermeasures to traffic analysis.
8.1.4. Countering Physical Device Compromise
Section 5 identified that many threats to the routing functionality
may involve compromised devices. For the sake of completeness, this
subsection examines how to counter physical device compromise,
without restricting the consideration to only those methods and
apparatuses available to an LLN routing protocol.
Given the distributed nature of LLNs and the varying environment of
deployed devices, confidentiality of routing assets and points of
access may rely heavily on the security of the routing devices. One
means of precluding attacks on the physical device is to prevent
physical access to the node through other external security means.
However, given the environment in which many LLNs operate, preventing
unauthorized access to the physical device cannot be assured.
Countermeasures must therefore be employed at the device and
component level so that routing/topology or neighbor information and
stored route information cannot be accessed even if physical access
to the node is obtained.
With the physical device in the possession of an attacker,
unauthorized information access can be attempted by probing internal
interfaces or device components. Device security must therefore move
to preventing the reading of device processor code or memory
locations without the appropriate security keys and in preventing the
access to any information exchanges occurring between individual
components. Information access will then be restricted to external
interfaces in which confidentiality, integrity, and authentication
measures can be applied.
To prevent component information access, deployed routing devices
must ensure that their implementation avoids address or data buses
being connected to external general purpose input/output (GPIO) pins.
Beyond this measure, an important component interface to be protected
against attack is the Joint Test Action Group (JTAG) [IEEE1149.1]
interface used for component and populated circuit board testing
after manufacture. To provide security on the routing devices,
components should be employed that allow fuses on the JTAG interfaces
to be blown to disable access. This will raise the bar on
unauthorized component information access within a captured device.
At the device level a key component information exchange is between
the microprocessor and its associated external memory. While
encryption can be implemented to secure data bus exchanges, the use
of integrated physical packaging which avoids inter-component
exchanges (other than secure external device exchanges) will increase
routing security against a physical device interface attack. With an
integrated package and disabled internal component interfaces, the
level of physical device security can be controlled by managing the
degree to which the device packaging is protected against expert
physical decomposition and analysis.
The device package should be hardened such that attempts to remove
the integrated components will result in damage to access interfaces,
ports or pins that prevent retrieval of code or stored information.
The degree of Very Large Scale Integration (VLSI) or Printed Circuit
Board (PCB) package security through manufacture can be selected as a
trade-off or desired security consistent with the level of security
achieved by measures applied for other routing assets and points of
access. With package hardening and restricted component access
countermeasures, the security level will be raised to that provided
by measures employed at the external communications interfaces.
Another area of node interface vulnerability is that associated with
interfaces provided for remote software or firmware upgrades. This
may impact both routing information and routing/topology exchange
security where it leads to unauthorized upgrade or change to the
routing protocol running on a given node as this type of attack can
allow for the execution of compromised or intentionally malicious
routing code on multiple nodes. Countermeasures to this device
interface confidentiality attack needs to be addressed in the larger
context of node remote access security. This will ensure not only
the authenticity of the provided code (including routing protocol)
but that the process is initiated by an authorized (authenticated)
entity. For example, digital signing of firmware by an authorized
entity will provide an appropriate countermeasure.
The above identified countermeasures against attacks on routing
information confidentiality through internal device interface
compromise must be part of the larger LLN system security as they
cannot be addressed within the routing protocol itself. Similarly,
the use of field tools or other devices that allow explicit access to
node information must implement security mechanisms to ensure that
routing information can be protected against unauthorized access.
These protections will also be external to the routing protocol and
hence not part of ROLL.
8.1.5. Countering Remote Device Access Attacks 8.1.4. Countering Remote Device Access Attacks
Where LLN nodes are deployed in the field, measures are introduced to Where LLN nodes are deployed in the field, measures are introduced to
allow for remote retrieval of routing data and for software or field allow for remote retrieval of routing data and for software or field
upgrades. These paths create the potential for a device to be upgrades. These paths create the potential for a device to be
remotely accessed across the network or through a provided field remotely accessed across the network or through a provided field
tool. In the case of network management a node can be directly tool. In the case of network management a node can be directly
requested to provide routing tables and neighbor information. requested to provide routing tables and neighbor information.
To ensure confidentiality of the node routing information against To ensure confidentiality of the node routing information against
attacks through remote access, any local or remote device requesting attacks through remote access, any local or remote device requesting
skipping to change at page 28, line 39 skipping to change at page 24, line 34
implementation of this type of dedicated routing protocol security implementation of this type of dedicated routing protocol security
where the correctness of aggregate distance vector information can where the correctness of aggregate distance vector information can
only be validated by initiating confirmation exchanges directly only be validated by initiating confirmation exchanges directly
between nodes that are not routing neighbors. between nodes that are not routing neighbors.
Alternatively, an entity external to the routing protocol would be Alternatively, an entity external to the routing protocol would be
required to collect and audit routing information exchanges to detect required to collect and audit routing information exchanges to detect
the Byzantine attack. In the context of the current security the Byzantine attack. In the context of the current security
analysis, any protection against Byzantine routing information analysis, any protection against Byzantine routing information
attacks will need to be directly included within the mechanisms of attacks will need to be directly included within the mechanisms of
the ROLL routing protocol. This can be implemented where such an the ROLL routing protocol.
attack is considered relevant even within the physical device
protections discussed in Section 8.1.4.
8.3. Availability Attack Countermeasures 8.3. Availability Attack Countermeasures
As alluded to before, availability requires that routing information As alluded to before, availability requires that routing information
exchanges and forwarding mechanisms be available when needed so as to exchanges and forwarding mechanisms be available when needed so as to
guarantee proper functioning of the network. This may, e.g., include guarantee proper functioning of the network. This may, e.g., include
the correct operation of routing information and neighbor state the correct operation of routing information and neighbor state
information exchanges, among others. We will highlight the key information exchanges, among others. We will highlight the key
features of the security threats along with typical countermeasures features of the security threats along with typical countermeasures
to prevent or at least mitigate them. We will also note that an to prevent or at least mitigate them. We will also note that an
skipping to change at page 31, line 36 skipping to change at page 27, line 31
feasible, certificates should be validated prior to use of the feasible, certificates should be validated prior to use of the
associated keys to counter potential resource overloading attacks. associated keys to counter potential resource overloading attacks.
The associated design decision needs to also consider that the The associated design decision needs to also consider that the
validation process requires resources and thus itself could be validation process requires resources and thus itself could be
exploited for attacks. Alternatively, resource management limits can exploited for attacks. Alternatively, resource management limits can
be placed on routing security processing events (see the comment in be placed on routing security processing events (see the comment in
Section 6, paragraph 4, of [RFC5751]). Section 6, paragraph 4, of [RFC5751]).
8.3.3. Countering Selective Forwarding Attacks 8.3.3. Countering Selective Forwarding Attacks
Selective forwarding attacks are another form of DoS attack which Selective forwarding attacks are a form of DoS attack which impacts
impacts the routing path availability. the availability of the generated routing paths.
A selective forwarding attack may be done by a node involved with the
routing process, or it may be done by what otherwise appears to be a
passive antenna or other RF feature or device, but is in fact an
active (and selective) device. An RF antenna/repeater which is not
selective, is not a threat.
An insider malicious node basically blends neatly in with the network An insider malicious node basically blends neatly in with the network
but then may decide to forward and/or manipulate certain packets. If but then may decide to forward and/or manipulate certain packets. If
all packets are dropped, then this attacker is also often referred to all packets are dropped, then this attacker is also often referred to
as a "black hole". Such a form of attack is particularly dangerous as a "black hole". Such a form of attack is particularly dangerous
if coupled with sinkhole attacks since inherently a large amount of if coupled with sinkhole attacks since inherently a large amount of
traffic is attracted to the malicious node and thereby causing traffic is attracted to the malicious node and thereby causing
significant damage. In a shared medium, an outside malicious node significant damage. In a shared medium, an outside malicious node
would selectively jam overheard data flows, where the thus caused would selectively jam overheard data flows, where the thus caused
collisions incur selective forwarding. collisions incur selective forwarding.
skipping to change at page 34, line 39 skipping to change at page 30, line 38
resistance commensurate with the particular application domain resistance commensurate with the particular application domain
environment to ensure the confidentiality, integrity, and environment to ensure the confidentiality, integrity, and
availability of stored routing information. availability of stored routing information.
9.1. Confidentiality Features 9.1. Confidentiality Features
With regard to confidentiality, protecting the routing/topology With regard to confidentiality, protecting the routing/topology
information from unauthorized disclosure is not directly essential to information from unauthorized disclosure is not directly essential to
maintaining the routing function. Breaches of confidentiality may maintaining the routing function. Breaches of confidentiality may
lead to other attacks or the focusing of an attacker's resources (see lead to other attacks or the focusing of an attacker's resources (see
Section 5.3) 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, o MUST provide privacy when geographic information is used (see,
e.g., [RFC3693]); e.g., [RFC3693]);
o MAY provide tunneling; o MAY provide tunneling;
skipping to change at page 36, line 11 skipping to change at page 32, line 11
checks, change increments, and message event frequency checks, checks, change increments, and message event frequency checks,
etc. as a means of countering intentional or unintentional etc. as a means of countering intentional or unintentional
Byzantine threats; Byzantine threats;
o MAY incorporate external consistency checking and auditing of o MAY incorporate external consistency checking and auditing of
routing information to protect against intentional or routing information to protect against intentional or
unintentional Byzantine-induced network anomalies. unintentional Byzantine-induced network anomalies.
In conjunction with the integrity protection requirements, a secured In conjunction with the integrity protection requirements, a secured
ROLL protocol SHOULD log, against the offending node, any security ROLL protocol SHOULD log, against the offending node, any security
failure that occurs after a valid integrity check. The record of failure that occurs after a valid integrity check. The record policy
such failures (as may result, for example, from incorrect security configuration) can provide the basis for nodes to avoid initiating
policy configuration) can provide the basis for nodes to avoid routing access to the offender or be used for further system
initiating routing access to the offender or be used for further countermeasures in the case of potential insider attacks. All
system countermeasures in the case of potential insider attacks. All
integrity security failures SHOULD be logged, where feasible, but integrity security failures SHOULD be logged, where feasible, but
cannot be reliably considered as countering against the offending cannot be reliably considered as countering against the offending
source(s). source(s).
Depending on the nature of the routing protocol, e.g., distance Depending on the nature of the routing protocol, e.g., distance
vector or link state, additional measures may be necessary when the vector or link state, additional measures may be necessary when the
validity of the routing information is of concern. In the most basic validity of the routing information is of concern. In the most basic
form, verification of routing peer authenticity and liveliness can be form, verification of routing peer authenticity and liveliness can be
used to build a "chain of trust" along the path the routing used to build a "chain of trust" along the path the routing
information flows, such that network-wide information is validated information flows, such that network-wide information is validated
skipping to change at page 37, line 4 skipping to change at page 32, line 51
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
skipping to change at page 38, line 8 skipping to change at page 34, line 6
The use of a public key infrastructure (PKI), where feasible, can be The use of a public key infrastructure (PKI), where feasible, can be
used to support authenticated short-term key management as well as used to support authenticated short-term key management as well as
the distribution of long-term routing security keying material. Note the distribution of long-term routing security keying material. Note
that where the option for a PKI is supported for security of the that where the option for a PKI is supported for security of the
routing protocol itself, the routing protocol MUST include provisions routing protocol itself, the routing protocol MUST include provisions
for public key certificates to be included or referenced within for public key certificates to be included or referenced within
routing messages to allow a node's public key to be shared with routing messages to allow a node's public key to be shared with
communicating peers. Even if the certificate itself is not communicating peers. Even if the certificate itself is not
distributed by the node, there needs to be a mechanism to inform the distributed by the node, there needs to be a mechanism to inform the
receiving node where to find the certificate and obtain associated receiving node where to find the certificate and obtain associated
validation information; see [RFC3029] for an example of the kind of validation information; see [RFC5055] for an example of the kind of
localized PKI support that may be applied in a given LLN environment. localized PKI support that may be applied in a given LLN environment.
Where PKI systems are not feasible, the key management system MUST Where PKI systems are not feasible, the key management system MUST
support means for secure configuration, device authentication, and support means for secure configuration, device authentication, and
adherence to secure key wrapping principles for the secure adherence to secure key wrapping principles for the secure
distribution and update of device keys. distribution and update of device keys.
LLN routing protocols SHOULD be designed to allow the use of existing LLN routing protocols SHOULD be designed to allow the use of existing
and validated key management schemes. As part of the LLN and validated key management schemes. As part of the LLN
optimization, these schemes may be independent of the routing optimization, these schemes may be independent of the routing
protocol and part of the broader LLN system security specifications. protocol and part of the broader LLN system security specifications.
Where the long-term key management is defined separately from the Where the long-term key management is defined separately from the
routing protocol security, LLN application domains can appropriately routing protocol security, LLN application domains can appropriately
employ IETF-standard key management specifications. Established key employ IETF-standard key management specifications. Established key
management solutions such as IKEv2 [RFC5996] or MIKEY [RFC3830], management solutions such as IKEv2 [RFC5996] or MIKEY [RFC3830],
which supports several alternative private, public, or Diffie-Hellman which supports several alternative private, public key distributions
key distribution methods (see [RFC5197]), can thus be adapted for use methods (see [RFC5197]), can thus be adapted for use in LLNs. For
in LLNs. For example, see [I-D.alexander-roll-mikey-lln-key-mgmt]. example, see [I-D.alexander-roll-mikey-lln-key-mgmt]. Group key
Group key management and distribution methods may also be developed management and distribution methods may also be developed based on
based on the architecture principles defined in MSEC [RFC4046]. 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 42, line 11 skipping to change at page 38, line 33
There are other factors which are not part of a ROLL routing protocol There are other factors which are not part of a ROLL routing protocol
but which can still affect its operation. These include elements but which can still affect its operation. These include elements
such as weaker barrier to accessing the data or security material such as weaker barrier to accessing the data or security material
stored on the nodes through physical means; therefore, the internal stored on the nodes through physical means; therefore, the internal
and external interfaces of a node need to be adequate for guarding and external interfaces of a node need to be adequate for guarding
the integrity, and possibly the confidentiality, of stored the integrity, and possibly the confidentiality, of stored
information, as well as the integrity of routing and route generation information, as well as the integrity of routing and route generation
processes. processes.
Figure 3 provides an overview of the larger context of system Figure 5 provides an overview of the larger context of system
security and the relationship between ROLL requirements and measures security and the relationship between ROLL requirements and measures
and those that relate to the LLN system. and those that relate to the LLN system.
Security Services for Security Services for
ROLL-Addressable ROLL-Addressable
Security Requirements Security Requirements
| | | |
+---+ +---+ +---+ +---+
Node_i | | Node_j Node_i | | Node_j
_____v___ ___v_____ _____v___ ___v_____
Specify Security / \ / \ Specify Security Specify Security / \ / \ Specify Security
Requirements | Routing | | Routing | Requirements Requirements | Routing | | Routing | Requirements
+---------| Protocol| | Protocol|---------+ +---------| Protocol| | Protocol|---------+
| | Entity | | Entity | | | | Entity | | Entity | |
| \_________/ \_________/ | | \_________/ \_________/ |
| | | | | | | |
|ROLL-Specified | | ROLL-Specified| |ROLL-Specified | | ROLL-Specified|
---Interface | | Interface---
| ...................................... | ---Interface | | Interface---
| : | | : | | ...................................... |
| : +-----+----+ +----+-----+ : | | : | | : |
| : |Transport/| |Transport/| : | | : +-----+----+ +----+-----+ : |
____v___ : +>|Network | |Network |<+ : ___v____ | : |Transport/| |Transport/| : |
/ \ : | +-----+----+ +----+-----+ | : / \ ____v___ : +>|Network | |Network |<+ : ___v____
| |-:-+ | | +-:-| | / \ : | +-----+----+ +----+-----+ | : / \
|Security| : +-----+----+ +----+-----+ : |Security| | |-:-+ | | +-:-| |
+->|Services|-:-->| Link | | Link |<--:-|Services|<-+ |Security| : +-----+----+ +----+-----+ : |Security|
| |Entity | : +-----+----+ +----+-----+ : |Entity | | +->|Services|-:-->| Link | | Link |<--:-|Services|<-+
| | |-:-+ | | +-:-| | | | |Entity | : +-----+----+ +----+-----+ : |Entity | |
| \________/ : | +-----+----+ +----+-----+ | : \________/ | | | |-:-+ | | +-:-| | |
| : +>| Physical | | Physical |<+ : | | \________/ : | +-----+----+ +----+-----+ | : \________/ |
| : +>| Physical | | Physical |<+ : |
Application : +-----+----+ +----+-----+ : Application Application : +-----+----+ +----+-----+ : Application
Domain User : | | : Domain User Domain User : | | : Domain User
Configuration : |__Comm. Channel_| : Configuration Configuration : |__Comm. Channel_| : Configuration
: : : :
...Protocol Stack..................... ...Protocol Stack.....................
Figure 3: LLN Device Security Model Figure 5: LLN Device Security Model
10. IANA Considerations 10. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
11. Security Considerations 11. Security Considerations
The analysis presented in this document provides security analysis The analysis presented in this document provides security analysis
and design guidelines with a scope limited to ROLL. Security and design guidelines with a scope limited to ROLL. Security
services are identified as requirements for securing ROLL. The services are identified as requirements for securing ROLL. The
skipping to change at page 44, line 22 skipping to change at page 40, line 12
acknowledge the guidance and input provided by the ROLL Chairs, David acknowledge the guidance and input provided by the ROLL Chairs, David
Culler, and JP Vasseur, and the Area Director Adrian Farrel. Culler, and JP Vasseur, and the Area Director Adrian Farrel.
This document started out as a combined threat and solutions This document started out as a combined threat and solutions
document. As a result of security review, the document was split up document. As a result of security review, the document was split up
by ROLL co-Chair Michael Richardson and security Area Director Sean by ROLL co-Chair Michael Richardson and security Area Director Sean
Turner as it went through the IETF publication process. The Turner as it went through the IETF publication process. The
solutions to the threads are application and layer-2 specific, and solutions to the 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
development of this document
13. References 13. References
13.1. Normative References 13.1. Normative References
[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.
13.2. Informative References 13.2. Informative References
[FIPS197] "Federal Information Processing Standards Publication 197: [FIPS197] , "Federal Information Processing Standards Publication
Advanced Encryption Standard (AES)", US National Institute 197: Advanced Encryption Standard (AES)", US National
of Standards and Technology, Nov. 26 2001. Institute of Standards and Technology, Nov. 26 2001.
[Huang2003] [Huang2003]
Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J. Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J.
Zhang, "Fast Authenticated Key Establishment Protocols for Zhang, "Fast Authenticated Key Establishment Protocols for
Self-Organizing Sensor Networks", in Proceedings of the Self-Organizing Sensor Networks", in Proceedings of the
2nd ACM International Conference on Wireless Sensor 2nd ACM International Conference on Wireless Sensor
Networks and Applications, San Diego, CA, USA, pp. 141- Networks and Applications, San Diego, CA, USA, pp.
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]
Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-04 (work in
progress), September 2010.
[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.
[ISO.7498-2.1988]
International Organization for Standardization,
"Information Processing Systems - Open Systems
Interconnection Reference Model - Security Architecture",
ISO Standard 7498-2, 1988.
[Karlof2003] [Karlof2003]
Karlof, C. and D. Wagner, "Secure routing in wireless Karlof, C. and D. Wagner, "Secure routing in wireless
sensor networks: attacks and countermeasures", Elsevier sensor networks: attacks and countermeasures", Elsevier
AdHoc Networks Journal, Special Issue on Sensor Network AdHoc Networks Journal, Special Issue on Sensor Network
Applications and Protocols, 1(2):293-315, September 2003. Applications and Protocols, 1(2):293-315, September 2003.
[Kasumi3gpp] [Kasumi3gpp]
"3GPP TS 35.202 Specification of the 3GPP confidentiality , "3GPP TS 35.202 Specification of the 3GPP
and integrity algorithms; Document 2: Kasumi confidentiality and integrity algorithms; Document 2:
specification", 3GPP TSG SA3, 2009. Kasumi specification", 3GPP TSG SA3, 2009.
[Messerges2003] [Messerges2003]
Messerges, T., Cukier, J., Kevenaar, T., Puhl, L., Struik, Messerges, T., Cukier, J., Kevenaar, T., Puhl, L., Struik,
R., and E. Callaway, "Low-Power Security for Wireless R., and E. Callaway, "Low-Power Security for Wireless
Sensor Networks", in Proceedings of the 1st ACM Workshop Sensor Networks", in Proceedings of the 1st ACM Workshop
on Security of Ad Hoc and Sensor Networks, Fairfax, VA, on Security of Ad Hoc and Sensor Networks, Fairfax, VA,
USA, pp. 1-11, Oct. 31 2003. USA, pp. 1-11, Oct. 31 2003.
[Myagmar2005] [Myagmar2005]
Myagmar, S., Lee, AJ., and W. Yurcik, "Threat Modeling as Myagmar, S., Lee, AJ., and W. Yurcik, "Threat Modeling as
a Basis for Security Requirements", in Proceedings of the a Basis for Security Requirements", in Proceedings of the
Symposium on Requirements Engineering for Information Symposium on Requirements Engineering for Information
Security (SREIS'05), Paris, France, pp. 94-102, Aug Security (SREIS'05), Paris, France, pp. 94-102, Aug 29,
29, 2005. 2005.
[Perlman1988] [Perlman1988]
Perlman, N., "Network Layer Protocols with Byzantine Perlman, N., "Network Layer Protocols with Byzantine
Robustness", MIT LCS Tech Report, 429, 1988. Robustness", MIT LCS Tech Report, 429, 1988.
[RFC1142] Oran, D., "OSI IS-IS Intra-domain Routing Protocol", [RFC1142] Oran, D., "OSI IS-IS Intra-domain Routing Protocol", RFC
RFC 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, [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November
November 1998. 1998.
[RFC3029] Adams, C., Sylvester, P., Zolotarev, M., and R.
Zuccherato, "Internet X.509 Public Key Infrastructure Data
Validation and Certification Server Protocols", RFC 3029,
February 2001.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 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.
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- [RFC4732] Handley, M., Rescorla, E., IAB, "Internet Denial-of-
Service Considerations", RFC 4732, December 2006. Service Considerations", RFC 4732, December 2006.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
RFC 4949, August 2007. 4949, August 2007.
[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W.
Polk, "Server-Based Certificate Validation Protocol
(SCVP)", RFC 5055, December 2007.
[RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of [RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of
Various Multimedia Internet KEYing (MIKEY) Modes and Various Multimedia Internet KEYing (MIKEY) Modes and
Extensions", RFC 5197, June 2008. Extensions", RFC 5197, June 2008.
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
"Routing Requirements for Urban Low-Power and Lossy "Routing Requirements for Urban Low-Power and Lossy
Networks", RFC 5548, May 2009. Networks", RFC 5548, May 2009.
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low-Power and Lossy "Industrial Routing Requirements in Low-Power and Lossy
Networks", RFC 5673, October 2009. Networks", RFC 5673, October 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks", Routing Requirements in Low-Power and Lossy Networks", RFC
RFC 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)", "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
RFC 5996, September 2010. 5996, September 2010.
[Szcze2008]
Szczechowiak1, P., Oliveira, L., Scott, M., Collier, M.,
and R. Dahab, "NanoECC: testing the limits of elliptic
curve cryptography in sensor networks", pp. 324-328, 2008,
<http://www.ic.unicamp.br/~leob/publications/ewsn/
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
Cryptography and Network Security, Yellow Mountain, China, Cryptography and Network Security, Yellow Mountain, China,
pp. 103-119, Jun. 8-11 2004. pp. 103-119, Jun. 8-11 2004.
[Wander2005] [Wander2005]
Wander, A., Gura, N., Eberle, H., Gupta, V., and S. Wander, A., Gura, N., Eberle, H., Gupta, V., and S.
Shantz, "Energy analysis of public-key cryptography for Shantz, "Energy analysis of public-key cryptography for
skipping to change at line 2096 skipping to change at page 45, line 4
Email: vanesa.daza@upf.edu Email: vanesa.daza@upf.edu
Angel Lozano Angel Lozano
Universitat Pompeu Fabra Universitat Pompeu Fabra
P/ Circumval.lacio 8, Oficina 309 P/ Circumval.lacio 8, Oficina 309
Barcelona 08003 Barcelona 08003
Spain Spain
Email: angel.lozano@upf.edu Email: angel.lozano@upf.edu
Michael Richardson (ed)
Sandelman Software Works
470 Dawson Avenue
Ottawa, ON K1Z5V7
Canada
Email: mcr+ietf@sandelman.ca
 End of changes. 68 change blocks. 
362 lines changed or deleted 304 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/