draft-ietf-roll-security-framework-02.txt   draft-ietf-roll-security-framework-03.txt 
Networking Working Group T. Tsao Networking Working Group T. Tsao
Internet-Draft R. Alexander Internet-Draft R. Alexander
Intended status: Informational Cooper Power Systems Intended status: Informational Cooper Power Systems
Expires: May 12, 2011 M. Dohler Expires: June 13, 2011 M. Dohler
CTTC CTTC
V. Daza V. Daza
A. Lozano A. Lozano
Universitat Pompeu Fabra Universitat Pompeu Fabra
November 8, 2010 December 10, 2010
A Security Framework for Routing over Low Power and Lossy Networks A Security Framework for Routing over Low Power and Lossy Networks
draft-ietf-roll-security-framework-02 draft-ietf-roll-security-framework-03
Abstract Abstract
This document presents a security framework for routing over low This document presents a security framework for routing over low
power and lossy networks (LLN). The development builds upon previous power and lossy networks (LLN). The development builds upon previous
work on routing security and adapts the assessments to the issues and work on routing security and adapts the assessments to the issues and
constraints specific to low power and lossy networks. A systematic constraints specific to low power and lossy networks. A systematic
approach is used in defining and evaluating the security threats and approach is used in defining and evaluating the security threats and
identifying applicable countermeasures. These assessments provide identifying applicable countermeasures. These assessments provide
the basis of the security recommendations for incorporation into low the basis of the security recommendations for incorporation into low
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 12, 2011. This Internet-Draft will expire on June 13, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Considerations on ROLL Security . . . . . . . . . . . . . . . 6 3. Considerations on ROLL Security . . . . . . . . . . . . . . . 6
3.1. Routing Assets and Points of Access . . . . . . . . . . . 6 3.1. Routing Assets and Points of Access . . . . . . . . . . . 6
3.2. The CIA Security Reference Model . . . . . . . . . . . . . 9 3.2. The CIA Security Reference Model . . . . . . . . . . . . . 9
3.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 10 3.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 10
3.4. ROLL Security Objectives . . . . . . . . . . . . . . . . . 12 3.4. ROLL Security Objectives . . . . . . . . . . . . . . . . . 12
4. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 13 4. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 13
4.1. Threats and Attacks on Confidentiality . . . . . . . . . . 14 4.1. Threats and Attacks on Confidentiality . . . . . . . . . . 14
4.1.1. Routing Exchange Exposure . . . . . . . . . . . . . . 14 4.1.1. Routing Exchange Exposure . . . . . . . . . . . . . . 14
4.1.2. Routing Information (Routes and Network Topology) 4.1.2. Routing Information (Routes and Network Topology)
Exposure . . . . . . . . . . . . . . . . . . . . . . . 14 Exposure . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Threats and Attacks on Integrity . . . . . . . . . . . . . 15 4.2. Threats and Attacks on Integrity . . . . . . . . . . . . . 15
4.2.1. Routing Information Manipulation . . . . . . . . . . . 15 4.2.1. Routing Information Manipulation . . . . . . . . . . . 15
4.2.2. Node Identity Misappropriation . . . . . . . . . . . . 15 4.2.2. Node Identity Misappropriation . . . . . . . . . . . . 16
4.3. Threats and Attacks on Availability . . . . . . . . . . . 16 4.3. Threats and Attacks on Availability . . . . . . . . . . . 16
4.3.1. Routing Exchange Interference or Disruption . . . . . 16 4.3.1. Routing Exchange Interference or Disruption . . . . . 16
4.3.2. Network Traffic Forwarding Disruption . . . . . . . . 16 4.3.2. Network Traffic Forwarding Disruption . . . . . . . . 16
4.3.3. Communications Resource Disruption . . . . . . . . . . 17 4.3.3. Communications Resource Disruption . . . . . . . . . . 18
4.3.4. Node Resource Exhaustion . . . . . . . . . . . . . . . 18 4.3.4. Node Resource Exhaustion . . . . . . . . . . . . . . . 19
5. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 18 5. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Confidentiality Attack Countermeasures . . . . . . . . . . 19 5.1. Confidentiality Attack Countermeasures . . . . . . . . . . 20
5.1.1. Countering Deliberate Exposure Attacks . . . . . . . . 19 5.1.1. Countering Deliberate Exposure Attacks . . . . . . . . 20
5.1.2. Countering Sniffing Attacks . . . . . . . . . . . . . 19 5.1.2. Countering Sniffing Attacks . . . . . . . . . . . . . 20
5.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 21 5.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 21
5.1.4. Countering Physical Device Compromise . . . . . . . . 21 5.1.4. Countering Physical Device Compromise . . . . . . . . 22
5.1.5. Countering Remote Device Access Attacks . . . . . . . 23 5.1.5. Countering Remote Device Access Attacks . . . . . . . 24
5.2. Integrity Attack Countermeasures . . . . . . . . . . . . . 24 5.2. Integrity Attack Countermeasures . . . . . . . . . . . . . 24
5.2.1. Countering Tampering Attacks . . . . . . . . . . . . . 24 5.2.1. Countering Tampering Attacks . . . . . . . . . . . . . 25
5.2.2. Countering Overclaiming and Misclaiming Attacks . . . 24 5.2.2. Countering Overclaiming and Misclaiming Attacks . . . 25
5.2.3. Countering Identity (including Sybil) Attacks . . . . 25 5.2.3. Countering Identity (including Sybil) Attacks . . . . 25
5.2.4. Countering Routing Information Replay Attacks . . . . 25 5.2.4. Countering Routing Information Replay Attacks . . . . 26
5.2.5. Countering Byzantine Routing Information Attacks . . . 25 5.2.5. Countering Byzantine Routing Information Attacks . . . 26
5.3. Availability Attack Countermeasures . . . . . . . . . . . 26 5.3. Availability Attack Countermeasures . . . . . . . . . . . 27
5.3.1. Countering HELLO Flood Attacks and ACK Spoofing 5.3.1. Countering HELLO Flood Attacks and ACK Spoofing
Attacks . . . . . . . . . . . . . . . . . . . . . . . 27 Attacks . . . . . . . . . . . . . . . . . . . . . . . 27
5.3.2. Countering Overload Attacks . . . . . . . . . . . . . 28 5.3.2. Countering Overload Attacks . . . . . . . . . . . . . 29
5.3.3. Countering Selective Forwarding Attacks . . . . . . . 29 5.3.3. Countering Selective Forwarding Attacks . . . . . . . 30
5.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 30 5.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 30
5.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 30 5.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 31
6. ROLL Security Features . . . . . . . . . . . . . . . . . . . . 31 6. ROLL Security Features . . . . . . . . . . . . . . . . . . . . 32
6.1. Confidentiality Features . . . . . . . . . . . . . . . . . 31 6.1. Confidentiality Features . . . . . . . . . . . . . . . . . 32
6.2. Integrity Features . . . . . . . . . . . . . . . . . . . . 32 6.2. Integrity Features . . . . . . . . . . . . . . . . . . . . 33
6.3. Availability Features . . . . . . . . . . . . . . . . . . 33 6.3. Availability Features . . . . . . . . . . . . . . . . . . 34
6.4. Additional Related Features . . . . . . . . . . . . . . . 34 6.4. Additional Related Features . . . . . . . . . . . . . . . 34
6.5. Consideration on Matching Application Domain Needs . . . . 34 6.5. Consideration on Matching Application Domain Needs . . . . 35
6.5.1. Security Architecture . . . . . . . . . . . . . . . . 34 6.5.1. Security Architecture . . . . . . . . . . . . . . . . 35
6.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 37 6.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 37
7. Application of ROLL Security Framework to RPL . . . . . . . . 38 7. Application of ROLL Security Framework to RPL . . . . . . . . 39
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 9. Security Considerations . . . . . . . . . . . . . . . . . . . 41
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
11.1. Normative References . . . . . . . . . . . . . . . . . . . 41 11.1. Normative References . . . . . . . . . . . . . . . . . . . 42
11.2. Informative References . . . . . . . . . . . . . . . . . . 41 11.2. Informative References . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Terminology
This document adopts and conforms to the terminology defined in
[I-D.ietf-roll-terminology] and in [RFC4949], with the following
addition:
Node An element of a low power lossy network that may be a router or
a host.
2. 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
access interface (e.g., the housing of a small stick-on switch), or access interface (e.g., the housing of a small stick-on switch), or
simply safety considerations (e.g., with gas meters). As a simply safety considerations (e.g., with gas meters). As a
skipping to change at page 6, line 5 skipping to change at page 5, line 41
The approach adopted in this effort proceeds in four steps, to The approach adopted in this effort proceeds in four steps, to
examine security issues in ROLL, to analyze threats and attacks, to examine security issues in ROLL, to analyze threats and attacks, to
consider the countermeasures, and then to make recommendations for consider the countermeasures, and then to make recommendations for
securing ROLL. The basis is found on identifying the assets and securing ROLL. The basis is found on identifying the assets and
points of access of routing and evaluating their security needs based points of access of routing and evaluating their security needs based
on the Confidentiality, Integrity, and Availability (CIA) model in on the Confidentiality, Integrity, and Availability (CIA) model in
the context of LLN. The utility of this framework is demonstrated the context of LLN. The utility of this framework is demonstrated
with an application to IPv6 Routing Protocol for Low Power and Lossy with an application to IPv6 Routing Protocol for Low Power and Lossy
Networks (RPL) [I-D.ietf-roll-rpl]. Networks (RPL) [I-D.ietf-roll-rpl].
2. Terminology
This document adopts and conforms to the terminology defined in
[I-D.ietf-roll-terminology] and in [RFC4949], with the following
addition:
Node An element of a low power lossy network that may be a router or
a host.
3. Considerations on ROLL Security 3. Considerations on ROLL Security
Security, in essence, entails implementing measures to ensure Security, in essence, 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
proper authorization for actions, authentication, and potentially proper authorization for actions, authentication, and potentially
confidentiality, but also proper order of state changes through confidentiality, but also proper order of state changes through
timeliness (since seriously delayed state changes, such as commands timeliness (since seriously delayed state changes, such as commands
skipping to change at page 9, line 34 skipping to change at page 9, line 34
At the conceptual level, security within an information system in At the conceptual level, security within an information system in
general and applied to ROLL in particular is concerned with the general and applied to ROLL in particular is concerned with the
primary issues of confidentiality, integrity, and availability. In primary issues of confidentiality, integrity, and availability. In
the context of ROLL: the context of ROLL:
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 publicly accessible Because LLNs are most commonly found on a publicly accessible
shared medium, e.g., air or wiring in a building, and sometimes shared medium, e.g., air or wiring in a building, and sometimes
formed ad hoc, confidentiality also extends to the neighbor formed ad hoc, confidentiality also extends to the neighbor
state and database information within the routing device since state and database information within the routing device since
the deployment of the network creates the potential for the deployment of the network creates the potential for
unauthorized access to the physical devices themselves. unauthorized access to the physical devices themselves.
Integrity Integrity
Integrity, as a security principle, entails the protection of Integrity, as a security principle, entails the protection of
routing information and routing neighbor maintenance exchanges, routing information and routing neighbor maintenance exchanges,
as well as derived information maintained in the database, from as well as derived information maintained in the database, from
misuse or unauthorized and improper modification. In addition, unauthorized modification or from misuse. Misuse, for example,
integrity also requires the authenticity of claimed identity in may take the form of a delayed or inappropriately replayed
the origin and destination of a message, access and removal of message even where confidentiality protection is maintained.
data, execution of the routing process, and use of computing Hence, in addition to the data itself, integrity also concerns
and energy resources. the authenticity of claimed identity of the origin and
destination of a message and its timeliness or freshness. On
the other hand, the access to and/or removal of data, execution
of the routing process, and use of a device's computing and
energy resources, while relevant to routing security are
considered larger system integrity issues [RFC4949] to be
addressed byond the routing protocol.
Availability Availability
Availability ensures that routing information exchanges and Availability ensures that routing information exchanges and
forwarding services need to be available when they are required forwarding services need to be available when they are required
for the functioning of the serving network. Availability will for the functioning of the serving network. Availability will
apply to maintaining efficient and correct operation of routing apply to maintaining efficient and correct operation of routing
and neighbor discovery exchanges (including needed information) and neighbor discovery exchanges (including needed information)
and forwarding services so as not to impair or limit the and forwarding services so as not to impair or limit the
network's central traffic flow function. network's central traffic flow function.
It is noted that, besides those captured in the CIA model, assurance It is recognized that, besides those security issues captured in the
of no denial of the transmission and/or reception of a message, i.e., CIA model, non-repudiation, that is, the assurance that the
non-repudiation, is a security interest under certain circumstances. transmission and/or reception of a message cannot later be denied,
With respect to routing, non-repudiation will involve providing some may be a security requirement under certain circumstances. The
ability to allow traceability or network management review of service of non-repudiation implies after-the-fact and thus relies on
participants of the routing process including the ability to the logging or other capture of on-going message exchanges and
determine the events and actions leading to a particular routing signatures. Applied to routing, non-repudiation will involve
state. Non-repudiation implies after the fact and thus relies on the providing some ability to allow traceability or network management
logging or other capture of on-going routing exchanges and review of participants of the routing process including the ability
signatures. Given the limited resources of a node and potentially to determine the events and actions leading to a particular routing
the communication channel, and considering the operating mode state. As such, non-repudiation of routing may thus be more useful
associated with LLNs, routing transaction logging or auditing process when interworking with networks of different ownerships. For the LLN
communication overhead will not be practical; as such, non- application domains as described in [RFC5548], [RFC5673], [RFC5826],
repudiation in the context of routing is not further considered as a and [RFC5867], particularly with regard to routing security,
ROLL security issue. proactive measures are much more critical than retrospective
protections. Furthermore, given the significant practical limits to
on-going routing transaction logging and storage and individual
device signature authentication for each exchange, non-repudiation in
the context of routing is not further considered as a ROLL security
issue.
It is important to note that for routing security the above CIA It should be emphasized here that for routing security the above CIA
requirements must be complemented by the proper security policies and requirements must be complemented by the proper security policies and
enforcement mechanisms to ensure that security objectives are met by enforcement mechanisms to ensure that security objectives are met by
a given routing protocol implementation. a given routing protocol implementation.
3.3. Issues Specific to or Amplified in LLNs 3.3. Issues Specific to or Amplified in LLNs
The work [RFC5548] and [RFC5673], [RFC5826], and [RFC5867] have The work [RFC5548], [RFC5673], [RFC5826], and [RFC5867] have
identified specific issues and constraints of routing in LLNs for the identified specific issues and constraints of routing in LLNs for the
urban, industrial, home automation, and building automation urban, industrial, home automation, and building automation
application domains, respectively. The following is a list of application domains, respectively. The following is a list of
observations and evaluation of their impact on routing security observations and evaluation of their impact on routing security
considerations. considerations.
Limited energy, memory, and processing node resources Limited energy, memory, and processing node resources
As a consequence of these constraints, there is an even more As a consequence of these constraints, there is an even more
critical need than usual for a careful trade study on which and critical need than usual for a careful study of trade-offs on
what level of security services are to be afforded during the which and what level of security services are to be afforded
system design process. In addition, the choices of security during the system design process. In addition, the choices of
mechanisms are more stringent. Synchronization of security security mechanisms are more stringent. Synchronization of
states with sleepy nodes is yet another issue. security states with sleepy nodes is yet another issue.
Large scale of rolled out network Large scale of rolled out network
The possibly numerous nodes to be deployed, e.g., an urban The possibly numerous nodes to be deployed, e.g., an urban
deployment can see several hundreds of thousands of nodes, as deployment can see several hundreds of thousands of nodes, as
well as the generally low level of expertise expected of the well as the generally low level of expertise expected of the
installers, make manual on-site configuration unlikely. installers, make manual on-site configuration unlikely.
Prolonged rollout and delayed addition of nodes, which may be Prolonged rollout and delayed addition of nodes, which may be
from old inventory, over the lifetime of the network, also from old inventory, over the lifetime of the network, also
complicate the operations of key management. complicate the operations of key management.
skipping to change at page 11, line 26 skipping to change at page 11, line 34
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 key management well as node replacement, can all contribute to key management
issues. issues.
Highly directional traffic Highly directional traffic
Some types of LLNs see a high percentage of their total traffic Some types of LLNs see a high percentage of their total traffic
traverse between the nodes and the Lln Border Routers (LBRs) traverse between the nodes and the LLN Border Routers (LBRs)
where the LLNs connect to non-LLNs. The special routing status where the LLNs connect to non-LLNs. The special routing status
of and the greater volume of traffic near the LBRs have routing of and the greater volume of traffic near the LBRs have routing
security consequences. In fact, when Point-to-MultiPoint security consequences. In fact, when Point-to-MultiPoint
(P2MP) and MultiPoint-to-Point (MP2P) traffic represents a (P2MP) and MultiPoint-to-Point (MP2P) traffic represents a
majority of the traffic, routing attacks consisting of majority of the traffic, routing attacks consisting of
advertising low route cost may cause serious damages. advertising low route cost may cause serious damages.
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
skipping to change at page 12, line 8 skipping to change at page 12, line 16
clearly need to have corresponding security mechanisms. clearly need to have corresponding security mechanisms.
Support for multicast and anycast Support for multicast and anycast
Support for multicast and anycast is called out chiefly for Support for multicast and anycast is called out chiefly for
large-scale networks. Since application of these routing large-scale networks. Since application of these routing
mechanisms in autonomous operations of many nodes is new, the mechanisms in autonomous operations of many nodes is new, the
consequence on security requires careful consideration. consequence on security requires careful consideration.
The above list considers how a LLN's physical constraints, size, The above list considers how a LLN's physical constraints, size,
operations, and varieties of application areas may impact security. operations, and varieties of application areas may impact security.
The following subsection sets up the security objectives for the However, it is the combinations of these factors that particularly
routing protocol designed by the ROLL WG. stress the security concerns. For instance, securing routing for a
large number of autonomous devices that are left in unattended
locations with limited physical security presents challenges that are
not found in the common circumstance of administered networked
routers. The following subsection sets up the security objectives
for the routing protocol designed by the ROLL WG.
3.4. ROLL Security Objectives 3.4. ROLL Security Objectives
This subsection applies the CIA model to the routing assets and This subsection applies the CIA model to the routing assets and
access points, taking into account the LLN issues, to develop a set access points, taking into account the LLN issues, to develop a set
of ROLL security objectives. of ROLL security objectives.
Since the fundament function of a routing protocol is to build routes Since the fundament function of a routing protocol is to build routes
for forwarding packets, it is essential to ensure that for forwarding packets, it is essential to ensure that
skipping to change at page 34, line 16 skipping to change at page 34, line 48
If a LLN employs multicast and/or anycast, it MUST secure these If a LLN employs multicast and/or anycast, it MUST secure these
mechanisms with the services listed in this sections. Furthermore, mechanisms with the services listed in this sections. Furthermore,
the nodes MUST provide adequate physical tamper resistance to ensure the nodes MUST provide adequate physical tamper resistance to ensure
the integrity of stored routing information. the integrity of stored routing information.
The functioning of the security services requires keys and The functioning of the security services requires keys and
credentials. Therefore, even though not directly a ROLL security credentials. Therefore, even though not directly a ROLL security
requirement, a LLN must include a process for key and credential requirement, a LLN must include a process for key and credential
distribution; a LLN is encouraged to have procedures for their distribution; a LLN is encouraged to have procedures for their
revocation and replacement. revocation and replacement. Correspondingly, the routing protocol(s)
specified by the ROLL Working Group should assume that the system
affords key management mechanisms consistent with the guidelines
given in [RFC4107]. Based on that RFC's recommendations, many LLNs,
particularly given the intended scale and ad hoc device associations,
will satisfy the requirement for supporting automated key management
in conjunction with the routing protocol operation.
6.5. Consideration on Matching Application Domain Needs 6.5. Consideration on Matching Application Domain Needs
As routing is one component of a LLN system, the actual strength of As routing is one component of a LLN system, the actual strength of
the security services afforded to it should be made to conform to the security services afforded to it should be made to conform to
each system's security policy; how a design may address the needs of each system's security policy; how a design may address the needs of
the urban, industrial, home automation, and building automation the urban, industrial, home automation, and building automation
application domains is considered as part of the security application domains is considered as part of the security
architecture in Section 6.5.1. architecture in Section 6.5.1.
skipping to change at page 39, line 36 skipping to change at page 40, line 36
|Forwarding V | |Forwarding V |
To/From Node_k|<----->(Read/Write | To/From Node_k|<----->(Read/Write |
Hop-by-Hop Option or | Hop-by-Hop Option or |
Routing Header)<------+ Routing Header)<------+
Figure 4: Data Flow Diagram of RPL Figure 4: Data Flow Diagram of RPL
From Figure 4, it is seen that threats to the proper operation of RPL From Figure 4, it is seen that threats to the proper operation of RPL
are realized through attacks on its DIO, DIS, and DAO messages, as are realized through attacks on its DIO, DIS, and DAO messages, as
well as on the information the protocol places on the IPv6 Hop-by-Hop well as on the information the protocol places on the IPv6 Hop-by-Hop
Option Header [I-D.ietf-6man-rpl-option]and Routing Header Option Header [I-D.ietf-6man-rpl-option] and Routing Header
[I-D.ietf-6man-rpl-routing-header]. As set forth in Section 6.1 to [I-D.ietf-6man-rpl-routing-header]. As set forth in Section 6.1 to
Section 6.4, the base security requirements concern message Section 6.4, the base security requirements concern message
integrity, authenticity and liveliness of the principals of a integrity, authenticity and liveliness of the principals of a
connection, and protection against message replay; message encryption connection, and protection against message replay; message encryption
may be desirable. The security objectives for RPL are therefore to may be desirable. The security objectives for RPL are therefore to
ensure that ensure that
1. participants of the DIO, DIS, and DAO message exchanges are 1. participants of the DIO, DIS, and DAO message exchanges are
authentic; authentic;
skipping to change at page 40, line 11 skipping to change at page 41, line 11
3. the received DIO, DIS, and DAO messages are not retransmissions 3. the received DIO, DIS, and DAO messages are not retransmissions
of previous messages; of previous messages;
4. the content of the DIO, DIS, and DAO messages may be made legible 4. the content of the DIO, DIS, and DAO messages may be made legible
to only authorized entities. to only authorized entities.
In meeting the above objectives, RPL also needs to provide tunable In meeting the above objectives, RPL also needs to provide tunable
mechanisms both to allow matching the security afforded to the mechanisms both to allow matching the security afforded to the
application domain requirements and to enable efficient use of system application domain requirements and to enable efficient use of system
resources, as discussed in Section 6.5.1 and Section 6.5.2. resources, as discussed in Section 6.5.1 and Section 6.5.2. In
particular, consistent with the recommendations of [RFC4107], RPL
should specify the use of a symmetric-key based cryptographic
algorithm as a baseline for session exchanges and rely on the use of
appropriately developed and validated key management mechanisms for
key control.
The functions of the different RPL messages, and the next hops The functions of the different RPL messages, and the next hops
information placed in the Routing Header and RPL option TLV carried information placed in the Routing Header and RPL option TLV carried
in the Hop-by-Hop Option Header are factors that can be taken into in the Hop-by-Hop Option Header are factors that can be taken into
account when deciding the optional security features and levels of account when deciding the optional security features and levels of
strength to be afforded. For example, the DIO messages build routes strength to be afforded. For example, the DIO messages build routes
to roots while the DAO messages support the building of downward to roots while the DAO messages support the building of downward
routes to leaf nodes. Consequently, there may be application routes to leaf nodes. Consequently, there may be application
environments in which the directions of the routes have different environments in which the directions of the routes have different
importance and thus warrant the use of different security features importance and thus warrant the use of different security features
skipping to change at page 41, line 19 skipping to change at page 42, line 22
draft-ietf-6man-rpl-option-01 (work in progress), draft-ietf-6man-rpl-option-01 (work in progress),
October 2010. October 2010.
[I-D.ietf-6man-rpl-routing-header] [I-D.ietf-6man-rpl-routing-header]
Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6 Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with RPL", Routing Header for Source Routes with RPL",
draft-ietf-6man-rpl-routing-header-01 (work in progress), draft-ietf-6man-rpl-routing-header-01 (work in progress),
October 2010. October 2010.
[I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl]
Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Protocol for Low power and Lossy Networks", Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
draft-ietf-roll-rpl-11 (work in progress), July 2010. Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-16 (work in
progress), December 2010.
[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.
[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.
[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 1998. November 1998.
[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.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
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.
11.2. Informative References 11.2. Informative References
[FIPS180] "Federal Information Processing Standards Publication [FIPS180] "Federal Information Processing Standards Publication
180-3: Secure Hash Standard (SHS)", US National Institute 180-3: Secure Hash Standard (SHS)", US National Institute
of Standards and Technology, Oct. 2008. of Standards and Technology, Oct. 2008.
[FIPS197] "Federal Information Processing Standards Publication 197: [FIPS197] "Federal Information Processing Standards Publication 197:
 End of changes. 29 change blocks. 
84 lines changed or deleted 116 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/