draft-ietf-roll-security-framework-05.txt   draft-ietf-roll-security-framework-06.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: October 26, 2011 M. Dohler Expires: December 17, 2011 M. Dohler
CTTC CTTC
V. Daza V. Daza
A. Lozano A. Lozano
Universitat Pompeu Fabra Universitat Pompeu Fabra
April 24, 2011 June 15, 2011
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-05 draft-ietf-roll-security-framework-06
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 October 26, 2011. This Internet-Draft will expire on December 17, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 35 skipping to change at page 3, line 35
4.3.3. Communications Resource Disruption . . . . . . . . . . 18 4.3.3. Communications Resource Disruption . . . . . . . . . . 18
4.3.4. Node Resource Exhaustion . . . . . . . . . . . . . . . 19 4.3.4. Node Resource Exhaustion . . . . . . . . . . . . . . . 19
5. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 19 5. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Confidentiality Attack Countermeasures . . . . . . . . . . 20 5.1. Confidentiality Attack Countermeasures . . . . . . . . . . 20
5.1.1. Countering Deliberate Exposure Attacks . . . . . . . . 20 5.1.1. Countering Deliberate Exposure Attacks . . . . . . . . 20
5.1.2. Countering Sniffing Attacks . . . . . . . . . . . . . 20 5.1.2. Countering Sniffing Attacks . . . . . . . . . . . . . 20
5.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 21 5.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 21
5.1.4. Countering Physical Device Compromise . . . . . . . . 22 5.1.4. Countering Physical Device Compromise . . . . . . . . 22
5.1.5. Countering Remote Device Access Attacks . . . . . . . 24 5.1.5. Countering Remote Device Access Attacks . . . . . . . 24
5.2. Integrity Attack Countermeasures . . . . . . . . . . . . . 25 5.2. Integrity Attack Countermeasures . . . . . . . . . . . . . 25
5.2.1. Countering Tampering Attacks . . . . . . . . . . . . . 25 5.2.1. Countering Unauthorized Modification Attacks . . . . . 25
5.2.2. Countering Overclaiming and Misclaiming Attacks . . . 25 5.2.2. Countering Overclaiming and Misclaiming Attacks . . . 25
5.2.3. Countering Identity (including Sybil) Attacks . . . . 26 5.2.3. Countering Identity (including Sybil) Attacks . . . . 26
5.2.4. Countering Routing Information Replay Attacks . . . . 26 5.2.4. Countering Routing Information Replay Attacks . . . . 26
5.2.5. Countering Byzantine Routing Information Attacks . . . 26 5.2.5. Countering Byzantine Routing Information Attacks . . . 26
5.3. Availability Attack Countermeasures . . . . . . . . . . . 27 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 . . . . . . . . . . . . . . . . . . . . . . . 28 Attacks . . . . . . . . . . . . . . . . . . . . . . . 28
5.3.2. Countering Overload Attacks . . . . . . . . . . . . . 29 5.3.2. Countering Overload Attacks . . . . . . . . . . . . . 29
5.3.3. Countering Selective Forwarding Attacks . . . . . . . 30 5.3.3. Countering Selective Forwarding Attacks . . . . . . . 30
5.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 31 5.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 31
5.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 31 5.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 32
6. ROLL Security Features . . . . . . . . . . . . . . . . . . . . 32 6. ROLL Security Features . . . . . . . . . . . . . . . . . . . . 32
6.1. Confidentiality Features . . . . . . . . . . . . . . . . . 33 6.1. Confidentiality Features . . . . . . . . . . . . . . . . . 33
6.2. Integrity Features . . . . . . . . . . . . . . . . . . . . 34 6.2. Integrity Features . . . . . . . . . . . . . . . . . . . . 34
6.3. Availability Features . . . . . . . . . . . . . . . . . . 35 6.3. Availability Features . . . . . . . . . . . . . . . . . . 35
6.4. Additional Related Features and Key Management . . . . . . 35 6.4. Security Key Management . . . . . . . . . . . . . . . . . 36
6.5. Consideration on Matching Application Domain Needs . . . . 37 6.5. Consideration on Matching Application Domain Needs . . . . 37
6.5.1. Security Architecture . . . . . . . . . . . . . . . . 37 6.5.1. Security Architecture . . . . . . . . . . . . . . . . 37
6.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 40 6.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 40
7. Application of ROLL Security Framework to RPL . . . . . . . . 41 7. Application of ROLL Security Framework to RPL . . . . . . . . 41
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
9. Security Considerations . . . . . . . . . . . . . . . . . . . 43 9. Security Considerations . . . . . . . . . . . . . . . . . . . 44
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
11.1. Normative References . . . . . . . . . . . . . . . . . . . 44 11.1. Normative References . . . . . . . . . . . . . . . . . . . 44
11.2. Informative References . . . . . . . . . . . . . . . . . . 45 11.2. Informative References . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
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 16, line 21 skipping to change at page 16, line 21
The forms of attack that allow manipulation to compromise the content The forms of attack that allow manipulation to compromise the content
and validity of routing information include and validity of routing information include
o Falsification, including overclaiming and misclaiming; o Falsification, including overclaiming and misclaiming;
o Routing information replay; o Routing information replay;
o Byzantine (internal) attacks that permit corruption of routing o Byzantine (internal) attacks that permit corruption of routing
information in the node even where the node continues to be a information in the node even where the node continues to be a
validated entity within the network; validated entity within the network (see, for example, [RFC4593]
for further discussions on Byzantine attacks);
o Physical device compromise or remote device access attacks. o Physical device compromise or remote device access attacks.
4.2.2. Node Identity Misappropriation 4.2.2. Node Identity Misappropriation
Falsification or misappropriation of node identity between routing Falsification or misappropriation of node identity between routing
participants opens the door for other attacks; it can also cause participants opens the door for other attacks; it can also cause
incorrect routing relationships to form and/or topologies to emerge. incorrect routing relationships to form and/or topologies to emerge.
Routing attacks may also be mounted through less sophisticated node Routing attacks may also be mounted through less sophisticated node
identity misappropriation in which the valid information broadcast or identity misappropriation in which the valid information broadcast or
skipping to change at page 23, line 31 skipping to change at page 23, line 31
locations without the appropriate security keys and in preventing the locations without the appropriate security keys and in preventing the
access to any information exchanges occurring between individual access to any information exchanges occurring between individual
components. Information access will then be restricted to external components. Information access will then be restricted to external
interfaces in which confidentiality, integrity and authentication interfaces in which confidentiality, integrity and authentication
measures can be applied. measures can be applied.
To prevent component information access, deployed routing devices To prevent component information access, deployed routing devices
must ensure that their implementation avoids address or data buses must ensure that their implementation avoids address or data buses
being connected to external general purpose input/output (GPIO) pins. being connected to external general purpose input/output (GPIO) pins.
Beyond this measure, an important component interface to be protected Beyond this measure, an important component interface to be protected
against attack is the Joint Test Action Group (JTAG) interface used against attack is the Joint Test Action Group (JTAG) [IEEE1149.1]
for component and populated circuit board testing after manufacture. interface used for component and populated circuit board testing
To provide security on the routing devices, components should be after manufacture. To provide security on the routing devices,
employed that allow fuses on the JTAG interfaces to be blown to components should be employed that allow fuses on the JTAG interfaces
disable access. This will raise the bar on unauthorized component to be blown to disable access. This will raise the bar on
information access within a captured device. unauthorized component information access within a captured device.
At the device level a key component information exchange is between At the device level a key component information exchange is between
the microprocessor and it associated external memory. While the microprocessor and its associated external memory. While
encryption can be implemented to secure data bus exchanges, the use encryption can be implemented to secure data bus exchanges, the use
of integrated physical packaging which avoids inter-component of integrated physical packaging which avoids inter-component
exchanges (other than secure external device exchanges) will increase exchanges (other than secure external device exchanges) will increase
routing security against a physical device interface attack. With an routing security against a physical device interface attack. With an
integrated package and disabled internal component interfaces, the integrated package and disabled internal component interfaces, the
level of physical device security can be controlled by managing the level of physical device security can be controlled by managing the
degree to which the device packaging is protected against expert degree to which the device packaging is protected against expert
physical decomposition and analysis. physical decomposition and analysis.
The device package should be hardened such that attempts to remove The device package should be hardened such that attempts to remove
skipping to change at page 25, line 11 skipping to change at page 25, line 11
protocol security of routing information stored on the node against protocol security of routing information stored on the node against
remote access will not be addressable as part of the routing remote access will not be addressable as part of the routing
protocol. protocol.
5.2. Integrity Attack Countermeasures 5.2. Integrity Attack Countermeasures
Integrity attack countermeasures address routing information Integrity attack countermeasures address routing information
manipulation, as well as node identity and routing information manipulation, as well as node identity and routing information
misuse. Manipulation can occur in the form of falsification attack misuse. Manipulation can occur in the form of falsification attack
and physical compromise. To be effective, the following development and physical compromise. To be effective, the following development
considers the two aspects of falsification, namely, the tampering considers the two aspects of falsification, namely, the unauthorized
actions and the overclaiming and misclaiming content. The countering modifications and the overclaiming and misclaiming content. The
of physical compromise was considered in the previous section and is countering of physical compromise was considered in the previous
not repeated here. With regard to misuse, there are two types of section and is not repeated here. With regard to misuse, there are
attacks to be deterred, identity attacks and replay attacks. two types of attacks to be deterred, identity attacks and replay
attacks.
5.2.1. Countering Tampering Attacks 5.2.1. Countering Unauthorized Modification Attacks
Tampering may occur in the form of altering the message being Unauthorized modifications may occur in the form of altering the
transferred or the data stored. Therefore, it is necessary to ensure message being transferred or the data stored. Therefore, it is
that only authorized nodes can change the portion of the information necessary to ensure that only authorized nodes can change the portion
that is allowed to be mutable, while the integrity of the rest of the of the information that is allowed to be mutable, while the integrity
information is protected, e.g., through well-studied cryptographic of the rest of the information is protected, e.g., through well-
mechanisms. studied cryptographic mechanisms.
Tampering may also occur in the form of insertion or deletion of Unauthorized modifications may also occur in the form of insertion or
messages during protocol changes. Therefore, the protocol needs to deletion of messages during protocol changes. Therefore, the
ensure the integrity of the sequence of the exchange sequence. protocol needs to ensure the integrity of the sequence of the
exchange sequence.
The countermeasure to tampering needs to The countermeasure to unauthorized modifications needs to
o implement access control on storage; o implement access control on storage;
o provide data integrity service to transferred messages and stored o provide data integrity service to transferred messages and stored
data; data;
o include sequence number under integrity protection. o include sequence number under integrity protection.
5.2.2. Countering Overclaiming and Misclaiming Attacks 5.2.2. Countering Overclaiming and Misclaiming Attacks
Both overclaiming and misclaiming aim to introduce false routes or Both overclaiming and misclaiming aim to introduce false routes or
topology that would not be generated by the network otherwise, while topology that would not be generated by the network otherwise, while
there is not necessarily tampering. The requisite for a counter is there are not necessarily unauthorized modifications to the routing
the capability to determine unreasonable routes or topology. messages or information. The requisite for a counter is the
capability to determine unreasonable routes or topology.
The counter to overclaiming and misclaiming may employ The counter to overclaiming and misclaiming may employ
o comparison with historical routing/topology data; o comparison with historical routing/topology data;
o designs which restrict realizable network topologies. o designs which restrict realizable network topologies.
5.2.3. Countering Identity (including Sybil) Attacks 5.2.3. Countering Identity (including Sybil) Attacks
Identity attacks, sometimes simply called spoofing, seek to gain or Identity attacks, sometimes simply called spoofing, seek to gain or
damage assets whose access is controlled through identity. In damage assets whose access is controlled through identity. In
routing, an identity attacker can illegitimately participate in routing, an identity attacker can illegitimately participate in
routing exchanges, distribute false routing information, or cause an routing exchanges, distribute false routing information, or cause an
invalid outcome of a routing process. invalid outcome of a routing process.
skipping to change at page 27, line 7 skipping to change at page 27, line 10
a period with valid network security credentials, the potential a period with valid network security credentials, the potential
exists for routing information to be manipulated. This compromise of exists for routing information to be manipulated. This compromise of
the routing information could thus exist in spite of security the routing information could thus exist in spite of security
countermeasures that operate between the peer routing devices. countermeasures that operate between the peer routing devices.
Consistent with the end-to-end principle of communications, such an Consistent with the end-to-end principle of communications, such an
attack can only be fully addressed through measures operating attack can only be fully addressed through measures operating
directly between the routing entities themselves or by means of directly between the routing entities themselves or by means of
external entities able to access and independently analyze the external entities able to access and independently analyze the
routing information. Verification of the authenticity and liveliness routing information. Verification of the authenticity and liveliness
of the routing principals can therefore only provide a limited of the routing entities can therefore only provide a limited counter
counter against internal (Byzantine) node attacks. against internal (Byzantine) node attacks.
For link state routing protocols where information is flooded with, For link state routing protocols where information is flooded with,
for example, areas (OSPF [RFC2328]) or levels (ISIS [RFC1142]), for example, areas (OSPF [RFC2328]) or levels (ISIS [RFC1142]),
countermeasures can be directly applied by the routing entities countermeasures can be directly applied by the routing entities
through the processing and comparison of link state information through the processing and comparison of link state information
received from different peers. By comparing the link information received from different peers. By comparing the link information
from multiple sources decisions can be made by a routing node or from multiple sources decisions can be made by a routing node or
external entity with regard to routing information validity. external entity with regard to routing information validity; see
Chapter 2 of [Perlman1988] for a discussion on flooding attacks.
For distance vector protocols where information is aggregated at each For distance vector protocols where information is aggregated at each
routing node it is not possible for nodes to directly detect routing node it is not possible for nodes to directly detect
Byzantine information manipulation attacks from the routing Byzantine information manipulation attacks from the routing
information exchange. In such cases, the routing protocol must information exchange. In such cases, the routing protocol must
include and support indirect communications exchanges between non- include and support indirect communications exchanges between non-
adjacent routing peers to provide a secondary channel for performing adjacent routing peers to provide a secondary channel for performing
routing information validation. S-RIP [Wan2004] is an example of the routing information validation. S-RIP [Wan2004] is an example of the
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
skipping to change at page 29, line 26 skipping to change at page 29, line 29
which is significantly more sensitive than that of a normal node, which is significantly more sensitive than that of a normal node,
thereby effectively extending its range. Since an ACK spoofing thereby effectively extending its range. Since an ACK spoofing
attack facilitates a HELLO flood attack, similar countermeasure are attack facilitates a HELLO flood attack, similar countermeasure are
applicable here. Viable counter and security measures for both applicable here. Viable counter and security measures for both
attacks have been exposed in [I-D.suhopark-hello-wsn]. attacks have been exposed in [I-D.suhopark-hello-wsn].
5.3.2. Countering Overload Attacks 5.3.2. Countering Overload Attacks
Overload attacks are a form of DoS attack in that a malicious node Overload attacks are a form of DoS attack in that a malicious node
overloads the network with irrelevant traffic, thereby draining the overloads the network with irrelevant traffic, thereby draining the
nodes' energy budget quicker, when the nodes rely on battery or nodes' energy store quicker, when the nodes rely on battery or energy
energy scavenging. It thus significantly shortens the lifetime of scavenging. It thus significantly shortens the lifetime of networks
networks of battery nodes and constitutes another serious of battery nodes and constitutes another serious availability attack.
availability attack.
With energy being one of the most precious assets of LLNs, targeting With energy being one of the most precious assets of LLNs, targeting
its availability is a fairly obvious attack. Another way of its availability is a fairly obvious attack. Another way of
depleting the energy of a LLN node is to have the malicious node depleting the energy of a LLN node is to have the malicious node
overload the network with irrelevant traffic. This impacts overload the network with irrelevant traffic. This impacts
availability since certain routes get congested which availability since certain routes get congested which
o renders them useless for affected nodes and data can hence not be o renders them useless for affected nodes and data can hence not be
delivered; delivered;
skipping to change at page 30, line 25 skipping to change at page 30, line 28
that more traffic is injected into the network than allowed by a that more traffic is injected into the network than allowed by a
prior set or dynamically adjusted threshold. Finally, if prior set or dynamically adjusted threshold. Finally, if
communication is sufficiently secured, only trusted nodes can receive communication is sufficiently secured, only trusted nodes can receive
and forward traffic which also lowers the risk of an overload attack. and forward traffic which also lowers the risk of an overload attack.
Receiving nodes that validate signatures and sending nodes that Receiving nodes that validate signatures and sending nodes that
encrypt messages need to be cautious of cryptographic processing encrypt messages need to be cautious of cryptographic processing
usage when validating signatures and encrypting messages. Where usage when validating signatures and encrypting messages. Where
feasible, certificates should be validated prior to use of the feasible, certificates should be validated prior to use of the
associated keys to counter potential resource overloading attacks. associated keys to counter potential resource overloading attacks.
Alternatively, resource management limits can be placed on routing The associated design decision needs to also consider that the
security processing events (see [RFC5751]). validation process requires resources and thus itself could be
exploited for attacks. Alternatively, resource management limits can
be placed on routing security processing events (see the comment in
Section 6, paragraph 4, of [RFC5751]).
5.3.3. Countering Selective Forwarding Attacks 5.3.3. Countering Selective Forwarding Attacks
Selective forwarding attacks are another form of DoS attack which Selective forwarding attacks are another form of DoS attack which
impacts the routing path availability. impacts the routing path availability.
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
skipping to change at page 31, line 16 skipping to change at page 31, line 23
consumption point of view. The second method basically involves a consumption point of view. The second method basically involves a
constantly changing routing topology in that next-hop routers are constantly changing routing topology in that next-hop routers are
chosen from a dynamic set in the hope that the number of malicious chosen from a dynamic set in the hope that the number of malicious
nodes in this set is negligible. A routing protocol that allows for nodes in this set is negligible. A routing protocol that allows for
disjoint routing paths may also be useful. disjoint routing paths may also be useful.
5.3.4. Countering Sinkhole Attacks 5.3.4. Countering Sinkhole Attacks
In sinkhole attacks, the malicious node manages to attract a lot of In sinkhole attacks, the malicious node manages to attract a lot of
traffic mainly by advertising the availability of high-quality links traffic mainly by advertising the availability of high-quality links
even though there are none. It hence constitutes a serious attack on even though there are none [Karlof2003]. It hence constitutes a
availability. serious attack on availability.
The malicious node creates a sinkhole by attracting a large amount The malicious node creates a sinkhole by attracting a large amount
of, if not all, traffic from surrounding neighbors by advertising in of, if not all, traffic from surrounding neighbors by advertising in
and outwards links of superior quality. Affected nodes hence eagerly and outwards links of superior quality. Affected nodes hence eagerly
route their traffic via the malicious node which, if coupled with route their traffic via the malicious node which, if coupled with
other attacks such as selective forwarding, may lead to serious other attacks such as selective forwarding, may lead to serious
availability and security breaches. Such an attack can only be availability and security breaches. Such an attack can only be
executed by an inside malicious node and is generally very difficult executed by an inside malicious node and is generally very difficult
to detect. An ongoing attack has a profound impact on the network to detect. An ongoing attack has a profound impact on the network
topology and essentially becomes a problem of flow control. topology and essentially becomes a problem of flow control.
skipping to change at page 31, line 51 skipping to change at page 32, line 9
use of geographical information deserves further attention. use of geographical information deserves further attention.
Essentially, if geographic positions of nodes are available, then the Essentially, if geographic positions of nodes are available, then the
network can assure that data is actually routed towards the intended network can assure that data is actually routed towards the intended
destination and not elsewhere. On the other hand, geographic destination and not elsewhere. On the other hand, geographic
position is a sensitive information that has security and/or privacy position is a sensitive information that has security and/or privacy
consequences (see Section 6.1). consequences (see Section 6.1).
5.3.5. Countering Wormhole Attacks 5.3.5. Countering Wormhole Attacks
In wormhole attacks at least two malicious nodes shortcut or divert In wormhole attacks at least two malicious nodes shortcut or divert
the usual routing path by means of a low-latency out-of-band channel. the usual routing path by means of a low-latency out-of-band channel
[Karlof2003]. This changes the availability of certain routing paths
This changes the availability of certain routing paths and hence and hence constitutes a serious security breach.
constitutes a serious security breach.
Essentially, two malicious insider nodes use another, more powerful, Essentially, two malicious insider nodes use another, more powerful,
transmitter to communicate with each other and thereby distort the transmitter to communicate with each other and thereby distort the
would-be-agreed routing path. This distortion could involve would-be-agreed routing path. This distortion could involve
shortcutting and hence paralyzing a large part of the network; it shortcutting and hence paralyzing a large part of the network; it
could also involve tunneling the information to another region of the could also involve tunneling the information to another region of the
network where there are, e.g., more malicious nodes available to aid network where there are, e.g., more malicious nodes available to aid
the intrusion or where messages are replayed, etc. In conjunction the intrusion or where messages are replayed, etc. In conjunction
with selective forwarding, wormhole attacks can create race with selective forwarding, wormhole attacks can create race
conditions which impact topology maintenance, routing protocols as conditions which impact topology maintenance, routing protocols as
skipping to change at page 33, line 19 skipping to change at page 33, line 25
addressed as part of the routing protocol itself. As routing is one addressed as part of the routing protocol itself. As routing is one
component of a LLN system, the actual strength of the security component of a LLN system, the actual strength of the security
services afforded to it should be made to conform to each system's services afforded to it should be made to conform to each system's
security policy; how a design may address the needs of the urban, security policy; how a design may address the needs of the urban,
industrial, home automation, and building automation application industrial, home automation, and building automation application
domains also needs to be considered. The second part of this domains also needs to be considered. The second part of this
section, Section 6.4 and Section 6.5, discusses system security section, Section 6.4 and Section 6.5, discusses system security
aspects that may impact routing but that also require considerations aspects that may impact routing but that also require considerations
beyond the routing protocol, as well as potential approaches. beyond the routing protocol, as well as potential approaches.
If a LLN employs multicast and/or anycast, these alternative
communications modes MUST be secured with the same routing security
services specified in this section. Furthermore, irrespective of the
modes of communication, nodes MUST provide adequate physical tamper
resistance commensurate with the particular application domain
environment to ensure the confidentiality, integrity and availability
of stored routing information.
6.1. Confidentiality Features 6.1. Confidentiality Features
With regard to confidentiality, protecting the routing/topology With regard to confidentiality, protecting the routing/topology
information from eavesdropping or unauthorized exposure is not information from eavesdropping or unauthorized exposure is not
directly essential to maintaining the routing function. Breaches of directly essential to maintaining the routing function. Breaches of
confidentiality may lead to other attacks or the focusing of an confidentiality may lead to other attacks or the focusing of an
attacker's resources (see Section 4.1) but does not of itself attacker's resources (see Section 4.1) but does not of itself
directly undermine the operation of the routing function. However, directly undermine the operation of the routing function. However,
to protect against, and improve vulnerability against other more to protect against, and improve vulnerability against other more
direct attacks, routing information confidentiality should be direct attacks, routing information confidentiality should be
skipping to change at page 34, line 27 skipping to change at page 34, line 41
6.2. Integrity Features 6.2. Integrity Features
The integrity of routing information provides the basis for ensuring The integrity of routing information provides the basis for ensuring
that the function of the routing protocol is achieved and maintained. that the function of the routing protocol is achieved and maintained.
To protect integrity, a secured ROLL protocol To protect integrity, a secured ROLL protocol
o MUST provide and verify message integrity (including integrity of o MUST provide and verify message integrity (including integrity of
the encrypted message when confidentiality is applied); the encrypted message when confidentiality is applied);
o MUST verify the authenticity and liveliness of both principals of o MUST verify the authenticity and liveness of both principals of a
a connection (independent of the device interface over which the connection (independent of the device interface over which the
information is received or accessed); information is received or accessed);
o MUST verify message sequence; o MUST verify message sequence;
o SHOULD incorporate protocol-specific parameter validity range o SHOULD incorporate protocol-specific parameter validity range
checks, change increments and message event frequency checks, etc. checks, change increments and message event frequency checks, etc.
as a means of countering intentional or unintentional Byzantine as a means of countering intentional or unintentional Byzantine
threats; threats;
o MAY incorporate external consistency checking and auditing of o MAY incorporate external consistency checking and auditing of
skipping to change at page 35, line 35 skipping to change at page 36, line 4
6.3. Availability Features 6.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 6.5). Where availability of the network is compromised, Section 6.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 insights for flow control. o MAY use geographic information for flow control.
6.4. Additional Related Features and Key Management
If a LLN employs multicast and/or anycast, it MUST secure these 6.4. Security Key Management
mechanisms with the services listed in this sections. Furthermore,
the nodes MUST provide adequate physical tamper resistance to ensure
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 have a process for key and credential requirement, a LLN MUST have a process for key and credential
distribution, as well as secure storage within the associated devices distribution, as well as secure storage within the associated devices
(including use of trusted platform modules where feasible and (including use of trusted platform modules where feasible and
appropriate to the operating environment). A LLN is encouraged to appropriate to the operating environment). A LLN is encouraged to
have automatic procedures for the revocation and replacement of have automatic procedures for the revocation and replacement of
maintained security credentials. maintained security credentials.
Individual routing peer associations and signaling exchanges will Individual routing peer associations and signaling exchanges will
require the generation and use of keys that may be derived from require the generation and use of keys that may be derived from
public key exchanges or obtained through other device configuration public key exchanges or obtained through other device configuration
means. Correspondingly, the routing protocol(s) specified by the means. Correspondingly, the routing protocol(s) specified by the
ROLL Working Group will assume the provision of key management ROLL Working Group SHOULD employ the provision of key management
mechanisms consistent with the guidelines given in [RFC4107]. Based mechanisms consistent with the guidelines given in [RFC4107]. Based
on that RFC's recommendations, many LLNs, particularly given the on that RFC's recommendations, many LLNs, particularly given the
intended scale and ad hoc device associations, will satisfy the intended scale and ad hoc device associations, will satisfy the
requirement for supporting automated key management in conjunction requirement for supporting automated key management in conjunction
with the routing protocol operation. These automated routing session with the routing protocol operation. These automated routing session
keys may be derived from pre-stored security credentials or other keys may be derived from pre-stored security credentials or other
authenticated key management mechanisms. authenticated key management mechanisms.
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 key management and the distribution of used to support authenticated key management and the distribution of
routing security keying material. Note that where the option for a routing security keying material. Note that where the option for a
PKI is supported for security of the routing protocol itself, the PKI is supported for security of the routing protocol itself, the
routing protocol MUST include provisions for public certificates to routing protocol MUST include provisions for public key certificates
be included or referenced within routing messages to allow a node's to be included or referenced within routing messages to allow a
public key to be shared with communicating peers. Even if the node's public key to be shared with communicating peers. Even if the
certificate itself is not distributed by the node, there needs to be certificate itself is not distributed by the node, there needs to be
a mechanism to inform the receiving node where to find the a mechanism to inform the receiving node where to find the
certificate and obtain associated validation information; see certificate and obtain associated validation information; see
[RFC3029] for an example of the kind of localized PKI support that [RFC3029] for an example of the kind of localized PKI support that
may be applied in a given LLN environment. Where PKI systems are not may be applied in a given LLN environment. Where PKI systems are not
feasible, the key management system must support means for secure feasible, the key management system MUST support means for secure
configuration, device authentication, and adherence to secure key configuration, device authentication, and adherence to secure key
wrapping principles for the secure distribution and update of device wrapping principles for the secure distribution and update of device
keys. 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 key management is defined separate from the routing protocol Where key management is defined separate from the routing protocol
security, LLN application domains can appropriately employ IETF- security, LLN application domains can appropriately employ IETF-
skipping to change at page 39, line 31 skipping to change at page 39, line 41
layer or higher or lower protocol layers(s)) according to the layer or higher or lower protocol layers(s)) according to the
particular application domain and user network configuration. particular application domain and user network configuration.
Based on device capabilities and the spectrum of operating Based on device capabilities and the spectrum of operating
environments it would be difficult for a single fixed security design environments it would be difficult for a single fixed security design
to be applied to address the diversified needs of the urban, to be applied to address the diversified needs of the urban,
industrial, home, and building ROLL application domains, and industrial, home, and building ROLL application domains, and
foreseeable others, without forcing a very low common denominator set foreseeable others, without forcing a very low common denominator set
of requirements. On the other hand, providing four individual domain of requirements. On the other hand, providing four individual domain
designs that attempt to a priori match each individual domain is also designs that attempt to a priori match each individual domain is also
very likely to provide a suitable answer given the degree of network very unlikely to provide a suitable answer given the degree of
variability even within a given domain; furthermore, the type of link network variability even within a given domain; furthermore, the type
layers in use within each domain also influences the overall of link layers in use within each domain also influences the overall
security. security.
Instead, the framework implementation approach recommended for Instead, the framework implementation approach recommended is for
optional, routing protocol-specific measures that can be applied optional, routing protocol-specific measures that can be applied
separate from or together with flexible transport network mechanisms. separately from, or together with, flexible transport network
Protocol-specific measures include the specification of valid mechanisms. Protocol-specific measures include the specification of
parameter ranges, increments and/or event frequencies that can be valid parameter ranges, increments and/or event frequencies that can
verified by individually routing devices. In addition to deliberate be verified by individual routing devices. In addition to deliberate
attacks this allows basic protocol sanity checks against attacks this allows basic protocol sanity checks against
unintentional mis-configuration. Transport network mechanisms would unintentional mis-configuration. Transport network mechanisms would
include out-of-band communications that may be defined to allow an include out-of-band communications that may be defined to allow an
external entity to request and process individual device information external entity to request and process individual device information
as a means to deriving an external verification of the derived as a means to effecting an external verification of the derived
network routing to identify the existence of intention or network routing information to identify the existence of intentional
unintentional network anomalies. or unintentional network anomalies.
This approach allows countermeasures against internal attacks to be This approach allows countermeasures against internal attacks to be
applied in environments where applicable threats exist. At the same applied in environments where applicable threats exist. At the same
time, it allows routing protocol security to be supported through time, it allows routing protocol security to be supported through
measures implemented within the transport network that are consistent measures implemented within the transport network that are consistent
with available system resources and commensurate and consistent with with available system resources and commensurate and consistent with
the security level and strength applied in the particular application the security level and strength applied in the particular application
domain networks. domain networks.
6.5.2. Mechanisms and Operations 6.5.2. Mechanisms and Operations
With an architecture allowing different configurations to meet the With an architecture allowing different configurations to meet the
application domain needs, the task is then to find suitable application domain needs, the task is then to find suitable
mechanisms. For example, one of the main problems of synchronizing mechanisms. For example, one of the main problems of synchronizing
security states of sleepy nodes, as listed in the last subsection, security states of sleepy nodes, as listed in the last subsection,
lies in difficulties in authentication; these nodes may not have lies in difficulties in authentication; these nodes may not have
received in time the most recent update of security material. received in time the most recent update of security material.
Similarly, the issues of minimal manual configuration, prolonged Similarly, the issues of minimal manual configuration, prolonged
rollout and delayed addition of nodes, and network topology changes rollout and delayed addition of nodes, and network topology changes
also complicate security management. In many cases the ROLL protocol also complicate security management. In many cases the ROLL protocol
may need to bootstrap the authentication process and allow for may need to bootstrap the authentication process and allow for a
flexible expiration scheme of authentication credentials. This flexible expiration scheme of authentication credentials. This
exemplifies the need for the coordination and interoperation between exemplifies the need for the coordination and interoperation between
the requirements of the ROLL routing protocol and that of the system the requirements of the ROLL routing protocol and that of the system
security elements. security elements.
Similarly, the vulnerability brought forth by some special-function Similarly, the vulnerability brought forth by some special-function
nodes, e.g., LBRs requires the assurance, particularly, of the nodes, e.g., LBRs requires the assurance, particularly, of the
availability of communication channels and node resources, or that availability of communication channels and node resources, or that
the neighbor discovery process operates without undermining routing the neighbor discovery process operates without undermining routing
availability. availability.
There and other factors which are not part of a ROLL routing protocol There are other factors which are not part of a ROLL routing protocol
can still affect its operation. This includes elements such as but which can still affect its operation. These include elements
weaker barrier to accessing the data or security material stored on such as weaker barrier to accessing the data or security material
the nodes through physical means; therefore, the internal and stored on the nodes through physical means; therefore, the internal
external interfaces of a node need to be adequate for guarding the and external interfaces of a node need to be adequate for guarding
integrity, and possibly the confidentiality, of stored information, the integrity, and possibly the confidentiality, of stored
as well as the integrity of routing and route generation processes. information, as well as the integrity of routing and route generation
processes.
Figure 3 provides an overview of the larger context of system Figure 3 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
| | | |
+---+ +---+ +---+ +---+
skipping to change at page 45, line 29 skipping to change at page 45, line 33
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-05 (work in Networks", draft-ietf-roll-terminology-05 (work in
progress), March 2011. progress), March 2011.
[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]
"IEEE Standard Test Access Port and Boundary Scan
Architecture", IEEE-SA Standards Board, Jun. 14 2001.
[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 confidentiality
and integrity algorithms; Document 2: Kasumi and integrity algorithms; Document 2: Kasumi
specification", 3GPP TSG SA3, 2009. specification", 3GPP TSG SA3, 2009.
skipping to change at page 46, line 5 skipping to change at page 46, line 14
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, 2005. 29, 2005.
[Perlman1988]
Perlman, N., "Network Layer Protocols with Byzantine
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 1142, February 1990. RFC 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 1998. November 1998.
 End of changes. 41 change blocks. 
86 lines changed or deleted 102 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/