draft-ietf-roll-security-threats-07.txt   draft-ietf-roll-security-threats-08.txt 
Routing Over Low-Power and Lossy Networks T. Tsao Routing Over Low-Power and Lossy Networks T. Tsao
Internet-Draft R. Alexander Internet-Draft R. Alexander
Intended status: Informational Cooper Power Systems Intended status: Informational Cooper Power Systems
Expires: December 12, 2014 M. Dohler Expires: January 20, 2015 M. Dohler
CTTC CTTC
V. Daza V. Daza
A. Lozano A. Lozano
Universitat Pompeu Fabra Universitat Pompeu Fabra
M. Richardson M. Richardson, Ed.
Sandelman Software Works Sandelman Software Works
June 10, 2014 July 19, 2014
A Security Threat Analysis for Routing Protocol for Low-power and lossy A Security Threat Analysis for Routing Protocol for Low-power and lossy
networks (RPL) networks (RPL)
draft-ietf-roll-security-threats-07 draft-ietf-roll-security-threats-08
Abstract Abstract
This document presents a security threat analysis for the Routing This document presents a security threat analysis for the Routing
Protocol for Low-power and lossy networks (RPL, ROLL). The Protocol for Low-power and lossy networks (RPL, ROLL). The
development builds upon previous work on routing security and adapts development builds upon previous work on routing security and adapts
the assessments to the issues and constraints specific to low-power the assessments to the issues and constraints specific to low-power
and lossy networks. A systematic approach is used in defining and and lossy networks. A systematic approach is used in defining and
evaluating the security threats. Applicable countermeasures are evaluating the security threats. Applicable countermeasures are
application specific and are addressed in relevant applicability application specific and are addressed in relevant applicability
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 12, 2014. This Internet-Draft will expire on January 20, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 50 skipping to change at page 2, line 50
6.1.1. Node Impersonation . . . . . . . . . . . . . . . . . 13 6.1.1. Node Impersonation . . . . . . . . . . . . . . . . . 13
6.1.2. Dummy Node . . . . . . . . . . . . . . . . . . . . . 14 6.1.2. Dummy Node . . . . . . . . . . . . . . . . . . . . . 14
6.1.3. Node Resource Spam . . . . . . . . . . . . . . . . . 14 6.1.3. Node Resource Spam . . . . . . . . . . . . . . . . . 14
6.2. Threats and Attacks on Confidentiality . . . . . . . . . 14 6.2. Threats and Attacks on Confidentiality . . . . . . . . . 14
6.2.1. Routing Exchange Exposure . . . . . . . . . . . . . . 14 6.2.1. Routing Exchange Exposure . . . . . . . . . . . . . . 14
6.2.2. Routing Information (Routes and Network Topology) 6.2.2. Routing Information (Routes and Network Topology)
Exposure . . . . . . . . . . . . . . . . . . . . . . 14 Exposure . . . . . . . . . . . . . . . . . . . . . . 14
6.3. Threats and Attacks on Integrity . . . . . . . . . . . . 15 6.3. Threats and Attacks on Integrity . . . . . . . . . . . . 15
6.3.1. Routing Information Manipulation . . . . . . . . . . 15 6.3.1. Routing Information Manipulation . . . . . . . . . . 15
6.3.2. Node Identity Misappropriation . . . . . . . . . . . 16 6.3.2. Node Identity Misappropriation . . . . . . . . . . . 16
6.4. Threats and Attacks on Availability . . . . . . . . . . . 17 6.4. Threats and Attacks on Availability . . . . . . . . . . . 16
6.4.1. Routing Exchange Interference or Disruption . . . . . 17 6.4.1. Routing Exchange Interference or Disruption . . . . . 16
6.4.2. Network Traffic Forwarding Disruption . . . . . . . . 17 6.4.2. Network Traffic Forwarding Disruption . . . . . . . . 17
6.4.3. Communications Resource Disruption . . . . . . . . . 18 6.4.3. Communications Resource Disruption . . . . . . . . . 18
6.4.4. Node Resource Exhaustion . . . . . . . . . . . . . . 19 6.4.4. Node Resource Exhaustion . . . . . . . . . . . . . . 18
7. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 20 7. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Confidentiality Attack Countermeasures . . . . . . . . . 20 7.1. Confidentiality Attack Countermeasures . . . . . . . . . 19
7.1.1. Countering Deliberate Exposure Attacks . . . . . . . 20 7.1.1. Countering Deliberate Exposure Attacks . . . . . . . 19
7.1.2. Countering Passive Wiretapping Attacks . . . . . . . 21 7.1.2. Countering Passive Wiretapping Attacks . . . . . . . 20
7.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 21 7.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 21
7.1.4. Countering Remote Device Access Attacks . . . . . . . 22 7.1.4. Countering Remote Device Access Attacks . . . . . . . 21
7.2. Integrity Attack Countermeasures . . . . . . . . . . . . 22 7.2. Integrity Attack Countermeasures . . . . . . . . . . . . 22
7.2.1. Countering Unauthorized Modification Attacks . . . . 23 7.2.1. Countering Unauthorized Modification Attacks . . . . 22
7.2.2. Countering Overclaiming and Misclaiming Attacks . . . 23 7.2.2. Countering Overclaiming and Misclaiming Attacks . . . 23
7.2.3. Countering Identity (including Sybil) Attacks . . . . 24 7.2.3. Countering Identity (including Sybil) Attacks . . . . 23
7.2.4. Countering Routing Information Replay Attacks . . . . 24 7.2.4. Countering Routing Information Replay Attacks . . . . 23
7.2.5. Countering Byzantine Routing Information Attacks . . 25 7.2.5. Countering Byzantine Routing Information Attacks . . 24
7.3. Availability Attack Countermeasures . . . . . . . . . . . 25 7.3. Availability Attack Countermeasures . . . . . . . . . . . 25
7.3.1. Countering HELLO Flood Attacks and ACK Spoofing 7.3.1. Countering HELLO Flood Attacks and ACK Spoofing
Attacks . . . . . . . . . . . . . . . . . . . . . . . 26 Attacks . . . . . . . . . . . . . . . . . . . . . . . 25
7.3.2. Countering Overload Attacks . . . . . . . . . . . . . 26 7.3.2. Countering Overload Attacks . . . . . . . . . . . . . 26
7.3.3. Countering Selective Forwarding Attacks . . . . . . . 28 7.3.3. Countering Selective Forwarding Attacks . . . . . . . 27
7.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 29 7.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 28
7.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 30 7.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 29
8. RPL Security Features . . . . . . . . . . . . . . . . . . . . 30 8. RPL Security Features . . . . . . . . . . . . . . . . . . . . 29
8.1. Confidentiality Features . . . . . . . . . . . . . . . . 31 8.1. Confidentiality Features . . . . . . . . . . . . . . . . 30
8.2. Integrity Features . . . . . . . . . . . . . . . . . . . 32 8.2. Integrity Features . . . . . . . . . . . . . . . . . . . 31
8.3. Availability Features . . . . . . . . . . . . . . . . . . 33 8.3. Availability Features . . . . . . . . . . . . . . . . . . 31
8.4. Key Management . . . . . . . . . . . . . . . . . . . . . 33 8.4. Key Management . . . . . . . . . . . . . . . . . . . . . 32
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 34 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
12.1. Normative References . . . . . . . . . . . . . . . . . . 34 12.1. Normative References . . . . . . . . . . . . . . . . . . 33
12.2. Informative References . . . . . . . . . . . . . . . . . 35 12.2. Informative References . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
In recent times, networked electronic devices have found an In recent times, networked electronic devices have found an
increasing number of applications in various fields. Yet, for increasing number of applications in various fields. Yet, for
reasons ranging from operational application to economics, these reasons ranging from operational application to economics, these
wired and wireless devices are often supplied with minimum physical wired and wireless devices are often supplied with minimum physical
resources; the constraints include those on computational resources resources; the constraints include those on computational resources
(RAM, clock speed, storage), communication resources (duty cycle, (RAM, clock speed, storage), communication resources (duty cycle,
packet size, etc.), but also form factors that may rule out user packet size, etc.), but also form factors that may rule out user
skipping to change at page 4, line 41 skipping to change at page 4, line 41
describes a subset of these protocols and the conditions which make describes a subset of these protocols and the conditions which make
the subset the correct choice. The text recommends and motivates the the subset the correct choice. The text recommends and motivates the
accompanying parameter value ranges. Multiple applicability domains accompanying parameter value ranges. Multiple applicability domains
are recognized including: Building and Home, and Advanced Metering are recognized including: Building and Home, and Advanced Metering
Infrastructure. The applicability domains distinguish themselves in Infrastructure. The applicability domains distinguish themselves in
the way they are operated, their performance requirements, and the the way they are operated, their performance requirements, and the
most probable network structures. Each applicability statement most probable network structures. Each applicability statement
identifies the distinguishing properties according to a common set of identifies the distinguishing properties according to a common set of
subjects described in as many sections. subjects described in as many sections.
The common set of security threats are herein are referred to by the The common set of security threats herein are referred to by the
applicability statements, and that series of documents describes the applicability statements, and that series of documents describes the
preferred security settings and solutions within the applicability preferred security settings and solutions within the applicability
statement conditions. This applicability statements may recommend statement conditions. This applicability statements may recommend
more light weight security solutions and specify the conditions under more light weight security solutions and specify the conditions under
which these solutions are appropriate. which these solutions are appropriate.
3. Terminology 3. Terminology
This document adopts the terminology defined in [RFC6550], in This document adopts the terminology defined in [RFC6550], in
[RFC4949], and in [I-D.ietf-roll-terminology]. [RFC4949], and in [I-D.ietf-roll-terminology].
skipping to change at page 7, line 45 skipping to change at page 7, line 45
attempts to misrepresent routing topology. Indeed, the intention of attempts to misrepresent routing topology. Indeed, the intention of
the security threat analysis is to be comprehensive. Hence, some of the security threat analysis is to be comprehensive. Hence, some of
the discussion which follows is associated with assets and points of the discussion which follows is associated with assets and points of
access that are not directly related to routing protocol design but access that are not directly related to routing protocol design but
nonetheless provided for reference since they do have direct nonetheless provided for reference since they do have direct
consequences on the security of routing. consequences on the security of routing.
4.2. The ISO 7498-2 Security Reference Model 4.2. The ISO 7498-2 Security Reference Model
At the conceptual level, security within an information system in At the conceptual level, security within an information system in
general and applied to RPL; in particular is concerned with the general and applied to RPL in particular is concerned with the
primary issues of authentication, access control, data primary issues of authentication, access control, data
confidentiality, data integrity, and non-repudiation. In the context confidentiality, data integrity, and non-repudiation. In the context
of RPL of RPL:
Authentication Authentication
Authentication involves the mutual authentication of the Authentication involves the mutual authentication of the
routing peers prior to exchanging route information (i.e., peer routing peers prior to exchanging route information (i.e., peer
authentication) as well as ensuring that the source of the authentication) as well as ensuring that the source of the
route data is from the peer (i.e., data origin authentication). route data is from the peer (i.e., data origin authentication).
[RFC5548] points out that LLNs can be drained by [RFC5548] points out that LLNs can be drained by
unauthenticated peers before configuration. [RFC5673] requires unauthenticated peers before configuration. [RFC5673] requires
availability of open and untrusted side channels for new availability of open and untrusted side channels for new
joiners, and it requires strong and automated authentication so joiners, and it requires strong and automated authentication so
skipping to change at page 13, line 37 skipping to change at page 13, line 37
inside or outside attackers. While some attackers inside the network inside or outside attackers. While some attackers inside the network
will be using compromised nodes, and therefore are only able to do will be using compromised nodes, and therefore are only able to do
what an ordinary node can ("node-equivalent"), other attacks may not what an ordinary node can ("node-equivalent"), other attacks may not
limited in memory, CPU, power consumption or long term storage. limited in memory, CPU, power consumption or long term storage.
Moore's law favours the attacker with access to the latest Moore's law favours the attacker with access to the latest
capabilities, while the defenders will remain in place for years to capabilities, while the defenders will remain in place for years to
decades. decades.
6.1. Threats due to failures to Authenticate 6.1. Threats due to failures to Authenticate
An attacker can assert an arbitrary identity, including the identity
of another node is said to be able to assert "any" identity.
6.1.1. Node Impersonation 6.1.1. Node Impersonation
If an attacker can join a network using any identity, then it may be If an attacker can join a network using any identity, then it may be
able to assume the role of a legitimate (and existing node). It may able to assume the role of a legitimate (and existing node). It may
be able to report false readings (in metering applications), or be able to report false readings (in metering applications), or
provide inappropriate control messages (in control systems involving provide inappropriate control messages (in control systems involving
actuators) if the security of the application is implied by the actuators) if the security of the application is implied by the
security of the routing system. security of the routing system.
Even in systems where there application layer security, the ability Even in systems where there application layer security, the ability
to impersonate a node would permit an attacker to direct traffic to to impersonate a node would permit an attacker to direct traffic to
itself. This may permit various on-path attacks which would itself. This may permit various on-path attacks which would
otherwise be difficult, such replaying, delaying, or duplicating otherwise be difficult, such replaying, delaying, or duplicating
(application) control messages. (application) control messages.
6.1.2. Dummy Node 6.1.2. Dummy Node
If an attacker can join a network with any identify, then it can If an attacker can join a network using any identify, then it can
pretend to be a legitimate node, receiving any service legitimate pretend to be a legitimate node, receiving any service legitimate
nodes receive. It may also be able to report false readings (in nodes receive. It may also be able to report false readings (in
metering applications), or provide inappropriate authorizations (in metering applications), or provide inappropriate authorizations (in
control systems involving actuators), or perform any other attacks control systems involving actuators), or perform any other attacks
that are facilitated by being able to direct traffic towards itself. that are facilitated by being able to direct traffic towards itself.
6.1.3. Node Resource Spam 6.1.3. Node Resource Spam
If an attacker can join a network with any identify, then it can If an attacker can join a network with any identify, then it can
continously do so with new (random) identities. This act may drain continously do so with new (random) identities. This act may drain
down the resources of the network (battery, ram, bandwidth). This down the resources of the network (battery, RAM, bandwidth). This
may cause legitimate nodes of the network to be unable to may cause legitimate nodes of the network to be unable to
communicate. communicate.
6.2. Threats and Attacks on Confidentiality 6.2. Threats and Attacks on Confidentiality
The assessment in Section 4.2 indicates that there are attacks The assessment in Section 4.2 indicates that there are attacks
against the confidentiality of routing information at all points of against the confidentiality of routing information at all points of
access. This threat results in disclosure, as described in access. This threat may result in disclosure, as described in
Section 3.1.2 of [RFC4593], and may involve a disclosure of routing Section 3.1.2 of [RFC4593], and may involve a disclosure of routing
information. information.
6.2.1. Routing Exchange Exposure 6.2.1. Routing Exchange Exposure
Routing exchanges include both routing information as well as Routing exchanges include both routing information as well as
information associated with the establishment and maintenance of information associated with the establishment and maintenance of
neighbor state information. As indicated in Section 4.1, the neighbor state information. As indicated in Section 4.1, the
associated routing information assets may also include device associated routing information assets may also include device
specific resource information, such as available memory, remaining specific resource information, such as available memory, remaining
skipping to change at page 21, line 22 skipping to change at page 20, line 41
A passive wiretap attack seeks to breach routing confidentiality A passive wiretap attack seeks to breach routing confidentiality
through passive, direct analysis and processing of the information through passive, direct analysis and processing of the information
exchanges between nodes. exchanges between nodes.
Passive wiretap attacks can be directly countered through the use of Passive wiretap attacks can be directly countered through the use of
data encryption for all routing exchanges. Only when a validated and data encryption for all routing exchanges. Only when a validated and
authenticated node association is completed will routing exchange be authenticated node association is completed will routing exchange be
allowed to proceed using established session keys and an agreed allowed to proceed using established session keys and an agreed
encryption algorithm. The mandatory to implement CCM mode AES-128 encryption algorithm. The mandatory to implement CCM mode AES-128
method, is described in [RFC3610], and is believed to be secure method, is described in [RFC3610], and is believed to be secure
against a brute force attack by even the most well-equiped adversary. against a brute force attack by even the most well-equipped
adversary.
The significant challenge for RPL is in the provisioning of the key, The significant challenge for RPL is in the provisioning of the key,
which in some modes of RFC6550 is used network-wide. RFC6550 does which in some modes of RFC6550 is used network-wide. RFC6550 does
not solve this problem, and it is the subject of significant future not solve this problem, and it is the subject of significant future
work: see, for instance: [AceCharterProposal], [SolaceProposal], work: see, for instance: [AceCharterProposal], [SolaceProposal],
[SmartObjectSecurityWorkshop]. [SmartObjectSecurityWorkshop].
A number of deployments, such as [ZigBeeIP] specify no layer-3/RPL A number of deployments, such as [ZigBeeIP] specify no layer-3/RPL
encryption or authentication and rely upon similiar security at encryption or authentication and rely upon similiar security at
layer-2. These networks are immune to outside wiretapping attacks, layer-2. These networks are immune to outside wiretapping attacks,
but are particularly vulnerable to passive (and active) attacks but are vulnerable to passive (and active) routing attacks through
through compromises of nodes. compromises of nodes. (see Section 8.2).
Section 10.9 of [RFC6550] specifies AES-128 in CCM mode with a 32-bit Section 10.9 of [RFC6550] specifies AES-128 in CCM mode with a 32-bit
MAC. MAC.
Section 5.6 Zigbee IP [ZigBeeIP] specifies use of CCM, with PANA and Section 5.6 Zigbee IP [ZigBeeIP] specifies use of CCM, with PANA and
EAP-TLS for key management. EAP-TLS for key management.
7.1.3. Countering Traffic Analysis 7.1.3. Countering Traffic Analysis
Traffic analysis provides an indirect means of subverting Traffic analysis provides an indirect means of subverting
skipping to change at page 31, line 4 skipping to change at page 29, line 39
be difficult to call an attack. The worst thing that a benign be difficult to call an attack. The worst thing that a benign
wormhole can do in such a situation is to cease to operate (become wormhole can do in such a situation is to cease to operate (become
unstable), causing the network to have to recalculate routes. unstable), causing the network to have to recalculate routes.
A highly unstable wormhole is no different than a radio opaque (i.e. A highly unstable wormhole is no different than a radio opaque (i.e.
metal) door that opens and closes a lot. RPL includes hysteresis in metal) door that opens and closes a lot. RPL includes hysteresis in
its objective functions [RFC6719] in an attempt to deal with frequent its objective functions [RFC6719] in an attempt to deal with frequent
changes to the ETX between nodes. changes to the ETX between nodes.
8. RPL Security Features 8. RPL Security Features
The assessments and analysis in Section 6 examined all areas of The assessments and analysis in Section 6 examined all areas of
threats and attacks that could impact routing, and the threats and attacks that could impact routing, and the
countermeasures presented in Section 7 were reached without confining countermeasures presented in Section 7 were reached without confining
the consideration to means only available to routing. This section the consideration to means only available to routing. This section
puts the results into perspective; dealing with those threats which puts the results into perspective; dealing with those threats which
are endemnic to this field, those which have been mitigated through are endemic to this field, those which have been mitigated through
RPL protocol design, and those which require specific decisions to be RPL protocol design, and those which require specific decisions to be
made as part of provisioning a network. made as part of provisioning a network.
The first part of this section, Section 8.1 to Section 8.3, is a The first part of this section, Section 8.1 to Section 8.3, is a
description of RPL security features that address specific threats. description of RPL security features that address specific threats.
The second part of this section, Section 8.4, discusses issues of The second part of this section, Section 8.4, discusses issues of
provisioning of security aspects that may impact routing but that provisioning of security aspects that may impact routing but that
also require considerations beyond the routing protocol, as well as also require considerations beyond the routing protocol, as well as
potential approaches. potential approaches.
skipping to change at page 32, line 44 skipping to change at page 31, line 29
entire deployment is under the control of a single administrative entire deployment is under the control of a single administrative
entity. entity.
Other layer-2 security mechanisms form a unique session key for every Other layer-2 security mechanisms form a unique session key for every
pair of nodes that needs to communicate; this is often called a per- pair of nodes that needs to communicate; this is often called a per-
link key. Such networks can provide a strong degree of origin link key. Such networks can provide a strong degree of origin
authentication and integrity on unicast messages. authentication and integrity on unicast messages.
However, some RPL messages are broadcast, and even when per-node However, some RPL messages are broadcast, and even when per-node
layer-2 security mechanisms are used, the integrity and origin layer-2 security mechanisms are used, the integrity and origin
authentication of broadcast messages can not be as securely known. authentication of broadcast messages can not be as trusted due to the
proliferation of the key used to secure them.
RPL has two specific messages which are broadcast: the DODAG RPL has two specific options which are broadcast in RPL Control
Information Object (DIO), and the DODAG Information Solicitation Messages: the DODAG Information Object (DIO), and the DODAG
(DIS). The purpose of the DIS is to cause potential parents to reply Information Solicitation (DIS). The purpose of the DIS is to cause
with a DIO, so the integrity of the DIS is not of great concern. The potential parents to reply with a DIO, so the integrity of the DIS is
DIS may also be unicast. not of great concern. The DIS may also be unicast.
The DIO is a critical piece of routing and carries many critical The DIO is a critical piece of routing and carries many critical
parameters. RPL provides for assymetric authentication at layer-3 of parameters. RPL provides for asymmetric authentication at layer 3 of
the DIO, and this may be waranteed in some deployments. A node the RPL Control Message carrying the DIO and this may be warranted in
could, if it felt that the DIO that it had received was suspicious, some deployments. A node could, if it felt that the DIO that it had
send a unicast DIS message to the node in question, and that node received was suspicious, send a unicast DIS message to the node in
would reply with a unicast DIS. Those messages could be protected question, and that node would reply with a unicast DIS. Those
with the per-link key. messages could be protected with the per-link key.
8.3. Availability Features 8.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. Where view beyond the requirements of the routing entities. Where
availability of the network is compromised, routing information availability of the network is compromised, routing information
availability will be accordingly affected. However, to specifically availability will be accordingly affected. However, to specifically
assist in protecting routing availability: assist in protecting routing availability, nodes:
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;
skipping to change at page 34, line 28 skipping to change at page 33, line 14
acknowledge the guidance and input provided by the RPL Chairs, David acknowledge the guidance and input provided by the RPL Chairs, David
Culler, and JP Vasseur, and the Area Director Adrian Farrel. Culler, and JP Vasseur, and the Area Director Adrian Farrel.
This document started out as a combined threat and solutions This document started out as a combined threat and solutions
document. As a result of security review, the document was split up document. As a result of security review, the document was split up
by RPL co-Chair Michael Richardson and security Area Director Sean by RPL co-Chair Michael Richardson and security Area Director Sean
Turner as it went through the IETF publication process. The Turner as it went through the IETF publication process. The
solutions to the threats are application and layer-2 specific, and solutions to the threats are application and layer-2 specific, and
have therefore been moved to the relevant applicability statements. have therefore been moved to the relevant applicability statements.
Ines Robles and Robert Craigie kept track of the many issues that Ines Robles and Robert Cragie kept track of the many issues that were
were raised during the development of this document raised during the development of this document
12. References 12. References
12.1. Normative References 12.1. Normative References
[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-04 (work in Networks", draft-ietf-roll-terminology-04 (work in
progress), September 2010. progress), September 2010.
skipping to change at page 40, line 4 skipping to change at page 38, line 35
Email: mischa.dohler@cttc.es Email: mischa.dohler@cttc.es
Vanesa Daza Vanesa Daza
Universitat Pompeu Fabra Universitat Pompeu Fabra
P/ Circumval.lacio 8, Oficina 308 P/ Circumval.lacio 8, Oficina 308
Barcelona 08003 Barcelona 08003
Spain Spain
Email: vanesa.daza@upf.edu Email: vanesa.daza@upf.edu
Angel Lozano Angel Lozano
Universitat Pompeu Fabra Universitat Pompeu Fabra
P/ Circumval.lacio 8, Oficina 309 P/ Circumval.lacio 8, Oficina 309
Barcelona 08003 Barcelona 08003
Spain Spain
Email: angel.lozano@upf.edu Email: angel.lozano@upf.edu
Michael Richardson (ed) (editor)
Michael Richardson (ed)
Sandelman Software Works Sandelman Software Works
470 Dawson Avenue 470 Dawson Avenue
Ottawa, ON K1Z5V7 Ottawa, ON K1Z5V7
Canada Canada
Email: mcr+ietf@sandelman.ca Email: mcr+ietf@sandelman.ca
 End of changes. 30 change blocks. 
63 lines changed or deleted 63 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/