RFC 7416

A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)

📅 published January 2015, from ietf
Part 1 of 8 🎀 more parts coming, bestie, so don't go anywhere yet 💅

A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs) 🦋

RFC 7416 is an Informational document from the IETF, published in January 2015 and tagged with ISSN 2070-1721. The authors are T. Tsao and R. Alexander (both at Eaton's Cooper Power Systems Business), M. Dohler and V. Daza and A. Lozano (CTTC and Universitat Pompeu Fabra), and M. Richardson, who is the editor, from Sandelman Software Works 👑. The title block doesn't list anything this document obsoletes or updates, so it doesn't claim either one 🌸

Abstract

This document is a security threat analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs) 🔥. It builds on earlier routing security work and then adapts all of that to the particular issues and limits of low-power and lossy networks 🧚. The threats are defined and evaluated using a systematic approach. The countermeasures depend on the application, so they get covered in the relevant applicability statements 💜

Status of This Memo

Okay so this one is not an Internet Standards Track spec. It's published purely for informational purposes ✨

It's a product of the IETF, it represents consensus from the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🎀 Not every IESG-approved document is in the running for any level of Internet Standard, though. Check Section 2 of RFC 5741 if you want the details 🧐

For the current status, any errata, and how to send feedback, the place to look is http://www.rfc-editor.org/info/rfc7416 🌈

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved 💖

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please actually read these, because they lay out your rights and restrictions for this document 🙈 Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Simplified BSD License ⭐

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Relationship to Other Documents . . . . . . . . . . . . . . .   4
3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
4.  Considerations on RPL Security  . . . . . . . . . . . . . . .   5
  4.1.  Routing Assets and Points of Access . . . . . . . . . . .   6
  4.2.  The ISO 7498-2 Security Reference Model . . . . . . . . .   8
  4.3.  Issues Specific to or Amplified in LLNs . . . . . . . . .  10
  4.4.  RPL Security Objectives . . . . . . . . . . . . . . . . .  12
5.  Threat Sources  . . . . . . . . . . . . . . . . . . . . . . .  13
6.  Threats and Attacks . . . . . . . . . . . . . . . . . . . . .  13
  6.1.  Threats Due to Failures to Authenticate . . . . . . . . .  14
    6.1.1.  Node Impersonation  . . . . . . . . . . . . . . . . .  14
    6.1.2.  Dummy Node  . . . . . . . . . . . . . . . . . . . . .  14
    6.1.3.  Node Resource Spam  . . . . . . . . . . . . . . . . .  15
  6.2.  Threats Due to Failure to Keep Routing Information
        Confidential  . . . . . . . . . . . . . . . . . . . . . .  15
    6.2.1.  Routing Exchange Exposure . . . . . . . . . . . . . .  15
    6.2.2.  Routing Information (Routes and Network Topology)
            Exposure  . . . . . . . . . . . . . . . . . . . . . .  15
  6.3.  Threats and Attacks on Integrity  . . . . . . . . . . . .  16
    6.3.1.  Routing Information Manipulation  . . . . . . . . . .  16
    6.3.2.  Node Identity Misappropriation  . . . . . . . . . . .  17
  6.4.  Threats and Attacks on Availability . . . . . . . . . . .  18
    6.4.1.  Routing Exchange Interference or Disruption . . . . .  18
    6.4.2.  Network Traffic Forwarding Disruption . . . . . . . .  18
    6.4.3.  Communications Resource Disruption  . . . . . . . . .  20
    6.4.4.  Node Resource Exhaustion  . . . . . . . . . . . . . .  20

7.  Countermeasures . . . . . . . . . . . . . . . . . . . . . . .  21
  7.1.  Confidentiality Attack Countermeasures  . . . . . . . . .  21
    7.1.1.  Countering Deliberate Exposure Attacks  . . . . . . .  21
    7.1.2.  Countering Passive Wiretapping Attacks  . . . . . . .  22
    7.1.3.  Countering Traffic Analysis . . . . . . . . . . . . .  22
    7.1.4.  Countering Remote Device Access Attacks . . . . . . .  23
  7.2.  Integrity Attack Countermeasures  . . . . . . . . . . . .  24
    7.2.1.  Countering Unauthorized Modification Attacks  . . . .  24
    7.2.2.  Countering Overclaiming and Misclaiming Attacks . . .  24
    7.2.3.  Countering Identity (including Sybil) Attacks . . . .  25
    7.2.4.  Countering Routing Information Replay Attacks . . . .  25
    7.2.5.  Countering Byzantine Routing Information Attacks  . .  26
  7.3.  Availability Attack Countermeasures . . . . . . . . . . .  26
    7.3.1.  Countering HELLO Flood Attacks and ACK Spoofing
            Attacks . . . . . . . . . . . . . . . . . . . . . . .  27
    7.3.2.  Countering Overload Attacks . . . . . . . . . . . . .  27
    7.3.3.  Countering Selective Forwarding Attacks . . . . . . .  29
    7.3.4.  Countering Sinkhole Attacks . . . . . . . . . . . . .  29
    7.3.5.  Countering Wormhole Attacks . . . . . . . . . . . . .  30
8.  RPL Security Features . . . . . . . . . . . . . . . . . . . .  31
  8.1.  Confidentiality Features  . . . . . . . . . . . . . . . .  32
  8.2.  Integrity Features  . . . . . . . . . . . . . . . . . . .  32
  8.3.  Availability Features . . . . . . . . . . . . . . . . . .  33
  8.4.  Key Management  . . . . . . . . . . . . . . . . . . . . .  34
9.  Security Considerations . . . . . . . . . . . . . . . . . . .  34
10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  34
  10.1.  Normative References . . . . . . . . . . . . . . . . . .  34
  10.2.  Informative References . . . . . . . . . . . . . . . . .  35
Acknowledgments  . . . . . .  . . . . . . . . . . . . . . . . . .  39
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  40

1. Introduction ✨

Lately, networked electronic devices are showing up everywhere 🌸 But these wired and wireless devices usually run on very little hardware, and that's for practical reasons and for money reasons too 💅 The limits include computing stuff (RAM, clock speed, and storage) and communication stuff (duty cycle, packet size, etc.). Some devices also have form factors that rule out a user-access interface, like the housing of a small stick-on switch. Others have safety concerns, like gas meters. So these networks end up more prone to losing traffic and to other vulnerabilities 😭 Low-Power and Lossy Networks (LLNs) are multiplying, and people are working hard on their networking challenges. Securing how these deployed devices set up and keep their network connectivity is one of the big key challenges 🔥

This document is a threat analysis for securing the Routing Protocol for LLNs (RPL) 🦋 It has two steps. First, the analysis identifies the security issues that matter. Second, it figures out which countermeasures are needed to secure RPL. There are many ways to solve this, and the trade-offs depend on the deployment, so the specific countermeasure to use gets spelled out in the applicability statements 🎀

This document uses a model based on [ISO.7498-2.1989]. That model covers authentication, access control, data confidentiality, data integrity, and non-repudiation as security services 🧚 This document extends the model to include availability. As explained below, non-repudiation doesn't apply to routing protocols 🙈

A lot of the issues in this document were also covered in the IAB Smart Object Workshop [RFC6574] and the IAB Smart Object Security Workshop [RFC7397] 🌈

This document is about securing control-plane traffic. So it doesn't deal with authorization or authentication of application traffic 💜 RPL uses multicast as part of its protocol. That means the mechanisms RPL uses to secure this traffic might also apply to the Multicast Protocol for Low-Power and Lossy Networks (MPL) control traffic. The important part is that the threats are similar 🫶

2. Relationship to Other Documents 🍓

Routing Over Low-Power and Lossy (ROLL) networks specified a set of routing protocols for LLNs [RFC6550] 👑 A bunch of applicability texts describe a subset of these protocols and the conditions that make that subset the right pick. The text recommends and motivates the matching parameter value ranges. Several applicability domains are recognized, including Building and Home and Advanced Metering Infrastructure 💖 The domains are different in how they're operated, in their performance requirements, and in the network structures they're most likely to have. Each applicability statement identifies its distinguishing properties using a common set of subjects, described in as many sections 🌸

The common set of security threats in this document is referred to by the applicability statements. Those documents describe the preferred security settings and solutions that fit within each applicability statement's conditions ✨ This applicability statement may recommend more lightweight security solutions, and it specifies the conditions under which those solutions are appropriate 🧚

3. Terminology 💅

This document adopts the terminology defined in [RFC6550], [RFC4949], and [RFC7102] 📚

The terms "control plane" and "forwarding plane" are used the same way they're used in Section 1 of [RFC6192] 🦋

The term "Destination-Oriented DAG (DODAG)" comes from [RFC6550] 🌈

Extensible Authentication Protocol - Transport Layer Security (EAP-TLS) is defined in [RFC5216] 🎀

The Protocol for Carrying Authentication for Network Access (PANA) is defined in [RFC5191] 💜

Counter with CBC-MAC (CCM) mode is defined in [RFC3610] ⭐

The term "sleepy node", introduced in [RFC7102], refers to a node that may sometimes go into a low-power state and suspend its protocol communications 😴

The terms Service Set Identifier (SSID), Extended Service Set Identifier (ESSID), and Personal Area Network (PAN) refer to network identifiers, which are defined in [IEEE.802.11] and [IEEE.802.15.4] 🍓

Okay, this isn't a protocol specification, but the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document get read the way [RFC2119] describes. The whole point is to make the guidance and directions for implementers and deployers of LLN nodes that use RPL clear and emphatic 🫶💅

4. Considerations on RPL Security ✨

okay so routing security is basically about making sure the routing protocol keeps doing its job correctly 💅 it means putting measures in place so that state changes on devices and network elements only happen in controlled ways 🫶 those changes can be triggered by outside inputs (stuff that arrives through communications) or inside inputs (the device's own physical security and the parameters it keeps track of, like its clock) ⏰ so state changes aren't just about authorizing whoever is doing the injecting 🙈 you also need to authenticate the injectors, maybe keep routing data confidential, and make sure changes happen in the right order by being timely. seriously delayed changes, like commands or routing table updates, can mess up the whole system 💀 so a security assessment can start by looking at the assets [RFC4949] that might be targeted by state changes, plus the access points (interfaces and protocol exchanges) those changes could come through 🎀 for routing security, the spotlight is on the stuff that sets up and maintains network connectivity 🌸

this section sets the stage for the analysis by using the systematic approach from [Myagmar2005] on routing security 🦋 it also borrows ideas from other reviews, especially [RFC4593] and [Karlof2003] (that's selective forwarding, wormhole, and sinkhole attacks, iykyk) 🧚 next up, we look at the parts of a generic routing process that set up routing assets and access points to the routing functionality 👑 then we briefly describe the security model based on [ISO.7498-2.1989] 💜 after that, we look at issues that are specific to LLNs or that get amplified in LLNs 🌈 and this section wraps up by forming a set of security objectives for RPL ⭐

4.1. Routing Assets and Points of Access 🍓

okay so an asset is an important system resource (that could be information, a process, or a physical resource) 💖 if you access it, corrupt it, or lose it, the system takes a hit 💀 in the control-plane context, assets are info about the network, the processes used to manage and manipulate that data, and the physical devices where the data gets stored and manipulated 🔥 losing or corrupting these can seriously mess up the network's control plane 😭 a point of access, in the same context, is an interface or protocol that lets control-plane assets interact with each other 🫶 identifying both gives you a basis for listing the attack surface of the control plane, which is literally the whole point 🎀

we use a level-0 data flow diagram [Yourdon1979] to find the assets and points of access in a generic routing process ✨ data flow diagrams give you a clean, concise model of how routing nodes talk to each other and process info, so they give context for threats and attacks 🌈 the goal is to be as detailed as possible, so the assets, points of access, and processes in any individual routing protocol can be easily spotted 👑

Figure 1 shows that nodes in the routing process send messages to discover neighbors and swap routing info 🦋 routes then get generated and stored, possibly kept as the protocol's forwarding table 💅 nodes use those derived routes to make forwarding decisions 💖

                ...................................................
                :                                                 :
                :                                                 :
    |Node_i|<------->(Routing Neighbor       _________________    :
                :     Discovery)------------>Neighbor Topology    :
                :                            -------+---------    :
                :                                   |             :
    |Node_j|<------->(Route/Topology       +--------+             :
                :     Exchange)            |                      :
                :           |              V            ______    :
                :           +---->(Route Generation)--->Routes    :
                :                                       ---+--    :
                :                                          |      :
                : Routing on Node_k                        |      :
                ...................................................
                                                           |
    |Forwarding                                            |
    |on Node_l|<-------------------------------------------+

Notation:

(Proc)     A process Proc

________
topology   A structure storing neighbor adjacency (parent/child)
--------
________
 routes    A structure storing the forwarding information base (FIB)
--------

|Node_n|   An external entity Node_n

------->   Data flow

Figure 1: Data Flow Diagram of a Generic Routing Process

Figure 1 shows the following: 🧚

  • Assets include:
    • routing and/or topology information 💜
    • route generation process 🌸
    • communication channel resources (bandwidth) 💅
    • node resources (computing capacity, memory, and remaining energy) 🔋
    • node identifiers (including node identity and ascribed attributes such as relative or absolute node location) 🎀
  • Points of access include:
    • neighbor discovery 🦋
    • route/topology exchange 🫶
    • node physical interfaces (including access to data storage) 💖

okay so focusing on that list of assets and points of access makes the security assessment way more targeted 🔥 like, it's super clear that some routing attacks are just attempts to misrepresent the routing topology 👀 the threat analysis is meant to be comprehensive though, so some of what follows is about assets and access points that aren't directly about routing protocol design 💅 they're still included for reference because they DO have direct consequences for routing security 🙈

4.2. The ISO 7498-2 Security Reference Model 💜

at the conceptual level, security in an information system in general (and for RPL in particular) is all about authentication, access control, data confidentiality, data integrity, and non-repudiation 🌈 here's how those apply to RPL:

Authentication 🔐 : okay so authentication means mutual authentication of routing peers before they swap route info (that's peer authentication), plus making sure route data really comes from the peer (that's data origin authentication) 💖 LLNs can get drained by unauthenticated peers before configuration, per [RFC5548] 😭 open and untrusted side channels for new joiners are required by [RFC5673] 🫶 and strong, automated authentication is required so networks can automatically accept or reject new joiners 👑

Access Control 🚪 : access control protects against unauthorized use of the asset, and it deals with authorizing a node 🎀

Confidentiality 🤫 : confidentiality is about protecting routing info and routing neighbor maintenance exchanges so only authorized and intended network entities can view or access them 🌸 LLNs are most commonly on a publicly accessible shared medium (think air or wiring in a building) and are sometimes formed ad hoc 😳 so confidentiality also covers the neighbor state and database info inside the routing device, since deploying the network opens up the chance of unauthorized access to the physical devices themselves 🔥

Integrity 🧱 : integrity means protecting routing info, routing neighbor maintenance exchanges, and derived info kept in the database from unauthorized modifications, insertions, deletions, or replays, to be addressed beyond the routing protocol 🦋

Non-repudiation 📜 : non-repudiation is the assurance that sending or receiving a message can't be denied later 🧚 this service applies after the fact, so it relies on logging or otherwise capturing ongoing message exchanges and signatures 💜 routing protocols typically don't have a notion of repudiation, so non-repudiation services are not required 🙈 plus, with the LLN application domains described in [RFC5867] and [RFC5548], proactive measures matter way more than retrospective protections 💅 and given the big practical limits on ongoing routing transaction logging and storage and on individual device digital signature verification for each exchange, non-repudiation for routing is an unsupportable burden 💀 so it bears no further consideration as an RPL security issue 🫶

it's also recognized that, besides the security issues in the ISO 7498-2 model, availability is a security requirement 🌈

Availability ⏱️ : availability makes sure routing info exchanges and forwarding services are available when the serving network needs them 👑 it applies to keeping routing and neighbor discovery exchanges (including needed info) and forwarding services running efficiently and correctly, so the network's central traffic flow function isn't impaired or limited 🎀

and just to be clear, for RPL security, the requirements above must be complemented by proper security policies and enforcement mechanisms so that a given RPL implementation actually meets its security objectives ✨💖

4.3. Issues Specific to or Amplified in LLNs

okay so bestie, the requirements work in Urban Requirements [RFC5548], Industrial Requirements [RFC5673], Home Automation [RFC5826], and Building Automation [RFC5867] already flagged a bunch of specific issues and constraints for routing in LLNs 💅🎀 Here's a list of what they noticed, plus how each one hits routing security ✨

Limited energy, memory, and processing node resources ok so these constraints mean we really need to study which kinds of security are doable 🥺 security at one level could be super memory efficient but literally drain the whole network's energy if it takes a ton of work to keep the security state in sync. Syncing security states with sleepy nodes [RFC7102] is a whole complex mess 😭 A non-rechargeable battery-powered node may be low on energy for its entire lifetime: once that's gone, it may well never work again 💀

Large scale of rolled out network the nodes that get deployed could be super numerous, so manual on-site configuration is unlikely 🙈 like, an urban deployment can have several hundreds of thousands of nodes installed by lots of installers with not much expertise. Nodes might get installed and not turned on for years, and more nodes can be added later, maybe from old inventory 🍓 The network lifetime is measured in decades, and that makes key management way harder 🔑

Autonomous operations self-forming and self-organizing are commonly required for LLNs, so no cap, a routing protocol for LLNs needs ad hoc networking elements and, in most cases, can't rely on manual configuration for setup or local filtering rules 🧚 Topology or ownership changes, partitioning or merging, and node replacement can all make key management even messier 💅

Highly directional traffic some LLNs send a high percentage of their traffic between the nodes and the LLN Border Routers (LBRs), where the LLN connects to non-LLNs 👑 The special routing status of LBRs and the bigger traffic volume near them make them a higher-valued attack target 🎯 When Point-to-MultiPoint (P2MP) and MultiPoint-to-Point (MP2P) traffic is the majority, routing attacks that advertise incorrect preferred routes can do serious damage 😭

it might seem like nodes higher up in the acyclic graph (the ones with lower rank) should get stronger security, right? but it's not easy to predict which nodes will end up in those spots until after deployment 🤷‍♀️ Because of redundancy and inventory control, any node might wind up in a sensitive attack position, so all nodes are to be capable of being fully secured 🛡️✨

and even if you could predict which nodes will be in lower-rank positions and give them stronger security, without a strong authorization model, any node could advertise an incorrect preferred route 🫠

Unattended locations and limited physical security in lots of applications, nodes are deployed in unattended or remote spots, and the nodes themselves often have minimal physical protection 🌲 These things make it way easier to get at the data or security material stored on the nodes through physical means 🔓

Support for mobility only a limited number of applications need mobile nodes, like a home LLN with nodes on wearable health care devices, or an industry LLN with nodes on cranes and vehicles 🚜 But if a routing protocol is used in those apps, it will clearly need matching security mechanisms 🔐

also, nodes can seem to move from one side of a wall to the other with no actual motion, because of changes to electromagnetic properties, like a metal door opening and closing 🚪⚡

Support for multicast and anycast multicast and anycast are mainly called out for large-scale networks 🌈 Since using these routing mechanisms in autonomous operations of many nodes is new, the security consequences need careful thought 🧐

The list above looks at how an LLN's physical constraints, size, operations, and variety of application areas can affect security 🦋 But it's really the combination of these factors that stresses the security concerns 😩 For example, securing routing for a huge number of autonomous devices left in unattended spots with limited physical security is a challenge you don't see with the usual administered networked routers 💜 The next subsection sets up the security objectives for the routing protocol the ROLL WG designed 🎀

4.4. RPL Security Objectives

this subsection applies the ISO 7498-2 model to routing assets and access points, keeping the LLN issues in mind, to build a set of RPL security objectives 🌸

Since the fundamental job of a routing protocol is building routes for forwarding packets, it's essential to make sure that:

  • routing/topology information integrity stays intact during transfer and in storage;
  • routing/topology information is used by authorized entities; and
  • routing/topology information is available when it's needed.

In addition, it's necessary to be assured that:

  • Authorized peers authenticate themselves during the routing neighbor discovery process.
  • The routing/topology information received is generated according to the protocol design.

However, when trust can't be fully vested through authentication of the principals alone (aka concerns of an insider attack), assurance of the truthfulness and timeliness of the received routing/topology information is necessary 🕵️‍♀️ As for confidentiality, protecting the routing/topology information from unauthorized exposure may be desirable in certain cases, but it's in itself less pertinent to the routing function in general 🤍

One of the main problems with synchronizing security states of sleepy nodes, as listed in the last subsection, is difficulty with authentication 😵 these nodes may not have received the latest update of security material in time ⏰ Similarly, minimal manual configuration, prolonged rollout and delayed addition of nodes, and network topology changes also complicate key management 🔑 So routing in LLNs needs to bootstrap the authentication process and allow a flexible expiration scheme for authentication credentials 🦋

The vulnerability brought on by some special-function nodes, e.g., LBRs, requires assurance, especially in a security context, of the following:

  • The availability of communication channels and node resources.
  • The neighbor discovery process operates without undermining routing availability.

There are other factors that aren't part of RPL but directly affect its function 🙃 These include a weaker barrier to getting at the data or security material stored on the nodes through physical means, so the internal and external interfaces of a node need to be adequate for guarding the integrity, and possibly the confidentiality, of stored information, as well as the integrity of routing and route generation processes 🛡️

Each individual system's use and environment will dictate how the above objectives get applied, including the choices of security services and the strengths of the mechanisms that must be implemented 💖 The next two sections take a closer look at how the RPL security objectives may be compromised and how those potential compromises can be countered 👀

5. Threat Sources

[RFC4593] provides a detailed review of the threat sources: outsiders and Byzantine. RPL has the same threat sources 🎭

6. Threats and Attacks

this section outlines general categories of threats under the ISO 7498-2 model and highlights the specific attacks in each category for RPL 🔍 As defined in [RFC4949], a threat is "a potential for violation of security, which exists when there is a circumstance, capability, action, or event that could breach security and cause harm." Per [RFC3067], an attack is "an assault on system security that derives from an intelligent threat, i.e., an intelligent act that is a deliberate attempt (especially in the sense of a method or technique) to evade security services and violate the security policy of a system." 😤

The subsequent subsections look at the threats and attacks that can cause security breaches under the ISO 7498-2 model to the routing assets and via the routing points of access identified in Section 4.1 📋 The assessment reviews the security concerns of each routing asset and looks at attacks that can exploit routing points of access. The threats and attacks identified are based on the routing model analysis and the review of existing literature 📚 The source of the attacks is assumed to be either inside or outside attackers. Some inside attackers will be using compromised nodes, so they're only able to do what an ordinary node can ("node-equivalent"), but other attacks may not be limited in memory, CPU, power consumption, or long-term storage 🔋 Moore's law favors the attacker with access to the latest capabilities, while defenders stay in place for years to decades 📈💀

6.1. Threats Due to Failures to Authenticate

6.1.1. Node Impersonation

if an attacker can join a network using any identity, it may be able to assume the role of a legitimate (and existing) node 🎭 It may be able to report false readings (in metering applications) or provide inappropriate control messages (in control systems involving actuators) if the security of the application is implied by the security of the routing system 😱

Even in systems with application-layer security, the ability to impersonate a node would let an attacker direct traffic to itself 🪤 This may permit various on-path attacks that would otherwise be difficult, such as replaying, delaying, or duplicating (application) control messages 🌀

6.1.2. Dummy Node

if an attacker can join a network using any identify, it can pretend to be a legitimate node and receive any service legitimate nodes receive 🫣 It may also be able to report false readings (in metering applications), provide inappropriate authorizations (in control systems involving actuators), or perform any other attacks that are facilitated by being able to direct traffic toward itself 💅✨

6.1.3. Node Resource Spam 🧚

okay so if an attacker can join a network with any identity, they can just keep doing it with new (random) identities 😭 and that act may drain down the resources of the network (battery, RAM, bandwidth) 🔋. that could leave legitimate nodes unable to communicate at all 💀

6.2. Threats Due to Failure to Keep Routing Information Confidential 🔐

the assessment in Section 4.2 shows there are attacks against the confidentiality of routing information at all points of access 👀. this threat may result in disclosure, as described in Section 3.1.2 of [RFC4593], and it may involve a disclosure of routing information 💜

6.2.1. Routing Exchange Exposure 💌

routing exchanges include both routing information and info tied to setting up and maintaining neighbor state 🤝. as Section 4.1 points out, the routing information assets may also include device-specific resource info, like available memory, remaining power, etc., which can be metrics of the routing protocol 🔋

the routing exchanges will contain reachability info, which tells you how important each node is in the network 📈. nodes higher up in the DODAG, where more streams of information flow, are way more interesting targets for other attacks, and routing exchange exposures could literally identify them 🎯

6.2.2. Routing Information (Routes and Network Topology) Exposure 🗺️

routes (which may be kept in the form of the protocol forwarding table) and neighbor topology info are the products of the routing process, and they get stored within the node device databases 🗄️

exposing this info lets attackers get direct access to the configuration and connectivity of the network, so routing becomes open to targeted attacks on key nodes or links 🎯. since routes and neighbor topology info live inside the node device, attacks on confidentiality apply to the physical device itself, including specified and unspecified internal and external interfaces 🔌

the forms of attack that allow unauthorized access or disclosure of routing info include:

  • Physical device compromise.
  • Remote device access attacks (including those occurring through remote network management or software/field upgrade interfaces).

both of these attack vectors are considered a device-specific issue and are out of scope for RPL to defend against 🙅‍♀️. in some applications, physical device compromise may be a real threat, and it may be necessary to provide for other devices to securely detect a compromised device and react quickly to exclude it 🚨

6.3. Threats and Attacks on Integrity 🛡️

the assessment in Section 4.2 shows that information and identity assets are exposed to integrity threats from all points of access 😤. in other words, the integrity threat space is defined by the potential for exploitation introduced by access to assets available through routing exchanges and the on-device storage 💅

6.3.1. Routing Information Manipulation 🫣

manipulating routing info, from neighbor states all the way to derived routes, lets unauthorized sources influence how the routing protocols operate and converge, and ultimately mess with the forwarding decisions made in the network 🙃

manipulating topology and reachability info lets unauthorized sources influence which nodes routing info gets exchanged with and updated from 🕸️. the consequence is that manipulated routing exchanges can lead to suboptimality, and to fragmentation or partitioning of the network, by restricting the universe of routers that associations can be established and maintained with 🧩

a suboptimal network may use too much power and/or may congest some routes, which can lead to premature failure of a node and a denial of service (DoS) on the entire network 🪫

also, being able to attract network traffic can make a black-hole attack way more damaging 🕳️

the forms of attack that let manipulation compromise the content and validity of routing info include:

  • falsification, including overclaiming and misclaiming (claiming routes to devices that the device cannot in fact reach);
  • routing information replay;
  • Byzantine (internal) attacks that permit corruption of routing information in the node even when the node continues to be a validated entity within the network (see, for example, [RFC4593] for further discussions on Byzantine attacks); and
  • physical device compromise or remote device access attacks.

6.3.2. Node Identity Misappropriation 🎭

falsifying or misappropriating node identity between routing participants opens the door for other attacks 🚪. it can also cause incorrect routing relationships to form and/or topologies to emerge 🌀. routing attacks may also be mounted through less-sophisticated node identity misappropriation, where the valid info a node broadcasts or exchanges is replayed without modification 📼

receiving seemingly valid info that is no longer current can cause routing disruption and instability (including failure to converge) 😵‍💫. without measures to authenticate the routing participants and to ensure the freshness and validity of received info, protocol operation can be compromised 🚨. the forms of attack that misuse node identity include:

  • Identity attacks, including Sybil attacks (see [Sybil2002]) in which a malicious node illegitimately assumes multiple identities.
  • Routing information replay.

6.4. Threats and Attacks on Availability 📉

the assessment in Section 4.2 shows that the process and resource assets are exposed to threats against availability 🫠. attacks in this category may exploit, directly or indirectly, information exchange or forwarding (see [RFC4732] for a general discussion) 📡

6.4.1. Routing Exchange Interference or Disruption 📵

interference is the threat action, and disruption is the threat consequence 💥. together they let attackers influence how the routing protocols operate and converge, by impeding the routing information exchange 🧱

the forms of attack that allow interference or disruption of routing exchange include:

  • routing information replay;
  • ACK spoofing; and
  • overload attacks (Section 7.3.2).

attacks may also be run directly at the physical layer, in the form of jamming or interfering 📻

6.4.2. Network Traffic Forwarding Disruption 🚧

disrupting network traffic forwarding undermines the central function of network routers and their ability to handle user traffic 😩. this affects availability of the network, because it can impair the network's primary capability 🙁

besides physical-layer obstructions, the forms of attack that allow disruption of network traffic forwarding include [Karlof2003]:

  • selective forwarding attacks;
        |Node_1|--(msg1|msg2|msg3)-->|Attacker|--(msg1|msg3)-->|Node_2|

                  Figure 2: Selective Forwarding Example
  • wormhole attacks; and
               |Node_1|-------------Unreachable---------x|Node_2|
                  |                                         ^
                  |               Private Link              |
                  '-->|Attacker_1|===========>|Attacker_2|--'

                        Figure 3: Wormhole Attacks
  • sinkhole attacks.
                |Node_1|     |Node_4|
                    |            |
                    `--------.   |
                Falsify as    \  |
                Good Link \   |  |
                to Node_5  \  |  |
                            \ V  V
                |Node_2|-->|Attacker|--Not Forwarded---x|Node_5|
                              ^  ^ \
                              |  |  \ Falsify as
                              |  |   \Good Link
                              /  |    to Node_5
                     ,-------'   |
                     |           |
                |Node_3|     |Node_i|

                     Figure 4: Sinkhole Attack Example

these attacks are generally done to both control-plane and forwarding-plane traffic 🤯. a system that prevents control-plane traffic (RPL messages) from being diverted in these ways will also prevent actual data from being diverted 🙌

6.4.3. Communications Resource Disruption 📶

attacks mounted against the communication channel resource assets that the routing protocol needs can be used to disrupt its operation 😬. however, while various forms of DoS attacks on the underlying transport subsystem will affect routing protocol exchanges and operation (for example, physical-layer Radio Frequency (RF) jamming in a wireless network or link-layer attacks), these attacks cannot be countered by the routing protocol 🫤. so the threats to the underlying transport network that supports routing are considered beyond the scope of the current document 🚫

that said, attacks on the subsystem will affect routing operation and must be directly addressed within the underlying subsystem and its implemented protocol layers 🫶

6.4.4. Node Resource Exhaustion 🪫

a potential threat consequence can come from attempts to overload the node resource asset by starting exchanges that can lead to exhaustion of processing, memory, or energy resources 🥵. establishing and maintaining routing neighbors opens the routing process up to engagement with, and potential acceptance of, multiple neighboring peers 👯. association info must be stored for each peer entity, and for the wireless network operation, provisions are made to periodically update and reassess the associations 🗂️. so a proliferation of apparent routing peers can have a negative impact on node resources 📉

node resources may also be unduly consumed by attackers attempting uncontrolled topology peering or routing exchanges, routing replays, or generating other data-traffic floods 🌊. beyond disrupting communications channel resources, these consequences may only be able to exhaust node resources where the engagements are able to proceed with the peer routing entities 🧐. routing operation and network forwarding functions can thus be adversely impacted by node resource exhaustion stemming from attacks that include:

  • identity (including Sybil) attacks (see [Sybil2002]);
  • routing information replay attacks;
  • HELLO-type flood attacks; and
  • overload attacks (Section 7.3.2).

7. Countermeasures ✨

by recognizing the characteristics of LLNs that may impact routing, this analysis provides the basis for understanding the capabilities within RPL used to deter the identified attacks and mitigate the threats 🧠. the following subsections consider such countermeasures by grouping the attacks according to the classification of the ISO 7498-2 model, so that associations with the necessary security services are more readily visible 🔍

7.1. Confidentiality Attack Countermeasures 🛡️

attacks to disclose routing information may be mounted at the level of the routing information assets, at the points of access associated with routing exchanges between nodes, or through device interface access 🕵️‍♀️. to get access to routing/topology info, the attacker may rely on a compromised node that deliberately exposes the information during the routing exchange process, on passive wiretapping or traffic analysis, or on attempting access through a component or device interface of a tampered routing node 😈

7.1.1. Countering Deliberate Exposure Attacks ✨

Okay so a deliberate exposure attack is when an entity that's already part of the routing process or topology exchange lets the routing/topology information, or the generated route information, leak to an unauthorized entity 👀 not cute at all.

For instance, a misconfigured or inappropriately enabled diagnostic interface could let an entity be copying ("bridging") traffic from a secured ESSID/PAN out to an unsecured interface 🙈

A prerequisite for countering this is making sure the communicating nodes are authenticated before data encryption gets applied in the routing exchange 🔐. That authentication makes sure the LLN starts with trusted nodes 🫶, but it doesn't tell you whether a node has been compromised. Authenticated is not the same as uncompromised, bestie 💀

Reputation systems could help when some nodes sleep for extended periods of time 😴. It's also unclear if the resulting datasets would even fit into constrained devices 🥲

To mitigate the risk of deliberate exposure, the process that communicating nodes use to establish session keys must be peer-to-peer (i.e., between the routing initiating and responding nodes) 💖. As [RFC4107] points out, automatic key management is critical for good security. This helps make sure neither node is exchanging routing information with another peer without the knowledge of both communicating peers 👯. For a deliberate exposure attack to succeed, the comprised node will need to be way more overt and take independent actions in order to disclose the routing information to a third party 😤

Note that the same measures that apply to securing routing/topology exchanges between operational nodes must also extend to field tools and other devices used in a deployed network, where such devices can be configured to participate in routing exchanges 🧰

7.1.2. Countering Passive Wiretapping Attacks 👂

A passive wiretap attack seeks to breach routing confidentiality through passive, direct analysis and processing of the information exchanges between nodes. Very sneaky 🕵️

Passive wiretap attacks can be directly countered by using data encryption for all routing exchanges 🔒. Only when a validated and authenticated node association is completed will the routing exchange be allowed to proceed, using established session keys and an agreed encryption algorithm. The mandatory-to-implement CCM mode AES-128 method, described in [RFC3610], is believed to be secure against a brute-force attack by even the most well-equipped adversary 💪

The significant challenge for RPL is provisioning the key, which in some modes of RFC 6550 is used network wide. This problem is not solved in RFC 6550, and it is the subject of significant future work 📚 see, for instance, [AceCharterProposal], [SolaceProposal], and [SmartObjectSecurityWorkshop]

A number of deployments, such as [ZigBeeIP], specify no Layer 3 (L3) / RPL encryption or authentication and rely upon similar security at Layer 2 (L2). These networks are immune to outside wiretapping attacks but are vulnerable to passive (and active) routing attacks through compromises of nodes (see Section 8.2) 🫠

Section 10.9 of [RFC6550] specifies AES-128 in CCM mode with a 32-bit Message Authentication Code (MAC) 🎀

Section 5.6 of ZigBee IP [ZigBeeIP] specifies use of CCM, with PANA and EAP-TLS for key management 🧚

7.1.3. Countering Traffic Analysis 🕸️

Traffic analysis is an indirect way to subvert confidentiality and get access to routing information. It lets an attacker indirectly map the connectivity or flow patterns (including link load) of the network, and other attacks can be mounted from there 👀. The traffic-analysis attack on an LLN, especially one founded on a shared medium, is passive and relies on the ability to read the immutable source/destination L2 and/or L3 routing information that must remain unencrypted to permit network routing 🙃

One way passive traffic-analysis attacks can be muted is through support of load balancing, which allows traffic to a given destination to be sent along diverse routing paths ⚖️ RPL does not generally support multipath routing within a single DODAG. Multiple DODAGs are supported in the protocol, and an implementation could make use of that. RPL does not have any inherent or standard way to guarantee that the different DODAGs would have significantly diverse paths. Having the diverse DODAGs routed at different border routers might work in some instances, and this could be combined with a multipath technology like Multipath TCP (MPTCP) [RFC6824]. It is unlikely that it will be affordable in many LLNs, as few deployments will have memory space for more than a few sets of DODAG tables 🥺

Another approach to countering passive traffic analysis could be for nodes to maintain a constant amount of traffic to different destinations through the generation of arbitrary traffic flows 🌊. The drawback, of course, would be the consequent overhead and energy expenditure 🔋

The only means of fully countering a traffic-analysis attack is through the use of tunneling (encapsulation), where encryption is applied across the entirety of the original packet source/destination addresses 🛡️ Deployments that use L2 security that includes encryption already do this for all traffic ✅

7.1.4. Countering Remote Device Access Attacks 📡

Where LLN nodes are deployed in the field, measures are introduced to allow for remote retrieval of routing data and for software or field upgrades. These paths create the potential for a device to be remotely accessed across the network or through a provided field tool. In the case of network management, a node can be directly requested to provide routing tables and neighbor information 🗂️

To ensure confidentiality of the node routing information against attacks through remote access, any local or remote device requesting routing information must be authenticated and must be authorized for that access 🔑. Since remote access is not invoked as part of a routing protocol, security of routing information stored on the node against remote access will not be addressable as part of the routing protocol 🙅‍♀️

7.2. Integrity Attack Countermeasures 🛡️

Integrity attack countermeasures address routing information manipulation, as well as node identity and routing information misuse 🧩. Manipulation can occur in the form of a falsification attack and physical compromise. To be effective, the following development considers the two aspects of falsification, namely, the unauthorized modifications and the overclaiming and misclaiming content. The countering of physical compromise was considered in the previous section and is not repeated here. With regard to misuse, there are two types of attacks to be deterred: identity attacks and replay attacks 🚫

7.2.1. Countering Unauthorized Modification Attacks ✍️

Unauthorized modifications may occur in the form of altering the message being transferred or the data stored. Therefore, it is necessary to ensure that only authorized nodes can change the portion of the information that is allowed to be mutable, while the integrity of the rest of the information is protected, e.g., through well-studied cryptographic mechanisms 🔏

Unauthorized modifications may also occur in the form of insertion or deletion of messages during protocol changes. Therefore, the protocol needs to ensure the integrity of the sequence of the exchange sequence 🔢

The countermeasure to unauthorized modifications needs to:

  • implement access control on storage;
  • provide data integrity service to transferred messages and stored data; and
  • include a sequence number under integrity protection.

7.2.2. Countering Overclaiming and Misclaiming Attacks 🎣

Both overclaiming and misclaiming aim to introduce false routes or a false topology that would not occur otherwise, while there are not necessarily unauthorized modifications to the routing messages or information. In order to counter overclaiming, the capability to determine unreasonable routes or topology is required 🧐

The counter to overclaiming and misclaiming may employ:

  • Comparison with historical routing/topology data.
  • Designs that restrict realizable network topologies.

RPL includes no specific mechanisms in the protocol to counter overclaims or misclaims. An implementation could have specific heuristics implemented locally 🧠

7.2.3. Countering Identity (including Sybil) Attacks 🎭

Identity attacks, sometimes simply called spoofing, seek to gain or damage assets whose access is controlled through identity. In routing, an identity attacker can illegitimately participate in routing exchanges, distribute false routing information, or cause an invalid outcome of a routing process 🙅

A perpetrator of Sybil attacks assumes multiple identities. The result is not only an amplification of the damage to routing but also an extension to new areas, e.g., where geographic distribution is explicitly or implicitly an asset to an application running on the LLN, for example, the LBR in a P2MP or MP2P LLN 🌍

RPL includes specific public key-based authentication at L3 that provides for authorization. Many deployments use L2 security that includes admission controls at L2 using mechanisms such as PANA 🔐

7.2.4. Countering Routing Information Replay Attacks 🔁

In many routing protocols, message replay can result in false topology and/or routes. This is often counted with some kind of counter to ensure the freshness of the message. Replay of a current, literal RPL message is, in general, idempotent to the topology. If replayed, an older (lower DODAGVersionNumber) message would be rejected as being stale. If the trickle algorithm further dampens the effect of any such replay, as if the message was current, then it would contain the same information as before, and it would cause no network changes 🙌

Replays may well occur in some radio technologies (though not very likely; see [IEEE.802.15.4]) as a result of echos or reflections, so some replays must be assumed to occur naturally 📶

Note that for there to be no effect at all, the replay must be done with the same apparent power for all nodes receiving the replay. A change in apparent power might change the metrics through changes to the Expected Transmission Count (ETX); therefore, it might affect the routing even though the contents of the packet were never changed. Any replay that appears to be different should be analyzed as a selective forwarding attack, sinkhole attack, or wormhole attack 🕳️💅

7.2.5. Countering Byzantine Routing Information Attacks 🕵️‍♀️

okay so picture this: a node gets captured or compromised, but it keeps running for a while with valid network security credentials 😭. that means it can start messing with routing information, and that can happen even if you've got security countermeasures working between the peer routing devices. the chaos is real 💀

bestie, this is the end-to-end principle thing 🧠. such an attack can only be fully handled by measures that operate directly between the routing entities themselves, or by external entities that access and independently analyze the routing information. so verifying that the routing entities are authentic and "liveliness" (aka they're still alive and active) can only give you a limited counter against internal (Byzantine) node attacks. not a full fix, sorry bestie 🫠

for link-state routing protocols, where info gets flooded with, for example, areas (OSPF [RFC2328]) or levels (IS-IS [RFC7142]), the countermeasures can be applied directly by the routing entities 💅. they do it by processing and comparing the link-state information they get from different peers. by comparing link info from multiple sources, a routing node or an external entity can decide whether the routing information is valid. see Chapter 2 of [Perlman1988] for a discussion on flooding attacks 📚✨

now distance vector protocols, like RPL, are a different story 🥲. info gets aggregated at each routing node, so nodes can't directly detect Byzantine information manipulation attacks from the routing information exchange. the routing protocol must include and support indirect communications exchanges between non-adjacent routing peers, so there's a secondary channel for validating routing information. S-RIP [Wan2004] is an example of this kind of dedicated routing protocol security. the correctness of aggregate distance vector information can only be validated by starting confirmation exchanges directly between nodes that are not routing neighbors 🎀

RPL doesn't have any direct mechanisms like S-RIP, lowkey 😩. what it does do is listen to multiple parents, and it may switch parents if it starts to suspect that it's being lied to. honestly iconic survival behavior 👑

7.3. Availability Attack Countermeasures 🌸

okay, as we talked about before, availability means routing information exchanges and forwarding mechanisms have to be available when they're needed so the network keeps functioning properly 🫶. this may, e.g., include the correct operation of routing information and neighbor state information exchanges, among others. we'll highlight the key features of the security threats, plus typical countermeasures to prevent them or at least mitigate them 💖. also, an availability attack may be facilitated by an identity attack and a replay attack, which we covered in Sections 7.2.3 and 7.2.4, respectively. so they're all connected, periodt 🔗

7.3.1. Countering HELLO Flood Attacks and ACK Spoofing Attacks 🦋

okay so HELLO Flood [Karlof2003], [HELLO], and ACK spoofing attacks are different, but they're highly related forms of attacking an LLN 😭. they basically make nodes believe that suitable routes are available when they're not. that makes them a serious availability attack, no cap 🚨

a HELLO attack against RPL would involve the attacker sending out (or replaying) DODAG Information Object (DIO) messages. then lower-power LLN nodes might try to join the DODAG at a lower rank than they otherwise would 🙈

the most effective method from [HELLO] is bidirectional verification ✨. a number of L2 links get arranged in controller/spoke arrangements, and they're continuously validating connectivity at layer 2. very organized, very slay 💅

also, to calculate metrics, the ETX has to be computed, and generally that means sending a bunch of messages between nodes that are believed to be adjacent. one protocol that does this is [MESH-LINK] 🧚

to join the DODAG, a Destination Advertisement Object (DAO) message gets sent upwards. in RPL, the DAO is acknowledged by the DAO-ACK message. this clearly checks bidirectionality at the control plane 🍓

as discussed in Section 5.1 of [HELLO], a receiver with a sensitive receiver could well hear the DAOs and even send DAO-ACKs as well. such a node is a form of wormhole attack 🌀

these attacks are all easily defended against using either L2 or L3 authentication 🔐. an attack like this could only be made against a completely open network (like one that might be used for provisioning new nodes), or by a compromised node. so it's basically "lock the door or be a compromised insider" 😤

7.3.2. Countering Overload Attacks 🔋

overload attacks are a form of DoS attack, bestie 😩. a malicious node overloads the network with irrelevant traffic, which drains the nodes' energy store faster when they rely on batteries or energy scavenging. so it significantly shortens the lifetime of networks of energy-constrained nodes, and it's another serious availability attack 🪫

energy is one of the most precious assets of LLNs, so targeting its availability is a pretty obvious move for an attacker 💀. another way to deplete an LLN node's energy is to have the malicious node flood the network with irrelevant traffic. this hits availability because certain routes get congested, which:

  • renders them useless for affected nodes; hence, data cannot be delivered;
  • makes routes longer, as the shortest path algorithms work with the congested network; and
  • depletes battery and energy scavenging nodes more quickly, and thus shortens the network's availability at large.

overload attacks can be countered by deploying a series of mutually non-exclusive security measures that:

  • introduce quotas on the traffic rate each node is allowed to send;
  • isolate nodes that send traffic above a certain threshold based on system operation characteristics; and
  • allow only trusted data to be received and forwarded.

on the first one, a simple way to minimize the harmful impact of an overload attack is to introduce traffic quotas 🎀. this stops a malicious node from injecting a huge amount of traffic into the network, though it doesn't stop that node from injecting irrelevant traffic at all. another method is to isolate nodes from the network at the network layer once it's been detected that more traffic is being injected than allowed by a prior set or dynamically adjusted threshold. and finally, if communication is sufficiently secured, only trusted nodes can receive and forward traffic, which also lowers the risk of an overload attack 🫶

⚠️ bestie, receiving nodes that validate signatures and sending nodes that encrypt messages need to be cautious about cryptographic processing usage when they're validating signatures and encrypting messages. where feasible, certificates should be validated before the associated keys are used, to counter potential resource overloading attacks. the design decision also has to consider that the validation process requires resources, so it could itself 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]) 📚

7.3.3. Countering Selective Forwarding Attacks 🧩

selective forwarding attacks are a form of DoS attack that impacts the availability of the generated routing paths 🥀

a selective forwarding attack may be done by a node involved in the routing process. or it may be done by something that otherwise looks like a passive antenna or other RF feature or device, but is actually an active (and selective) device 👀. an RF antenna/repeater that isn't selective is not a threat, so no need to panic about that one 🙅‍♀️

an insider malicious node basically blends in neatly with the network, but then may decide to forward and/or manipulate certain packets 🫣. if all packets get dropped, this attacker is often called a "black hole" 🕳️. this is especially dangerous when it's coupled with sinkhole attacks, since a large amount of traffic gets attracted to the malicious node, which causes significant damage 💔. in a shared medium, an outside malicious node would selectively jam overheard data flows, and the collisions it causes lead to selective forwarding 📡

selective forwarding attacks can be countered by deploying a series of mutually non-exclusive security measures:

  • multipath routing of the same message over disjoint paths; and
  • dynamically selecting the next hop from a set of candidates.

the first measure basically guarantees that if a message gets lost on a particular routing path because of a malicious selective forwarding attack, there will be another route that successfully delivers the data 🛤️. but honestly, that method is suboptimal from an energy consumption point of view, and also suboptimal from a network utilization perspective 😮‍💨. the second method involves a constantly changing routing topology, since next-hop routers are chosen from a dynamic set, in the hope that the number of malicious nodes in that set is negligible 🎲. a routing protocol that allows for disjoint routing paths may also be useful 💜

7.3.4. Countering Sinkhole Attacks 🕳️✨

in sinkhole attacks, the malicious node manages to attract a lot of traffic mainly by advertising the availability of high-quality links even though there aren't any [Karlof2003]. so it's a serious attack on availability, fr fr 😤

the malicious node creates a sinkhole by attracting a large amount of, if not all, traffic from surrounding neighbors. it does this by advertising inward and outward links of superior quality 🪤. so affected nodes eagerly route their traffic via the malicious node. if that's coupled with other attacks, such as selective forwarding, it may lead to serious availability and security breaches 💀. such an attack can only be executed by an inside malicious node, and it's generally very difficult to detect 🕵️‍♀️. an ongoing attack has a profound impact on the network topology and basically becomes a problem of flow control 🌊

sinkhole attacks can be countered by deploying a series of mutually non-exclusive security measures to:

  • use geographical insights for flow control;
  • isolate nodes that receive traffic above a certain threshold;
  • dynamically pick up the next hop from a set of candidates; and
  • allow only trusted data to be received and forwarded.

a canary node could periodically call home (using a cryptographic process) with the home system, noting if it fails to call in. this provides detection of a problem, but it doesn't mitigate it, and it may have significant energy consequences for the LLN 🐤🔋

some LLNs may provide geolocation services, often derived from solving triangulation equations from radio delay calculations 📍. those calculations could, in theory, be subverted by a sinkhole that transmitted at precisely the right power in a node-to-node fashion 😵

while geographic knowledge could help assure that traffic always goes in the physical direction desired, it would not assure that the traffic is taking the most efficient route. the lowest cost real route might match the physical topology, such as when different parts of an LLN are connected by high-speed wired networks 🚄💫

7.3.5. Countering Wormhole Attacks 🌀

okay so in wormhole attacks, at least two malicious nodes claim to have a short path between themselves [Karlof2003] 🙈. This messes with which routing paths are actually available, so it's a seriously big security breach, bestie 💀

Basically, two malicious insider nodes borrow a stronger transmitter to talk to each other and warp the routing path everyone thought was agreed on 🦋. That warp can be a shortcut that paralyzes a huge chunk of the network 😭, or it can tunnel the info to another region where there are, e.g., more malicious nodes to help out with the intrusion, or where messages get replayed, etc. 🌈

When you pair wormholes with selective forwarding, they can cause race conditions that mess with topology maintenance and routing protocols, plus any security suites built on "time of check" and "time of use" 💅.

A pure wormhole attack is nearly impossible to detect 👀. A wormhole used to launch some other kind of attack gets defeated by defeating that other attack ✨. A perfect wormhole, where nothing bad happens to the traffic, would be hard to even call an attack 🫶. The worst a benign wormhole can do is stop working (become unstable), which forces the network to recalculate its routes 🔄.

A highly unstable wormhole is basically a radio opaque (i.e., metal) door that opens and closes nonstop 🚪💀

RPL includes hysteresis in its objective functions [RFC6719] to try to handle frequent changes to the ETX between nodes 💖.

8. RPL Security Features ✨

The assessments and analysis in Section 6 looked at every area of threats and attacks that could impact routing 👀, and the countermeasures in Section 7 were reached without limiting the consideration to means only available to routing 🧠. This section puts all of that into perspective 💅. It deals with the threats that are endemic to this field, the ones RPL protocol design has already mitigated, and the ones that need specific decisions made when a network is provisioned 🎀.

The first part of this section, Sections 8.1 to 8.3, describes the RPL security features that address specific threats 🌸. The second part, Section 8.4, discusses provisioning issues for security aspects that may impact routing but also need considerations beyond the routing protocol, along with potential approaches 🔥.

RPL employs multicast, so these alternative communications modes MUST be secured with the same routing security services specified in this section 🫶. Also, no matter which mode of communication is in use, nodes MUST provide adequate physical tamper resistance commensurate with the particular application-domain environment, so that the confidentiality, integrity, and availability of stored routing information stay safe 🔐.

8.1. Confidentiality Features

okay so with confidentiality, protecting routing/topology information from unauthorized disclosure isn't directly essential to keeping the routing function running 🤷‍♀️. Confidentiality breaches may lead to other attacks or to an attacker focusing their resources (see Section 6.2), but they don't directly undermine how the routing function operates by themselves 🙈. Still, to protect against and reduce the fallout from more direct attacks, routing information should be protected 🛡️. So, to secure RPL:

  • Implement payload encryption using L3 mechanisms described in [RFC6550] or
  • Implement L2 confidentiality

Whenever confidentiality is built into the routing exchanges, the encryption algorithms and key lengths need to be specified to match the level of protection the routing protocol and the associated application-domain transport network call for 💜. For most networks, that means AES-128 in CCM mode, but this needs to be spelled out clearly in the applicability statement ✨.

Now, key lifetimes 🔑. Being able to change the encryption key periodically boosts the level of security for any given implementation 📈. But when strong cryptography is in use, physical, procedural, and logical data access protection can matter more for cryptoperiod selection than algorithm and key size do 🧐. Still, in general, shorter cryptoperiods (the stretches during which a single key is applied) make security stronger 💪.

Since routing node authentication is a mandatory protocol requirement as part of routing integrity (see Section 8.2), key exchanges can be coordinated as part of the integrity verification process 🤝. That's a chance to exchange keys more often and shorten the cryptoperiod, which complements the key length and encryption algorithm required for a given application domain 🌈.

8.2. Integrity Features

The integrity of routing information is the foundation for making sure the routing protocol's function is achieved and stays that way 🏗️. To protect integrity, RPL must run either using only the secure versions of the messages, or over an L2 that uses channel binding between node identity and transmissions 🔒.

Some L2 security mechanisms use a single key for the entire network 😬. Those networks can't provide much integrity protection, because any node that has that key can impersonate any other node 👻. This mode is likely acceptable when an entire deployment is under the control of a single administrative entity 🏠.

Other L2 security mechanisms form a unique session key for every pair of nodes that need to communicate, which is often called a per-link key 🗝️. Networks like that can provide a strong degree of origin authentication and integrity on unicast messages 💖.

But some RPL messages are broadcast, and even when per-node L2 security mechanisms are used, the integrity and origin authentication of broadcast messages can't be trusted as much 😩. The reason is the proliferation of the key used to secure them 🔑.

RPL has two specific options that are broadcast in RPL Control Messages: the DIO and the DODAG Information Solicitation (DIS) 📡. The DIS exists to make potential parents reply with a DIO, so the integrity of the DIS isn't a big concern 🤷‍♀️. The DIS may also be unicast 💌.

The DIO is a critical piece of routing and carries many critical parameters 👑. RPL provides for asymmetric authentication at L3 of the RPL Control Message carrying the DIO, and this may be warranted in some deployments 🎀. If a node felt that a DIO it had received was suspicious, it could send a unicast DIS message to the node in question, and that node would reply with a unicast DIS 🕵️‍♀️. Those messages could be protected with the per-link key 🔐.

8.3. Availability Features

Availability of routing information is linked to system and network availability 🌐. For LLNs, that means a broader security view is needed, beyond just the requirements of the routing entities 🧠. When network availability is compromised, routing information availability gets affected too 📉. But to specifically help protect routing availability, nodes MAY:

  • restrict neighborhood cardinality;
  • use multiple paths;
  • use multiple destinations;
  • choose randomly if multiple paths are available;
  • set quotas to limit transmit or receive volume; and
  • use geographic information for flow control.

8.4. Key Management

The routing security services can't function without keys and credentials 🔑. So even though it's not directly an RPL security requirement, an LLN MUST have a process for initial key and credential configuration, along with secure storage within the associated devices 🔐. Anti-tampering SHOULD be a consideration in physical design 🛠️. Beyond the initial credential configuration, an LLN is also encouraged to have automatic procedures for revoking and replacing the maintained security credentials 🔄.

While RPL has secure modes, some of them are impractical without public key cryptography, which many people believe is too expensive 💸. RPL L3 security will often depend on existing LLN L2 security mechanisms, which provide node authentication but not much in the way of node authorization 🙃.

9. Security Considerations

The analysis presented in this document provides security analysis and design guidelines with a scope limited to RPL 📝. Security services are identified as requirements for securing RPL 🔒. The specific mechanisms used to deal with each threat are specified in link-Land and deployment-specific applicability statements 📋.

10. References

10.1. Normative References

10.2. Informative References 📚✨

Okay bestie, these are the informative refs. They're the extra reading that backs up the doc, so you don't need them to implement anything, but they're super useful for context. Here's the full list, all of the details intact 💅

Acknowledgments 🫶

Big thank yous to the reviewers! Rene Struik and JP Vasseur reviewed and commented on the work, and the authors also want to shout out the guidance and input from the ROLL Chairs, David Culler and JP Vasseur, plus Area Director Adrian Farrel. 💜

This document started out as a combined threat and solutions document 🧚. After a series of security reviews by Steve Kent, ROLL Co-Chair Michael Richardson and Security Area Director Sean Turner split it up during the IETF publication process. The solutions to the threats are application and L2 specific, so they moved into the relevant applicability statements. ✨

Ines Robles and Robert Cragie kept track of the many issues raised during development. They were the real MVPs 👑

Authors' Addresses 🎀

Tzeta Tsao
Eaton's Cooper Power Systems Business
910 Clopper Rd., Suite 201S
Gaithersburg, Maryland  20878
United States
EMail: tzetatsao@eaton.com

Roger K. Alexander
Eaton's Cooper Power Systems Business
910 Clopper Rd., Suite 201S
Gaithersburg, Maryland  20878
United States
EMail: rogeralexander@eaton.com

Mischa Dohler
CTTC
Parc Mediterrani de la Tecnologia, Av. Canal Olimpic S/N
Castelldefels, Barcelona  08860
Spain
EMail: mischa.dohler@kcl.ac.uk

Vanesa Daza
Universitat Pompeu Fabra
P/ Circumval.lacio 8, Oficina 308
Barcelona  08003
Spain
EMail: vanesa.daza@upf.edu

Angel Lozano
Universitat Pompeu Fabra
P/ Circumval.lacio 8, Oficina 309
Barcelona  08003
Spain
EMail: angel.lozano@upf.edu

Michael Richardson (editor)
Sandelman Software Works
470 Dawson Avenue
Ottawa, ON  K1Z5V7
Canada
EMail: mcr+ietf@sandelman.ca
📦 where this page comes from